GitHub рассказал о внутреннем аналитическом агенте Qubot на базе GitHub Copilot, который позволяет сотрудникам запрашивать данные из корпоративного хранилища в свободной формулировке и получать готовые ответы за секунды. Инструмент решает задачу самообслуживания в аналитике, с которой крупные организации безуспешно пытались справиться на протяжении десятилетий.
По данным компании, Qubot освобождает продуктовые команды от необходимости постоянно привлекать аналитиков для работы с телеметрией. Раньше для получения ответа нужно было разбираться в модели данных, уровне агрегации, фильтрах и писать запрос. Теперь любой сотрудник GitHub (Hubber) может задать вопрос на естественном языке к любой модели данных в хранилище и быстро получить результат.
Qubot не заменяет отчётность и дашборды. Он рассчитан на исследовательские вопросы вроде: «какой когорт пользователей лучше всего удерживается на этой функции?» или «какой продукт сильнее всего повлиял на метрику за прошлую неделю?». При этом инструмент практически не требует сопровождения и помогает командам быстрее освоиться с новыми наборами данных.
Архитектура Qubot состоит из трёх основных компонентов: пользовательский интерфейс, контекстный слой и движок выполнения запросов. Такой подход позволил масштабировать решение на разные инструменты и источники данных, сохраняя единый механизм работы.
Qubot доступен через Slack, VS Code и Copilot CLI. Slack выбран как основной канал, поскольку это главный инструмент совместной работы в компании и не требует настройки. При публикации вопроса в канале Qubot создаёт экземпляр Copilot Cloud Agent, выполняющийся на github.com, и возвращает ответ прямо в Slack. Результаты можно обсуждать в тредах, а все ответы сохраняются в виде markdown-отчётов в pull request, чтобы дорабатывать запросы или использовать их в дашбордах.
Qubot также устанавливается как плагин в VS Code и Copilot CLI одной командой и становится доступен в любой сессии агента наряду с другими пользовательскими агентами, навыками и инструментами. Такой вариант больше подходит тем, кто предпочитает работу прямо в среде разработки или терминале.
Хранилище данных GitHub организовано по классической трёхуровневой схеме: сырьевые события (bronze), нормализованные факты и измерения (silver) и подготовленные наборы для конкретных бизнес-задач (gold). Контекстный слой для Qubot строится федеративно, с учётом типа данных и степени их подготовки.
GitHub использует ETL-пайплайны, чтобы автоматически обогащать контекст дополнительными сигналами и производными метаданными. Контекст загружается в рантайме через GitHub MCP Server, который получает данные из контекстного слоя и передаёт их в Copilot.
Контекстный слой пополняется постоянно, знания хранятся в нескольких репозиториях. В компании в основном используют markdown-документацию, поэтому Qubot почти не приходится интегрировать внешние источники и инструменты — всё уже находится в репозиториях GitHub.
Для упрощения вклада в контекст GitHub создал отдельного контекст-агента. Команды могут описывать данные по стандартизированному шаблону или указывать репозиторий с нужной документацией. Агент затем автоматически загружает, структурирует и нормализует эти сведения в формат, который показал хорошую эффективность в Qubot по результатам внутренних проверок.
Каждое изменение в контексте или конфигурации агента проходит оценку перед релизом. Чтобы добавить новые знания, сотрудник открывает pull request. Новый контент прогоняют через офлайн-фреймворк, который измеряет точность ответов, задержку при поиске и помогает выявить регрессии до того, как они повлияют на пользователей.
Бенчмарк-фреймворк для оценки Qubot на наборе структурированных тестов включает три компонента. Полный цикл выглядит так: формирование тестовых кейсов, многократный прогон Qubot по каждому сценарию, сбор результатов, агрегация статистики и сравнение конфигураций. Это позволяет объективно измерять влияние изменений.
Qubot подключается к двум основным движкам аналитических запросов в GitHub — Kusto и Trino — через MCP-сервер. Для Trino команда разработала собственную реализацию MCP, а для Kusto развернула локальную версию Fabric RTI MCP Server. Kusto используют для быстрых исследовательских запросов по свежим событиям, а Trino — для сложных join-операций и глубокой исторической аналитики.
Пользователю не нужно разбираться, какой движок подходит лучше. По умолчанию Qubot обращается к Kusto и автоматически переключается на Trino, если вопрос требует более сложной обработки или длительного исторического анализа.
По данным GitHub, Qubot уже стал рабочим стандартом для сотен сотрудников, которые выполняют через него тысячи запросов. Количество вопросов в канал аналитики в Slack резко снизилось: теперь пользователи сначала пробуют найти ответ сами и обращаются к специалистам только по сложным случаям. Такой подход также открыл доступ к данным для тех, кто раньше не работал с хранилищем напрямую.
Команда быстро пришла к выводу, что ключ к качественной работе аналитического агента — контекстный слой. В ходе экспериментов GitHub выяснил, что структурированный и хорошо подготовленный контекст не только повышает точность Qubot, но и в три раза ускоряет получение корректного ответа. Это влияет на практику аналитической инженерии, так как контекстные артефакты становятся важной частью моделирования данных, а не побочным продуктом.
Qubot в GitHub стал примером модели hub-and-spoke. Он снижает нагрузку на центральную команду данных и аналитики: продуктовые команды отвечают за телеметрию своих сервисов, а бизнес-команды — за определение своих gold-наборов. Qubot выступает «точкой притяжения», объединяя распределённые знания в одном инструменте. Это мотивирует команды вкладываться в Qubot, вместо создания разрозненных внутренних решений.
Над Qubot работала инженерная команда в составе Weijie Tan, Tobias Tschuemperlin и Vamsi Anamaneni. Руководитель направления продуктовой аналитики и data science в GitHub — Matteo Vasirani (staff manager of software engineering). Старший продакт-менеджер команды данных — Cynthia Joseph.
Источник: блог GitHub.
