一、先看清问题：企业 RAG 不是"塞个 PDF 就能答"
在多个企业 RAG 落地项目的实战中，我们把"如何把大模型变成真正可用、可信、可持续迭代的企业知识助手"这件事拆成了 6 个关键工程环节：文档解析 → 分块策略 → 向量化 → 检索优化 → 知识沉淀闭环 → 企业级工程保障。这篇文章会按这条主线，把每一环的实战经验、判断标准和常见踩坑点都摊开来讲。
很多团队一开始会把 RAG 想象成"上传文档 → 自动回答"，但真正落地时往往会撞上四类问题：
- 答非所问：明明知识库里就有，但检索不到相关内容。多数情况不是模型不够强，而是分块太大、把"答案"和"问题"切到了不同 chunk。
- 幻觉严重：模型基于"看似相关"的上下文编造内容，没有引用、无法溯源。缺的不是更长的上下文，是更准的检索和明确的拒答阈值。
- 更新滞后：业务文档每周都在变，但知识库还停留在上个月的版本。缺的不是 ETL 脚本，是回流闭环和权限管理。
- 越用越难维护：上线 3 个月后，文档库膨胀、chunk 重复、向量库漂移，回答质量不升反降。缺的是知识治理，而不是更多的 GPU。
我们的解决思路可以浓缩成一句话：把 RAG 当成一个会被持续运营的系统来建设，而不是一次性接入就能交付的功能。
二、文档解析：先把"原料"洗干净
文档解析是 RAG 流水线最容易被低估的一环。同一份 PDF，被粗暴地当字符串塞进向量库和被结构化解析之后，检索准确率可以差出 30% 以上。
我们实践下来的几个原则：
- 多格式统一管线：Word、PDF、Excel、PPT、扫描件、图片、HTML、工单、Slack 消息……不同来源走不同解析器，但输出统一为带语义角色的中间表示（标题 / 段落 / 列表 / 表格 / 代码块 / 页眉页脚），避免把版式信息全部压平成纯文本。
- 表格单独处理：表格被压成字符串是检索灾难。我们会把表格转成"标题 + 行结构"的描述，并保留原表用于回答时引用。
- 扫描件走 OCR + 版式还原：扫描 PDF 必须经过版面分析（Layout Analysis），区分"标题区 / 正文区 / 图表区"，否则 OCR 出来的内容顺序会彻底错乱。
- 元数据前置：解析阶段就把"所属部门、文档版本、生效时间、保密等级"等元数据补齐。这部分元数据后续会进入过滤召回，比"扩写 query"更有效。
三、分块策略（Chunk）：决定检索命中率的 70%
Chunk 是企业 RAG 项目里最影响最终效果的单一变量。A/B 测试数据显示：分块策略对命中率的解释力通常在 60%–80% 之间，向量模型和重排序加起来不到 20%。
3.1 父子分块（Parent-Child Chunking）
- 小 chunk（child，200–400 字）用于检索：保证语义聚焦，匹配更准。
- 大 chunk（parent，800–1500 字）用于回答：召回时定位到小 chunk，再把小 chunk 所属的完整段落交给模型生成。
这套做法兼顾了"找得准"和"答得全"，是我们对企业长文档（合同、制度、研究报告）的默认方案。
3.2 语义边界优先于固定长度
- 优先按"标题 / 小节 / 段落"切，避免把一个完整的论点切成两半。
- 同段落过长时，按"句群 + 标点 + 指代关系"做次级切分，而不是按字数硬切。
- 对话类、FAQ 类内容采用 Q-A 配对切分，不要把问题和答案拆到不同 chunk。
3.3 长度策略要按场景配置
| 场景 | 推荐 chunk 大小 | overlap |
|---|---|---|
| 政策 / 制度文档 | 400–600 字 | 10%–15% |
| 研究报告 / 论文 | 600–1000 字 | 8%–12% |
| 工单 / 对话记录 | 一问一答为一个 chunk | 0 |
| 代码片段 | 函数 / 类为粒度 | 上下文 5–10 行 |
四、向量化方案：选对 Embedding 模型比"训一个"更划算
Embedding 的核心问题不是"准不准"，而是"在我的业务语料上准不准"。
4.1 模型选型三原则
- 中文化优先：通用多语言模型在中文业务术语上的表征往往不如专用中文模型。涉及中文场景时，我们默认在 bge、m3e、text-embedding-3 系列里选型。
- 领域微调 > 通用升级：通用 Embedding 在金融、医疗、法律等垂类容易"撞墙"。如果客户愿意提供 1000–5000 条高质量正负样本对，做一次轻量级对比学习微调，性价比远高于换一个更大的模型。
- 维度不要盲目追高：1536 维并不总是比 768 维好。维度上升带来的存储和检索成本是线性的，但边际收益会快速衰减。我们建议先从 1024 维起步，根据业务反馈再调整。
4.2 向量库选型
- 千万级以下：开源 Milvus / Qdrant 即可，单机可撑住，成本可控。
- 亿级以上：考虑云原生方案，配合分片、量化、缓存。配合 Metadata 过滤（部门、版本、权限）通常比"用更强模型"更有效。
4.3 切忌"一锅炖"
不同业务线（财务、技术、人事）的语料应该建独立的向量空间，而不是把全公司文档混在一起。一个常见的反例：HR 的"年假制度"被检索匹配到业务的"年假促销方案"，员工问"我还有几天年假"时拿到错误答案。
五、检索优化：多路召回 + 重排序的工程化
光靠"向量相似度"是不够的。我们在企业 RAG 项目中始终保持一个原则：至少 3 路召回 + 1 次重排序 + 1 次上下文组装。
5.1 多路召回（Multi-Recall）
| 召回通道 | 解决的问题 | 典型权重 |
|---|---|---|
| 向量召回 | 语义模糊匹配 | 50%–60% |
| 关键词召回（BM25） | 专有名词、型号、编号 | 20%–30% |
| 图谱召回 | 实体关系、跨文档关联 | 10%–20% |
| 结构化过滤 | 部门 / 版本 / 权限 | 强制前置 |
向量召回擅长"意思对得上"，关键词召回擅长"字面对得上"，图谱召回擅长"上下游关系对得上"。没有任何单一通道能同时做好这三件事。
5.2 重排序（Rerank）
向量召回出来的 Top-50 chunk 直接交给模型，引入的噪声往往超过增益。必须做一次重排序：
- 用 Rerank 模型（bge-reranker、cohere-rerank 等）对 Top-50 重排到 Top-5。
- 同时给重排后的每个 chunk 打一个"可引用置信度"，低于阈值的内容在 Prompt 里直接标注为"仅供背景，禁止作为答案依据"。
5.3 上下文组装
- 按相关性 + 时效性综合排序，新版本覆盖旧版本。
- 加入"指代段落"：把当前 chunk 所在小节的前后文一并塞入，避免孤立。
- 强制引用：要求模型在每个结论后附
[1] [2]这样的来源标记，前端在展示时可直接跳转原文。
这一步做完，幻觉率通常能从 30%+ 降到 5% 以下。
六、知识沉淀闭环：让 RAG"越用越聪明"
一次性接入不算落地，可持续迭代才算。
6.1 数据回流
- 用户每次提问、点踩、纠正、采纳都应回流到反馈日志，作为后续微调和评估的数据源。
- 推荐"反馈即训练样本"的流水线：人工标注 → 自动对比 → 周期性微调 Embedding / Rerank。
6.2 知识治理
- 文档版本管理：旧版本默认不参与召回，仅作历史存档。
- 重复检测：定期跑一次 chunk 相似度扫描，自动合并高度重复的内容。
- 冷启动审计：每批新文档入库前，先做一次"小样本 + 模拟问答"评测，确认召回质量合格再上线。
6.3 评估体系
强烈建议建立一套离线评测集：
- 200–500 条业务高频问题。
- 人工标注标准答案 / 关键引用段落。
- 每周跑一次，监控"召回率、引用准确率、拒答率、幻觉率"四个核心指标。
七、企业级工程保障：别让 RAG 拖垮核心系统
把 RAG 放进生产环境后，它就不再是"一个 AI 功能"，而是一个有 SLA 的核心系统。这一层的工程化往往被低估：
- 稳定性：目标 SLA 99.95%（基于云舟智渡自有 MaaS 业务测算） + 多模型自动 Fallback（这一点上我们走的是统一模型路由 + 多家 MaaS 厂商容灾的方案）。
- 可观测性：每一次问答的召回链路、引用来源、模型版本、Token 成本都必须可追溯。
- 安全合规：PII 自动脱敏、全量审计日志、Input/Output 双护栏、敏感词库管理。
- 部署形态：从轻量单机版（1–50 人）到混合服务版（50–500 人），再到全本地集群版（500–5000 人），数据真不出域。
- 成本控制：AutoCost 三级路由（轻量 / 中端 / 旗舰），按问题难度自动选模型，能在不牺牲效果的前提下省 50%–83% 的 Token 成本（典型场景 60-75%）。
八、一句话总结
把"文档解析、分块策略、向量化、检索优化、知识沉淀、工程保障"这六件事当作一个持续运营的系统来建设，效果会在 3–6 个月内明显拉开差距。这也是云舟智渡 RAG 引擎在金融、政务、制造等行业生产环境验证中得出的结论。
如果你的团队正在筹备或优化企业 RAG 项目，欢迎联系我们的咨询团队，我们可以用 3 周（POC 验证）帮你把现有方案的瓶颈和改造路径摸清楚。
关于作者
云舟智渡 RAG 平台团队。专注企业级知识库、向量检索与多路召回引擎研发。服务于金融、政务、医疗、制造等多个行业。
