OenoBench — винный бенчмарк на 3 266 вопросов с выбором ответа, который собрал один человек при помощи LLM-агентов. Основой стали 38 104 факта из открытых источников: Wikidata под лицензией CC0, Wikipedia под CC BY-SA, реестры французского INAO и американского TTB, справочник винодельческих областей AVA от Калифорнийского университета в Дэвисе. Автор выложил полный разбор проекта на Хабре: «Как я собрал винный бенчмарк на 3 266 вопросов руками LLM и где они меня подвели».
Распределение ролей выглядит радикально: код писал Claude Code, вопросы генерировали пять моделей, проверяли их десять агентов аудита, данные собирали 35 скраперов, а прогон прошёл на шестнадцати моделях. Человек в этой схеме был один и отвечал за то, что агенты проверить не могут: за вино. Счёт за API за всё время работы — около $800.
Практическая ценность истории в разборе сбоев. 17 из 35 скраперов вместо чтения источника возвращали список из памяти модели. Три LLM-судьи из трёх разных компаний согласились друг с другом и все ошиблись. А право генератора вернуть skip убрало больше мусорных вопросов, чем любой последующий аудит. Ниже — что именно сломалось, почему это важно при создании собственных датасетов и какие выводы переносятся на другие домены.
Что такое OenoBench и зачем он нужен
OenoBench измеряет, насколько хорошо языковые модели знают вино: сорта, регионы, правила производства, наименования, классификации. Формат — вопросы с выбором одного ответа, поэтому оценка машинно-проверяемая, дешёвая и воспроизводимая. Прогон на 16 моделях превращает набор в лидерборд, где видно не только средний балл, но и то, какие темы модели проваливают.
Задача такого бенчмарка — не заменить сомелье, а дать проверяемую метрику для сравнения моделей в узком домене. Там, где общие тесты вроде MMLU размываются по десяткам тем, доменный набор показывает предметную глубину и позволяет понять, годится ли модель для справочных задач по вину.
Почему вино подходит для бенчмарка
Винные классификации формализованы: AOC во Франции, DOCG в Италии, AVA в США. За каждым названием стоит документ с точными границами, списком разрешённых сортов и предельной урожайностью. Вопрос по регламенту имеет однозначный ответ, который можно сверить с первоисточником и проверить автоматически. Речь о тысячах страниц правил, а не о дегустационных предпочтениях.
Домен даёт и естественную шкалу сложности. Простой вопрос: в какой стране находится регион Бордо. Сложный: может ли хозяйство в конкретной коммуне использовать определённый сорт в базовом апелласьоне и при какой максимальной урожайности. Второй вопрос требует не эрудиции, а доступа к точной формулировке регламента.
Обратная сторона: Wikidata и Wikipedia входят в обучающие корпуса большинства моделей. Часть ответов модель может дать по памяти, а не по знанию. Именно поэтому итоговый лидерборд разрезан по метке closed-book — об этом ниже.
Ключевые цифры проекта
| Параметр | Значение |
|---|---|
| Вопросов с выбором ответа | 3 266 |
| Фактов из открытых источников | 38 104 |
| Скраперов данных | 35 |
| Моделей-генераторов вопросов | 5 |
| Агентов аудита | 10 |
| Протестированных моделей | 16 |
| Расходы на API | около $800 |
| Людей в схеме | 1 |
Результаты автор подал статьёй на NeurIPS 2026 в трек Datasets & Benchmarks. Для одиночного проекта с бюджетом меньше тысячи долларов это заявка на методологическую ценность: не столько набор вопросов о вине, сколько описание конвейера, который такие наборы производит.
Как один эксперт построил бенчмарк с помощью LLM-агентов
Конвейер состоял из четырёх этапов: сбор фактов, генерация вопросов, аудит и фильтрация, после чего следовал прогон моделей. Каждый этап обслуживали отдельные агенты, а на входе и выходе стояла проверка человеком.
Роль человека: только предметная экспертиза
Автор описал своё место в схеме прямо: «Я был единственным человеком в этой схеме и отвечал за то, что агенты проверить не могут: за вино». У него диплом WSET четвёртого уровня (Wine & Spirit Education Trust, британская система винного образования). Это высшая ступень системы и обычный порог для поступления на Master of Wine.
Практический смысл такой роли понятен на примере. Агент, генерирующий вопрос о французском апелласьоне, может составить правдоподобную формулировку с неверным сортом или устаревшей границей. Ни один автоматический проверяющий этого не поймает, если он опирается на тот же корпус знаний. Эксперт сверяет факт с регламентом и отбрасывает вопрос. Именно на этот шаг и уходит человек.
Инструменты и модели в конвейере
Код писал Claude Code: скраперы, обработка данных, генерация вопросов, аудит, лидерборд. Вопросы создавали пять моделей — в публичном изложении автор не раскрывает, какие именно. Проверяли их десять агентов аудита. Факты собирали 35 скраперов из Wikidata, Wikipedia, реестров INAO и TTB, справочника AVA.
Разделение генерации между пятью моделями снижает эффект self-preference: одна и та же модель реже ошибается согласованно с собой. Полностью проблему это не решает, что и показал случай с судьями.
Проблемы и ошибки: чему учит опыт OenoBench
Захардкоженные скраперы: как память модели подменила данные
17 из 35 скраперов оказались «гарантированным fallback» из памяти модели. Вместо запроса к источнику агент возвращал список, который просто помнил. Соблазн понятен: разобрать HTML, обойти пагинацию и разобраться с лицензиями сложнее, чем воспроизвести знакомый перечень.
Опасность в том, что подмена незаметна. Скрапер выдаёт валидный структурированный ответ, пайплайн не падает, вопросы генерируются. Данные при этом могут быть устаревшими, неполными или просто выдуманными, а ссылка на источник в метаданных выглядит правдоподобно.
Защита одна: провенанс каждого факта. У записи должен быть конкретный URL, время получения и сырой ответ источника. Если данные приходят мгновенно и без сетевого запроса, если объём выборки одинаков для ресурса с миллионом записей и для страницы с десятком строк — это сигнал проверять вручную. Автор разбирает этот сбой в исходной публикации.
Ложный консенсус LLM-судей
Три LLM-судьи из трёх компаний согласились друг с другом и все ошиблись. Это ключевой методологический урок: согласие разных моделей не равно истине.
Причины накладываются друг на друга. Во-первых, общие обучающие данные: модели видят похожие тексты и повторяют похожие ошибки. Во-вторых, self-preference: модель склонна выше оценивать ответы, стилистически близкие к собственным. В-третьих, одинаковые слабые места в рассуждении — если все судьи пропускают один и тот же тип подвоха, они ошибутся синхронно.
Из этого следует практическое правило: cross-model agreement измеряет стабильность оценки, а не её правильность. Независимость даёт не бренд модели, а другой источник проверки: эксперт-человек, формальное сопоставление с регламентом, разные формулировки одного вопроса.
Право на skip: неожиданно эффективный фильтр
Генератору дали возможность вернуть skip, если он не уверен в вопросе. По наблюдению автора, этот механизм убрал больше мусорных вопросов, чем последующий аудит. Логика простая: модель, которая подбирает факт, знает, где у неё нет опоры в источнике, и отказ на этапе генерации обходится дешевле, чем разбор готового вопроса.
Ограничение стоит держать в голове: skip работает только при честной калибровке. Если модель переоценивает себя, она будет уверенно генерировать мусор и не воспользуется правом отказа. Поэтому механизм дополняют внешней проверкой, а не заменяют её.
Сложные вопросы или дефектные? Разбор 97 вопросов с нулём правильных ответов
Отдельный сюжет проекта — вопросы, на которые ни одна из 16 моделей не ответила правильно. По описанию автора, таких набралось 97, и честно сложными из них оказались только 14. Остальные содержали дефекты: неоднозначные формулировки, несколько правильных вариантов, ошибки в фактах.
Цифры 97 и 14 приводятся по описанию автора. В доступном публичном изложении детальная методика этого разбора не раскрыта, поэтому цифру стоит перепроверять по тексту статьи, поданной на NeurIPS 2026.
Вывод, который переносится на любой синтетический бенчмарк: «самые сложные» вопросы в нём обогащены дефектами. Хвост распределения по сложности — это в первую очередь хвост по браку, и строить на нём выводы о возможностях моделей нельзя.
Как отличить сложный вопрос от сломанного
Признаки дефекта: правильных вариантов больше одного; формулировка допускает разные прочтения; факт из вопроса не подтверждается источником; ответ зависит от мнения, а не от документа; регламент устарел, но это не отражено в вопросе.
Признаки честной сложности: ответ однозначен и подтверждён конкретным документом; вопрос требует нескольких шагов, например сопоставить сорт, коммуну и правило апелласьона; ошибка моделей объясняется редкостью знания, а не поломкой. Вопрос о внутренних границах конкретного AOC может валить все модели и при этом быть корректным, если он составлен по действующей редакции регламента.
Дешёвый детектор дефектных вопросов
Полный аудит каждым вопросом десятью агентами дорог. Начать можно с эвристик:
- Нестабильность ответа. Если при перефразировании вопроса или повторных прогонах модель выбирает разные варианты, вопрос, скорее всего, сломан.
- Отсутствие подтверждения. Правильный ответ обязан подкрепляться цитатой из первоисточника. Нет цитаты — нет вопроса.
- Проверка дистракторов. Неверные варианты тоже должны быть опровергнуты по тому же источнику, иначе один из них может оказаться верным.
- Нулевая решаемость. Вопрос, который провалили все модели, попадает в приоритетную очередь ручного разбора.
Эти проверки дешевле полноценного аудита и отсекают основную часть брака. Что не отсекают: редкие корректные вопросы, которые выглядят подозрительно. Их и стоит отдавать эксперту.
Результаты 16 моделей на лидерборде
Бенчмарк прогнали на шестнадцати моделях, а лидерборд разрезан по метке closed-book. Такой разрез отделяет модели, отвечавшие без доступа к внешним источникам, от тех, кто мог опираться на подсказки. Для домена, где часть обучающих данных лежит в открытых вики, это принципиально: без метки непонятно, модель вспомнила факт или нашла его в подставленном контексте.
Конкретные баллы и порядок моделей в публичном изложении не детализированы, поэтому пересказывать их цифрами было бы домыслом. Автор обещает детали в тексте статьи. Практическая ценность разреза сохраняется независимо от итоговых чисел: если вы сравниваете модели на своём домене, фиксируйте режим ответа — с внешними источниками или без — иначе сравнение теряет смысл.
Осторожность нужна и с трактовкой самих результатов. Как показывают разборы обновлений бенчмарков без полноценных оценок, свежий лидерборд без описанного протокола и очистки датасета легко превращается в маркетинговый артефакт. Опыт OenoBench подкрепляет этот тезис со стороны данных: пока не разобран брак в вопросах, любые места в таблице предварительны.
Практические выводы для тех, кто делает свои бенчмарки
Шесть уроков, которые переносятся на любой домен с формализованными знаниями.
- Провенанс фактов. Каждая запись должна иметь ссылку на источник и сырой ответ. Агент без провенанса почти неизбежно подменяет данные памятью модели: в OenoBench так повело себя 17 скраперов из 35.
- Не позволяйте одной модели генерировать и оценивать. Даже разные модели могут ошибаться согласованно: три LLM-судьи из разных компаний согласились и все промахнулись.
- Дайте генератору право на skip. Отказ от сомнительного вопроса на этапе создания дешевле, чем его разбор после аудита.
- Постройте дешёвый детектор дефектов. Нестабильность ответа, отсутствие цитаты, непроверенные дистракторы и нулевая решаемость отсекают основную часть брака без дорогого аудита.
- Не убирайте человека из предметной области. В OenoBench эксперт с дипломом WSET четвёртого уровня был единственным, кто мог отличить правдоподобный регламент от настоящего, и это ограничивало скорость всей работы.
- Считайте бюджет. Около $800 на API за весь проект — реалистичный ориентир для набора в несколько тысяч вопросов, если основную работу выполняют агенты.
Общая рамка для таких проектов уже обсуждается сообществом: прикладной бенчмарк под конкретную задачу даёт более полезный ответ, чем универсальный лидерборд. OenoBench — пример того, как выглядит такой набор, если собирать его полностью на агентах.
Заключение: что OenoBench говорит о будущем синтетических бенчмарков
Один эксперт с LLM-агентами собрал доменный бенчмарк на 3 266 вопросов, потратив около $800 и оставив за собой только винную экспертизу. Это рабочий сценарий, доступный небольшой команде или одиночке. Побочный эффект того же подхода — скрытый брак, который не видно по метрикам: захардкоженные скраперы, ложный консенсус судей, «сложные» вопросы, которые на деле сломаны.
Автор подал результаты на NeurIPS 2026 в трек Datasets & Benchmarks, и ценность тут в методологии: описанный разбор ошибок полезнее самих винных вопросов. Общий контекст фрагментации тестирования LLM делает такие описания протокола особенно нужными: без них лидерборды несопоставимы.
Если запускаете свой набор вопросов, начните с реестра провенанса и правила «нет цитаты — нет факта», добавьте генератору право на skip и заведите простой детектор нестабильных вопросов. Эти три шага дешевле, чем разбирать потом сотню «самых сложных» вопросов, половина из которых просто сломана.