Заблуждение процентомании
Каждая презентация новой Text-to-SQL системы начинается с одного и того же слайда: "Мы достигли 90% точности на Spider/WikiSQL". Руководители проектов хлопают в ладоши, инвесторы улыбаются, а инженеры тихо проклинают этот театр абсурда. Потому что 90% на синтетическом датасете — это примерно как сдать экзамен по вождению на пустой парковке. В реальном мире вас ждут ямы, пешеходы и внезапный дождь.
Проблема не в том, что модели плохие. Проблема в том, что мы измеряем не то. Точность на стандартных бенчмарках стала таким же рекламным трюком, как "до 10 часов работы" у производителей ноутбуков. В лабораторных условиях. При минимальной яркости. С выключенным Wi-Fi.
Запомните раз и навсегда: 90% точности в Text-to-SQL означает, что каждый десятый запрос сломает вашу бизнес-логику. Каждый десятый отчет будет врать. Каждый десятый финансовый расчет приведет к неправильным выводам. Вам это нужно?
Что на самом деле ломается при 90%
Давайте отбросим теорию и посмотрим на реальные инциденты из production-систем. Я собрал их за последний год от коллег в крупных компаниях.
| Тип ошибки | Частота при 90% точности | Бизнес-последствия |
|---|---|---|
| Неправильный JOIN (LEFT вместо INNER) | 3-5% запросов | Потерянные строки в отчетах, двойной учет транзакций |
| Ошибки в агрегатных функциях (COUNT vs SUM) | 2-4% запросов | Неправильные KPI, искаженная аналитика |
| Проблемы с NULL и обработкой пустых значений | 4-7% запросов | Падение производительности запросов, таймауты |
| Неправильное понимание временных диапазонов | 5-8% запросов | Отчеты за неверный период, missed deadlines |
И это только вершина айсберга. Самые опасные ошибки — те, что выглядят правдоподобно. Модель генерирует SQL, который выполняется без синтаксических ошибок, возвращает данные, но эти данные неверные. Аналитик строит на них дашборд, менеджер принимает решение, компания теряет деньги. Все довольны, пока не станет слишком поздно.
Почему RAG для баз данных — это особая боль
RAG (Retrieval-Augmented Generation) должен решать проблему точности. В теории. На практике для баз данных он создает новые проблемы, которых нет в обычных чат-системах.
Схема — это не документ
Самый популярный подход: засунуть DDL базы данных в контекст модели и надеяться на лучшее. Это как дать архитектору список материалов и ожидать, что он построит дом. Без понимания нагрузок, связей, бизнес-логики.
Обычный RAG ищет похожие куски текста. Но в базе данных "похожесть" определяется внешними ключами, индексами, триггерами — вещами, которые не попадают в эмбеддинги. Модель видит "customer" и "order", но не понимает, что между ними связь один-ко-многим.
Динамический контекст против статического
В классическом RAG вы индексируете документы один раз и используете этот индекс месяцами. С базой данных все сложнее:
- Новые таблицы добавляются еженедельно
- Поля переименовываются во время миграций
- Бизнес-логика меняется быстрее, чем документация
- Разные пользователи имеют доступ к разным представлениям (views)
Ваш красивый RAG-пайплайн, который работал вчера, сегодня генерирует SQL к несуществующей таблице. Или хуже — к таблице, которую видит только админ, а запрос делает рядовой сотрудник.
Совет из практики: никогда не давайте AI-системе прямой доступ к продакшен-базе. Создайте отдельную схему с материализованными представлениями, которые обновляются по расписанию. Это защитит и данные, и психику DBA.
Метрики, которые имеют значение (а не 90%)
Забудьте про accuracy на Spider. Вот что нужно измерять в реальной системе:
Business Accuracy
Сравнивайте не SQL с ground truth, а результаты запросов. Два разных SQL могут давать одинаковый результат (и это нормально). Но одинаковый SQL на разных данных даст разный результат. Business Accuracy — это процент запросов, где AI-генерация возвращает тот же результат, что и запрос, написанный senior разработчиком.
Time to Correctness
Сколько итераций нужно пользователю, чтобы получить правильный ответ. Идеальная система дает правильный ответ с первого раза. Реальная система требует уточнений: "Нет, я имел в виду выручку за прошлый квартал, не включая возвраты". Time to Correctness — это среднее количество кругов диалога до правильного результата.
Query Safety Score
Метрика, которая оценивает риск запроса. Включает:
- Наличие потенциально опасных операций (DELETE, DROP)
- Отсутствие LIMIT в запросах к большим таблицам
- Использование полей с персональными данными
- Кросс-джойны таблиц размером гигабайты
Эту тему я подробно разбирал в статье про production-ready AI-агентов. Guardrails — это не опция, это обязательный слой безопасности.
Архитектурные антипаттерны, которые убивают доверие
За годы работы я увидел десятки неудачных реализаций. Вот топ-3 архитектурных ошибки, которые гарантированно приведут к провалу:
1. Монопромпт на всю базу
Одна большая prompt-инженерия, которая пытается охватить все таблицы разом. Работает на демо с 5 таблицами, ломается на продакшене с 500. Модель перегружена контекстом, начинает путаться, генерирует ерунду.
2. RAG без ранжирования по релевантности схемы
Поиск по эмбеддингам названий таблиц и полей — это только первый шаг. Нужно ранжировать результаты по тому, насколько они релевантны конкретному запросу. Поле "amount" есть в 20 таблицах, но в контексте "выручка за месяц" оно нужно только из таблицы "invoices".
3. Отсутствие человеческого контура (human-in-the-loop)
Полная автоматизация — это красиво на бумаге, но страшно на практике. Особенно для финансовых или медицинских запросов. Нужен механизм, где сложные или потенциально опасные запросы отправляются на проверку человеку. И этот механизм должен обучать систему на одобренных примерах.
Как двигаться от 90% к 99.9% (практически)
Вот что работает в реальных проектах, а не в исследовательских статьях:
- Создайте семантический слой — не просто схему БД, а бизнес-словарь: какие поля что означают, как считаются метрики, какие ограничения есть у данных.
- Используйте итеративное уточнение — не генерируйте финальный SQL с первого раза. Сначала создайте промежуточное представление (план запроса), покажите его пользователю, уточните детали, затем генерируйте окончательную версию.
- Добавьте валидацию на нескольких уровнях — синтаксическая проверка, проверка существования таблиц/полей, анализ производительности (explain query), сравнение с похожими историческими запросами.
- Собирайте feedback loop — каждый исправленный запрос становится тренировочным примером. Каждый отказ пользователя от результата — сигнал для дообучения.
Да, это сложнее, чем запустить готовую библиотеку из GitHub. Зато ваша система не сломает бизнес в пятницу вечером.
Будущее, которое уже наступило (но его не замечают)
Самый интересный тренд — не улучшение моделей, а изменение парадигмы взаимодействия. Text-to-SQL умирает. На смену приходит Conversational Analytics.
Пользователь не пишет "покажи мне выручку за прошлый месяц". Он говорит: "Какой был наш лучший продукт в прошлом квартале и почему?". Система сама разбивает этот вопрос на серию SQL-запросов, объединяет результаты, строит графики, формулирует выводы на естественном языке.
И последнее. Самый важный урок, который я усвоил: доверие к AI-системе для работы с данными зарабатывается не точностью, а прозрачностью. Покажите пользователю, какие таблицы вы использовали. Объясните, почему выбрали именно такие условия фильтрации. Предложите альтернативные интерпретации запроса.
Когда система говорит "я могу ошибаться, вот как я это сделала" — ей начинают доверять. Когда она молча выдает цифры с 90% точности — ее боятся. А боятся — значит, не используют.
P.S. Если ваша команда все еще гордится 90% на Spider, задайте им один вопрос: "А что насчет остальных 10%? Куда они деваются в продакшене?" Ответ вас удивит. Или напугает.
