Исследование Databricks показывает, что создание лучших ИИ-судей — это не просто техническая задача, это проблема людей
Интеллект ИИ-моделей — это вовсе не то, что мешает их внедрению на уровне предприятий. Проблема заключается в неспособности изначально определить и измерить качество.
Именно здесь всё более важную роль начинают играть ИИ-судьи (AI judges). В контексте оценки ИИ «судья» — это ИИ-система, которая оценивает результаты работы другой ИИ-системы.
Judge Builder — это фреймворк от Databricks для создания таких судей, впервые представленный в рамках технологии компании Agent Bricks в начале этого года. С момента своего первоначального запуска фреймворк значительно эволюционировал в ответ на отзывы пользователей и практические внедрения.
Ранние версии были сосредоточены на технической реализации, однако отзывы клиентов показали, что настоящим узким местом является отсутствие согласованности на уровне организации. Теперь Databricks предлагает структурированный процесс воркшопов, который помогает командам справиться с тремя основными проблемами: достижением консенсуса среди стейкхолдеров по критериям качества, сбором экспертных знаний у ограниченного круга профильных специалистов и развертыванием систем оценки в масштабе всей компании.
«Интеллект модели обычно не является узким местом, модели очень умны, — рассказал Джонатан Франкл (Jonathan Frankle), главный научный сотрудник Databricks по искусственному интеллекту, в эксклюзивном интервью VentureBeat. — Скорее, дело в том, как заставить модели делать то, что нам нужно, и как узнать, действительно ли они сделали то, что мы хотели».
«Проблема уробороса» в оценке ИИ
Judge Builder решает то, что Паллави Коппол (Pallavi Koppol), научный сотрудник Databricks, руководившая разработкой, называет «проблемой уробороса». Уроборос — это древний символ, изображающий змею, которая поедает собственный хвост.
Использование ИИ-систем для оценки других ИИ-систем создает проблему циклиточной валидации.
«Вы хотите, чтобы судья проверил, хороша ли ваша система, хороша ли ваша ИИ-система, но при этом ваш судья — это тоже ИИ-система, — пояснила Коппол. — И теперь вы задаетесь вопросом: а как мне узнать, что этот судья хорош?»
Решением является измерение «расстояния до эталонной истины человеческого эксперта» в качестве основной функции оценки. Минимизируя разрыв между тем, как результаты оценивает ИИ-судья, и тем, как их оценили бы профильные эксперты, организации могут доверять таким судьям как масштабируемым прокси-оценкам человеческого труда.
Этот подход кардинально отличается от традиционных систем защитных барьеров (guardrails) или оценок по одному показателю. Вместо того чтобы просто выяснять, прошел ли результат работы ИИ общую проверку на качество, Judge Builder формирует высокоспецифичные критерии оценки, адаптированные под предметную область и бизнес-требования каждой конкретной организации.
Техническая реализация также выделяет этот инструмент. Judge Builder интегрирован с MLflow от Databricks и инструментами оптимизации промптов, а также может работать с любой базовой моделью. Команды могут осуществлять версионирование своих судей, отслеживать производительность с течением времени и развертывать нескольких судей одновременно по разным критериям качества.
Уроки на практике: создание судей, которые действительно работают
Опыт работы Databricks с корпоративными клиентами позволил выделить три важнейших урока, актуальных для всех, кто создает ИИ-судей.
Урок первый: ваши эксперты согласны друг с другом далеко не так сильно, как вам кажется. Когда качество субъективно, организации обнаруживают, что даже их собственные эксперты расходятся в мнениях о том, что считать приемлемым результатом. Ответ службы поддержки может быть фактологически верным, но иметь неподходящий тон. Финансовый отчет может быть исчерпывающим, но слишком техническим для целевой аудитории.
«Один из главных выводов всего этого процесса заключается в том, что все проблемы в конечном итоге сводятся к проблемам взаимодействия между людьми, — говорит Франкл. — Самое трудное — вытащить идею из головы человека и перенести ее во что-то явное. И ситуация усложняется тем, что компании состоят не из одного мозга, а из множества».
Решением является пакетная аннотация с проверкой межэкспертной согласованности. Команды аннотируют примеры в небольших группах, а затем измеряют показатели согласия перед тем, как двигаться дальше. Это позволяет выявить несоответствия на ранней стадии. В одном из случаев три эксперта поставили оценки 1, 5 и «нейтрально» одному и тому же результату, прежде чем обсуждение показало, что они по-разному интерпретируют критерии оценки.
Компании, использующие этот подход, достигают показателей межэкспертной согласованности на уровне до 0,6 по сравнению с типичными 0,3 от внешних служб аннотирования. Более высокий уровень согласия напрямую транслируется в лучшую производительность судьи, поскольку обучающие данные содержат меньше шума.
Урок второй: разбивайте размытые критерии на конкретных судей. Вместо одного судьи, оценивающего, является ли ответ «релевантным, фактологичным и лаконичным», создайте трех отдельных судьев. Каждый из них нацелен на конкретный аспект качества. Такая детализация имеет решающее значение, поскольку низкая оценка «общего качества» лишь показывает, что что-то не так, но не говорит о том, что именно нужно исправить.
Наилучшие результаты достигаются при сочетании требований сверху вниз (например, регуляторных ограничений и приоритетов стейкхолдеров) с обнаружением паттернов сбоев снизу вверх. Один из клиентов создал судью для проверки корректности (сверху вниз), но в ходе анализа данных обнаружил, что корректные ответы почти всегда ссылались на два первых результата поиска. Это наблюдение легло в основу нового, удобного для продакшна судьи, который мог выступать прокси для проверки корректности без необходимости использования эталонных размеченных данных.
Урок третий: вам требуется меньше примеров, чем вы думаете. Команды могут создавать надежных судей всего на основе 20–30 тщательно отобранных примеров. Ключ к успеху — выбор пограничных случаев (edge cases), выявляющих разногласия, а не очевидных примеров, с которыми все согласны.
«Мы способны реализовать этот процесс с некоторыми командами всего за три часа, так что создание хорошего судьи на самом деле не занимает много времени», — отметила Коппол.
Результаты в продакшене: от пилотных проектов до семизначных инвестиций
Франкл выделил три метрики, которые Databricks использует для измерения успеха Judge Builder: хотят ли клиенты использовать его снова, увеличивают ли они расходы на ИИ и продвигаются ли дальше в своем пути внедрения ИИ.
Что касается первой метрики, один из клиентов создал более десятка судей после своего первого воркшопа. «Этот клиент создал более десятка судей после того, как мы впервые провели их через этот процесс строгим путем с использованием данного фреймворка, — рассказал Франкл. — Они действительно увлеклись судьями и теперь измеряют абсолютно всё».
В отношении второй метрики бизнес-эффект очевиден. «Есть несколько клиентов, которые прошли через этот воркшоп и стали тратить на генеративный ИИ в Databricks семизначные суммы, чего раньше не было», — говорит Франкл.
Третья метрика раскрывает стратегическую ценность Judge Builder. Клиенты, которые раньше опасались использовать передовые методы, такие как обучение с подкреплением (reinforcement learning), теперь чувствуют себя уверенно при их развертывании, потому что могут измерить, действительно ли произошли улучшения.
«Есть клиенты, которые занялись очень сложными вещами после появления этих судей, хотя раньше они этого избегали, — поделился Франкл. — Они перешли от простого промпт-инжиниринга к обучению с подкреплением вместе с нами. Зачем тратить деньги и энергию на обучение с подкреплением, если вы не знаете, принесло ли это реальную пользу?»
Что предприятиям делать дальше
Команды, успешно переводящие ИИ из стадии пилота в продакшн, рассматривают судей не как разовые артефакты, а как развивающиеся активы, которые растут вместе с их системами.
Databricks рекомендует три практических шага. Во-первых, сосредоточьтесь на наиболее важных судьях, выделив одно критическое регуляторное требование и один наблюдаемый тип сбоев. Они станут вашим первоначальным портфелем судей.
Во-вторых, создайте легковесные рабочие процессы с участием профильных экспертов. Несколько часов на анализ 20–30 пограничных случаев обеспечивают достаточную калибровку для большинства судей. Используйте пакетную аннотацию и проверку межэкспертной согласованности для очистки данных от шума.
В-третьих, запланируйте регулярные проверки судей с использованием производственных данных. По мере эволюции вашей системы будут возникать новые типы сбоев. Ваш портфель судей должен развиваться вместе с ними.
«Судья — это способ оценки модели, это также способ создания защитных барьеров, это способ получения метрики для оптимизации промптов, а также метрика, на основе которой можно проводить обучение с подкреплением, — подытожил Франкл. — Как только у вас появляется судья, который эмпирически отражает ваши человеческие представления о качестве и к которому можно обращаться сколько угодно раз, вы можете использовать его 10 000 разными способами для измерения или улучшения ваших агентов».
