面试官：RAG 你也做了一段时间了，你觉得实际落地中最难的地方在哪？我：我觉得最难的是 Embedding 模型的选型，模型不好向量就不准，后面效果肯定差。面试官：Embedding 选型确实重要，但你说的只是其中一个小点，我想了解的是整体落地层面最难的核心问题。而且你只提到了模型这一块，那文档解析乱码、chunk 切割不合理、整体效果没法量化评估这些现实问题，你怎么看？我：没错，还有 chunk 切割也特别让人头疼，切得太大检索精准度不够，切得太小又会丢失关键上下文信息。面试官：你这样想到哪说到哪，零散罗列一堆，完全没有逻辑框架。我想问的是，你能不能站在工程落地的角度，系统性梳理清楚 RAG 落地的难点，分层有条理地讲明白。接下来我们就好好梳理一下，RAG 实际落地过程里，最让人棘手的几大核心难点。
简要回答
我认为 RAG 真正的难点，从来不是搭建基础演示版本，简单的 Demo 一两天就能搭建完成，真正难的是落地之后持续调优，达到可用的业务标准。从工程落地角度来说，最让人费心的主要有三个方面。第一就是文档预处理环节，业务场景里的原始文档格式杂乱多样，PDF 里的表格、图片、嵌套排版内容特别多，一旦处理不到位，就会产生大量乱码数据录入知识库，本质就是劣质数据入库，最终输出的答案自然也没有质量可言。第二是检索效果的调优，向量召回不准直接决定了整个 RAG 系统的效果上限，而造成这个问题的原因特别多，Chunking 划分、Embedding 选用、Query 语句改写，任意一个环节出问题，都会影响最终检索结果，排查问题的过程也十分耗费精力。第三是效果量化评估，很难有一套通用标准去判断输出答案的好坏，也没法快速定位具体是哪个环节出了故障，后续优化只能凭感觉摸索，没有明确的方向。
详细解析
第一难：文档预处理
RAG 系统的最终效果受全链路多个环节影响，文档预处理是最前置的一环，这一步要是没做好，后续不管是 Chunking 拆分、Embedding 向量化、检索匹配还是大模型生成，再完善的优化手段都没法补救，毕竟录入系统的原始数据本身就存在问题。简单来说，文档预处理不只是单一影响因素，更是整个系统的基础根基，根基没打牢，后续所有优化都是白费功夫。看着只是简单读取文档，实际落地却是最繁琐、最耗费精力的工程工作。
很多人会觉得，文档预处理不就是读取文件内容吗，没什么复杂的。真正实操就会发现，现实业务中的文档格式五花八门，复杂度远超想象。最常见的就是 PDF 解析难题，pypdf 这类常规的 PDF 工具库，核心作用只是提取文本信息流，本身并不适配复杂排版场景。一旦遇到带表格、双栏布局、多层嵌套排版的 PDF，就会打乱原有内容顺序，表格数据会被拆解成杂乱的单行文字，双栏内容也会互相混杂。这并不是 pypdf 工具本身有缺陷，而是它的定位本就不适合处理复杂版面，这类带表格和特殊排版的文档，更适合用 pdfplumber、unstructured 这类专门做结构化内容提取的工具库来处理。
举个很直观的例子，一份产品规格 PDF 原本是规整的三列布局，分别对应型号、内存、价格，每一行对应一款产品；用 pypdf 解析之后，就会变成没有任何分隔的杂乱文字，行列之间的关联关系彻底丢失。这种有问题的内容存入向量数据库之后，哪怕选用再好的 Embedding 模型，检索出来的内容也没有实际价值，劣质数据入库，最终输出的自然也是无效信息。常规的解决方式，就是选用专业的解析工具，用 pdfplumber 处理各类表格文档，用 unstructured 库针对性适配不同文件格式。如果是高价值的重要文档，还可以借助多模态模型，通过识别 PDF 截图的方式理解完整内容。不过多模态模型的调用成本，要比普通 Embedding 高出几十甚至上百倍，只适合内容复杂、价值高且数量可控的文档，像合同、财报、专利这类文件，并不适合用来处理海量普通文档。除了常规 PDF，还有扫描版文档需要做 OCR 文字识别、含大量图片的文档无法提取图中关键信息、代码文档拆分不当会破坏原有逻辑完整性等各类问题。每种文件格式都暗藏不少坑，正规生产级系统里，文档预处理相关的代码体量，往往比 RAG 核心业务逻辑还要多。
第二难：检索质量调优
做好文档预处理，只能保证输入数据的基础质量，如果检索环节出问题，前面所有的准备工作都会白费。检索精准度直接锁定了整个 RAG 系统的效果上限，要是检索不到相关核心内容，后续就算接入再强大的大模型，也没办法给出准确答案。但检索效果变差，诱因可能分布在多个环节，想要精准定位问题源头，难度特别大。
首先要排查的就是 Chunking 拆分策略，chunk 划分不合理，会导致用户的提问，和知识库中相关内容无法完成语义匹配。比如用户咨询退款相关流程，知识库文档却是按照产品类别分类整理，退款相关内容被拆分分散在十几个不同的 chunk 里，单个 chunk 的语义相关度都偏低，最终只能检索到一些无关的边缘内容。其次是用户提问和文档内容的语义差异问题，用户日常提问大多是口语化表达，而知识库留存的都是正式的业务或者专业文案。比如用户问这个功能为什么没法正常使用，文档里对应的却是系统故障排查指南这类专业表述，两者的向量相似度会偏低，直接导致正确的文档无法被检索召回。常用的解决办法就是对 Query 进行语句改写，也可以在存入文档时，为每个 chunk 提前生成多种常见提问句式一并存储，做内容增强处理。还有一个很容易被忽略的点，向量检索对专属精确词汇的匹配效果并不好。很多人误以为向量检索能适配所有搜索场景，实际并不是这样。像产品具体型号、专业专有名词、行业缩写这类内容，单纯依靠向量检索，效果远不如 BM25 关键词检索。所以生产环境中基本都会采用混合检索模式，让向量检索和关键词检索分别召回相关内容，再做合并去重处理，整体效果要比单独使用任意一种检索方式都更好。
第三难：效果评估困难
检索调优本身就足够费心，更让人无奈的是，没办法快速判断调整之后效果是变好还是变差。RAG 系统上线运行后，如何客观评判系统整体表现，这个问题远比表面看起来复杂。单条回答的对错，靠人工判断不仅成本高，每个人的评判标准还不统一。从整体业务层面看，用户满意度、问题解决率这类最终指标，反馈周期特别长，就算发现效果不好，也没法确定问题出在 Chunking 拆分、检索匹配还是大模型生成环节。工程落地里比较实用的方式，是把整体评估拆分成两个层面。
第一个层面是检索专项评估，不用考虑大模型最终输出，只判断需要召回的目标文档，有没有被成功检索出来。常用的评估指标是 Hit@K，也就是看标准答案对应的内容，是否出现在检索结果的前 K 条当中。举个例子，Hit@5 = 0.8 代表百分之八十的问题，对应的核心答案都排在检索结果前五条以内。这个指标可以批量自动化运行，能快速判断检索环节是不是系统的性能瓶颈。第二个层面是端到端整体评估，可以借助 RAGAs 这类框架自动完成打分评判。RAGAs 主要从三个维度做评估。忠实度用来判断大模型给出的答案，有没有编造知识库以外的内容，忠实度数值越高，说明模型只会基于检索到的内容作答，不会随意编造信息。答案相关性主要核对回答内容和用户问题是否匹配，避免出现答非所问的情况。上下文召回率用来衡量检索到的内容，能不能覆盖解答用户问题需要的全部知识点，这个指标偏低，就说明检索环节遗漏了关键信息。把这三个维度的指标结合起来，就能精准锁定问题到底出在检索环节，还是大模型生成环节。总的来说，RAG 落地有个很明显的感受，搭建一个基础演示版很快，一两天就能搞定，但要打磨到能正式投入业务使用的标准，往往需要好几周甚至几个月的反复迭代优化。整个链路里，文档预处理、Chunking 拆分策略、Embedding 模型选用、检索方式、重排序、提示词设计，任意一个环节做得不到位，都会拉低整体效果，而且各个环节之间还会互相影响，根本没有捷径可以走。
面试总结
回到面试官的核心问题，RAG 落地最难的从来不是单一技术选型，而是整个业务链路中每个环节都有可能成为瓶颈，并且各个环节相互关联影响。从系统层面可以归纳出三大难点，第一是文档预处理，PDF 表格、扫描文件、复杂排版内容解析难度大，劣质数据入库就注定输出不了优质答案。第二是检索质量调优，Chunking 拆分策略、语义表达差异、专属精确词汇召回这三类问题互相交织，排查和优化的难度都很大。第三是效果评估没有完善的量化体系，找不到明确的优化方向，只能盲目调整。面试回答这类问题，核心就是要有逻辑分层，搭建清晰的框架梳理难点，不要零散堆砌知识点，想到什么说什么。
