大模型在一定程度上去改变了我们生活生工作的思考的方式,然后也越来越多的个人还有企业在思考如何将大模型去应用到更加实际的呃生产生活中去,希望大语言模型能够呃有一些更多企业级别生产落地的实践,然后去帮助我们解决一些业务上的问题。目前
LLM因为是一个预训练模型,它已有一些知识储备,我们提的问题跟他的知识储备不相符时,会产生一些幻觉问题,看上去正确的回答
LLM预训练出来之后,不能感知到我们实时更新的工业数据,还有企业内部的一些私域数据
LLM训练依赖很多训练数据集,然后为了保证大语言模型的效果更好,训练集的质量以及数据量越多对于大语言模型的一个训练。最终的一个效果会更好,但我们又期望LLM想要去帮我们解决一些垂类的问题,然后又是希望在数据安全这儿会有一些防范,就比如说像企业的一些内部的敏感数据以及敏感文档是一定不能够暴露出去,让公有的大语言模型去进行训练。
为解决单元模型刚刚提到问题,提出RAG,将企业内部私域数据以及实时更新的一些公域数据,通过一些处理之后,变成可进行相似性搜索的向量数据,然后存储到向量数据库。
在我们跟大约模型交互时,用户提问。首先在我们的相同数据库中去进行相似性检索,检索出与这个提问相关的知识内容,然后检索后交给LLM,连同用户的提问一起让 LLM 去生成回复。
RAG帮助我们个人及用户去把企业内部的一些知识数据,很快构建出一个庞大知识库,然后结合目前已有LLM能力,可快速制作智能问答机器人应用。
为LLM提供来自外部知识源的额外信息的概念。这允许它们生成更准确和有上下文的答案,同时减少幻觉
使用到RAG的这条链路之后,用户会先去构建好的知识库,也就是我们向量数据库里面去进行相似性检索,然后带出一部分的知识知识文档。这部分知识文档会跟用户的query结合。
然后我们通过prompt 技术组装成一个最终完成的一个输入给到LLM。然后让LLM生成回复。
最关键一点就是知识库生成这一步,因为主要涉及把我们的知识文档去做内容的提取及拆分。还要进行量化,存入数据库。
知识切片成Chunk
向量化Chunk入库
前两步都是去知识库生成。
Query检索知识Chunk
构建Prompts
调用LLM生成回答
后三步都是知识库生成后,在检索方面需要做的。
像LangChain快速构建一个RAG应用。Langchain中RAG的实现:
各种文档 - 各种 loader - 文本切片 - 嵌入向量化 - 向量存储 - 各种检索链。
思想就是把那五个步骤拆成不同组件,然后由每个不同节点做相应处理。让用户去编写自己的业务逻辑的代码,然后去把这整个过程串起来。
优点和痛点都非常明显。
优势主要是:
痛点也明显:通过开源框架构建出来的一个RAG应用,其实本质上它的通用性是非常强。为保证强通用性,它在效果层面不一定做到最好,就需要企业或个人投入比较大精力,较多研究去把这一个整体的RAG在召回层面的一个效果给提升到最佳。
介绍一下在整体构建整个RAG应用过程中会遇到的一些问题和解决方案。
用户提问:请问A产品分析报告多久分析一次?
然后我们召回的相关知识是:A产品的分析报告信息近30天的数据分析结果。
原因是我们用户的问题,在相关知识中没有明确提到,只是有一定相似度。但跟我们用户问题不直接相关。这样的相关知识以及用户的问题。组装之后交给LLM回答,本质上是人为搞干扰。
对此,有一个工程化实践叫拒答。
提问的A课程适合多大年龄小孩。
知识库里会召回来两条数据,然后其中一条数据是我们期望的一个知识。就在A课程文档。会有一段话跟提问相关,但还会召回其他的一个干扰知识。如其他文档里一些内容,像该课程适合3到7岁的小孩,适合6到8岁的女孩。这种知识内容也会被召回。
主要是期望的召回内容携带一部分干扰信息,这干扰信息没有A课程这个关键字,然后也不会召回回来。在这两个知识内容交给大源模型处理,他也无法理解哪个字内容是正确。
我们更希望在召回层面,就能有较好手段处理。工程化的实践里面,会对用户的进行改写,去增强query的一个效果。
然后也用到类似BM25这种倒排索引,提升关键字的权重。比如干扰知识里没生成这一个关键字,那它的相似度分数较低,就召不回来。
可能有用户的提问是类似:服务器连接不上,应当如何解决?
现在给知识库里面注入的文档,都是类似连接服务器应该有哪些步骤。
整体效果 = 文档处理效果 * Embedding效果 * Retrieval效果 * LLM效果。
demo易,但上手难的主要原因是因为像LangChain和 LLamIndex这种框架盛行。很快接入就是初级的一个状态,可能只能做到35%。如提高整体一个准确率,可通过在拆分那儿会拆更合理、提取内容时,把整个内容提取更好。做向量化时,去选择我们的向量,更好的一个embedding模型。在最终我们去跟LLM交流时,选择效果更好的LLM,然后把这个效果给提升到更高。但实际上60%的一个准确率还是达不到我们生产环境落地的一个期望值。希望准确率90%,在RAG应用构建的各个阶段,我们都会有很多工程化的一些手段实现。
可优化的效果的方式比较多,然后在整个课程里面我们也会去挑选一些核心关键的及怎么去把这个效果给做的更高。
目前RAG整体应用在界内的比较关注的一个地方就是在召回。因为涉及知识文档,思考方向:
RAG召回回来是希望获得更多的跟用户提问相关的知识内容,还是说我只需要更关键的知识内容排在最顶。腾讯相关数据库的AI套件是选择前面这路,期望是召回回来更多跟用户相关的提问的内容。
精度尽量保证召回内容在top3、top5位置出现,因为召回的一些内容确实会有一部分干扰信息。但目前LLM 能力还可以,对这种干扰性信息的一个排除能力较好。
关注我,紧跟本系列专栏文章,咱们下篇再续!
作者简介:魔都架构师,多家大厂后端一线研发经验,在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。
各大技术社区头部专家博主。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。
负责:
- 中央/分销预订系统性能优化
- 活动&券等营销中台建设
- 交易平台及数据中台等架构和开发设计
- 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
- LLM应用开发
目前主攻降低软件复杂性设计、构建高可用系统方向。
参考: