《GitHub 如何构建内部数据分析智能体 Qubot》

导语

Natalie Guevara 介绍了 GitHub 内部的 Qubot：一个由 GitHub Copilot 驱动的数据分析智能体。它要解决的是大型数据团队长期没能真正解决的问题：让产品和工程团队不用等待专职分析师，也能用自然语言探索数据仓库。Qubot 不替代报表或仪表盘，而是回答探索性问题，例如哪个用户群体留存最高、哪个产品上周最推动某项指标。它的关键不是“把自然语言变成 SQL”这么简单，而是把界面、上下文层、查询引擎、评估框架和团队协作机制连成一套内部自助分析系统。

1. GitHub 为什么需要 Qubot

• 在 GitHub 的规模下，数据与分析团队很难为几十个产品团队提供专属分析支持。虽然产品遥测数据很有价值，但普通产品或工程团队往往不知道该选哪个数据模型、用哪个粒度、加什么过滤条件，也不容易写出查询并验证结果。
• Qubot 允许任何 Hubber，也就是 GitHub 员工，用自然语言询问数据仓库中的任意数据模型，并在几秒内得到答案。它尤其适合探索性问题，而不是固定看板中的周期性指标。
• 这套系统的目标还有两个现实收益：一是零维护成本地支持团队快速熟悉陌生数据集；二是把原本分散在分析师、产品团队和业务团队里的数据知识集中到一个可以复用的入口。

2. Qubot 的三段架构

2.1 用户界面：让不同工作流都能进入同一个智能体

• Qubot 的架构有三个主组件：用户界面、上下文层和查询引擎。界面层覆盖 Slack、VS Code 和 Copilot CLI。Slack 不需要配置，又是 Hubber 首选协作工具，因此是最低门槛入口。
• 当用户在 Qubot 的 Slack 频道提问时，一个 Qubot 实例会作为运行在 github.com 上的 Copilot Cloud Agent 被启动。答案直接回到 Slack，用户可以把结果分享给其他人，也可以在同一线程继续追问、细化或改变问题。
• 所有结果还会保存为一个拉取请求里的 Markdown 报告，方便用户引用、微调查询，或把它用于仪表盘。对希望更贴近开发工作流的人，Qubot 也可以用一条命令作为插件安装到 VS Code 和 Copilot CLI 的智能体会话中，与其他自定义智能体、技能和工具并列使用。

2.2 上下文层：按数据成熟度组织知识

• GitHub 的数据仓库按治理阶段分为三层：原始事件数据、统一事实和维度、面向具体业务场景的精选数据集。Qubot 的上下文层也用联合方式构建，不同数据类型配不同知识。
• 对原始事件数据，产品团队贡献遥测上下文，包括模式信息和元数据；对统一事实和维度，数据与分析团队维护查询示例、使用指引和必填过滤条件；对精选数据集，拥有这些数据集的团队贡献业务规则和指标定义。
• GitHub 还利用数据管道系统性地给上下文层补充额外信号和派生元数据。运行时，Qubot 通过 GitHub MCP Server 从上下文层加载这些信息，让智能体知道该如何理解数据模型，而不是只靠模型的通用知识猜测。

2.3 查询引擎：默认 Kusto，必要时切到 Trino

• Qubot 通过 MCP server 连接 Kusto 和 Trino，这两个查询引擎支撑了 GitHub 大部分分析工作负载。团队自定义实现了 Trino MCP server，并为 Kusto 部署了本地版本的 Fabric RTI MCP Server。
• Kusto 速度快，适合查询近期事件数据和探索性问题；Trino 更适合复杂连接和更深的历史分析。用户不需要自己判断该用哪个引擎，Qubot 默认使用 Kusto，并在问题需要时自动切换到 Trino。

3. 上下文贡献如何被工程化

• 上下文层会持续吸收跨多个仓库的新知识。GitHub 主要用 Markdown 写文档，因此 Qubot 不需要对接许多不同知识管理工具，团队可以沿用已有文档习惯。
• 为了让分布式团队贡献上下文更顺畅，GitHub 建了一个上下文智能体。团队可以通过标准模板贡献，也可以引用包含相关上下文的仓库。智能体随后会摄取、组织、规范化这些信息，变成评估中证明对 Qubot 有效的结构化格式。
• 这一步很关键，因为 Qubot 的能力依赖的不只是模型推理，还依赖上下文是否可发现、可复用、可评估。结构化上下文把数据团队平时写给人的知识，变成智能体可以稳定调用的分析资产。

4. 每次上下文和配置变更都要先评估

4.1 离线评估防止新知识带来回归

• 每一次上下文层或智能体配置变更在发布前都要评估。如果有人想补充新的上下文知识，可以开一个拉取请求；新上下文会经过离线评估框架，检查回答准确性、找到正确答案的延迟，并在影响用户前捕捉回归。

4.2 基准框架由三个部分组成

• 第一部分是测试用例：一组人工策划的提示，包含已知正确答案、真实 SQL，以及领域、难度等元数据。
• 第二部分是自动化运行编排：脚本会用 GitHub CLI 的 agent-task create 启动每个测试用例作为智能体任务，运行多轮并行试验，轮询完成状态，并保存详细 JSON 结果。
• 第三部分是统计聚合：报告脚本读取保存结果，计算每个测试用例的完成率、准确率和耗时，包括平均、最小和最大时长。完整流程是定义测试用例，按每个用例运行 Qubot N 次，收集结果，聚合统计，再比较不同配置。

5. 采用后的变化和团队协作方式

5.1 自助分析减少了分析频道里的重复问题

• Qubot 已在 GitHub 内部被广泛采用，数百名热情用户运行了数千次查询。Hubber 在数据与分析 Slack 频道里提出的问题显著减少，因为他们可以更自主地探索数据，只在复杂问题上再找分析团队。
• 多入口设计也降低了心理门槛。GitHub 员工整体很技术化，但团队仍然提供 Slack、Copilot CLI 和 VS Code 三种入口，让从未敢进入数据仓库的人也能以零配置方式访问决策所需数据。

5.2 上下文层让智能体更准，也让分析工程资产变成一等公民

• GitHub 很快发现，上下文层是增强 Copilot 推理能力、创建专家分析智能体的关键。实验显示，结构化且精心治理的上下文不仅让 Qubot 更准确，还能让它快三倍返回正确答案。
• 这对分析工程有更深含义：上下文、示例、过滤条件、业务规则和指标定义不再是建模后的附属文档，而应成为数据建模的一等公民。没有这些资产，智能体很容易在错误粒度、错误过滤条件或错误指标定义上生成看似合理的答案。

5.3 Qubot 成为 hub-and-spoke 协作的成功样本

• 作者把 Qubot 称作少见的成功 hub-and-spoke 执行案例。它减轻了数据与分析团队压力，因为产品团队继续负责自己产品面的遥测知识，业务团队继续负责精选数据集定义，而 Qubot 把这些分散知识集中到一个全 GitHub 可用的工具里。
• 这种集中不是把所有工作收归中心团队，而是给合作团队一个贡献激励：与其各自造只服务本领域的小工具，不如把知识贡献给 Qubot，让整个组织都能受益。工程团队名单包括 Weijie Tan、Tobias Tschuemperlin、Vamsi Anamaneni，特别感谢 Yaswanth Anantharaju。

思想框架

文章先提出大型数据组织的老问题：自助分析常常停在口号上，因为用户缺的不只是查询入口，还缺数据模型、粒度、过滤条件和结果验证知识。随后它按架构展开 Qubot：Slack、VS Code 和 Copilot CLI 提供低门槛入口；上下文层按原始事件、统一事实维度、精选业务数据三类组织知识；查询引擎在 Kusto 与 Trino 之间自动选择。中段把重点放到工程治理：上下文贡献由智能体规范化，任何上下文或配置变更都必须通过包含测试用例、自动运行编排和统计聚合的离线评估。最后，文章用采用结果收束：数百用户、数千查询、分析频道问题减少，以及三倍更快返回正确答案，说明自助数据分析的关键不是单个模型，而是模型、上下文、评估和组织激励共同成形。