RAG
做过知识型 Agent 的岗位，几乎一定会问 RAG。真正拉开差距的不是背概念，而是你能不能把问题拆到检索、排序、注入、生成这几层，而不是一出错就笼统地说“模型幻觉”。
这一页最适合按“先查证据链，再谈模型”的顺序来读。先用短答版记住每类问题的判断主线，再用深答版补“为什么会错、该看什么指标、不同方案各自解决什么问题”，这样你在面试里会更像一个能定位故障的人，而不是只会背 RAG 组件名词的人。
高频题
1. RAG 为什么会答不准？
题目：如果文档明明在库里，为什么模型还是答错？
面试官想听什么：你是否具备定位问题的能力，而不是把一切失败都归因给“模型幻觉”。
短答版：我一般会分四层看：没召回到、召回到了但排序靠后、注入了但上下文被噪声淹没、模型读到了但没按证据回答。很多 RAG 问题不是模型本身不行，而是检索链路失真。
深答版：
展开深答版
这题的本质是建立 RAG 的故障分层视角。RAG 答不准，通常不是一个单点故障，而是检索、排序、注入和生成四层里至少有一层出了偏差。真正做过系统的人，不会一上来就说“模型幻觉”，而是会先判断证据有没有进来、进来后排得对不对、排对后模型有没有真的按证据回答。
定位顺序很关键。如果文档根本没召回到，那是检索问题；如果召回了但没进最终上下文，是排序或注入问题；如果证据已经在上下文里，模型还答偏，才更像生成层问题。也就是说，RAG 出错时应该先看证据链，再看模型行为。
工程上，只有先分层定位，后面的调优才不会乱。你可以记成：
RAG 先查证据链，再怪模型。追问方向：你会怎样一步步定位是哪一层出了问题？
2. 混合检索为什么常常优于纯向量检索？
题目：只做 embedding 检索为什么不一定够？
面试官想听什么：你是否理解不同检索方式的优势边界，而不是把向量检索当成万能答案。
短答版：纯向量检索擅长语义相似，但对精确关键词、实体名、编号和结构化约束不够稳。混合检索结合关键词和语义检索，通常更能兼顾 recall 和 precision。
深答版：
展开深答版
这题的核心判断是，检索问题往往不是单一相似度函数能完整覆盖的。向量检索很擅长找语义相近内容，但对专有名词、错误码、文档编号、日期这种强精确匹配信号通常不够稳；关键词检索正好补这类“字面命中很重要”的场景。
所以混合检索的意义，不是把两套结果粗暴拼起来，而是让不同检索机制分别覆盖不同类型的查询信号，再通过统一排序把最有价值的候选送到前面。一个偏 semantic，一个偏 lexical，它们解决的是不同维度的召回问题。
工程上，混合检索会增加实现复杂度和排序成本，但在企业知识库、FAQ、代码库这类混合语义与结构信号的场景里通常非常值。你可以记成：
向量负责语义近似，关键词负责精确命中。追问方向：什么时候纯关键词检索反而更靠谱？
3. RAG 的核心指标该看什么？
题目：如果你要评估一个 RAG 系统，重点看哪些指标？
面试官想听什么：你是否知道 RAG 评估必须分层，否则出了问题根本不知道该改哪。
短答版：我至少会分成两层：召回质量和最终答案质量。前者看命中率、排序质量、上下文相关性，后者看答案正确率、证据一致性和是否真的用到了有效材料。
深答版：
展开深答版
这题本质上是在看你有没有可操作的评估框架。RAG 评估如果只看“答案像不像对的”，几乎没法支撑调优，因为你不知道问题出在召回、排序、注入还是生成。至少要拆成两层：检索层和回答层。
检索层关心的是对的材料有没有进候选、有没有排到前面；回答层关心的是模型是否真的基于这些材料做出正确、可引用、不过度推断的结论。只有把这两层拆开，后续调参、换索引、换 reranker、改 prompt 才有因果基础。
工程上，分层评估确实需要更多标注和样本，但它能显著提升系统迭代效率。你可以记成：
先评材料到没到，再评答案对不对。追问方向：为什么离线指标和线上用户满意度常常不完全一致？
4. 上下文注入是不是越多越好？
题目：既然都召回出来了，为什么不全给模型？
面试官想听什么：你是否有上下文预算意识，知道召回结果进入模型前还需要二次治理。
短答版：不是越多越好。过多上下文会稀释关键信息、抬高成本，还可能引入互相冲突的片段。更常见的做法是控制 chunk 质量、重排、去重后再送最相关的一小部分。
深答版：
展开深答版
这题的核心是“召回结果不等于最终上下文”。检索的任务是别漏掉，注入的任务是别塞太多。模型的注意力和上下文窗口都是有限资源，如果把所有召回片段都扔进去，关键证据反而更容易被噪声压住。
所以注入阶段真正追求的不是数量，而是“足够回答问题的最小证据集合”。好的上下文注入应该让模型迅速看到最重要的证据，而不是被一堆边缘相关片段拖散注意力。也就是说，召回求覆盖，注入求收缩。
工程上，重排、去重、摘要虽然增加一点前处理成本，但通常比盲目加 token 更稳、更便宜。你可以记成：
召回可以多一点，注入必须少而准。追问方向：chunk 太大和太小分别会带来什么问题？
5. RAG 和 Fine-tuning 怎么选？
题目：如果业务方说“知识答不准，要不要微调模型”，你怎么判断？
面试官想听什么：你是否知道“知识问题”和“行为问题”通常要用不同手段解决。
短答版：如果问题是外部知识更新频繁、需要引用原始资料，优先考虑 RAG；如果问题是输出风格、任务格式或固定行为模式不稳定，微调可能更合适。很多项目不是二选一，而是分层组合。
深答版：
展开深答版
这题的本质是区分“模型不知道”和“模型不会按你想要的方式表达”。如果问题出在外部知识更新频繁、需要接入实时资料、需要保留引用能力，那更像知识接入问题，优先该考虑 RAG；如果问题出在输出格式不稳、任务模式不固定、行为风格总跑偏，那才更像微调或行为约束问题。
也就是说，RAG 主要解决“知识从哪来”，微调主要解决“行为怎么稳定”。一旦业务要求知识可更新、答案可追溯、来源可引用，优先微调通常不划算，因为知识会很快过时，训练和版本治理成本会很重。
工程上，很多成熟系统不是二选一，而是“RAG 负责知识，prompt/微调负责行为”。你可以记成：
RAG 补知识，微调稳行为。追问方向：什么迹象说明问题根本不在模型参数，而在检索链路？
扩展题
6. chunk 应该怎么切，为什么这不是纯参数题？
题目：RAG 里的 chunk size 和 overlap 应该怎么定？
面试官想听什么：你是否理解 chunk 设计影响的是召回边界、证据完整性和噪声比例，而不是只会报几个经验数值。
短答版：chunk 太大，主题混杂、排序变差；chunk 太小，语义断裂、证据不完整。我的判断标准不是固定字数，而是看一个 chunk 能不能尽量表达一个相对完整的语义单元。
深答版：
展开深答版
这题的关键是把 chunk 看成检索系统的最小证据单位，而不是简单切文本。切得太大，会把多个主题绑在一起，embedding 容易平均化；切得太小，又会把语义切碎，模型拿到的是零散片段，很难形成完整证据。
overlap 也不是越大越好。过大会带来索引膨胀、重复召回和 rerank 浪费；过小则会让上下文接缝处的信息断掉。真正的判断标准不该只是字数，而应该看一个 chunk 能不能尽量表达一个完整语义单元。
工程上，FAQ、API 文档、制度文档、长报告都不该用同一套切法。拍一个固定参数长期不动，是很常见但也很粗糙的做法；更稳的是按文档类型和失败样本反推 chunk 策略。
追问方向：你会优先按字数切、按标题切，还是按语义段落切？
7. 明明已经召回了，为什么还要加 reranker？
题目：有了向量检索或混合检索，reranker 的价值在哪里？
面试官想听什么：你是否知道召回和排序是两件事，能解释 reranker 解决的不是“找不到”，而是“排不准”。
短答版：召回阶段更关注别漏掉，reranker 负责把真正最相关的证据顶到前面。很多系统不是没找到答案，而是正确 chunk 排在后面，没进最终上下文。
深答版：
展开深答版
这题本质是在区分 recall 和 ranking。第一阶段检索的主要目标是别漏掉，所以它通常会在速度和覆盖率之间做平衡；但候选集合里常常混着很多“看起来相关、但并不真正回答问题”的片段。
reranker 的价值就在于，用更重但更准的相关性判断，把有限上下文预算留给最值得注入的证据。也就是说，检索阶段解决“找没找到”，reranker 解决“排得准不准”，它们不是同一层能力。
工程上，reranker 会增加延迟和成本，所以更适合放在 topK 收窄后的第二阶段，而不是替代第一阶段检索。候选集合已经很干净时，它的收益会下降；文档冗长、chunk 很多时，它通常很值。
追问方向：什么情况下你会判断 reranker 带来的延迟不值得？
8. query rewrite 要做到什么程度，什么时候该停？
题目：用户问题要不要先改写再检索？
面试官想听什么：你是否理解 query rewrite 是提升召回的工具，但一旦改写过度，就会把用户真实意图改坏。
短答版：我会把 rewrite 限制在补全实体、消歧、展开缩写、补上下文这几类，不让它替用户改需求。检索前改写可以更稳，但边界一定要保守。
深答版：
展开深答版
这题的核心不是“要不要改写”，而是“改写的权限有多大”。很多真实查询很短、带省略、夹杂代词或缩写，这时适度 rewrite 确实能明显提升召回；但一旦改写开始替用户补目标、加约束、改问题，风险就从提升 recall 变成污染 intent。
所以 query rewrite 更适合做表达层修复，比如补全实体、展开缩写、消歧和补上下文，而不该做任务层重写。系统应该帮用户把问题说清，而不是替用户把问题改成另一个问题。
工程上，rewrite 越激进，单次命中率可能看起来更高，但系统会更难解释、更难回溯。保留原 query、改写结果和检索日志，是很重要的诊断基础。
追问方向：如果 rewrite 后结果更差，你怎么证明问题出在改写而不是检索器？
9. RAG 为什么常被要求“必须带引用”，难点到底在哪？
题目：做 citation 看起来很简单，为什么落地时经常出问题？
面试官想听什么：你是否理解引用不是“把链接贴上去”这么简单，而是证据绑定、一致性校验和用户信任问题。
短答版：难点不在展示引用，而在保证回答里的每个关键结论都能对应到真实证据，而且引用片段和最终表述不能互相打架。
深答版：
展开深答版
这题的关键是 citation consistency。用户真正要的不是“页面上出现几个引用编号”，而是答案里的关键结论能被逐条追溯到真实证据，且证据和表述之间不打架。
引用容易出问题，通常是因为模型把多个 chunk 混写成一个结论、把引用标到了相关但并不支撑该结论的片段，或者知识库里有版本冲突但系统没处理。也就是说，展示引用很简单，让引用真的成立很难。
工程上，想把 citation 做稳，往往要增加回答约束、片段级证据对齐甚至后校验，这会抬高复杂度和延迟，但这是可信度建设的必要成本。只要求“输出引用编号”，常常只是表面合规。
追问方向：如果两个来源都像对的，但结论冲突，你会怎么处理引用展示？
10. 知识库经常更新时，RAG 怎么保证检索新鲜度？
题目：业务文档每天都在变，怎么避免系统还在回答旧版本？
面试官想听什么：你是否意识到 RAG 不只是检索算法问题，还包括索引更新、版本管理和线上一致性。
短答版：关键不是“能不能重新建索引”，而是多快感知变更、多快完成更新，以及新旧版本切换时会不会混答。新鲜度是数据管道问题，不只是模型问题。
深答版：
展开深答版
这题的本质是 retrieval freshness。很多团队只关注检索准确率，却忽略知识库更新链路是不是可靠。如果文档更新频繁，但索引刷新慢、缓存没失效、旧 chunk 没退场，系统就会很自信地给出历史答案。
所以新鲜度不只是“能不能重建索引”，而是从变更感知、增量更新、缓存失效到新旧版本切换整条链路是否稳。最危险的情况甚至不是“全旧”，而是新旧内容混答，因为这种错误更难被人察觉。
工程上，实时更新最理想，但成本和复杂度都高，所以往往要在全量重建、增量刷新、版本分层和热点文档优先更新之间做平衡。新鲜度本质上是数据管道问题，不只是模型问题。
追问方向：如果索引更新不能做到实时，你会优先保障哪类文档的新鲜度？
11. RAG 为什么既要做离线评估，也要盯线上指标？
题目：离线 eval 和线上 eval 各自解决什么问题？
面试官想听什么：你是否知道离线评估适合做可控对比，线上评估才反映真实流量和真实任务价值，两者不能互相替代。
短答版：离线 eval 适合做方案筛选和回归测试，线上 eval 才能看用户是否真的得到更好的答案。离线保证可比，线上保证有效。
深答版：
展开深答版
这题的核心是理解评估场景不同，结论边界也不同。离线 eval 的优势是可重复、低成本、可分层定位，所以很适合比较 chunk 策略、检索器、reranker 和 prompt 版本；但它天然受数据集覆盖限制，对真实长尾问题不够敏感。
线上 eval 则能看到真实查询分布、用户追问率、人工纠错率、停留和反馈这些更接近业务价值的信号，但它噪声更大、归因更难。也就是说，离线更适合做可控对比，线上更适合验证真实有效性，两者互补而不是替代。
工程上，好的 RAG 迭代流程通常是先用离线淘汰明显差的方案，再在线上灰度验证真实收益。离线涨分就直接全量上线，是很典型的冒进。
追问方向：如果离线指标更好了，但线上满意度下降，你会先查什么？
12. 怎么区分是模型幻觉，还是检索根本没给到对的证据？
题目：用户说“这题答错了”，你怎么判断是 hallucination 还是 retrieval miss？
面试官想听什么：你是否有系统化诊断思路，能把“答错”拆成证据缺失、证据冲突、证据已给但模型没遵循三类问题。
短答版：我会先看正确证据有没有进候选、有没有进最终上下文，再看模型回答是否真的引用了这些证据。先证据，后模型，不然很容易误判。
深答版：
展开深答版
这题本质是在做故障归因。很多人一看到答错就说“幻觉”，但如果正确材料根本没被召回，那就不是 hallucination，而是 retrieval miss；如果材料进了候选却没进上下文，更像排序或注入问题；只有证据已经在上下文里，模型还编了新结论，才更接近生成层幻觉。
真正复杂的是证据不完整或彼此冲突的情况。这时模型未必是在纯编造，它也可能是在不完整材料上做了过度推断。所以诊断不能只看最终答案，而要沿着 query、候选集、最终上下文和回答逐层往下查。
工程上，如果没有保存 query、候选集、上下文和回答日志，你就只能凭感觉调系统。先证据、后模型，是 RAG 诊断里非常重要的一条顺序。
追问方向：如果候选里有正确答案，但最终回答用了错误证据，你会先改哪一层？
13. 向量数据库的更新、删除、版本管理应该怎么做？
题目：如果知识库里的文档会持续修改、下线、重写，你怎么保证向量库不会越来越脏，最后把新旧内容混着答？
面试官想听什么：你是否把向量数据库当成“知识生命周期系统”而不是一次性入库组件，理解更新、删除、版本切换和回滚的治理要求。
短答版：我不会把向量库更新理解成“覆盖一下 embedding”就结束，因为真正变化的是文档版本、chunk 集合、metadata 和索引状态。生产上更关键的是把知识变更做成可追溯、可切换、可回滚的生命周期治理，避免新旧内容混答。向量库真正难的不是“能不能存”，而是变更后还能不能保持干净和可信。
深答版：
展开深答版
这题的核心是：向量数据库不是把文本向量化后扔进去就结束了，它本质上承接的是知识生命周期治理。文档一旦更新，变的从来不只是某一条 embedding，而是整组 chunk、它们的 metadata、所属文档版本、可能还有倒排索引和缓存状态。如果只做“原地覆盖”，你很快就会遇到旧 chunk 残留、新旧版本同时命中、引用指向过期内容这些典型生产问题。
所以这里先要建立的不是某一种具体更新动作，而是一套知识变更治理框架。系统至少要知道：这次变更影响了哪些文档和 chunk，旧版本现在是否仍可命中，新版本什么时候对检索生效，出了问题能不能快速切回上一版。真正的关键不在于你背了多少更新手法，而在于你是否能把每次知识变更管理成一个可追踪、可验证的版本事件。
版本管理尤其重要。你需要让检索层知道自己命中的是哪个文档版本、哪个 chunk 版本，最好还能做到按版本切换或回滚。否则线上一旦发现错误，你只能继续在脏索引上修补，既讲不清问题出在哪，也没法快速恢复到上一个可信状态。对生产 RAG 来说，可追溯和可回滚并不是附加项，而是知识治理的地基。
面试里可以这样收口：
向量库的难点不是存进去，而是知识变动后还能不能干净地更新、删除、切换和回滚。追问方向：如果一份核心制度文档刚更新，而全量重建要很久，你会先用什么策略避免系统继续答旧版本？
14. RAG 为什么不是“建一次索引就完事”？
题目：很多团队一开始觉得 RAG 就是“切文档、做 embedding、建索引”，为什么你会说真正难点根本不在第一次建库？
面试官想听什么：你是否理解 RAG 是持续运行的知识系统，而不是一次性交付的离线流程，知道后续真正麻烦的是质量漂移、内容变更、评估和运营治理。
短答版：第一次建索引只解决了“能不能开始检索”，没有解决“以后会不会越来越差”。只要文档在变、查询在变、用户问题在变，chunk 策略、召回质量、索引新鲜度和引用一致性都会持续漂移。RAG 真正难的是长期维护一个可更新、可验证、可解释的知识检索系统，而不是把数据第一次塞进去。
深答版：
展开深答版
这题本质上是在考你有没有“系统生命周期视角”。第一次建索引当然重要，但它解决的是一个非常初级的问题：系统有没有最基本的检索能力。只要进入真实生产环境，问题马上会从“建出来没有”变成“还能不能持续可信地工作”。文档会更新，知识会下线，热点查询会变化，原本有效的 chunk 策略和排序方式也可能逐渐失效。
所以 RAG 真正的工作量通常发生在建库之后。你需要持续处理文档变更带来的索引更新，处理查询分布变化带来的召回退化，处理引用和答案不一致带来的信任问题，还要做离线评估和线上监控，证明系统不是“偶尔答对”，而是“长期稳定地答得还可以”。换句话说，第一次建索引更像是系统启动，后面的治理才是系统运营。
这也是为什么很多 Demo 看起来不错，一上线很快就暴露问题。Demo 只验证了“在一小批静态样本上能跑通”，没有验证知识库生命周期、索引老化、检索漂移、线上长尾问题这些真正决定可用性的东西。RAG 如果没有后续治理，很容易在最初几周看上去很好，之后逐渐积累脏数据和错误信号。
面试里可以这样收口：
建一次索引只是启动 RAG，长期治理才决定它能不能真正在生产里活下去。追问方向：如果一个 RAG 系统前两周效果很好，后面用户满意度持续下降，你会优先排查哪些“建库之后”的问题？
15. 增量更新、全量重建、软删除分别适合什么场景？
题目：如果知识库内容一直在变，你会怎么判断该做增量更新、全量重建，还是先软删除而不是立刻物理删除？
面试官想听什么：你是否理解向量库维护不是单一技术动作，而是时效、成本、风险和可回滚性之间的工程取舍。
短答版：增量更新适合局部频繁变更、要求快速生效的场景；全量重建适合切分策略、embedding 模型或索引结构发生系统性变化时；软删除适合需要审计、灰度切换、短期可恢复的场景。关键不是“哪种更高级”，而是根据变更范围、恢复要求和线上风险选路径。
深答版：
展开深答版
这题核心看你有没有“知识资产运维视角”。很多人把向量库更新理解成“新文档来了就重新 embedding”，但生产里真正要处理的是三类不同问题：局部内容变了、整体加工方式变了、内容暂时不该再被命中。它们对应的处理策略完全不同，不能混用。
增量更新最适合文档整体结构不变、只是局部内容追加或修订的情况，比如制度补充条款、FAQ 新增问答、商品说明更新一段参数。它的优势是快、成本低、对线上冲击小，但前提是你能可靠定位受影响 chunk，并保证旧版本不会继续混入召回。做不好，增量更新就会逐步把索引变成“新旧拼接层”。
全量重建适合更底层的东西变了，比如 chunk 策略改了、embedding 模型换了、metadata 结构调整了、过滤规则变了、召回质量已经整体漂移。这时候继续增量修补通常是在脏基座上叠补丁，短期省事，长期更贵。全量重建的代价更高，但它解决的是一致性问题，不只是新鲜度问题。
软删除则更像治理手段，而不是最终状态。它适合高风险文档下线、合规争议内容、等待人工复核的数据，或者需要先从检索视角撤出、但暂时还不能彻底物理删除的内容。软删除让你能审计、能回滚、能和新版本并行切换。面试里可以收口成一句：
增量更新解决时效，全量重建解决一致性，软删除解决风险控制和可恢复性。追问方向：如果一批核心文档今天必须下线，但合规团队要求保留审计痕迹，你会怎么设计删除路径？
16. 检索命中率很高，为什么答案还是不靠谱？
题目：如果离线评估看起来召回命中率已经不错了，但用户还是经常觉得答案不可信，你会怎么解释？
面试官想听什么：你是否理解“检索命中”不等于“答案可靠”，知道问题可能出在证据选择、上下文组织、引用一致性和生成约束上。
短答版：因为命中率只说明“正确材料出现过”，不说明它是否被排在关键位置、是否被模型真正采用、是否和最终回答保持一致。RAG 的可靠性不止取决于有没有找到证据，还取决于证据是怎么被选、怎么被组织、怎么被引用进答案里的。
深答版：
展开深答版
这题很适合用来区分“会做检索评估”和“理解 RAG 可靠性”的候选人。命中率高通常只表示正确文档或正确 chunk 在候选集中出现过，但候选集不是最终答案。中间还隔着 rerank、上下文拼装、长度截断、提示词约束和模型生成。任何一层处理不好，最后都可能变成“证据其实在，但答案还是不靠谱”。
最常见的问题有几类。第一类是正确证据命中了，但位置不够靠前，被更花哨但次优的内容盖住了。第二类是上下文里混入了彼此冲突、时效不同或粒度不一致的材料，模型在整合时做了错误抽象。第三类是回答阶段没有把证据绑定到结论，导致模型虽然看到了材料，却仍然补出了超出证据边界的说法。用户感知到的“不靠谱”，很多时候不是完全答错，而是引用松、结论飘、说得像真但落不到证据上。
所以工程上不能只盯召回指标，还要看 evidence coverage、citation consistency、answer grounding 这些更接近最终体验的指标。否则系统会出现一种很典型的假象：检索报表很好看，但用户依旧不信答案。因为用户要的不是“后台某一步命中过”，而是“最终回答能让我看出它为什么这么答”。
面试里可以收口成一句：
召回命中解决的是“有没有找到”，答案可靠解决的是“有没有用对、讲清、讲一致”。RAG 最后输赢看的是后者。追问方向：如果你只能额外补一个指标来解释“命中率高但答案不可信”，你会优先补哪个？为什么？
17. RAG 里什么时候该先改 chunk，而不是先换模型？
题目：如果一个 RAG 系统效果不好，你会怎么判断问题更可能出在 chunk 策略上，而不是先急着换 embedding 模型或生成模型？
面试官想听什么：你是否理解 chunk 是检索质量的基础切分单位，很多看似“模型不够强”的问题，本质上是知识切分方式先把证据结构打坏了。
短答版：如果问题集中表现为证据被切碎、关键上下文总是断裂、召回结果粒度不对、引用前后文经常缺半截，我会优先怀疑 chunk。模型只能在已有切分上工作，chunk 一旦把语义边界切坏，后面换再强的模型也只能在坏材料上继续优化。
深答版：
展开深答版
这题本质上是在问你有没有抓住 RAG 的一层地基。很多团队一看到效果差，就本能地想换 embedding、换 reranker、换大模型，因为这些组件“更高级、更显眼”。但如果知识在进入索引之前就被切得不合理，后面很多优化其实都是在坏输入上做精加工。chunk 策略决定了证据最小组织单元长什么样，这一步做坏了，后面几层都会连带受损。
什么时候该先怀疑 chunk？典型信号包括：正确答案明明在文档里，但总是被切成两半；召回命中了很多相关段落，却缺关键定义或结论句；单个 chunk 太短导致语义悬空，太长又导致主题混杂；同一问题需要跨 chunk 才能拼出完整证据，但系统总是只拿到半截。此时你看到的可能是“模型答不准”，但根因并不在模型理解，而在证据材料被切分得不适合检索和引用。
相反，如果 chunk 组织已经比较合理，证据也能完整进入上下文，但模型仍然经常排序不稳、整合错误、生成跑偏，那才更值得往 embedding、rerank 或 generation 层看。顺序很重要。先把证据单元设计对，再谈更上层的相似度学习和生成能力，否则容易把底层结构问题误诊成模型能力问题。
面试里可以收口成一句：
模型是在已有证据单元上工作，chunk 决定证据长什么样。证据被切坏了，换更强模型通常只是把坏输入处理得更贵。追问方向：如果一份文档既有定义段、流程段，也有表格和附录，你会怎么设计不同内容类型的 chunk 规则？
18. 什么时候 RAG 的问题其实不是检索问题，而是知识源本身不适合检索？
题目：如果一个 RAG 系统一直答不稳，你会怎么判断问题不在检索器，而在于知识源本身就不适合直接拿来做检索？
面试官想听什么：你是否意识到并不是所有知识都天然适合向量检索，很多失败源头在原始知识形态，而不是召回算法。
短答版：如果知识源高度碎片化、强依赖表结构或跨页关系、包含大量隐含前提、版本冲突严重，或者答案必须经过显式规则计算才能得到，我会先怀疑“源数据不适合直接检索”。这时继续调召回，往往是在不适合的材料上硬做搜索。
深答版：
展开深答版
这题很重要，因为很多团队默认“有文档就能做 RAG”。实际上，RAG 更适合那种可以被切成相对独立证据片段、并且片段本身就带有较完整语义的知识源。如果你的原始材料不是这种结构，检索层再怎么调，也可能只是勉强把问题压住。
不适合直接检索的知识源通常有几类。第一类是强结构化关系数据，比如多张表之间要联查、聚合、比较后才能得出结论，这类问题更像查询和计算，不像检索。第二类是强流程依赖或强时序依赖内容，单个片段离开上下文就失真。第三类是存在大量隐式约束、图表语义、跨章节引用的材料，切成 chunk 后语义会严重塌陷。第四类是版本冲突频繁、源头本身不一致的知识，这种情况下检索只会更快地把冲突送到模型面前。
一旦判断是知识源问题，解决方向通常不是继续堆 rerank，而是先做知识重构。比如把规则显式结构化、把表格转成字段化查询源、把长流程改写成步骤卡片、把版本冲突做治理、把图表语义补成可检索文本。也就是说，RAG 不是万能接入层，有些知识先得被整理成适合检索的形态，检索系统才有发挥空间。
面试里可以收口成一句：
RAG 优化的前提是知识本身适合被检索。源头如果不是证据型知识，而是计算型、关系型或强上下文型知识，先重构知识源往往比继续调检索更关键。追问方向：如果一个知识库里既有 FAQ 文本，也有规则表和审批流程图，你会怎么拆成不同的知识接入方式？