AI (Вештачка Интелигенција)

Architecting Software to Teach AI Your Business Nuances

Архитектура на софтвер за да ја научите ВИ на нијансите на вашиот бизнис

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

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

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

Започнете со одлуки, а не со интерфејси за разговор

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

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

Опишете го работниот тек пред да изберете модел:

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

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

Одвојте ги знаењето, политиката и дејството

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

Знаењето се информациите потребни за разбирање на случајот

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

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

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

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

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

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

Секоја алатка изложена на систем со ВИ е интерфејс со последици. Дизајнирајте ги алатките тесно. Алатка со име update_subscription што прифаќа произволни полиња е тешка за управување. Алатка како request_plan_change_quote, проследена со apply_approved_plan_change, ги прави намерата и овластувањето многу појасни.

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

Изградете го контекстот како продуктна површина

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

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

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

{
  "customer_tier": "business",
  "current_plan": "standard",
  "account_status": "active",
  "region": "EU",
  "change_request": "upgrade",
  "requires_human_approval": false
}

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

Користете ги агентите како оркестрирани работни текови

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

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

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

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

Направете ја евалуацијата дел од архитектурата

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

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

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

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

Дајте им на луѓето влијание, а не формален надзор

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

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

Трајната предност е кодифицирано разбирање

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

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

Портрет на автор на блогот

Mihajlo

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