Содержание
Коротко
Большая языковая модель (LLM) способна уверенно назвать сумму или среднее значение, даже когда у неё нет для этого всех данных. Автор разбора на Habr предлагает не просить ИИ считать «в уме», а отдать вычисления DuckDB и оставить модели роль оператора инструментов.
В основе подхода — схема данных до первого запроса, безопасный доступ только для чтения и отдельная песочница для сложной аналитики. Это не отменяет ошибок полностью, но заметно сужает пространство, в котором ИИ может их придумать.
Что произошло
Автор начал с практической проблемы: передача CSV-файла прямо в контекст модели плохо подходит для анализа таблиц. Для LLM таблица остаётся текстом; если строк слишком много, колонка названа неожиданно или вопрос сформулирован неточно, модель может достроить правдоподобный ответ вместо честного «не знаю».
В Claude Desktop анализ крупных наборов данных выглядит устойчивее, но результат одного и того же вопроса может зависеть от выбранного моделью пути. Поэтому автор не пытается воспроизвести внутреннее устройство продукта, а переносит полезный принцип в собственный сервер инструментов: модель формулирует запрос, а проверяемая среда получает и считает данные.
Для арифметики используется DuckDB. ИИ пишет SQL, но среднее, сумма, группировка и соединение таблиц выполняются движком. Когда SQL недостаточно для статистики, прогнозов или преобразований, код запускается в отдельной изолированной среде Python.
Почему это важно
Ошибка в числах опаснее обычной неточности в тексте: ответ может звучать убедительно и попасть в отчёт, решение о бюджете или сообщение клиенту. Даже верный движок не спасёт, если модель запросила не ту колонку либо посчитала итог только по усечённому выводу.
Поэтому важен порядок действий. Сначала ИИ должен увидеть каталог доступных наборов и их структуру: имена полей, типы, долю пропусков, единицы измерения и валюты. Лишь затем он составляет запрос. Такой порядок уменьшает риск выдуманных таблиц, полей и смешения несовместимых значений.
Автор также возвращает модели подробный контекст о результате. Если запрос не нашёл строк, инструмент показывает реальные допустимые значения в условиях. Если выборка сокращена, ответ прямо предупреждает об этом. Вместо догадки модель получает материал, с которым можно исправить запрос.
На практике
Начать можно с небольшого набора ограничений, не строя сложную аналитическую платформу:
- Выполняйте арифметику и агрегации в базе или аналитическом движке, а не в ответе LLM.
- Давайте модели отдельный инструмент для просмотра схемы до доступа к данным; не просите угадать имена таблиц.
- Разрешайте только запросы на чтение и проверяйте SQL до исполнения. Запрещайте изменение данных, подключение произвольных файлов и загрузку расширений.
- Запускайте произвольный Python-код в изолированной среде с заранее известным набором библиотек и без лишнего доступа к сети.
- Передавайте число найденных строк, признак усечения и понятные сообщения об ошибках. При нулевом результате помогайте проверить фильтр на фактических значениях.
Стоит помнить и о границах метода. Простая проверка запроса может пропустить неверное соединение таблиц, а устаревшее описание схемы — отправить модель к уже удалённому полю. Подсказка о смешанных валютах полезна, но не заменяет запрет или проверку правилами.
Итог
Надёжность здесь строится не на обещании, что ИИ перестанет ошибаться. Она появляется, когда вычисления, доступ к файлам и состояние данных контролирует код, а модель не получает возможности заполнить пробел красивой догадкой.
Для команд, которые подключают LLM к таблицам, это практичный ориентир: сделать каждый результат прослеживаемым до выполненного запроса и набора данных. Там, где граница закреплена в инструменте, ответ легче проверить и воспроизвести.