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

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

Почнете со деловни факти, а не со промптови

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

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

Практичната граница често изгледа вака:

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

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

Вградете деловен речник во API-то

Бекенд API-јата треба да зборуваат со доменски концепти, а не со апстракции обликувани според базата на податоци. Генеричка крајна точка како GET /records?id=123 нуди мала помош за работен тек со ВИ или за човечки одржувач. Крајна точка ориентирана кон можности, како GET /orders/123/support-context, може да обезбеди намерен, ревидиран приказ на тоа што поддршката смее да знае.

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

final class OrderSupportContext
{
    public function __construct(
        public readonly string $orderId,
        public readonly string $status,
        public readonly bool $cancellationAllowed,
        public readonly array $shipmentEvents,
        public readonly array $applicablePolicies,
    ) {}
}

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

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

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

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

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

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

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

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

Стабилниот работен тек го раздвојува предлогот од извршувањето:

1. Апликацијата ја идентификува намерата на корисникот и собира овластен контекст.
2. Моделот враќа структуриран излез, како побарано дејство и објаснување.
3. Бекендот го валидира тој излез според шема и деловни правила.
4. Детерминистичка услуга извршува дозволено дејство или бара човечки преглед.
5. Системот ги евидентира одлуката, влезовите, резултатот и релевантните верзии на изворите.

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

Дизајнирајте за неуспех пред обем

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

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

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

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

Мерете го системот, не само моделот

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

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

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

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

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