Почему 90% точности преобразования текста в SQL являются бесполезными

Вечные перспективы аналитики самообслуживания

Делиться

Я работаю в сфере аналитики более 20 лет. Тогда это называлось не «аналитика», а «бизнес-аналитика» или даже «системы поддержки принятия решений». Термины меняются: от хранилищ данных до больших данных, от больших данных до систем анализа данных на основе искусственного интеллекта, а теперь, с появлением ИИ, суть и вечное обещание самообслуживаемой аналитики остаются прежними: извлечение истины из данных для расширения возможностей пользователей без зависимости от кого-либо из команды, работающей с данными. ИИ без участия человека? Это звучит спорно.

С появлением больших языковых моделей (LLM) одним из наиболее интересных вариантов их применения является разработка диалоговых интерфейсов для взаимодействия с базами данных (преобразование текста в SQL). Потенциал здесь огромен, и это обещает демократизировать доступ к данным в масштабах всей организации.

Однако для данного конкретного случая решение должно быть бинарным. Оно либо работает, либо нет.

К сожалению, точности в 80% или даже 90% недостаточно. Предоставлять конечным пользователям аналитическое приложение на основе ИИ, которое выдает иллюзорные таблицы или неправильно интерпретирует фильтры, — это не шутка. Нельзя идти на компромисс с точностью, потому что это немедленно подрывает доверие. А что происходит, когда система теряет доверие? Ее перестают использовать. Уровень внедрения снизится, не говоря уже о катастрофическом риске принятия бизнес-решений на основе неверных данных.

Сложность трубопровода RAG

Я начал свои исследования по этой теме более полутора лет назад, и быстро стало ясно, что создание надежного приложения Text-to-SQL RAG (Retrieval-Augmented Generation) — задача нетривиальная. Вам потребуется множество компонентов в вашем конвейере, работающих в идеальной гармонии:

• Классификатор намерений для определения цели вопроса.
• Векторная база данных для хранения дополнительного контекста (например, бизнес-определений), необходимого языковым моделям.
• Модель встраивания для векторизации этих дополнительных знаний.
• Механизм извлечения сохраненных данных.
• Доступ к базе данных.
• Возможность генерировать SQL-запросы на специфическом диалекте базы данных.
• А также способность оценивать результаты.

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

BigQuery: пример интеграции нативного ИИ.

Управление этим сложным процессом часто требует интеграции нескольких платформ. Недавно меня впечатлило, как BigQuery интегрировал аналитику и генеративный ИИ непосредственно в свою платформу.

У вас есть возможность работать с SQL-запросами в среде разработки BigQuery IDE и сразу же использовать Gen AI, не переходя на другую платформу или продукт. Например: вы можете выполнить запрос к базе данных, и полученные результаты могут быть немедленно отправлены в Gemini (или через Vertex вы также можете добавить другие модели). Вы можете использовать Gemini для классификации намерений, создания эмбеддингов и их хранения в векторной базе данных BigQuery, выполнения семантического поиска и генерации SQL-запросов.

И все это на одной платформе, без хлопот, связанных с управлением множеством подписок.

Конечно, как и во всем в жизни, у этого есть свои недостатки.

Один из главных недостатков BigQuery заключается в том, что это может быть не самая дешевая база данных, и я слышал истории о стартапах, где один неверный запрос может опустошить вашу кредитную карту. Со мной такого не случалось, но я понимаю, как это может произойти. Еще один недостаток — это полная зависимость от Google. Возможно, это и не так уж плохо; так же, как мы все зависимы от Gmail. Возможно, в будущем ИИ станет товаром широкого потребления, как сейчас электронная почта.

Ещё одним недостатком является отсутствие детальной прослеживаемости стоимости токенов и своего рода «имитация LLM» для разработки; на этапе разработки вам вряд ли понадобится использовать настоящий дорогостоящий LLM.

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

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

https://github.com/garyzava/bigq-ethereum-rag

Недостающий элемент: Тщательная оценка

Теперь вернёмся к фреймворкам для оценки результатов. Такие платформы, как BigQuery, упрощают архитектуру, но они автоматически не решают проблему точности. Я вижу множество решений, но большинству из них не хватает надёжных возможностей для оценки.

Если мы примем тот факт, что преобразование текста в SQL должно быть бинарным (правильным или неправильным), нам понадобятся стратегии оценки, отражающие сложную реальность корпоративных данных, а не безупречную среду академических или демонстрационных наборов данных.

Оценка системы преобразования текста в SQL крайне сложна из-за декларативного характера SQL и сложности схемы вашей базы данных. Содержит ли она тысячи таблиц? Хорошо ли документированы эти таблицы? Вероятно, нет. Едины ли соглашения об именовании для всех таблиц? Два запроса могут выглядеть совершенно по-разному синтаксически (например, разный порядок соединений, псевдонимы или использование CTE), но при этом давать идентичные результаты.

Для того чтобы действительно оценить производительность вашего RAG-приложения как на этапе разработки, так и в производственной среде, необходимо использовать правильные метрики.

Показатели, которые имеют значение

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

1. Переход к точности выполнения (EX): Ранние тесты производительности основывались на точном совпадении (EM), которое сравнивало предсказанную строку SQL с эталонной. Это было серьезной ошибкой, поскольку оно наказывало за допустимые синтаксические вариации. Современный стандарт — точность выполнения (EX). Этот показатель выполняет как предсказанный SQL, так и «золотой» (эталонный) SQL по отношению к фактической базе данных и сравнивает возвращаемые наборы результатов. Это позволяет корректно проверять запросы независимо от того, как они написаны.
2. Целенаправленная оценка: В корпоративной среде запрос может возвращать дополнительные, несущественные столбцы (например, столбец ID, используемый для объединения). Строгая проверка точности выполнения может расценить это как ошибку. «Целенаправленная оценка на основе выполнения» позволяет проводить более детальное сравнение, проверяя правильность целевых столбцов и значений, при этом проявляя большую снисходительность к избыточным данным или порядку строк.
3. Метрика «Soft-F1»: Чтобы смягчить бинарную природу точности выполнения (когда одна неправильная ячейка приводит к провалу всего теста), все чаще используется метрика Soft-F1. Эта метрика частично учитывается путем вычисления перекрытия между прогнозируемыми и эталонными результатами. Если запрос возвращает 99 из 100 правильных строк, Soft-F1 отражает высокую производительность, тогда как EX вернет 0. Это крайне важно для отладки.
4. LLM-в роли судьи: Иногда выполнение невозможно (например, отсутствуют конфиденциальные данные, возникают ошибки среды). В таких случаях продвинутому LLM может быть предложено сравнить семантическую логику прогнозируемого SQL с эталонным SQL. Хотя это менее объективно, чем выполнение, это имеет высокую корреляцию с человеческим суждением.

«Паук 2.0»: проверка реальности в «Энтерпрайзе»

В настоящее время существует три замечательных фреймворка для оценки производительности: Spider 2.0, BIRD (BIg Bench for LaRge-scale Database Grounded Text-to-SQL) и SynSQL (на основе синтетических данных). Однако отрасль страдает от ложного чувства безопасности, созданного устаревшими бенчмарками. В течение многих лет отрасль полагалась на Spider 1.0. Он был ориентирован на небольшие, чистые базы данных SQLite (в среднем менее 10 таблиц). Модели достигали точности более 90%, что заставляло многих считать, что проблема «решена».

Наиболее рекомендуемая мной модель, которая включает в себя современные показатели и действительно проверяет готовность предприятия, — это Spider 2.0 .

Spider 2.0 (выпущенный в рамках ICLR 2025) представляет собой сдвиг парадигмы, призванный устранить этот «разрыв в реальности» путем внедрения сложностей, которые приводят к сбоям в работе программ LLM в реальных условиях:

1. Масштабность: Корпоративные схемы огромны. Базы данных Spider 2.0 в среднем содержат 812 столбцов, а некоторые превышают 3000. Такой масштаб часто превышает контекстные ограничения LLM, вынуждая модели использовать стратегии «связывания схем» (извлечения данных) только для идентификации соответствующих таблиц перед генерацией SQL-запросов.
2. Разнообразие диалектов: В реальных компаниях используются Snowflake, BigQuery и T-SQL, а не только SQLite. Spider 2.0 обеспечивает разнообразие диалектов, требуя от моделей освоения определенного синтаксиса (например, обработки вложенных данных JSON с помощью UNNEST или FLATTEN).
3. Внешние знания: Бизнес-логика (например, определение «показателя оттока клиентов») находится в документации или кодовых базах проектов (например, DBT), а не в схеме. Spider 2.0 имитирует это, предоставляя внешние файлы (Markdown, YAML), которые модель должна прочитать, чтобы обосновать свои рассуждения.
4. Рабочий процесс Agentic: Что особенно важно, Spider 2.0 моделирует рабочий процесс современного инженера данных. Он выходит за рамки статического преобразования, оценивая способность модели исследовать файловую систему, читать документацию, взаимодействовать с работающими экземплярами баз данных и итеративно отлаживать ошибки.

Разница в сложности разительна. Модели, которые доминируют в Spider 1.0, демонстрируют снижение вероятности успеха до 10-20% в полной версии Spider 2.0, что подчеркивает недостатки существующих моделей LLM при столкновении со сложностью реального мира.

Заключение: Двоичная шкала для корпоративных данных

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

Достижение 90% точности может быть интересно с академической точки зрения, но на практике это бесполезно. Критерий бинарен: либо работает, либо подрывает доверие.

Поскольку такие платформы, как BigQuery, упрощают интеграцию ИИ и данных, крайне важно одновременно внедрять сложные методологии оценки и строгие бенчмарки, такие как Spider 2.0. Только тестируя приложения на основе сложных корпоративных данных, мы сможем разработать достаточно надежные приложения для преобразования текста в SQL, на которые можно будет положиться в бизнесе.

До новых встреч! Надеюсь, эта тема показалась вам такой же увлекательной, как и мне.

Дополнительная литература

Spider 2.0: Оценка языковых моделей в реальных корпоративных рабочих процессах преобразования текста в SQL. Авторы: Фанъюй Лэй, Цзисюань Чен, Юйсяо Е и др. Опубликовано: arXiv (ноябрь 2024 г.), принято к публикации на ICLR 2025 (устный доклад). Ссылка: https://arxiv.org/abs/2411.07763

Безусловно, как и в случае с любыми современными технологиями искусственного интеллекта, этот разговор не должен на этом заканчиваться. Я с удовольствием выслушаю ваши мнения и точку зрения на сайте www.gyza.org.

Источник: towardsdatascience.com