Повеќето иницијативи за ВИ пропаѓаат многу пред моделот да произведе лош одговор. Тие пропаѓаат кога никој не може јасно да одговори на поедноставно прашање: кој е сопственик на системот што го претвора деловното знаење во сигурно однесување?

„ВИ“ често се третира како функција што треба да се додаде на апликација: поврзете API, напишете промпт, додадете прозорец за разговор. Но корисен деловен систем не е промпт. Тој е производна површина со јасен сопственик, со граници на податоци, правила, набљудливост, справување со неуспеси и тим што одговара за неговите резултати.

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

Сопственоста е архитектонска одлука

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

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

Цврстиот дизајн му дава на секој слој јасна одговорност:

• Системот на евиденција е сопственик на трајните деловни факти.
• Апликациските услуги се сопственици на работните текови, авторизацијата и деловните правила.
• Слојот на ВИ го толкува одобрениот контекст и произведува ограничени излези.
• Луѓето се сопственици на одлуките што остануваат со големо влијание, двосмислени или регулирани.
• Надзорот и евалуацијата се сопственици на доказите дали системот помага.

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

Изградете цевководи за контекст, а не огромни промптови

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

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

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

final class ReplacementEligibility
{
    public function evaluate(Order $order, Warranty $warranty): array
    {
        $eligible = $order->isDelivered()
            && $warranty->isActive()
            && !$order->hasReplacement();

        return [
            'eligible' => $eligible,
            'reason' => $eligible
                ? 'Replacement is permitted.'
                : 'Replacement requirements are not met.',
        ];
    }
}

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

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

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

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

Направете ги дејствата експлицитни, типизирани и повратни

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

Изложете тесни апликациски можности како get_order, create_refund_draft или send_customer_reply. Потврдувајте го секој аргумент на серверската страна. Применувајте авторизација врз основа на автентицираниот корисник и деловната улога, никогаш врз основа на тврдења генерирани од моделот. Барајте потврда за чекори со значајни последици и направете ги неповратните операции намерни.

Корисен образец е извршување со прво создавање на нацрт:

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

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

Евалуирајте го однесувањето како продукциски софтвер

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

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

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

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

Дизајнирајте за неуспех пред да го скалирате успехот

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

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

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

Трајната предност е систем што може безбедно да учи

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

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