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

Реалноста се тековниот клиент, неговите дозволи, состојбата на нарачката, верзијата на API-договорот, трансакцијата во базата на податоци што сè уште не е потврдена и оперативните ограничувања на услугата што го обработува барањето. Да се научи ВИ на таа реалност е проблем од бекенд-инженерството.

Продуктивното прашање не е: „Како да напишеме подобар промпт?“ Туку: „Каков проверен контекст и кои безбедни дејства може овој систем да ги обезбеди токму во овој момент?“

Контекстот е производ на вашата архитектура

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

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

Разгледајте асистент за поддршка што е прашан: „Зошто овој клиент не може да го извезе својот извештај?“ Нејасен промпт може да вклучува е-пошта на корисник и да побара од моделот да го дијагностицира проблемот. Втемелен систем, наместо тоа, може да го разреши автентицираниот актер, да ги преземе можностите на претплатата на целната сметка, да ја провери состојбата на задачата за извештајот и да му обезбеди на моделот експлицитни факти:

{
  "account_id": "acct_123",
  "plan": "standard",
  "export_feature_enabled": false,
  "report_status": "ready",
  "actor_can_manage_billing": true
}

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

Дајте му на моделот можности, а не пристап до базата на податоци

Честа архитектонска грешка е интеграцијата на ВИ да се третира како кратенка околу границата на апликацијата. Директниот пристап до базата на податоци изгледа моќно бидејќи прави повеќе информации достапни. Тој, исто така, ги заобиколува валидацијата, авторизацијата, ревизијата и деловните правила за кои биле потребни години да се изградат.

Наместо тоа, изложете тесни операции што ја откриваат намерата. Моделот треба да повика нешто како getReportExportEligibility(accountId), а не да составува произволен SQL. Треба да побара createRefundDraft(orderId, reason), а не да ажурира табела за плаќања.

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

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

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

Дизајнирајте за застарена состојба и неуспешни повици

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

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

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

try {
    $result = $billingService->createUpgradeDraft(
        accountId: $accountId,
        requestedPlan: $plan
    );
} catch (PlanNotAvailable $exception) {
    return ['status' => 'unavailable'];
} catch (TemporaryBillingFailure $exception) {
    return ['status' => 'retry_later'];
}

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

Нека доменскиот јазик ја заврши тешката работа

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

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

Чувајте ја политиката надвор од разговорот

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

Корисно правило е едноставно: ако прекршувањето на правило би било баг кога човек ќе кликне копче, тоа е баг и кога ВИ ќе повика алатка.

Набљудувајте ја целата патека на одлучување

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

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

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

Промптовите ќе продолжат да се менуваат. Моделите ќе се подобруваат. Ниту едно од тоа не ја отстранува потребата јасно да се моделира вистината на вашиот систем.

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