Интеллектуальная маршрутизация запросов для помощников SQL на основе ИИ: как сократить затраты без ущерба для качества

Представьте, что ваш помощник SQL – это ракета, прорывающаяся через сложные запросы. Затем однажды вы понимаете, что используете ракетное топливо, чтобы получить список покупок.

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

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

Проблема заключается в здании. Стоит дорого запускать модели ИИ Frontier, которые могут думать об планах выполнения, схемах и сложной логике запросов. Эта цена оправдана для сложных задач, поскольку она стоит около 0,03 доллара за запрос. Однако при использовании для простых операторов SELECT и операций CRUD это становится расточительством в масштабе.

Но ответ не в снижении модели. Это направление запросов в нужное место. Интеллектуальная маршрутизация запросов сортирует каждый запрос по сложности и направляет его в соответствующий уровень модели. Этот метод может сократить затраты на вывод по 40-70% в рабочих нагрузках SQL без ущерба для качества вывода.

Эта статья объясняет, как работает эта архитектура: определение уровней сложности SQL, построение конвейеров классификации и маршрутизации, а также измерение реальных компромиссов между стоимостью и качеством после запуска системы. Эти закономерности отражают уроки, извлеченные при разработке осведомленности о схеме в dbForge AI Assistant.

Почему одна модель не подходит для всех задач SQL

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

Если система behandelt их одинаково, результат предсказуем: расточительство вычислительных ресурсов. В большинстве корпоративных рабочих нагрузок большинство запросов являются рутинными. Простые поиски, чтения из одной таблицы, базовые вставки, исправления синтаксиса. Ничего сложного. Направление всех этих запросов в модель Frontier – это как использование грузового лифта, чтобы нести блокнот.

Один из способов рассматривать эту проблему – разделить запросы на уровни сложности:

Разрыв в стоимости между уровнями значительный. Запрос уровня 1 может стоить около 0,001 доллара на легкой модели. Тот же запрос, направленный в модель Frontier, стоит около 0,03 доллара. При 10 000 запросов в день это 10 долларов против 300 долларов в дневных расходах. Разница в 30 раз, только из-за решений о маршрутизации.

Осведомленность о схеме также имеет значение здесь. Запросы уровня 3 не только требуют больше вычислительных ресурсов, но и контекста: отношения между таблицами, внешние ключи, индексы, синтаксис, специфичный для базы данных. Этот контекст должен быть внедрен во время вывода.

Запуск простого запроса уровня 1 через тот же тяжелый путь расточителен, добавляет задержку и не улучшает результат.

Практическая архитектура для выбора модели

Система маршрутизации обычно имеет четыре стадии: классификация, маршрутизация, выполнение и проверка. Каждая стадия выполняет разную задачу и может выйти из строя по-разному. Полезно думать о них отдельно, прежде чем собирать полный конвейер.

Классификация – наиболее важный шаг. Классификатор получает либо сырой запрос SQL, либо естественно-языковый запрос, который будет сгенерировать его, и присваивает ему уровень сложности. Существует три распространенных способа построения этого классификатора.

Классификация на основе правил полагается на шаблоны regex и парсинг абстрактного синтаксического дерева (AST), чтобы обнаружить структурные сигналы: такие как количество таблиц, глубина вложенности, оконные функции, подзапросы или операторы агрегации. Этот подход быстр и предсказуем, с практически нулевым накладным расходом. Он работает хорошо для очевидных случаев: простые операторы SELECT и базовый DML обычно могут быть определены без участия модели.

Легкие модели классификаторов используют небольшую языковую модель, обученную для оценки сложности SQL. Это добавляет дополнительный шаг, но это один из наиболее высоких ROI решений в整个 конвейере. Вызов классификатора может стоить около 0,0001 доллара, что легко оправдывает избежание вызова модели Frontier стоимостью 0,03 доллара.

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

Гибридная классификация объединяет оба подхода. Логика, основанная на правилах, обрабатывает ясные случаи с нулевой стоимостью, в то время как классификатор обрабатывает неясный средний уровень: запросы, которые выглядят умеренными, но могут фактически требовать осведомленности о схеме для правильной генерации.

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

1. Требования контекста схемы. Некоторые запросы требуют от модели понимания внешних ключей, индексов или других структурных деталей. Эти запросы несут больше контекста и обычно должны быть направлены в модель более высокой способности.
2. Терпимость к задержке. Функции, ориентированные на пользователя, такие как автозаполнение или инлайн-предложения, имеют строгие бюджеты задержки. Фоновые задачи обычно не имеют. В этих случаях более медленная, но более способная модель может быть приемлемой.
3. Пороги уверенности. Иногда классификатор не уверен в уровне сложности. В этих случаях маршрутизация вверх обычно является более безопасным вариантом. Неправильное понижение может произвести плохой запрос и вызвать повторные попытки, что часто стоит больше, чем использование более сильной модели с самого начала.

Слой проверки запускается после выполнения кода. Его задача – поймать ошибки маршрутизации, прежде чем они достигнут пользователя. После выполнения проверяется правильность синтаксиса, разумность результатов (вернул ли запрос правильные формы строк?) и последовательность схемы. Когда результат не проходит проверку, система перемещается на более высокий уровень и запускает запрос снова.

В Devart наиболее важным для обеспечения точности маршрутизации в dbForge AI Assistant было построение осведомленности о схеме в решение о классификации. Без контекста схемы запросы, которые использовали неясные имена таблиц или полагались на неявные отношения, всегда неправильно классифицировались и направлялись в более дешевые модели, которые не могли их обработать. Решением было предоставление классификатору не только структуры запроса, но и некоторой метаданных схемы.

Измерение того, что имеет значение: компромиссы между стоимостью и качеством на практике

Бизнес-сделка по маршрутизации действительна только в том случае, если качество сохраняется. Снижение стоимости, которое приводит к ухудшению вывода, увеличению повторных попыток или недоверию разработчиков, не является экономией, а переносом стоимости с инфраструктуры на время инженерии. Три метрики определяют, работает ли система маршрутизации на самом деле.

Стоимость за запрос по уровню устанавливает базовую линию. Отслеживайте фактические расходы на каждом уровне отдельно, а не как среднее значение. Смешивание затеняет, работает ли маршрутизация, система, которая маршрутизирует 50% запросов в неправильный уровень, все равно покажет более низкую среднюю стоимость, но при этом будет производить худшие результаты.

Балл качества проверяет правильность, полноту и соблюдение лучших практик SQL. Коэффициент эскалации – наиболее прямой сигнал. Он показывает, как часто модель уровня 1 или 2 производит вывод, который не проходит проверку и требует направления в другое место. Хорошо настроенная система должна держать эскалацию ниже 5%. Классификатор необходимо重新 обучить выше этого уровня. Он может неправильно интерпретировать структурные сигналы или может не иметь контекста схемы, необходимого для различия между умеренными и сложными запросами.

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

В реальной жизни хорошо настроенная система маршрутизации может снизить затраты на вывод по 40-60%, держать эскалацию ниже 5% и сохранять качество вывода на высоком уровне для сложных запросов. Чтобы сэкономить 70% или больше, обычно необходимо выполнять задачи уровня 1 самостоятельно с помощью более мелких моделей. Это может сработать, но также усложняет все, с чем не каждая команда хочет иметь дело.

“Налог на эскалацию” – это еще один аспект, который необходимо учитывать. Если маршрутизация слишком сурова для более дешевых моделей, система может выполнять больше работы в целом: вызов классификатора, первоначальный вызов модели, неудачная проверка, перенаправление и второй вызов модели. В некоторых случаях это стоит больше, чем направление вопроса в модель Frontier с самого начала.

Учет только стоимости за вызов пропускает этот эффект. Коэффициент эскалации должен отслеживаться вместе с ним.

Стратегические выводы для инженерных команд

Умная маршрутизация не является просто приятной вещью для зрелых развертываний SQL на основе ИИ; это необходимое условие для долгосрочных развертываний. Команды, которые пропускают это, обменивают проблему бюджета, которую нельзя решить, на проблему архитектуры, которую можно решить. Закономерности есть; все, что осталось, – это решить, какие из них следовать первыми.

Начните с классификатора, а не с моделей. Слой маршрутизации решает, работает ли все остальное. Хорошо настроенный гибридный классификатор даст вам большинство экономии без чрезмерного усложнения.

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

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

Перед классификатором спланируйте слой проверки. Зная, как выглядит неудача, и что вызывает эскалацию, делает логику маршрутизации чище и систему более способной обрабатывать граничные случаи.

Ценность слоя маршрутизации увеличивается, а не уменьшается, по мере улучшения открытых моделей и снижения стоимости локального вывода. Более дешевые модели уровня 1 делают разницу в стоимости между уровнями больше, что делает правильную классификацию более ценной. Архитектура маршрутизации, построенная сегодня, будет полезна в течение долгого времени, а не только как быстрое решение.