На днях OpenAI опубликовали в своем блоге небольшую статью с достаточно громким названием «How evals drive the next chapter in AI for businesses». Я сделал ее перевод, чуть адаптировав для лучшей читабельности, очень уж бюрократический язык в оригинале.
Статью авторы называют «руководством для бизнес-лидеров». Внутри — про оценку недетерминированных систем, как к этому подходить, немного про A/B тесты и почему не стоит пытаться решить все сразу. Классический цикл фиксации метрики и постепенного ее улучшения, но с LLM спецификой.
Отношение к статье у меня немного двойственное: с одной стороны, фактически весь текст можно свести к тому, что нужен бейзлайн в виде пошаговых смысловых оценок на реальных данных (но, возможно, я избалован созданием бенчмарков и тем, что мы описанное в статье делаем регулярно) и для LLM-based это важно особенно. О том, что для улучшения чего-либо нужно всем заинтересованным придумать метрику, описать ее и последовательно улучшать — нуу, это же не откровение.
Но с другой стороны, вопрос «а как выбрать LLM под нашу задачу?» возникает регулярно, «без бейзлайна сразу в прод» — ситуация скучного вторника, а потому простое и структурированное напоминание базовых основ и фиксации процесса «evals» в виде небольшого текста может быть многим полезно.
Так что это стоит прочитать как сборник хороших практик для LLM-систем и как ответ на вопрос «А что же такое LLM evals?». Дальше — слово OpenAI.
Более миллиона компаний по всему миру используют ИИ для повышения эффективности и создания дополнительной ценности, но многие в итоге не получают ожидаемых результатов. В чем же причина?
В OpenAI мы применяем ИИ внутри компании для достижения наших амбициозных целей и один из ключевых инструментов — это оценки (evals), то есть набор методов измерения и улучшения способности ИИ соответствовать бизнес-ожиданиям.
Как и документы требований к продукту, оценки превращают размытые цели и абстрактные идеи в конкретные и явные формулировки. Постоянное и систематическое использование оценок решает проблемы пользователей, улучшает пользовательский опыт и делает продукты более надежными, снижая количество критических ошибок и защищая от негативных рисков. И, конечно, дает компаниям измеримый путь к более высокой окупаемости инвестиций (ROI).
В OpenAI наши модели — это и есть продукты, поэтому наши исследователи используют строгие оценки передовых возможностей (frontier evals) для измерения того, насколько хорошо модели работают в различных областях. Хотя передовые оценки помогают нам выпускать лучшие модели быстрее, они не могут выявить и покрыть все нюансы, возникающие в работе различных продуктов, процессов и бизнесов.
Именно поэтому внутренние команды также создали десятки контекстуальных оценок (contextual evals), разработанных для оценки производительности в рамках конкретного продукта или рабочего процесса. И именно такие оценки руководителям необходимо создавать под себя, под свою специфику и потребности.
Это руководство для руководителей бизнеса и продуктов, стремящихся научиться создавать и применять оценки AI в своих организациях. Процесс создания контекстуальных оценок, каждая из которых создана для конкретного рабочего процесса или продукта организации, еще находится в активной фазе разработки и многие определения не зафиксированы окончательно. Но эта статья предоставляет вам фреймворк мышления, который по нашему опыту неплохо работает во многих ситуациях.
Мы ожидаем, что область будет развиваться и появятся новые фреймворки под конкретные бизнес-задачи и цели. Нельзя одинаково оценивать потребительский продукт и внутренний технический сервис, всю специфику конкретного применения LLM необходимо выделять и учитывать.
Как работают оценки: Определить → Измерить → Улучшить
1. Определить: установить, что значит «отлично»
Соберите небольшую команду с полномочиями, которая сможет простыми словами описать, зачем нужна ваша система ИИ. Например: «обрабатывать входящие заявки клиентов в стиле нашего бренда: отвечать на вопросы и при необходимости назначать встречи».
Такая команда должна состоять из специалистов с технической экспертизой и экспертизой в предметной области (в данном примере нужны будут эксперты по продажам). Они должны уметь сформулировать наиболее важные результаты для измерения, описать рабочий процесс от начала до конца и выявить каждую важную точку принятия решения (decision point), с которой столкнется ваша система ИИ.
Для каждого шага в этом рабочем процессе команда должна определить, как выглядит успех и чего следует избегать. Этот процесс создаст соответствие десятков примеров входных данных (например, входящих писем) выходным данным, которые система должна производить. Полученный эталонный набор примеров (golden set: соответствие inputs и outputs) должен быть жизненным отражением того, что именно все эксперты считают хорошо проделанной работой и успешной отработкой конкретных случаев.
Не пугайтесь холодного старта (cold start) (прим. пер. — это когда совсем ничего нет, а начинать с чего-то надо) и не пытайтесь решить все сразу: это итеративный и неупорядоченный процесс. Раннее прототипирование может очень хорошо помочь, а ручной просмотр 50-100 отработанных случаев очень быстро покажет, где система дает сбои. Этот «анализ ошибок» приведет к созданию таксономии различных ошибок (и их частоты), которые и нужно будет отслеживать по мере улучшения вашей системы.
Этот процесс не является чисто техническим — он межфункциональный (cross-functional) и сосредоточен на определении бизнес-целей и желаемых процессов. Не следует перекладывать решения о проработке оценок на техническую команду — это именно консенсус всех заинтересованных в успехе команд. Ответственность за проработку правильной системы оценок лежит на всех заинтересованных сторонах.
2. Измерить: тестировать в реальных условиях
Следующий шаг — измерить. Цель измерения состоит в том, чтобы надежно выявлять конкретные примеры того, как и когда система дает сбои. Для этого создайте выделенную тестовую среду, которая близко воспроизводит реальные условия — а не просто демонстрацию или песочницу для промптов (prompt playground). Оценивайте производительность относительно вашего эталонного набора и анализа ошибок именно в тех же условиях нагрузки и на тех же граничных случаях (edge cases/corner cases), с которыми ваша система действительно столкнется.
Критерии оценки (rubrics) помогают конкретизировать, что хорошо, а что плохо в результатах работы системы. Но тут очень легко увлечься мелочами и потерять из виду главные цели, и, более того, некоторые вообще очень сложно (или невозможно) измерить. Иногда хорошо подойдут традиционные метрики, иногда их придется изобрести самому. Это долгая и часто нудная работа, требующая согласования всех причастных к работе.
Для реального тестирования берите примеры из жизни, когда это возможно, и обязательно добавляйте граничные случаи — достаточно редкие случаи и среди них особенно те, которые приводят к тяжелым последствиям, если их неправильно обработать.
Некоторые оценки можно масштабировать с помощью LLM-оценщика (LLM Grader) — модели ИИ, которая проверяет выдачу так же, как это сделал бы эксперт. Но человека все равно важно держать в процессе (human in the loop), но это должен быть именно эксперт в предметной области, который должен регулярно проверять точность LLM-оценщиков и напрямую смотреть логи поведения системы.
Оценки помогут понять, когда систему можно запускать, но только на запуске они не заканчиваются. Нужно постоянно мерить качество реальной выдачи на реальных данных. Как с любым продуктом, обратная связь от конечных пользователей — внешних или внутренних — особенно важна, и ее нужно сразу встроить в вашу оценку.
3. Улучшить: учиться на ошибках
Последний шаг — настроить процесс постоянного улучшения. Решать проблемы, которые выявила оценка, можно по-разному: дорабатывать промпты, настраивать доступ к данным, обновлять саму оценку, чтобы она лучше отражала ваши цели, и так далее. По мере того как находите новые типы ошибок, добавляйте их в анализ ошибок и исправляйте. Каждая итерация накладывается на предыдущую: новые критерии и более четкие ожидания от поведения системы помогают находить новые граничные случаи и неявные баги, от которых сложно избавиться.
Для постоянного итеративного улучшения постройте маховик данных (data flywheel). Логируйте входы, выходы и результаты; периодически делайте выборки из этих логов и автоматически направляйте неоднозначные или сложные случаи на экспертную проверку. Затем добавляйте эти экспертные суждения в свою оценку и анализ ошибок, а затем используйте их для обновления промптов, инструментов или моделей.
Благодаря этому циклу вы сможете лучше определить свои ожидания от системы, подгоните ее точнее под эти ожидания и найдете новые важные метрики. Развертывание этого процесса в широком масштабе создает большой, уникальный, контекстно-специфичный набор данных, который сложно достать и скопировать — полезная штука для создания лучшего продукта на рынке.
Хотя оценки создают системный способ улучшения вашей AI-системы, всегда могут возникать новые типы сбоев. Поэтому оценки не должны быть сделаны один раз и забыты, а обязаны развиваться как в ту же сторону, в которую развивается продукт, так и просто независимо проходить стресс-тестирование на соответствие их бизнес-целям.
Но здесь важно понимать, что evals-оценки не заменяют более традиционные A/B тесты и другие продуктовые эксперименты, они их дополняют.
Что оценки значат для руководителей бизнеса
Каждый крупный технологический сдвиг меняет операционное превосходство и конкурентное преимущество. Фреймворки вроде OKR и KPI помогли организациям сфокусироваться на «измерении того, что важно» в эпоху аналитики больших данных. Оценки — естественное продолжение этого подхода для эпохи ИИ.
Работа с вероятностными системами требует новых типов измерении и более глубокого понимания компромиссов. Руководители должны понимать природу вероятностных систем и решать, когда точность критична, когда можно быть гибче и как балансировать между скоростью и надежностью.
Оценки сложно внедрить по той же причине, по которой сложно делать крутые продукты — нужны строгость, видение и чутье. Если все сделать правильно, оценки становятся уникальными отличающими факторами. В мире, где информация доступна всем, а экспертиза демократизирована, ваше преимущество зависит от того, насколько хорошо такие системы решают задачи именно ваших пользователей. Качественные оценки создают эффект снежного кома — преимущества растут, а внутри компании накапливаются знания о том, как делать это правильно.
В своей сути оценки основаны на глубоком понимании бизнес-контекста и целей. Если вы не можете определить, что означает «отлично» для вашего случая использования, вы вряд ли этого добьетесь. В этом смысле оценки подчеркивают ключевой урок эпохи AI: управленческие навыки — это навыки AI. Четкие цели, прямая обратная связь, взвешенные решения и ясное понимание создаваемой нами ценности, стратегии и процессов по-прежнему имеют значение — возможно, даже больше, чем когда-либо.
По мере появления новых лучших практик и фреймворков мы будем делиться ими. Пока что призываем экспериментировать с оценками и находить процессы, которые работают для ваших задач. Чтобы начать, определите проблему и эксперта в предметной области, соберите небольшую команду, и если строите на нашем API, то изучите документацию платформы.
Не надейтесь на «отлично». Определите это, измерьте это и улучшайте в этом направлении.
Спасибо! Это был перевод с бюрократического английского на русский, а вот мои самонаписанные крафтовые статейки (и мой тг-канальчик Agentic World):
Порулить браузером через LLM: пишем AI-агента в стиле «browser-use» на ванильной LLM без фреймворков
Выбираем векторную БД для AI-агентов и RAG: большой обзор баз данных и поиск смысла
От LangChain к LangGraph: детально разбираемся с фреймворками и всей Lang-экосистемой
Источник: habr.com
