RAG 项目面试表达：如何讲清楚从文档到答案的工程链路
这篇文章解决什么问题
面试中常见问题：
- 你做过 RAG 吗？
- RAG 的完整链路是什么？
- Chunk 怎么切？
- 向量库怎么选？
- 检索效果不好怎么办？
- RAG 怎么评测？
- 如何减少幻觉？
- 引用溯源怎么做？
如果你只回答"用向量数据库存文档，用户提问时检索相关段落，然后让模型生成答案"，面试官会觉得你只做过 Demo，没有工程落地经验。
核心观点：RAG 不是向量库加 Prompt，而是一条可评估、可追踪、可迭代的知识增强链路。 这篇文章基于 HFL AI Agent Lab 中 RAG 工程化专题和项目 A 的工程理解，整理面试中如何讲清楚一个 RAG 项目。
面试官真正想考什么
| 考察点 | 面试官想确认什么 |
|---|---|
| 是否理解完整 RAG 链路 | 你知不知道 RAG 不只是检索 + 生成 |
| 是否理解文档解析 | 你知不知道解析质量直接影响后续所有环节 |
| 是否理解 Chunk 策略 | 你知不知道切块方式影响召回质量和上下文完整性 |
| 是否理解 Embedding 版本管理 | 你知不知道版本混用会影响召回稳定性 |
| 是否理解检索和 Rerank | 你知不知道检索策略和重排对效果的影响 |
| 是否理解引用溯源 | 你知不知道引用是答案可信度的重要依据 |
| 是否理解 RAG 评测 | 你知不知道 RAG 需要分层评测 |
| 是否有问题定位能力 | RAG 效果不好时，你知不知道怎么定位问题 |
面试官想确认你有没有完整做过 RAG 链路，而不只是调了一个向量搜索 API。
回答 RAG 项目时，要展示你理解每个环节的作用和风险：不只是检索能做什么，还有怎么保证召回质量、怎么减少幻觉、怎么做引用溯源、怎么评测和迭代。
一句话回答框架
我不会把 RAG 简化成向量库加 Prompt。我会把它拆成文档解析、文本清洗、Chunk 切分、Embedding、向量入库、Query Rewrite、Hybrid Search、Rerank、Context Build、答案生成、引用溯源、Evaluation 和失败样本迭代几个环节。RAG 效果不好时，我会先定位是解析问题、切块问题、召回问题、排序问题、上下文构建问题还是生成问题。
这个回答框架的核心是：展示你理解 RAG 的完整链路，而不只是检索和生成；展示你有能力定位问题，而不只是调参数。
RAG 完整链路怎么讲
文档上传 → 文档解析 → 文本清洗 → Chunk 切分 → Embedding → 向量入库 → 用户问题 → Query Rewrite → 检索 → Rerank → 上下文构建 → 答案生成 → 引用返回 → 用户反馈 → 失败样本库 → 评测迭代
每一步的作用：
- 文档上传：接收用户上传的文档。
- 文档解析：提取文本、标题、表格、页码等结构信息。
- 文本清洗：去除噪声、修复格式、保留关键结构。
- Chunk 切分：把文档切成适合检索的片段。
- Embedding：把 Chunk 转换成向量。
- 向量入库：把向量和元数据存入向量数据库。
- 用户问题：接收用户查询。
- Query Rewrite：优化用户查询，补全语义。
- 检索：向量检索 + 关键词检索，获取候选 Chunk。
- Rerank：对候选 Chunk 重新排序，提升相关性。
- 上下文构建：把排序后的 Chunk 组装成模型输入。
- 答案生成：模型基于上下文生成答案。
- 引用返回：返回答案和引用来源。
- 用户反馈：收集用户对答案的评价。
- 失败样本库：把失败案例积累起来。
- 评测迭代：定期评估效果，驱动优化。
文档解析怎么讲
面试中要提：
- 格式差异：PDF / Word / Markdown / HTML / 表格的解析方式不同，不能用一套逻辑处理所有格式。
- 结构保留：标题、页码、段落、表格结构需要保留，否则 Chunk 会丢失上下文。
- 元数据：每个 Chunk 要关联
source_uri、page、section、document_id，用于引用溯源。 - 解析失败记录：某些文档可能解析失败，需要记录失败原因，不能静默跳过。
- 结构丢失的影响：如果文档结构丢失，后续 Chunk 切分质量会下降，引用溯源也会出问题。
面试表达：
文档解析是 RAG 的基础，如果解析质量差，后面所有环节都会受影响。我会保留文档的标题、页码、段落和表格结构，并为每个 Chunk 关联元数据，用于引用溯源和问题排查。
Chunk 策略怎么讲
| 策略 | 适用场景 | 风险 |
|---|---|---|
| 固定长度切分 | 快速实现，文档结构不重要 | 可能在句子中间切断，丢失语义完整性 |
| 按标题切分 | 文档有清晰标题层级 | 标题层级不一致时效果差 |
| 按语义切分 | 需要保留语义完整性 | 实现复杂，计算成本高 |
| 滑动窗口 | 需要保留上下文连续性 | 可能有重复内容，增加存储和检索成本 |
| Parent-Child Chunk | 需要精确匹配但完整上下文 | 实现复杂度增加 |
| Chunk Overlap | 减少边界信息丢失 | 增加存储和计算成本 |
面试要强调：
- Chunk 太大会引入噪声，模型可能被无关信息干扰。
- Chunk 太小会丢上下文，模型缺乏足够信息生成答案。
- Chunk 大小通常在 200-1000 token 之间，需要根据文档类型和查询场景调优。
Embedding 和向量库怎么讲
要讲清楚的关键字段：
embedding_model：使用的 Embedding 模型。embedding_version：模型版本，版本混用会影响召回稳定性。chunk_hash：Chunk 内容的哈希值，用于增量更新。document_id：文档唯一标识。chunk_id：Chunk 唯一标识。vector_id：向量数据库中的 ID。metadata：元数据，如页码、标题、文档类型。- 增量更新：文档修改后只更新变化的 Chunk，不重建整个索引。
- 重建索引：Embedding 模型升级后需要重建索引。
面试表达：
Embedding 版本管理很重要——如果不同批次的 Chunk 使用了不同版本的 Embedding 模型，向量空间的语义分布会不一致，召回质量会下降。我会记录每个 Chunk 的 embedding_version，在模型升级时重建索引。
检索策略怎么讲
- 向量检索：适合语义相似的查询，比如"这个功能怎么用"。
- 关键词检索：适合编号、术语、错误码、精确短语，比如"ERR-001"。
- Hybrid Search：结合语义和关键词，覆盖更多场景。
- Metadata Filter：处理权限、租户、时间、文档类型等过滤需求。
- Query Rewrite：解决用户表达不完整的问题，比如把"怎么退款"改写成"退款流程、退款条件和退款时间"。
- Multi-query：复杂问题多角度召回，比如生成多个不同角度的查询，合并去重后返回最相关的 Chunk。
- Rerank：对候选结果重新排序，提升最终上下文质量。Rerank 通常比向量检索更准，但速度更慢。
面试表达：
检索策略的选择取决于查询场景。纯语义查询用向量检索，精确匹配用关键词检索，混合场景用 Hybrid Search。Query Rewrite 可以提升查询质量，Rerank 可以提升排序质量。
引用溯源怎么讲
答案应返回：
document_id：文档唯一标识。chunk_id：Chunk 唯一标识。source_uri：文档来源链接。page：页码。section：章节。score：相关度分数。
面试表达：
引用不是装饰，而是答案可信度、问题排查和评测的重要依据。用户可以通过引用验证答案是否来自可靠来源；开发人员可以通过引用定位检索问题；评测系统可以通过引用评估 Citation Accuracy。
RAG 评测怎么讲
| 指标 | 关注点 |
|---|---|
| Recall@K | 检索阶段是否召回了相关文档 |
| MRR | 相关文档在检索结果中的排名 |
| Context Precision | 上下文中相关文档的比例 |
| Context Recall | 相关文档被召回的比例 |
| Faithfulness | 答案是否忠于上下文，没有幻觉 |
| Answer Relevance | 答案是否和用户问题相关 |
| Citation Accuracy | 引用是否正确指向来源 |
| Human Review | 人工评估答案质量 |
面试要强调：
RAG 要分开评估召回、上下文、答案和引用。不能只看最终答案好不好，还要看是哪个环节导致的问题。
评测还要区分自动评测和人工评测。自动评测用指标打分，适合大规模回归测试；人工评测由标注员判断答案质量，适合发现自动评测无法捕捉的问题。两者结合才能建立可靠的评测体系。
RAG 效果不好怎么排查
按问题类型定位：
- 检索不到：检查文档解析是否正确、Chunk 是否丢失关键信息、Embedding 是否匹配、Query Rewrite 是否有效。
- 检索到了但排序靠后：检查 Rerank 策略、score 阈值、top_k 设置。可能需要调整 Rerank 模型或增加 top_k。
- 检索结果无关：检查 Chunk 是否有噪声、Metadata Filter 是否正确、Hybrid Search 权重是否合理。
- 答案幻觉：检查上下文构建是否包含足够信息、Prompt 是否有引用约束、模型是否被无关上下文干扰。
- 引用错误：检查 citation 绑定逻辑、chunk_id 是否正确关联。
- 权限错误：检查 Metadata Filter 是否正确过滤了无权限的文档。
面试表达：
RAG 效果不好时，我不会盲目调参数，而是先定位问题出在哪个环节。通过 Trace 可以看到每次查询的检索结果、排序分数、上下文内容和最终答案，这样可以精确定位是召回问题、排序问题还是生成问题。
定位问题后，我会针对性优化：召回问题优化 Chunk 策略和 Embedding，排序问题优化 Rerank 模型，生成问题优化 Prompt 和上下文构建。每次优化后都要跑评测集，确认效果是否提升。
常见追问
追问 1：Chunk 怎么设置大小？
回答要点：通常 200-1000 token，需要根据文档类型调优。法律文档可以大一些，FAQ 可以小一些。可以用滑动窗口减少边界信息丢失。
追问 2：Rerank 有什么作用？
回答要点：向量检索返回的是语义相似的候选，但不一定是最相关的。Rerank 用更精细的模型对候选重新排序，提升最终上下文质量。Rerank 通常比向量检索更准，但速度更慢，所以先用向量检索召回 top_k 个候选，再用 Rerank 精排。
追问 3：什么时候用 Hybrid Search？
回答要点：当查询可能包含语义和关键词混合时。比如"ERR-001 错误怎么解决"，"ERR-001"需要关键词匹配，"错误怎么解决"需要语义匹配。Hybrid Search 结合两种检索方式，通过权重调整平衡语义和关键词的贡献。
追问 4：RAG 怎么做权限控制？
回答要点：在文档入库时记录权限标签（tenant_id、role），检索时用 Metadata Filter 过滤无权限的文档。
追问 5：如何做增量更新？
回答要点：文档修改后，用 chunk_hash 对比变化的 Chunk，只更新变化的部分。Embedding 模型升级后需要重建整个索引。增量更新可以减少计算成本和时间，但需要维护 chunk_hash 和版本信息。
追问 6：如何处理表格和图片？
回答要点：表格可以转成文本或结构化数据。图片可以用多模态模型提取描述，或者单独存储图片链接。复杂表格可能需要专门的表格解析器。表格解析需要保留行列结构，否则 Chunk 会丢失表格语义。
追问 7：如何评估 RAG 是否变好了？
回答要点：建立评测指标体系（Recall、MRR、Faithfulness、Citation Accuracy），定期跑评测集，对比版本间的变化。不能只靠主观感受。
追问 8：如何减少幻觉？
回答要点：在 Prompt 中要求模型只基于上下文回答，不确定时说"我不知道"。用引用约束模型必须标注来源。用 Faithfulness 指标评估幻觉率。还可以在后处理阶段检查答案是否忠于上下文。
追问 9：RAG 和微调怎么选？
回答要点：RAG 适合知识频繁更新、需要引用溯源的场景；微调适合需要模型掌握特定风格或格式的场景。两者可以结合——用 RAG 提供知识，用微调优化生成风格。
容易踩坑的回答
- 只说用了向量数据库——面试官会觉得你只做了最简单的检索。
- 只说用了 LangChain——面试官会觉得你只是调了框架 API。
- 不讲文档解析——面试官会觉得你不了解 RAG 的基础环节。
- 不讲 Chunk 策略——面试官会觉得你不理解切块对效果的影响。
- 不讲引用溯源——面试官会觉得你不知道引用的重要性。
- 不讲评测指标——面试官会觉得你不知道怎么评估 RAG 效果。
- 不讲失败样本——面试官会觉得你没有迭代优化的意识。
- 不知道怎么定位问题——面试官会觉得你只做过正常流程，没处理过异常。
更好的表达方式
| 不推荐表达 | 更好的表达 |
|---|---|
| 我用向量数据库存文档 | 我把文档解析、Chunk 切分、Embedding、向量入库作为完整的索引链路 |
| 用户提问时搜索相关段落 | 我用 Query Rewrite 优化查询，Hybrid Search 结合语义和关键词，Rerank 提升排序 |
| 让模型根据检索结果回答 | 我构建上下文时会控制 Chunk 数量和顺序，在 Prompt 中加入引用约束 |
| 引用就是返回来源链接 | 引用需要绑定 document_id、chunk_id、page、section，用于可信度验证和问题排查 |
| 效果不好就调参数 | 我会先定位是解析、切块、召回、排序、上下文还是生成问题，再针对性优化 |
| 测试一下就知道好不好 | 我建立评测指标体系，定期跑评测集，对比版本间 Recall、Faithfulness、Citation Accuracy |
| 直接部署就行了 | 需要监控检索延迟、token 消耗、引用准确率，建立失败样本库驱动迭代 |
| RAG 就是向量搜索 | RAG 是完整的知识增强链路，从文档解析到评测迭代，每个环节都影响最终效果 |
| Chunk 切小一点就行 | Chunk 太小会丢上下文，太大会引入噪声，需要根据文档类型和查询场景调优 |
对个人项目的启发
项目 A（RAG 工单系统）：
可以围绕 RAG 工单系统讲清楚文档解析、Chunk、Embedding、检索、Rerank、引用和评测。后续可以补失败样本库和 RAG Evaluation，让 RAG 系统有完整的质量闭环。RAG 查询可加入 Trace，记录每次查询的检索结果、排序分数、引用来源和用户反馈。
面试时可以这样表达：我的 RAG 工单系统覆盖了完整的工程链路——文档解析保留结构信息，Chunk 按标题切分，Hybrid Search 结合语义和关键词，Rerank 提升排序质量，引用溯源绑定 document_id 和 chunk_id。当效果不好时，我会通过 Trace 定位是哪个环节的问题。
项目 B（多 Agent 运营中台 Copilot）：
多 Agent 使用知识库时也需要引用溯源。Agent 调用 RAG 工具时要记录 run_id 和 citation，这样可以追踪哪个 Agent 基于什么来源做了什么决策。本文只说明 Project B 可复用的 RAG 迁移方向。
面试时可以这样表达：在多 Agent 系统中，RAG 不只是单个 Agent 的能力，而是多个 Agent 共享的知识服务。每个 Agent 调用 RAG 工具时都会记录 run_id、agent_id 和 citation，这样可以追踪知识的使用链路。
后续 TODO
- 补充 RAG 面试 3 分钟口述稿，用于面试快速表达。
- 补充 RAG 效果排查案例，覆盖常见问题和解决方案。
- 补充 RAG 评测表格模板，可直接用于项目 A 的评测设计。
- 补充项目 A 的 RAG 面试表达版本，把工程实践转成面试话术。
- 补充 RAG 评测自动脚本示例，展示如何自动化跑评测集。
- 补充 Chunk 策略对比实验数据，用实际数据说明不同策略的效果差异。