赞
踩
生成式AI技术很强大,但它们受到知识的限制。 虽然像 ChatGPT 这样的LLM可以执行许多任务,但每个LLM的基线知识都存在基于其训练数据的差距。 如果你要求LLM写一些关于最近趋势或事件的文章,LLM不会知道你在说什么,而且回答最好是混合的,坏的情况下往往还是有问题的。
LLM基于知识的问题归结为两个关键问题:
在线工具推荐: Three.js AI纹理开发包 - YOLO合成数据生成器 - GLTF/GLB在线编辑 - 3D模型格式在线转换 - 可编程3D场景编辑器
检索增强生成 (RAG:Retrieval Augmented Generation) 是一种有助于解决这两个问题的策略,它将信息检索与一组精心设计的系统提示相结合,将LLM锚定在从外部知识存储检索的精确、最新和相关信息上。 尽管LLM训练数据保持静态,但利用这种背景知识提示LLM可以创建需要对事实进行深入且不断发展的理解的特定领域应用程序。
你可以问LLM“什么是 RAG?”,根据LLM本身是否使用 RAG,可能会得到截然不同的答案:
“RAG是什么?” 有RAG的LLM响应:
RAG(检索增强生成)是 Meta AI 研究人员引入的一种方法,它将信息检索组件与文本生成器模型相结合,以解决知识密集型任务。 可以有效地修改其内部知识,而无需重新训练整个模型。 您想了解更多详细信息吗?
“RAG是什么?” 没有 RAG 的LLM响应:
根据上下文,RAG 可以指多种不同的事物。 以下是一些常见的含义:
1. 红色、琥珀色、绿色 (RAG):在项目管理和报告中,RAG 是一种颜色编码系统,用于快速传达项目或任务的状态或运行状况。
2. RAG分析:这是一种用于风险评估或决策的方法。 它涉及根据风险或选项的严重程度、影响或可取性将其分类为红色、琥珀色或绿色。 它有助于优先考虑行动或选择。
3. 随机访问生成器 (RAG):在某些技术背景下,RAG 可能指生成随机访问模式或数据的系统或算法,通常用于计算机科学或信息检索。
4.资源分配图(RAG):在操作系统和计算机科学的背景下,资源分配图用于死锁检测。 它是一个有向图,表示系统中进程之间的资源分配和请求关系。
如果你有特定的上下文或领域,请提供更多详细信息,我可以在该上下文中为你提供有关“RAG”的更准确的解释。
使用和不使用 RAG 来回答这个问题有很大区别。 特别是在涉及特定领域知识(如首字母缩略词)的情况下,RAG 可以极大地提高LLM回答的准确性。
如果你与了解最近事件、了解用户特定信息或对某个主题比正常情况有更深入了解的聊天机器人进行过交互,那么很可能在没有意识到的情况下与 RAG 进行了交互。 如果你看过有关“通过文档聊天”的教程,那么这就是 RAG 最简单的版本。 LangChain 和 LlamaIndex 等框架使快速创建简单的知识感知应用程序成为可能,从而实现了 RAG 的民主化。
我开发并实现了 Skyflow 内部的 LLM 应用程序,包括使用 RAG 的系统。 由于 RAG 几乎无处不在,并且不会很快消失,因此了解 RAG 的基础知识以及当你想要将代码转移到生产环境时如何超越这些基础知识非常重要。 我邀请你学习我在 RAG 旅程中的经验,这样你就不必经历艰难的摸索过程。
LangChain 提供了一个 RAG 最小(但不是最简单)形式的示例:
- from langchain.document_loaders import WebBaseLoader
- from langchain.indexes import VectorstoreIndexCreator
- loader = WebBaseLoader("https://www.promptingguide.ai/techniques/rag")
- index = VectorstoreIndexCreator().from_loaders([loader])
- index.query("What is RAG?")
通过这五行代码,我们得到了 RAG 的描述,但代码是高度抽象的,因此很难理解实际发生的情况:我们获取网页的内容(本示例的知识库)。
虽然此脚本有助于原型设计和理解使用 RAG 的主要节拍,但它对于超越该阶段并不是那么有用,因为你没有太多控制权。 让我们讨论一下实际执行的内容。
由于完整的 LLM 应用程序架构相当大,因此我们将仅考虑启用 RAG 的组件:
在典型的LLM应用程序中,你的推理处理脚本会根据需要连接到检索工具。 如果你正在构建基于 LLM 代理的应用程序,则每个检索实用程序都会作为工具向你的代理公开。 从这里开始,我们将只讨论典型的基于脚本的用法。
当用户触发你的推理流程时,编排层会将必要的工具和 LLM 结合在一起,以从你的检索工具中收集上下文并生成上下文相关的知情响应。 编排层处理所有 API 调用和特定于 RAG 的提示策略(我们很快就会谈到)。 它还执行验证,例如确保你没有超出 LLM 的令牌限制,这可能会导致 LLM 拒绝你的请求,因为你在提示中填充了太多文本。
要查询数据,你不仅需要数据,还需要应用程序可以访问的格式。 对于基于 LLM 的应用程序,这通常涉及向量存储 - 一个可以基于文本相似性而不是精确匹配进行查询的数据库。
将数据从源格式转换为矢量存储需要 ETL(提取、转换、加载)管道。
存储向量后,你可以查询向量存储并查找与你的查询最相似的内容。 如果您需要更新或添加源文档,大多数向量数据库都允许更新存储。 这意味着你还可以从矢量存储中删除内容,这是微调模型时无法执行的操作。
你可以再次运行管道来重新创建整个知识库,虽然这比重新训练模型成本更低,但它仍然耗时且效率低下。 如果你希望定期更新源文档,请考虑创建文档索引流程,以便仅处理管道中的新文档和最近更新的文档。
从向量存储中检索并不是唯一的检索类型。 如果你有任何允许编程访问的数据源(客户记录数据库、内部票务系统等),请考虑让你的编排层可以访问它们。 在运行时,你的编排层可以查询基于 API 的检索系统,以提供与当前请求相关的其他上下文。
设置好检索工具后,就可以使用一些编排层魔法将它们编织在一起。
首先,我们将从提示模板开始。 提示模板包含你想要作为提示的一部分传递给 LLM 的所有信息的占位符。 系统(或基本)提示符告诉LLM如何表现以及如何处理用户的请求。 一个简单的提示模板可能如下所示:
- System: You are a friendly chatbot assistant that responds in a conversational
- manner to users' questions. Respond in 1-2 complete sentences, unless specifically
- asked by the user to elaborate on something. Use History and Context to inform your answers.
- ---
- History: {history}
- ---
- Context: {context}
- ---
- User: {request}
当你的最终用户提交请求时,你就可以开始填写变量。 如果用户提交“什么是RAG?”,你可以填写请求变量。 你可能会随请求一起获得对话历史记录,因此也可以填写该变量:
- System: You are a friendly chatbot assistant that responds in a conversational
- manner to user's questions. Respond in short but complete answers unless specifically
- asked by the user to elaborate on something. Use History and Context to inform your answers.
- ---
- History: [{"role": "assistant", "message": "Hi! How can I help you?"}]
- ---
- Context: {context}
- ---
- User: What is RAG?
接下来,调用你的检索工具,无论它们是矢量存储还是其他 API。 一旦你掌握了上下文(知识库结果、客户记录等),就可以更新上下文变量,以便在推理过程中为 LLM 提供信息和基础。
注意:如果你的 RAG 实施中包含多种类型的数据,请确保对它们进行标记,以帮助LLM区分它们。
- System: You are a friendly chatbot assistant that responds in a conversational
- manner to user's questions. Respond in short but complete answers unless specifically
- asked by the user to elaborate on something. Use History and Context to inform your answers.
- ---
- History: [{"role": "assistant", "message": "Hi! How can I help you?"}]
- ---
- Context: [Document(page_content='Meta AI researchers introduced a method called [Retrieval Augmented Generation](https://ai.facebook.com/blog/retrieval-augmented-generation-streamlining-the-creation-of-intelligent-natural-language-processing-models/) (RAG) to address such knowledge-intensive tasks. RAG combines an information retrieval component with a text generator model. RAG can be fine-tuned and its internal knowledge can be modified in an efficient manner and without needing retraining of the entire model.', metadata={'source': 'https://www.promptingguide.ai/techniques/rag', 'title': 'Retrieval Augmented Generation (RAG)'})]
- ---
- User: What is RAG?
上下文就位后,提示模板已填写,但你仍然有两个后处理任务需要完成:
一旦你的提示被清理并在令牌限制内,就可以通过将提示发送到你选择的LLM来执行推理。 当你收到响应时,它应该根据你提供的上下文进行通知,并且你可以将其发送回用户。
现在你的应用程序中已经有了 RAG,你可能希望立即投入生产。 还不做! 或者,你可能对所得到的结果并不那么兴奋。 不用担心,你可以采取以下一些措施来提高 RAG 性能并做好生产准备:
在结束之前,让我们先讨论另一个与 LLM 相关的流行语:微调。
微调和 RAG 提供了两种不同的方法来优化 LLM。 虽然 RAG 和微调都利用源数据,但它们都有独特的优势和需要考虑的挑战。
微调是一个继续使用附加数据训练模型的过程,使其在数据集详细说明的特定任务和领域上表现更好。 然而,单一模型不可能在所有方面都是最好的,并且与微调任务无关的任务通常会随着额外的训练而降低性能。 例如,微调是创建特定于代码的 LLM 的方式。 Google 的 Codey 在各种语言的代码示例精选数据集上进行了微调。 这使得 Codey 在编码任务方面的表现明显优于 Google 的 Duet 或 PaLM 2 模型,但代价是聊天性能一般。
相反,RAG 通过从外部知识库检索到的相关和当前信息来增强LLM。 这种动态增强使LLM能够克服静态知识的局限性,并生成更明智、更准确且与上下文相关的响应。 然而,外部知识的集成会增加计算复杂性、延迟和提示复杂性,可能导致推理时间更长、资源利用率更高和开发周期更长。
RAG 在一个特定领域比微调效果要好:遗忘。 当你微调模型时,训练数据将成为模型本身的一部分。 你无法隔离或删除模型的特定部分。 LLM 不能忘记。 但是,矢量存储允许你添加、更新和删除其内容,因此你可以随时轻松删除错误或过时的信息。
微调和 RAG 一起可以创建专门针对特定任务或领域并能够使用上下文知识的 LLM 支持的应用程序。 考虑 GitHub Copilot:它是一个经过微调的模型,专门从事编码,并使用你的代码和编码环境作为知识库,为你的提示提供上下文。 因此,Copilot 往往适应性强、准确且与你的代码相关。 另一方面,Copilot 基于聊天的响应据说比其他模型需要更长的时间来处理,并且 Copilot 无法协助完成与编码无关的任务。
RAG 代表了增强LLM能力的实用解决方案。 通过将实时外部知识集成到 LLM 响应中,RAG 解决了静态训练数据的挑战,确保所提供的信息保持最新且与上下文相关。
展望未来,将 RAG 集成到各种应用程序中有望显着改善用户体验和信息准确性。 在当今时代,及时了解最新动态至关重要,RAG 提供了一种可靠的方法来让法学硕士了解情况并保持高效。 采用 RAG 的实用性使我们能够自信而精确地应对现代人工智能应用的复杂性。
原文链接:检索增强生成架构剖析 - BimAnt
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。