Следната важна улога во софтверскиот дизајн можеби нема да биде „prompt engineer“. Таа е поблиска до архитект: некој што може нејасна деловна цел да ја претвори во ВИ-систем што се однесува доволно корисно, безбедно и предвидливо за да заслужи место во реалната работа.

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

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

Гледајте на агентот како на систем, а не како на четбот

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

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

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

Почнете со границата на работниот тек

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

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

Дефинирајте го договорот на агентот пред да ги дизајнирате неговите потсетници:

• Влез: Кои информации пристигнуваат, во кои формати и од кои доверливи системи?
• Исход: Каков конкретен резултат треба да произведе работниот тек?
• Дозволени дејства: Кои читања, запишувања, известувања или трансакции смее да ги изврши?
• Точки за одобрување: Кои одлуки бараат потврда од лице или од друга детерминистичка услуга?
• Однесување при неуспех: Што треба да се случи кога недостигаат докази, алатка не успее или сигурноста е недоволна?

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

Одделете го расудувањето од извршувањето

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

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

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

Направете ги значајните дејства експлицитни

Не секоја алатка заслужува ист степен на автономија. Читањето јавен каталог на производи е различно од испраќањето надворешна е-пошта. Испраќањето е-пошта е различно од менувањето сопственост на сметка или иницирањето плаќање.

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

Ова не е само безбедносна функција. Ја подобрува довербата на корисниците. Луѓето полесно ќе усвојат агент кога можат да видат што има намера да направи и да ја задржат контролата во моментите што се важни.

Контекстот е одлука за производот

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

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

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

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

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

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

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

Набљудливоста е подеднакво важна. Евидентирајте повици кон алатки, одлуки, влезови што е безбедно да се задржат, верзии на излезот, грешки и настани на одобрување. Целта не е неселективно да се снима секој приватен разговор; туку важното однесување да биде проверливо, со почитување на барањата за ракување со податоци.

Оценувајте го целиот работен тек

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

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

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

Новата одговорност на архитектот

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

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

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