引言
RAG（检索增强生成）在 2025-2026 年已经成为企业 AI 应用的默认架构。但在我们的 8 个企业落地项目中，真正跑通 RAG 的只有 3 个。失败案例的共性是：把 RAG 当作“模型调用问题”，而不是“系统工程问题”。
本文基于我们为制造业、金融、法律三个行业客户落地的真实经验，拆解 RAG 工程中五个最容易被忽视的关键决策。
一、文档解析：最容易被低估的瓶颈
企业的知识载体极其复杂：PDF（扫描件/文字版）、Word、Excel、PPT、邮件归档、数据库导出……我们遇到过一个客户，合同库里有 40% 是扫描件 PDF，OCR 后的文字准确率只有 78%，导致后续所有环节的数据污染。
文档解析的关键决策点：
- 扫描件 PDF：必须上专用 OCR 引擎（如 PaddleOCR、AWS Textract）。普通 PDF 解析器会把扫描件当空白处理。
- 表格数据：Excel 和 PDF 表格需要专用解析器。直接用文本提取会把表格变成“乱码字符串”。
- 版本管理：企业文档经常有“最终版”“最终版_真的”“最终版_v3”这样的命名混乱。解析前必须做文件去重和版本对齐。
我们的经验：在 RAG 项目中，文档解析和数据清洗的工作量占总工作量的 40% 以上，但往往被分配不到 10% 的预算。
二、切块策略：Chunk Size 没有“最优值”，只有“最合适的值”
Chunk size 的选择直接决定 RAG 的召回准确率。我们做了系统性对比测试：
| Chunk Size | Token 数 | 召回准确率 | 上下文完整度 | 适用场景 |
|---|---|---|---|---|
| 128 | ~100 | 82% | 低 | FAQ、定义查询 |
| 512 | ~400 | 91% | 中 | 产品文档、操作手册 |
| 1024 | ~800 | 88% | 高 | 法律合同、技术规范 |
| 2048 | ~1600 | 79% | 很高 | 长篇报告、综述 |
结论：512 token 是性价比最高的起点，但它不是万能的。法律合同需要更大的上下文保持条款完整性，FAQ 则需要更小的 chunk 做精准匹配。
进阶策略：采用“分层切块”。把文档切成“章节块（1024 token）+ 段落块（256 token）”，查询时先检索章节块定位范围，再在章节内检索段落块做 rerank。这种双层检索策略，在金融合同场景中把准确率提升了 12%。
三、Embedding 模型选型：中文场景的隐藏陷阱
很多团队默认使用 text-embedding-3-large 或 bge-large-zh，但在实际测试中，不同领域的 embedding 性能差异巨大。
我们在三个垂直领域做了 benchmark：
- 通用百科/新闻：text-embedding-3-large 得分最高。
- 技术文档/代码：CodeBERT + 领域微调的 embedding 得分比通用模型高 23%。
- 法律/金融合同：专用领域模型（如法律 embedding）的准确率比通用模型高 31%。
更关键的是：embedding 模型要和 rerank 模型对齐。如果你用 bge 做 embedding，用 Cohere Rerank 做 rerank，两者的语义空间不一致，会导致 rerank 失效。最佳实践是选择同一生态或同一厂商的 embedding + rerank 组合。
四、向量数据库：不是越快越好
我们测试了 Pinecone、Milvus、Weaviate、Qdrant 四款向量数据库在百万级文档规模下的表现：
- Pinecone：运维成本最低，但定制化能力弱，适合快速 MVP。
- Milvus：性能最强，但运维复杂度高，需要专门的 DBA 或 ML 工程师。
- Weaviate：模块化设计，内置 vectorizer 方便，但大规模下稳定性一般。
- Qdrant：Rust 实现，内存效率高，适合边缘部署或成本敏感场景。
选型时容易被忽略的点：过滤（filtering）性能。企业 RAG 几乎都需要做权限过滤（“这个用户只能看自己部门的文档”）。Pinecone 的 metadata filtering 延迟在百万级下约 120ms，而 Milvus 约 35ms——差距在并发场景下会被放大。
五、评估与监控：上线只是开始
RAG 系统上线后的性能衰减是必然的。我们监控了三个客户的 RAG 系统，发现每 30 天召回准确率平均下降 5-8%，主要原因是：
- 源文档更新但向量库未同步
- 用户提问方式变化（新术语、新业务场景）
- embedding 模型厂商升级导致向量空间漂移
必须建立的监控指标：
- Recall@5：前 5 个检索结果中是否包含正确答案。
- Rerank 分数分布：分数方差突然变大，往往意味着 embedding 空间漂移。
- 用户反馈率：“回答没用”的点击比例是系统健康度的最直接指标。
总结与互动
RAG 不是“接个 API 就能跑”的简单系统，它是数据工程、算法工程和系统工程的结合体。企业级 RAG 的核心竞争力，不在于你用多强的模型，而在于你对自有数据的工程化处理能力。
互动提问：
- 你在 RAG 落地中遇到的最大障碍是什么？是数据质量、embedding 选型还是系统集成？
- 你认为 RAG 的下一个技术突破点会是什么？多智能体检索？还是端到端的生成式知识库？
相关标签：RAG, 企业知识库, 向量数据库, AI 工程, 大模型落地
— IMAI 编辑部 | 2026-08-18