- Дата публикации
DataCopilot от VK: как рой ИИ-агентов разгружает data‑команды и пишет SQL за сотрудников
Что нового
VK собрала внутреннего ассистента DataCopilot для работы с корпоративным хранилищем данных и документацией. Вместо одного «всезнающего» RAG-бота команда запустила мультиагентную систему по паттерну Swarm (роевая архитектура в LangGraph).
Ключевые изменения по сравнению с классическим RAG:
- Разделение на специализированных агентов, а не один универсальный бот.
- Отдельные промпты и инструменты для разных задач: поиск витрин, генерация SQL/ClickHouse-кода, ответы по документации, оркестрация диалога.
- Маршрутизация сложных запросов: один запрос пользователя может автоматически раскладываться на несколько шагов и передаваться между агентами.
Конкретные результаты за февраль 2026 года внутри VK:
- 731 сотрудник воспользовался системой.
- Retention 68% — 499 человек вернулись к DataCopilot.
- По оценке команды, инструмент ежедневно экономит десятки часов рабочего времени специалистов Data Office и пользователей платформы данных.
Функции, которые выросли из реальных запросов аналитиков и менеджеров:
- Поиск нужных данных среди тысяч витрин DWH.
- Генерация валидного SQL и ClickHouse-кода под задачу пользователя.
- Ответы по внутренней документации и помощь с заявками на доступ.
DataCopilot не просто отвечает на вопросы. Он помогает ориентироваться в каталоге витрин, подсказывает, что и где хранится, как оформить доступ, и генерирует скрипты, которые можно сразу забирать в ETL-процессы.
Как это работает
Базовый RAG-прототип
Команда VK сначала собрала классический RAG, чтобы проверить идею на практике. Под капотом использовали:
- Redis — векторное хранилище.
- BERT — эмбеддер для превращения текста в вектора.
- bge-m3 — реранкер, который сортирует топ-N кандидатов по релевантности.
- LLM с tool calling — генерация финального ответа и вызов внешних инструментов.
Схема работы прототипа:
- Парсинг базы знаний.
- Разбиение на чанки и конвертация каждого чанка в эмбеддинг BERT.
- Загрузка эмбеддингов в Redis.
- При запросе пользователя — поиск по расстоянию L2 и выбор, например, 50 ближайших чанков.
- Реранкинг этих 50 фрагментов через bge-m3.
- Выбор 15 самых релевантных и сборка промпта:
ЗНАНИЯ + ЗАПРОС ПОЛЬЗОВАТЕЛЯ. - LLM генерирует ответ, при необходимости вызывает инструменты.
Этот подход заработал, но упёрся в три проблемы:
- Масштабируемость. В монолитной схеме сложно менять отдельные логические цепочки. Любая доработка промптов или логики легко ломает другие сценарии.
- Смешение задач в одном агенте. Когда один агент одновременно:
- ищет таблицы,
- пишет SQL,
- лезет в документацию, он перегружается контекстом. Растёт риск:
- выбрать нерелевантные таблицы,
- сгенерировать синтаксически неверные функции,
- перепутать домены знаний.
- Лишний контекст в промптах. Для генерации SQL не нужно знать правила форматирования ответа. Для поиска витрины не нужен подробный синтаксис SQL. Всё это попадало в один системный промпт и засоряло контекстное окно, ухудшая качество ответов.
Переход к роевой архитектуре
Решение — разнести функциональность по независимым агентам и наладить их взаимодействие. Для этого команда использовала LangGraph и его паттерн Swarm.
Что даёт Swarm-подход:
- Нет жёсткой иерархии «начальник–подчинённый», как в Supervisor-паттерне.
- Каждый агент — узкий эксперт со своим системным промптом и набором инструментов.
- Агенты общаются между собой, передают контекст и результаты, последовательно решая части сложного запроса.
Команда агентов
VK описывает четыре ключевые роли (часть из них в тексте раскрыта явно, часть — по смыслу архитектуры):
-
Support (Оркестратор)
- Переводит запрос пользователя в понятные системе намерения.
- Классифицирует запрос: поиск данных, генерация кода, вопрос по документации или комбинированный сценарий.
- Декомпозирует сложные задачи на шаги и решает, какого агента подключить.
- Хранит большой системный промпт, в котором описано поведение всей системы и правила взаимодействия агентов.
-
Data Search (Сыщик)
- Ищет путь к нужной витрине в DWH.
- Работает поверх корпоративного каталога данных с помощью RAG.
- Отвечает на вопросы вида: «Где лежат данные по X?», «Какую витрину использовать для Y?».
-
Code Generation (Разработчик)
- Генерирует SQL и ClickHouse-скрипты под задачу пользователя.
- Получает от Data Search информацию о таблицах и колонках.
- Следит за синтаксисом и корректностью запросов.
-
Docs QA (Документовед)
- Отвечает на вопросы по внутренней документации.
- Помогает заполнить заявки на доступ, разобраться в регламентах и особенностях витрин.
Как проходит типичный сложный сценарий:
- Пользователь пишет: «Найди таблицу с данными по X, напиши запрос с условием Y и объясни синтаксис функций, которые ты использовал».
- Support понимает, что это комбинированный запрос, и разбивает его на три шага:
- поиск витрины;
- генерация SQL;
- объяснение синтаксиса.
- Data Search через RAG находит подходящую витрину и возвращает её описание.
- Code Generation получает название витрины и условия, пишет SQL/ClickHouse-код.
- Docs QA по документации и/или встроенным знаниям объясняет, какие функции использованы и как они работают.
- Support собирает всё в единый, понятный пользователю ответ.
Каждый агент видит только нужный ему кусок контекста и инструкции. Это снижает шум в промптах и повышает предсказуемость поведения.
Что это значит для вас
Когда DataCopilot полезен
Подход VK хорошо ложится на задачи компаний, у которых:
- есть крупное DWH с тысячами витрин;
- много аналитиков, продуктовых менеджеров и разработчиков, которые регулярно:
- спрашивают у Data Office, где лежат нужные данные;
- просят «накидать запрос» под задачу;
- не могут быстро найти ответ в сложной внутренней документации.
Практические сценарии:
- Оперативный поиск витрин: «Мне нужны ежедневные DAU по продукту Z за полгода — какую таблицу брать?»
- Автогенерация SQL/ClickHouse для ETL-процессов и разовых задач.
- Самообслуживание вместо очереди в поддержку: часть типовых вопросов к Data Office и разработчикам платформы уходит в DataCopilot.
- Обучение новичков: быстрее понять, как устроено хранилище, куда смотреть и как правильно запросить доступ.
С точки зрения бизнеса это даёт:
- разгрузку инженеров Data Office и разработчиков DWH от рутинных запросов;
- сокращение времени от вопроса «где взять данные» до готового запроса;
- более предсказуемую работу с проприетарными данными внутри закрытого контура.
Где подход не сработает
Мультиагентная архитектура может быть избыточной, если:
- у вас маленькое хранилище и один-два ключевых датасета;
- нет развитой внутренней документации, которую нужно искать и интерпретировать;
- объём вопросов к data-команде небольшой, и проще отвечать вручную.
В таком случае достаточно простого RAG-бота или даже статического FAQ.
Доступность и инфраструктура
DataCopilot — внутренний продукт VK для работы с корпоративными данными. Он развёрнут в закрытом контуре и работает с проприетарной информацией. Для внешних пользователей он недоступен, VPN не поможет.
Но архитектурный подход можно повторить:
- LangGraph доступен разработчикам.
- Redis, BERT, bge-m3 и LLM с tool calling — стандартный стек, который можно собрать в собственном периметре.
Место на рынке
DataCopilot — не публичный сервис, а корпоративный помощник. Сравнивать его по скорости, цене запроса или размеру контекста с GPT-4o, Claude 3 или другими коммерческими ассистентами некорректно: это разные классы продуктов.
Зато идея роевой архитектуры решает типичные проблемы классических «одиночных» RAG-ботов в больших компаниях:
- проще масштабировать систему, добавляя новых агентов под новые домены знаний, не ломая старые сценарии;
- легче контролировать поведение: промпты и инструменты изолированы, можно целенаправленно улучшать один тип задач;
- сложные запросы обрабатываются по шагам, а не одним гигантским промптом.
Для команд, которые строят ассистентов поверх своих DWH и документации, опыт VK — рабочий пример: как уйти от монолитного RAG к системе, где несколько ИИ-агентов ведут себя как команда экспертов, а не один перегруженный бот.