技术速递｜我们如何打造一款内部智能数据分析助手
作者Matteo Vasirani Cynthia Joseph排版Alan WangQubot 是我们内部基于 GitHub Copilot 打造的智能数据分析助手它允许任何 GitHub 员工使用自然语言直接查询公司的数据。本文将分享我们在构建 Qubot 过程中积累的实践经验与思考。大型数据与分析团队长期以来一直面临一个难题如何真正实现数据和洞察的自助化访问。几十年来整个行业都在尝试解决这一问题但始终收效甚微。而如今AI 正为这一目标提供一种真正可行的解决方案。在 GitHub 这样的规模下为数十个产品团队持续提供专门的数据分析支持并非易事因此许多团队不得不自行解决数据分析问题。虽然产品和工程团队拥有大量有价值的产品遥测数据可用于辅助决策但如果没有数据分析师的支持要弄清楚应该使用哪个数据模型、选择怎样的数据粒度、应用哪些筛选条件再编写查询并验证结果一直都是一件困难的事情。为了解决这一问题我们打造了 Qubot——GitHub 内部基于 GitHub Copilot 的智能数据分析助手。Qubot 允许任何 HubberGitHub 对员工的内部称呼直接使用自然语言对 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无需用户手动干预。有哪些变化我们又学到了什么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
)
