Text2SQL caching становится практичным только тогда, когда кэширует не ответы, а структуру запроса. В этой архитектуре шаблоны SQL снижают latency, token cost и нагрузку на LLM.
Проблема проявилась там, где многие AI-прототипы начинают ломаться в продакшене. Пользовательский запрос обрабатывался за 25–30 секунд, и на этом этапе падало вовлечение. Для Text2SQL это критично: система может быть точной, но слишком медленной, чтобы выглядеть как рабочий инструмент. Без caching каждый вопрос запускал вызов LLM для генерации SQL, а это означало непредсказуемое время ответа, throttling limits и рост token cost вместе с трафиком.
Мы не пошли по пути замены модели на более маленькую и быструю. В исходном тексте прямо сказано, что попытки перейти на smaller models ухудшали качество, а деградация accuracy была неприемлемой. Поэтому выбор был компромиссным, но инженерно понятным: сохранить качество генерации и убрать лишние повторяющиеся вызовы в той части pipeline, где запросы отличаются не смыслом, а параметрами. Так появилась идея кэшировать не user question и не готовый ответ, а SQL query и его шаблон.
Это важный архитектурный сдвиг. Кэш ответа быстро устаревает, потому что данные в operational databases меняются постоянно. Кэш SQL-запроса живет дольше, потому что запрос вроде `SELECT SUM(revenue) FROM sales WHERE quarter = ‘Q3’` сохраняет смысл, даже если данные под ним уже обновились. Дальше команда заметила более сильную закономерность: многие запросы различались только фильтрами. Отсюда и шаблонизация, где `quarter=’Q3’` превращается в `{quarter}`. Такой подход повышает reuse без потери актуальности данных.
Ключевая сложность была не в генерации шаблонов, а в их поиске. Пользователь может спросить “Show me Q3 sales”, а может написать “What were sales in Q3?”. Строковое совпадение здесь бесполезно. Поэтому каждая template pair хранится вместе с vector embedding исходного вопроса, а новый запрос сравнивается через semantic similarity search. Если confidence threshold достаточно высокий, система извлекает entities, заполняет placeholders и идет напрямую к выполнению SQL. Так она bypass-ит дорогой LLM call для генерации запроса.
Implementation здесь построен как конвейер с четкими развилками. Сначала идет entity recognition, причем система учитывает не только текущий вопрос, но и conversation history, current date и user preferences. Это помогает разобрать такие ссылки, как “last month” или “my region”. Затем embedding нового вопроса ищет ближайший шаблон в cache. Если совпадение найдено, placeholder’ы заполняются и SQL выполняется как parameterized database query, а не через string interpolation. Это одновременно снижает риск SQL injection и помогает отсеивать ошибки entity extraction.
Если шаблон не найден, система возвращается к стандартному Text2SQL pipeline. Там LLM генерирует SQL с полным контекстом схемы и примерами. После успешного fallback query система не выбрасывает результат. Она пытается снова обобщить запрос в template и добавить его в cache. Это создает self-improving loop: покрытие растет по мере того, как реальные запросы пользователей показывают новые паттерны. Такой механизм особенно полезен в доменах, где набор формулировок ограничен, а структура вопросов повторяется.
Важный нюанс — проверка достаточности результата. После выполнения SQL система отправляет результаты в response generation model, которая должна не только сформировать ответ, но и понять, достаточно ли данных для него. Если запрос просил “Q3 sales by region”, а шаблон вернул только общий total, ответ считается incomplete. Это снижает риск уверенно выдать частичный результат за полный. Для production-системы это не косметическая деталь, а защитный слой против тихих ошибок.
Результат описан без попытки превратить его в маркетинговую метрику. В production deployment параметризованные SQL templates снизили end-to-end latency на 80% и сократили token consumption более чем на 50%. При этом авторы отдельно уточняют: конкретные цифры зависят от schema size, prompt design, model choice и query mix. То есть главный вывод не в абсолютных значениях, а в направлении улучшения. Самая дорогая стадия Text2SQL — генерация SQL через LLM — была вынесена из hot path на cache hit, а это и дало основной выигрыш.
В инженерном смысле это прагматичный паттерн. Система не пытается “ускорить LLM” как черный ящик. Она уменьшает число обращений к нему там, где задача уже может быть решена структурно. Для Text2SQL это особенно логично: смысл запроса часто повторяется, меняются только значения. Именно поэтому template caching оказывается не обходным путем, а более точным уровнем абстракции.