RAG 项目面试会怎样连续追问？一场工程深挖教学复原

先把这部分当成模拟面试。不要背示例项目，先在纸上写下自己的资料类型、请求链路和负责范围。 面试官：请用两分钟讲清楚你的 RAG 系统。 一个合格回答至少要交代四件事：资料怎样解析和切分，问题怎样进入检索，候选怎样融合与重排，最终答案怎样引用原文或拒答。还要明确哪些部分由你完成，哪些来自框架、同事或已有平台。 面试官：为什么使用现在的切分方法？固定长度有什么问题？ 不要直接回答某个固定 chunk size。先说明资料结构：普通段落、表格、列表、跨页内容分别会在哪里破坏语义，再说明你准备怎样用同一批问题比较不同切分方案。没有跑过对照实验，就说清楚这是待验证项，不能编一个提升数字。 面试官：为什么同时使用关键词检索与向量检索？ 回答应落到互补关系。关键词检索更擅长标题、编号和专业术语；向量检索更擅长同义改写。两路结果需要融合，之后才轮到重排。请继续说明搜索范围、权限过滤和文档状态在哪里生效，否则“召回更好”仍然只是口号。 面试官：多轮对话里，用户只说“那个方案”怎么办？ 先判断历史里是否有足够信息消解指代，再把问题改写成可独立检索的表达。改写前后的 Query、使用了哪些历史消息、错误改写怎样被发现，都应进入 Trace。这里考察的不是会不会调用一次模型，而是你能否解释失败路径。 面试官：Rerank 为什么可能更准？它能解决漏召回吗？ Bi-Encoder 适合先从大量资料中快速找候选，Cross-Encoder 会让问题与候选在 token 层交互，适合对较少候选重新打分。它只能调整已经找回的候选，不能把候选集之外的正确原文变出来。先区分“有没有找到”和“找到后排得好不好”，再谈模型。 面试官：RRF 的参数为什么这样取？你测过吗？ 如果沿用了默认值，就明确说是默认起点，不要包装成自己的实验结论。更完整的回答是：固定评测集和其他配置，只改变待比较参数，记录召回、排序、延迟与成本，并在独立测试集上复查。真正做过哪些，就只讲哪些。 面试官：答案不准就是大模型幻觉吗？ 先做阶段归因：正确资料是否入库，是否进入候选，重排后是否保留，送给模型的上下文是否完整，生成是否忠于证据。不同原因对应不同修复。只改 Prompt，可能掩盖解析或检索问题。 面试官：你怎样证明优化有效？ 先定义评测集的来源、证据标注和切分方式，再说明检索指标、生成指标以及端到端指标。每个结果都要带基线、样本量、配置和测量方法；如果还没有实测，就把表格留空。还要准备一条变差的 bad case，解释为什么整体均值上升仍不等于所有问题都更好。 面试官：权限为什么不能在检索之后再过滤？ 未经授权的资料不应先被召回再裁掉。权限条件应进入候选资格判断，缓存也要按租户或可见范围隔离。回答时要覆盖数据访问、候选被无权内容占位、权限变更后的失效与审计记录。 面试官：上下文窗口越来越长…