## 一、“准确”和“有用”是两回事项目上线第三周我盯着后台数据发愣。一个用户问“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”。
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”。
