RAG 不只是切片 + 向量：一张应用层知识地图
作者：Honlnk/鸿影
日期：2025年11月9日
标签：RAG, 向量搜索, 知识管理, 权限控制, 语义检索
引言：我曾以为 RAG 很简单
几个月前，我对 RAG（Retrieval-Augmented Generation）的理解停留在一句话：
“把文档切片，转成向量，用户提问时找最相似的几段，喂给大模型生成答案。”
听起来很清晰，对吧？但当我真正开始构建一个企业级文件管理系统时，才发现——这仅仅是冰山一角。
真正的挑战在于：
- 如何确保用户只能搜到自己有权访问的文件？
- 扫描版 PDF、会议录音、Excel 表格该怎么处理？
- 为什么有时候搜“重置密码”能找到结果，但问“怎么找回账号”却不行？
这些问题，没有一个能靠“切片 + 向量”解决。
于是，我梳理出一张 RAG 应用层知识地图，分享给同样走在落地路上的你。
一、RAG 的本质：端到端的知识服务系统
RAG 不是一个算法，而是一个工程系统。它的目标不是“炫技”，而是：
在正确的时间，把正确的知识，以正确的方式，交给正确的人。
为此，它必须覆盖从原始数据到最终答案的完整链路：
原始文件 → 内容提取 → 智能切片 → 向量化存储 → 权限感知检索 → 生成与溯源 → 用户反馈
下面，我们逐层拆解。
二、数据摄入：不是所有数据都能直接“向量化”
很多人误以为向量模型能处理任意格式。其实，只有“有意义的文本”才能被有效嵌入。
| 数据类型 | 能否直接向量化？ | 正确做法 |
|---|---|---|
| 纯文本（.txt, .md） | ✅ 是 | 直接切片 |
| PDF / Word / PPT | ⚠️ 否 | 先用专用库提取文本（注意保留标题层级） |
| Excel / CSV | ⚠️ 否 | 将行记录转为自然语言描述 |
| 图片 | ❌ 否 | 用多模态模型生成语义描述（如“会议室含白板和投影仪”） |
| 音频/视频 | ❌ 否 | 先 ASR 转文字，再处理 |
| 扫描件 PDF | ❌ 否 | 必须先 OCR |
💡 关键原则：让非文本数据“声情并茂”地变成文本，才能进入 RAG 流程。
值得注意的是，对于图片、图表、会议录像等复杂内容，单一描述往往不足以覆盖所有检索意图。此时可采用 “多视角语义化” 策略：
- 从视觉角度生成描述（“图中有柱状图，蓝色代表Q3销售额”）；
- 从业务角度补充上下文（“该图表用于2024年预算评审会”）；
- 从安全或合规角度添加标签（“画面未包含敏感信息”）。
这些不同视角的文本可分别作为独立 chunk 存入向量库，共享同一原始文件 ID。这样，无论用户从哪个角度提问，系统都有机会命中相关语义。
三、切片策略：切得好，效果翻倍
切片不是越小越好，也不是越大越好。常见策略：
- 固定长度切片（如 512 tokens）：通用，但可能切断语义；
- 按段落/标题切片：保留逻辑完整性，适合技术文档；
- 滑动窗口重叠：防止关键信息被切碎；
- LLM 辅助分块：高成本，用于合同、法律等高价值场景。
📌 建议：从“按段落 + 固定兜底”开始，后续根据 bad case 优化。
四、权限控制：RAG 的安全底线
这是企业级 RAG 最容易被忽视的一环。
两种主流方案：
| 方案 | 思路 | 适用场景 |
|---|---|---|
| 预计算 file_id 列表 | 搜索前先查用户有权访问的文件 ID，再过滤向量库 | 权限灵活、细粒度（支持临时共享） |
| 权限维度打标 | 在向量 metadata 中存 dept_id/role_id，动态匹配 | 权限静态、按部门/角色划分 |
🔐 核心原则：权限判断必须发生在检索阶段，不能依赖后端二次过滤（否则性能与安全双输）。
五、检索策略：别只靠语义向量
纯向量检索容易“过度联想”，纯关键词检索又太死板。混合检索（Hybrid Search）是生产标配。
- BM25：高级关键词匹配，擅长精确查找（如文件编号、产品型号）；
- 语义向量：理解意图，支持同义、换说法（如“找回账号” ≈ “重置密码”）；
- 融合方式：推荐使用 RRF（倒数排名融合），无需调参，效果稳定。
✅ 效果：混合检索通常比单一方法提升 10%~20% 的召回率。
六、生成与溯源：让用户信任答案
RAG 的价值不仅在于“答对”，更在于“可验证”。
- Prompt 设计：明确要求“仅基于以下资料回答，若无相关信息请说不知道”；
- 自动引用：标注答案来自哪个文件、哪一段落；
- 流式输出：提升长答案的交互体验。
七、RAG 的边界：为什么“总结全文”不是标准 RAG 能做的事？
很多用户第一次使用 RAG 系统时会问：“能不能帮我总结这篇文档？”
乍看合理，但标准 RAG 其实无法可靠完成全文总结——因为它只检索“最相关的几个片段”，而非理解整篇文档的结构与主旨。
🔍 问题根源
- RAG 的本质是 局部检索 + 局部生成；
- 总结需要 全局上下文 + 整体逻辑把握；
- 若强行把全文塞入 prompt，会超出 LLM 上下文窗口（尤其长 PDF）。
🛠️ 真实产品的解法：混合模式
观察腾讯 IMA-Copilot 和 Google NotebookLM 可发现，它们都超越了传统 RAG：
▶ 方案一：动态全文摘要（NotebookLM 风格）
- 适用于单文件或小知识库；
- 检测到“总结”意图后，绕过向量检索，直接加载全文；
- 若文档过长，则递归分块 → 分别摘要 → 再汇总；
- 客户端看到的“两个大 chunk”，其实是为覆盖全文而做的临时切分，并非用于语义检索的标准 chunks。
▶ 方案二：预生成文件级元摘要（IMA-Copilot 风格）
- 适用于企业级多文件知识库；
- 预处理阶段为每份文件生成一个 100–300 字的“元摘要”；
- 用户请求总结时，系统：
- 按权限筛选出用户可见的文件；
- 拉取这些文件的元摘要；
- 将多个摘要拼接后送入 LLM 生成综述；
- 客户端显示“参考了以下 3 份文件”，以文件为单位溯源，而非 chunks。
💡 给开发者的启示
真正可用的智能知识系统，应具备 多模式处理能力：
- 细节问答 → 标准 RAG（chunk 级）；
- 全文总结 → 全文加载或元摘要聚合（文件级）；
- 知识域综述 → 多文件元摘要融合。
可通过简单的意图识别（如检测“总结”“概述”等关键词）自动切换处理 pipeline。
✅ 记住：RAG 是工具，不是终点。智能系统的价值，在于知道何时不用 RAG。
八、持续迭代：RAG 不是一次性工程
- 构建人工测试集，定期验证效果；
- 收集用户反馈（“这个回答有帮助吗？”）；
- 用 bad case 驱动优化：是切片问题？权限问题？还是 prompt 问题？
结语：RAG 的终点是“可用”，不是“能跑”
当你能把一份扫描合同、一段会议录音、一张带表格的截图，都变成安全、准确、可追溯的知识服务时，才算真正掌握了 RAG。
而这一切，始于对“切片 + 向量”之外世界的理解。
希望这张知识地图，能帮你少走弯路，更快打造出值得信赖的智能知识系统。