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

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

Промптовите се инструкции, а не институционално знаење

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

Разгледајте асистент за корисничка поддршка. „Биди корисен и емпатичен“ е корисна насока, но не одговара на прашања како: Кои планови вклучуваат приоритетна поддршка? Кога може да се одобри поврат на средства? Што треба да се случи ако сметката е под ревизија? Која верзија на производот ја користи клиентот?

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

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

Изградете слој за деловен контекст

Практичниот ВИ-систем обично има потреба од повеќе од API за модел и внимателно напишан системски промпт. Му е потребен контекстуален слој што го поврзува моделот со одобрено знаење и деловна состојба.

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

Почнете со тесен работен тек со висока вредност. На пример, внатрешен асистент што подготвува нацрт-одговор на тикет за поддршка може да добие:

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

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

Преземањето бара дисциплина

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

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

Дајте им алатки на агентите, а потоа ограничете ги последиците

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

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

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

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

Барање од корисникот
  -> Преземи одобрен контекст
  -> Моделот предлага дејство
  -> Валидирај политика и дозволи
  -> Побарај преглед кога е потребно
  -> Изврши тесно дефинирана алатка
  -> Запиши го резултатот

Оваа структура не ја прави ВИ помалку способна. Таа ја прави способноста доволно сигурна за употреба.

Направете ја неизвесноста исход од прва класа

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

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

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

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

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

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

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

Нека повратните информации го подобруваат работниот тек

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

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

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

Од умно демо до доверлив колега

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

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