先这样答
RAG 的 Demo 一两天能搭起来，难的在后面。我认为最难的三块按顺序说。
第一是文档预处理。原始文档格式五花八门，PDF 里的表格、双栏排版，用通用解析库提出来的常是乱序文字，行列关系全丢。垃圾进垃圾出，原料烂了后面的优化全白搭。处理方案按代价分级：结构化解析库处理表格，高价值文档用视觉模型理解版面，扫描件走 OCR。生产系统里预处理的代码量往往比 RAG 核心逻辑还多。
第二是检索质量调优。召回不准的原因分散在多个环节：切分策略、Embedding 选型、查询改写，定位要靠分层指标而不是猜。还有一个高频盲区：向量检索对精确词（型号、专有名词、代码标识）效果差，生产环境通常要向量加关键词混合检索。
第三是效果评估。答案对错难系统衡量，出了问题不知道是检索的锅还是生成的锅。工程做法是拆两层：检索层看该召回的有没有进前 K，生成层用忠实度这类指标自动打分。评估建不起来，每次调整都无法验证收益。
面试官会怎么追问
- 「chunk 切大了切小了分别什么问题？」 切大了单块语义稀释、检索不准还挤上下文；切小了信息被切断，召回了也拼不出完整答案。按语义边界切加重叠窗口是常用解。
- 「查询和文档的语义鸿沟怎么解决？」 查询改写把口语转成术语、补全指代；入库时为每个 chunk 生成几个可能的提问形式一起存进去，双向靠近。
- 「为什么不把知识全微调进模型？」 知识更新频繁的场景微调成本高且更新慢，RAG 改知识库即时生效；微调适合稳定的行为模式，不适合频繁变化的事实。
回答的坑
只答「Embedding 选型最重要」。那是其中一个点，面试官要的是分层说清楚难在哪的体系感。
每个难点都只给名词不给方案，会被追问「你实际怎么解决的」时露馅。
同系列的题
—— 本题完 ——