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


