LLM и база данных на 253 таблицы: схема целиком в промпте обошлась в 110 рублей и победила

---

Крупная финтех-база на 253 таблицы стала полигоном для честного сравнения трёх способов подключить LLM (большую языковую модель, которая генерирует текст и код) к реальным данным, и результат удивил обе стороны спора.

Источник, статья инженера финтех-компании (более миллиона пользователей, шесть стран), описывает внутренний эксперимент. Команда разделилась: одни считали, что ИИ-агент (программа, которая сама вызывает нужные инструменты) должен каждый раз заново исследовать схему базы через MCP (Model Context Protocol, протокол, позволяющий модели самой вызывать инструменты). Другие, включая автора, настаивали: дешевле один раз вложить описание схемы в промпт (текстовую инструкцию для модели). Спорили на ощущениях, пока не собрали бенчмарк на собственных данных.

Три подхода, которые сравнивали

• A. MCP. Агент сам просматривает список таблиц, читает их описание и выполняет SQL-запросы. Боевой вариант компании.
• B. Schema linking (связывание схемы). Два вызова модели: сначала ей показывают каталог всех 253 таблиц (2 234 токена, то есть примерно 1 700 слов), она выбирает до 10 подходящих, затем получает их полную структуру и пишет SQL. На один вопрос уходит от 600 до 2 800 токенов.
• C. Вся схема целиком в промпт. DDL (описание структуры всех таблиц) плюс 346 перечислений значений, 58 727 токенов в каждый запрос. Заранее казалось, что это слишком дорого.

Рабочая модель: MiniMax-M2, температура 0. Автор подчёркивает: на моделях другого класса и цены выводы могут развернуться.

Почему аргумент «это дорого» не сработал?

Команда заранее посчитала стоимость подхода C, ожидая убийственную цифру. Весь прогон, до трёх попыток на каждый вопрос по 58 000 токенов, обошёлся примерно в 110 рублей. Без промпт-кеширования (механизм, при котором повторяющийся текст не пересчитывается заново). На MiniMax-M2 входной токен стоит $0,26 за миллион, и на этой модели денежный довод против «схема целиком в промпте» просто не работает. Автор предупреждает: на Claude или GPT-4 арифметика будет другой.

Как измеряли точность?

Сравнивать текст SQL бессмысленно: два разных запроса могут дать одинаково верный ответ. Поэтому использовали execution accuracy, как в академических бенчмарках Spider и BIRD: выполняли запрос, сравнивали набор результатов с эталонным. Порядок строк и имена колонок не учитывались, числа сравнивались с округлением.

Золотой набор: 29 вопросов из реальной истории обращений аналитиков.

• 12 простых (одна таблица)
• 11 средних (2-3 соединения)
• 6 сложных (агрегации, оконные функции)

На каждый вопрос давалось 3 попытки. EX@1 означает верный ответ с первой попытки, EX@3 означает верный ответ хотя бы с одной из трёх. После неудачной попытки модель получала обратную связь: текст ошибки БД или сообщение «результат неверен» без данных.

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

Эталонные ответы составлял ИИ-агент на Claude. Компенсировали двумя проверками: независимый SQL другим путём должен дать тот же результат, плюс сверка с бизнес-реальностью.

Три найденные ошибки, все одного типа: судья додумывал смысл колонки по её имени, не заглядывая в код.

Ошибка на два порядка. Вопрос «сколько активных партнёров» судья посчитал через колонку BusinessmanStatus = 1, получил 432. Перекрёстный запрос подтвердил ту же цифру. Поймал только проверка на здравый смысл: в одной из стран с тысячами пользователей «активных партнёров» оказалось ноль. В коде выяснилось, что BusinessmanStatus отвечает за статус ИП для выплат, а роль партнёра лежит в таблице ролей. Правильный ответ: 33 434. Ошибка в 77 раз, причём со статусом «подтверждено».

Ошибку нашла испытуемая модель. На вопросе про склады ветка C добавила фильтр по типу склада, которого не было в эталоне. Проверка по перечислению в коде подтвердила: модель права, эталон считал лишние шесть складов.

Три ошибки на 29 эталонов, это 10% известного шума разметки. Автор честно говорит: сколько ошибок не поймано, неизвестно. Поэтому разницу между подходами меньше 10 процентных пунктов он не интерпретирует.

Что с этого вам прямо сейчас?

Авторам Дзена и копирайтерам. Если вы используете LLM для работы с базой данных (например, генерируете отчёты из CMS или аналитических панелей), не доверяйте «эталонным» ответам без проверки на здравый смысл. Один бизнес-инвариант («в стране с тысячами пользователей не может быть ноль партнёров») ловит ошибку, которую пропускает перекрёстная проверка.

Маркетологам. Стоимость «вшить всю схему в промпт» на дешёвых моделях оказалась около 110 рублей за полный прогон. Прежде чем отбрасывать подход как дорогой, посчитайте на своей модели: возможно, экономия на вызовах API перевесит расход токенов.

Предпринимателям в РФ и СНГ. Для реальной базы на 250 и более таблиц общие рекомендации не работают. Соберите бенчмарк на своих данных: 25-30 типовых вопросов из реальной практики аналитиков, проверьте эталоны вручную, замерьте. Затраты на схему в промпте часто ниже, чем кажется, а точность может быть выше, чем у «умного» агентного подхода. Из доступных в РФ моделей для экспериментов подойдут YandexGPT и GigaChat, но результаты нужно перемерять: выводы автора получены на MiniMax-M2 и могут не перенестись на другую модель.

Честный бенчмарк на своих данных стоит дешевле одного дня споров в отделе. Соберите 29 вопросов, проверьте эталоны бизнес-инвариантами и замерьте. Ответ «какой подход лучше» зависит от вашей базы, вашей модели и вашей цены за токен, а не от чужих рекомендаций.