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

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

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

Почнете со ограничена задача, не со општ асистент

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

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

Пред да изберете модел или да напишете промпт, дефинирајте четири работи:

• Каков влез прима системот, вклучително и очекуваната неуредност.
• Кој излез е корисен и како ќе се користи.
• Кои дејства, доколку ги има, системот смее да ги преземе.
• Што треба да се случи кога одговорот недостига, е несигурен, неправилно форматиран или небезбеден.

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

Држете го генерирањето јазик одделено од деловното овластување

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

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

{
  "action": "reschedule_meeting",
  "event_reference": "tomorrow planning session",
  "new_time_window": "Friday afternoon",
  "add_attendee_role": "design_lead"
}

JSON не е дејството. Тој е недоверлив предлог. Валидирајте го според шема, разрешете ги референците во авторитативни системи и одбијте или разјаснете сè што не може безбедно да се протолкува. Никогаш не дозволувајте текст генериран од модел да стане барање до база на податоци, shell команда, одлука за овластување или API барање без наменски слој за валидација.

Користењето алатки има потреба од договори и заштитни механизми

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

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

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

Претпоставете дека преземениот текст е недоверлив

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

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

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

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

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

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

Дизајнирајте за вообичаен неуспех

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

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

Доброто UX е дел од сигурноста. Корисен интерфејс прави разлика меѓу „Не најдов одговор“, „Ми треба детал“, „Не можев да го завршам дејството“ и „Го завршив ова дејство“. Ова се различни состојби, а нивното третирање како ист весел одговор во разговор ја нарушува довербата.

Направете го човечкиот преглед производна одлука

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

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

Вистинската интеграција е организациска

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

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