RAG的另类思考

## 一、“准确”和“有用”是两回事

项目上线第三周，我盯着后台数据发愣。一个用户问“CNC机床主轴温度报警怎么处理”，系统从维修手册里精准找到了三段处理步骤，内容完全正确。但用户点了“无用”。

我把对话日志调出来看，发现问题的症结：系统给出的步骤里有一句“检查主轴冷却液温度传感器”，但这个用户所在车间的那台机床，三年前就改造过冷却系统，传感器型号和手册里写的完全不一样。手册是对的，但**对这个人、这台设备、这个时刻，手册是无效的。**

这不是检索精度的问题，也不是LLM生成的问题。问题是：我们把“知识库里的正确信息”等同于“用户需要的有效信息”。

企业知识库有一个和公开互联网完全不同的特性：**信息的有效性高度依赖于上下文。** 同一个设备的维修手册，对新手和老技工的有效信息完全不同；同一个流程文档，对A车间和B车间的适用性截然不同。

我们的系统没有感知上下文的能力，于是给出的“正确答案”在用户眼里就是“正确的废话”。

### 我的调整方案

在检索环节之外，增加了一层**“用户画像注入”**。

具体做法：在用户第一次使用系统时，记录三个维度的信息：
- 岗位（维修工/工艺工程师/质量检验员/生产主管）
- 负责的产线和设备型号
- 过去30天的提问历史摘要

每次用户提问时，系统先把这个用户的画像和当前问题一起送去做一次轻量级的**“问题意图-用户角色对齐”**——判断用户在当前问题下，期望的信息粒度是什么、需要的是操作步骤还是原理说明、是否需要考虑特定设备的差异。

这个对齐结果会注入到检索的权重里，也会注入到Prompt里。例如：

> “用户是维修工，提问涉及的具体设备是MC-2023型改造版，该设备的冷却系统与原手册不一致，回答时优先参考该设备的改造文档和维修日志。”

这个改动上线后，负反馈率从17%降到了11%。**回答还是那些回答，但因为“知道”了对面站的是谁，准确率没变，“有用感”上来了。**

## 二、RAG最大的敌人是“过度信任”

说一个让我后怕的事。

项目上线第二个月，系统回答了一个关于“热处理炉温度校准周期”的问题。我后来抽查时发现了一个严重问题：系统引用的那份文档是2019年的旧版校准规范，2022年公司已经更新了标准，周期从6个月改成了3个月。但旧文档没有被标记为“已废弃”，新文档和旧文档同时存在知识库里，检索时旧文档和新文档都进入了候选集，重排序后旧文档靠前——于是系统给了用户一个过时的、不符合当前安全规范的答案。

如果那个车间的操作工按照6个月的周期执行，意味着有3个月的时间，热处理炉的温度校准是逾期状态，产品可能批量报废，甚至有安全隐患。

这件事让我意识到一个更深层的危机：**RAG系统本质上是在“权威文本”和“时效文本”之间做概率选择，但用户天然会认为AI给的答案是经过“验证”的。** 系统越是流畅、自信，这种信任就越危险。

### 我的应对

第一，**知识库治理不是技术问题，是管理问题。** 我开始要求客户指定每个业务领域的“文档责任人”。任何文档入库前，必须经过责任人确认：有效性状态（当前有效/已废弃/仅供历史参考）、适用起始日期、关联的替代文档ID。这些字段一旦录入，不可由系统自动修改，必须有明确的操作日志。

第二，在检索结果传递给LLM之前，**增加一层“时效性校验”**。对于涉及“周期”“标准”“规范”“有效期”等关键词的问题，系统会强制检查引用文档的有效期状态。如果发现引用的是已废弃文档，无论相关度多高，都会被过滤器拦截。

第三，**Prompt里加了一句明确的限制：** “如果参考资料中包含了已标记为‘已废弃’或‘仅供参考’的文档，不得使用其中的内容作为回答依据。”

这三板斧下去，知识库里躺着几十份旧文档，但系统再也不会引用它们了。

## 三、为什么我不建议在RAG里做“多轮对话”

这是个和主流观点相悖的结论，但我说说理由。

在RAG系统里做多轮对话，所有人都遇到同一个问题：随着对话轮次增加，检索的query会越来越模糊。因为用户的后续问题往往是省略式的——“那它的价格呢？”“第二个方案呢？”——如果不把指代消解做好，检索就会乱套。

技术上有成熟的解决方案：把历史对话压缩成上下文摘要，或者用LLM对当前query做改写补全。很多人就是这么做的，效果也还可以。

但我遇到的实际问题是另一回事。在企业场景里，尤其是维修、质检这类一线岗位，用户和AI的交互模式根本不适合多轮对话。一个维修工站在机器前，掏出手机问一个问题，得到答案就去操作了。他不需要“继续聊”，他需要的是“这次对话能解决问题”。

我们上线的第一个版本支持多轮对话，产品经理觉得这是“AI的基本能力”。但用户根本不按这个模式用。后台数据显示：93%的对话轮次是1轮，只有7%超过2轮。而且那7%的多轮对话里，大部分是因为第一轮没答对，用户在换着方式反复问同一个问题——本质上是检索失败了，用户在做人工消歧。

结论很朴素：**不要为了展示“AI能力”而设计功能。用户想早点结束对话，而不是和AI聊天。**

### 我的调整

把默认的“多轮对话模式”改成了“单次问答模式”：
- 每次提问都是独立检索和生成
- 如果确实需要上下文，用户手动开启“关联对话”开关（使用率极低）
- 把对话历史精简为“用户身份+最近一次提问+最近一次回答摘要”，只用于极少数场景下的指代消解

对话长度降下来了，Token成本降下来了，用户满意度反而上去了。**简单就对了。**

## 四、知识闭环：比回答更重要的是“反哺”

传统的RAG系统是一个单向流程：知识库 → 检索 → 生成 → 输出答案。知识库是静态的，答案消耗知识但不产生知识。

我在项目里加了一个逆向流程：**用户对回答点了“有用”之后，系统会把这个问答对记录下来，经过人工审核后，作为新的知识条目入库。**

为什么这么做？因为**用户问的问题本身就是知识的一部分。**

举个例子：用户问“XX设备急停按钮按下去之后怎么恢复”。运维手册里可能写的是“旋转急停按钮解锁”，但不同型号的设备恢复方式不一样——有的需要旋转，有的需要提拉，有的需要先复位再旋转。新员工问这个问题，说明这个知识点在现有文档里没有被足够清晰地强调。用户的问题指出了“知识盲区”，而用户的“好问题+好答案”就形成了一个高价值的“微知识”。

我们实施了这个“知识闭环”机制三个月后，系统里20%的高频问答对来自用户贡献。这些新增的微知识大大提升了长尾问题的覆盖率。

这个机制还有一个附带的收益：**用户感觉到“我教过AI”之后，使用意愿明显提升。** 这是一种很有趣的心理效应——从“用AI”变成了“养AI”。