Повеќето неуспеси на ВИ во деловниот софтвер не се неуспеси на моделот. Тие се неуспеси на сопственоста.

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

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

Почнете со прашањето: кој го поседува овој факт?

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

• Договорниот план на клиентот може да биде во сопственост на услугата за наплата.
• Тековниот инвентар може да биде во сопственост на база на податоци за инвентар или API за складиште.
• Дозволите за сметка може да бидат во сопственост на давател на идентитет.
• Внатрешните белешки на агентот за поддршка може да бидат во сопственост на систем за управување со случаи.
• Пресметка како данок, подобност или цени може да биде во сопственост на апликацискиот код.

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

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

Одделете го знаењето од овластувањето

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

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

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

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

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

Одржувајте ги деловните правила извршливи

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

Во PHP-апликација, тоа може да значи изложување мала сервисна граница како RefundEligibilityService. Крајната точка наменета за ВИ доставува идентификатор на нарачка и автентицираниот актер; сервисот ја вчитува тековната нарачка, ги применува правилата и враќа структуриран резултат. Моделот добива објаснување, а не бланко чек.

final class RefundEligibilityService
{
    public function evaluate(Order $order, User $actor): EligibilityResult
    {
        if (!$actor->can('refund', $order)) {
            return EligibilityResult::denied('Not authorized.');
        }

        if (!$order->isPaid() || $order->isRefunded()) {
            return EligibilityResult::denied('Order is not refundable.');
        }

        return EligibilityResult::approved();
    }
}

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

Дајте му на моделот помали, побезбедни алатки

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

Претпочитајте алатки ориентирани кон задачи, со експлицитни облици на влез и излез. Наместо „пребарај ја базата на податоци за клиенти“, обезбедете операции како:

• get_customer_summary(customer_id)
• list_open_invoices(customer_id)
• check_refund_eligibility(order_id)
• create_draft_support_reply(case_id, tone)

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

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

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

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

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

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

Docker не ги менува овие принципи. Без разлика дали услугите работат на еден хост или низ кластер, конфигурацијата треба да ги направи зависностите видливи: поставките за поврзување со база на податоци, ингеренциите за редицата, вредностите за истек на време и ингеренциите за давателот на моделот треба да се внесуваат преку конфигурација специфична за околината, наместо да се вградуваат во промптови или слики.

Направете од пребарувањето производ, а не депонија

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

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

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

Мерете го работниот тек, не само одговорот

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

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

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

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

Најдобрата деловна ВИ не се преправа дека знае сè. Таа знае каде да праша, што смее да открие, што смее да направи и кога да запре.

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