衡石 RAG × ChatBI：检索增强生成如何让自然语言问数「不再胡说」

Article body

正文

6 分钟阅读

引言

大模型有一个广为人知的毛病：幻觉（Hallucination）。 问它一个它不知道的问题，它不会说「我不知道」，而是会一本正经地编造一个看似合理的答案。

在闲聊场景，幻觉最多让人尴尬一笑。但在 BI 场景，幻觉的代价可能是灾难性的——如果 ChatBI 把「销售额」理解成了「订单量」，或者把「华东区」理解成了「东部时区」，业务决策就会基于错误数据做出错误判断。

检索增强生成（Retrieval-Augmented Generation，RAG）是目前抑制大模型幻觉最有效的工程方案。 它的核心思路是：在 LLM 生成回答之前，先从知识库中检索相关上下文，把上下文注入 Prompt，让模型「看着资料回答」而不是「凭记忆回答」。

衡石 ChatBI 在最新版本中引入了完整的 RAG 增强体系，覆盖指标语义、业务术语、历史问答、数据 Schema 四个维度的知识注入。 本文将深入解析这套 RAG 体系的技术架构和工程实践。

一、ChatBI 为什么需要 RAG？

1.1 纯 LLM 问数的三大问题

不借助 RAG，直接让 LLM 做自然语言问数，会遇到三个核心问题：

问题一：领域术语理解偏差

用户问：「上个月的 ARR 是多少？」

LLM 可能不知道 ARR 是 Annual Recurring Revenue（年度经常性收入），它可能理解为 Array（数组）、或者某个字段缩写。不同企业的 ARR 计算口径还不同——有的包含试用转付费，有的不包含。

问题二：指标口径漂移

用户问：「本月 GMV 是多少？」

GMV 的定义在企业内部可能是：已支付订单金额 + 未支付订单金额 - 退款金额。但 LLM 可能直接用「订单金额」字段求和，忽略了退款扣减和未支付过滤。

问题三：Schema 理解不足

用户问：「华南区 Top 5 客户的复购率」

LLM 需要知道：哪个字段标识「华南区」？哪个字段标识「客户」？「复购率」怎么算？涉及哪些表？这些信息如果不在 Prompt 上下文中，LLM 只能猜——猜对了是运气，猜错了是事故。

1.2 RAG 的解题思路

RAG 的解法很直接：不要让模型猜，把答案线索直接递给它。

在生成回答之前，先执行一个检索流程：

把用户问题做向量化编码
在知识库中检索语义最相关的文档片段
把检索到的片段拼接到 Prompt 中
LLM 基于这些片段生成回答

关键转变：从「模型知道什么」变成「我们给模型什么」。模型的参数化知识不再是唯一依据，外部知识库成为了更可控的信息源。

二、衡石 ChatBI 的四维 RAG 架构

衡石 ChatBI 的 RAG 体系不是单一的检索管道，而是按知识类型分为四个独立检索维度，每个维度有专属的索引策略和注入方式。

2.1 维度一：指标语义知识库

知识来源：衡石指标管理平台中注册的所有指标定义。

索引内容：每个指标以结构化文档形式存储，包含：

指标名称（中英文、别名、常用缩写）
计算口径（分子逻辑、分母逻辑、过滤条件）
关联数据集（该指标从哪个数据集计算）
业务说明（指标的业务含义、使用场景、注意事项）
同义词映射（「营收」=「营业收入」=「Revenue」）

检索策略：当用户问题中包含指标相关词汇时，从指标库中检索匹配的指标定义，注入 Prompt。匹配逻辑采用「向量语义相似度 + 关键词精确匹配」的双路召回——向量检索捕获语义近似（「营收」匹配到「营业收入」），关键词匹配捕获精确缩写（「ARR」精确命中）。

注入格式：检索到的指标定义以结构化文本注入 Prompt，明确标注「以下是相关指标的定义，请严格按此口径计算」。

2.2 维度二：业务术语词典

知识来源：企业自定义的业务术语表。

很多企业有自己独特的业务概念，这些概念在通用 LLM 的训练语料中很少出现。比如：

零售企业的「坪效」（销售额 / 门店面积）
物流企业的「满载率」（实际装载量 / 车辆容量）
SaaS 企业的「NRR」（Net Revenue Retention，净收入留存率）

索引内容：每个术语包含：术语名称、定义解释、计算公式、业务上下文、关联指标。

检索策略：对用户问题做术语实体识别——检测问题中是否包含业务术语表中的词汇。如果检测到，将该术语的完整定义注入 Prompt。

特殊处理：术语检测不仅要处理精确匹配，还要处理口语化变体。比如用户说「门店效率」而非「坪效」，系统通过同义词映射仍然能识别。

2.3 维度三：历史问答库

知识来源：用户历史问答记录中标注为「正确」的交互。

当用户问了一个问题，AI 给出了正确答案（用户点击了「满意」或未做修正），这条问答被自动收录到历史问答库。这形成了一个持续增长的「正确答案样本库」。

索引内容：每条记录包含：原始问题、AI 理解的意图、生成的查询逻辑、最终结果、用户反馈。

检索策略：当新问题进来时，从历史问答库中检索语义相似的问题。如果找到高相似度的历史记录（相似度 > 0.9），直接复用历史查询逻辑，跳过 LLM 生成环节——既快又准。

注入策略：如果相似度在 0.7-0.9 之间，把历史问答作为「参考案例」注入 Prompt，引导 LLM 参考历史逻辑做适当调整。相似度低于 0.7 则不注入，避免误导。

2.4 维度四：数据 Schema 知识库

知识来源：衡石 BI 中所有数据集的元数据。

索引内容：每个数据集的 Schema 信息——字段名称、字段类型、字段含义说明、字段间关系、数据分布特征（枚举值列表、值域范围）。

检索策略：根据用户问题中提到的实体（如「客户」「订单」「产品」），检索包含这些实体的数据集 Schema。如果用户问题涉及多个实体，检索所有相关数据集并注入关联关系说明。

注入格式：Schema 信息以精简的表结构描述注入 Prompt，包含字段名、类型、含义、关联外键。对于字段数超过 50 的大宽表，只注入与当前问题相关的字段子集，避免 Prompt 过长。

三、RAG 流水线的工程细节

3.1 检索-排序-注入三阶段

衡石 ChatBI 的 RAG 流水线不是简单的「检索一次就注入」，而是经过三阶段处理：

第一阶段：多路召回

四个维度并行检索，每个维度独立返回 Top-K 候选结果
向量检索使用衡石自建的 Embedding 服务（基于 BGE-M3 模型微调）
关键词检索使用 BM25 算法做精确匹配补充
两路结果合并去重

第二阶段：重排序

对合并后的候选结果用 Cross-Encoder 模型做精排
精排模型考虑问题-文档的深层语义匹配，而非仅靠向量相似度
精排后取 Top-N（通常 N=5-10）作为最终注入内容

第三阶段：上下文组装

按 Prompt 长度预算裁剪——总注入内容不超过 4000 Token
优先保留高排序分的结果，低分结果被截断
每条注入内容标注来源类型（指标定义/术语/历史问答/Schema），帮助 LLM 区分信息层级

3.2 Embedding 模型的选型与微调

通用 Embedding 模型在 BI 场景的效果不理想——它们不理解「GMV」和「交易额」是同义词，不理解「华南」包括「广东、广西、海南」。

衡石的做法是在 BGE-M3 基础模型上做领域微调：

训练数据：从指标管理平台和业务术语表中构造正样本对（「营收」-「营业收入」为正样本），从随机搭配中构造负样本
微调方式：对比学习（Contrastive Learning），拉近正样本对距离、推远负样本对距离
效果：微调后 Embedding 在内部测试集上的 Top-5 召回率从 72% 提升到 91%

3.3 增量索引与实时更新

RAG 知识库不是静态的——新指标不断注册、新术语不断加入、历史问答持续积累。衡石的增量索引机制：

指标和术语变更触发实时索引更新（延迟 < 5 秒）
历史问答每天凌晨批量索引
Schema 变更（加字段、改类型）监听数据集元数据事件，自动触发索引更新
向量索引使用 HNSW 算法，支持高效增量插入，不需要全量重建

四、RAG 增强的效果度量

4.1 评估指标体系

RAG 的效果不能只看「AI 回答是否正确」，需要从检索和生成两个环节分别评估：

检索环节指标：

召回率（Recall@K）：相关文档是否被检索到 Top-K 中
精确率（Precision@K）：检索到的文档中有多少是真正相关的
MRR（Mean Reciprocal Rank）：相关文档的排名位置

生成环节指标：

答案准确率：AI 最终回答与标准答案的吻合度
幻觉率：AI 回答中包含与知识库矛盾的信息的比例
拒答率：AI 在知识不足时正确回答「我不知道」的比例

4.2 实测效果对比

衡石在 20 家企业客户的真实数据上做了 A/B 测试——关闭 RAG vs 开启 RAG：

指标	关闭 RAG	开启 RAG	提升幅度
答案准确率	68%	89%	+21pp
指标口径错误率	22%	4%	-18pp
Schema 误解率	15%	3%	-12pp
平均响应延迟	1.2s	1.8s	+0.6s

关键发现：RAG 带来了 21 个百分点的准确率提升，代价是增加了 0.6 秒的检索延迟。对于 BI 场景来说，这个延迟交换是值得的——准确比快更重要。

4.3 持续优化的飞轮效应

RAG 系统有一个天然的飞轮效应：用户使用越多 → 历史问答库越丰富 → 检索质量越高 → 准确率越高 → 用户使用更多。

衡石为客户提供了一个「RAG 健康度面板」，展示：

每周新增历史问答数量
历史问答复用率（有多少新问题命中了历史记录）
各维度知识库的覆盖度（指标库覆盖了多少百分比的用户问题）
幻觉率趋势

当历史问答复用率超过 30% 时，意味着 RAG 系统已经进入了良性循环——大部分问题都能从历史经验中受益。

五、RAG 落地的常见坑

坑 1：知识库质量差，垃圾进垃圾出

把未治理的指标定义直接灌入 RAG 知识库——同名字段在不同表中有不同含义、指标定义文档互相矛盾、术语解释含糊不清。RAG 检索到了「知识」，但知识本身是错的。

避坑：RAG 上线前先做知识库治理。指标定义要由业务方确认、术语表要经过评审、历史问答要人工审核后才能入库。

坑 2：Prompt 过长导致 LLM 「注意力分散」

把检索到的 20 条知识全部塞进 Prompt，总长度超过 8000 Token。LLM 在长上下文中出现「中间遗忘」现象——位于 Prompt 中间的信息被忽略。

避坑：控制注入内容的总量。衡石的做法是总注入不超过 4000 Token，按相关性排序后截断。宁可少注入，不要注入噪音。

坑 3：只做向量检索不做关键词检索

纯向量检索对精确缩写（如 ARR、NRR、ROI）的匹配效果不好——这些缩写在向量空间中的语义可能与完整短语距离较远。

避坑：双路召回——向量检索 + 关键词检索并行，结果合并。向量负责语义近似，关键词负责精确匹配。

坑 4：忽略检索结果的「负向注入」

检索到的知识不一定都是有用的——有时候检索到的指标定义与用户问题并不相关，但 LLM 仍然会参考它，导致误导。

避坑：在 Prompt 中明确标注「以下是可能相关的参考信息，请判断是否适用于当前问题」。给 LLM 「忽略不相关信息」的权限。

六、总结

RAG 不是 ChatBI 的锦上添花，而是雪中送炭。没有 RAG 的 ChatBI 是一个「聪明的猜测机器」——大部分时候猜对，但偶尔猜错，而偶尔猜错的代价在 BI 场景是不可接受的。

衡石 ChatBI 的四维 RAG 架构，核心价值在于把「模型的隐性知识」转化为「企业的显性知识」：

指标口径不再存在于人的脑子里，而是存在于可检索的知识库中
业务术语不再依赖新员工的学习曲线，而是即时注入 AI 上下文
历史问答不再是一次性消费，而是持续增值的资产

当一个 BI 系统的每一次正确回答都成为下一次正确回答的基础，这个系统就不再是一个工具，而是一个会成长的分析伙伴。