How we built an internal data analytics agent

The GitHub Blog

The GitHub Blog2026年6月19日

How we built an internal data analytics agent

8.5内容质量

TL;DR · AI 摘要

GitHub 使用 AI 构建了 Qubot，一个内部数据分析代理，可在 Slack、VS Code 和 Copilot CLI 中通过自然语言查询数据仓库。

核心要点

Qubot 通过自然语言查询 GitHub 数据仓库，无需专业数据分析师。
Qubot 支持 Slack、VS Code 和 Copilot CLI 三种访问方式。
Qubot 的架构包括用户界面、上下文层和查询引擎三部分。

结构提纲

按章节快速跳转。

§引言
大型数据分析组织面临数据和洞察难以自助访问的挑战，AI 提供了新的解决方案。
§Qubot 的作用
Qubot 是 GitHub 内部基于 Copilot 的数据分析代理，允许用户通过自然语言查询数据仓库。
§Qubot 的工作原理
Qubot 的架构包括用户界面、上下文层和查询引擎三部分，支持多种访问方式。
·用户界面
Qubot 可通过 Slack、VS Code 和 Copilot CLI 访问，支持自然语言查询和结果共享。
·上下文层
GitHub 数据仓库包含不同阶段的数据，上下文层以联邦方式构建，支持多种数据模型。
·查询引擎
查询引擎利用 Trino 和 Kusto 提供答案，支持快速查询和结果验证。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）

Qubot 架构
- 用户界面
  - Slack
  - VS Code
  - Copilot CLI
- 上下文层
  - 数据仓库（青铜、白银、黄金）
  - 联邦构建
- 查询引擎
  - Trino
  - Kusto

金句 / Highlights

值得收藏与分享的关键句。

Qubot 允许任何 Hubber 用自然语言查询 GitHub 数据仓库，并在几秒钟内得到答案。
— 第 3 段
⬇︎ 下载 PNG 𝕏 分享到 X
Qubot 不是报表工具或仪表板的替代品，而是用于探索性问题，如用户保留率和产品对指标的影响。
— 第 4 段
⬇︎ 下载 PNG 𝕏 分享到 X
Qubot 的用户界面支持 Slack、VS Code 和 Copilot CLI，提供灵活的访问方式。
— 第 5 段
⬇︎ 下载 PNG 𝕏 分享到 X

#GitHub#AI#数据分析#Copilot

打开原文

标题：我们如何构建了一个内部数据分析代理

URL 来源：https://github.blog/ai-and-ml/github-copilot/how-we-built-an-internal-data-analytics-agent/

发布时间：2026-06-19T09:00:00-07:00

Markdown 内容：大型数据和分析组织通常难以真正实现数据和洞察的自助访问。几十年来，行业一直试图解决这个问题，但都未能成功，而如今，人工智能为我们提供了一种可信的方式来实现这一点。

在 GitHub 的规模下，为数十个产品团队提供专门的分析支持是一项挑战，因此许多团队只能自行解决这个问题。尽管产品和工程团队可以使用大量有价值的产品遥测数据来做出决策，但如果没有数据分析师的支持，确定使用哪种数据模型、粒度、筛选条件，然后编写查询并验证结果一直都很困难。

于是我们引入了 Qubot，这是我们内部基于 GitHub Copilot 的分析代理。Qubot 允许任何 Hubber（这是我们对 GitHub 员工的称呼）用自然语言询问 GitHub 数据仓库中的任何数据模型，并在几秒钟内得到答案。

Qubot 不是一个报告工具或仪表板的替代品。相反，它适用于探索性问题，例如“哪个用户群体在该功能上的留存率最高？”或“上周哪个产品对这个指标的提升贡献最大？”Qubot 的维护成本为零，并帮助团队快速熟悉他们可能不熟悉的数据库。

在本文中，我们将介绍我们是如何构建 Qubot 的，它发生了哪些变化，以及我们学到了什么。

Qubot 的工作原理

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

图 1：显示 Qubot 分析代理架构的图表。上下文和用户输入到 Qubot，Qubot 参考 Trino 和 Kusto 来获取答案。

用户界面

Qubot 可通过 Slack、VS Code 和 Copilot CLI 访问。Slack 界面不需要任何配置，而且是 Hubbers 偏好的协作工具。当有人在 Qubot 的 Slack 频道中提出问题时，Qubot 实例会作为 Copilot 云代理在 github.com 上运行。答案直接在 Slack 中提供，允许用户将结果与他人分享，同时在对话线程中进行迭代，以进一步发展或完善问题。所有结果也会以 Markdown 报告的形式存储在一个拉取请求中，用户可以参考该报告以微调查询或将其用在仪表板中。

Qubot 还可在 VS Code 和 Copilot CLI 中使用，为希望与工作流程更紧密集成的用户提供了更好的体验。Qubot 可以通过一个命令作为插件安装，并在 VS Code 或 Copilot CLI 的任何代理会话中使用，与用户配置的其他自定义代理、技能和工具并列。

对于青铜级数据，我们有产品团队提供的遥测上下文，包含模式信息和元数据。
对于白银级数据，我们有数据和分析团队维护的查询示例、使用指南、强制过滤器等。
对于黄金级数据，我们有业务规则和指标定义，由负责这些数据集的团队提供。

我们还利用 ETL 管道系统地丰富上下文层，添加更多信号和派生元数据。上下文在运行时通过 GitHub MCP 服务器加载，从上下文层获取。

上下文代理

上下文层不断通过多个仓库中持久化的知识进行丰富。在 GitHub，我们主要使用 Markdown 进行文档编写，因此我们不需要与多种不同的工具进行交互。

我们通过上下文代理简化了联邦上下文贡献。团队可以通过标准化模板进行贡献，或者通过引用包含相关上下文的仓库进行贡献。代理随后会摄入、组织并规范化这些信息，形成结构化格式，根据我们的评估，这种格式对 Qubot 已经证明是有效的。

评估框架

在上下文层或代理配置发生任何更改之前，都会通过评估框架进行评估。当有人想要通过新知识丰富上下文层时，他们可以打开一个拉取请求。新的上下文会通过一个离线评估框架进行处理，该框架测量响应的准确性、找到正确答案的延迟时间，并在到达用户之前捕获回归问题。

用于在结构化测试用例中评估 Qubot 的基准框架有三个组成部分：

测试用例：一组经过精心挑选的提示数据集，包含已知的正确答案、真实 SQL 语句和元数据（领域、难度）。
自动化运行编排：一个脚本，用于通过 GitHub CLI gh agent-task create 自动启动每个测试用例作为代理任务，运行多个并行试验，轮询完成状态，并保存详细的 JSON 结果。
统计聚合：一个报告脚本，读取保存的结果并计算每个测试用例的指标：完成率、准确性、持续时间（平均值/最小值/最大值）。

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

查询引擎

Qubot 通过 MCP 服务器连接到 Kusto 和 Trino，这两个查询引擎支持 GitHub 大部分的分析工作负载。我们为 Trino 开发了自定义的 MCP 服务器实现，而对 Kusto，我们部署了 Fabric RTI 的本地版本 MCP 服务器。Kusto 运行速度快，适合对最近事件数据进行探索性问题分析。Trino 能够处理复杂的连接和更深入的历史分析。

Qubot 默认使用 Kusto，而不是强制用户了解应该使用哪一个，当问题需要时，Qubot 会自动切换到 Trino。

有哪些变化，以及我们学到了什么

Qubot 已经在 GitHub 上得到了广泛应用，拥有数百名热情的用户运行着数千个查询。在数据和分析的 Slack 频道中，Hubbers 提出的问题数量大幅减少，因为他们现在可以更自主地探索数据，只有在遇到复杂问题时才会寻求帮助。这也让那些从未敢接触数据仓库的 Hubbers 能够访问他们需要的数据，以支持他们的决策过程。这也是我们提供多种接口（如 Slack、Copilot CLI 和 VS Code）的原因之一；Hubbers 非常技术化，但我们希望提供一个零门槛、无需配置的选项。

我们很快发现上下文层对于增强 Copilot 的推理能力以及创建专家分析代理至关重要。在我们的实验中发现，结构良好且精心整理的上下文不仅使 Qubot 更加准确，而且返回正确答案的速度也快三倍。这对分析工程领域有深远的影响，因为它使这种类型的工件成为数据建模中的一等公民，而不是一个事后考虑的事项。

Qubot 是一个成功实施“中心-分支”模式的罕见例子。它减轻了数据和分析团队的负担，因为产品团队负责各自领域的遥测数据，而业务团队负责定义其黄金数据。Qubot 作为一种引力，将这些分散的知识集中到一个工具中，使所有 GitHub 用户都能受益，并激励合作团队为 Qubot 做出贡献，而不是创建仅限于各自领域内的多个工具。