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

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

Почнете со одлуката, не со моделот

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

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

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

Дизајнирајте ја ВИ како ненадежен соработник

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

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

• Ограничете ги влезовите. Јасно дефинирајте ги задачата, достапниот контекст и дозволените дејства.
• Валидирајте ги излезите. Проверувајте формати, задолжителни полиња, опсези, идентификатори и дозволи во обичен апликациски код.
• Ограничете го овластувањето. Дајте му на агентот минимум алатки и податоци потребни за неговата работа.
• Барајте потврда. Поставете чекор за човечко одобрување пред последователни надворешни дејства.
• Евидентирајте ги одлуките. Зачувајте ги релевантните влезови, повици кон алатки, излези и исходи за дебагирање и преглед.

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

Држете ги деловните правила надвор од промптот

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

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

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

Користете структурирани граници

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

{
  "action": "create_draft",
  "customer_id": "string",
  "summary": "string",
  "requires_review": true
}

Шемата не го прави излезот точен. Таа го прави договорот проверлив. Вашата услуга сè уште треба да потврди дека клиентот постои и дека повикувачот е овластен да ја создаде нацрт-верзијата.

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

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

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

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

Планирајте го неуспехот како нормална состојба

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

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

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

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

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

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

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

Дајте им на луѓето значајна контрола

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

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

Архитектурата е местото каде што довербата станува реална

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

Сметајте го моделот за моќна компонента, а не за самата апликација. Нека толкува, генерира, рангира и помага. Нека околната архитектура ги дефинира вистината, дозволата, политиката и одговорноста. Така ВИ станува повеќе од привлечен интерфејс: станува систем на кој луѓето можат да се потпрат.