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

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

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

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

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

Што е сметка? Кога нарачката ги исполнува условите за поврат на средства? Кои полиња дефинираат квалификуван потенцијален клиент? Кој може да одобри исклучок? Што значи „достапен инвентар“ кога артиклите се резервирани, во транзит или оштетени?

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

Претставете ги важните концепти експлицитно во вашата апликација и API-ја. Дајте им стабилни имиња, типизирани полиња, сопственост, состојби на животниот циклус и документирани правила. Избегнувајте да ги принудувате потрошувачите надолу по синџирот повторно да го конструираат значењето од лабави низи, UI-ознаки или случајни конвенции во базата на податоци.

На пример, нарачката не треба да стане „подготвена за поврат на средства“ затоа што агент забележал одредена белешка во тикет. Апликацијата треба да изложи намерна евалуација на политиката, како што е getRefundEligibility(orderId), со одговор што ги вклучува и одлуката и нејзината причина.

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

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

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

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

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

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

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

Претпочитајте тесно насочени алатки наместо широк пристап до системот

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

Архитектонскиот одговор е да им се дадат на агентите тесно насочени, наменски изработени алатки, наместо општа врска со база на податоци или неограничено административно API. Алатката треба да изразува деловна операција, да ги валидира своите влезови, да спроведува авторизација и да враќа структурираn резултат.

type RefundRequest = {
  orderId: string;
  reasonCode: "duplicate" | "damaged" | "not_received";
};

type RefundResult = {
  status: "approved" | "needs_approval" | "rejected";
  reason: string;
  caseId?: string;
};

async function requestRefund(
  actorId: string,
  request: RefundRequest
): Promise<RefundResult> {
  // Authorize actor, load the order, evaluate policy,
  // record an audit event, and create a case if needed.
  return { status: "needs_approval", reason: "Manager approval required" };
}

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

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

Одделете ги предлозите од обврските

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

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

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

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

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

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

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

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

Вградете набљудливост во секој работен тек со ВИ

Традиционалните дневници на апликации одговараат на прашања како „Дали барањето не успеа?“ На работните текови со ВИ им требаат дополнителни одговори: „Кои информации ги користеше системот?“ „Кои повици на алатки ги направи?“ „Зошто запре?“ и „Дали корисник може да го репродуцира резултатот?“

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

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

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

Архитектурата е долгорочната предност на ВИ

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

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

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