🧗 RAG 落地最难的地方：不是跑起来，是调好
原型一两天能搭，生产要几周。三大难点：文档预处理、检索质量、效果评估。
为什么落地比搭 Demo 难得多
🚀 Demo 很容易
一个基础 RAG Demo，一两天就能搭起来——切块、embedding、检索、生成，链路简单。
但把它调到生产可用的质量水平，往往需要几周甚至几个月的迭代。
🎯 难点在三大块
① 文档预处理：原始数据格式五花八门
② 检索质量调优：向量召回不准是天花板
③ 效果评估：答得对不对很难系统衡量
而且环环相扣，一个环节出问题影响全局。
第一难：文档预处理（地基）
📄 PDF 解析是最大的坑
pypdf 这类通用库做文本流提取，遇到带表格、双栏、嵌套的 PDF 会把顺序搞乱。
一个三列规格表（型号/内存/价格）可能被解析成一串乱码「型号内存价格iPhone 158GB5999」，行列关系全没了。
存进向量库，检索出来也是废的。
🧰 处理方案
• pdfplumber：专门处理表格
• unstructured：对不同格式专项处理
• 多模态模型（GPT-4o Vision）：对高价值文档用 Vision 理解截图——代价高几十上百倍，适合合同/财报/专利，不适合海量普通文档。
🧩 还有一堆格式坑
扫描件（要 OCR）、含图片的文档（图片信息提不出）、代码文档（代码块切坏破坏逻辑）。
每种格式都是坑——生产系统文档预处理代码量往往比 RAG 核心逻辑还多。
核心：进去是垃圾，出来的也是垃圾。地基歪了，上面 Chunking、Embedding、检索、生成再优化也难救回来。
第二难：检索质量调优（天花板）
✂️ ① Chunking 问题
chunk 切不好，问题和相关内容语义对不上。
用户问「退款流程」，但文档按产品分类组织，退款内容被切散在十几个 chunk 里，每个单独看相关度都不高。
🗣️ ② 语义鸿沟
用户口语化「这功能怎么用不了」，文档是「系统故障排查指南」，向量相似度可能不高。
解法：Query 改写，或存文档时给每个 chunk 生成几个可能的提问形式（假设性问题增强）。
🔍 ③ 精确词差
产品型号「Pro Max 256GB」、专有名词、缩写，纯向量检索往往不如 BM25。
解法：混合检索——向量和关键词各召回一批，再合并去重。
检索质量是整个 RAG 系统效果的天花板。但质量差的原因可能来自好几个地方，多个原因交织，排查费劲——这才是难点。
第三难：效果评估（最难量化）
🤔 为什么难
• 单条答案人工判断成本高、标准不一
• 端到端指标（满意度/解决率）反馈周期太长
• 出问题不知道是 Chunking 的锅、检索的锅、还是 LLM 的锅
🎯 没有量化 = 瞎猜
不知道哪个环节出问题，优化就变成瞎猜。
解法：分层评估 + 逐步排查，把问题定位到具体层。
检索层用 Hit@K：正确答案有没有出现在前 K 条。Hit@5=0.8 意思是 80% 问题对应答案都进了前 5 条，可自动化批量跑。
端到端用 RAGAs 框架打三维度分：
• Faithfulness 忠实度：有没有编造库里没有的内容
• Answer Relevancy 答案相关性：答没答非所问
• Context Recall 上下文召回率：检索内容是否覆盖回答所需全部知识
落地方法论
先把地基做扎实
文档预处理优先，PDF 表格、扫描件、复杂排版都处理干净，别让垃圾进库。
先用 Hit@K 验检索
批量跑检索层评估，快速定位是不是检索瓶颈，别急着调生成。
再用 RAGAs 验生成
端到端看 Faithfulness / Relevancy / Context Recall 三个维度，区分检索 vs 生成问题。
环环相扣、没有捷径
各环节相互影响，要分步迭代。从 60% 到 75% 靠 Prompt 就能到，75% 到 85%+ 要系统化优化。
RAG 落地最难的不是搭 Demo（一两天），而是调到生产可用（几周几月）。三大难点：文档预处理（PDF 表格/扫描件/排版，进去垃圾出来也垃圾）、检索质量调优（Chunking/语义鸿沟/精确词三因交织）、效果评估（难量化）。方法论：分层评估 + 逐步排查——先 Hit@K 定位检索层，再用 RAGAs 验生成层。
我觉得最难的不是把它跑起来，一个基础 Demo 一两天就能搭，难的是调好。工程上最头疼的有三块：第一是文档预处理，原始数据格式五花八门，PDF 的表格、图片、嵌套格式处理不好就是一堆乱码进知识库，进去垃圾出来也垃圾；第二是检索质量调优，向量召回不准是整个系统的天花板，但问题来源很多，Chunking、Embedding、Query 改写任何一个环节出问题都影响结果，排查很费劲；第三是效果评估，答案对不对很难系统衡量，不知道哪个环节出问题，优化就变瞎猜。
我用的方法是分层评估加逐步排查。先做检索层评估，不管 LLM 输出，只看该召回的文档有没有被召回到，用 Hit@K 指标，比如 Hit@5 等于 0.8 就是 80% 的问题对应答案都出现在前 5 条，这个能自动化批量跑，快速定位检索是不是瓶颈。然后再做端到端评估，用 RAGAs 框架打三个维度的分：Faithfulness 看有没有编造库外内容、Answer Relevancy 看有没有答非所问、Context Recall 看检索内容是否覆盖回答所需知识。三个指标结合基本能定位是检索层问题还是生成层问题。
最大的坑是 PDF 解析。通用库像 pypdf 主要做文本流提取，遇到带表格、双栏、嵌套的 PDF 会把内容顺序搞乱，比如一个三列规格表被解析成一串没有分隔的文字，行列关系全没了，存进向量库检索也是废的。我的处理是分情况：表格用 pdfplumber，复杂格式用 unstructured，对合同、财报这种高价值文档用多模态模型理解截图，虽然贵但值得；扫描件要做 OCR；代码文档要注意代码块切割。生产系统里这块的代码量往往比 RAG 核心逻辑还多。