我们如何构建内部数据分析代理
我们如何构建内部数据分析代理
作为软件工程的一位主管经理，Matteo Vasirani 在 GitHub 负责产品分析与数据科学。
Qubot 是我们内部基于 Copilot 的分析代理，任何 GitHub 员工都可以用自然语言询问关于数据的问题。以下是我们在构建它时学到的东西。
大型数据与分析组织常常难以实现数据和洞察的真正自助服务。几十年来，行业曾试图解决这个问题，但收效甚微，而现在 AI 给了我们一种可靠的方法来实现这一点。
在 GitHub 的规模下，为数十个产品团队提供专门的分析支持具有挑战性，因此许多团队只能自行解决这个问题。尽管产品和工程团队可以利用大量有价值的产品遥测数据来做决策，但在没有数据分析师支持的情况下，确定使用哪个数据模型、哪个粒度、哪个过滤器，然后编写查询并验证结果，一直都很困难。
于是 Qubot 应运而生——这是我们内部基于 GitHub Copilot 的分析代理。Qubot 允许任何 Hubber（我们对 GitHub 员工的称呼）用自然语言询问关于 GitHub 数据仓库中任何数据模型的问题，并在几秒钟内得到答案。
Qubot 并非报告工具或仪表盘替代品。相反，它是为探索性问题设计的，例如“哪个用户群组在此功能上留存率最高？”或“上周哪款产品对该指标的提升贡献最大？”Qubot 维护成本为零，并能帮助团队快速上手他们可能不熟悉的数据集。
在这篇博文中，我们将介绍我们如何构建 Qubot，它经历了哪些变化，以及我们学到了什么。
该架构包含三个主要组件：用户界面、上下文层和查询引擎。
Qubot 可通过 Slack、VS Code 和 Copilot CLI 访问。Slack 界面无需任何配置，是 Hubber 首选的协作工具。当有人在 Qubot Slack 频道中发布问题时，Qubot 实例会作为运行在 github.com 上的 Copilot Cloud Agent 被生成。答案直接显示在 Slack 中，用户不仅可以与他人分享结果，还可以在线程中迭代以演变或细化问题。所有结果也会以 markdown 报告的形式存储在一个拉取请求中，用户可以参考该请求来微调查询，或将其用于仪表盘。
Qubot 也可在 VS Code 和 Copilot CLI 中使用，适合那些希望与工作流更紧密集成的用户。Qubot 可以通过一条命令作为插件安装，然后在 VS Code 或 Copilot CLI 的任何代理会话中与用户配置的其他自定义代理、技能和工具一起使用。
我们的数据仓库包含处于不同处理阶段的数据：原始事件（青铜层）、一致的事实和维度（银层），以及为特定业务用例定制的数据集（金层）。上下文层以联邦方式构建，其知识根据数据类型量身定制。
我们还利用 ETL 流水线来系统地用额外信号和衍生元数据丰富上下文层。上下文在运行时通过 GitHub MCP Server 获取，从上下文层加载。
上下文层会不断被跨多个仓库持久化存储的新知识所丰富。在 GitHub，我们主要使用 markdown 进行文档编写，因此无需与多种不同工具交互。
我们通过一个上下文代理简化了联邦上下文贡献的流程。团队可以通过标准化模板或引用包含相关上下文的仓库来贡献内容。然后，该代理会将这些信息摄取、组织并规范化成一种结构化格式，根据我们的评估，这种格式对 Qubot 非常有效。
对上下文层或代理配置的每次更改都会在发布前进行评估。当有人希望用新知识丰富上下文层时，他们可以开启一个拉取请求。新的上下文会经过一个离线评估框架，该框架衡量响应的准确性、找到正确答案的延迟，并在回归问题影响用户之前捕获它们。
用于在结构化测试用例上评估 Qubot 的基准测试框架包含三个组件：
gh agent-task create：运行多个并行试验，轮询完成状态，并保存详细的 JSON 结果。
端到端流程为：定义测试用例 → 每个用例运行 Qubot N 次 → 收集结果 → 聚合统计 → 比较配置。
Qubot 通过一个 MCP 服务器连接到 Kusto 和 Trino，这两个查询引擎支撑着 GitHub 的大部分分析工作负载。我们开发了一个 Trino MCP 服务器的自定义实现，而对于 Kusto，我们部署了 Fabric RTI MCP 服务器的本地版本。Kusto 速度快，非常适合对近期事件数据的探索性问题。Trino 则处理复杂的连接和更深层的历史分析。
Qubot 不会强迫用户知道该用哪个，而是默认使用 Kusto，并在问题需要时自动切换到 Trino。
Qubot 在 GitHub 已被广泛采用，数百名热情用户运行了数千次查询。Hubber 在数据与分析 Slack 频道中提问的数量大幅减少，因为他们现在可以更自主地探索数据，只在遇到复杂问题时才求助。这也让那些从未敢涉足数据仓库的 Hubber 能够访问他们所需的数据来推动决策。这也是我们提供 Slack、Copilot CLI 和 VS Code 多种界面的原因之一；Hubber 技术能力很强，但我们希望提供一个零入门门槛、无需任何配置的选项。
我们很快发现，上下文层是丰富 Copilot 推理能力并创建专业分析代理的关键。在我们的实验中，我们发现结构良好且精心组织的上下文不仅让 Qubot 更准确，而且使返回正确答案的速度提升了三倍。这对分析工程学科有着深远影响，因为此类制品在数据建模中成为了一等公民，而非事后才考虑。
Qubot 是成功执行中心辐射式模式的罕见例子。它减轻了数据与分析团队的压力，因为产品团队拥有各自领域的遥测数据，业务团队拥有各自金层数据的定义。Qubot 像一个引力中心，将所有分散的知识集中到一个惠及整个 GitHub 的单一工具中，激励合作团队为 Qubot 做贡献，而不是创建多个局限于自身领域的工具。