考察点
面试官不想听你背「检索+生成」的定义，他想确认你是否真的把一个 RAG 系统从文档到上线完整做过一遍，知道每个环节在哪里会翻车。回答时展现出全链路视角和 badcase 驱动的调优思路，基本就过关了。追问通常会往某个具体环节深挖：切分怎么切、召回率怎么测、幻觉怎么压、线上效果怎么监控。
参考答案
整体链路：离线建索引，在线问答
RAG 分两大阶段。离线索引阶段：文档解析 → 清洗 → 切分（chunking）→ Embedding 向量化 → 写入向量库（同时保留一份倒排索引做 BM25）。在线问答阶段：query 理解与改写 → 多路召回 → Rerank 精排 → 上下文组装 → LLM 生成 → 引用标注与后处理。每个环节都有坑，挨个说。
文档解析：垃圾进垃圾出
这是最容易被低估的环节。PDF 里的双栏排版、页眉页脚、页码、水印，直接解析会把正文切得稀碎；表格如果被抽成一堆散落的单元格文本，语义全丢。工程上常用 pdfplumber、unstructured 这类工具，表格尽量转成 markdown 或 HTML 保留结构，扫描件要走 OCR。清洗时去掉页眉页脚、目录、重复模板文本，否则这些噪声会被 Embedding 进库，污染召回。
切分：粒度决定召回质量
切太短语义不完整，模型拿到的 chunk 没头没尾；切太长噪声多，Embedding 被稀释，还浪费上下文窗口。常见做法按标题层级和标点递归切分，中文 chunk 一般控制在几百字。表格、代码块不能腰斩。这块的详细策略是高频单独考点，不展开。
召回：纯向量不够用
向量检索对语义相似的问题很好，但对专有名词、产品型号、错误码、缩写这类精确匹配很差。生产上基本是向量 + BM25 混合召回。另外用户的原始 query 经常又短又口语化，直接拿去召回效果差，需要做 query 改写：多轮对话里的指代消解（「它多少钱」改写成完整问题）、HyDE（让 LLM 先生成一个假想答案再去检索）、一个 query 扩写成多个变体并行召回。
上下文组装与生成：两个典型坑
第一个坑是 lost in the middle：LLM 对长上下文中间部分的信息利用率明显低于开头和结尾，所以 Rerank 之后把最相关的 chunk 放在首尾，别按召回顺序原样塞。第二个坑是幻觉，prompt 里要明确约束「仅根据给定资料回答，资料里没有就说不知道」，并在生成结果里带引用编号，方便用户溯源，也方便事后核查忠实度。上下文窗口不够时要做压缩或筛选，而不是无脑截断。
评估与迭代
RAG 没有银弹，调优是 badcase 驱动的：先建一个几十到几百条的评测集，把每次改动当实验跑，定位问题在检索层还是生成层，再针对性修。拍脑袋换模型、调参数，没有评测集兜底，改了也不知道是好是坏。
可能的追问
- 怎么控制幻觉？答：三层手段——召回侧用 rerank 分数阈值过滤低质 chunk，生成侧用 prompt 约束加拒答策略，输出侧做引用校验，答案里的事实必须能映射回检索到的原文。
- query 改写具体怎么做？答：多轮场景先做指代消解和省略补全；单轮可以上 HyDE 或多 query 扩展，成本敏感就用小模型做改写。
- 上线后怎么发现效果退化？答：记录全链路日志（query、召回、rerank 分数、答案），定期抽样人工评审，加用户点赞点踩反馈，评测集定期回归。