EDB встроила семантический слой для агентов в Postgres и подключила к Bedrock

Классическая беда text-to-SQL: агент видит названия колонок, но не понимает, что за ними стоит бизнес. Он не знает, что «большой клиент» у вас означает заказ дороже 250 долларов, а колонка price хранит сумму всего заказа. В итоге получаются красивые, но неверные цифры. AWS в очередной статье серии про семантические слои показывает подход EDB: не заводить отдельную систему смыслов, а положить её в тот же Postgres, где лежат данные.

Как это устроено

В EDB Postgres AI есть расширение AIDB. Оно создаёт семантическую базу знаний (SemKB) поверх схемы. В неё попадают определения таблиц, представлений и колонок вместе с текстом из COMMENT ON. Всё это превращается в эмбеддинги, и агент ищет нужную таблицу по смыслу, а не по имени. Внешние ключи автоматически превращаются в пути соединения таблиц.

Авторинг сводится к трём вещам. Первая: комментарии к колонкам. Вторая: бизнес-термины как представления со своим комментарием, например view big_spender, где определение лежит в одном месте для всех агентов и дашбордов. Третья: семантические алиасы, то есть именованные параметризованные SELECT с описанием на естественном языке. Агент находит такой алиас по смыслу и вызывает как готовый инструмент.

В примере со статьёй цена ошибки хорошо видна. Если агент прочитает purchases.price как цену единицы и умножит на количество, топ-клиент получит 502 529 долларов вместо реальных 27 991,66. Один комментарий к колонке закрывает эту дыру.

Как агент добирается до данных

Схема такая. Аналитик логинится через Amazon Cognito и вызывает AgentCore Gateway с JWT. Gateway проверяет токен и политику Cedar, затем направляет запрос в рантайм агента на Strands Agents, где планирует Claude на Bedrock. Инструменты агент вызывает по MCP. Встроенный в AIDB сервер edb-endpoints уже говорит на streamable HTTP MCP с Basic-авторизацией, поэтому Gateway подключается к нему напрямую через Application Load Balancer. Лямбды и прослойки не нужны.

Пароль роли Postgres хранит AgentCore Identity и подставляет в каждый исходящий запрос. Код агента этого пароля не видит.

Права решает Postgres, а не промпт

Самое полезное место статьи — governance. У MCP-эндпоинта нет собственной системы разрешений: что можно, решают обычные GRANT. Каждый запрос открывает отдельное соединение под логином из Basic-заголовка, так что current_user внутри инструмента — это роль агента, и она видна в pg_stat_activity.

Авторы создают две роли. mcp_agent_full видит всё, mcp_agent_restricted — всё, кроме customers.ssn. Промпт, каталог инструментов и код агента одинаковы. На просьбу «покажи пять клиентов с номерами соцстрахования» первая роль получит данные, вторая — ошибку permission denied, которую MCP передаёт без изменений. Дополнительно можно включать row-level security, чтобы разные роли видели разные строки.

Аудит тоже остаётся в базе. AIDB пишет OpenTelemetry-трейсы выполнения SQL в схему aidb_otel, и их можно разбирать обычным SQL. Трейсы AgentCore по вызовам инструментов, LLM и токенам уходят в CloudWatch.

Что с этим делать

Если у вас операционный Postgres и вы строите агента для аналитики или поддержки, начните с дешёвого: напишите COMMENT для неочевидных колонок и вынесите бизнес-термины во view. Это улучшает точность и без всякого AIDB.

Ограничения тоже есть. Это решение вокруг экосистемы EDB: AIDB, его AMI и MCP-сервер. SemKB индексирует схему, а не данные, поэтому качество зависит от дисциплины в комментариях. Модели в AWS доступны не во всех регионах. Пример построен на маленьком демонстрационном наборе из четырёх таблиц, а на сотнях таблиц поиск по смыслу придётся проверять отдельно.

Итог: идея «смысл и права живут рядом с данными» убирает целый класс проблем синхронизации каталогов и позволяет доверять ограничениям доступа больше, чем просьбам в системном промпте.