来源：CIO之家

在当今企业环境中，数据成为了新的生产资料，但“用数”的门槛依然存在。业务团队面临找数难、取数难的问题，往往需要排队等待数据需求响应，导致数据消费效率低下 。数据团队则疲于应付重复性的取数工作，不仅人力成本高，成就感也低 。大模型与智能体技术的发展为此提供了新的路径 。自然语言是最高效、最直接的需求表达方式 ，传统 BI 正在加速向 BI+AI 转型 。然而，构建一套真正能在企业环境中落地的 ChatBI 系统，挑战重重。

自研的抉择与核心挑战

为何选择自研？调研发现，市面上的产品在几个关键点上难以满足企业级需求。首先是准确度，测试显示它们无法达到预期。其次是数据安全，商业产品无法继承企业原有的数据权限体系，在加密和脱敏方面存在合规挑战 。自研 ChatBI 能够复用现有的数据权限，并针对多表关联、多轮追问等复杂场景持续优化，实现能力的持续进化 。但自研的道路必须直面四大核心挑战：

• 表召回难：在企业动辄十万级别的海量数据表中，如何精准识别并召回用户提问所命中的表？

• 模型幻觉：大模型不可避免地会“无中生有”，编造事实 。

• 准确率低：在复杂的真实业务场景中，ChatBI 的实际准确率往往较低

• 评测难：如何衡量系统的“好坏”？同一个问题，SQL 没有标准答案，导致准确率难以评测 。

可持续进化的 ChatBI 飞轮

要解决这些挑战，不能依赖单一技术点的突破，而应构建一个可持续进化的系统。其核心是一个由四大要素构成的 ChatBI 飞轮 ：高质量数据集、多 Agent 协同、评测反馈和用户理解 。

评测反馈：无法衡量，就无法改进 在四大要素中，评测是系统的“指南针”。无法衡量，就无法改进 。传统的评测方式，如“点赞/点踩”，互动率低且并不能真实反映准确率 。评测 SQL 本身也不可行，因为同一个问题可以有多种正确的 SQL 写法 。我们必须转变思路：评测的是结果准确性，而非 SQL 准确性 。

为此，我们构建了 ChatBI 评测 Agent 。这个 Agent 的任务是自动化执行一个不断扩充的问题集，包括回归问题集（覆盖核心数据集的上千问题）和增量问题集（来自线上用户的真实反馈和 badcase）。评测 Agent 会自动发起提问 ，获取 ChatBI 的返回结果 ，并与“预期结果”进行自动化一致性校验 。所有结果最终汇总到评测质量大盘 ，用于指导模型、Context 和知识库的调优 。这个评测机制覆盖了多轮问答、多表查询、拒绝回答等多种复杂场景 ，确保了 ChatBI 的每一次迭代都有据可依。

高质量数据集：从“表”到“数据集”的抽象

评测指明了方向，而高质量数据集 则是解决“表召回难”和“准确率”问题的基石。面对十万级的海量表 ，LLM 的上下文窗口受限 ，且企业数据表普遍存在注释不完善、枚举不明确、质量差（如测试表、临时表）、Join 关系不明确等问题 。解决方案是进行一次关键的抽象：处理数据集，而不是处理表 。

“数据集”是对表、知识和规则的核心 Context 封装 。它是一个经过精心治理的软件工程产物，“大而全不如少而精” 。我们按照业务域（如内容运营域、用户域）梳理核心业务表 ，并为其封装丰富的上下文信息：

• 表信息：包括表、字段、中英文描述、枚举值、数据时间等 。

• 知识：包括企业黑话、术语、业务说明、指标口径等 。

• 规则：包括 SQL 语法规则、时间规则、安全规则、Join 规则等

通过这种方式，我们将海量表的召回问题，转化为了在几百个高质量“数据集”中进行选择的问题，大幅降低了召回难度，并为后续的 SQL 生成提供了充足且高质量的 Context。

多智能体协同：各司其职的专业团队

有了评测的“指南针”和数据的“基石”，还需要一个强大的“执行团队”。这个团队就是多智能体（Multi-Agent）协同系统 。我们不追求“少而精”的 Agent，而是按照核心职责拆分 Agent，让每个 Agent 做到极致 。

这个协同团队各司其职 ：

• 数据集 Agent：它只做一件事，就是处理数据集 Context，并智能选择命中的数据集 。

• 改写 Agent：负责处理用户问题中的模糊表述，特别是时间语义改写（如将“本周”改写为具体的日期范围），以此提升准确性 。

• SQL Agent：它是 SQL 专家，专注于 SQL 的生成、解释、纠错和优化 。

• 用户理解 Agent：负责个性化 Memory、行为偏好和需求理解，是系统持续进化的关键 。

• 评测 Agent：如前所述，负责守护系统的准确性 。这些 Agent 还需要“手和脚”，即工具（Tools） 。这些工具必须安全高效，例如权限 Tool 必须能复用企业原有的数据权限系统 ，取数 Tool 负责跨数据源查询 ，全链路 Trace Tool 则负责追踪和反馈 Agent 的每一步行为 。

飞轮运转：一个完整的请求流程

当这套系统运转起来时，一个看似简单的用户提问，实则经历了一场精密的协同作业 。以用户提问“本周小说频道的专辑DAU趋势如何？环比？” 为例：用户提出问题 。智能改写 Agent 介入，澄清模糊概念。它会将“本周”和“环比”根据时间规则，改写为明确的日期范围，例如：“问题中‘本周’指[2025-10-20, 2025-10-23]；计算同环比时，比较周期严格按照...前一周的对照周期是[2025-10-13, 2025-10-16]” 。数据集选择 Agent 接手改写后的问题，结合用户权限、相似问题等信息，在高质量数据集中进行召回和重排 ，最终选择最相关的“专辑综合分析集” 。NL2SQL Agent 登场。它获取“专辑综合分析集”的全部 Context，包括表结构、字段知识、指标口径、Join 规则、样例等 ，并结合个性化 Memory 和会话上下文 ，生成 SQL 。生成的 SQL 经过校验和反思纠错（例如合法性、语法校验） 。取数 Tool 执行 SQL ，智能图表选择最合适的展示方式（如趋势图）并呈现给用户 。

落地的成效

这套 ChatBI 飞轮系统在落地后，取得了显著的效果。在准确率方面，单数据集（含多表、数百列）的准确率达到了 85%（人工复盘，非点赞点踩） 。在覆盖率上，核心指标覆盖超 85%，尤其是运营岗位的覆盖率达到 85% 。更重要的是效率和价值的释放。它实现了数据平权，取数效率获得百倍提升，从“找数半天找不到”变为“随时随地想问就问” 。运营人员更爱用数了，“聊着天就把活干了” 。同时，ChatBI 通过 API 和 MCP 开放能力，让其他 AI Agent 也能用自然语言消费数据，大幅降低了 AI 消费数据的门槛 。

未来，这个飞轮将继续旋转，推动企业知识库的持续治理 ，并从“人找数”向“数找人”进化 ，实现主动的数据巡检和异动推送 ，最终走向更深度的洞察分析 。

据统计，90%的数据大咖都关注了这个公众号