Евалуације: од AI експеримената до поуздане продукције

• Иако су основни модели напредовали, прави помак који омогућава поуздану примену у продукцији потиче од дисциплинованог приступа евалуацији

• Добро осмишљене евалуације помажу менаџерима производа, руководиоцима за управљање вештачком интелигенцијом и техничким директорима да безбедно и масовно примењују AI агенте, претварајући AI из изоловане играчке у конкурентску предност.

• То поверење потиче од процене понашања AI агента на основу стварних корисничких упита, граничних случајева и сценарија специфичних за домен који одражавају ваш пословни контекст, а не од јавног референтног теста који тврди: „овај модел је најбољи“

• Циљ је да се то поверење оправда мерљивим резултатима. Успех подразумева конкретно и мерљиво дефинисање онога што је "добро", у складу с вашим пословним потребама и толеранцијом на ризик — било да је реч о чињеничној тачности, одговарајућем тону, брзини или исплативости.

• Уграђивањем евалуације у цео систем (инструментација, евидентирање, A/B тестирање, заштитне мере) и успостављањем равнотеже између темељности и ефикасности, тимови ће брже и поузданије примењивати решења.

Већина предузећа нема ништа против тога да се њихови запослени поигравају производима ChatGPT или Gemini. Међутим, велики језички модели (LLM) ређе се користе у токовима рада и окружењима у којима су последице грешака озбиљне.

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

Однос ризика и користи значајно се променио током протекле године. Иако се то делом може приписати бољим перформансама основних модела, велики део напретка потиче од све дисциплинованијег приступа евалуацији (или „евалуацијама“). Евалуације нама и нашим клијентима дају сигурност да за свега неколико недеља применимо агенте великих размера намењене клијентима.

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

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

У основи сваке стратегије евалуације налази се једноставно питање: Како изгледа оно што је „добро“? Одговор треба да буде конкретан. За једну организацију „добро“ може значити чињеничну тачност у строгим границама, док друга може дати предност брзини, исплативости или препознатљивом тону комуникације. На ову дефиницију утичу сва ограничења у којима послујете, од тога који се подаци смеју користити до важећих регулаторних обавеза.

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

Сваки процес евалуације почива на три међусобно повезана стуба:

1. Улази/референтни тестови: репрезентативни примери из стварног света за опште перформансе и пажљиво одабрани интерни скупови података за проверу применљивости у домену.

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

3. Метрике: начин мерења и тумачења перформанси.

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

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

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

Примери доброг избора метрика:

• Чет-бот за корисничку подршку: стопа решавања при првом контакту (да ли је проблем корисника решен без ескалације?), просечно време обраде, оцена задовољства корисника, стопа ескалације људским агентима

• Алат за финансијско истраживање: тачност навода (% тврдњи с одговарајућим изворима), чињенична прецизност проверена према референтним подацима, релевантност претраге (да ли су пронађени прави документи?), кохерентност резоновања коју оцењују стручњаци за домен

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

Примери лошег избора метрика:

• Коришћење само дужине одговора као замене за квалитет (дуже ≠ боље)

• Мерење брзине без узимања у обзир компромиса у погледу тачности

• Праћење оцена поузданости модела без провере у односу на стварну исправност

• Ослањање искључиво на интерну перплексију модела без валидације усмерене на кориснике

Уобичајене замке при избору метрика:

• Сукобљене метрике: истовремена оптимизација брзине и свеобухватности без уважавања компромиса

• Прекомерно прилагођавање референтним тестовима: постизање 95% на тестном скупу уз неуспех у продукцији јер се стварни корисници понашају другачије

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

Када користити велики језички модел (LLM) као судију за процену нијанси квалитета

Приступ „велики језички модел (LLM) као судија“ користи други AI модел као оцењивача, замењујући људски преглед скалабилним, аутоматизованим оцењивањем квалитета. Приступ „велики језички модел (LLM) као судија“ често се непотребно користи када једноставније метрике могу пружити потребну тачност. Може бити користан када детерминистичке провере не могу да обухвате квалитет, на пример када је метрика семантичка (корисност, заснованост на изворима, квалитет резоновања, тон, тумачење правила), па детерминистичко оцењивање није могуће. Можда ће вам бити потребне скалабилне повратне информације за бројне варијанте инструкција и модела, као и јасно дефинисан критеријум и шема структурираног излаза. Да би овај приступ дао резултате, следите ове кораке:

• Изричито дефинишите димензије критеријума: исправност, заснованост на изворима, усклађеност с правилима, употребљивост и тон.

• За одговоре судије користите структуриране излазе (JSON шему).

• Бележите и бинарне оцене пролазности и дијагностички текст за анализу неуспеха.

• У сваком циклусу издања калибришите излазе судије према узорцима које су означили људи.

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

• Током времена пратите одступање судије и стопу неслагања.

Скуп података за референтно тестирање јесте фиксни, пажљиво одабрани скуп тестних примера с познатим одговорима, који служи за доследну евалуацију модела и правично поређење резултата различитих верзија. Обично садржи улазе (нпр. корисничке упите), очекиване излазе или референтне оцене и критеријуме/ознаке за оцењивање. Јавни референтни тестови користе се за поређење перформанси најсавременијих модела и могу послужити као почетна смерница при пројектовању система и избору модела који би могао бити добар кандидат.

Ипак, за сопствени систем не можете да се ослоните на те тестове као показатељ перформанси у свом пословном контексту јер они имају познате недостатке:

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

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

• Узак обухват: Подаци референтног теста не одражавају ваше стварне задатке јер су веома пажљиво одабрани и очишћени. Неки су чак генерисани помоћу великих језичких модела (LLM), па не одражавају сложеност и граничне случајеве у вашим подацима (словне грешке, необичне формулације, слике са шумом).

Ученик тражи од апликације помоћ у решавању текстуалних задатака.

Пример јавног референтног теста који можете користити: GSM8K (математичко резоновање за основну школу)

• Опциони тежи скуп: MATH.

Зашто је овај референтни тест користан:

• Омогућава брзо поређење модела у општем математичком резоновању,

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

Зашто вам је и даље потребан сопствени скуп података:

Ваша апликација има захтеве које GSM8K не тестира:

• Формулације и редослед тема у вашем наставном програму,

• Стил објашњавања прилагођен узрасту,

• Поступање с двосмисленим ученичким питањима или питањима препуним словних грешака,

• Правила поступања (нпр. када дати наговештај, а када цео одговор).

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

Веза између референтног теста специфичног за апликацију и избора модела од пресудног је значаја. Ваш референтни тест не показује само да ли решење ради, већ и која комбинација величине модела и техника накнадне обуке најисплативије пружа потребне перформансе. Највећа побољшања претходно обучених модела („PT“ у називу ChatGPT) не потичу од поновне обуке, већ од метода "накнадне обуке".

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

• Инструкције за начин резоновања и динамичку расподелу рачунарских ресурса (више размишљања за теже проблеме)

• Самодоследност, при којој се генерише више излаза и бира најбољи

• Изградњу и оркестрацију контекста, као што су генерисање проширено претрагом (RAG), примери са малим бројем уноса и токови рада засновани на агентима

• Употребу алата и приступ спољном знању, који моделу омогућавају да делује изван својих интерних параметара

• Стратегије представљања и складиштења знања, осмишљене за ефикасно проналажење и резоновање над структурираним и неструктурираним подацима

Иако ове технике накнадне обуке могу значајно побољшати перформансе система, оне доносе и одређене компромисе. Сваки додатни слој оркестрације, претраге или резоновања повећава сложеност система, време закључивања и оперативне трошкове. Међутим, када се промишљено примени, права комбинација техника накнадне обуке често омогућава употребу мањих, бржих и јефтинијих модела уз испуњавање захтева за перформансе. Уместо повећањем величине модела, перформансе се постижу бољим пројектовањем система.

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

AI решење треба посматрати као целовит систем: базе података, API-је, корисничке интерфејсе, слојеве оркестрације, инфраструктуру за надзор и друго. Евалуација зато мора обухватити читав технолошки стек. Треба да надгледате кључне делове система како бисте задржали увид у могуће проблеме и одговорно убрзали развој.

Надгледање кључних делова система подразумева:

• Инструментирање процеса ради добијања мерљивих резултата.

• Евидентирање експеримената како бисте видели ефекат сваке измене.

• Коришћење једноставних A/B поређења пре примене већих измена ради провере могућих регресија.

Итерације засноване на подацима скраћују пут од прототипа до продукције, без слепих тачака. Евидентирање и надзор важни су и за разумевање стварне употребе апликације. Ево примера како се обезбеђује опсервабилност:

• Корак 1: Кориснички захтев стиже са request_id, user_segment и intent.

• Корак 2: Траг бележи верзију модела, верзију инструкције, преузете документе и позиве алата.

• Корак 3: Велики језички модел (LLM) као судија оцењује одговор (исправност, заснованост на изворима, policy_risk).

• Корак 4: Механизам правила процењује граничне вредности.

• Корак 5: Ако је гранична вредност прекршена, активира се упозорење и захтев усмерава на резервно решење/људски преглед.

• Корак 6: Неуспех се додаје у ред за тријажу, а затим у листу задатака за референтни тест.

Стварни корисници ретко се понашају баш онако како пројектанти очекују. Неки ће погрешно разумети упутства. Други ће намерно испитивати слабе тачке. Ти гранични случајеви нису аномалије, већ непроцењиви сигнали. Добро примењен процес евалуације бележи их, анализира и укључује у будућа тестирања. Брзе итерације без слепих тачака могуће су само када је евалуација уграђена у систем, а не накнадно додата после развоја.

Препоручујемо да заштитне мере и надзор уградите од првог дана:

• Редовно пратите метрике и регресије модела помоћу референтног теста специфичног за вашу апликацију.

• Бележите и прегледајте граничне случајеве или злонамерне улазе (и додајте их у скуп података референтног теста специфичног за апликацију).

• Ускладите ове метрике евалуације са својим кључним показатељима учинка.

• Редовно преиспитујте скуп података и референтни тест како бисте били сигурни да не занемарујете нове ризике нити подлежете пристрасностима.

• Уведите аутоматска упозорења за погоршање метрика (нпр. ако тачност падне испод 85%, покрените преглед).

• Задржите људски преглед одлука с озбиљним последицама (правни савети, медицинске смернице, финансијске трансакције).

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

Неколико практичних корака може спречити неконтролисан раст потрошње енергије и трошкова:

• Користите мање моделе кад год је могуће: почетне експерименте обављајте на јефтинијим моделима, а капацитет повећавајте тек након валидације приступа.

• Кеширајте инструкције и API позиве.

• Планирајте извршавање уз уважавање потрошње енергије (пакетна обрада, спот инстанце, флексибилни приоритет).

• Пратите потрошњу рачунарских ресурса упоредо с перформансама.

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

Заштита података:

• Проверите да скупови података референтних тестова не садрже податке о личности (PII) без одговарајуће сагласности

• Уведите правила чувања података за евидентиране упите

• Обезбедите механизме за подношење захтева за брисање података

Равноправност и пристрасност:

• Тестирајте перформансе у различитим демографским групама

• При изради референтног теста обезбедите разноврсну заступљеност

Људска права и транспарентност:

• Корисницима јасно документујте ограничења модела

• Пружите објашњења за одлуке с озбиљним последицама

• Омогућите људски надзор над критичним применама

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

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