RAG面试题深度解析（一）：6个高频技术问题的背后逻辑

前段时间在找工作，投了不少做RAG相关业务的公司。面试下来发现，大家问的问题还挺有意思的，表面上看起来很基础，但想要答好还真不容易。

今天整理了6道比较经典的题目，跟大家分享一下我的思考。不是标准答案啊，主要是想聊聊这些问题背后到底在考什么。

为什么面试官喜欢问这些？

说实话，刚开始我也挺困惑的。为啥不问些具体的技术实现，偏偏问这些看起来很"虚"的问题？

后来想明白了，这些问题其实都是实际工作中会遇到的坑。搭一个demo很容易，但要让系统在生产环境稳定运行，你得能解决各种奇奇怪怪的问题。面试官通过这些问题，能快速判断你有没有踩过这些坑。

让我们逐一来看这些问题。

问题0：怎么优化RAG中的检索速度和召回精度？

这道题其实在考什么？

这题一看就是经典的鱼和熊掌不可兼得的问题。实际做项目的时候，产品经理总是希望检索又快又准，但技术上你知道这两个目标是冲突的。面试官就想看看你怎么处理这种矛盾。

我的理解

说白了，这就是个资源分配的问题。你有限的计算资源，是用来提速还是用来提精度？我觉得可以从几个角度来看：

索引这块儿
选索引算法就像选车，HNSW就像豪车，造价高但跑得快；IVF像家用车，各方面都还行。具体怎么选得看你的业务场景。

模型维度的选择
Embedding维度就像图片分辨率，越高越清晰，但文件也越大。我之前做过实验，从512维到1024维，精度确实有提升，但存储和计算成本直接翻倍。得算性价比。

分层检索策略
这个思路挺巧妙的，就像筛沙子一样。先用粗筛子快速过一遍，拿到候选集；再用细筛子精挑细选。速度和精度都能兼顾到。

面试时怎么回答？

我建议别只盯着一个点说，展现一下全局思维：

• 聊聊不同索引的适用场景
• 提到分层检索的好处
• 强调要通过实验数据来决策，不能拍脑袋

问题1：如何设计智能分块策略来处理结构化文档？

这道题想考什么？

这题挺有意思的，说的是传统那种按固定字符数切分的方式，在处理财报、法律条文的时候经常把关键信息给切断了。比如一个财务指标的说明被切成两半，前半句在这个块里，后半句跑到下个块去了。

面试官其实想看你有没有意识到文档是有结构的，不能粗暴地一刀切。

我踩过的坑

以前做过一个法律文档检索的项目，刚开始就是简单按1000字符切分，结果用户问一个法条的时候，经常检索不到完整的内容。后来才发现，法律条文有很明显的层次结构，应该按条款来分。

几个经验：

文档结构很重要
财报有章节、表格、注释；法律条文有条、款、项。这些都是天然的分割点，比机械切分靠谱多了。

信息密度不一样
有些地方信息很密集，比如财务数据表格，需要切小一点方便精确检索；有些地方比较松散，可以保持大块来维持上下文。

NLP技术的应用
现在有些工具可以自动识别段落边界、章节标题，比纯粹按字符数切要智能很多。

面试时这样说

回答这题的时候，最好能举个具体例子，比如：

• 说说你遇到过的文档切分问题
• 解释为什么要按结构而不是按字符切分
• 提到如何平衡切分粒度和语义完整性
• 如果有实际的改进效果数据就更好了

问题2：如何构建专业领域的检索微调数据集？

这题想考啥？

这题很实际，通用的embedding模型在专业领域经常水土不服。比如医学里的"MI"指的是心肌梗死，但通用模型可能理解成Michigan（密歇根州）。面试官想看你知不知道怎么解决这个问题。

我的经历

之前给一个医疗公司做过类似的项目，刚开始用的是通用的sentence-transformer，效果惨不忍睹。医生问"冠心病的治疗方案"，系统给出的结果里竟然有心理学的内容。

后来才明白，专业领域的坑主要在这几个地方：

专业术语理解偏差
同一个词在不同领域意思完全不一样。"细胞"在生物学和监狱管理中是两个概念。

负样本很重要
我发现很多人只关注正样本，但负样本的质量决定了模型的判断能力。要构造那种"看起来很像但实际不相关"的样本。

数据标注的层次
不能只标注文档级别的相关性，词语、段落、文档都要标注。这样模型才能学会不同粒度的语义关系。

这样回答比较好

面试时记得强调这几点：

• 举例说明专业领域的特殊性（比如术语歧义）
• 提到负样本构造的重要性
• 说说多层次标注的必要性
• 如果有和领域专家合作的经验就更好了

问题3：Re-ranker模型过滤掉相关文档的问题诊断

这题考什么？

这是个很实际的生产问题。Re-ranker本来是用来提升精度的，结果反而把最相关的文档给过滤掉了，这就很尴尬了。面试官想看你有没有系统性的debug思路。

我遇到过类似的情况

去年在一个客服系统里遇到过这个问题，用户问产品功能，系统总是给出无关的答案。后来发现是Re-ranker的锅，它把真正相关的文档排到了后面。

排查下来，主要问题在这几个地方：

训练数据有问题
我们的训练数据里有很多人工标注的错误，Re-ranker学到了错误的排序模式。垃圾进，垃圾出。

模型太"激进"了
模型的判断标准太严格，只要不是完全匹配就给低分。这在实际使用中显然不合适。

阈值设置不当
我们把过滤阈值设得太高了，很多中等相关的文档都被误杀了。

面试时怎么说？

记得从系统排查的角度来回答：

• 先检查训练数据质量，这是最常见的问题
• 再看模型的决策逻辑是否合理
• 最后提到要用A/B测试来验证修复效果

问题4：基于大模型的查询重写（HyDE）

这题想考什么？

这个问题挺有意思的。用户问问题的时候往往很口语化，比如"感冒了咋办？"但你的文档库里写的是"感冒的临床治疗指南"。这种表达差异导致检索效果很差。

HyDE这个技术就是用来解决这个问题的，面试官想看你理不理解它的巧妙之处。

HyDE的巧思

这个技术的核心思路挺巧妙的：

用户问题 vs 文档内容的差异
用户说话比较随意，"感冒了咋办"；但医学文档写得很正式，"上呼吸道感染的诊疗规范"。直接匹配效果肯定不好。

让AI"预想"答案
HyDE让大模型先"想象"一个理想的答案是什么样的，然后用这个想象出来的答案去做检索。因为这个假设答案的表达方式更接近真实文档。

从问题到内容的桥梁
本质上是把模糊的用户意图转换成了具体的内容描述。

面试回答思路

重点突出技术的核心价值：

• 解释用户查询和文档内容之间的表达差异
• 说明假设文档如何起到桥梁作用
• 可以提到一些可能的改进想法，比如多轮重写等

问题5：HNSW索引参数的量化调优

这题考什么？

这是个挺技术的问题，主要考你对HNSW索引的理解，以及有没有实际调优的经验。HNSW里有两个关键参数M和ef_construction，设置不当会严重影响性能。

我的调优经历

之前做过一个大规模检索系统，刚开始就是用的默认参数，结果性能很一般。后来花了不少时间调优，才发现这里面的门道。

M参数的影响
M是每个节点的连接数。设小了检索不准，设大了内存爆炸。我们从16试到64，最后发现32是最佳平衡点。

ef_construction的权衡
这个参数控制建索引时的搜索宽度。大了质量好但建索引慢得要死，小了建得快但质量差。

实验很重要
调参数不能靠感觉，必须设计对照实验。我们用了多个指标：查询延迟、召回率、内存使用量，最后找到了最优组合。

面试时要点

记住这几个要点：

• 解释参数的物理意义，别只背数字
• 提到多指标评估的重要性
• 强调要结合具体业务场景来调优

问题6：父文档-子文档检索策略

这题想考什么？

这个策略挺巧妙的，是为了解决一个很现实的问题：小文档块检索精准但上下文不够，大文档块上下文足够但噪音太多。怎么办？

我见过的解决方案

之前在一个知识库项目中用过类似的策略，效果确实不错。

核心思路
用小块来检索（精准定位），用大块来返回（完整上下文）。就像用望远镜找到目标，然后用肉眼看全景。

技术实现
我们把长文档切成两套：精细的子文档用来检索，粗粒度的父文档用来提供上下文。检索时用子文档，返回时给父文档。

工程复杂度
这个方案需要维护文档间的层次关系，存储成本会增加，但效果提升明显。

回答要点

面试时重点说这几个：

• 解释小块vs大块的矛盾
• 说明分层检索的巧妙设计
• 提到实现的技术难点和成本考虑

聊聊我的感受

分析完这6道题，我发现一个有趣的现象：这些问题都没有标准答案。

每个问题背后都是一个权衡问题：

• 要速度还是要精度？
• 要通用性还是要专业性？
• 要简单易维护还是要功能强大？
• 要节省成本还是要最好效果？

这就是为什么这些问题难答的原因。面试官不是想听你背书，而是想看你怎么在复杂的现实场景中做技术决策。

几个面试小建议

基于我自己的面试经历，总结几个小贴士：

别只说技术，要谈场景
同样的技术在不同场景下选择完全不同。比如HNSW索引，对于实时性要求高的场景很合适，但对于离线批处理就没必要。

多举具体例子
面试官最怕听到"应该"、"可能"这种虚词。你说"我之前遇到过类似问题"，立马就不一样了。

承认技术的局限性
没有完美的方案，每种选择都有代价。坦诚地说出限制条件，反而显得专业。

准备一些数据
如果能说出"改进后召回率提升了15%"这种具体数字，会给面试官留下深刻印象。

希望我的这些想法对你有帮助。RAG这个领域还在快速发展，新的问题和解决方案层出不穷，大家一起学习进步吧！