← 返回资讯
赵一鸣
产品评测编辑
已审核

深度好文!的大模型 RAG 技术概览

1. **事实与数据**:没有发现硬伤——提到的模型(bge‑m3、text2vec、M3E、Qwen2‑1.5B 等)和技术流程(递归分块、混合检索、重排序、Query 重写等)都是真实存在的经验描述;文中出现的百分比(12%、64%→83%)是个人测试或举例,不属于公共事实,保留原样未改。只有一处“模型版本1.0”略显具体但无错误,为保险已弱化表述。

深度好文!的大模型 RAG 技术概览

深度好文!的大模型 RAG 技术概览


1. 事实与数据:没有发现硬伤——提到的模型(bge‑m3、text2vec、M3E、Qwen2‑1.5B 等)和技术流程(递归分块、混合检索、重排序、Query 重写等)都是真实存在的经验描述;文中出现的百分比(12%、64%→83%)是个人测试或举例,不属于公共事实,保留原样未改。只有一处“模型版本1.0”略显具体但无错误,为保险已弱化表述。

2. AI味表达:用户列出的短语(“值得注意的是”“总而言之”等)文中并未出现,整体口语风格鲜明,故未删减。

3. 工整排比句:几处较规整的排比或对称结构已打散,替换为更自然的叙述节奏。

4. 最终版本:保留原文框架、语气、篇幅,仅针对上述原则做调整,不改变作者观点和案例。


我搞了半年RAG,差点被甲方追杀!这些坑,今天全给你扒干净!

你猜怎么着?去年有个项目,差点没把我搞死!

甲方要做企业知识库,几十页的PDF往里扔,还要支持多轮对话。我当时那个天真啊,心想不就是“切块—向量化—检索—生成”嘛,小菜一碟!结果呢?一上线就翻车了!

客户问:“第三季度的净利润是多少?”

模型张嘴就来:“第二季度,2.5个亿。”

客户又问:“刚才说的那个方案,具体怎么实施?”

模型直接开始编造步骤,那叫一个理直气壮!

我当时就懵了。心想:这玩意儿跟网上教程说的完全不一样啊!

网上那些资料,要么是学术论文翻版,又臭又长;要么就跑个demo就号称“实战”,结果一上生产环境就原地爆炸。

搞RAG这事,我断断续续折腾了大半年,踩过的坑比我吃过的盐还多!

后来我才发现:RAG要落地到生产环境,远不止跑通一个demo那么简单!

说到这儿,肯定有人问了:现在大模型不是动不动就百万token上下文吗?RAG是不是要过时了?

恰恰相反!

谁还说RAG要过时了?扯淡!

超长上下文有个要命的问题——“Lost in the Middle”。模型对中间位置的信息,关注度断崖式下降!而且token费用贵得离谱,你想想,每次对话都把所有书堆到桌上,那开销谁受得了?

RAG就聪明多了:它相当于给模型配了个精准的参考书,让它自己翻到相关页再看! 比把所有书都堆在桌上,不知道靠谱多少倍!


先说说RAG到底解决了什么

大模型啊,有几个天生硬伤,谁都躲不掉:

所以RAG的思路特别简单粗暴:不让模型闭卷考试,允许它实时翻参考书再答题!

这样一来,答案有依据、可追溯,更新成本还低。你说美不美?

核心公式你给我记住咯:RAG = 向量检索(实时知识) + LLM生成(自然语言表达)


我把RAG分几个阶段聊,每个都有坑

第一个阶段:Naive RAG(朴素RAG)

最基础的流程,所有入门资料都会讲。但我实际跑了一遍,才摸到门道。

索引阶段,第一关就是文本分块。

我刚开始直接按句子切,结果长文档的检索片段信息不完整,断章取义!后来试按段落切,又发现有些段落超过1000字,模型上下文窗口扛不住。

最稳的是什么?递归分块!设定一个最大长度,我常用512个token,再用重叠窗口(比如重叠32个token)。既能保持语义连贯,又不丢掉边界信息。这一步相当关键!

分块后用embedding模型转成向量。测试阶段我用了bge-m3text2vec-large-chinesem3e-base

说实话,bge-m3在中文长文本上效果最好,但显存吃得也多。你想想,小规模验证我用m3e-base,生产环境才换成bge-m3。这个取舍,得看你的数据量和硬件。

检索阶段,我早期只用向量相似度(余弦相似度),后来才发现:精准关键词反而抓不到!

比如用户问“乙肝治疗方案”,向量检索可能召回“乙型肝炎治疗指南”,但BM25关键字可以直接命中!这就是语义匹配和关键词匹配的互补性。

所以后来我上了混合检索:向量检索(语义匹配)+ BM25(关键词精确匹配),再用一个简单的加权合并结果。

这一步,直接让Top-5召回率提升了12%! 你没看错,12个点!

生成阶段,就是构造prompt:把检索回来的文本块和用户问题一起喂给LLM。

prompt模板我改了很多版,最后保留三条核心指令:

就这条“不知道”指令,救了我多少次命啊!


第二阶段:Modular RAG(模块化RAG)

Naive RAG太死板了,遇到复杂场景直接裂开!

Modular RAG就不一样了——把检索过程拆成独立模块,像搭积木一样组合!

我实际测试过几种模式:

624
8927 阅读
5 评论
分享
链接已复制
编辑说明

本文由 MakeSense 编辑团队撰写并审核。文中引用的数据和观点均经过交叉验证,如有疏漏欢迎在评论区指正。最后更新:2026年06月20日 23:07

赵一鸣

产品评测编辑

前产品经理,现专注 AI 工具评测。实测过 30+ 款 AI 产品,擅长横向对比和用户体验分析。

读者评论 5

前端工程师 4天前
代码示例很清晰,直接用到项目里了。
回复 点赞 (6)
技术小白 1周前
作为非技术人员也看懂了,感谢作者的通俗讲解。
回复 点赞 (3)
Dev小王 1周前
终于有人把这个说清楚了,收藏了。
回复 点赞 (8)
A
AI研究员 1周前
观点有道理,不过我觉得还需要考虑算力成本的问题。
回复 点赞 (11)
M
创业者Mark 2天前
正在做相关方向,这篇文章给了我不少启发。
回复 点赞 (7)