我们2025年给一家制造企业交付知识库RAG系统。POC阶段在500份测试文档上回答准确率92%，CTO看完Demo当场拍板。上线接入全部4.2万份内部文档后，第一周准确率跌到61%——不是模型突然变笨了，是工程侧的7个问题被逐个引爆了。这篇文章把每个坑的成因和填坑方案摊开来讲。关于检索精度优化的工程细节，我们在另一篇实录里有更细的拆解。
1. 文档解析：不是所有PDF都能直接喂给Embedding模型
POC阶段我们用的全是文字型PDF，解析几乎不出错。生产环境一接真实数据，问题全来了：技术规格书里的多级嵌套表格、扫描版合同里的OCR识别偏差、PPT导出PDF里嵌在SmartArt里的文字直接丢失。
我们测试了三条管线：
- LlamaParse：对复杂表格和嵌套结构还原最好，但单页平均耗时1.2秒，4.2万页跑完需要约14小时，而且API按页计费——月成本预估直奔4000元；
- Unstructured（开源版）：速度快、免费，但遇到扫描件直接抛异常，需要前置OCR管线配合；
- 自研管线：pdfplumber + Marker + EasyOCR串联，成本可控，但维护开销不小。
最终我们走了混合路线：文字型PDF走Unstructured快速通道，表格密集型走LlamaParse，扫描件先过EasyOCR再过Unstructured。这套组合拳让文档解析的整体准确率从初始的73%拉到了94%。
教训：别指望一个解析器通吃所有格式。生产环境的文档格式多样性远超POC的精选样本，必须按文档类型做路由分发。
2. 切片策略：chunk_size只是起点
POC期间我们设了chunk_size=512、overlap=64，效果不错。上线后发现同样的参数在不同文档类型上的检索命中率差异极大：技术手册的命中率还有85%，会议纪要掉到了41%。
问题出在"一刀切"。技术手册是结构化段落，512 token刚好覆盖一个完整操作步骤；会议纪要的核心信息往往散布在多个短对话轮次里，被512 token一截就断——一个问题对应三个chunk，每个chunk都缺关键上下文。
我们实测了三种策略在3000条真实查询上的效果：
| 文档类型 | 推荐方案 | chunk_size | overlap | 检索命中率 |
|---|---|---|---|---|
| 技术手册 / SOP | 固定token切分 | 512 | 64 | 87% |
| 会议纪要 / 对话记录 | 语义边界切分（按段落+发言人） | 800-1200 | 200 | 79% |
| 合同 / 法务文档 | 按条款编号切分 | 300-500 | 100 | 91% |
| FAQ / 知识条目 | 按Q&A对切分，不做额外分割 | 不限制 | 0 | 94% |
另一个被忽略的细节：元数据注入。每个chunk如果不带文档标题、章节路径、最后修改日期，检索召回后LLM缺少判断引用可信度的上下文。我们后补了metadata策略，检索相关性提升了约12个百分点。
3. 向量数据库选型：50万文档规模的实测账
POC用Chroma本地跑，完全没压力。生产环境文档量爬到50万条向量后，Chroma的查询延迟从80ms飙到2.3秒——用户已经开始投诉"搜个东西转半天"。
我们拿Milvus、Qdrant、pgvector做了同环境实测（32核CPU、128GB内存、NVMe SSD），关键数据如下：
| 指标 | Milvus 2.4 | Qdrant 1.9 | pgvector 0.7 |
|---|---|---|---|
| 50万条写入耗时 | 18分钟 | 9分钟 | 34分钟 |
| Top-10查询P99延迟 | 45ms | 38ms | 210ms |
| 过滤查询（带元数据）P99 | 62ms | 51ms | 380ms |
| 月运维成本（自建） | ~1800元 | ~900元 | ~300元（复用PG） |
| HNSW索引 | ✅ | ✅ | ✅ |
| DiskANN（磁盘索引） | ✅ | ❌ | ❌ |
| GPU加速 | ✅ | ❌ | ❌ |
我们最终选了Qdrant。不是它单项最优，而是够用+运维简单：单节点就能撑住50万规模，RocksDB做底层存储稳定，upsert比Milvus快1.5-2倍（因为不需要同步刷盘），适合我们每天增量更新3000+文档的场景（详细对比见掘金社区实测）。
pgvector的吸引力在于零额外运维——跟业务数据库共用PostgreSQL。但当向量量超过10万条且需要混合过滤查询时，延迟会明显劣化。如果你的团队已经有成熟的PG运维体系且文档量不大，pgvector是性价比最高的起点。
4. 检索增强的「最后一公里」：三招把召回率从71%抬到93%
基础RAG的检索流水线是：用户Query → Embedding → 向量相似度Top-K → 拼接Context → 给LLM生成。这套朴素方案在我们的数据上召回率只有71%，意味着每10次查询就有3次漏掉了关键文档。
我们逐个叠加了三层优化，量化收益如下：
- 多路召回（Hybrid Retrieval）：向量检索 + BM25关键词检索并行，结果合并去重。BM25对精确术语匹配（比如零件编号"SKU-8832-A"）的召回远超向量检索。单独叠加这一层，召回率从71% → 82%。
- 重排序（Reranker）：初召回Top-30候选后，用BGE-Reranker-v2-m3做精排，取Top-5给LLM。相比直接用向量相似度排序，精排后的Top-5命中率提升了9个百分点。Cohere Rerank API效果略好但成本按token计费，30万次/月调用账单约2400元；BGE-Reranker自部署基本零成本。
- HyDE（Hypothetical Document Embedding）：让LLM先根据Query生成一个假设答案，用假设答案的向量去做检索而非直接用Query向量。对抽象类问题（"这个设备为什么频繁过载？"）效果显著，召回率再提4个百分点。
三层叠加后最终召回率93%。代价是端到端延迟从0.8秒增加到1.6秒——在可接受范围内。
5. 幻觉率控制：不是加个Prompt"请如实回答"就管用
POC阶段我们在System Prompt里加了"只基于提供的文档回答，不知道就说不知道"，测试时幻觉率约3%。生产环境一周内幻觉率涨到11%——原因是用户开始问"文档里没写但看起来合理"的问题，LLM就开始编。
幻觉控制的策略选择跟整体架构强相关，我们在企业知识库AI落地的3种架构方案对比里有详细展开。以下是这个项目上生效的三层防线：
- 引用溯源（强制标注）：LLM输出每个事实句必须附带源chunk ID + 文档路径。不是"建议"，是Prompt里强制要求结构化输出格式。生成后用正则校验输出段落是否都带有引用标记，缺失的直接触发重生成。
- 置信度阈值拦截：用RAGAS的faithfulness评分做后置判断，低于0.7的回答不直接返回用户，而是降级为"我找到相关信息但不确定是否完全准确，建议你查看原始文档：[链接]"。
- 人工审核兜底：对特定高风险领域（合规条款、安全操作规范）设置为必须人工确认后才释放给终端用户。这部分查询量只占2%，但一次错误造成的影响远超审核成本。
三层防线上线后，线上幻觉率稳定控制在2%以内。引用溯源的额外好处是用户信任度明显提升——看到每个结论都能点回原始文档，CTO那边不再追问"这个答案靠谱吗"。
6. 成本控制：从月耗1.2万压到2800元
上线初期我们每月在Embedding API调用、LLM生成和向量存储上的开销加起来约1.2万元。对于一个还在试运行阶段的内部系统，这个账单让IT部门坐不住了。
降本三板斧：
- Embedding缓存：文档切片的Embedding向量只生成一次，存入向量库后不再重复调用API。系统上线时4.2万文档一次性Embedding花了约600元，之后每天增量3000条的Embedding成本降到12元/天（360元/月）。
- 分层存储：热数据（近3个月文档）存在Qdrant NVMe上、毫秒级查询；温数据（3-12个月）仍在Qdrant但关闭HNSW索引重建、查询仍可秒回；冷数据（12个月以上）归档到S3，仅在明确检索时加载。分层后Qdrant内存占用从42GB降到18GB，实例规格直接降了两档。
- 查询改写去重：我们发现约18%的用户查询是语义相同的重复问题（"XX设备怎么维护" vs "XX设备保养流程"）。加了一层查询缓存 + 语义去重后，重复查询直接返回缓存结果，LLM调用量减少了22%。
最终月成本：Embedding 360元 + LLM生成约1400元 + Qdrant服务器900元 + 其他150元 ≈ 2810元。
7. 监控与持续评估：没有闭环的系统一定会退化
RAG系统上线不是终点。文档持续增加、用户提问模式迁移、Embedding模型版本更新——任何一环的漂移都会缓慢拉低准确率。
我们搭了双层监控：
- 离线评估（每周）：用RAGAS跑四个指标——faithfulness（答案是否忠实于检索内容）、answer relevancy（答案是否切题）、context precision（检索到的内容是否相关）、context recall（相关内容是否都被检索到）。每周一份RAGAS报告，任何指标周环比下降超过5%触发告警。
- 在线监控（实时）：LangSmith追踪每条Query的完整链路——检索了哪些chunk、重排序后的Top-K、LLM的token消耗和生成耗时。设置了三个告警规则：P99延迟超过3秒、单日幻觉率超过5%、Embedding API错误率超过1%。
上线第三周，RAGAS的context recall从0.87掉到0.73。排查发现是因为新增了一批设备维修记录采用了与旧文档不同的术语体系（"故障代码" vs "错误码"），向量相似度匹配偏移了。我们补了一批同义词映射后指标回升。如果没有监控，这个问题可能几个月后才被动发现。
常见问题
Q: RAG系统建议从多大文档规模开始做工程化？
我们的经验是：文档量超过5000份或日均查询超过200次，就应该认真考虑向量数据库选型、切片策略优化和监控体系。5000份以下用Chroma或pgvector跑单机足够，过度设计反而拖慢迭代速度。
Q: 自研还是买SaaS RAG产品？
取决于两个变量：文档敏感性（涉密数据不建议上传第三方SaaS）和团队工程能力。如果团队有2名以上后端工程师且文档涉密，自研的长期成本更低；如果追求3周内上线且文档不涉密，可以考虑Dify或FastGPT等开源方案做二次开发，省去大量基础设施工作。
Q: Embedding模型多久需要换一次？
不需要追新。我们2025年用的是BGE-large-zh-v1.5，2026年初测试了BGE-M3（多语言版），在中文检索上提升不足3%，不值得全量重Embedding的成本。建议每年评估一次新模型，检索质量提升超过10%才考虑迁移。
Q: 知识库RAG和微调哪个更适合企业场景？
目前业界的主流实践是"RAG为主、微调为辅"。RAG解决知识时效性和溯源问题，微调解决领域术语和输出风格的问题。我们在这个制造企业项目中只用RAG就达到了业务要求——微调的额外收益在知识库场景中并不显著，成本却高一个数量级（参考企业RAG全链路实施方案）。
总结
RAG系统从POC到生产，差距不在模型能力，在工程细节。文档解析的格式兼容性、切片策略的按类型适配、向量库的规模拐点、检索链路的逐层优化、幻觉的多层防线、成本的分层控制、监控的持续闭环——这7个坑，每个都可能在POC阶段"看起来没问题"，但放到真实数据和真实用户面前就会逐一亮红灯。
另一个经常被低估的变量是团队能力建设——企业AI应用落地，团队配置比模型选型更关键。而基础模型路线的选择（开源 vs 闭源）是整个RAG系统的上游决策，DeepSeek V4与GPT-5.5的路线对比值得在项目启动前就搞清楚。
如果你正在做企业知识库RAG的落地规划，或者已经发现POC效果和生产效果差距巨大，可以直接联系我们，我们会根据你的文档类型和规模给出一份具体的工程化方案建议——不卖焦虑，只讲实操。
参考资料
- 向量数据库选型：Milvus vs Elasticsearch vs PgVector 生产环境实测 — 掘金社区，2026年5月
- 产品经理AI落地实战：企业RAG全链路实施方案 — 人人都是产品经理，2026年4月
- Python向量数据库的Milvus/Qdrant/Weaviate对比 — PHP中文网，2026年2月
- 一文吃透RAG：从原理到优化，解决大模型幻觉与时效性 — CSDN，2026年2月