现场共情：资料很多，答案仍靠问人
制度、产品手册、项目复盘散在网盘和群聊里。员工搜到十几个文件，却不知道哪个版本有效，于是继续问最熟悉业务的人。此时团队很容易把问题定义成“缺一个 AI 知识库”。但如果文档没有负责人、版本混乱、权限不清，RAG 只会更快地返回不可靠内容。先把任务分清：用户是要定位文件、核对原文，还是要跨文档归纳并保留引用。
判断条件：满足哪些条件才值得做 RAG？
答案常分散在多份材料中，需要比较、摘要或按角色组织，而不是只找一个标题或关键词。若用户只需打开原文，搜索通常更直接。
业务人员需要看到引用片段、文件名和版本，能够回到原文复核。不能显示证据的“流畅回答”不应进入决策流程。
首批资料有明确范围、有效版本和内容负责人；过期文档能下架，新增内容有人维护。否则应先做文档盘点。
不同部门、项目或岗位看到的内容不同，系统能够沿用现有权限或建立可审计的访问规则，而不是把全部资料放进同一个索引。
一个实用判断是：如果十个高频问题中，多数能用“关键词 + 文件筛选”稳定找到唯一原文，先把企业搜索做好；如果多数问题必须跨段落组织答案，并且使用者需要逐条核对证据，再验证 RAG。
明确不适合做的情况
核心资料主要存在员工记忆中；同一制度有多个冲突版本；资料涉及敏感权限但无法识别访问者；问题要求模型替代法务、财务或管理者作最终判断；团队没有内容维护人；只因为“别人都有聊天机器人”而没有明确任务。此时投入 RAG 会掩盖根因，也会放大错误引用和越权风险。
3 天最小动作：用真实问题选技术
找 3–5 位真实使用者，记录 20 个最近问过的问题、理想答案、应引用的文档以及不能访问的内容。不要先写功能清单。
用同一批资料分别测试普通搜索和带引用的 RAG 演示。逐题记录是否找到正确版本、引用是否支持结论、权限是否正确。
把问题分为“搜索足够、需要综合、资料缺失、权限阻塞”四类。只有需要综合且资料可治理的比例足够高，才进入小范围 PoC。
证据与成熟度边界
现有企业 RAG 案例页展示了可演示的权限、审批与引用闭环，可用于讨论系统结构和验证方法。它不能被表述为生产成功案例：目前缺少真实企业环境下的系统评测、长期内容维护记录与团队采用数据，因此不能承诺准确率、使用率或业务结果。
查看企业 RAG 可演示闭环 →