做一个电子商城网站建设方案,有哪些做二手的网站,网站 建设 计划,做网站的业务逻辑目录 一、概述
二、过程概述
三、如何优化提问#xff1f;
四、路由和高级查询
五、丰富索引结构
六、重排序上下文
七、总结 一、概述 Retrieval Augmented Generation RAG 检索增强的内容生成。 从字面上来看检索只是一种手段途径#xff0c;在人工智能领域中存在多种…
目录 一、概述
二、过程概述
三、如何优化提问
四、路由和高级查询
五、丰富索引结构
六、重排序上下文
七、总结 一、概述 Retrieval Augmented Generation RAG 检索增强的内容生成。 从字面上来看检索只是一种手段途径在人工智能领域中存在多种增强大语言模型输出的方式而检索只是其中一种。不同于传统应用的检索RAG中的检索更像是大语言模型能力的扩展它的侧重点在于如何通过检索出来的信息让大模型生成出更优质的内容。 为什么大语言模型的输出会需要增强呢 现阶段大语言模型在训练时会接触到大量文本数据这些文本数据可能包括书籍网页论文新闻资讯等信息。这些数据构成了模型对现实世界的基础理解模型信息中会特地标注训练时所使用的参数量(Billion)7B 代表着 70亿个训练参数。优质的内容和训练参数的数量级都会影响模型的能力和输出质量但知识库的构建会基于某个时间点的数据模型的训练也可能在之后的时间完成这带来不可避免的滞后性和时效性。 通过检索最新的数据作为上下文提示能在一定程度上弥补语言模型在知识更新方面的不足可以提供更加准确的回答但它的效果也依赖检索系统和知识库的质量。在私域场景下大模型在理解私域文档后结合它自己知识库所产生的输出要比传统私域文档中做检索要优质得多。 几十亿个训练参数听起来已经足够多了LLAMA2 在训练时使用了2T大小的数据但它的上下文在4K左右虽然训练参数和上下文随着时间的推移还在不断的增加但对于模型应用来说还远远不够对于整个人类世界来说还远远不够。而RAG就是为了在有限的上下文中让模型发挥更强大的能力。 二、过程概述 构建一个RAG大致能分为三个部分 1.为私域数据建立索引(Embedding)
2.基于用户的输入将相似度最高的内容的提取出来(向量搜索)
3.基于用户的问题对回答的内容进行增强(提示词工程)。 下图来源于https://scriv.ai/guides/retrieval-augmented-generation-overview LangChain 三行代码构建一个简单的RAG示例 fromlangchain.document_loaders importWebBaseLoader
fromlangchain.indexes importVectorstoreIndexCreatorloader WebBaseLoader(http://www.paulgraham.com/greatwork.html)
index VectorstoreIndexCreator().from_loaders([loader])
index.query(What should I work on?) 检索本质上是一种搜索操作传统的搜索引擎可以根据用户的输入查找最相关的信息。在AI检索中的行为也是类似的它由两个部分组成 1.索引将知识库变为可以搜索/查询的内容。
2.查询从搜索词中提取最相关的知识。 任何搜索过程都可以用于检索可以把检索当作一个外部扩展的工具无论是通过Restful API 还是通过向量搜索只要能检索出输出问题想匹配的信息满足相关的上下文输出给大模型那么这个检索过程就是符合要求的。 建立索引的过程也是Embedding的过程因为模型会有上下文的限制通常情况下建立私域知识库时会先将文档进行“切片”。切片对于RAG是一个很重要的部分如果将一个大文档直接输入给大语言模型根本没什么意义这样检索出来的信息太泛化了。切的太小也会造成输出质量的下降——相关性内容会丢失。 开发者必须要考虑切成什么大小才能更接近平衡点虽然LangChain 提供工具来简化这一过程但不同的文档和内容不能一概而论而是需要通过具体的场景再做权衡。索引是构建整个RAG最困难但又最重要的部分整个索引部分可以分为两步 1.加载从通常存储的位置获取知识库的内容
2.分割将知识库分割成适合嵌入搜索的片段大小的块。 适合这个词在软件工程中让人感觉格格不入到底什么是适合这句话和食谱中的“适量”有着相同的迷惑性似乎存在各种不确定性。将用户输入的问题和一大堆的提示词结合在一起将它们向量化后在另外一堆向量数据中进行匹配最终输入给一个黑盒并企图它能输出优质内容这更像是《计算机程序的构造和解释》前言中描述的魔法因为它真的能运行。 三、如何优化提问 怎样提一个好问题从主观上来讲如果别人问我们一个问题比较理想的情况是回答者只要稍加思索便能准确捕捉到其中的关键点从而轻松回答出对方想要的答案。 上述描述肯定不是一个好的回答因为太理想化现实生活中因为问题质量差而导致得不到回答的例子比比皆是那么又怎么能奢求大模型输出高质量的回答呢提一个好的问题是有门槛的否则互联网也不会存在关于“如何提一个好问题”的文章市面上也不会存在指导人们如何提问的书。 反过来通过现实生活的思考优化对大模型的提问似乎也是可行的。我们更希望问题中提供充足的相关背景足够简单具体的词句目的明确。 但事实上应用无法决定用户输入什么输入可以是一个简短的单词它不存在上下文或过于概括也可能不存在目的性。在这种情况下有一种思路是将一个问题生成多个问题以此来丰富整个问题。 输入向量生成解释向量这个词
生成向量这一概念存在于哪些领域
生成请解释计算机领域中的向量
生成请解释物理学中的向量
生成请解释数学中的向量... 在私域场景下将一个问题生成多个问题的方式称为Multi Query在这种情况下不同的问题自然会生成各自相关的检索也可能在同一份文档中得到相同的块。在Multi Query中可以做的相对简单一点直接去重就好了。 RAG-Fusion中会对检索后的信息进行排序这背后的意义在于文档块在多次被检索后出现的频率可以用作被分析的指标就像传统应用中的热点缓存通过分析某些重合的文档片段相似度来进行一个统一的排序提高多次命中的热点文档片段在上下文中的排序。 将问题具象 将问题具象化很符合人类的思考方式现实生活中将一个大的问题拆分成多个子问题小的问题更容易回答只要回答这些小的问题大的问题也迎刃而解。同时这些小的问题也存在一定的关联性更像是一个逐步递进的过程 通过提示词将一个抽象的问题拆分成具象化的子问题并要求这些问题依次回答然后将答案作为检索文档的一部分为下一个问题提供信息依据。 输入如何写作生成写作的基本概念是什么
答案写作是使用文字来表达思想、情感和信息的一种方式。生成写作有哪些不同的类型和风格
答案写作类型包括但不限于小说、散文、诗歌、剧本、报告、学术论文等。风格则根据作者的个人特点和写作目的而有所不同。生成如何确定写作的主题或论点
答案确定主题或论点通常基于个人兴趣、专业领域、社会热点或读者需求。...答案写作是一个复杂的过程但可以分解为几个关键步骤来逐一掌握。以下是写作的基本指南
1.确定写作目的首先明确你写作的目的是什么是为了传达信息、娱乐读者、还是表达个人观点。
2.选择主题根据你的写作目的选择一个你感兴趣且具有一定知识基础的主题。
3.进行研究如果需要进行必要的研究以收集信息和数据确保你的内容准确无误。
4.构思大纲创建一个大纲概述你的文章结构包括引言、主体段落和结论。
5.撰写初稿根据大纲开始写作不必担心初稿的完美关键是将想法转化为文字。 可预见的是如果一个问题本身就很具体如果再进行子任务的拆分那么不可避免的到一些无意义的信息这样不仅不会提高输出的质量反而会下降。这也意味着这种处理方式只适合太过概括或抽象的问题。如果太抽象的问题可以将它们具体化那么具体的问题能不能抽象化呢 将问题抽象化可以拔高视角再与原问题进行检索以得到更全面的信息。 HyDE(Hypothetical Document Embeddings) 提供另外一种思路如果用户输入的问题过于简短那么可以基于LLM的能力生成一个假设性文档再对这个文档进行检索。这也是一种将问题抽象化的方式但显而易见的是对于现阶段AI应用来说它的效果可能并不好——如今AI应用都在极力降低LLM的幻觉这种生成假设性文档的内容方式显然会加剧幻觉的不可控。当然这种思路至少看起来会让问题产生更多的创造性。 上述是从应用的角度在“如何提问”这个维度进行分析从用户的角度有一个小技巧也可以提高输出质量即用多种不同的语言提问会得到完全不一样的答案。LLM 在训练时的预料质量和数据量都会影响输出的质量不同语言的语言语法也不一样这点会很直观地反映到输出内容中。 四、路由和高级查询 优化问题最简单方式就是增加问题的覆盖面将一个问题变成多个问题意图得到更多的信息并加以分析。但私域文档能否提供足够的信息满足这些问题或者如何找到契合的文档 路由(Routing)将这些衍生出来的问题通过分发将不同的问题映射到契合度更高的模版中在不同场景使用不同的处理方式。 Logincal 当一个问题产生后需要思考的是这个问题使用什么处理方式才是最优解是传统的SQL查询是图查询还是进行向量索引 一个常见的场景是用户输入一个指向性十分具体的问题比如查询某年月日发生的事件的内容这种情况下不需要任何生成的“创新”使用传统检索的方式可能会更好但如果依然使用向量检索在向量数据库中本身就存有大量关联性的数据在这种关联数据过于紧密的情况下反而会分散LLM的注意力导致输出结果并不理想。 路由的作用就是在不同情况下使用不同的检索数据但路由不是通过编程去实现的在AI应用的构建中路由是通过LLM的相关能力完成的这点虽然和传统的网络路由有相近的部分但它的构建有着本质的区别。 传统应用在并发量较大时会将数据库分表分库在构建AI应用时也可以沿用这样的思路当私域文档过于庞杂后通过多个向量数据库存放不同领域的文档再通过路由分流以适用于各个场景。 Semantic routing 不是每个私域都存在大量文档在某些轻量级的场景下使用多个向量数据库未免太过奢侈。模版也可以做语义化或近似度的匹配Semantic routing的思路是将路由分到不同的提示词模版在此之前直接将问题和提示词模版做向量化当两者结合后在向量数据库中直接做近似度匹配。 使用向量数据库的原因是私域文档或文档内容信息太多所以才需要使用向量索引提升检索效率向量存储做非结构化很好但是在AI领域中依然没有银弹。使用自然语言查询关系性数据库或图数据库也是很常见的需求场景。 五、丰富索引结构 在过程概述这一小节中提到切片对于RAG是一个很重要的部分将一个文档切分成若干个片段比较简单的方式可以基于换行或段落来进行切片。如果这个文档中包含代码的片段(代码中的换行较多)那么切分出来的结果可能太过散乱LLM并不能有效对这些信息加以分析。如果切得太大会导致上下文长度过长切片中的噪音也会影响LLM的幻觉。 如果存在很多文档在切片前可以使用一些特定函数将这些文档先进行聚合合并成一个聚合文档其中的特点是将整个过程聚合的文档都存入向量数据库中在这个过程中可以形成一个阶梯状的多层级结构。这种方式的好处是无论回溯还是检索在不同层面都能找到对应的检索点。 在[优化提问]中将一个问题变成多个问题为的是丰富上下文的信息将多个文档聚合的每个阶段都保留下来也是为了有更好的召回率而且细化了每个节点增加了命中率。 文档中不仅仅只包含文本也有可能包含大量的图片图表等信息。这种情况下仅仅依靠切分文本信息是不够的LangChain建议是使用unstructured框架将其中的复杂内容单独提取出来然后通过LLM分别将它变为文本的摘要最后再将这些信息分别向量化于原文档一同进行存储。在检索时根据源文件和检索信息相似度拟合会有更好的召回率。 从技术理论上思考似乎潜力很大在实际应用场景下会更复杂且多变对于某些特定领域使用通用的向量化可能也不太适用。在某些场景下建议使用专有的向量化模型进行enbeddings比如ColBERT。 现有的开源大模型训练趋势是生产出通用能力的模型这更像是一个基础的操作系统AI应用在LLM的基础上扩展某一领域的能力这些方式会有诸多限制比如受限于上下文受限于模型的能力在复杂场景下虽然理论思路层出不穷但构建AI应用时会受到很多挑战。 比较理想化的情况是让各个领域训练专有模型在此基础上构建AI应用会相对容易也更容易发挥出模型的能力。但反过来思考可能某些领域受限于高昂的算力和成本走向弱势化最终趋同单一化。 六、重排序上下文 从[优化提问]开始生成的问题本身可能就是经过某种关联关系衍生的这个生成的过程本身就包含一定权重。对文档切片时文档内容本身也是存在关联的一般都是从简到繁。经过这些观察很容易想到如果文档中的某一部分命中率较高是不是能提高它的权重让LLM更好的输出文档优质的内容 但从排序来看通过权重来控制索引的排列顺序这点类似于搜索引擎。但不同于权重算法来决定顺序在RAG中重新排序是计算问题和文档中间的相关性按照从高到低进行排序。因为LLM上下文的限制需要对输入窗口TopK值进行调整。即使上下文可能很大但过多的信息依然会分散LLM的注意力毕竟可能引入了过多的低相关性的信息。 七、总结 本文简单概述RAG以及构建过程讨论了如何优化提问路由索引切片和重新排序这几种方式提高输出质量。 RAG是一种简单而又强大的技术可以仅靠三行代码构建出一个简易应用相比Agent对LLM能力要求也较低又可以显著提升在特定领域的应用能力。随着技术的爆发性进步层出不穷优化RAG的思路在努力消除大语言模型带来的幻觉提供更准确更相关的信息从而生成更高质量的内容。 作者王凯| 后端开发工程师 学习资料
1、从零开始学习RAG
2、How do domain-specific chatbots work? An Overview of Retrieval Augmented Generation (RAG)
3、https://rolen.wiki/talk-to-a-successful-american-with-seven-kids
4、http://www.catb.org/~esr/faqs/smart-questions.html
5、https://medium.com/narenderbeniwal1234/multi-vector-retriever-for-rag-on-tables-text-and-images-775815fcb777
