企业级 RAG 系统开发框架如下:
RAG 的优势在于:
同时,通用的基础大模型无法满足实际业务需求的原因包括:
设置基线:RAG是当今大多数现代人工智能应用程序的标准架构。让我们以Sana的企业搜索用例为例,了解它在幕后的工作原理。该过程始于应用程序加载和转换无结构文件(如PDF、幻灯片、文本文件)跨越企业数据孤岛,如Google Drive和Notion,转换为LLM可查询格式,通常通过像[Unstructured](https://menlovc.com/portfolio/unstructured/)*这样的数据预处理引擎进行。这些文件现在被"分块"成更小的文本块,以实现更精确的检索,并作为向量嵌入和存储在像[Pinecone](https://menlovc.com/portfolio/pinecone/)*这样的数据库中。当用户向AI应用程序提出问题时(例如,"总结我与公司X会议的所有笔记"),系统会检索语义上最相关的上下文块,并将其折叠到"元提示"中,与检索到的信息一起馈送给LLM。然后,LLM会从检索到的上下文中合成一个整洁的带有项目符号的答复返回给用户。当然,该图仅说明了一个带有一个LLM调用的单一检索步骤。在生产中,AI应用程序具有更复杂的应用程序流程,包含数十甚至数百个检索步骤。这些应用程序通常具有"提示链",其中一个检索步骤的输入馈送到下一步,并且不同类型的任务并行执行多个"提示链"。然后将结果综合在一起,以生成最终输出。[Eve](https://menlovc.com/portfolio/eve/)*法律研究的共同驾驭员,例如,可能会将针对《第七篇》的研究查询分解为专注于预定子主题的独立提示链,如雇主背景、就业历史、《第七篇》、相关案例法和原告案件支持证据。LLMs然后运行每个提示链,为每个生成中间输出,并综合各输出编写最终备忘录。
大语言模型技术的本质导致了大模型的输出结果具有不可预测性,此外,静态的训练数据导致了大模型所掌握的知识存在截止日期,无法即时掌握最新信息。因此,当我们将大模型应用于实际业务场景时会发现,通用的基础大模型无法满足我们的实际业务需求。主要存在以下原因:知识的局限性:模型自身的知识完全源于它的训练数据,而现有的主流大模型(ChatGPT、文心一言、通义千问…)的训练集基本都是抓取网络公开的数据用于训练,对于一些实时性的、非公开的或离线的数据是无法获取到的,这部分知识也就无从具备。幻觉问题:大模型的底层原理是基于数学概率的文字预测,即文字接龙。因此大模型存在幻觉问题,会在没有答案的情况下提供虚假信息,提供过时或通用的信息,从可信度低非权威来源的资料中提供结果等。数据安全性:对于企业来说,数据安全至关重要,没有企业愿意承担数据泄露的风险,将自身的私域数据上传第三方平台进行训练。因此如何大模型落地应用时如何保障企业内部数据安全是一个重要问题。而RAG是解决上述问题的一套有效方案。它可以让大模型从权威的、预先确定的知识来源中检索、组织相关信息,更好地控制大模型生成的文本输出,并且用户可以深入了解LLM如何生成最终的结果。并且,RAG可以和微调结合使用,两者并不冲突。RAG类似于为模型提供教科书,允许它基于特定查询检索信息。这该方法适用于模型需要回答特定的询问或解决特定的信息检索任务。然而,RAG不适合教模型来理解广泛的领域或学习新的语言,格式或样式。微调类似于让学生通过广泛的学习内化知识。这种方法当模型需要复制特定的结构、样式或格式时非常有用。以下是RAG与微调从维度方面的比较:参考资料:《Retrieval-Augmented Generation for Large Language Models:A Survey》(https://arxiv.org/pdf/2312.10997.pdf)
RAG是检索增强生成(Retrieval Augmented Generation)的简称,是当前最火热的企业级LLM应用方案。RAG概括起来就是知识检索+内容生成。这么说太抽象,可以理解为大模型的开卷考试,既然是开卷考试,那么谁带的书和资料内容更全,谁翻书翻的更快更准,谁开卷考试的结果就往往更好。下面来看RAG的主要组成,依次是数据提取——embedding(向量化)——创建索引——检索——自动排序(Rerank)——LLM归纳生成。当然这里少了使用环节,我们暂时先忽略。大家知道,开卷考试时,往往大家的参考资料都差不多,在有限的考试时间内如何又快又准的锁定问题在书上的相关内容更为重要。RAG做的好不好也是如此,核心就看能不能将内容检索的又快又准。如果抄错了书上(知识库)内容,往往大模型给出的答案也南辕北辙。