A 社起名字真是一把好手，self service data analytics，说白了，这就是我们常说的Chat BI。
这篇文章讲了三件事：会遇到什么样的问题、如何解决、最终达到了什么样的效果。读下来，还是非常具有参考意义的。一起看看吧~
* *
本文大纲 ｜ 全文共 3930 字
•先聊聊背景：一个三年了还没解决的老问题
•第一个问题：数据基础层怎么建？
•首当其冲：建立权威数据集
•第二步：用程序代替人/Agent来守规矩
•第三步：把所有产出放进同一个代码库（Scope 里）
•第四步：把元数据当成一流产品来对待
•第二个问题：查询时到底依赖哪些数据源？
•第一层：语义层（信任度最高，简练同时也比较耗人力）
•血缘与转换图
•查询语料库（理论很美，现实打脸）
•业务上下文（最容易被忽略，但很关键）
•Skill：Agent 的"操作手册"
•最后一关：验证
•写在最后
* *
先聊聊背景：一个三年了还没解决的老问题
ChatBI 其实就是查数。我记得 2023 年大量 AI 应用涌现的时候，最先落地的就是这个场景。时间过去了三年，模型也迭代了很多版本，但这个问题依然没被解决，也依然很重要。
为什么重要？因为这个需求真的太普遍了——谁不想实时、准确、快速地查到自己关注的数据？
为什么难？A 社总结了三个难点：
•概念与实体的模糊：数据模型里有成百上千个可选项（甚至是数百万个字段），Agent 根本不知道该选哪个字段才能回答用户的问题。举个例子，统计"活跃用户数"——什么行为才算"活跃"？要不要算上欺诈用户？回溯窗口取多长？
•数据过期：数据源、业务定义、表结构天天在变，资产和 Agent 的知识慢慢就过时了，开始返回那种"看起来对、其实悄悄错了"的答案。
•检索失败：正确的信息其实就在数据模型里，标注也很完整，但搜索空间太大，Agent 就是找不到它。
我们在帮企业落地的过程中还发现一个 A 社没单独列出来的问题——脏数据，也就是数据质量本身就有问题。不过不用担心，后文里 A 社也给出了对应的解法。
那么问题来了：面对这三个难点，A 社到底是怎么逐一拆解的？
简单概括一下他们的思路：
• 数据模糊 → 建立标准的数据基础层，让数据语义干净隔离，同时建立有层次、可溯源的数据层，层层递进。
• 数据过期 → 用一套harness 标准强制维护数据。
• 检索失败 → 用标准流程来规范（标准查询流程、知识检索流程、标准查数流程）。
下面我们一层层往下看。
第一个问题：数据基础层怎么建？
既然要让 Agent 查得准，第一步该从哪下手？答案是：先把地基打好。
首当其冲：建立权威数据集
本质就是先治理一下数据。要想真正在数据查询上做到更高水平的准确率，抛弃脏、乱、差的原始数据，是绕不开的第一步。
不用想，你们公司里那些日常查询用的数据，经常被一次次无计划地修改，改得面目全非。带来的最常见问题就是——同一个指标可能在多个表里都存在，而且数值还不一样。
所以 A 社的建议很直接：先治理。治理的目标只有一个，让一个概念对应一个权威答案。
第二步：用程序代替人/Agent来守规矩
数据好不容易治理干净了，怎么保证它不再被弄乱？
一个很直白的道理 —— 如果人能自我约束，那一开始数据就不会乱成这样了，我们必须尽量替代人在维护数据中工作。
所以 A 社建议，用一段段程序来代替人、也代替 Agent（因为程序执行不会出错）。本质上就是：在对准确性要求极高的地方，用可解释的程序，替代不可靠的"人"和黑盒的"Agent"。具体落地就是工具强制路由、CI 卡审查、外加团队的强制约定。
第三步：把所有产出放进同一个代码库（Scope 里）
在一个动态、庞大的系统里，怎么才能感知到一个指标的变化？
A 社的做法是——把所有产出（建模、语义层、参考文档、看板定义）都放进同一个代码库。这相当于给人和 Agent 一个更全局的视野。建模一改，如果会破坏下游看板或某个指标定义，CI 当场就会报警，修复也在同一个 PR 里完成。
第四步：把元数据当成一流产品来对待
地基都就位之后，剩下的就是在查询过程中给 Agent 准备一张精准的地图，也就是 metadata。
可以理解成 Agent 查询过程中的"基础设施"，也是前面所有工作的关键体现。列说明、表说明、指标定义、粒度文档、取值范围、血缘、归属……这些维护好了，后面 Agent 才知道该怎么查。
第二个问题：查询时到底依赖哪些数据源？
地基建好了，那真正查询的时候，我们能依赖哪些数据源？又该怎么用？总不能一股脑全丢给 Agent 吧？
A 社给了一个按信任度从高到低，按知识复杂度由简练到全面排序的清单。
第一层：语义层（信任度最高，简练同时也比较耗人力）
语义层就是编译好的指标和维度定义。如果一个问题能干净地映射到某个已定义的指标，Agent 调一个函数就能拿到一个数字——而且是全公司每个地方都一致的那个数字。A 社的 Agent 被规则强制要求：优先用语义层。
这里有个失败的尝试值得一提：他们曾想用 LLM 从原始表和查询日志里自动生成指标定义来"引导"语义层，结果生成的定义看起来挺像样，实际上把他们想消除的那些模糊性又编码进去了。所以结论是——文档可以让 Claude 来写，但定义必须由人来拍板。
因此这个过程难以完全自动化，比较耗人力，且体量有限。
血缘与转换图
语义层肯定有极限，遇到没定义过的指标怎么办？
这时候，前面建好的结构清晰、血缘明确、依赖清楚的数据基础就格外重要了。它能让 Agent 很轻松地把"我不知道这个指标"，转变成"我知道该从哪个受治理的模型里聚合出来"。
查询语料库（理论很美，现实打脸）
多年来，很多人用 RAG 技术存储优秀案例喂给 Agent，希望它下次查询能参考历史的好案例。
结果呢？A 社说这个方案对准确率的提升不到 1%。
原因是——非结构化的检索无法把新问题映射到正确的历史案例上。啊这……我只能说，数据量限制了我的想象（他们直接给 Agent 上了几千个历史 SQL 文件做实验）。
那真正有用的做法是什么？把这些查询语料提炼成结构化的、按领域划分的参考文档和可复用的分析模式，写进 Skill。理论上，把非结构化知识做成结构化，至少能大幅提高检索和召回的准确率。所以——查询历史是用来"提炼"的原材料，不是让 Agent 直接读的真理来源。
业务上下文（最容易被忽略，但很关键）
这一层就厉害了，要接入的是整个企业的知识——索引过的文档、路线图、决策记录、组织架构，整体做成一个个知识图谱方便查询。
一个不懂业务的 Agent，只会回答"用户问了什么"，而不是"用户到底想问什么"。比如它不知道"Q2 那次发布"指的是哪个产品，不知道两个团队对同一个词的定义不一样，也不知道这个问题被问出来是因为周四要开董事会。
这个确实有用，但 scope 太大了。其实并不是每个人都需要对整个企业的决策、行动做到感知，最终还是要围绕企业里一个个具体的人来收敛。而且据我所知，打通一个个信息孤岛，有时候不仅仅是技术问题~ 😂
小结一下：以上这四类，本质上都是数据。是数据，就要用前面那套 CI 或者程序性的东西维护起来。
Skill：Agent 的"操作手册"
数据源都备齐了，那 Agent 拿到一个问题之后，该按什么顺序、用什么套路去查？这就是 Skill 要解决的事。
A 社这边需要维护两套 Skill：
知识型 Skill：核心思路是——别让模型上来就直接查原始表，因为原始表数据量往往非常大。它走的是一种"漏斗式"的渐进思想：
先语义层 → 再参考文档 → 最后才尝试原始表
尽量通过维护好语义层和参考文档，在前两层就把大部分问题解决掉。这其实就是对"检索失败"的回答——不让 Agent 在百万字段里硬搜，而是先把范围收窄到几十个精选文件。
流程型 Skill：说的是一次查询的标准步骤，比如：澄清问题 → 找到数据源（通过知识型 Skill）→ 跑查询 → 把结果交给对抗性审查子 Agent循环检验。它还打包了一堆可复用的分析模式（留存曲线、漏斗分析等），免得每次都重新造轮子。
顺便提一个惊人的数字：没有 Skill 时，Claude 的准确率在他们评测集上不超过 21%；加上 Skill 后，整体稳定在 95% 以上，某些领域甚至能到 99%。
那 Skill 写好就一劳永逸了吗？当然不是。Skill 描述的是一个天天在变的数据模型，不维护的话，几周内就会过时。A 社就眼睁睁看着离线准确率从上线时的 大约 95% 在一个月内掉到了 65%左右。
解决办法还是老一套——把 Skill 文档和转换模型放进同一个代码库，改模型的 PR 就是改文档的 PR，代码审查钩子会强制检查。现在他们大约 90% 的数据模型 PR 都在同一个 diff 里带上了 Skill 的改动。
最后一关：验证
前面做了这么多，怎么知道系统到底准不准、哪个环节还在漏？这就要靠验证了。
验证分两部分：离线批量评估和在线实时评估。
•离线评估：就是一堆问答对，类似机器学习里的离线测试。它不能告诉你线上的真实表现，但能帮你发现有没有明显的大坑。A 社还有个很妙的做法——每次有人在群里纠正 Agent，这条纠正就变成一个候选评测样本。
•在线评估：包括对抗性审查（准确率 +6%，但代价是 token +32%、延迟 +72%）、来源标注页脚（告诉你这个答案来自哪一层、数据多新、归谁管）、数据质量检查，以及一个自动巡检群聊、自动起草修复 PR 的"纠正收割"Agent。
不过在动手做验证之前，有一个问题必须先想清楚：你的受众，到底有没有辨别数据准确性的能力？
• 如果你的受众有这个辨别能力，那完全可以按我们频道一贯的想法——人机协同地去用 AI，让人来兜底。
• 但如果受众本身根本不会去判断数据的可靠性，那你才有必要去建立这一整套复杂的系统，靠系统本身把整体准确率顶上去。
写在最后
A 社最后也很实在地说：如果你从零开始，几个权威数据集 + 几十个离线评测 + 一个薄薄的知识 Skill，就能拿下大部分收益大概是 80% 的准确率；这篇文章里其他所有东西，都是在这三样建好之后才慢慢加上去的。是当你决心将系统从 80% 推向 90%+ 甚至更高时需要做的。
可以看出，为了最好的那 20% 的效果收益，我们要做的 harness 工程建设的工作量，是惊人的。而且即使是这样，也很难达到 100%，而我看国内外不少评论区都说 95% 约等于 0%， 因为要找出那 5% ，需要付出的工作，也是巨大的。
所以，还是回到那个老生常谈的问题，基于 LLM 的 AI 发展是无法做到真正的 AGI 的，我2025年年初的文章：泡沫？革命？2025年的今天，再看看这一轮AI发展有可能让我们进入AGI吗？
我们现阶段还是需要 — 人机协同。
We Evolve 共勉~
