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

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

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

Почнете со одлуки, не со податоци

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

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

Добро дефинираниот случај на употреба појаснува што системот мора да разбере:

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

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

Направете го доменот видлив во вашиот софтвер

ВИ не може сигурно да го изведе оперативниот модел на компанијата од збирка табели наречени orders, events и status_code. Не можат ниту новите инженери, продукт-менаџерите или идните одржувачи. Двосмислениот код е скап многу пред да пристигне ВИ-функција.

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

type DeliveryStatus =
  | "planned"
  | "dispatched"
  | "delivered"
  | "delivery_failed";

function canOfferReplacement(order: Order): boolean {
  return order.deliveryStatus === "delivery_failed"
    && order.replacementEligibility.isActive;
}

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

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

Изградете доверливи патеки до знаењето

На ВИ-функцијата ѝ треба повеќе од пристап до информации; ѝ треба начин да процени на кои информации да им верува. Третирајте го секој извор како интеграција на производ со дефиниран договор.

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

Одделете го контекстот од авторитетот

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

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

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

Дизајнирајте за неизвесност и предавања

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

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

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

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

Дајте му на системот јасна сопственост

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

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

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

Испорачувајте тесно, мерете длабоко

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

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

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

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

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

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