一次 RAG 上线翻车：从"能跑"到"能交付"的五个坑

上周给一个制造业客户交付 RAG 知识库系统。需求听起来简单：把内部技术文档喂给大模型，让产线工程师能自然语言提问。

结果上线第一天就翻车了。

坑一：文档格式比想象中脏得多

客户给了 200 多份 PDF，其中三分之一是扫描件。OCR 出来的表格全是乱码，公式变成了天书。我们用的 chunking 策略是按段落切，但技术手册的段落经常跨页，切完语义全碎。

教训：上线前必须做文档质量审计。不是看"有多少份"，而是抽样看"切完能不能读"。我们后来加了个预处理流水线：先按标题层级重组，再按语义相似度合并碎片块。

坑二：向量检索的"差不多"陷阱

用默认的 cosine 相似度，top-5 召回看起来都很相关。但实际回答时，模型经常把不同产品的参数混在一起——因为它们在向量空间里确实很近。

教训：检索后必须加一层元数据过滤。我们按产品线和文档版本加了 filter，召回精度从 62% 拉到 89%。这个改动花了半天，但省了客户两周的投诉处理。

坑三：延迟不是模型的问题

客户抱怨"问一个问题要等 15 秒"。我们第一反应是模型太慢，换了个更快的模型——还是 15 秒。

最后定位到是向量数据库的索引没建好。Milvus 默认配置在小数据集上反而比暴力搜索慢，因为索引构建本身就有开销。

教训：先 profiling，再优化。别凭直觉换模型。

坑四：用户不会用"好问题"

工程师习惯问"3号机温度异常怎么办"，但文档里写的是"设备过热故障排查流程"。语义差距导致检索不到相关内容。

教训：在检索前加一层 query rewrite。用一个小模型把用户问题改写成语料库风格，效果立竿见影。这个技巧成本极低，但 ROI 很高。

坑五：监控缺位

上线后我们没有任何使用数据。不知道哪些问答失败了，不知道用户最常问什么，不知道系统瓶颈在哪。

教训：Day 1 就要埋点。记录查询、召回结果、用户满意度（哪怕只是一个 thumbs up/down）。没有数据，优化就是盲人摸象。

总结

RAG 不是"接个 API 就完事"的技术。从文档清洗到检索优化，从延迟调优到用户行为分析，每个环节都有坑。交付不是 demo 跑通，而是系统能稳定服务真实用户。

下次再做 RAG 项目，我会把 40% 的时间花在数据质量和监控上，而不是调模型参数。