Евалуации: од експерименти со ВИ до сигурна продукциска примена

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

• Добро осмислените евалуации им помагаат на продуктовите менаџери, раководителите за управување со ВИ и техничките директори безбедно и во голем обем да применуваат ВИ-агенти, претворајќи ја ВИ од изолирана играчка во конкурентска предност.

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

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

• Со вградување на евалуацијата низ целиот систем (инструментација, евидентирање, A/B-тестирање и заштитни механизми) и со балансирање на темелноста и ефикасноста, тимовите ќе постигнат побрзо и постабилно пуштање во употреба.

На повеќето компании им е прифатливо нивните вработени да експериментираат со ChatGPT или Gemini. Но примената на големи јазични модели (LLM) во процеси или средини со висок ризик е многу поретка.

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

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

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

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

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

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

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

1. Влезни податоци/репери: репрезентативни примери од реалниот свет за општите перформанси и внимателно избрани интерни податочни множества за тестирање на применливоста во доменот.

2. Однесување на моделот: како се повикува моделот (генерирање дополнето со пребарување, сумирање, структурирано пронаоѓање информации и употреба на алатки).

3. Метрики: како ги мерите и толкувате перформансите.

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

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

На крајот, тука се метриките. Бројките ретко ја кажуваат целата приказна, но добро избраните метрики го прават однесувањето на системот разбирливо. Латентноста, точноста, безбедноста, кохерентноста, пристрасноста, трошокот и задоволството на корисниците заедно создаваат повеќедимензионална слика за продукцискиот систем. Умешноста е во изборот на метрики усогласени со клучните показатели за успешност на проектот или бизнисот, кои ги истакнуваат својствата најважни за корисниците. Поедноставните метрики често се попрецизни и поевтини, додека лошиот избор може да ги доведе тимовите во заблуда. Еве како да размислувате за изборот на метрики:

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

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

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

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

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

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

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

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

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

Вообичаени замки кај метриките што треба да се избегнуваат:

• Спротивставени метрики: истовремено оптимизирање на брзината и сеопфатноста без да се признае компромисот

• Прекумерно приспособување кон реперите: постигнување 95 % на тест-множеството, но неуспех во продукција бидејќи вистинските корисници се однесуваат поинаку

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

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

При користење голем јазичен модел (LLM) како оценувач, втор модел со ВИ ја врши евалуацијата, заменувајќи го човечкиот преглед со скалабилно, автоматизирано оценување на квалитетот. Голем јазичен модел (LLM) како оценувач често се користи непотребно кога поедноставни метрики можат да ја обезбедат потребната точност. Може да биде корисен кога детерминистичките проверки не можат да го опфатат квалитетот, на пример кога метриката е семантичка (корисност, заснованост врз извори, квалитет на расудувањето, тон или толкување на политики) и не е можно детерминистичко оценување. Можеби ќе ви треба скалабилна повратна информација за многу варијанти на промптот и моделот, како и јасни критериуми и шема за структуриран резултат. За ова да функционира добро, следете ги овие чекори:

• Јасно дефинирајте ги димензиите на критериумите: точност, заснованост врз извори, усогласеност со политики, применливост и тон.

• Користете структурирани резултати (JSON-шема) за одговорите на оценувачот.

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

• Во секој циклус на издавање калибрирајте ги резултатите на оценувачот според примероци означени од луѓе.

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

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

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

Сепак, за сопствениот систем не можете да се потпрете на овие репери како показател за перформансите во вашиот деловен контекст, бидејќи имаат познати недостатоци:

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

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

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

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

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

• Незадолжително потешко множество: MATH.

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

• Брзо споредување кој модел е подобар во општо математичко расудување,

• Добар прв филтер пред да вложите во целосни евалуации на производот.

Зошто сепак ви треба сопствено податочно множество:

Вашата апликација има барања што GSM8K не ги тестира:

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

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

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

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

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

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

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

• Задавање промпт за синџир на размислување и динамичко распределување пресметковни ресурси (повеќе размислување за потешки проблеми)

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

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

• Употреба на алатки и пристап до надворешно знаење, со што моделот може да дејствува надвор од своите внатрешни параметри

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

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

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

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

Следењето на клучните делови на системот подразбира:

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

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

• Користење едноставни A/B-споредби пред примената на поголеми промени за да се проверат можни регресии.

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

• Чекор 1: Корисничкото барање пристигнува со request_id, user_segment и intent.

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

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

• Чекор 4: Механизмот со правила ги проверува праговите.

• Чекор 5: Ако прагот е прекршен, се активира предупредување + пренасочување кон резервно решение/човечки преглед.

• Чекор 6: Неуспехот се додава во редицата за тријажа, а потоа во списокот за дополнување на реперот.

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

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

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

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

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

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

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

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

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

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

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

• Кеширајте ги промптовите и повиците кон API.

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

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

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

Заштита на податоците:

• Погрижете се податочните множества за реперите да не содржат лични податоци без соодветна согласност

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

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

Еднаквост и пристрасност:

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

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

Човекови права и транспарентност:

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

• Обезбедете објаснувања за одлуките со висок ризик

• Овозможете човечки надзор за критичните апликации

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

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