Когда команда Miro пустила AI-агентов напрямую в Snowflake, те ошибались больше чем в 65% случаев. Новый контекст для AI-агентов, который готовит DataHub, предлагает чинить не модель, а навигацию по данным: вместо угадывания по схеме агентам дают память о том, какие SQL-связки уже работали в реальной компании.
О запуске новой прослойки Context Intelligence сообщает VentureBeat. Идея у DataHub довольно приземленная и потому опасно правдоподобная: если в хранилище больше 10 тысяч таблиц, агенту мало названий полей и DDL, ему нужен рабочий контекст. Иначе даже хороший LLM начинает фантазировать на тему join’ов, метрик и того, какая таблица вообще отвечает на бизнес-вопрос.
DataHub строит этот контекст не с нуля и не на очередной модной «семантической магии», а на SQL-истории, которую компании и так копят годами. Платформа забирает query logs из хранилищ, фильтрует шум и выделяет так называемые golden queries — качественные аналитические запросы и пайплайны, в которых уже зафиксирована проверенная бизнес-логика. Дальше из них извлекаются паттерны и формируются semantic anchors — структурированные текстовые определения, которые агент может использовать до генерации SQL. По сути, речь о попытке инвертировать классическую схему text-to-SQL: сначала найти правильный смысл и нужные сущности, потом уже писать запрос.
Для DataHub это не эксперимент на салфетке, а надстройка над давно существующей инфраструктурой. Проект вырос из внутренней системы LinkedIn, где сооснователь и CTO Ширшанка Дас почти 11 лет отвечал за data infrastructure. В open source DataHub ушел в начале 2020 года после примерно шести лет внутренней разработки. С тех пор главной задачей платформы был lineage — отслеживание того, как данные идут из операционных систем через стриминг и хранилища в BI и продуктовые инструменты. По данным компании, у проекта уже больше 15 тысяч контрибьюторов и 3 тысяч production-развертываний по миру, а среди самых частых подключенных источников — Postgres, MySQL, Oracle, Snowflake и Google BigQuery. Поддерживается более 100 источников метаданных. Это важная деталь: plumbing для извлечения query logs и разбора SQL у них уже был, меняется лишь слой потребления — раньше им пользовались люди, теперь на него сажают агентов.
Кейс Miro здесь не декоративный, а показательный. Компания уже использовала DataHub для lineage и impact analysis, когда начала тестировать аналитических агентов против своего Snowflake-окружения. Проблема всплыла сразу: натуральные запросы, отправленные напрямую в Snowflake MCP, слишком часто приводили к неверным ответам. Причина банальна для любой большой дата-платформы: когда агент видит более 10 тысяч таблиц без нормального маршрутизатора по смыслу, он не понимает, какой набор данных соответствует какому бизнес-вопросу. В продакшене Miro пошла другим путем: не открывать агенту весь склад данных целиком, а собирать их в хорошо определенные data products и ограничивать видимость. Архитектура выглядит так: пользователь задает вопрос через Claude Chat или Claude Cowork, затем контекстный слой с MCP от DataHub подбирает нужные активы, и только после этого запрос уходит в Snowflake MCP на генерацию SQL. В этот контекст подтягиваются метаданные, связи между сущностями, история запросов и бизнес-намерение каждой таблицы — то есть ответ на вопрос, для какой задачи она вообще создана.
На рынке такой ход вряд ли пройдет незамеченным, потому что борьба смещается от «у кого лучше модель» к «у кого лучше runtime-контекст». Вендоры вроде Pinecone, Oracle и Redis уже развивают механики контекстной памяти. У Microsoft есть Fabric IQ как семантический слой. Но позиция DataHub чуть хитрее: компания не пытается заменить все эти системы, а продает идею платформенно-нейтрального слоя, который может подмешивать контекст для AI-агентов в уже существующие endpoints — например, в Snowflake semantic views или тот же Fabric IQ. Для компаний это звучит разумно: мало кто хочет намертво зашивать бизнес-смысл в один конкретный стек и потом обнаружить, что мигрировать данные проще, чем мигрировать смысл.
Аналитики, опрошенные VentureBeat, подчеркивают именно это. Кевин Петри из BARC выделяет способность DataHub работать не только со структурированными таблицами, но и с более разнообразными объектами, включая документы и изображения. Майкл Ни из Constellation Research видит в этом переход от пассивного каталогизирования к постоянно обновляемому семантическому интеллекту. Его формулировка, пожалуй, самая полезная для CIO и data platform команд: конкуренция за контекст может стать следующей большой платформенной войной, потому что тот, кто контролирует контекст во время выполнения, контролирует и слой принятия решений для данных, агентов и бизнес-процессов. И здесь есть трезвое предупреждение для покупателей: vector memory — это еще не бизнес-смысл, бизнес-смысл — не governance, а governance сам по себе не гарантирует исполнение.
Для разработчиков и продуктовых команд вывод тоже вполне прикладной. Если ваш AI-аналитик ошибается в SQL, проблема может быть не в модели и не в размере контекстного окна. Часто агент просто не знает, какие join’ы в компании уже считаются валидными, какие метрики спорные, а какие таблицы вообще трогать не стоит. Поэтому контекст для AI-агентов постепенно становится такой же базовой частью стека, как каталог данных, lineage и доступы. Вопрос теперь не в том, будут ли компании строить такие прослойки, а в том, кто первым превратит накопленную историю запросов в рабочую память для агентных систем. Проверить первоисточник и цитаты можно в материале VentureBeat .
The post DataHub учит AI-агентов не путаться в SQL по истории запросов appeared first on iTech News.