Повеќето интеграции со ВИ пропаѓаат од изненадувачки обична причина: на моделот му се задава задача, но не и логиката што ѝ дава смисла на задачата.

Моделот може да сумира тикет, да состави е-порака, да класифицира документ или да повика алатка. Она што не може поуздано да го заклучи е непишаниот систем на ограничувања зад тие дејства: кои состојби на клиентот се важни, што значи „одобрено“, каде припаѓаат исклучоците, кој може да поништи одлука и кои операции се безбедни за автоматизирање.

Корисната промена е да престанете да ја третирате ВИ како паметно поле за текст и да почнете да ја третирате како учесник во систем. Како и на секој учесник, ѝ се потребни јасна улога, ограничен интерфејс, релевантен контекст и повратна информација кога ќе згреши.

Логиката е слојот за интеграција

Деловната логика често е распределена низ полиња во базата на податоци, сервисен код, дијаграми на работни текови, прирачници за поддршка и акумулираното знаење на луѓето кои знаат каде се замките. Функција со ВИ станува сигурна кога таа логика е доволно јасно изразена за моделот да може да ја користи.

Разгледајте асистент за поддршка што подготвува одговори за неуспешни плаќања. Општ потсетник може да побара од него „да му помогне на клиентот да го реши проблемот со плаќањето“. Тоа звучи разумно, но остава неодговорени клучни прашања. Дали плаќањето е одбиено или сè уште чека? Дали клиентот веќе се обидел повторно? Дали сметката е заклучена? Дали регионот наметнува поинаков процес за поврат на средства? Дали асистентот треба да понуди повторен обид, да побара верификација или да ескалира?

На моделот не му е потребен секој ред од секоја табела. Му е потребен компактен, доверлив приказ на фактите и правилата релевантни за одлуката.

{
  "payment_status": "declined",
  "retry_count": 1,
  "account_locked": false,
  "eligible_actions": ["retry_payment", "update_payment_method"],
  "prohibited_actions": ["issue_refund"],
  "escalation_required": false
}

Таа структура прави две работи. Му го дава на моделот контекстот што му е потребен и го ограничува искушението да измисли дејство што околниот систем би го одбил.

Одделете ја проценката од овластувањето

ВИ е корисна за толкување: извлекување намера, забележување обрасци, предлагање следен чекор и претворање структурирани факти во јасен јазик. Таа е многу помалку соодветна како конечен авторитет за правила што мора да бидат прецизни, проверливи или доследно спроведувани.

Добриот дизајн му дозволува на конвенционалниот софтвер да ги поседува детерминистичките одлуки. Вашата апликација треба да пресметува дозволи, подобност, цени, салда, проверки на политики и состојба на работниот тек. Моделот потоа може да го објасни резултатот, да побара информации што недостигаат, да рангира опции или да подготви нацрт-дејство.

Ова не е ограничување за кое треба да се извинувате. Тоа е архитектура што ја прави ВИ побезбедна и полесна за подобрување. Ако се промени правило, ажурирајте го правилото на едно место. Не надевајте се дека ревидиран пасус во потсетник ќе се применува доследно на секоја патека.

Користете ги алатките како тесни договори

Кога агентот може да дејствува врз систем, секоја алатка треба да се однесува како внимателно дизајниран API, наместо како неограничена способност. Дајте им на алатките конкретни имиња, ограничени влезни податоци, јасни повратни вредности и проверки на овластување што се спроведуваат надвор од моделот.

На пример, create_refund_request е побезбедна од широка алатка manage_payment. Првата може да бара идентификатор на нарачка и причина, да ја потврди подобноста на серверот и да врати или идентификатор на барање или структурирано одбивање. Моделот може да одлучи да го побара дејството; не треба да може да ги заобиколи условите за негово извршување.

• Изложувајте само дејства што на агентот навистина му се потребни.
• Потврдете го секој влез за алатка на серверот.
• Враќајте причини за неуспех читливи за машина каде што е можно.
• Направете ги дејствата со значајни последици прегледливи, повратни или и двете.
• Запишувајте ги влезовите, повиците на алатките, резултатите и конечниот исход за корисникот.

Поучувајте ги правилата преку контекст, а не преку желби во потсетници

Потсетниците се вредни, но „биди точен“ не е системски дизајн. Силните упатства воспоставуваат улога, приоритети, забрането однесување, формат на излез и правила за ескалација. Најдобро функционираат кога се спарени со тековен контекст преземен од авторитетни извори.

Да претпоставиме дека внатрешен оперативен асистент помага при распоредување работа на терен. Неговите упатства може да кажуваат дека безбедносните ограничувања имаат предност пред целите за испорака и дека мора да ескалира кога податоците за доделувањето се во конфликт. При извршување, апликацијата ги доставува сертификатите на техничарот, потребните квалификации за работниот налог, ограничувањата за патување и тековната политика за распоредување.

Клучната разлика е меѓу стабилни насоки и променливи факти. Стабилните насоки припаѓаат во упатства и дефиниции на политики контролирани со верзии. Променливите факти треба да пристигнуваат преку доверливо преземање или контекст обезбеден од апликацијата. Мешањето на двете во огромен потсетник создава застарени информации, го отежнува дебагирањето и ја зголемува веројатноста нерелевантниот материјал да му го одвлече вниманието на моделот.

Дизајнирајте за неизвесност и неуспех

Моделите може погрешно да разберат двосмислено барање, да создадат неважечки аргумент за алатка или да изберат опција што изгледа веројатна, но е во конфликт со скриено ограничување. Мрежните повици може да истечат. Последователна услуга може да одбие барање откако агентот веќе објаснил што има намера да направи.

Работен тек за продукциска средина бара експлицитно однесување за тие случаи. Агентот треба да знае кога да постави прашање за појаснување, кога повторно да се обиде со безбедна операција за читање и кога да ја предаде работата на лице. Никогаш не треба да навестува дека дејството успеало сè додека авторитетниот систем не го потврди успехот.

За операција за запишување, низата обично е едноставна: потврдете го барањето, извршете го дејството преку апликацијата, проверете го вратениот статус и дури потоа соопштете го резултатот. Ако дејството не успее, одговорот треба да го опише следниот корисен чекор без да изложува внатрешни детали за имплементацијата или да се преправа дека неуспехот не се случил.

Оценете ја целата патека

Тимовите често проверуваат дали моделот дава пријатен одговор. Тоа е неопходно, но нецелосно. Тестирајте го работниот тек како синџир: преземање контекст, расудување на моделот, избор на алатка, валидација на влез, одговор од алатката, однесување при повторен обид и конечна комуникација.

Создајте репрезентативни случаи пред широко воведување. Вклучете нормални барања, податоци што недостигаат, конфликтни упатства, неуспеси со дозволи, застарени записи, небезбедни барања и двосмислен јазик. За секој случај, дефинирајте како изгледа добар исход. Понекогаш точниот исход не е завршување; тоа е навремено одбивање, прашање за појаснување или ескалација.

Оценувањето треба да продолжи и по објавувањето. Прегледувајте ги обрасците на неуспех, не само просечниот успех. Ако истиот исклучок се појавува постојано, подобрете го основниот работен тек или изворните податоци наместо бескрајно да додавате упатства во потсетници.

Започнете со ограничен работен тек

Најсилните рани функции со ВИ ретко се најтеатрални. Изберете работа што има јасен влез, корисен излез, достапни изворни податоци и човечка или детерминистичка контролна точка за важните последици. Подготовката на структурирано резиме за инцидент, тријажата на пристигнати барања или подготовката на контролна листа за преглед на промени може да донесе вредност, додека ги открива вистинските предизвици на интеграцијата.

Почнете тесно, набљудувајте како луѓето го користат и проширувајте само кога системот може да објасни зошто дал препорака и што направил потоа. Ова гради доверба во производот и го учи тимот кои делови од сопствената логика претходно биле имплицитни.

ВИ станува корисна кога станува одговорна

Трајната можност не е да се замени софтверската логика со модел. Таа е да се поврзе модел со софтверската логика на начин што ги прави сложените системи полесни за користење.

Научете ја ВИ за состојбата што ѝ е потребна. Ставете ги правилата таму каде што можат да се спроведуваат. Дајте ѝ тесни, доверливи алатки. Очекувајте неуспеси и мерете го целиот работен тек. Кога системот со ВИ може да расудува во рамки на реални ограничувања и да ја покаже својата работа преку сигурни исходи, тој престанува да биде интерфејс-новитет и станува способен дел од производот.