На реальных запросах к хранилищу MIT система text-to-SQL показала 0% точности, хотя публичные бенчмарки обещают более 80%. Для команд, внедряющих PostgreSQL для ИИ, это неприятное, но полезное напоминание: красивое демо с вопросом на естественном языке ещё не означает, что агенту можно поручить корпоративные данные.
Об этом в партнёрском материале EnterpriseDB сообщает The Register со слов Майкла Стоунбрейкера, создателя Postgres, и Брюса Момджиана, сооснователя PostgreSQL Global Development Group. Их общий тезис прост: ИИ нужен не очередной слой промптов поверх данных, а управляемая реляционная основа с правами доступа, журналами действий и предсказуемым поведением.
Почему text-to-SQL ломается на настоящих данных
Команда Стоунбрейкера проверяла text-to-SQL не на учебных наборах, а на хранилище MIT: около 1 400 таблиц со сведениями о студентах, преподавателях, зданиях и зарплатах. В тест взяли реальные запросы из SQL-лога. Итоговая точность оказалась нулевой. Подключение агентного подхода, retrieval и настройки промптов подняло результат лишь до значений «в районе десятков процентов». Когда модели дали сведения обо всех таблицах и терминах соединений, она добралась до уровня в 30%, но это всё равно далеко от рабочего инструмента для предприятия.
Причина не в том, что компании недостаточно старательно пишут промпты. У корпоративной базы обычно нет публичного обучающего корпуса: она закрыта от интернета и содержит локальные правила, сокращения и исторические артефакты. В MIT, например, здания обозначаются номерами, а не привычными названиями. За годы схема обрастает неочевидными именами столбцов, дублирующимися представлениями и исключениями. Модель может уверенно собрать синтаксически корректный SQL, который просто отвечает не на тот вопрос. Для аналитики это досадная ошибка, для кредита, расчёта зарплаты или медицинского процесса — уже риск с вполне материальными последствиями.
Стоунбрейкер приводит и более сложный пример: чтобы разобраться с жалобой жителя на работу пешеходного перехода, специалистам транспортного ведомства Мюнхена пришлось объединять регламенты, CAD-чертежи, расписания троллейбусов и карты школьных зон. Попытка держать языковую модель в центре такой цепочки оказалась слишком дорогой. В разработанной его командой системе Rubicon модели обрабатывают текстовые фрагменты, затем результаты приводятся к табличному виду, а соединения и вычисления выполняет табличный движок. По оценке автора Postgres, такой подход примерно в десять раз дешевле и точнее агентных схем, где LLM пытается дирижировать всем процессом.
База как память и контур безопасности
Для разработчиков вывод звучит прозаично, зато практично: LLM стоит использовать там, где она сильна — в разборе и генерации текста. Операции над структурированными данными, соединения таблиц, ограничения и контроль доступа разумнее оставить СУБД. Именно здесь PostgreSQL для ИИ выглядит не как модная приставка к привычной базе, а как слой, который делает агентские действия проверяемыми. В базе уже есть роли, аудит, транзакции и триггеры, способные остановить нежелательное изменение до фиксации.
Стоунбрейкер считает, что агенты, работающие с данными, в перспективе должны жить ближе к данным — например, в форме пользовательских функций. Но для этого нужны зрелые средства отладки, версионирования и наблюдаемости. Иначе компания получает не цифрового сотрудника, а сервис с широкими полномочиями, который иногда объясняет свои действия очень убедительно, но воспроизвести их не может. Недетерминированность особенно плохо сочетается с процессами, где решение требуется подтвердить на проверке или в суде.
Отдельная тема — независимость самой платформы. По словам Стоунбрейкера, ключевая особенность PostgreSQL в том, что им не управляет единственный поставщик. В разработке участвуют инженеры EDB, Microsoft, Google и других компаний, но ни одна из них не может единолично определять курс проекта. Для бизнеса это снижает зависимость от вендора и упрощает разговор о суверенности данных: где система работает, кто её обслуживает и как организация контролирует изменения.
Момджиан описывает PostgreSQL как проект без офиса, активов и единого юридического лица, который при этом конкурирует с продуктами компаний с миллиардными бюджетами. Такая модель иногда кажется медленной тем, кто ждёт кнопку с надписью «включить ИИ». Зато она хорошо переживает смену технологической моды. Архитектура Postgres изначально делалась расширяемой, поэтому в неё без полной перестройки вошли JSON, полнотекстовый поиск, геоданные и новые ИИ-сценарии.
В обсуждаемом PostgreSQL 19 сообщество делает ставку на эксплуатационные улучшения: REPACK CONCURRENTLY для работы с нагруженными таблицами, более умный параллельный autovacuum и синхронизацию последовательностей при логической репликации. Несколько функций, включая запросы к графам свойств SQL и операции слияния и разделения партиций, были убраны из предварительных планов ради надёжности. Показателен и другой факт: августовское обновление PostgreSQL 18 закрыло 28 CVE, а ИИ-инструменты помогали быстрее находить проблемы при ревью кода.
Спор между собеседниками остаётся в деталях. Момджиан ожидает, что агенты будут создавать базы и генерировать заметную часть кода. Стоунбрейкер считает, что в крупных организациях это упрётся в качество описания данных, закрытые силосы и внутреннюю политику. Но направление понятно уже сейчас: PostgreSQL для ИИ нужен не для того, чтобы агент красивее писал SQL, а чтобы его память, доступы и последствия действий оставались под контролем людей.
