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

Способен модел може да резимира договор, да состави одговор за поддршка, да напише SQL пребарување или да насочи задача. Но, тој не знае автоматски кои услови за клиентите не се предмет на преговори, што значи „одобрено“ во одреден работен тек, каде се наоѓа единствениот извор на вистината или кога мора да застане и да побара човек. Тие детали се бизнисот. Ако останат заробени во главите на луѓето, расфрлани документи и неконзистентни системи, ВИ агентот ќе произведува полирани претпоставки.

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

Деловното знаење е повеќе од документација

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

Вистинското оперативно знаење има најмалку четири форми:

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

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

Почнете со одлуки, а не со промптови

Најпродуктивното прашање не е: „Што може да прави нашиот ВИ четбот?“ Наместо тоа, прашајте: „Кои повторливи одлуки трошат стручно внимание и кои информации и ограничувања ги обликуваат?“

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

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

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

Мапирајте ја работата пред да ја автоматизирате

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

1. Изберете процес со голем обем и јасни граници, со значаен но управлив трошок при грешка.
2. Соберете репрезентативни примери, вклучително и нецелосни барања и незгодни гранични случаи.
3. Дефинирајте ја излезната шема и дејствата што системот смее да ги преземе.
4. Одделете го советодавното однесување од дејствата што менуваат записи, трошат пари, откриваат податоци или контактираат клиенти.
5. Осмислете патека за ескалација пред да се овозможи првото автоматизирано дејство.

Ова е помалку гламурозно од широка најава за „ВИ трансформација“. Но, така системите стануваат сигурни.

Направете го знаењето употребливо за софтверот

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

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

{
  "destination": "example-region",
  "shipping_method": "expedited",
  "eligible": false,
  "reason_code": "METHOD_UNAVAILABLE_FOR_DESTINATION"
}

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

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

Градете агенти со ограничени овластувања и јасни договори

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

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

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

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

Оценувајте го деловниот процес, а не само одговорот

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

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

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

Обучувајте ја организацијата додека ја обучувате ВИ

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

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

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