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

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

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

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

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

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

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

• Одлука: Што треба некој порано да одлучи или истражи?
• Сигнали: Кои одобрени системи ги обезбедуваат потребните докази?
• Публика: Кој може да го потврди резултатот и да преземе дејство?
• Дејство: Кој безбеден следен чекор произлегува од увидот?
• Мерење: Како тимот ќе знае дека системот е корисен?

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

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

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

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

Одделете го набљудувањето од интервенцијата

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

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

agent:
  allowed_reads:
    - service_metrics
    - deployment_records
    - approved_runbooks
  allowed_writes:
    - draft_incident_note
  requires_human_approval:
    - create_ticket
    - modify_configuration
    - deploy_service
  stop_conditions:
    - missing_evidence
    - conflicting_sources
    - permission_error

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

Дизајнирајте излези за проверка

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

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

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

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

Направете го прибирањето контекст намерно

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

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

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

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

Градете за неуспех пред да градите за обем

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

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

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

Мерете го квалитетот на работниот тек

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

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

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

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

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

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

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