为什么采用RAG?
模型缺陷
1)幻觉 是因为它没有学过问题的知识 会产生幻觉 可能会瞎答 或者回答不知道
2)精度(效果)
如何解决上面的问题呢?
1.将公司里面的数据给模型学习微调(SFT 高质量数据打标签),成本较大(人工、合成、蒸馏、RLHF),并且需要多次学习调试(即使一模一样的数据给相同的模型学习 得到的结果也是存在差异的 )
2.就是通过 RAG 不需要对我们的基础模型进行更改
那么什么时间采用SFT 微调 、什么时候采用 RAG 检索增强?
1.小公司数据不多情况下,考虑成本,采用 RAG 基于公司里面的一些文档进行问题回答
2.拥有海量数据,且业务数据质量较高,硬件成本可以负担时采用微调
RAG检索增强是怎么使用的呢?
当用户一个问题提问过来时 首先通过RAG进行检索到相似度最高的文档内容 然后将数据和 prompt 组合一起发给LLM大模型 大模型进行总结归纳
在哪里检索相似度最高的文档内容 ?
在向量数据库
向量数据库数据怎么来的呢?
通过Embedding model 将我们的数据转为向量存储到向量数据库
向量模型是有维度的 比如我们现在用的最多的 text embedding ada002(openAi开发的)他是1536位的 ,当一个数据转为向量化数据时,就会生成1536维浮点数向量 即把输入的文本等数据映射为一个 1536 维的向量空间中的点 这个小数代表的就是特征提取 ,维度越大 ,特征提取的越详细
为什么要转向量数据呢?
就是因为相似度检索 相似度检索通过通过维浮点数向量欧式距离的计算 或者 余璇距离的计算 可以想象有个x轴和y轴 在xy之间有两个点,这两个点就是两个向量化后的数据 两个数据之间欧式距离越近 说明两条数据相似度越高, 向量是什么呢? 你就可以把他理解成一个数组 数组中有n个小数
下图来自KEVIN老师讲的RAG项目
如果 RAG 后精度感觉还不够怎么办呢?
还可以采用知识图谱进行更准确化
知识图谱需要:信息抽取、关系抽取、事件抽取、关键词抽取,分配,分类,指代消解,阅读理解等更多繁琐的工作来完成
RAG
RAG
现在发展出三种类型:Naive RAG
(朴素RAG)、Advanced RAG
(高级RAG)和Modular RAG
(模块化RAG)RAG在成本效益上超过了原生LLM,但也表现出了几个局限性,这也更大家一个印象:入门容易,做好难。Advanced RAG
和Modular RAG
的发展是为了解决Naive RAG
中的缺陷。Naive RAG
遵循一个传统的流程,包括索引、检索和生成,它也被称为“检索-阅读”框架,将查询(query)与文档的检索结合起来,通过大语言模型 (LLM) 生成答案。
将数据先通过嵌入(embedding
)算法转变为向量数据
,然后存储在Chroma
这种向量数据库
中,当用户在大模型输入问题后,将问题本身也embedding
,转化为向量
,在向量数据库
中查找与之最匹配的相关知识,组成大模型的上下文,将其输入给大模型,最终返回大模型处理后的文本给用户,这种方式不仅降低大模型的计算量,提高响应速度,也降低成本,并避免了大模型的tokens限制,是一种简单高效的处理手段。
Naive RAG
Naive RAG 的优势
简单高效
:
架构设计简单,便于实现,特别适合初学者和小型应用场景。
模块化设计
:
将检索和生成分离,便于针对每一模块优化。
低延迟
:
因为无需复杂的后续排序或多级推理,响应速度快。
Naive RAG 的局限性
结果质量不稳定
:
检索的文档片段可能不完全相关,导致生成结果准确性受限。
缺乏上下文整合
:
无法有效地对不同文档片段之间的关系建模,例如相互矛盾或补充的信息。
易受查询噪声影响
:
用户查询如果不明确,可能导致检索到无关内容。
入门demo:
1.langchain +ollama +chroma+embedding模型实现RAG入门级Demo(python版)
2.RAGFlow安装+本地知识库+踩坑记录