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

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

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

Подучувајте преку експлицитен доменски јазик

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

Разгледајте производ за управување со сметки. Рута како GET /accounts/123 може да врати корисен запис, но не мора да ѝ каже на ВИ дали сметката ги исполнува условите за надградба, е блокирана поради проверка за усогласеност или смее да покани друг корисник.

Подобриот дизајн ги изложува деловните способности и нивното образложение:

{
  "accountId": "123",
  "plan": "team",
  "canInviteMembers": false,
  "inviteRestriction": {
    "code": "SEAT_LIMIT_REACHED",
    "message": "Овој работен простор нема достапни места за членови.",
    "nextAction": "upgrade_plan"
  }
}

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

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

Дизајнирајте алатки, не само крајни точки

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

Слабата алатка бара моделот да состави нисконивоовски операции: да ажурира неколку записи, да пресмета кредит, па да испрати е-пошта. Посилната алатка ја опфаќа деловната намера: issue_subscription_credit, resend_verification_email или prepare_return_label.

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

Направете го безбедниот пат лесен пат

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

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

• Валидирајте ги овластувањето и деловните правила во самата алатка.
• Користете идемпотентност за операции што може повторно да се обидат.
• Враќајте стабилни кодови за грешка заедно со објаснувања разбирливи за луѓето.
• Запишете кој или што ја иницирал акцијата и добиената состојба.
• Барајте експлицитна потврда за неповратна работа или работа со големо влијание.

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

Направете го оперативното знаење достапно за пребарување

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

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

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

Изградете набљудливост за одлуки, не само за неуспеси

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

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

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

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

Почнете со тесна лекција со висока вредност

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

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

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

Бекендот сега е дел од разговорот

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

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