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

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

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

Почнете од задачата, не од моделот

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

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

Пред да изберете модел или да изградите потсетник, дефинирајте четири работи:

• Корисник: кој го добива резултатот и каква стручност има?
• Одлука: што ќе направи поинаку откако ќе го види?
• Докази: кои извори се доволно авторитетни за да го поткрепат резултатот?
• Граница: што системот мора да одбие, да ескалира или да му го остави на човек?

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

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

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

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

Одделете ги инструкциите, фактите и дозволите

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

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

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

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

Дајте им на агентите алатки со тесни договори

ВИ-агентот станува покорисен кога може да пребарува системи, да создава записи или да активира работни текови. Тој исто така станува поопасен. Решението не е да се избегнуваат алатките; туку да се дизајнираат исто толку внимателно како јавните API-ја.

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

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

{
  "action": "create_refund_request",
  "order_id": "ORD-1042",
  "amount": 49.00,
  "reason": "duplicate_charge",
  "requires_approval": true
}

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

Дизајнирајте за неизвесност и неуспех

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

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

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

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

Оценувајте го работниот тек, не само одговорот

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

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

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

Човечкиот надзор треба да биде намерен

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

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

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

Подучувајте го системот преку архитектурата

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

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