面试时如何讲清一个 RAG 项目：从链路讲到评测
先说项目解决了什么问题
面试官问“介绍一下你的 RAG 项目”，如果只回答“用了大模型、向量数据库和框架”，很难判断你做了哪些工程工作。更好的开头是：用户是谁、资料来自哪里、为什么直接调用模型不够，以及怎样判断系统真的有用。
例如企业文档问答，目标可能是让员工查到带出处的内部流程，而不是让模型自由发挥。接下来应交代文档更新频率、访问权限、问题类型和响应时间要求。这些条件决定方案，不能省略。
本文提供项目表达框架，不代表作者或读者已经完成某个上线项目。只讲你实际做过的部分；学习 Demo 可以明确称为 Demo。
用一条主链路解释实现
离线侧通常包括文档解析、清洗、分块、提取元数据、生成向量和建立索引。在线侧包括问题理解、候选检索、必要的重排、组装上下文、生成回答和返回引用。
每一步都要能回答“为什么这样做”。例如按标题层级分块，是为了尽量保留语义结构；添加文档 ID、章节、更新时间和权限标签，是为了追溯来源和控制可见范围。分块并不是越小越好：太小可能缺上下文，太大可能带入噪声并占用更多模型输入。
向量检索擅长语义匹配，关键词检索对编号、专有名词和精确术语可能更有效。混合检索值得作为候选方案，但是否引入，应由错误样本证明，而不是为了让技术栈显得丰富。
评测要拆成两层
第一层看检索：正确证据有没有进入候选集合？可以为一组真实问题标注相关文档或片段，观察 Recall@k，并检查排名。第二层看回答：有没有回答问题、是否忠于证据、引用能否支持结论、证据不足时是否明确说明。
只看“回答读起来很顺”不够。一个流畅的答案可能引用错误，也可能掩盖检索漏召回。评测集应覆盖常见问题、模糊问题、无答案问题和文档更新后的问题；涉及权限时还要验证不同用户不能获取无权查看的片段。
自动评审可以帮助筛选样本，但需要人工抽查。没有标注集时，可以先做小规模人工样本，记录问题、证据、预期要点和实际结果，再逐步扩充，而不是先报一个没有定义的“准确率”。
一个真实的失败排查路径
假设用户问报销标准，系统答出了旧版本额度。先查看返回的证据和元数据：如果召回的是旧文档，问题可能在更新、删除或版本过滤；如果新文档已召回但被排在后面，考虑排序；如果证据正确而回答错误，再检查上下文截断、提示约束和生成步骤。
修复后应把这个问题加入回归样本。文档更新还需要处理旧片段删除，不能只不断追加新向量。证据不足时，安全的结果是说明缺少依据并给出可查阅来源，而不是编造额度。
权限、延迟和成本如何取舍
内部知识库必须在检索或取回上下文时应用用户权限，不能仅在提示词里要求模型“不要泄露”。文档内容也不能被当成高优先级指令执行。
延迟可以拆成检索、重排和生成三段，成本则包括向量化、检索服务与模型输入输出。先测量再优化：减少无关片段可能同时改善成本和答案质量，但候选太少也可能损失召回。缓存需要考虑权限与文档版本，不能把一个用户的结果直接共享给所有人。
面试表达结构
用两分钟讲清“目标 → 链路 → 一次关键取舍 → 一个失败案例 → 如何验证修复”。随后再展开自己负责的代码、评测和排错工作。技术名称是辅助信息，能解释方案为何有效，才是项目经验的核心。