Как журналы запросов исправляют ошибки SQL у ИИ-агентов

Когда аналитики Miro направили ИИ-агентов напрямую в свою средовую базу Snowflake, агенты выдавали неверные ответы более чем в 65% случаев. Проблема заключалась не в самой модели, а в контексте. При наличии более 10 000 таблиц и отсутствии семантического слоя для маршрутизации у агентов не было возможности узнать, какие именно массивы данных соответствуют тем или иным бизнес-вопросам.

В четверг DataHub выпускает слой контекстного интеллекта (context intelligence layer), который анализирует историю существующих SQL-запросов для построения семантического индекса и предоставляет к нему доступ агентам через MCP, LangChain, Agent Development Kit от Google и CrewAI. Компания называет это решение Context Intelligence; оно построено на той же инфраструктуре журналов запросов, которую DataHub использовала для отслеживания происхождения данных (lineage) в производственных развертываниях по всему миру.

Компания была основана командой, которая создала DataHub как проект с открытым исходным кодом в LinkedIn, где сооснователь и технический директор Ширшанка Дас руководил инфраструктурой данных почти 11 лет. На сегодняшний день открытый проект насчитывает более 15 000 участников и 3 000 рабочих внедрений по всему миру.

«Впервые компании могут превратить многолетнюю историю запросов аналитиков в живую, доступную базу знаний, где агенты перестают галлюцинировать при соединении таблиц, потому что у них есть доступ к тем соединениям, которые уже работали раньше и были проверены людьми, запустившими их», — рассказал в эксклюзивном интервью VentureBeat Ширшанка Дас, сооснователь и технический директор DataHub.

Почему история запросов эффективнее сырой схемы для маршрутизации агентов

DataHub начинался как проект по управлению метаданными в LinkedIn, созданный для решения двух задач одновременно: облегчить поиск и использование данных по всей организации и гарантировать, что они применяются только по назначению. Дас открыл исходный код проекта в начале 2020 года после почти шести лет внутренней разработки.

Основным сценарием использования за прошедшие годы стало отслеживание происхождения (lineage) — понимание того, как данные поступают из операционных систем через потоковую инфраструктуру в хранилища и передаются в бизнес-инструменты. Аудиты на соответствие нормативным требованиям, оперативное устранение неполадок и онбординг новых инженеров — все это зависит от графа происхождения данных. Postgres является наиболее часто подключаемым источником в базе развертываний DataHub по всему миру, за ним следуют MySQL, Oracle и основные облачные хранилища, включая Snowflake и Google BigQuery. Платформа поддерживает более 100 подключенных источников метаданных.

Эта обширная база развертываний имеет решающее значение для нового продукта DataHub. Возможности извлечения логов запросов и синтаксического анализа SQL, лежащие в основе Context Intelligence, разрабатывались годами в рамках реальной эксплуатации, а не создавались специально под этот релиз. Теперь та же инфраструктура обслуживает агентов, запрашивающих семантический индекс во время выполнения.

«Слой потребления изменился: от людей к агентам», — отметил Дас.

Context Intelligence обрабатывает проверенную историю запросов, а не сырые логи

Context Intelligence — это новый функциональный уровень, построенный поверх существующей базы метаданных DataHub с открытым исходным кодом. Платформа с открытым исходным кодом годами извлекала и анализировала логи запросов из подключенных хранилищ для отслеживания происхождения данных. Именно на эту инфраструктуру опирается Context Intelligence при построении семантического индекса. Сама возможность — новая, но лежащая в ее основе техническая база — нет.

Фильтрация полезного сигнала. Журналы запросов хранилищ содержат слишком много шума для прямого использования. Движок DataHub отбирает то, что Дас называет «золотыми запросами» — высококачественными запросами аналитиков и запланированными пайплайнами, которые отражают проверенную бизнес-логику.

Превращение SQL в семантические определения. Движок извлекает паттерны из этих запросов и переводит их в структурированные текстовые определения, которые в DataHub называют семантическими якорями. Эти якоря формируют основу извлечения, к которой агенты обращаются перед генерацией SQL.
«Это можно рассматривать как обратный процесс преобразования текста в SQL», — сказал Дас.

Чешская проверка (валидация). Context Hub позволяет профильным экспертам просматривать предложенный ИИ контекст, разрешать конфликтующие определения и симулировать влияние изменений перед публикацией. DataHub выявляет случаи, когда разные команды рассчитывают одну и ту же метрику по-разному, и выносит их на рассмотрение людей.

Как в Miro заставили ИИ-агентов работать с 10 000 таблиц Snowflake

Платформа цифровой коллаборации Miro уже использовала DataHub для отслеживания происхождения данных и анализа их влияния, когда начала тестирование аналитических агентов на своей среде Snowflake. Рональд Энджел, продакт-менеджер платформы данных в Miro, рассказал VentureBeat, что масштаб хранилища данных сразу же стал проблемой. Отправка запросов на естественном языке напрямую в MCP Snowflake приводила к неверным ответам более чем в 65% случаев. Предоставление агентам прямого доступа к более чем 10 000 таблиц создавало слишком много путаницы для надежной маршрутизации.

Miro решила эту проблему, организовав данные в четко определенные продукты данных, которые ограничивают видимость для агентов, вместо того чтобы открывать сырую схему. Производственная архитектура работает следующим образом: запросы пользователей, поступающие через Claude Chat или Claude Cowork, проходят через контекстный слой, где MCP от DataHub сопоставляет естественный язык с соответствующими массивами данных, а затем передает задачу MCP от Snowflake для генерации SQL.

По словам Энджела, контекстный слой подтягивает метаданные, связи между сущностями, историю запросов и бизнес-цель для каждой таблицы Snowflake, в частности, на какой именно бизнес-вопрос призвана отвечать каждая сущность. Эти семантические сигналы позволяют агенту определить правильные сущности базы данных до написания SQL, а не угадывать их исключительно по схеме.

Pinecone, Oracle, Redis, Microsoft: как DataHub вписывается в контекстный стек

Поставщики данных, включая Pinecone, Oracle и Redis, обладают возможностями контекстной памяти. На уровне платформ компания Microsoft создала Fabric IQ в качестве семантического слоя для контекста.

Аргумент DataHub заключается не в паритете функций. Компания позиционирует свой контекстный слой как платформенно-нейтральный — обеспечивая передачу контекста в существующие конечные точки (например, семантические представления Snowflake и Microsoft Fabric IQ) вместо того, чтобы заменять их.

«Часто люди хотят, чтобы их контекстный слой был платформенно-нейтральным», — отметил Дас.

Кевин Петри, аналитик из BARC, сообщил VentureBeat, что считает сильной стороной DataHub на рынке ее способность интегрировать разнообразные метаданные как для структурированных, так и для неструктурированных объектов, включая документы и изображения.

«Многие другие вендоры больше сосредоточены на структурированных таблицах, которые предоставляют проверенные факты, но часто лишены богатого контекста текстовых объектов», — пояснил он.

Майкл Ни, вице-президент и ведущий аналитик Constellation Research, рассказал VentureBeat, что в контекстном слое DataHub для него выделяется поддержка перехода от пассивного каталогирования к непрерывно обновляемому семантическому интеллекту.

Ни охарактеризовал конкуренцию за контекст как следующую крупную битву платформ, утверждая, что тот, кто контролирует контекст во время выполнения, контролирует уровень принятия решений для данных, агентов, рабочих процессов и бизнес-процессов.

«Покупателям следует быть осторожными, поскольку многие вендоры поддерживают лишь часть полного набора контекстных возможностей, необходимых для ИИ и агентских решений, — заявил Ни. — Покупателям необходимо четко понимать свои требования к управлению контекстом, поскольку векторная память — это еще не бизнес-смысл, бизнес-смысл — это не управление (governance), а управление — это еще не исполнение».