Агент прайшоў адзін тэст — гэта яшчэ не надзейнасць: запускайце серыі

Адзін паспяховы тэст ШІ-агента не даказвае яго надзейнасці: Anthropic адзначае, што вынікі мадэлі змяняюцца паміж спробамі, і рэкамендуе паўтараць запуск задачы. Для ацэнкі перад вытворчым выпускам патрэбны набор задач з выразнымі крытэрыямі поспеху, некалькі спроб для кожнай і праверка таго, што агент зрабіў.

Правярайце канчатковы вынік разам з трасай: правільны адказ можа суправаджацца недапушчальным выклікам інструмента, а няўдалы — выявіць праблему ў самім тэсце. Параўноўвайце новы запуск з папярэдняй версіяй агента на аднолькавых задачах. Вытворчыя збоі ператварайце ў кейсы, якія аўтаматычна запускаюцца перад наступным выпускам.

Збярыце задачы, якія можна ацаніць

Пачніце, напрыклад, з 20 кейсаў, якія каманда ўжо правярае ўручную. Гэта прапанаваны аб’ём для першага набору, а не норма надзейнасці. Уключыце звычайныя запыты, складаныя шматкрокавыя сцэнарыі і сітуацыі, дзе агент павінен спыніцца, удакладніць умовы або не выконваць дзеянне.

Для кожнага кейса зафіксуйце ўваходны запыт, даступныя інструменты, пачатковы стан асяроддзя і назіральны крытэрый поспеху. Калі агент змяняе запіс у базе, правярайце стан запісу пасля працы, а не толькі ўпэўненую фразу ў адказе. Калі да мэты вядуць розныя дапушчальныя шляхі, апішыце прымальны вынік і забароненыя дзеянні замест абавязковай паслядоўнасці кожнага кроку.

Захоўвайце эталоннае рашэнне для кожнай задачы: яно паказвае, што задачу можна выканаць у зададзеным асяроддзі, а ацэншчык прымае слушны вынік. Дайце двум спецыялістам незалежна вызначыць, ці пройдзены складаны кейс. Калі яны разыходзяцца, удакладніце ўмову або крытэрый да серыі запускаў, інакш неадназначнасць задання сказіць вынікі.

Паўтарайце спробы ў аднолькавых умовах

Кожную задачу запускайце некалькі разоў з той самай канфігурацыяй мадэлі, інструкцый і інструментаў. Перад кожнай спробай аднаўляйце пачатковы стан: файлы, кэш і змены базы, пакінутыя ранейшым праходам, могуць падказаць адказ або выклікаць збой. Калі некалькі спроб церпяць няўдачу праз адно абмежаванне інфраструктуры, іх нельга лічыць незалежнымі сведчаннямі памылкі агента.

Паказвайце вынік асобна для кожнай задачы: колькі спроб прайшло і колькі правалілася. Агульная доля поспеху можа схаваць нестабільны крытычны кейс, калі простых задач у наборы больш. Парушэнні забаронаў улічвайце асобна, нават калі канчатковы адказ выглядае правільным.

Колькасць паўтораў выбірайце паводле цаны збою і бюджэту праверкі. Кароткая серыя можа не выявіць рэдкую памылку, а поўны поспех у ёй не гарантуе таго ж на новых запытах. Яе карысць у тым, што зменлівасць становіцца бачнай, а версіі агента можна параўнаць у супастаўных умовах.

Ацэньвайце вынік і дзеянні асобна

Першым наладзьце аўтаматычны ацэншчык канчатковага выніку. Для структураванага адказу ён можа праверыць схему і абавязковыя палі; для змяненняў у сістэме — патрэбны стан даных; для кода — выкананне адпаведных тэстаў. Такі ацэншчык павінен абапірацца на назіральны вынік, а не на заяву агента пра ўласны поспех.

Умоўны прыклад: агент атрымаў заданне забраніраваць рэйс і адказаў, што браніраванне завершана. Поспех вызначае наяўнасць брані ў тэставай базе. Калі перад дзеяннем патрабавалася згода карыстальніка, асобная праверка павінна выявіць заўчаснае браніраванне, нават калі запіс у базе з’явіўся.

Для якасцей, якія цяжка апісаць праграмным правілам, задайце ацэншчыку на аснове мадэлі вузкія крытэрыі з прыкметамі праходу і правалу. Напрыклад, ён можа правяраць, ці грунтуецца тлумачэнне на атрыманых даных. Яго высновы перыядычна звярайце з ацэнкамі людзей; калі даных бракуе, дазвольце адказ «невядома», каб няпэўнасць не ператваралася ў памылковы поспех.

Адкрывайце трасу, калі важны шлях да выніку

Кіраўніцтва OpenAI раіць пачынаць адладку агентнага працэсу з трас, якія фіксуюць выклікі мадэлі і інструментаў, ахоўныя механізмы і перадачы паміж агентамі. Гэта дазваляе ўбачыць, дзе менавіта ўзнік збой: пры выбары інструмента, у яго адказе або пасля перадачы задачы.

Для трасы задавайце праверкі толькі там, дзе шлях істотны для поспеху ці бяспекі. Можна ацаніць, ці быў выкліканы патрэбны інструмент з дапушчальнымі параметрамі, ці не адбылося забароненае дзеянне і ці спрацаваў ахоўны механізм. Дакладнае супадзенне ўсіх крокаў патрабуйце толькі тады, калі іншыя паслядоўнасці сапраўды недапушчальныя.

Пры правале адкрывайце трасу канкрэтнай спробы разам з рашэннем ацэншчыка. Яна дапамагае адрозніць памылку агента ад сітуацыі, калі тэст адхіліў слушны варыянт. Пасля змены інструкцыі, маршрутызацыі або апісання інструмента такі разбор паказвае прычыну збою, якую не відаць з аднаго фінальнага адказу.

Замацуйце парог выпуску і папаўняйце рэгрэсійны набор

Захоўвайце версіі задач і ацэншчыкаў. Перад выпускам запускайце новага і папярэдняга агента на адным наборы, параўноўваючы поспех па задачах, крытычныя парушэнні, час і выдаткі на выкананне. Парог вызначайце загадзя: абавязковыя кейсы могуць патрабаваць праходу кожнай спробы, а для астатніх можна задаць дапушчальную долю няўдач. Так паляпшэнне агульнага паказчыка не схавае рэгрэс у важнай задачы.

Дакументацыя LangSmith адрознівае праверкі на падрыхтаваным наборы перад разгортваннем ад назірання за вытворчымі запускамі і прапануе браць выяўленыя збоі як кандыдатаў у новыя кейсы. Для такога кейса захавайце ўваходныя ўмовы, прыбярыце адчувальныя даныя, узнавіце збой у кантраляваным асяроддзі і запішыце крытэрый, па якім выпраўленне можна аўтаматычна праверыць.

Пасля выпраўлення запускайце ўвесь рэгрэсійны набор: змяненне, якое выратавала адзін сцэнарый, можа сапсаваць іншы. Калі няўдалы тэст аказаўся двухсэнсоўным або ацэншчык адхіліў слушнае рашэнне, выпраўце сам кейс і зафіксуйце прычыну змены. Гэта захоўвае набор карысным для рашэння аб наступным выпуску.

Чытайце таксама:

• DigitalOcean Managed Agents: цыклічны агент можа спустошыць баланс
• ШІ закранае кожную чацвёртую працу — але гэта яшчэ не прагноз звальнення
• OpenAI запусціла Dots: агент працуе, нават калі чат закрыты