Повеќето иницијативи за ВИ започнуваат со прашање за моделите: Кој добавувач треба да го користиме? Колкав треба да биде прозорецот на контекстот? Дали агент може да повикува алатки? Овие прашања се важни, но доаѓаат по поважното: што всушност знае овој бизнис и каде живее тоа знаење?

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

Бизнис-знаењето е повеќе од документација

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

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

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

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

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

Добрите кандидати често вклучуваат:

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

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

Засновајте ги моделите на докази, не на самодоверба

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

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

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

Дајте му на системот јасна граница

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

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

{
  "action": "create_change_request",
  "service": "billing-api",
  "summary": "Add validation for missing currency",
  "requires_approval": true
}

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

Третирајте ги агентите како софтверски системи

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

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

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

Мерете ја работата, не разговорот

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

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

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

Изградете институционална меморија без да создадете црна кутија

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

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

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