大模型时代的数据问答：ChatBI的技术路径与实践

自2023年生成式AI应用浪潮兴起以来，ChatBI（对话式商业智能）便成为最受关注的应用场景之一。然而三年时间过去，尽管大模型能力持续演进，这一领域仍面临诸多未解难题。本文将深入探讨构建高质量ChatBI系统所需解决的核心技术挑战与可行路径，为企业落地实践提供参考。

概述

ChatBI的本质是让用户通过自然语言实时获取准确的数据洞察。看似简单的需求背后，实际上横亘着三重技术障碍：首先是概念模糊问题——数据模型中往往包含成百上千万个字段，而"活跃用户"这类看似简单的指标背后，可能涉及行为定义、用户筛选、时间窗口等多重维度的考量；其次是数据老化问题——数据源、表结构和业务定义持续变化，导致系统的知识逐渐与实际脱节，开始返回"看起来正确、实则错误"的答案；最后是检索失效问题——正确答案明明存在于数据模型中，标注也很完整，但由于搜索空间过大，Agent无法准确定位到目标信息。

基石工程：数据基础层的标准化建设

要让大模型真正做到"查得准"，首要任务是为其打造坚实的数据基础层。这包含四个递进的建设步骤： 第一步是建立权威数据集。数据治理是一切的前提——必须先清理掉那些脏乱差的原始数据，建立起一个概念对应一个权威答案的标准体系。否则同一指标在不同表中数值各异的问题，将持续困扰系统。 第二步是用程序代替人工维护。数据治理完成后，如何防止其再次被破坏？答案是让程序接管人工工作：引入工具强制路由、CI卡点审查以及团队强制约定，在准确性要求极高的环节，用可解释的程序替代不可靠的人为操作和黑盒的Agent行为。 第三步是统一代码库管理。将建模、语义层、参考文档、看板定义等所有产出纳入同一代码库管理，为人和Agent提供全局视野。当建模发生变更时，CI系统会即时检测是否破坏下游看板或指标定义，修复工作也可在同一个PR中完成。 第四步是将元数据作为一流产品来对待。元数据是Agent查询过程中的"基础设施"，包括列说明、表说明、指标定义、数据粒度、取值范围、血缘关系等。只有维护好这些信息，后续的查询工作才能有序展开。

层层递进：查询时的多层次数据源架构

数据基础层就绪后，查询阶段需要依赖一套按信任度从高到低组织的多层次数据源： 语义层处于信任度金字塔的顶端。其本质是编译好的指标和维度定义，当问题能干净地映射到某个已定义指标时，Agent调用一个函数即可获得一个数字——而且是全公司口径一致的那个数字。值得注意的是，语义层定义必须由人工审核拍板，不宜完全交由LLM自动生成，否则可能将原本想要消除的模糊性重新编码进去。 血缘与转换图是语义层的必要补充。当遇到未预定义的指标时，清晰的血缘关系和依赖结构能帮助Agent将"我不知道这个指标"转化为"我知道该从哪个受治理的模型中聚合"。 业务上下文是最容易被忽视却极为关键的一环。需要接入企业整体知识——文档、路线图、决策记录、组织架构——并构建知识图谱以支持查询。缺乏业务理解的Agent只能回答"用户问了什么"，而非"用户真正想问什么"。 Skill（技能集）是Agent的"操作手册"。知识型Skill遵循"漏斗式"渐进查询策略：先语义层、再参考文档、最后才尝试原始表，尽量将问题解决在前两层。流程型Skill则定义了标准查询步骤：澄清问题→定位数据源

持续守护：验证体系的建立与维护

无论前期建设多么完善，都需要验证体系来确保系统实际运行效果。验证分为离线批量评估与在线实时评估两个维度： 离线评估主要依赖问答对库，类似机器学习中的离线测试集。一个值得借鉴的做法是——每当用户在群聊中纠正Agent的错误时，该纠正立即成为候选评测样本，形成持续优化的闭环。 在线评估则更为复杂，包括对抗性审查（可提升准确率约6%，但代价是token消耗增加32%、延迟增加72%）、来源标注（明确答案来源、数据时效和责任归属）、数据质量检查，以及自动巡检并起草修复PR的"纠正收割"机制。 需要强调的是，Skill并非一劳永逸。若不持续维护，系统的离线准确率会在一个月内从95%跌至65%。解决方案是将Skill文档和转换模型纳入同一代码库管理，改模型的PR必须同步改文档，代码审查钩子强制执行这一规范。目前头部实践已实现约90%的数据模型PR同步携带Skill改动。

如有侵权，请联系删除。