知识库问答已死？试试把RAG改成任务型检索

企业知识库RAG几乎是每个公司都会做的一号AI项目。做的过程很一致：整理文档、切片、建向量库、接模型、上线。

结果也很一致：上线三个月，日活掉到个位数。

复盘时的归因通常是”检索不准”或”模型不行”。但真正的错位在更前面一步——方向选错了。

一、问答型检索的根本错位

大多数企业知识库RAG的设计假设是：

用户有一个问题，系统给一个答案。

这个假设在通用搜索里成立（比如”怎么泡咖啡”），在企业场景里往往不成立。

真实的企业信息需求通常是这样的：

• “这个季度的销售政策在哪份文件里，我要发给客户”
• “上次那个项目的验收标准文档是哪个版本”
• “新员工入职要签哪几张表，模板在哪下载”

这些不是”问题”，是”找东西”。 用户知道自己要找什么，他缺的不是答案，是那个文件、那份表格、那个条款。

给他一段AI总结的答案，他反而更不安心——因为他还得找到原文去确认。你不但没省他的时间，还加了一层干扰。

二、两种检索的差别

维度	问答型检索	任务型检索
用户目标	得到答案	拿到可用的材料
输出形式	一段总结的文字	文件/条款/模板+定位
成功标准	答对	用户能直接使用
错误代价	被误导	多翻一页
需要的能力	理解+生成	定位+辨别版本

关键差别在错误代价。问答型答错了会误导用户（严重），任务型找错了用户一眼就能看出来（轻微）。

这意味着任务型检索可以容忍更低的精度，但需要更强的”辨别”能力——特别是版本辨别。

三、任务型检索要解决的三个问题

问题一：版本

“最新版”是企业文档最大的陷阱。知识库里同一份制度可能有五个版本，文件名都差不多。

AI生成的答案不会告诉你”我说的是2024版还是2022版”。而任务型检索必须回答这个问题，因为用户要拿去用。

做法：

• 建立**文档家族（document family）**概念：同一主题的多个版本归为一组
• 自动识别版本号（文件名、文档内标题、修订记录页）
• 默认返回最新版，但明确标注版本和生效日期
• 提供”查看历史版本”入口

版本管理不是搜索功能，是文档治理的前置条件。 没有它，再好的检索也是在一堆过时资料里淘金。

问题二：颗粒度

用户要的可能不是整份文件，是某一页、某一条、某张表。

长文档（制度、法规、说明书）整份给出去，用户还要再翻。这时候需要的是章节级定位：

• 返回”《差旅管理制度》第三章 第2节 住宿标准”
• 提供直接跳转到该节的链接
• 同时给出原文片段

这比给全文有用。但它要求切片方式从”固定长度切”改成”按文档结构切”。

问题三：可执行性

员工找到文档之后，往往还有下一步：填表、提交、分享。

所以任务型检索的终点不是”展示内容”，是**“支持下一步动作”**：

• 附上配套模板的下载链接
• 提供”转发给同事”的卡片
• 提供”复制条款”按钮
• 对流程类文档，给出步骤清单和对应的表单链接

四、改造的四个步骤

第一步：重新定义成功指标

问答型RAG的指标是”答案准确率”。任务型检索的指标应该是：

• 首次命中率：第一个结果就是用户要的那份
• 零结果率：多少查询什么都没找到（这是最值得优化的）
• 二次操作率：用户拿到内容后是否做了下一步（下载、复制、分享）
• 查询改写率：用户搜了一次不满足，换个说法再搜

“零结果率”这个指标特别有价值。 它直接告诉你知识库缺什么内容——缺的内容补上，比优化检索算法收益大。

第二步：建设元数据

检索质量的天花板，往往由元数据决定。

必须有的字段：

• 文档类型（制度/模板/项目文档/技术文档）
• 所属部门/业务线
• 生效日期与失效日期
• 版本号
• 受众（全员/管理层/技术岗）
• 关联文档（配套的表格、说明）

有了这些，检索可以先过滤再匹配——这比纯向量相似度可靠得多，而且能回答”最新版”这类问题。

第三步：混合检索 + 结构感知切片

• 按结构切：以标题层级为主，不是固定字数
• 混合检索：关键词（BM25）+ 向量，权重根据查询类型动态调整
  • 查编号、查人名、查文件名的查询，关键词权重高
  • 查概念、查意思的查询，向量权重高
• 重排：用重排模型对前50条重排，取前5

混合检索几乎在所有企业场景里都优于纯向量检索。 因为企业查询里有大量专有名词，向量模型对这些词表现最差。

第四步：保留”搜索”界面

不要强制用户走对话。

一个带筛选器的搜索框，加一个可选的AI总结，比纯对话框实用得多。

设计上：

• 主界面是搜索结果列表（文件卡片、版本、生效日期、摘要片段）
• 每条结果有”AI 总结这一份”按钮
• 顶部有”跨多份文档总结”入口（这才是对话式的场景）

关键转变：AI从”主入口”变成”增强功能”。 用户想快就直接搜，想深就让它总结。

五、一个反直觉的建议

先别做对话。

很多企业知识库的第一步就是”做个聊天机器人”，因为演示效果好。但这会把团队的大量精力放在对话体验上（多轮管理、语气、拒答），而这些对”找东西”这件事的边际价值很低。

更好的顺序：

1. 先把搜索做对（版本、结构、混合检索）
2. 再加”对单份文档提问”（上下文明确，容易做好）
3. 最后做跨文档总结（最难，需要清晰的引用）

反过来做，你会得到一个”什么都能聊但什么都不准”的助手。

六、什么场景适合问答型

任务型检索并不适用于所有场景。这几种情况下问答型是对的：

• 事实查询：产品参数、政策数值、流程规则
• 跨文档综合：多份文档之间有关系，用户不知道在哪找
• 新人提问：他自己也不知道要找什么文档

判断标准很简单：用户来的时候，知不知道自己需要哪份文件？

• 不知道 → 问答型
• 知道 → 任务型

大部分企业内部工具，两者都该有，但默认入口应该是任务型的。

结语

RAG不是错的，RAG的方向常错。

企业知识库的核心矛盾，从来不是”AI不够聪明”，而是文档没人维护、版本混乱、找不到东西。这些问题不解决，把模型换成多强的都没用。

先做文档治理，再做检索，最后才做生成。 顺序对了，投入产出才会对。