一文看懂最前沿得高级RAG+设计是如何消灭AI幻觉的架构设计

本文链接：https://blog.csdn.net/lifetragedy/article/details/145994174

数据幻觉一直是企业落地AI的痛点

在我之前相关系列中一直在和大家讲如何消除AI在企业应用中的幻觉。见我之前的作品：

AI RAG引擎构建核心技术全揭密-精准切分个人知识库内的条目

AI RAG引擎构建核心技术全揭密-打造个人知识库问答体系

AI在落地企业应用时的“数据幻觉”缘何这么难解决一谈LORA微调与数据质量处理之争

数据质量是企业落地AI的重中之重

DeepSeek的出现再次把大家的关注力吸引回到了AI Agent，其中最受关注的几大点中有一个大点那就是“数据”。

在AI应用中一切的根本或者说直接可以决定这个项目、产品成败中有70%甚至占到了80%的因素就是“质量良好的数据”。

从各方面新闻、业界动态、趋势已经可以看到对于数据标注、打标一类岗位的需求急剧上升，要落地AI先保证数据质量成了业界实施和落地AI项目的一句口头禅。

足以看到数据对于AI项目和产品有多重要。其实RAG这个东西存在的根本就是如何利用好数据而诞生的。

随着AI越来越成熟特别是今年DeepSeek的出现，RAG也发生了一系列的进化。

总体来说其实RAG一共经历了两代：

2022年~2023年的RAG时代，我们现在回首可以称其为Agent工作流时代；
2023年年底至2024年第3季度时，由于RAG1.0时代间人们经历了各种AI幻觉和不稳定性，于是把目光聚焦在了GraphRag一类的工作流量上，其实这个时代我们可以称其为RAG1.5；
从2024年年底直到DeepSeek一类的Reasoning AI的出现，RAG正式进入了真正的2.0时代；

RAG+来了

于是RAG+其实又称：Advanced Rag包括上周五Microsft的PIKE RAG，把企业实施从L0~L4划成4个层次还有KRAG都是指“同一样东西”，为了简写我们就统称其为RAG+吧。这是因为它不是具体某一个产品而是一种“思想”，是一种企业落地AI的架构设计，这有点像以前的IT TOGAF架构一样，是一种理念。

但是近来也有几个产品用最终的用户可使用产品“具象化”了这个理念，从目前来看形成的理念，的确是有效或者可以说从源头上的确是解决了AI幻觉这一现象。

没有太多数据说明，只能说一个类比包括本人自己的实验、实施结果。可以这样比喻之前的RAG和RAG+到底是什么样的一种差别呢？那就是：天和地之间的区别！

对。。。传统RAG和现在的RAG+间的区别真的就这么大。

为什么这么大？下面一起来看。

RAG

RAG的通用流程

RAG-Retrieval-Augmented Generation的缩写，它是企业落地AI的根本。这是因为每个企业有自己的切口、术语、业务规则，这不是预训练的LLM所能具备的。

再有就是不可能每一个企业都会去为了自身特殊的规则去微调一个自己的LLM，这也是不现实的。

上图是我在一系列博客中使用的一个标准的RAG流程，看看有点复杂其实说白了就3步：

把要用于AI问答或者是执行的数据（各种数据，有PDF、TXT、图片、Excel、Word）放在一个统一的存储的地方，我们又称为“知识库”；
通过向量检索根据用户的提问“带”出一堆的可能答案；
把这一堆答案送给AI作最终回答或者解释；

一切AI Agent包括Cursor、Text-to-Sql、智能BI、自动写作小到：智能客服、AI客服全部是这种设计。

传统RAG的痛点

我们直接就用生产实例来说吧这样看着更直观看。世面上有不少写RAG+的文章，但全部统统是翻译的老外的论文，所以看着各种架构图好似很先进但引用的例子没有一个适用于中国本土场景全是LAO WAI的什么蓝球、棒球、比赛。非旦不实用也因此遗漏了很多RAG+技术中的重要要领和精髓也一概都没讲清楚，读者也领会不到。笔者就用手头落地的多个企业AI Agent直接来讲问题这样大家看得也就一目了然。

先来看例子中的企业拥有的数据与业务知识背景介绍

这是一个上海市公租房相关智能客服的场景，负责其中一处公租房的物业公司拥有两个大地块，这两个大地块间间隔了28公里（一切实体与小区都用的是假名，如有雷同纯属巧合）。

1#地块内有4个期数，分1期、2期、3期、4期，每一期有公租房少则8栋多达15-20多栋小中高层，用于给到人才引进专门租用。
2#地块内不分期数，有数十栋高层小区。

其中1#地块代运营公司的官方招租引租手册包括公司对外服务叫：明星公租房；
其中2#地块代运营公司的官方招租引租手册包括公司对外服务叫：明星罗秀路公租房；

1#地块和2#地块周边相应的配套设施如：教育配套、饮食、交通甚至是物业相关服务都完完全全是不同的。

每个地块的服务条款多达上万条，其中物业维修再分套外和套内。

所谓套外就是指：家门以外包括楼宇、小区的公共部位都属于套外维修，而套外维修呢对于1#地块的4个期都不是明星公司管理的，属于绿叶子物业维护着的。
所谓套内就是指：家门内以及家内一切，属于明星公司维护着的，但是1#地块（包括1期，2期，3期，4期）和2#地块又属于明星公司两处部门维护着的。

语料中最容易混淆之处

用户常用切口或者是公司客服人员常用切口最容易搞混的地方

如果用户开头问：我是罗秀路的，这里指的就是2#地块：明星罗秀路公租房相关事宜；
如果用户开头问：我是公租房的，这里只指1#地块，即包括1期的（碧海苑、群星苑）、2期的（蓝天苑），3期的（景泰兰苑、金苹果苑、绿叶子小区）和4期的（普乐小区和草莓苑）；
如果用户开头问：我是罗秀路公租房的，那么也是指的是2#地块：明星罗秀路公租房相关事宜；

然后穿插着各种租房条款、房型、各种的周边、套内、套外、甚至是一些生活琐事、责任条款、相应的规则混在一起。

于是呢，就有了下面的故事。

实际在生产中发生的例子

语料混在一起，AI乱回答的情况举例

用户问：

我是罗秀路公租房的，请问本人符合上海公租房条款，那么是否可以带妻子的父母一起居住进来呢？

这儿要“透一个题”，对于当前用户的回答：

罗秀路是2#地块公租房，它的租房政策允许带妻子和孩子，而且是办理落户政策的，而除去配偶和直系亲属以外的不允许住进来。

而1#地块即包括（1期、2期、3期、4期）的公租房是允许的。

于是根据用户上述提问，一个RAG流程走下来，我们手上至少有2条数据：

罗秀路的租房规则；
1#地块的租房规则；

于是AI时而回答可以时而回答不可以。

这是很糟糕的体验。

缺少语料乱回答的举例

用户问：

你好，我刚住进碧海苑，忙了一天，饿了。

我们通过上下文知道碧海苑属于一期的小区之一，语料库内碧海苑所归属的一期周边有“黄山菜饭、芭比馒头、南京汤包”。

但是通过RAG流程走下来，我们手里有至少10条数据和碧海苑有关分别为：

碧海苑周边配套设施
碧海苑附近教育
碧海苑周边交通
碧海苑房型介绍
碧海苑租房政策
碧海苑附近商超
罗秀路附近小吃
罗秀路周边配套设施，饿了您可以点外买还可以点小区内配套社区特色食堂
碧海苑家庭宽带安装指南
碧海苑停车场收费

检索出来的语料中就是没有：碧海苑，我饿了。

那很正常，极少有正规则企业语料会专门写：饿了怎么办。

但就算企业写了，如果用户在半夜发一条：我馋了。。。你总不见得手工再添加一条？

那用户的话术千变万化，中文语言博大精深，你这要添加多少条语料才可以照顾得到全用户场景呢？

但是呢，正正好，就有一条：饿了您可以点外买。但是注意啦，这一条语料是属于罗秀路即2#地块的相关知识点。

于是呢，AI碰到用户这样问就像下面这样回答了：

您好，欢迎入住碧海小区。忙碌了一天您幸苦了。
如果您饿了可以点社区特色食堂。。。

但是碧海苑可是没有社区特色食堂的。

于是用户接着问：

食堂电话是什么？

此时语料收到了停车场收费的电话于是AI就这样回答了

有的，您可以拨打：64xx-xxxx

用户于是还真去打这个电话了，一打以后才知道是停车收付处的咨询电话，保安大叔一听用户要点“炸署条”？呵呵乐了：俺这没有炸署条，但正在吃方便面，您要饿了可以给您也送一包过去。

AI在聊天过程中上下文引起的数据污染的举例

在经历了上述2起“惨案”后，我们知道语料足够很重要，于是我们放大了在送给AI前的“召回率”，放大到一个提问搜索召回TopK把K值设到了30条。

这下乐子更大了。

用户问：

我是碧海苑的，附近有什么小学？

碧海苑是一期公租房，附近有：兰苗苗小学、航天幼儿园、金星小学、上海外国语小学。

然后AI回答得挺好。

用户接着上文问：

我朋友是罗秀路公租房的，附近有什么小学？

于是AI的上下文是这样的一个情况：

语料：
1. 公租房附近相关小学
2. 罗秀路周边配套设施
3. 罗秀路公租房物业电话
上下文内容（标准messages结构）
[
    {
      "role": "user",
      "content": "我是碧海苑的，附近有什么小学"
    },
    {
        "role": "assistant",
        "content": "碧海苑周边配套齐全，有航天小学，有上海外国语小学"
    },
    {
        "role": "user",
        "content": "我朋友是罗秀路公租房的，附近有什么小学？"
]

而实际罗秀路附近小学在知识库内是：罗秀路交大附属小学、建平红星小学。

但是因为：

都有公租房，于是把公租房相关的语料混在了一起；
加之上下文里有小学列表名；
召回资料里没有召回罗秀路小学列表名；

于是AI是这样回答的：

很高兴您的朋友住在罗秀路公租房，罗秀路公租房周边配套设施齐全，有航天小学，有上海外国语小学

天哪。。。打住吧！

这就是语料太多带来的上下文污染。而且，你们看，这AI胡诌时还一本正经的胡诌！！！

反过来，如果用户先问2#地块相关情况后接着再换成问到1#地块相关情况也是同样会产生相应的问题。

越搞乐子越大

甚至在1#地块内的几个小区或者是不同期数间的房型、价格、设施互相“窜”了去回答用户的提问。

准确率有50%已经不得了。

所以，这样的产品。。。体验是相当的糟糕的。

当然，这个客户的语料烂、从未经过整理，客户也未经历过数字化，连基本的结构化数据都不存在固然有其原因。

但是事后我们回顾时不得不承认，如果连这样的语料都能实施得好，那么是真的有技术挑战的，这点不能全怪客户的语料。

如果一切都准备到极致了、本身数据质量也没问题了，那也就不需要你们来做项目了。

传统RAG中最致命的问题

在传统RAG中最致命的问题其实就是：

召回语料少了，AI乱回答，甚至是自我创造；
召回语料多了，AI胡诌，拿知识条目间彼此乱窜、乱合成；

就像下面这张图，我们的理想中用户的语料经过了RAG因该都是这样的，每一条数据间彼此都有关联，可以彼此建立起相互的自然语言上的“血缘关系”。

而现实其实是“骨干的”。

实际用户手上的语料不是缺少这个就是缺少那个，更不要说，你不可能约束最终使用者们按照你的语料话术严谨的去描述他的问题的。

就好比上例中，用户是会问：我饿了，有点饿，想搞点夜宵这样的问法，对不对？

而语料中也不可能为了用户不同的提问不断的去扩充和满足用户不同的话术，语料中如果真的只有：

附近外卖
附近小吃
24小时营业的饭店有没有？

有这些其实已经够了，没必要写清楚如下面这样：

饿了怎么办？
夜宵哪里吃？
小吃有哪些？
吃正式大餐有哪些？
等等等

所以业界才把GraphRAG称作RAG1.5，因为GraphRAG真的就是为了满足：用户可能产生的不同问法去把现有语料库去建立各种“血缘”关系。

GraphRAG同样没有解决数据的问题

这是GraphRAG的原理图。

因为为了弥补知识库、语料中缺失的那些点，于是有了一些自动化、AI化的工具去建立知识点间的关系。

GraphRAG只是心里上解决了语料不全的问题而并未实际解决问题的本质

我们在2024年年中那会看到的GraphRAG，界面美观、操作上支持拖拖拉拉拽拽、又是树来又是叶、还能AI自我扩展这些节点。

这个一看：哎呀，层次那叫一个分明；

这个一看：哎呀，这叫一个高级、高大上；

实际应用中一用，好么。。。下面两个问题的出现让人们头痛不己。

GraphRAG的自我扩展是基于AI的搜索、和数据蒸馏的

也正因为GraphRAG是AI自我扩展的，你省却不了人工审核环节。

然后人工审核环节会发觉一些点太扩散或者没有扩散好，于是逃不掉至少有：人工标、错误纠正、如果语料的确是不足要补上传这3步，对不对？

而其中每一步都至少穿插着：打开文件、内容查询、内容合并、人工去重。

几个一组合乘上万、十万条语料。。。这个人工需要多少投入知道不？

实施项目中一句：客户的语料不够、不好，因此需要先补足语料。。。说起来很简单，客户方少则全职投入6-10个人，多则有达上百人去做语料修正。

随便举一例，拿配偶这个词，有多少种叫法呢？你不可能要求一个一般用户发消息或者是和AI语音时一定要用：男性配偶，看到了这样的严谨的学术性的提问后这样AI才能回答得好吧？

我们来看配偶一词随手举例就有多少种叫法：

女性配偶：
老婆（全国通用）
媳妇儿（北方地区）
堂客（湖南、四川）
婆姨（陕北）
家主婆（江浙沪）
内人（传统书面）
屋里的（华北农村）
阮某（闽南/台湾）
妹仔（客家地区）

男性配偶（10种）：
老公（全国通用）
当家的（北方农村）
老汉（四川）
外头人（传统说法）
先生（台湾/上海）
老头子（中老年夫妻）
掌柜的（晋语区）
郎罢（福州话）
阮尪（闽南/台湾）
赖子（客家地区）

这还只是一个词，几十万、上百万条语料每一条在200-300字左右呢？

这个校验和纠正所需要的人工成本又是多少呢？

GraphRAG极耗费Token

GraphRAG是基于AI的，它有时多则一条数据要10几次和LLM交互，试想一下如果是MAAS类用户（必竟大量企业-90%以上的企业用的还是MAAS它们没有这个实力本地布署）手上如果是100万条数据我们先不说耗时要多久，光洗数token消耗是多少呢？

这就是2024年4月到2024年12月左右那段时间里人们口中的：AI这东西实施落地项目费不贵，但是上线后运行起来后突然不知道下一个月怎么一下多出几十万、上百万的什么token费（企业是无法理解已经花了钱买了一个产品为什么动不动某个月会多几十万而且还是没有规律的突然运营成本上升这么一件事的）。

所以随着人们这1年半来大量AI落地得到的各种教训以及AI技术的成熟，RAG+终于来到了人们的面前。

RAG+

什么是RAG+？

其实又叫Advanced RAG。

如上文所述，它不是一个固定的产品或者是框架，也不是langchain一类的东西可以做到的，它是一种设计模式，一种先进、科学、合理的RAG设计模式。

它解决的是：最大、最优利用先有语料，最大化召回（检索出）用户所需要的答案，并且可以让AI精准的回答用户的提问。

RAG+中数据流的生命流程

RAG+中数据流的生命流程被业界定义为3R即：

Rewrite->Retrieve->Read。

Rewrite

重写用户的提示语

一句这样的提问

你好，我外公今年79岁，眼压高、模糊、头痛、眼胀

在Rewrite后会变成这样

眼压高,模糊,头痛,眼胀,>59岁,老人,症状,高眼压,青光眼,眼部不适,治疗,缓解,眼药水,眼科医生,咨询,眼压监测,健康检查

Retrieve

多路召回，最大可能去把符合用户要的答案召回（而不是瞎胡乱搜索）。

一般会混杂着ElasticSearch、DB、Redis、VectorDB库，而不仅仅只有VectorDB库。

Read

此处的Read又被称为LLM Read。即让AI真正去理解、了解用户到底问的什么同时结合前两步给到的语料数据好好发挥其LLM的角色去润色和重组语言甚至是去做“判断哪一条结果是对的”。

RAG+的精髓设计思想

要搞清用户到底在问什么？无论是不是AI，其实这个理念就是搜索的理念，它早在几十年前的搜索和传统互联网做法中就已经有了，那就是充分的精确的匹配用户要搜索的内容；
最大化挖掘用户的真正需求，比如说女孩爱虚荣心，“包解优愁”就有可能是在找“奢侈品”此时你不能总是带一些大众普通类包包的结果给女孩看吧？因此才叫“多路召回”；
召回这一词早有了，用ES开始那一年其实就己经有了召回这个词，它其实就是一种穷举搜索用户需求的算法组合；
把正确的、潜在的和用户提问有关联的结果都搜出来、错误的结果也搜出来（不相关的）；
排除完全不相关的的答案；
此时根据一条用户的提问，你检索出来的结果会有很多，再进行去重即重排序；
让LLM去回答；

其实整个架构设计总结下来就是这么7步。

算法经典的的有：BM25、HYDE、GRM，但是不是固定的一种就可以做到，而是彼此间有机的组合和互补并且不断的微调。

最终我们可以做到以下2点效果：

根据用户的提问检索出的内容必定是>=用户所需要的答案的；
排除完全不相干的答案，减少送给LLM的条数，由于数量少精准了LLM的算力也充足、回答质量会更好、性能会更优，用户的体验才会更好；

经过上述7步中的1~6点，这个召回的准确率可以到达90%~95%，此时如果LLM稍微给点力如：DeepSeek 14b或者是Phi4这种小模型都可以回答得相当的另人满意。

一个良好的RAG系统的特征

其实整个Rag+(Advanced RAG)的设计思想可以总结成以下的图，也可以认为是RAG+系统的特征：

能做到这种几乎零幻觉的RAG+系统都具有图左边那样的三步即：前处理（包括提示语重写）、搜索路由（多路召回）、后处理（重排序）。
而好的RAG+的最终语料在吐给LLM前一定符合：强关联、弱关联系、语义（包括了近义、同义）相关并且排除绝对没有关联的。

写在最后

2024年年底左右到今天出现的这种RAG+高级RAG技术是人类目前以来可以解决AI幻觉的最有效手段，它既满足了多样化召回语料的需求又照顾到了不会盲目消耗Token、烧Token的梗，同时它不能说完全取代人工标注而是最大程度上削减和优化了人工标注的工作量。

拿本人实施的项目来说采用了这种设计方式来说原有需要30人标注3-4个月的事变成了5个人在工具的帮助下耗费1个月不到即完成了百万条目的人工再审核工作。这个对比不得不说是巨大的。

因此才会响应了我在本文开头所说的：它不是又一个造神、它出现不久因此没有太多指标，但是对比下来绝对一个是地、一个是天。

因此呢，本人也正在准备开源一整套符合完整的RAG+设计理念的轻量级企业RAG库，快完成了，到时会直接开源到GITHUB上，内部开发代号为：fountain（永生之泉），它可以让一个企业仅仅需要自己准备一台台式游戏电脑配置就可以用上如此高级的几乎0幻觉的企业级知识库，届时我一定会把开源后的网址告诉大家的。

好了，结束今天的内容。