RAG效果差,不一定是模型问题:深入理解Chunk、Embedding与Rerank

当时我就笑出声了 当时我就笑出声了 墨衍会员 · AI 创作全网分发 墨衍智能分发 通过墨衍一键同步至各平台 可同步平台 CSDN微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年,写一次发全网 我也要 + 加入社区

前言

很多RAG项目的第一版都非常相似:

PDF → 切块 → 向量化 → FAISS → Top5 → 大模型

代码很快就能运行。

但真正上线之后,开发者很容易发现:

用户问的问题明明在PDF里,系统却找不到。

这时候最容易出现的误区,就是不断更换大模型。

实际上,大量RAG问题发生在模型看到Prompt之前。


一、Chunk决定了模型能够“找到什么”

假设原文为:

NX系统中,拉伸特征可以通过草图轮廓形成实体。拉伸距离支持对称、单向以及直至选定对象等方式。

如果采用固定长度切块,有可能出现:

Chunk A:
NX系统中,拉伸特征可以通过草图轮廓形成实体。
拉伸距离支持

Chunk B:
对称、单向以及直至选定对象等方式。

当用户询问:

“NX拉伸支持哪些终止方式?”

Chunk B虽然包含答案,但是缺少“拉伸”这一主体。

这就是典型的语义断裂。


二、常见Chunk策略

固定长度切分

例如:

chunk_size = 500
chunk_overlap = 100

优点:

  • 实现简单;
  • 速度快;
  • 适合结构较弱的文本。

缺点:

  • 容易打断语义。

按段落切分

利用:

标题
章节
自然段
Markdown Heading

进行切分。

这种方式更加符合人类阅读结构。

语义切分

通过Embedding判断前后句语义是否发生明显变化。

如果语义变化较大,就建立新的Chunk。


三、为什么要设置Overlap?

假设:

Chunk1 = 第1~500字
Chunk2 = 第401~900字

中间存在100字重叠。

目的就是尽量避免关键信息恰好落在Chunk边界。

flowchart LR

A[Chunk1<br/>1-500] --> B[Overlap<br/>401-500]
B --> C[Chunk2<br/>401-900]

Overlap不是越大越好。

因为重叠过大意味着:

  • 索引数量增加;
  • 存储增加;
  • 检索结果可能大量重复。

四、Embedding负责“理解相似性”

关键词检索关注的是:

有没有相同词。

向量检索更加关注:

表达的意思是不是相似。

例如:

用户:
“电脑突然没电了怎么办?”

文档:
“当笔记本出现无法供电时,应首先检查电源适配器。”

两句话字面差异很大,但语义相关。

Embedding正是用来解决这种问题。


五、为什么还需要Reranker?

假设向量数据库检索出20条结果:

Top20
↓
Reranker
↓
Top5
↓
LLM

向量数据库负责:

快速找到“可能相关”的内容。

Reranker负责:

精细判断“到底谁最相关”。

flowchart LR
A[用户Query] --> B[Vector Search]
B --> C[Top 20]
C --> D[Reranker]
D --> E[Top 5]
E --> F[LLM]

因此两者不是替代关系。

更加合理的工程方案通常是:

粗排 + 精排。


六、混合检索为什么越来越常见?

向量检索并非任何场景都占优势。

比如用户搜索:

ERROR_CODE_0X8021

这种精确编号使用关键词搜索通常更加可靠。

因此可以组合:

BM25结果
+
Vector Search结果
↓
融合排序
↓
Reranker

这种方式叫做Hybrid Search。

适合:

  • 产品型号;
  • 错误码;
  • 人名;
  • 专业术语;
  • 自然语言问题

混合出现的知识库。


七、一个更合理的RAG检索链

flowchart TD

A[用户问题]
--> B[Query Rewrite]

B --> C[BM25]
B --> D[Vector Search]

C --> E[Result Fusion]
D --> E

E --> F[Reranker]

F --> G[Context Compression]

G --> H[LLM]

H --> I[答案]

这个结构比:

Vector Search → LLM

虽然复杂一些,但工程效果往往更加稳定。

总结

RAG效果不好时,可以按照以下顺序排查:

1. 文档有没有清洗干净?
2. Chunk是否合理?
3. Embedding是否适合?
4. Query是否需要改写?
5. 检索结果是否准确?
6. 是否需要Hybrid Search?
7. 是否需要Rerank?
8. 最后再考虑更换LLM。

从这个角度看:

检索质量决定模型能够看到什么,大模型只是决定怎样利用看到的信息。

...全文

相关推荐

RAG中的Embedding与Reranking模型[代码]

本文详细介绍了RAG(检索增强生成)系统中Embedding模型与Reranking模型的协同作用。Embedding模型通过双塔结构将文本转换为向量,用于快速检索语义相近的文本片段(chunk),适合大规模数据的粗筛。而Reranking模型采用交叉编码器结构,深入分析文本间的语义关联,对候选chunk进行精排,提升回答质量。文章还列举了常见的Reranking模型如BGE-Reranker和Cohere Rerank,并强调了两种模型配合的必要性:Embedding模型高效处理海量数据,Reranking模型确保语义准确性。最后,作者分享了AI大模型学习资料,助力读者掌握相关技术。

Mars5

企业级RAG知识库落地指南:从切块、检索到评测的完整链路

检索增强生成(RAG)已成为企业接入大模型的默认方式,它将外部知识检索与大模型生成相结合,在无需重新训练的前提下扩展模型知识边界。然而,从Demo到生产级系统,团队常被文本切块不合理、召回不准、引用无溯源、评测靠直觉等难题绊住。企业级RAG的本质是一条完整工程链路:文档解析与清洗决定数据质量,切块策略影响语义完整性,向量检索与关键词检索的混合策略确保精确命中,重排序优化上下文相关性,引用溯源保障答案可审计,量化评测驱动持续迭代。本文从基础概念出发,逐层拆解企业级RAG的架构设计、核心模块选型与常见坑点,并给

weixin_34268753

RAG技术原理与架构拆解

本资源以《RAG 技术原理与架构拆解》为主题,围绕“文档如何进入知识库、用户问题如何被检索并交给大模型回答”这条主线,系统讲解文档解析、Chunk 切分、Embedding、向量数据库、BM25、混合检索、Top-K、Rerank、Context 构造、Prompt 与答案生成等关键技术,并通过企业汽车技术知识库案例串联完整数据流程。内容同时涵盖 RAG 幻觉成因、效果评测、故障定位、GraphRAG 及企业级权限、版本与安全治理。 适合刚接触 RAG 和大模型知识库的开发者、测试人员、产品经理、解决方案架构师,以及汽车、通信、制造等行业的数字化从业者阅读。无需深厚的 NLP 或算法基础,具备基本软件与大模型概念即可学习。 可用于 RAG 入门学习、企业知识库方案设计、技术培训、架构评审、项目选型及面试准备。目标是帮助读者建立完整的 RAG 技术框架,理解各组件的作用与数据流向,具备分析检索效果、定位系统问题和规划企业级 RAG 项目的基础能力。

美人胖七分

基于向量数据库构建高质量RAG应用.pdf

基于向量数据库构建高质量RAG应用.pdf

数研基站

RAG面试八股,补充RAG相关基础知识

RAG面试八股,补充RAG相关基础知识

智刃纪元
评论
收藏 已收藏
分享
返回顶部