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

За програмерите, практичната промена е едноставна. Престанете да третирате ВИ-модел како паметно поле за текст. Третирајте го како ненадежна, но корисна компонента во внимателно дизајниран софтверски систем.

Моделот учи од средината што ја градите

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

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

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

Контекстот е интерфејс, а не истурање документи

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

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

Силниот слој за контекст одговара на неколку практични прашања:

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

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

Алатките го претвораат четботот во систем

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

Основниот принцип на дизајн е најмала привилегија. Дајте му на агентот најмал сет дејства потребен за тековната задача и направете ги алатките тесно наменски. Алатка именувана update_customer_record треба да бара конкретен идентификатор и изречно дефинирани полиња. Широка алатка што прифаќа произволни инструкции и ги извршува на друго место создава непотребна граница за безбедност и сигурност.

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

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

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

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

Евалуацијата е начинот на кој ВИ-производот станува доверлив

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

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

Корисните мерења зависат од производот, но прегледот треба да ги разликува барем следниве димензии:

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

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

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

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

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

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

Изградете го оперативниот модел, а не само функционалноста

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

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

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