Исследовательская группа из Иллинойсского университета в Урбане-Шампейне обнаружила, что более половины аннотаций в широко используемом бенчмарке BIRD Text-to-SQL ошибочны, что ставит под сомнение значимость показателей точности, на которые полагается множество разработчиков.

Почему этот бенчмарк важен

BIRD является стандартом де-факто для измерения того, насколько хорошо модель может преобразовать вопрос на естественном языке в SQL-запрос. В научных статьях, описаниях продуктов и тестах при приеме на работу приводятся показатели BIRD. Если «эталонные» («золотые») SQL-запросы, определяющие правильность, содержат ошибки, модель, пишущая лучший запрос, может быть наказана, в то время как модель, копирующая ошибочный эталонный ответ, может получить вознаграждение.

Как был выявлен уровень ошибок

Команда UIUC изучила 238 случаев ошибок из набора BIRD-dev. Вместо того чтобы гадать, почему вывод каждой модели был помечен как неверный, они вручную пометили каждое расхождение между SQL-запросом, сгенерированным моделью, и эталонным ответом. Их аудит показал, что 52,8 % случаев содержат ошибку аннотации — неверный SQL, несоответствие схемы или даже некорректно сформулированный вопрос на естественном языке.

Один паттерн составил 19 % отмеченных ошибок: модель использовала DISTINCT, в то время как в эталонном запросе он отсутствовал. Представьте, что пользователь спрашивает количество пациентов с аномальными результатами анализов. Эталонный ответ подсчитывает строки с помощью COUNT(ID). Если у одного пациента пять аномальных анализов, эталонный запрос сообщит о пяти вместо одного. COUNT(DISTINCT ID) модели правильно подсчитает каждого пациента один раз. В таких случаях бенчмарк фиксирует ошибку модели, хотя ответ модели лучше соответствует предполагаемой семантике.

Влияние на разработку моделей в реальном мире

Разработчики часто реагируют на низкие показатели BIRD, подправляя промпты, добавляя ограничения вроде «не используй DISTINCT» или переобучая модели на данных бенчмарка. Такие корректировки могут повысить отчетный балл, создавая иллюзию прогресса. Анализ UIUC показывает, что это «улучшение» может быть простым переобучением под неверные ключи ответов, что потенциально снижает производительность на реальных базах данных, где требуется исправленная логика.

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

Что эти результаты значат для заинтересованных сторон

  • Исследователи: Заявления в публикациях, основанные на показателях BIRD, должны сопровождаться оговоркой о качестве аннотаций. Сравнения в разных статьях могут отражать разную толерантность к шуму в бенчмарке, а не реальный методологический прогресс.
  • Продуктовые команды: Использование BIRD в качестве единственной метрики готовности к релизу несет риск выпуска моделей, которые научились воспроизводить ошибочные запросы. Тестирование на проприетарных схемах в реальных условиях становится обязательным.
  • Кураторы бенчмарков: Высокий уровень ошибок указывает на необходимость систематической проверки. Очистка эталонного набора или предоставление вторичного «проверенного» набора данных могли бы восстановить доверие.

Практический рабочий процесс аудита

Команда UIUC предлагает легкий процесс, который можно применить к любому бенчмарку Text-to-SQL:

  1. Разберите (Parse) как сгенерированные модель, так и эталонные SQL-запросы в абстрактные синтаксические деревья.
  2. Сопоставьте (Align) структуры, чтобы выявить различия в выбранных столбцах, фильтрах, соединениях (joins) и агрегатных функциях.
  3. Пометьте (Tag) каждое различие (например, лишний столбец, отсутствующий фильтр, неверная агрегация).
  4. Обобщите (Summarize) метки в гистограмме, чтобы выявить доминирующие категории ошибок.
  5. Проверьте (Validate) эталонный запрос для каждой высокочастотной метки, прежде чем использовать его в качестве цели для промпт-инжиниринга.

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

Итог

Бенчмарк, который ошибочно классифицирует более половины своих примеров, не может служить надежным мерилом. Исследование UIUC показывает, что многие «ошибки», отмеченные BIRD, на самом деле являются успехами модели, в то время как подлинные ошибки скрываются за правильными эталонными ответами. Аудит эталонного набора, совершенствование конвейеров оценки и отношение к показателям бенчмарка как к одной из составляющих более широкой стратегии валидации — это единственные способы гарантировать, что улучшения на бумаге трансформируются в надежность в реальном мире.