先这样答
我按两条线讲：离线建库和在线问答。
离线这条线的输入是原始文档，输出是可检索的向量库。第一步解析，PDF、Word、网页各有各的麻烦，扫描件还要过 OCR，表格和图片的解析最容易被做砸。第二步清洗，去掉页眉页脚、水印、乱码，这些脏东西进了向量库，检索时就是噪音。第三步切分，把长文档切成适合检索的块，这一步的质量直接决定后面检索的上限。第四步向量化，用 Embedding 模型把每个块变成向量，连同原文和元数据一起写进向量库，元数据里至少要有来源、标题、更新时间。
在线这条线从用户提问开始。第一步查询理解，判断该不该检索、要不要改写——用户的问题可能口语化、有指代，或者一次问了三件事要拆开查。第二步召回，从向量库里拉出候选段落，讲究一点的会向量检索加关键词检索双路一起拉。第三步重排，用更重的模型把候选段落按相关性重新排一次，只留最靠前的几段。第四步生成，把重排后的段落连同问题拼成提示词交给模型，要求它只依据资料回答并标注引用。
面试时讲完流程，最好主动补一句：这两条线里最容易出问题的是切分和查询改写，我做项目的时候主要精力也花在这两处。
面试官会怎么追问
- 为什么检索完还要重排？ 向量召回用的是双塔结构的轻量模型，求快；重排用交叉编码器逐对精算，求准。先用便宜的拉全量，再用贵的排顺序。
- 多轮对话里流程有什么不一样？ 要多一步指代消解：「它的价格呢」得先改写成「iPhone 16 的价格是多少」再去检索，否则查不到东西。
- 结构化数据也走 RAG 吗？ 表格类数据通常走 Text-to-SQL 更直接，混合场景才需要两者结合，硬把表格切成文本块检索效果一般不好。
回答的坑
- 只讲「向量检索然后生成」两步。流程讲不全，等于告诉面试官你没真正搭过。
- 不提元数据。来源和更新时间丢了，答案就没法溯源，企业场景这是硬伤。
同系列的题
—— 本题完 ——