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

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

Почнете со работата, не со моделот

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

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

Пред да интегрирате модел, дефинирајте:

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

Ова е вообичаена инженерска дисциплина. Системите со ВИ едноставно ја прават неизвесноста повидлива.

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

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

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

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

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

Структурираните излези се особено вредни тука. Наместо да барате „резиме“, побарајте полиња како impact, suspected_components, evidence, unknowns и recommended_next_check. Вашата апликација може да отфрли неправилно форматирани резултати, јасно да ја прикаже неизвесноста и да избегне претворање на течен пасус во непрегледан извор на вистина.

Употребата на алатки бара заштитни механизми, не оптимизам

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

Добрата интеграција на алатки следи познати безбедносни принципи:

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

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

Задржете ги дејствата повратни кога е можно

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

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

Контекстот е површина на производот

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

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

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

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

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

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

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

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

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

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

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