Как я создал винный бенчмарк OenoBench для LLM с помощью агентов

В начале года я задался целью проверить, насколько хорошо современные языковые модели разбираются в винной индустрии. Меня мало интересовали общие разговоры о регионах вроде Бордо — гораздо важнее было узнать, помнят ли нейросети точные регламенты выдержки Бароло или специфические границы американских винодельческих зон. К сентябрю этот эксперимент превратился в полноценный бенчмарк OenoBench, состоящий из десятков тысяч верифицированных фактов, тысяч тестовых вопросов и результатов комплексного эвала шестнадцати передовых конфигураций. Практически всю рутинную работу выполнили автономные агенты, а мне досталась роль главного эксперта-калибровщика.

Итоговая статья по результатам исследования была направлена на конференцию NeurIPS в трек Datasets & Benchmarks. Общие расходы на API составили около 800 долларов. Ниже я подробно описываю архитектуру проекта, подводные камни при сборе данных, работу мультиагентного аудита и реальные возможности актуальных нейросетей.

Что я делал и зачем

Мой бэкграунд включает диплом WSET четвёртого уровня — это престижная британская квалификация и стандартный порог для тех, кто планирует поступать на Master of Wine. Совмещая винную экспертизу с активной работой над проектами в сфере искусственного интеллекта, я столкнулся с очевидным пробелом. Существующие бенчмарки вроде MMLU или GPQA блестяще оценивают знания физики, права или медицины, но совершенно не способны показать, отличает ли конкретная модель Бароло от Барбареско.

Сфера виноделия подходит для создания качественного бенчмарка идеально, поскольку её стандарты строго формализованы. Законодательство Франции (AOC), Италии (DOCG) и США (AVA) опирается на тысячи страниц регламентов с четкими географическими границами, разрешенными сортами лозы и лимитами урожайности. Все эти данные находятся в открытом доступе на Викиданных, сайтах профильных ведомств и в университетских базах. Моей задачей было собрать факты со ссылками, превратить их в вопросы с четырьмя вариантами ответа по шести ключевым категориям и распределить их по четырём уровням сложности.

17 скраперов из 35 ничего не скрапили

Первые скрипты для сбора данных я написал еще в феврале, и к апрелю моя база насчитывала около 27 тысяч записей. Однако проверка показала неприятную правду: почти половина скраперов не делала реальных HTTP-запросов. Во многих файлах содержались заранее захардкоженные списки фактов, которые модели сгенерировали по памяти во время написания кода. Например, данные по итальянским регионам DOCG сопровождались пометкой об источнике вроде Federdoc, хотя фактического скачивания не происходило.

Если модель черпает данные из собственной памяти, мы измеряем не реальные знания, а замкнутое информационное эхо. Мне пришлось полностью переписать 17 скраперов и починить еще 8, удалив десятки тысяч строк фейкового кода. После глубокой очистки в базе осталось чуть более 38 тысяч тщательно проверенных фактов, каждый из которых получил строгую привязку к реальному URL-адресу первоисточника.

Как абзац из Wikipedia становится фактом

Большая часть текстов из 25 работающих скраперов проходила через специальный конвейер обработки. На первом этапе длинные конструкции разбивались на атомарные предложения длиной не более 30 слов, а местоимения заменялись на конкретные наименования сущностей из контекста. Затем алгоритм классифицировал домен, проверял минимальную длину, наличие глагола и отсекал постороннюю информацию по ключевым словам.

В итоговой базе каждый факт представлял собой строгое одиночное утверждение с уникальным идентификатором источника. После финальной автоматической чистки из массива удалили дубликаты, пустые географические справки из Викиданных и обрывки предложений, обеспечив высочайшее качество исходного сырья для генерации тестов.

Генерация: пять стратегий, пять моделей и 99 % брака на входе

Чтобы превратить собранные факты в качественные тесты, я задействовал пять различных стратегий генерации и пять языковых моделей через OpenRouter. Важнейшим шагом стало внедрение в промпты инструкции, позволяющей генераторам возвращать статус пропуска, если факт сводился исключительно к упоминанию известного бренда без глубоких технических деталей. Это моментально избавило корпус от примитивных вопросов вроде «В каком регионе производят Бароло?».

Оркестратор распределял задачи по квотам, контролировал уникальность формулировок с помощью эмбеддингов и пресекал попытки моделей завышать частоту правильных ответов на определенной позиции. На этапе тестирования выяснилось, что слабые генераторы часто путают правильные ключи, поэтому для них был введен дополнительный верификатор. Уровень брака на ранних экспериментах доходил до 99%, но после оптимизации процесса конвейер стал стабильно выдавать качественные кандидаты.

Аудит: десять агентов в четырех командах

Полученные вопросы проходили жесткую многоуровневую проверку в специализированном контуре аудита. Десять агентов анализировали материалы по статическим правилам, проверяли логику с помощью независимых судейских панелей, искали утечки категорий и оценивали статистические перекосы. На начальных этапах пилотные запуски выявляли множество дефектов — от дословного цитирования источников до некорректных ключей.

Релизный аудит занял чуть больше пяти часов машинного времени и потребовал десятков тысяч вызовов API. По его итогам сотни проблемных вопросов были окончательно отсеяны, а оставшиеся перераспределены по уровням сложности, что гарантировало максимальную объективность и надежность итогового датасета.

Судьи ошибаются вместе

Использование языковых моделей в качестве судей требует постоянной калибровки и проверки через коэффициент согласия Коэна. Мои эксперименты показали, что если несколько моделей анализируют изначально дефектный вопрос со схожими логическими изъянами, они дружно приходят к одинаковому ошибочному выводу. Обычное голосование здесь не помогало, поэтому ключевую роль сыграли ранние программные фильтры-верификаторы, отсекающие брак еще до экспертной оценки судейской панели.

16 моделей, 52 256 ответов, два часа

Финальный этап тестирования включал одновременный прогон шестнадцати конфигураций через OpenRouter по тысячам валидированных вопросов. Верх лидерборда заняли передовые фронтирные модели, показавшие плотные результаты с минимальным разрывом. Интересно, что задействование тяжелых режимов рассуждения на данном типе задач не всегда давало заметный прирост точности, в то время как более компактные модели демонстрировали выдающуюся эффективность в узких специализированных доменах.

Self-preference, и где он отрицательный

Отдельный интерес представлял анализ феномена самопредпочтения — склонности моделей лучше справляться с вопросами, сгенерированными их технологическими «родственниками». У моделей Anthropic этот эффект проявился ярко и предсказуемо, тогда как решения от Google показали парадоксальный отрицательный результат. Практический вывод из этого очевиден: оценка моделей на бенчмарках, созданных ими же или близкими аналогами, неизбежно искажает объективную картину.

Что эвал рассказал про сам корпус

Ручной разбор вопросов, на которые не смогла ответить ни одна из шестнадцати моделей, выявил любопытную закономерность. Подавляющее большинство таких тестов содержали скрытые дефекты: двусмысленные формулировки, некорректные ключи или несколько верных вариантов одновременно. Это доказало, что хвост самых сложных заданий в сгенерированных датасетах по умолчанию обогащен ошибками сборки.

Сколько это стоило

Совокупные затраты на генерацию, аудиторские пилоты, финальные прогоны эвала и дополнительные проверки составили около 800 долларов США. Проект занял около семи месяцев вечерней работы и потребовал написания сотен коммитов, продемонстрировав высокую эффективность связки автоматизированных агентов под управлением человека.

Что забрать, если вы не про вино

Описанный конвейер легко адаптируется под любую другую сложную предметную область. Главные выводы просты: закладывайте право модели ничего не генерировать при отсутствии глубоких фактов, не полагайтесь слепо на независимость судейских панелей, тщательно проверяйте провенанс данных на уровне исходного кода и помните, что самые сложные вопросы в автоматических бенчмарках почти всегда требуют дополнительной ручной редактуры.