博客POC阶段准确率92%，上线一周跌到61%。不是模型不行，是工程侧7个坑没填。从文档解析、切片策略、向量库选型到幻觉控制与成本优化，一篇一线交付复盘。
我们2025年给一家制造企业交付知识库RAG系统。POC阶段在500份测试文档上回答准确率92%，CTO看完Demo当场拍板。上线接入全部4.2万份内部文档后，第一周准确率跌到61%——不是模型突然变笨了，是工程侧的7个问题被逐个引爆了。这篇文章把每个坑的成因和填坑方案摊开来讲。关于检索精度优化的工程细节，我们在另一篇实录里有更细的拆解。
POC阶段我们用的全是文字型PDF，解析几乎不出错。生产环境一接真实数据，问题全来了：技术规格书里的多级嵌套表格、扫描版合同里的OCR识别偏差、PPT导出PDF里嵌在SmartArt里的文字直接丢失。
我们测试了三条管线：
最终我们走了混合路线：文字型PDF走Unstructured快速通道，表格密集型走LlamaParse，扫描件先过EasyOCR再过Unstructured。这套组合拳让文档解析的整体准确率从初始的73%拉到了94%。
教训：别指望一个解析器通吃所有格式。生产环境的文档格式多样性远超POC的精选样本，必须按文档类型做路由分发。
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个百分点。
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是性价比最高的起点。
基础RAG的检索流水线是：用户Query → Embedding → 向量相似度Top-K → 拼接Context → 给LLM生成。这套朴素方案在我们的数据上召回率只有71%，意味着每10次查询就有3次漏掉了关键文档。
我们逐个叠加了三层优化，量化收益如下：
三层叠加后最终召回率93%。代价是端到端延迟从0.8秒增加到1.6秒——在可接受范围内。
POC阶段我们在System Prompt里加了"只基于提供的文档回答，不知道就说不知道"，测试时幻觉率约3%。生产环境一周内幻觉率涨到11%——原因是用户开始问"文档里没写但看起来合理"的问题，LLM就开始编。
幻觉控制的策略选择跟整体架构强相关，我们在企业知识库AI落地的3种架构方案对比里有详细展开。以下是这个项目上生效的三层防线：
三层防线上线后，线上幻觉率稳定控制在2%以内。引用溯源的额外好处是用户信任度明显提升——看到每个结论都能点回原始文档，CTO那边不再追问"这个答案靠谱吗"。
上线初期我们每月在Embedding API调用、LLM生成和向量存储上的开销加起来约1.2万元。对于一个还在试运行阶段的内部系统，这个账单让IT部门坐不住了。
降本三板斧：
最终月成本：Embedding 360元 + LLM生成约1400元 + Qdrant服务器900元 + 其他150元 ≈ 2810元。
RAG系统上线不是终点。文档持续增加、用户提问模式迁移、Embedding模型版本更新——任何一环的漂移都会缓慢拉低准确率。
我们搭了双层监控：
上线第三周，RAGAS的context recall从0.87掉到0.73。排查发现是因为新增了一批设备维修记录采用了与旧文档不同的术语体系（"故障代码" vs "错误码"），向量相似度匹配偏移了。我们补了一批同义词映射后指标回升。如果没有监控，这个问题可能几个月后才被动发现。
我们的经验是：文档量超过5000份或日均查询超过200次，就应该认真考虑向量数据库选型、切片策略优化和监控体系。5000份以下用Chroma或pgvector跑单机足够，过度设计反而拖慢迭代速度。
取决于两个变量：文档敏感性（涉密数据不建议上传第三方SaaS）和团队工程能力。如果团队有2名以上后端工程师且文档涉密，自研的长期成本更低；如果追求3周内上线且文档不涉密，可以考虑Dify或FastGPT等开源方案做二次开发，省去大量基础设施工作。
不需要追新。我们2025年用的是BGE-large-zh-v1.5，2026年初测试了BGE-M3（多语言版），在中文检索上提升不足3%，不值得全量重Embedding的成本。建议每年评估一次新模型，检索质量提升超过10%才考虑迁移。
目前业界的主流实践是"RAG为主、微调为辅"。RAG解决知识时效性和溯源问题，微调解决领域术语和输出风格的问题。我们在这个制造企业项目中只用RAG就达到了业务要求——微调的额外收益在知识库场景中并不显著，成本却高一个数量级（参考企业RAG全链路实施方案）。
RAG系统从POC到生产，差距不在模型能力，在工程细节。文档解析的格式兼容性、切片策略的按类型适配、向量库的规模拐点、检索链路的逐层优化、幻觉的多层防线、成本的分层控制、监控的持续闭环——这7个坑，每个都可能在POC阶段"看起来没问题"，但放到真实数据和真实用户面前就会逐一亮红灯。
另一个经常被低估的变量是团队能力建设——企业AI应用落地，团队配置比模型选型更关键。而基础模型路线的选择（开源 vs 闭源）是整个RAG系统的上游决策，DeepSeek V4与GPT-5.5的路线对比值得在项目启动前就搞清楚。
如果你正在做企业知识库RAG的落地规划，或者已经发现POC效果和生产效果差距巨大，可以直接联系我们，我们会根据你的文档类型和规模给出一份具体的工程化方案建议——不卖焦虑，只讲实操。