★ FEATURED ARTICLE 上个月帮人复盘面试时聊到RAG我发现一个现象准备过大模型岗位面试的人几乎人人都能说出“切分chunk、向量检索、重排”这几个词但一旦面试官往深处问“你觉得RAG有哪些核心痛点”就容易卡住——不是没话说而是说得太散想到哪说到哪。后来我把RAG从准备到上线的完整链路过了一遍整理出了下面这九个高频痛点。这篇文章既适合正在备战大模型面试的人也适合那些已经把手上的RAG项目从Demo推向生产环境、但总觉得效果差口气的工程师。RAGRetrieval-Augmented Generation这条技术路线看上去很直白先检索相关资料再交给大模型生成回答。但真正落地过的人都知道每一环都可能埋着坑。面试官问“RAG的痛点有哪些”时想听的往往不是你能数出几个问题而是你能不能说清楚问题出在哪一步、根因是什么、以及你打算用什么方法验证和收敛。所以我把九个痛点按照“知识准备层、检索理解层、生成与系统层”三层来拆逐个给出现象、根因、解法以及面试现场怎么表达会更有层次感。1. RAG为什么“人人都在谈落地处处坑”先建立全局视图1.1 面试官用痛点题考察的三个能力很多人以为痛点题是“知识题”背熟几张清单就能过关。我复盘了多轮面试反馈后发现面试官其实在借这道题考察三个更底层的能力。第一有没有全局认知。RAG不是“embedding 大模型”两个组件拼起来就完事而是包含文档解析、切分、索引、召回、排序、上下文组装、生成、评估的一条长链路。能沿着请求链路把痛点定位到具体环节的人说明真的在系统里摸爬过。第二能不能区分“模型问题”和“工程问题”。比如回答质量差有人第一反应是换更大的模型但实际情况往往是检索回来的上下文本身就错了或者文档切分把答案搞碎了。第三有没有取舍和度量意识。每个痛点都有至少三五种解法面试官想听的是你根据什么条件选型而不是你把所有方案念一遍。1.2 一条请求在RAG系统里的完整流转每个环节都可能丢分我习惯把RAG的请求链路画成一条流水线用户问题进来后先经过查询理解改写、扩展、路由然后进入检索模块向量召回、关键词召回或混合召回接着是重排和过滤再把选中的文档片段组装成上下文最后交给大模型生成回答生成之后如果有条件还要做一层校验。这条链路里几乎没有一步是“零损耗”的。为了把后面九个痛点串起来我列了一张对应表面试时先讲这张表再展开细节会显得很有条理。链路环节容易出现的症状对应痛点查询理解用户问题太口语化和文档表述对不上痛点四文档切分答案被拦腰切断语义不完整痛点二索引与召回检索结果大量无关或漏掉关键文档痛点三排序过滤正确答案排名太靠后被错误拼进上下文痛点五上下文组装塞入太多噪音生成质量反而下降痛点八生成阶段模型编造知识库中不存在的内容痛点七线上反馈出问题后无法定位是召回还是生成环节痛点九这张表还有一个好处它天然引导着面试官往下一层追问而你已经提前把回答框架铺好了。接下来我就按这三层逐个讲透九个痛点。2. 九大痛点逐条拆解现象、根因、解法与面试回答要点2.1 知识准备层的三个痛点时效性、切分粒度、索引质量痛点一知识时效性与更新困难。现象很典型知识库里某份业务规则已经改版了但线上系统还在用旧版本回答用户。根因通常不是大模型的问题而是更新机制没跟上。文档被替换后没有触发对应索引的增量更新旧chunk还躺在向量库里更隐蔽的是缓存层如果热门的旧答案被缓存下来了即使索引更新了用户还是会在短时间内拿到过期内容。解法上比较有效的是“版本号 事件驱动更新”给每个文档维护版本号文件变更时写入更新队列异步重建该文档相关的chunk和向量缓存要设计失效策略给敏感业务短TTL让新版本能及时透出。面试回答时不要只说“我们会定期全量更新”要说清楚“什么时候走增量、什么时候走全量、缓存的旧答案如何处理”这一层细节才体现工程经验。痛点二文档切分粒度与上下文割裂。这是所有RAG项目里最常见也最容易被低估的坑。很多初版Demo会按固定字符数量切分文档比如每512字切一块。但文档有自己的结构业务规则往往依赖上下文硬切会把“本政策适用于所有直营门店”和“不含加盟店”切成两个块。用户检索到前半句时模型就很容易给出过度扩大化的错误结论。我见过一个客服知识库项目最初的错误答案里有一大半都能追溯到表格被截断、规则被切开这类问题。解法基本分两个层次。第一层是结构感知切分根据Markdown标题、段落边界、表格的行列结构、代码块边界来切割而不是只数字符。第二层是“父子块”策略检索时命中小块子块生成时返回它所在的完整大块父块保证答案单元的上下文完整。面试时如果能把这两层都讲出来会比单纯说“chunk设成512、重叠50”有说服力得多。痛点三索引质量与召回率不足。这个痛点的表象是“检索结果乱七八糟”。具体分两种情况一种是用户问题很明确但向量召回返回了一堆语义沾边却实际无关的内容另一种是召回结果太少关键文档根本没进候选集。根因主要有三个embedding模型和领域不匹配、索引参数没调、只用单一向量检索一条路走到黑。比如一些通用embedding处理专业术语时语义相似度和业务相关性会发生明显偏移这时候再叠加大模型能力也救不回来。成熟的做法是混合检索BM25关键词召回跑一路向量召回跑一路合并后再做重排。关键词能兜住“术语精确匹配”的场景向量能兜住“语义相似但用词不同”的场景两者互补性极强。面试表达上记得强调召回环节的目标不是“尽量精确”而是“尽量别漏”把相关性判断交给后面的重排环节去解决。2.2 检索理解层的三个痛点查询理解、排序精度、多跳推理痛点四查询理解与改写能力弱。用户在真实场景里提问时口语化程度比我们想象中高得多。用户可能问“这个季度的退款怎么比上个季度多这么多”而知识库里对应文档的表述是“2025年Q2退款率环比分析”。词汇鸿沟会让向量检索的对齐效果很差。根因很简单检索默认假设“用户问题”和“文档表述”处在同一个语言空间但现实中根本不是。解法里有两条路特别值得提。一条是查询改写让大模型把原始问题改写成更书面、更适合检索的形式甚至可以生成多个query变体分别检索后合并结果。另一条是HyDEHypothetical Document Embeddings先让大模型写一段“假设性答案”再拿这段答案去检索。理由也很朴素——假设性答案的语言风格接近文档用它去和文档做相似度匹配往往比拿口语化问题直接检索更稳。面试时讲清楚这个“把查询翻译成文档语言”的思路会比只报方案名更容易打动人。痛点五检索排序与相关性判断失准。很多人做RAG时会忽略排序这一步直接把召回的top5按得分拼进上下文这是现阶段RAG效果不稳的常见原因。向量相似度高并不等于业务上相关BM25的词频高也不等于语义上正确。最典型的情况是正确答案确实在候选集里但因为排序分数低而没进最终上下文导致模型看着一堆次相关的内容生成答案。解法是在召回和生成之间加一个重排模块。常见的做法是用一个更精确的排序模型比如交叉编码器对候选集做二次打分取有限的top结果进入上下文。如果业务有强规则也可以在重排阶段做元数据过滤比如强制“只能选择生效日期在今天的文档”或“只能选择指定权限范围的文档”。面试时可以总结成一句话召回要宽精排要准最后进生成器的那几块内容必须是“瘦身后”的高质量证据。痛点六多跳问题拆解与证据聚合能力不足。有一类问题单个文档回答不了需要跨多个文档来推理。比如“某个产品在某区域的销量和另一个产品在另一些区域的销量相比谁更高”信息分散在两个表格里单次检索根本不可能同时拿到完整证据。如果RAG系统只用“一次召回、一次生成”这类问题基本必错。解法方向是“先拆后合”把复杂问题分解成多个子查询分别检索再把证据统一交给大模型聚合回答。更进阶的可以做成迭代式检索第一轮检索后让模型判断还缺什么信息据此生成下一轮查询直到证据链闭环。面试时一定要明确承认单次检索的天花板然后立刻给出“多轮检索 证据聚合”的思路这比含糊其辞说“我们模型能力强”高级得多。2.3 生成与系统层的三个痛点幻觉、上下文管理、评估缺失痛点七生成幻觉。幻觉是RAG最容易被放大讨论的问题。最典型的表现是知识库里根本没有相关信息或者只有部分相关信息模型却在回答里言之凿凿地补全了细节。根因有两个层面一是prompt约束不够硬模型默认自己是“万事通”不会承认不知道二是检索结果本身质量差时模型宁可自己编也不愿意复述证据。应对幻觉不是靠模型自觉而是要靠机制。第一强制引用溯源生成时要求答案附带来源编号比如“根据文档[1]”后处理时检查引用编号是否真实存在缺失就拦截或降级回答。第二增加“不知道”选项在prompt里明确告诉模型检索到的内容不足以回答时就直说不知道而不是强行组织答案。第三生成后校验用专门模型判断“答案是否被检索证据支持”如果支持度不达标宁可返回“未找到可靠答案”。面试里提“允许模型拒答”其实是很加分的产品思维。痛点八上下文窗口管理混乱。有些团队会陷入一个误区模型支持的上下文越长就越应该把更多检索结果塞进去。实际效果往往相反。检索回来的chunk多了噪音也多了模型的注意力被无关信息稀释核心答案反而答不全。另一个常见问题是截断策略太粗暴为了塞进窗口直接把排在后面的内容切掉而切掉的可能恰恰是某个表格的结论行。解法上先重排后裁剪只保留最相关的少量证据进入上下文对超长chunk先做摘要压缩再参与拼接系统提示词要保持稳定别让动态检索内容把指令部分给冲散了。我个人的经验是很多RAG系统不是内容不够而是噪音太多与其追求“塞得更满”不如追求“留得更少”。痛点九端到端评估与可观测性缺失。这是九个痛点里最容易被忽视、但影响最深的一个。没有评估体系前面所有优化都是盲人摸象。很多项目上线后只看接口成功率完全不知道“答非所问”在真实用户那里占了多少比例。更糟的是线上出问题时只能猜是检索没召回到是排序排错了还是模型没按上下文回答没有追踪数据连定位都做不到。解法要分两层。第一层是离线评估按检索和生成分别设指标。检索侧看Recallk、MRR这类传统指标生成侧看忠实度faithfulness和答案有用性。还应该维护一份高质量的hard case集每次改版跑一遍回归。第二层是在线可观测给每条请求留trace日志记录原始问题、改写后的query、召回的候选文档、重排后的顺序、最终进入上下文的片段、模型输出出问题时可以完整重放单个请求。面试时说“没有评估就没有优化方向”这一句话就能体现出你是认真做过系统的。3. 痛点题的回答逻辑背方案只是及格讲出取舍才是加分3.1 同一个痛点的三个回答层次九个痛点内容不少但面试回答质量高低的差别往往不在“知不知道痛点”而在“怎么展开解法”。我用最经典的切分问题来演示一下三个层次。第一层是“背名词型”回答是“我们用512字符切分重叠50个字符”。这种回答面试官听过一千遍没有任何信息增量。第二层是“讲策略型”会说“不同文档用不同策略纯文本按段落和标题切PDF扫描件先OCR再做版面分析表格按行和结构单元保留长文档用父块回传”。这已经能体现实际操作经验可以算及格偏上。第三层是“讲目的型”会进一步说“切分的终极目标不是让chunk变得整齐而是让检索单元和答案单元对齐。所以先看文档结构再看用户问题对答案单元的依赖方式还要用线上失败case反推是不是切分导致信息割裂”。第三层之所以加分是因为它把“切分”从一个操作参数上升到了“检索单元设计”的层面而且给出了验证闭环。准备面试时我给A同学的建议是每个痛点都至少准备到第三层即“目的—判断—验证”三段式。目的说明为什么用这个方案而不是别的判断说明你根据什么条件做选型验证说明你怎么知道它有效。3.2 反直觉的经验RAG问题更多出在数据管道不是模型能力有一个观察在面试里说出来很能体现工程深度大部分RAG效果差的项目问题根源不在于大模型不够聪明而在于数据管道有缺陷。文档没解析干净、表格被截断、切分把语义拆碎、索引没有及时更新这些工程侧的脏活累活对最终效果的影响往往比换一个更强的模型更显著。我印象很深的某个知识库项目就是这种情况。初期团队在重排、embedding选型上花了很多时间效果总不稳定。后来排查发现一批核心业务表格在PDF转文本时全乱掉了检索系统拿到的本来就是错误内容。把表格解析按行列结构重做之后整体回答正确率直接提升了一个台阶而大模型这边几乎没有改动。这件事放到面试里反过来就是很好的表达提到痛点时主动说“我先看数据侧再看模型侧”同时举一个排查顺序的例子。面试官会高度认可这种不迷信模型能力的工程判断。4. 把九个痛点串成一套系统设计面试现场能直接用的组合方案4.1 四层改进框架预处理、召回增强、生成控制、闭环评估面试现场如果只答“痛点有哪些”终归是防御姿态。更高阶的答法是把痛点串成一套改进方案展示你不仅能发现问题还能把问题揉进一个系统里解决。我习惯用四个层面来组织。预处理层解决痛点一和痛点二文档解析要尊重原始格式切分要跟随文档结构更新要走版本号和增量队列。召回增强层解决痛点三到痛点六查询改写、多路召回、重排过滤必要时拆解多跳问题。生成控制层解决痛点七和痛点八上下文只保留高质量证据生成时强制引用溯源支持“不知道就拒答”。闭环评估层解决痛点九离线跑指标和hard case线上留trace日志每次改动出对比报告。这个框架的好处是面试官无论从哪个痛点追问你都能立刻定位它属于哪一层然后给出该层和其他层的联动方案。比如生成幻觉不只是生成层的事它可能源于召回层没有提供证据也可能源于评估层没有及时暴露问题。能讲出“层与层之间的关系”比孤立列举方案要立体得多。4.2 一个客服问答系统的改进示例为了让这套框架更好复述我以一个常见的客服问答系统为例列出它的“初版方案”和“改进版方案”。这个例子面试时可以直接借用只需要根据提问方向调整细节。环节初版方案改进版方案文档处理PDF直接转文本后按固定字数切分先OCR解析表格和版面按结构切分维护文档版本号查询处理用户原问题直接检索用LLM做查询改写生成1-2个变体必要时走不同知识库路由召回策略仅用向量召回top5BM25 向量混合召回各取若干候选后合并排序过滤按向量分数取top5直接拼上下文增加重排模型结合业务规则过滤只留top3上下文组装尽可能多塞内容裁剪和摘要后只保留高相关证据控制总长度生成方式直接让模型回答强制引用来源答案需要标识出处片段质量校验无生成后用模型判断答案是否被证据支持不通过则拒答线上监控只有接口成功率全链路trace日志离线失败case定期回归如果面试官让你详细描述其中某一步可以用这段简化伪代码展示系统主流程。def rag_pipeline(query): # 痛点四查询改写生成多个检索变体 query_variants rewrite_query(query) # 痛点三混合召回互相兜底 candidates hybrid_retrieve(query_variants) # 痛点五重排与业务过滤缩小到高质量证据 top_evidence rerank_and_filter(query, candidates, limit3) # 痛点八上下文裁剪只保留必要信息 context build_trimmed_context(top_evidence) # 痛点七生成时强制引用并允许拒答 answer generate_with_citation(context, query) # 痛点七/九支持度校验不达标就拦截 if not verify_supported(answer, context): return 未找到可靠答案请尝试补充更多信息。 return answer这段伪代码最大的价值是让每一个痛点都有具体的落点面试官听完会觉得你不是在背题而是真的动手搭过完整链路。5. 面试现场最容易追问的三个细节切分、延迟、拒绝回答5.1 被问到“chunk切多大合适”怎么答这类追问看起来是在问参数实际上是在考你对“检索单元”的理解。我的回答逻辑是先给一个可操作的起点再快速转入判断依据。起步值可以参考主文档500到800字左右设置10%到15%的重叠这个范围在多数场景下不会太差。但更重要的是往下说切分粒度要服从文档结构Markdown按标题层级拆代码按逻辑块拆表格按行列语义单元拆扫描版PDF要先做OCR和版面分析再切。如果担心信息割裂可以加父块回传机制让检索命中小块、生成使用完整大块。这样回答等于把一道参数题拔高到了设计题面试官想继续追问也只能沿着你的框架往下走。5.2 被问到“向量检索慢怎么办”怎么答延迟问题在线上RAG系统里几乎必被追问。我会先分清场景再给方案。如果数据量大先缩小候选范围再精排比如先用BM25或轻量级模型粗筛出可能相关的几百条再用向量检索或重排模型精排。如果查询流量高常见query结果可以做缓存热点问题可以直接命中缓存。如果索引规模在大幅增长可以调向量索引的构建参数用近似检索换取速度提升。最后一定要主动把“延迟、召回率、硬件成本”三者之间的权衡讲出来。没有参数的调优方案是不完整的面试官想确认你有没有在真实环境里背着延迟预算做过选择。5.3 被问到“检索不到答案还硬生成”怎么答这个问题是从痛点七延伸出来的高频追问。核心是改变模型的“默认心态”允许不知道比强行知道更安全。做法至少三层。第一层是在prompt里给“不知道”一个明确的落点比如“检索内容不足以回答时请直接回复资料库中未找到可靠答案”。第二层是检索侧做置信度判断如果重排分数低于阈值直接不生成。第三层是生成后校验拿答案和证据做支持度比对不合格就拦截输出。这里有个容易被忽略的产品视角当知识库确实没有答案时RAG的正确表现不是“努力回答”而是“诚实暴露信息缺口”这反而是更符合用户长期利益的。面试中能把“产品体验”和“技术方案”接在一起讲是非常加分的。6. 最后分享一点整理这组痛点后的个人体会这九个痛点梳理下来我最大的感受是RAG看起来简单难在细节环环相扣。知识切分切得不好后面所有环节都在错误基础上工作查询不改写检索再强也不一定召回到位生成不校验幻觉就会悄悄溜出去。真正把系统从能跑做到稳定可用靠的不是某一个惊艳的模块而是每个环节都经得起拆解和度量。给你一个准备面试的小建议与其把九个痛点的标准答案背得滚瓜烂熟不如挑一个自己在项目里真实踩过的坑把当时的判断、失败后的现象、调整方案和最终验证讲完整。面试官每天听太多标准答案你手里那个具体的失败case比任何教科书式的回答都更让人记得住。这套题考到最后考的不是记忆力而是你有没有在一堆“看起来都能解决”的方案里说清楚自己做判断的依据和代价。能说清楚这个这场面试就算没白准备。
阅读完成 · 觉得有帮助？
