RAG 答非所问别急着换模型:检索优化避坑复盘

我们花了一个多月,做了一个基于 RAG(检索增强生成)的企业知识库问答机器人——把公司几千篇内部文档喂进去,让员工能用自然语言提问、由大模型结合文档内容来回答。Demo 阶段效果惊艳,可一上线给全公司用,投诉就来了:"它答非所问""它在一本正经地胡说""明明文档里写得清清楚楚的东西,它却说找不到"。我一开始的反应,和很多人一样——是不是大模型不够聪明?是不是该换个更强的模型?于是我换了更大的模型、反复打磨提示词,可效果只是略有改善,那种"驴唇不对马嘴"的回答依然层出不穷。

直到我把每次问答时,真正喂给大模型的"参考文档"打印出来看,我才如梦初醒:问题根本不在大模型,而在它之前那一步——"检索"。我喂给模型的所谓"相关文档",很多压根就和用户的问题不沾边;模型是在一堆不相关的、甚至误导性的内容里,被要求"基于这些资料回答"——巧妇难为无米之炊,它能不胡说吗?换句话说,我一直在怪那个"厨师"(大模型)菜做得难吃,却没发现是我递给他的"食材"(检索到的文档)本身就是错的、烂的。这篇文章,就从这次"RAG 答非所问"的事故讲起,聊聊做 RAG 应用时,那个最容易被忽视、却最致命的真相:RAG 的质量瓶颈,绝大多数时候不在"生成",而在"检索"。

故障现场:被"喂错资料"的大模型

先简单说下 RAG 是怎么工作的,这样才好理解坑在哪。一个最朴素的 RAG 流程是这样的:

RAG 问答的基本流程:
1. 离线准备: 把文档切成一段段(chunk), 每段算出一个向量(embedding), 存进向量库
2. 用户提问:
   ① 把"问题"也算成一个向量
   ② 拿这个向量去向量库里, 找出"最相似"的 top-k 个文档片段(检索)
   ③ 把这 k 个片段, 连同用户问题, 一起塞给大模型
   ④ 让大模型"基于这些片段"生成答案(生成)

看出来了吗?第 ③ 步喂给大模型的"参考资料",完全取决于第 ② 步检索出来的那 k 个片段。如果检索这一步召回的片段是相关的、高质量的,大模型就能给出准确的回答;可如果检索召回的是一堆不相关的"垃圾",那大模型就只能基于垃圾来回答——它要么从垃圾里强行编一个(胡说),要么老实说"资料里没有"(明明文档里有,却说找不到)。这就是 RAG 的命门:它的回答质量,有一个"上限"被牢牢卡在检索环节——检索召回的内容质量,就是大模型生成质量的天花板。我那次的所有"答非所问",追根溯源,全都是检索召回了错误的片段。

我具体排查后,发现检索召回质量差,主要栽在两个地方:一是文档切分(chunking)太粗暴——我当时是简单地按固定字数(比如每 500 字)硬切的,结果一个完整的知识点经常被从中间劈成两半,一个 chunk 里又混着好几个不相干的话题,这样切出来的片段,语义本就支离破碎,检索自然不准。二是只靠向量相似度做了一次简单的 top-k 召回,没有任何后续的精排和过滤,导致一些"看起来字面相似、实则答非所问"的片段也被召回了进来。食材的采购(切分)和挑选(检索)两个环节都出了问题,厨师再厉害也救不回来。

第一件事:认清 RAG 的瓶颈在"检索"而非"生成"

这次事故纠正了我对 RAG 一个最根本的误解。做 RAG 之前,我潜意识里把它理解成"一个很厉害的大模型 + 一点文档辅助",所以出了问题,我的第一反应永远是"去优化那个大模型"。可事实恰恰相反:在一个 RAG 系统里,大模型(生成)往往是最不需要担心的一环——现在的大模型,只要你喂给它的资料是准确、相关的,它"基于资料回答"的能力已经相当出色了。真正决定 RAG 成败的、最薄弱的一环,是"检索"——你能不能精准地、从海量文档里捞出那几段真正能回答用户问题的内容。

一个朴素但关键的认知:
  RAG 答案质量  ≈  min(检索质量, 生成质量)

  而现实是: 生成质量(大模型)通常很高且稳定,
            检索质量(找对资料)才是那个拖后腿的短板。

  所以优化 RAG, 80% 的精力应该花在"检索"上, 而非死磕"生成"/换模型。
  口诀: Garbage In, Garbage Out —— 喂垃圾资料, 必得垃圾答案。

这个认知的转变是决定性的:它把我优化 RAG 的精力,从"死磕大模型、调提示词、换更贵的模型"(收效甚微),重新分配到了"如何把检索做准"(收效巨大)上。这其实是软件工程里一个普遍的道理——优化系统,要先找准真正的瓶颈,把力气花在刀刃上;在错误的环节上使再大的劲,也只是事倍功半。对 RAG 而言,这个刀刃,绝大多数时候就是"检索"。想通了这一点,后面所有的优化才有了正确的方向。

第二件事:把文档"切好",是检索的地基

检索优化的第一步,要回到最源头——文档切分(chunking)。因为切分决定了你的知识库里存的"片段"长什么样,而检索就是在这些片段里捞。切得不好,后面再怎么优化检索都是补救。我那次按固定字数硬切,是典型的反面教材;改进的核心思路是:让每个 chunk 尽量是一个"语义完整、主题单一"的单元。

# 反面: 按固定字数硬切, 会把完整知识点拦腰斩断
chunks = [text[i:i+500] for i in range(0, len(text), 500)]   # 粗暴!

# 改进1: 按语义结构切(标题/段落/章节), 保持知识点完整
# 改进2: 切块之间留"重叠"(overlap), 避免边界信息丢失
def split_with_overlap(text, size=500, overlap=100):
    chunks, start = [], 0
    while start < len(text):
        chunks.append(text[start:start + size])
        start += size - overlap        # 每块和上一块重叠 overlap 字, 防边界割裂
    return chunks
# 改进3: 给每个 chunk 附上元数据(来自哪篇文档/哪个章节/标题),
#        既能辅助过滤, 也能在回答里给出准确出处

这里有几个实用的切分原则:一是优先按文档的自然语义结构切(按章节、标题、段落),而不是机械地按字数,尽量让一个 chunk 表达一个完整的意思;二是相邻 chunk 之间保留一定的重叠(overlap),这样即便一个知识点恰好落在两块的边界上,也不至于因为被割裂而两块都检索不全;三是给每个 chunk 带上元数据(它来自哪篇文档、哪个章节),这些元数据既能用来做检索时的过滤,也能让最终答案标注出处、增强可信度。chunk 的大小也要权衡:太大,一个块里混入太多无关信息,稀释了相关性;太小,又会丢失上下文、语义不完整。这个度需要结合你的文档特点去调试,但"语义完整、主题单一"这个目标是不变的。

第三件事:别只靠向量召回,要"混合检索 + 重排"

切好了块,接下来是检索本身。我最初只做了一件事:把问题转成向量,去向量库里找最相似的 top-k——这叫向量检索(语义检索)。它的优点是能理解语义(问"怎么请假"能匹配到"休假流程"),但它也有明显的短板:对精确的关键词、专有名词、产品型号、错误码这类"字面匹配"反而不擅长(你搜一个精确的错误码 "E1024",向量检索可能给你召回一堆"语义相近"却不含这个码的内容)。

# 进阶检索: 混合检索(向量 + 关键词) + 重排序
def retrieve(query):
    # 1. 向量检索: 擅长语义理解(同义、近义)
    vec_hits = vector_search(query, top_k=20)
    # 2. 关键词检索(如 BM25): 擅长精确词、专有名词、错误码
    kw_hits = bm25_search(query, top_k=20)
    # 3. 合并两路召回结果(各取所长, 互补)
    candidates = merge(vec_hits, kw_hits)      # 先广撒网, 召回 ~40 个候选
    # 4. 重排序(rerank): 用更精的模型对候选精排, 选出真正最相关的几个
    reranked = rerank_model(query, candidates)
    return reranked[:5]                         # 只把最相关的 top5 喂给大模型

这套"混合检索 + 重排序"的组合拳,是提升检索质量的关键:第一步用"混合检索"(向量检索 + 关键词检索 BM25 双路召回)来弥补单一向量检索的短板——向量管语义、关键词管精确匹配,两者互补,先尽可能广地把可能相关的候选都召回来(召回阶段宁可多召一点,追求"不漏");第二步用"重排序(rerank)"做精排——召回来的几十个候选里难免鱼龙混杂,这时用一个更强、更精准(但也更慢、所以只能用于少量候选)的重排模型,对这几十个候选逐一打分,挑出真正最相关的那几个,再喂给大模型(精排阶段追求"准")。"先粗召回求全、再精排序求准"的两阶段检索,几乎是提升 RAG 检索质量性价比最高的一招。我把优化前后的检索流程画成对比图:

这张图的核心,是把"检索"从优化前那种"一步到位、粗糙地召回就直接用"的草率做法,升级成了"召回(求全)→ 重排(求准)"的两阶段精细流程。这背后是一个通用的检索智慧:用一个快但粗的方法先把候选范围缩小(召回),再用一个慢但精的方法在小范围里挑出最优(精排)——兼顾了效率和质量。搜索引擎、推荐系统,用的都是这套"召回-精排"的分层思想。

第四件事:在"生成"环节给大模型立规矩

检索做准之后,生成环节虽然不是瓶颈,但也有一个一定要做的加固——用提示词约束大模型"只基于给定资料回答,资料里没有就说不知道,绝不自己编"。因为即便检索做得再好,也难免有"知识库里确实没有用户要的答案"的情况;这时如果不加约束,大模型很可能会发挥它的"创造力",凭自己的训练知识硬编一个看似合理实则错误的答案——这就是 RAG 里最危险的幻觉。

# 给生成环节立规矩: 只用资料回答, 没有就坦白, 并给出处
PROMPT = """你是企业知识库助手。请严格遵守:
1. 只能基于下面提供的【参考资料】回答用户问题。
2. 如果参考资料中没有相关信息, 必须如实回答"根据现有资料, 我无法回答这个问题",
   绝对不许凭你自己的知识编造或推测。
3. 回答时请标注信息来自哪篇资料(出处), 方便用户核实。

【参考资料】
{retrieved_chunks}

【用户问题】
{question}
"""

这段提示词在做三件事:一是"圈定范围"——明确告诉模型只能用我给的资料,把它的回答锁死在知识库内,不让它跑出去用训练时的旧知识;二是"允许示弱"——明确授权它在资料不足时说"我不知道",这一点至关重要,因为模型默认的倾向是"无论如何都要给个答案",你必须显式地告诉它"答不上来是被允许的、甚至是被鼓励的",它才不会硬编;三是"要求出处"——让它标明答案来自哪篇资料,既增强可信度,也方便用户核实、给了用户一个"反查"的抓手。对 RAG 这类"基于事实回答"的应用,"宁可如实说不知道,也不许一本正经地胡编"是一条必须通过提示词显式立下的铁律——一个会坦诚"我不知道"的助手,远比一个永远自信、却时常胡说的助手可靠。

把检索和生成两端的优化手段汇总一下,我整理成一张"RAG 优化抓手"表:

第五件事:按"现象"对症下药

有了上面这些抓手,实战中怎么用?关键是学会根据 RAG 出问题的"具体现象",反推是哪个环节的毛病,再对症下药,而不是眉毛胡子一把抓。我把常见的失败现象和对应的排查方向列成一张表:

这张表传达的核心方法,是"先定位环节,再针对性优化":RAG 是个多环节的流水线(切分→召回→精排→生成),哪一环出问题,表现出来的"症状"是不一样的。学会从症状反推病灶,你就能把有限的精力,精准地投到真正出问题的那一环,而不是盲目地"换个模型试试""调调提示词看看"。特别注意倒数第二行:只有当你确认"喂给模型的资料是对的、相关的,它却答得不好"时,才轮到去优化生成、去怀疑模型——在那之前,先老老实实地把检索查清楚。这正是本文最想强调的那条主线:遇到 RAG 问题,先看检索,再看生成。

一张"RAG 答不好怎么查"的决策图

把这次踩坑沉淀的排查思路,做成一张图。下次你的 RAG 答得不好时,别急着换模型,照着它走一遍:

这张图的第一步,也是整篇文章最想让你记住的动作:RAG 答不好,第一件事永远是"把真正喂给大模型的检索片段打印出来看"。这一步能瞬间帮你分清问题在哪——片段里压根没有正确答案,那是检索的锅(占绝大多数);片段里明明有正确答案、模型却没答好,那才轮到怀疑生成。我那次走了一个多月弯路,就是因为一直没做这个最简单的动作,凭想象认定"是模型不行",结果南辕北辙。一个简单的"打印中间结果"的动作,胜过一万次对着黑盒的瞎猜。

我立下的几条 RAG 工程经验

这次"RAG 答非所问"的事故后,我把这些用一个多月弯路换来的经验,沉淀成了几条:

1. 优化先看检索:RAG 答不好,先排查检索召回的片段对不对,而非第一时间去换模型、调提示词。
2. 必先打印中间结果:把每次真正喂给大模型的检索片段打出来看,这是定位问题最快、最有效的一步。
3. 切分要语义完整:按语义结构切 chunk、留重叠、带元数据,别用固定字数硬切割裂知识点。
4. 用混合检索 + 重排:向量召回管语义、关键词召回管精确,合并后再 rerank 精排,先求全再求准。
5. 生成端约束防幻觉:提示词明确"只基于资料回答、没有就说不知道、标注出处",绝不许硬编。
6. 建评估集量化迭代:准备一批"问题-标准答案"测试集,量化检索命中率和回答质量,让优化有据可依而非凭感觉。
7. 知识库要维护更新:文档会变,建立定期重新切分、重新索引的机制,避免答案过时。

这几条里,第一、二条是纲。我尤其想再强调第六条"建评估集"——这是从"玩具 Demo"迈向"生产级 RAG"的分水岭。没有评估集,你所有的"优化"都只是凭感觉瞎调:换个切分策略,感觉好像好点了?加个重排,好像也还行?——全是主观臆测,无法量化、无法对比、无法持续改进。而有了一批"标准问答测试集",你就能客观地量化每次改动的效果(检索命中率从 60% 提到了 85%、回答准确率提升了多少),知道每一步优化到底有没有用、用了多少。"可量化"是"可持续优化"的前提——这对 RAG 这种效果"看起来玄乎"的 AI 应用,尤其重要。

写在最后:AI 应用,七分工程三分模型

这次做 RAG 踩的坑,彻底改变了我对"AI 应用开发"的认知。在做之前,我以为做一个 AI 应用,核心就是"用好那个大模型"——模型是主角,我做的不过是给它搭个壳、传个话。所以一出问题,我满脑子都是"模型不行""换个模型""调提示词"。可这一个多月的折腾让我看清:一个 RAG 应用最终好不好用,大模型本身的贡献可能只占三成,而剩下七成,全在模型之外那一整套"工程"里——文档怎么切、怎么存、怎么检索、怎么重排、怎么组织上下文、怎么约束生成、怎么评估迭代。大模型是那颗珍贵的"芯片",但要让它真正发挥价值,你得给它配上整整一台精心设计的"机器"。

这个"七分工程、三分模型"的认知,让我对 AI 应用开发者的价值有了新的理解。在大模型能力日益强大、且越来越触手可及(谁都能调 API)的今天,单纯"会调用大模型"已经不再是壁垒——真正的壁垒、真正能拉开应用质量差距的,是模型之外的那套工程能力:你能不能把数据处理好、把检索做准、把上下文组织好、把异常兜住、把效果评估并持续优化。这套能力,恰恰是我们这些"传统"软件工程师最擅长、也最有积累的地方。所以 AI 时代非但没有让工程能力贬值,反而给了它一个全新的、巨大的舞台:模型负责"智能",而把这份智能可靠地、高质量地落地成一个真正好用的产品,靠的还是扎实的工程。

所以,如果你也在做 AI 应用、做 RAG,我想把这次踩坑最想说的话送给你:别把目光只盯在那个大模型上,别一出问题就归咎于"模型不够强"。把更多的心力,投到模型周围那一整套工程里去——去把你的数据切好、存好,去把检索打磨准,去把上下文组织清楚,去给生成立好规矩,去建起能量化的评估体系。因为决定你的 AI 应用是"惊艳的 Demo"还是"好用的产品"的,往往不是你用了多强的模型,而是你在模型之外,做了多少扎实的工程。那个曾经让我以为"是模型不行"的 RAG,在我把检索这套工程认真做好之后,脱胎换骨——而我也由此真正理解了:在 AI 的时代,工程,依然是那座最深、最可靠的护城河。愿你也能守好它,让你手中的大模型,真正长成一个让人离不开的好产品。

—— 别看了 · 2026