我们如何构建内部数据分析agent

大型数据和分析组织往往难以真正实现数据和洞察的自助访问。几十年来，行业试图解决这个问题，但收效甚微，如今AI为我们提供了一条可信的路径。在GitHub的规模下，为数十个产品团队提供专门的分析支持极具挑战，因此许多团队只能自行解决这一问题。尽管产品和工程团队可以利用大量有价值的产品遥测数据来做决策，但在没有数据分析师支持的情况下，确定使用哪个数据模型、哪个粒度、哪个过滤器，然后编写查询并验证结果，始终困难重重。于是，Qubot应运而生——这是我们内部基于GitHub Copilot的分析agent（代理）。Qubot允许任何Hubber（我们对GitHub员工的称呼）用自然语言询问关于GitHub数据仓库中任何数据模型的问题，并在几秒内获得答案。Qubot并非报表工具或仪表盘替代品，而是面向探索性问题，例如“哪个用户群组在此功能上留存率最高？”或“上周哪个产品对这项指标的提升贡献最大？”Qubot维护成本为零，并能帮助团队快速上手他们可能不熟悉的数据集。在这篇博文中，我们将介绍Qubot的构建方式、演变过程以及我们学到的经验。

Qubot的工作原理

该架构包含三个主要组件：用户界面、上下文层和查询引擎。

用户界面

Qubot可通过Slack、VS Code和Copilot CLI访问。Slack界面无需任何配置，也是Hubber们偏好的协作工具。当有人在Qubot Slack频道中提问时，一个Qubot实例会作为运行在github.com上的Copilot Cloud Agent被创建。答案直接显示在Slack中，用户不仅可以将结果分享给他人，还可以在线程中迭代以改进或细化问题。所有结果也会以markdown报告的形式存储在一个pull request中，用户可引用该报告来微调查询或将其用于仪表盘。对于希望体验与工作流更深度融合的用户，Qubot也支持在VS Code和Copilot CLI中使用。Qubot可通过一条命令作为插件安装，之后便可在VS Code或Copilot CLI的任何agent会话中，与用户配置的其他自定义agent、技能和工具一同使用。

上下文层

我们的数据仓库包含不同整理阶段的数据：原始事件（bronze层）、统一事实和维度（silver层），以及为特定业务用例设计的精选数据集（gold层）。上下文层采用联邦方式构建，其知识针对数据类型进行了定制。对于bronze数据，我们拥有产品团队贡献的遥测上下文，包含schema（模式）信息和元数据。对于silver数据，我们拥有数据和分析团队维护的查询示例、使用指南、强制过滤器等。对于gold数据，我们拥有拥有这些数据集的团队贡献的业务规则和指标定义。我们还利用ETL流水线，系统地用额外信号和派生元数据来丰富上下文层。上下文在运行时通过GitHub MCP Server从上下文层获取。

上下文agent

上下文层不断被跨多个仓库持久化的新知识所丰富。在GitHub，我们主要使用markdown编写文档，因此无需与多种不同工具对接。我们通过一个上下文agent简化了联邦上下文的贡献流程。团队可以通过标准化模板或引用包含相关上下文的仓库来贡献内容。然后，该agent会将这些信息摄取、组织并规范化为结构化格式，根据我们的评估，这种格式对Qubot非常有效。

评估框架

对上下文层或agent配置的每次更改在发布前都会经过评估。当有人希望用新知识丰富上下文层时，可以发起一个pull request。新上下文会经过一个离线评估框架，该框架衡量响应的准确性、找到正确答案的延迟，并在回归问题影响用户之前将其捕获。用于在结构化测试用例上评估Qubot的基准测试框架包含三个组件：

• 测试用例：一组精心策划的prompt（提示词）数据集，包含已知正确答案、ground-truth SQL和元数据（领域、难度）。
• 自动运行编排：一个脚本，通过gh agent-task create命令自动将每个测试用例作为agent任务启动，运行多个并行试验，轮询完成状态，并保存详细的JSON结果。
• 统计聚合：一个报告脚本，读取保存的结果并计算每个测试用例的指标：完成率、准确率和持续时间（平均/最小/最大）。

端到端流程为：定义测试用例 → 每个用例运行Qubot N次 → 收集结果 → 聚合统计 → 比较配置。

查询引擎

Qubot通过一个MCP服务器连接到Kusto和Trino这两个驱动GitHub大部分分析工作负载的查询引擎。我们为Trino MCP服务器开发了自定义实现，而对于Kusto，我们部署了Fabric RTI MCP Server的本地版本。Kusto速度快，非常适合对近期事件数据进行探索性查询。Trino则处理复杂连接和更深层次的历史分析。Qubot不会强迫用户选择使用哪个引擎，而是默认使用Kusto，并在问题需要时自动切换到Trino。

变化与经验

Qubot已在GitHub被广泛采用，数百名热情用户运行了数千次查询。Hubber们在数据和分析Slack频道中提问的数量大幅减少，因为他们现在可以更自主地探索数据，仅在遇到复杂问题时才寻求帮助。这也让那些从未敢涉足数据仓库的Hubber能够访问所需数据来驱动决策。这也是我们提供Slack、Copilot CLI和VS Code等多种界面的原因之一；Hubber们技术能力很强，但我们希望提供一个零门槛、零配置的选项。

我们很快发现，上下文层是增强Copilot推理能力、创建专家级分析agent的关键。在实验中，我们发现结构良好且精心整理的上下文不仅让Qubot更准确，还能将返回正确答案的速度提升三倍。这对分析工程学科有着深远影响，因为它使这类工件成为数据建模方式中的一等公民，而非事后补充。

Qubot是中心辐射式（hub-and-spoke）执行模式成功的一个罕见例子。它减轻了数据和分析团队的负担，因为产品团队负责其界面的遥测，业务团队负责其gold数据的定义。Qubot像引力一样，将所有分散的知识集中到一个能让整个GitHub受益的工具中，激励合作团队为Qubot做出贡献，而不是创建多个局限于自身领域的工具。

致谢

Qubot工程团队：Weijie Tan, Tobias Tschuemperlin, Vamsi Anamaneni 特别感谢：Yaswanth Anantharaju

原文《How we built an internal data analytics agent》首发于 The GitHub Blog。