
大家好，我是晚安code。

假设一个场景，有个做 RAG 的活儿，给售后知识库搭问答。第一版上线就被业务怼了：用户问「退货要几天到账」，它回了一段「签收后 7 天内可申请」——条款本身没错，但答的根本不是这个问题。

第一反应是模型不够强，从便宜换到贵的，换了两轮，效果一点没动。

![](https://developer.qcloudimg.com/http-save/yehe-12591818/5c79f353641a8a39e9fbbd968069ef6a.webp)

最后查出来的原因很朴素：切分的时候按固定字数硬切，把「退货时效」那张表切成了两半，表头在上一块、数字在下一块。检索召回的永远是半句话，模型再强也只能拿着半句话编。

这篇把 RAG 是什么、怎么工作、以及为什么效果差，一次讲透。全程配可跑的代码，建议先点个收藏。

## 一、先给结论：RAG 的瓶颈在检索端，不在生成端

**RAG 的效果上限，是被检索质量卡住的，不是被模型能力卡住的。**

先把这个词的定义钉死。

**RAG（Retrieval-Augmented Generation，检索增强生成）**：在让大模型回答之前，先去你的知识库里捞出相关资料，把资料连同问题一起交给模型，让它照着资料答。类比一下，就是把闭卷考试改成开卷考试。

这个类比的妙处在于：闭卷考的是「背没背过」，开卷考的是「会不会查」。RAG 给模型加的是**查**的能力，不是**背**的能力。

想通这一层，排查思路就顺了。它答错了，只可能是两种情况：

1. **它没查到**——召回的结果里压根没有正确答案。这是检索端的问题。
2. **它查到了但答错了**——正确内容就在 Top-K 里，模型没用上或者用歪了。这才是生成端的问题。

所以拿到一个效果不好的 RAG，我的排查顺序固定是：先把召回结果打出来，人眼看一遍有没有正确答案，再决定往哪修。

顺序反过来会怎样？我替你试过了，就是开头那个换两轮模型的白忙活。

**RAG 不是让模型变聪明，是给它的输出接一条可核验的来源线。** 这条线接在哪一段，比线另一端接的是哪家模型重要得多。

![闭卷考的是记忆，开卷考的是检索——RAG 换的是考法，不是考生。](https://developer.qcloudimg.com/http-save/yehe-12591818/ee1ba08b50fb639c2bbc2ae59781b6dd.png)



## 二、RAG 要解决的是大模型的三道硬伤

**RAG 不是为了把模型变聪明，是为了绕开大模型天生的三个短板。**

这三个短板不解决，任何模型都躲不掉：

1. **知识停在训练截止日。** 模型权重是训练那一刻冻住的知识。训练结束后的新政策、新价格、新流程，它一概不知道，而且是不知道自己不知道。
2. **不知道时会硬编。** 这是最要命的一条。
3. **答错了你查不到依据。** 它给一段通顺的答案，你没法判断这句是记住了还是编的，合规场景里这没法用。

第二条单独拎出来说：

**大模型幻觉（Hallucination）**：模型在不知道答案的时候，仍然按语言概率生成一段通顺、具体、但事实错误的内容。类比一下，它不是撒谎，是「太想把话说圆」——为了让句子完整，它把空缺的部分填上了。

到 2026 年，对付这三个短板主要有三条路，分工大致是这样：

| 方案 | 解决什么 | 知识更新 | 主要成本 | 适合场景 |
|------|---------|---------|---------|---------|
| 微调 | 让模型学会某种表达风格或输出格式 | 要重新训练 | 训练算力 + 标注数据 | 格式固定、风格要求高 |
| RAG | 让模型答出训练集里没有的事实 | 改知识库即可 | 检索链路的搭建与维护 | 知识频繁变、要溯源 |
| 长上下文 | 一次塞更多原文进去 | 不用更新（每次现塞） | 每轮 token 费用 | 单次材料少、临时分析 |

三条路不互斥。格式靠微调、事实靠 RAG、临时材料靠长上下文，完全可以一起上。

![这三条不是模型不够大，是架构决定了它治不好——所以要靠外挂来补。](https://developer.qcloudimg.com/http-save/yehe-12591818/8eb71a250a2b13545759a07baa71529b.png)



## 三、RAG 工作流程拆解：一次提问背后发生了什么

**RAG 的链路分两段：离线建索引决定「你能查到什么」，在线检索决定「这次查到了什么」。**

大多数人对 RAG 的模糊印象只停留在后半段，所以出了问题也只往后半段找。

完整链路长这样：

![RAG 工作流程全链路：离线建索引与在线检索两阶段示意图](https://developer.qcloudimg.com/http-save/yehe-12591818/71a631cb1633a68f3f652db69583d046.png)

拆开说。

**离线那一段**（建索引，跑一次）：把原始文档切分成块，逐块转向量，存进向量库。这段决定了你的知识库里「有什么是可被查到的」。切分切坏了，后面全白搭。

**在线那一段**（每次提问都跑）：把用户问题也转向量，去向量库里按相似度捞回最接近的 Top-K 块，重排一次，拼进 Prompt，最后交给模型生成。

有个细节容易忽略：**问题和文档必须用同一个 embedding 模型转向量**。两个模型各自转出来的向量不在一个空间里，算相似度等于拿尺子量温度。换了 embedding 模型，整个库都要重转一遍。

下面是三段核心代码。用哪个向量库、哪个 embedding 模型，各家的接口写法差别不小，这里只保留逻辑骨架，具体调用以官方文档为准。

问的是「分块怎么切」，代码长这样：

```python
import re

def split_by_structure(text, max_chars=800):
    """先按标题层级切，保住「条款 → 子条款」的从属关系；超长块再按段落拆"""
    blocks = re.split(r"\n(?=#{1,3}\s)", text)
    chunks = []
    for block in blocks:
        block = block.strip()
        if not block:
            continue
        if len(block) <= max_chars:
            chunks.append(block)
            continue
        # 标题行带进每一块，避免子块脱离上下文后语义丢失
        head, _, rest = block.partition("\n")
        for para in rest.split("\n\n"):
            if para.strip():
                chunks.append(f"{head}\n{para.strip()}")
    return [c for c in chunks if len(c) > 30]
```

关键在那句 `re.split(r"\n(?=#{1,3}\s)")`——按标题切，而不是按字数切。标题天然是语义边界，字数不是。

检索那一步，本质就是算余弦相似度取前几名：

```python
import numpy as np

def top_k(query_vec, doc_matrix, k=5):
    """doc_matrix 每一行是一个文档块的向量"""
    q = query_vec / np.linalg.norm(query_vec)
    docs = doc_matrix / np.linalg.norm(doc_matrix, axis=1, keepdims=True)
    scores = docs @ q                      # 余弦相似度
    idx = np.argsort(-scores)[:k]
    return [(int(i), float(scores[i])) for i in idx]
```

最后是拼 Prompt。这一段是全文性价比最高的地方，多加两行规则，效果能差出一截：

```python
PROMPT = """你是售后政策助手，只能依据下面的资料回答。

资料：
{context}

问题：{question}

规则：
1. 资料里没有提到的内容，直接回答"资料中未提及"，不要推测。
2. 每个结论后面用 [编号] 标注它出自哪一段资料。"""

def build_prompt(contexts, question):
    ctx = "\n\n".join(f"[{i + 1}] {c}" for i, c in enumerate(contexts))
    return PROMPT.format(context=ctx, question=question)
```

第 1 条规则给模型留了「可以拒答」的出口，第 2 条让答案天然带引用。少写这两行的 RAG，就是模型硬编的主要来源。

## 四、四个最容易翻车的地方（以及怎么修）

**RAG 效果差的时候，先怀疑切分，再怀疑检索，最后才怀疑模型——这个顺序能省掉大半无效排查。**

下面四条按「出现频率 × 排查成本」排的，从最容易查的开始。

**1）切分把语义切碎了**

固定字数切分看着整齐，实际上会把表格、代码块、带编号的条款从中间劈开。开头那个例子里，「退货时效」的表头和数字就是这样被拆散的。

![](https://developer.qcloudimg.com/http-save/yehe-12591818/9083407d69d28ac0f527b42fc749ae87.webp)

改法有三个，都不复杂：

- 按结构切（标题、段落、列表项），别按字数切
- 相邻块之间留 10%~20% 的重叠，防止边界上的语义被切断
- 表格、代码块这类结构敏感的内容整块保留，宁可超长也不切开

**2）向量检索「看着像」不等于「答得上」**

向量检索比的是语义相似度，本质是模糊匹配。碰到型号、「第 12 条」这类精确标识，它就明显不灵了——「KB-2200」和「KB-2201」在向量空间里挨得极近，但一个是你要的，一个不是。

**混合检索（Hybrid Search）**：同时跑两路召回，一路是向量检索负责语义，一路是关键词检索负责精确匹配，两路结果合并后再统一排序。类比一下，就是既让懂行的人凭印象找，也让机器按条码逐一核对，两边对不上的再人工看一眼。

多数向量库和检索框架都内置了这能力，难点不在实现，在于你有没有意识到需要它。

**3）少了重排，Top-K 里混着一堆干扰**

**Rerank（重排序）**：先用向量检索快速召回一批候选（比如 50 条），再用一个更慢但更准的模型对这 50 条精排，只取最相关的 5 条送进 Prompt。类比一下，先海选再面试。

它的位置在检索链路里是这样，重点看「宽召回」和「精排」的分工：

![Rerank 在 RAG 检索链路中的位置：向量召回 50 条后精排取前 5](https://developer.qcloudimg.com/http-save/yehe-12591818/1d82e9448b5729f1d5b4cdc5f4c95f9b.png)

向量检索要在毫秒级扫过全库，所以模型必须做得轻，精度天然有限；重排只处理 50 条，可以放心用重模型。这一轻一重搭配，比单纯把 Top-K 调大有效得多——把 K 从 5 调到 50，多出来的 45 条里大半是噪声，反而把真正有用的那条淹没了。

**4）没给模型留「可以拒答」的出口**

不写拒答规则，模型遇到资料里没有的问题时会倾向于硬答，因为它的训练目标就是「把话说完整」，而不是「说不知道」。上一节那段 Prompt 的第 1 条规则就是在堵这个口子。

四个问题对照着看更清楚：

| 症状 | 多半是 | 先改哪 |
|------|-------|-------|
| 答非所问，但条款内容本身没错 | 切分把语义切碎了 | 改按结构切 + 加 10%~20% 重叠 |
| 问型号、编号类问题答不准 | 纯向量检索对精确匹配不敏感 | 加一路关键词检索做混合召回 |
| Top-K 里混着一堆无关内容 | 没做重排 | 加 Rerank，候选先放大到 50 再精排 |
| 资料里没有它也硬编 | Prompt 没给拒答出口 | 明确写「资料未提及时回答不知道」 |

## 五、RAG 会不会被长上下文干掉

**长上下文解决的是「一次能塞多少」，RAG 解决的是「该塞哪一些」，这是两个问题。**

> **可能有人会问：现在模型上下文动辄几十万 token，把文档全塞进去不就行了，还要 RAG 干什么？**
>
> 三个原因。一是成本，全量塞进去，每一轮对话都要为整份材料付 token 费用，而 RAG 只送进去几条相关片段，量级差得很远。二是数据规模，企业知识库通常是几十万到上百万份文档，任何上下文窗口都装不下，这不是容量问题，是量级问题。三是模型对长上下文并不均匀地好用。

第三点有实测支撑。Liu 等人在 2023 年的论文 *Lost in the Middle*（arXiv:2307.03172）里做过一个实验：把答案放在输入上下文的不同位置，看模型还能不能找出来。结果是条 U 型曲线——答案在开头或结尾时模型找得到，放到中间就明显掉分，而且长上下文模型也不例外。

所以「塞得进去」和「用得起来」是两件事。这也解释了一个常见现象：你把 Top-K 从 5 调到 20，效果没变好反而变差——多出来的文档把正确答案推到了上下文中间。

**长上下文没有干掉 RAG，它干掉的是「切一切、塞一塞就上线」那一版 RAG。**

真正在变的是检索这一端：从单轮向量检索，变成会判断该查哪个库、查不到就换个问法再查一轮的智能体式检索；从纯向量，变成向量加关键词的混合召回。模型换了一代又一代，这段链路的位置反而越来越重要了。

---

我是晚安code，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你做 RAG 的时候，卡在切分、检索还是生成哪一环？


假设一个场景，有个做 RAG 的活儿，给售后知识库搭问答。第一版上线就被业务怼了：用户问「退货要几天到账」，它回了一段「签收后 7 天内可申请」——条款本身没错，但答的根本不是这个问题。

RAG 检索增强生成原理详解：为什么你的 RAG 效果差，问题多半在检索端

很多人做 RAG 效果不好就换模型，其实瓶颈在检索端。本文用可跑的代码拆解 RAG 工作流程：切分、向量检索、重排、拼 Prompt，讲清每步为何重要。

人工智能

算法

后端

RAG效果差的根源多在检索端而非模型能力，常见问题包括按固定字数切分切断语义、纯向量检索对精确编号不敏感、缺少重排与拒答规则。本文拆解RAG全流程，提供按结构切分、混合检索、Rerank及Prompt优化等可运行代码方案，助你快速定位并修复问答系统的核心故障。

代码解释

智能体

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

RAG 检索增强生成原理详解：为什么你的 RAG 效果差，问题多半在检索端-腾讯云开发者社区-腾讯云

RAG 检索增强生成原理详解：为什么你的 RAG 效果差，问题多半在检索端

RAG 检索增强生成原理详解：为什么你的 RAG 效果差，问题多半在检索端

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐