Сравнение подходов подключения LLM к сложной БД: победил неожиданный метод, но выявились системные проблемы
Исследование трёх способов интеграции больших языковых моделей с базой данных из 253 таблиц выявило победителя по точности, стоимости и скорости, которым оказался не самый популярный вариант. Однако ключевым выводом стали серьёзные дефекты в методологии тестирования и фундаментальное ограничение всех подходов, связанное со скрытой семантикой в коде приложения.
В споре о подключении больших языковых моделей к сложным базам данных эмпирические данные оказались важнее маркетинговых заявлений. Исследователи сравнили три подхода интеграции с реальной производственной базой данных, содержащей 253 таблицы. Целью было определить самый эффективный метод по точности исполнения запросов, стоимости вызовов и задержке.
Для чистоты эксперимента собрали специальный бенчмарк из 29 реальных вопросов от аналитиков. Это позволило оценить подходы в условиях, максимально приближенных к реальным.
Сравнили два популярных направления: использование инструментов MCP и помещение схемы базы данных прямо в системный промпт модели. Третий, гибридный вариант, изначально не имевший явных сторонников, стал главным сюрпризом. Он показал лучший совокупный результат по всем трём метрикам.
Интересно, что больше всего ошибок в тестировании допустил не искусственный интеллект, а человек - составитель бенчмарка. Он трижды ошибся в ожидаемых ответах, и в одном случае его поправила сама испытуемая модель.
Анализ выявил серьезные дефекты в самом наборе тестов. Эти недостатки приводили к тому, что система иногда выдавала правдоподобные, но неверные числовые ответы, вместо того чтобы сообщить о невозможности выполнить запрос. Такое поведение создает опасную иллюзию корректной работы, что в бизнес-среде может привести к решениям на основе ошибочных данных. Качество бенчмарков для оценки систем на основе больших языковых моделей критически важно, и без их тщательной проверки любые сравнения вводят в заблуждение.
Исследование выявило более фундаментальное ограничение. Семантика данных, скрытая в коде бизнес-приложения, представляет собой естественный предел для любого подхода. Большая языковая модель, даже имея точную схему базы данных и мощные инструменты, не может вывести бизнес-логику, правила агрегации, специфичные преобразования или неочевидные связи, которые прописаны в коде сервиса и не отражены в SQL-схеме. Для создания надежных систем, способных отвечать на сложные вопросы, недостаточно просто дать модели структуру таблиц. Нужна интеграция на более глубоком уровне, включающая понимание контекста и бизнес-правил. Это отдельная сложная инженерная задача.
Что это значит для практиков? Во-первых, при выборе архитектуры не стоит слепо следовать трендам - простые или гибридные решения могут оказаться эффективнее. Во-вторых, важно инвестировать время в создание корректных, проверенных тестовых наборов. Ошибки в них искажают оценку всей системы. В-третьих, большая языковая модель не станет волшебной палочкой, которая просто поймет вашу базу данных. Максимальная точность достижима только тогда, когда модель получит доступ не только к структуре, но и к смысловому слою - бизнес-логике. Это ведет к необходимости разработки сложных промежуточных слоев, семантических коннекторов или специализированных агентов, что требует значительных инженерных усилий.
