Оценки: от експерименти с ИИ към уверено внедряване

• Макар базовите модели да се подобриха, истинската промяна, която позволява уверено използване в реална среда, идва от систематичните практики за оценяване

• Добре проектираните оценки помагат на продуктовите мениджъри, ръководителите по управление на ИИ и техническите директори безопасно да внедряват ИИ Агенти в голям мащаб, превръщайки ИИ от изолиран експеримент в конкурентно предимство.

• Тази увереност идва от оценяването на поведението на ИИ Агентите спрямо реални потребителски заявки, гранични случаи и специфични за областта сценарии, които отразяват действителния ви бизнес контекст, а не от публичен бенчмарк, според който „този модел е най-добрият“

• Целта е тази увереност да бъде обоснована чрез измерими резултати. Успехът означава да определите "доброто" с конкретни, измерими критерии, съобразени с бизнес нуждите и допустимия за вас риск — независимо дали става дума за фактологична точност, подходящ тон, бързина или разходна ефективност.

• Като вградят оценяването в цялата система — инструментиране, регистриране, A/B тестване и защитни механизми — и балансират строгостта с ефективността, екипите могат да внедряват по-бързо и да постигнат по-голяма устойчивост.

Повечето компании приемат спокойно служителите им да експериментират с ChatGPT или Gemini. Използването на големи езикови модели в процеси или среди с висок залог обаче е много по-рядко.

Причините често са основателни: качеството е непостоянно, а рискът от халюцинации или нежелано поведение надхвърля потенциалните ползи от технологията.

През последната година този баланс между риск и полза се промени съществено. Това отчасти се дължи на по-доброто представяне на базовите модели, но до голяма степен и на все по-систематичния подход към оценяването („оценките“). Оценките дават на нас и клиентите ни увереността да внедряваме мащабни Агенти, взаимодействащи с клиенти, само за няколко седмици.

Това ръководство обяснява основните елементи на оценките и как да ги проектирате, внедрявате и използвате за реални приложения.

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

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

Най-важното е 'доброто' да включва компоненти, които действително можете да измерите. Ако успехът означава предоставяне на полезни финансови насоки, полезността трябва да се изрази чрез конкретни характеристики: фактологична точност, подходящи откази от отговорност, персонализирано структурирано анализиране и безопасни граници. След като „доброто“ бъде определено чрез измерими критерии, следващият въпрос е как ще анализирате и тълкувате резултатите. Действията въз основа на тези резултати превръщат оценяването в метод, а не просто в поредица от субективни преценки.

Всеки процес за оценяване се основава на три взаимосвързани стълба:

1. Входни данни/бенчмаркове: Представителни примери от реалния свят за общото представяне и подбрани вътрешни набори от данни за проверка на приложимостта в конкретната област.

2. Поведение на модела: Как се извиква моделът (генериране с подпомагане чрез извличане, обобщаване, структурирано извличане на информация, използване на инструменти).

3. Показатели: Как измервате и тълкувате представянето.

Входните данни трябва да представят средата, в която ще работи системата ви. Най-ценните изводи идват от реални примери: клиентските ви заявки, финансови сценарии или случаи, характерни за отрасъла. Само чрез такива тестове можете да разберете дали моделът действително улавя нужните на потребителите нюанси и удовлетворява бизнес потребността.

Поведението на модела — например как получава подкани, как се координират извличането и инструментите и как му се подава контекст — е също толкова важно, колкото самият модел. Два еднакви модела могат да се държат много различно в зависимост от начина на внедряване. Затова този слой трябва да бъде включен в проекта ви за оценяване.

Накрая идват показателите. Числата рядко разказват цялата история, но добре подбраните показатели правят поведението на системата разбираемо. Закъснението, точността, безопасността, съгласуваността, пристрастията, разходите и удовлетвореността на потребителите заедно изграждат многоизмерна картина на системата в реална среда. Майсторството е в избора на показатели, съобразени с ключовите показатели за ефективност на проекта или бизнеса и разкриващи най-важните за потребителите качества. По-простите показатели често са по-точни и по-евтини, а неправилният избор може да подведе екипите. Ето как да подходите към избора на показатели:

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

• Чатбот за обслужване на клиенти: дял на разрешените при първия контакт случаи (решен ли е проблемът без ескалация?), средно време за обработка, оценка за удовлетвореност, дял на ескалациите към служители

• Инструмент за финансови проучвания: точност на цитирането (% твърдения с коректен източник), фактологична точност спрямо еталонни данни, релевантност на извличането (открити ли са правилните документи?), съгласуваност на структуриранoто анализиране, оценена от експерти в областта

• Асистент за генериране на код: правилен синтаксис, дял на успешно преминатите тестове, брой уязвимости в сигурността, време до работещо решение

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

• Използване само на дължината на отговора като заместител на качеството (по-дълго ≠ по-добро)

• Измерване на бързината, без да се отчитат компромисите с точността

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

• Разчитане единствено на вътрешната перплексия на модела без проверка от гледна точка на потребителите

Често срещани капани при показателите:

• Противоречиви показатели: Едновременно оптимизиране за бързина и изчерпателност, без да се отчита компромисът между тях

• Прекомерно напасване към бенчмарковете: Постигане на 95% върху тестовия набор, но провал в реална среда, защото действителните потребители се държат различно

За наш клиент от силно регулирания сектор на финансовите услуги точността на решението му за дълбоко проучване беше от първостепенно значение. Създадохме набори от въпроси и отговори, изготвени от експерти, и ги съчетахме с набори, генерирани чрез инструменти. Така оценихме точността, избора на правилните инструменти и извличането на подходящата информация и получихме балансирана представа за точността и качеството на структурираното анализиране. Ключът беше измерването на няколко измерения: фактологична точност (експертна проверка), качество на извличането (прецизност/пълнота на релевантните документи) и съгласуваност на структурираното анализиране (структурирана оценка на логическия ход).

Кога да използвате големи езикови модели като оценител за нюансирано качество

Подходът с големи езикови модели като оценител използва втори ИИ модел за оценяване, като заменя човешкия преглед с мащабируема автоматизирана оценка на качеството. Подходът с големи езикови модели като оценител често се използва неправилно, когато по-прости показатели могат да осигурят нужната точност. Той може да е полезен, когато детерминистичните проверки не улавят качеството — например при семантични показатели като полезност, обоснованост, качество на структурираното анализиране, тон и тълкуване на правила, за които детерминистично оценяване не е възможно. Може да са ви нужни мащабируеми отзиви за много варианти на подкани и модели, както и ясна рубрика и схема за структурирани изходни данни. За да приложите подхода успешно, следвайте тези стъпки:

• Определете изрично измеренията на рубриката: точност, обоснованост, спазване на правилата, приложимост и тон.

• Използвайте структурирани изходни данни (JSON схема) за отговорите на оценителя.

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

• При всеки цикъл на издаване калибрирайте резултатите на оценителя спрямо образци, означени от хора.

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

• Проследявайте във времето отклонението на оценителя и дела на несъгласията.

Наборът от данни за бенчмарк е фиксирана, подбрана съвкупност от тестови примери с известни отговори, използвана за последователно оценяване на модели и справедливо сравняване на резултатите между версиите. Обикновено той включва входни данни (напр. потребителски заявки), очаквани резултати или референтни оценки и критерии/етикети за оценяване. Публичните бенчмарк тестове сравняват представянето на водещите модели и могат да послужат като първоначален ориентир при проектирането на системата и избора на подходящ модел.

За собствената си система обаче не можете да използвате тези бенчмаркове като заместител на измерването в конкретния ви бизнес контекст, защото те имат известни недостатъци:

• Замърсяване: Моделите може да са обучени върху данните от бенчмарка; оценяването върху същия набор е като изпит с готови отговори.

• Насищане: Всички водещи модели вече постигат почти максимални оценки, затова подобрението или влошаването се ограничава до няколко процентни пункта и често попада в естествената променливост на тестовите резултати.

• Тесен обхват: Данните от бенчмарка не отразяват действителните ви задачи, тъй като са щателно подбрани и изчистени. Някои дори са генерирани от големи езикови модели и не отразяват сложността и граничните случаи във вашите данни — печатни грешки, необичайни изрази и изображения с шум.

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

Пример за публичен бенчмарк, който можете да използвате: GSM8K (структурирано анализиране на задачи по математика за началния курс)

• Незадължителен по-труден набор: MATH.

Защо този бенчмарк е полезен:

• Позволява бързо да сравните кой модел е по-добър в общото математическо структурирано анализиране,

• Подходящ първи филтър, преди да инвестирате в цялостни продуктови оценки.

Защо все пак ви е нужен собствен набор от данни:

Приложението ви има изисквания, които GSM8K не проверява:

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

• Стилът на обяснение за съответната възрастова група,

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

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

Ефективната проверка зависи от създаването на специфични за приложението ви бенчмаркове за оценяване. Тези набори от данни трябва да се основават на реални взаимодействия, типични гранични случаи и правдоподобни начини за възникване на неизправности. Това може да е трудна задача при внедряването на нов продукт или процес. В повечето случаи обаче данни могат да се съберат от съществуващ продукт или възможно най-рано, дори по време на първоначалното тестване. След разработването на приложението тези бенчмаркове трябва да се развиват заедно с продукта и с времето да стават по-богати и представителни.

Връзката между специфичния за приложението бенчмарк и избора на модел е решаваща. Бенчмаркът показва не само дали дадено решение работи, но и коя комбинация от размер на модела и техники след обучението осигурява необходимото представяне при най-добра разходна ефективност. Най-съществените подобрения на предварително обучените модели („PT“ в ChatGPT) идват не от повторно обучение, а от методи за "дообработка след обучението".

Тези методи определят до каква информация има достъп моделът, как е структурирана тя и как моделът се насочва и координира по време на извеждането. Техники за дообработка след обучението като:

• Подкани за логическо мислене и динамично разпределяне на изчислителни ресурси (повече обмисляне за по-трудните задачи)

• Самосъгласуваност, при която се генерират няколко резултата и се избира най-добрият

• Изграждане и координиране на контекста, например генериране с подпомагане чрез извличане (RAG), примери с малко повторения и агентни работни процеси

• Използване на инструменти и достъп до външни знания, които позволяват на модела да действа отвъд вътрешните си параметри

• Стратегии за представяне и съхранение на знания, предназначени за ефективно извличане и структурирано анализиране на структурирани и неструктурирани данни

Макар тези техники за дообработка след обучението да могат значително да подобрят представянето на системата, те налагат и компромиси. Всеки допълнителен слой на координация, извличане или структурирано анализиране увеличава сложността на системата, времето за извеждане и оперативните разходи. Когато се прилага обмислено, правилната комбинация от техники за дообработка след обучението често позволява използването на по-малки, по-бързи и по-евтини модели, които все пак покриват изискванията за представяне. Вместо чрез увеличаване на размера на модела, желаното представяне се постига с по-добър системен дизайн.

Този баланс е специфичен за всяко приложение и трябва да се определя чрез собствените му оценки, за да се намери оптималната комбинация от техники. Те ще ви помогнат да откриете момента, в който допълнителната координация престава да носи съществени подобрения, така че екипите да изберат минималната сложност на дообработката след обучението, необходима за целевото представяне.

ИИ решението трябва да се разглежда като цялостна система: бази данни, API, потребителски интерфейси, слоеве за координация, инфраструктура за наблюдение и още много. Следователно оценяването трябва да обхваща целия технологичен стек. Наблюдавайте ключовите части на системата, за да запазите видимостта върху потенциалните проблеми и да ускорите развитието отговорно.

Наблюдението на ключовите части на системата включва:

• Инструментиране на процесите за получаване на измерими резултати.

• Регистриране на експериментите, за да виждате ефекта от всяка промяна.

• Използване на прости A/B сравнения преди внедряването на съществени промени, за да проверите за потенциални регресии.

Итерациите, основани на данни, съкращават пътя от прототип до реална употреба, без да оставят слепи зони. Регистрирането и наблюдението са важни и за разбирането на реалното използване на приложението. Ето пример за осигуряване на наблюдаемост:

• Стъпка 1: Потребителската заявка постъпва с request_id, user_segment, intent.

• Стъпка 2: Трасировката записва версията на модела, версията на подканата, извлечените документи и извикванията на инструменти.

• Стъпка 3: Оценителят с големи езикови модели оценява отговора (correctness, groundedness, policy_risk).

• Стъпка 4: Системата от правила проверява праговете.

• Стъпка 5: При нарушен праг се задейства сигнал и заявката се насочва към резервен вариант/човешки преглед.

• Стъпка 6: Неуспехът се добавя към опашката за първоначален анализ, а след това към списъка със задачи за бенчмарка.

Реалните потребители рядко се държат точно както очакват проектантите. Някои ще разберат погрешно инструкциите. Други умишлено ще търсят слаби места. Тези гранични случаи не са аномалии, а безценни сигнали. Добре внедреният процес за оценяване ги улавя, анализира и включва в бъдещите тестове. Бързи итерации без слепи зони са възможни само когато оценяването е вградено в системата, а не добавено след разработката.

Препоръчваме да вградите защитни механизми и наблюдение още от първия ден:

• Редовно проследявайте показателите и регресиите на модела чрез специфичния за приложението ви бенчмарк.

• Улавяйте и преглеждайте граничните случаи или злонамерените входни данни и ги добавяйте към набора на специфичния за приложението ви бенчмарк.

• Уверете се, че тези показатели за оценяване са съобразени с основните ви ключови показатели за ефективност.

• Редовно подлагайте на проверка набора от данни и бенчмарка, за да сте сигурни, че не пренебрегвате нови рискове и не сте повлияни от пристрастия.

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

• Поддържайте процес за човешки преглед на решенията с висок залог (правни съвети, медицински насоки, финансови трансакции).

Всяко изпълнение на бенчмарк използва изчислителни ресурси и енергия. Всеки излишен експеримент увеличава разходите. Отговорното оценяване трябва да балансира строгостта с ефективността.

Следните практически стъпки могат да предотвратят неудържимото нарастване на потреблението на енергия и разходите:

• Когато е възможно, използвайте по-малки модели: провеждайте първоначалните експерименти с по-евтини модели и преминавайте към по-големи едва след като потвърдите подхода.

• Кеширайте подканите и извикванията към API.

• Използвайте енергийно ефективно планиране (пакетна обработка, спот инстанции, гъвкав приоритет).

• Проследявайте използваните изчислителни ресурси наред с представянето.

Също така следете внимателно новите регулации за ИИ. Дори когато няма специален закон, продължават да се прилагат съществуващите рамки и необходимите мерки, като например:

Защита на данните:

• Уверете се, че наборите от данни за бенчмарковете не съдържат лични данни без надлежно съгласие

• Въведете правила за съхранение на регистрираните заявки

• Осигурете механизми за подаване на искания за изтриване на данни

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

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

• Осигурете разнообразно представителство при създаването на бенчмарка

Права на човека и прозрачност:

• Опишете ясно ограниченията на модела за потребителите

• Предоставяйте обяснения за решенията с висок залог

• Осигурете човешки надзор за критичните приложения

Оценяването не е еднократно събитие, а развиваща се система. В бързо развиваща се област предимството ви зависи от това колко бързо можете да тествате, да се учите и да се адаптирате, за да внедрявате по-ефективно модели и нови решения.

Като превърнат оценяването в основна инженерна и продуктова дейност, екипите могат да внедряват иновации по-бързо и по-безопасно. Започнете, като определите как изглежда доброто в контекста на вашето ИИ приложение, създайте платформа за оценяване и я развивайте, за да разполагате със специфичен за приложението бенчмарк, който при всяка итерация ви дава увереност, че то е готово за реална употреба.