Надвор од поттикот: Архитектирајте го вашиот код за да вградите деловна логика за ВИ
Повеќето неуспеси при AI кодирање не започнуваат со слаб промпт. Тие започнуваат со апликација што има скриени правила, нејасна одговорност и деловни одлуки расфрлани низ контролери, барања до базата на податоци, услови во UI и нечија меморија.
Јазичниот модел може да генерира код, да класифицира барања, да сумира документи или да управува со алатки. Но не може сигурно да постапува според деловна логика што никогаш не била изречно дефинирана. Ако агентот треба да одлучи дали да издаде поврат на средства, да насочи случај за поддршка, да одобри трошок или да ажурира запис за клиент, му треба повеќе од промпт што ги опишува намерите на компанијата. Му требаат софтверски граници што ги прават тие намери извршливи, тестирабилни и набљудливи.
Практичната промена е едноставна: престанете да ги третирате промптовите како примарна локација за деловната логика. Третирајте ги како интерфејс кон систем чии правила живеат во код, податоци и контролирани работни текови.
Промптовите не се траен механизам за правила
Промптовите се корисни за изразување цели, контекст, тон и инструкции специфични за задачата. Тие не се идеални за спроведување правила што мора да бидат прецизни и повторливи.
Разгледајте AI агент за поддршка од кого се бара да обработува барања за откажување. Промптот може да каже дека клиентите можат да добијат поврат на средства во рок од 30 дена, освен ако користеле премиум услуга или нивната сметка е под проверка. Тоа звучи јасно сè додека агентот не мора да одговори на практични прашања: Која временска ознака го одредува датумот на купување? Што се смета за користење? Кој става сметка под проверка? Може ли менаџер да го поништи резултатот?
Тоа се прашања за политики, но не треба одново да се решаваат во излезот на моделот. Тие припаѓаат во доменски слој со именувани концепти, структурирани влезови и детерминистички исходи.
type RefundDecision =
| { eligible: true; reason: "within_window" }
| { eligible: false; reason: "outside_window" | "service_consumed" | "account_review" };
function assessRefund(order: Order, account: Account, now: Date): RefundDecision {
if (account.isUnderReview) {
return { eligible: false, reason: "account_review" };
}
if (order.premiumServiceConsumed) {
return { eligible: false, reason: "service_consumed" };
}
const ageInDays = (now.getTime() - order.paidAt.getTime()) / 86_400_000;
return ageInDays <= 30
? { eligible: true, reason: "within_window" }
: { eligible: false, reason: "outside_window" };
}Моделот може да ги прибере информациите што недостигаат, да ја објасни одлуката на разбирлив јазик и да го започне одобрениот работен тек. Апликацијата треба да ја утврдува подобноста.
Дизајнирајте го AI како клиент на вашиот домен
Корисно архитектонско правило е на AI агентот да му се даде истото ниво на почит и ограничувања како на секој друг надворешен клиент. Тој не треба директно да пристапува до продукциски табели, да заклучува дозволи од проза или да составува произволни операции за запишување.
Наместо тоа, изложете внимателно дизајнирани можности. Можноста треба да претставува деловно дејство, а не операција на ниско ниво со база на податоци. Претпочитајте createRefundRequest наместо updateOrderStatus. Претпочитајте assignCaseToQueue наместо setOwnerId.
Оваа разлика е важна бидејќи деловното дејство може да ја провери авторизацијата, да спроведе премини меѓу состојби, да создаде запис за ревизија и да врати значаен резултат. Сирово ажурирање не може само по себе да ги изрази тие заштитни мерки.
Направете ги договорите за алатките тесни и изречни
Секоја алатка достапна за агент е оперативно ветување. Одржувајте ја нејзината влезна шема мала, валидирајте ја на серверот и враќајте структурирани исходи што моделот може да ги користи без нагаѓање.
{
"caseId": "CS-1042",
"targetQueue": "billing",
"reason": "refund_question"
}Алатката треба да одбие неважечка редица, случај до кој повикувачот нема пристап или премин што ги прекршува правилата на работниот тек. Грешката треба да биде применлива, како „случајот е веќе затворен“, наместо нејасен неуспех на серверот. Тоа му овозможува на агентот да закрепне со објаснување на ограничувањето или со барање човек да интервенира.
Не потпирајте се на инструкција во промптот како „повикај ја оваа алатка само за овластени корисници“. Спроведете ја авторизацијата во самата алатка. Насоките во промптот го обликуваат однесувањето; контролите на апликацијата воспоставуваат гаранции.
Претворете го неформалното знаење во извршлива политика
AI иницијативите често откриваат корисна непријатност: тимовите знаат дека нивната деловна логика е реална, но не можат да посочат каде се наоѓа. Правилото може да биде поделено меѓу продажен прирачник, макро за поддршка, табеларна пресметка и услов закопан во стара услуга.
Пред да поврзете агент со последични дејства, идентификувајте ги одлуките врз кои ќе влијае. За секоја од нив, дефинирајте:
- влезовите потребни за донесување на одлуката;
- авторитативниот извор за секој влез;
- дозволените исходи и премини меѓу состојби;
- лицето или системот одговорен за исклучоците;
- податоците за ревизија потребни подоцна да се објасни што се случило.
Оваа работа не е бирократија околу AI. Тоа е инженерската работа потребна за автоматизацијата да биде доверлива. Ако политиката не може да се претстави доволно јасно за да се тестира, таа е премногу нејасна за безбедно да ѝ се делегира на модел.
Одделете го расудувањето од извршувањето
Моделите се вредни кога јазикот, двосмисленоста и нецелосните информации се суштински за задачата. Тие можат да извлечат намера од е-пошта, да сумираат долга историја на случај, да откријат дека барањето треба да се ескалираат или да состават одговор прилагоден на прашањето на клиентот.
Тие силни страни не бараат на моделот да му се даде конечна контрола врз неповратни дејства. Робустен работен тек го одделува толкувањето од извршувањето:
- Моделот го толкува барањето и предлага структурирано дејство.
- Апликацијата го валидира дејството според деловните правила и дозволите.
- Работниот тек или го извршува, или бара одобрување, или враќа јасно ограничување.
- Моделот му го соопштува потврдениот резултат на корисникот.
На пример, агентот може да препознае дека фактурата изгледа дуплирана. Тој може да ги собере идентификаторите на фактурата и да подготви препорака. Сервисот за наплата треба да одлучи дали е исполнет условот за дупликат и дали може да се издаде кредит. За случаи со големо влијание, сервисот може да создаде задача за одобрување наместо автоматски да го примени кредитот.
Овој образец исто така го подобрува корисничкото искуство. Наместо да измислува сигурност, агентот може да каже што пронашол, кое правило се применило и што ќе се случи понатаму.
Градете за повторни обиди, неуспех и преглед
Вистинските системи не се демонстрации со еден чекор. Мрежите откажуваат, корисниците се премислуваат, алатките истекуваат по време и моделот може да повтори барање откако ќе добие нејасен одговор. Дизајнирајте ги деловните операции да ја толерираат оваа реалност.
Користете идемпотентност за дејства за запишување, така што повторениот обид нема да создаде два поврата на средства или два тикети за поддршка. Забележете го идентитетот на барањето, актерот, влезовите, резултатот од валидацијата и резултирачката состојба. Направете ја долготрајната работа асинхрона кога е потребно, враќајќи статус што агентот може да го провери наместо да се преправа дека завршувањето е моментално.
Човечкиот преглед треба да биде исход од прв ред, а не засрамувачка резервна опција. Добрата ескалација ги вклучува релевантниот контекст, предложеното дејство, правилото што ја блокирало автоматизацијата и точната одлука што треба да ја донесе прегледувачот. Тоа го намалува триењето при предавањето, додека ја зачувува одговорноста.
Тестирајте го системот, не само промптот
Тестовите за промптови и понатаму се важни, особено за извлекување намера и квалитет на одговорот. Но тестовите со поголема вредност го проверуваат однесувањето на доменот околу моделот. Тестирајте неважечки аргументи на алатка, неовластени барања, застарени записи, дуплирани поднесувања, делумни неуспеси и спротивставени состојби на политики.
Ограничете го излезот на моделот каде што е можно. Барајте структурирани полиња, валидирајте ги и третирајте го неправилно форматираниот излез како поправлива влезна грешка. Моделот може да биде пробабилистички; системот околу него не треба да биде немарен.
Трајната лекција е дека AI станува покорисен како што вашиот софтвер станува поизречен за тоа во што верува, што дозволува и што запишува. Промптовите можат да направат агентот да звучи способен. Добро архитектурираната деловна логика го прави доверлив. Кога моделот е поврзан со јасни доменски можности наместо со нејасни инструкции и широк пристап, добивате нешто повредно од импресивна демонстрација: автоматизација што заслужува место во вистинската работа.
