Передовые языковые модели терпят неудачу при работе с реальными корпоративными реляционными базами данных. К такому выводу пришли исследователи Санджай Мишра, Дивья Чуккапалли и Ганеш Р. Наик. Тестирование на верификационном наборе из 1000 корпоративных сценариев показало, что GPT-4o, Claude Sonnet 4.5 и Gemini 2.5 Flash достигают точности выполнения запросов лишь на уровне 52,9%, 52,8% и 52,1% соответственно. Авторы объясняют этот провал проблемой масштабирования графа схемы: рабочие базы данных с сотнями нормализованных таблиц, дублирующимися именами столбцов в разных пространствах имен и отсутствующими внешними ключами полностью исчерпывают бюджет внимания стандартных LLM.
Чтобы преодолеть разрыв между генерацией чистого SQL-кода и целостностью данных, команда разработала DRL (Deterministic Relational Middleware Layer) — детерминированный слой реляционного связующего ПО. Фреймворк выстраивает строгую границу между диалоговыми агентами и транзакционными SQL-бэкендами, сочетая динамическое сокращение контекста, офлайн-типизацию через абстрактное синтаксическое дерево (AST) и жесткие предохранители исполнения, такие как валидация плана EXPLAIN и явный контроль значений NULL. В тестах на PostgreSQL динамический маршрутизатор DRL сократил объем промпта на 92% по сравнению с наивной передачей всего каталога данных, продемонстрировав задержку фильтрации на уровне 0,58 мс (p95) и накладные расходы связующего ПО всего в 4,6 мс без учета инференса модели.
Воспринимать генерацию корпоративного SQL как задачу обычного промптинга — тупиковый путь. Семантические парсеры не способны самостоятельно угадывать неявные связи в каталогах или гарантировать безопасность выполнения запросов. Для технических руководителей, подключающих автономных агентов напрямую к боевым OLTP-базам, детерминированные уровни валидации остаются единственным надежным способом исключить риск повреждения данных без постоянного ручного переписывания запросов.