作者：Matteo Vasirani & Cynthia Joseph

排版：Alan Wang

Qubot 是我们内部基于 GitHub Copilot 打造的智能数据分析助手，它允许任何 GitHub 员工使用自然语言直接查询公司的数据。本文将分享我们在构建 Qubot 过程中积累的实践经验与思考。

大型数据与分析团队长期以来一直面临一个难题：如何真正实现数据和洞察的自助化访问。几十年来，整个行业都在尝试解决这一问题，但始终收效甚微。而如今，AI 正为这一目标提供一种真正可行的解决方案。

在 GitHub 这样的规模下，为数十个产品团队持续提供专门的数据分析支持并非易事，因此，许多团队不得不自行解决数据分析问题。虽然产品和工程团队拥有大量有价值的产品遥测数据，可用于辅助决策，但如果没有数据分析师的支持，要弄清楚应该使用哪个数据模型、选择怎样的数据粒度、应用哪些筛选条件，再编写查询并验证结果，一直都是一件困难的事情。

为了解决这一问题，我们打造了 Qubot——GitHub 内部基于 GitHub Copilot 的智能数据分析助手。Qubot 允许任何 Hubber（GitHub 对员工的内部称呼）直接使用自然语言，对 GitHub 数据仓库中的任意数据模型提出问题，并在几秒钟内获得答案。

Qubot 并不是一个报表工具，也不是仪表板的替代品。它更适用于探索式分析，例如：“哪个用户群体在这个功能上的留存率最高？”或“上周哪个产品对这一指标的变化贡献最大？”Qubot 几乎无需维护成本，还能帮助团队快速熟悉原本并不了解的数据集，大幅降低数据探索门槛。

本文将介绍我们如何构建 Qubot、它一路走来的演进过程，以及在实践过程中积累的经验与思考。

Qubot 的工作原理

Qubot 的整体架构由三个核心部分组成：用户界面、上下文层、查询引擎。

用户界面

Qubot 可通过 Slack、Visual Studio Code 和 Copilot CLI 使用。其中，Slack 无需任何额外配置，也是 GitHub 员工最常用的协作工具。当有人在 Qubot 的 Slack 频道中提出问题时，系统会在 GitHub.com 上启动一个作为 Copilot Cloud Agent 运行的 Qubot 实例。Qubot 会直接在 Slack 中返回分析结果，方便用户与团队成员共享，同时也可以继续在同一条讨论线程中追问、完善或细化问题。所有分析结果还会以 Markdown 报告的形式保存到一个 Pull Request 中，用户既可以基于该报告进一步优化查询，也可以直接将其用于仪表板等场景。

对于希望将 Qubot 更深入集成到日常开发流程中的用户，它同样支持 Visual Studio Code 和 Copilot CLI。Qubot 可以通过一条命令安装为插件，随后便可在 VS Code 或 Copilot CLI 的任意 Agent 会话中使用，与用户配置的其他自定义 Agent、Skill 和 Tool 一同协作。

上下文层

我们的数据仓库包含处于不同治理阶段的数据：

• Bronze（原始层）：原始事件数据

• Silver（标准层）：统一建模后的事实表和维度表

• Gold（业务层）：针对特定业务场景整理的数据集

Qubot 的上下文层采用联邦式架构构建，根据不同类型的数据提供相应的领域知识。

• 对于 Bronze 数据，我们提供由产品团队维护的遥测上下文，其中包含数据结构信息和元数据。

• 对于 Silver 数据，则由数据与分析团队维护查询示例、使用指南、必需的过滤条件等内容。

• 对于 Gold 数据，则由负责对应数据集的业务团队维护业务规则和指标定义。

此外，我们还借助 ETL 数据流水线，持续为上下文层补充更多辅助信号和派生元数据，不断丰富其知识体系。在运行时，Qubot 会通过 GitHub MCP Server 从上下文层动态获取并加载这些上下文信息。

上下文智能体

上下文层中的知识持续增长，并分散保存在多个代码仓库中。由于 GitHub 内部主要使用 Markdown 编写文档，因此无需对接各种不同的知识管理工具。

为了降低联邦式知识维护的门槛，我们构建了一个 Context Agent。各团队既可以通过统一模板提交上下文信息，也可以直接指定包含相关知识的代码仓库。Context Agent 会自动完成这些内容的采集、整理和标准化，并转换为一种经过实践验证、最适合 Qubot 使用的结构化格式。

评估框架

无论是修改上下文层，还是调整 Agent 配置，每一次变更在正式上线之前都会经过完整评估。当有人希望向上下文层补充新的知识时，可以直接提交 Pull Request。新的内容随后会进入离线评估框架，重点验证回答准确率、找到正确答案所需的响应时间，以及是否引入了功能回归。确保问题不会影响最终用户之后，相关改动才会正式发布。

用于评估 Qubot 的基准测试框架主要包含三个组成部分：

• 测试用例：一套精心构建的数据集，包含 Prompt、已知正确答案、Ground Truth SQL，以及元数据（如业务领域、任务难度等）。

• 自动化运行编排：通过脚本自动调用 GitHub CLI 的 gh agent-task create，将每个测试用例作为 Agent 任务执行，支持并行运行多个测试实例、轮询任务完成状态，并保存详细的 JSON 执行结果。

• 统计汇总：通过统计脚本读取保存的执行结果，计算每个测试用例的关键指标，包括完成率、准确率以及执行时长（平均值 / 最小值 / 最大值）。

整个端到端评估流程如下：定义测试用例 → 每个用例运行 Qubot N 次 → 收集执行结果 → 汇总统计指标 → 对比不同配置的效果。

查询引擎

Qubot 通过 MCP Server 同时连接 Kusto 和 Trino 两个查询引擎，它们共同支撑了 GitHub 大部分的数据分析工作负载。其中，我们为 Trino 开发了一套自定义 MCP Server 实现；对于 Kusto，则部署了 Fabric RTI MCP Server的本地版本。Kusto 查询速度快，非常适合针对近期事件数据进行探索式分析；Trino 更擅长复杂的多表关联以及长时间跨度的历史数据分析。

Qubot 并不会要求用户自行判断应该使用哪个查询引擎。默认情况下，它会优先使用 Kusto；而当问题涉及复杂分析场景时，则会自动切换到 Trino，无需用户手动干预。

MCP Server

https://learn.microsoft.com/en-us/fabric/real-time-intelligence/mcp-overview/?wt.mc_id=3reg_webpage_reactor

有哪些变化？我们又学到了什么？

Qubot 已在 GitHub 内部得到广泛采用，数百名员工积极使用它，累计发起了数千次数据查询。如今，Hubbers 在数据与分析相关 Slack 频道中提问的数量已经大幅下降，因为他们现在可以更加自主地探索数据，仅在遇到复杂问题时才需要向数据团队寻求帮助。与此同时，那些过去从未尝试直接使用数据仓库的员工，也能够借助 Qubot 获取支撑业务决策所需的数据。这也是我们同时提供 Slack、Copilot CLI 和 Visual Studio Code 等多种使用方式的重要原因之一。虽然 Hubbers 普遍具备较强的技术背景，但我们仍希望提供一种零配置、零门槛的使用体验，让任何人都能轻松上手。

我们很快发现，上下文层是提升 Copilot 推理能力、打造专业数据分析智能体的关键。在实验过程中，我们发现，结构化且经过精心治理的上下文不仅能够显著提升 Qubot 的回答准确率，还能让其找到正确答案的速度提升 3 倍。这一发现对于分析工程领域具有重要意义，因为它意味着这类上下文资产应当成为数据建模过程中的核心组成部分，而不再只是事后补充的附属文档。

Qubot 也是 GitHub 内部少见的中心辐射式协作模式成功实践。它有效减轻了数据与分析团队的工作压力：产品团队负责维护各自产品的遥测数据，业务团队负责维护各自 Gold 数据层的业务定义，而 Qubot 则像一种引力，将这些分散在各团队中的知识集中到一个统一的平台中，使整个 GitHub 都能够共享这些知识。这种模式也激励了各合作团队持续向 Qubot 贡献知识，而不是各自开发仅服务于自身业务领域的独立工具。

致谢

Qubot 工程团队：Weijie Tan、Tobias Tschuemperlin、Vamsi Anamaneni

特别感谢：Yaswanth Anantharaju