Дослідницька група з Університету Іллінойсу в Урбані-Шампейні виявила, що понад половина анотацій у широко використовуваному бенчмарку BIRD Text-to-SQL є помилковими, що ставить під сумнів значення показників точності, на які покладаються багато розробників.

Чому цей бенчмарк важливий

BIRD є стандартом де-факто для вимірювання того, наскільки добре модель може перетворити запитання природною мовою на SQL-запит. Наукові статті, описи продуктів та тести при прийомі на роботу посилаються на показники BIRD. Якщо «еталонні» (gold) SQL-інструкції, що визначають правильність, мають помилки, модель, яка пише кращий запит, може бути покарана, тоді як модель, що копіює помильну еталонну відповідь, може отримати винагороду.

Як було виявлено рівень помилок

Команда UIUC дослідила 238 випадків невдач із розділу BIRD-dev. Замість того, щоб вгадувати, чому кожна відповідь моделі була позначена як неправильна, вони вручну тегували кожну розбіжність між згенерованим моделлю SQL та еталонним зразком. Їхній аудит показав, що 52,8 % випадків містять помилку анотації — неправильний SQL, невідповідність схеми або навіть некоректне запитання природною мовою.

Один паттерн склав 19 % позначених помилок: модель використовувала DISTINCT, тоді як еталонний запит — ні. Уявіть користувача, який запитує кількість пацієнтів із аномальними результатами лабораторних аналізів. Еталонна відповідь підраховує рядки за допомогою COUNT(ID). Якщо один пацієнт має п'ять аномальних результатів, еталонний запит покаже п'ять замість одного. COUNT(DISTINCT ID) моделі правильно підраховує кожного пацієнта один раз. У таких випадках бенчмарк фіксує помилку моделі, хоча відповідь моделі краще відповідає задуманій семантиці.

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

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

Дослідники продемонстрували протилежний сценарій. Проаналізувавши як запити моделі, так і еталонні запити, вони виявили сім випадків, коли модель помилково об'єднала дві окремі колонки в одну. У цих випадках еталонний SQL був правильним. Зосередившись лише на цих справжніх помилках за допомогою вдосконаленого промпту, вони підвищили продуктивність моделі без штучного завищення показника бенчмарку.

Що ці результати означають для зацікавлених сторін

  • Дослідники: твердження у публікаціях, засновані на показниках BIRD, потребують застереження щодо якості анотацій. Порівняння в різних статтях можуть відображати різну толерантність до шуму в бенчмарку, а не справжній методологічний прогрес.
  • Продуктові команди: покладання на BIRD як на єдину метрику готовності до релізу створює ризик випуску моделей, які навчилися відтворювати помилкові запити. Тестування на власних схемах стає необхідним.
  • Куратори бенчмарків: високий рівень помилок свідчить про те, що систематичний перегляд давно назрілий. Очищення еталонного набору або надання вторинного «перевіреного» розділу могло б відновити довіру.

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

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

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

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

Підсумок

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