大型语言模型 (LLM) 通常对广泛的主题非常了解，但仅限于训练它们所依据的数据。这意味着，希望使用 LLM 处理私人或专有商业信息的客户无法使用“开箱即用”的 LLM 来回答问题、生成信函或完成类似作业。
检索增强生成 (RAG) 是一种架构模式，它使基础模型能够针对不属于模型训练数据的专门或专有主题生成事实正确的输出。通过使用从外部数据源检索的相关数据来增强用户的问题和提示，RAG 可为模型提供（对于模型而言）“新的”事实和细节，并作为其响应的基础。
概念架构
如下图所示，RAG 模式由两部分组成：构建时的数据嵌入，以及运行时的用户提示（或返回搜索结果）。
AI 工程师在数据预处理期间准备客户数据（例如，程序手册、产品文档或帮助台工单等）。对客户数据进行转换和/或扩充，使其适用于模型增强。转换可能包括简单的格式转换（例如将 PDF 文档转换为文本），也可能包括更复杂的转换（例如将复杂的表格结构转换为 if-then 类型语句）。丰富内容可能包括扩展常见缩写、添加元数据（如货币信息）以及其他附加内容，以提高搜索结果的相关性。
嵌入模型用于将源数据转换为一系列表示客户端数据中单词的矢量。嵌入令针对大型输入（例如代表单词的稀疏矢量）进行机器学习变得更加容易。嵌入以客户数据的段落（称为块）形式存储，就像小节或段落一样，以便于查找信息。
生成的嵌入存储在向量数据库中。任何支持“模糊”查询，并根据可能的相关性返回结果的数据源（例如 watsonx Discovery）都可以在 RAG 架构中使用，但最常见的实现方式是使用向量数据库，例如 Milvus、FAISS 或 Chroma。
该系统现在可供最终用户使用。
最终用户与支持生成式 AI 的应用程序进行交互并输入查询。
生成式 AI 应用程序接收查询，并在向量数据库上执行搜索，以获取与用户查询最匹配的前几条（我们称之为前 K 条）信息。例如，如果用户的查询是“MaxSavers 账户的每日取款限额是多少”，则搜索结果可能会返回诸如“MaxSavers 账户是……”、“每日取款限额是……”以及“...账户限额...”之类的段落。
最前面的段落和针对特定应用程序精心挑选的提示都会被发送给 LLM。
LLM 会根据用户的查询、提示和上下文信息返回一个类似于人的响应，并将其呈现给最终用户。
上图展示了 IBM Watson 及 watsonx 产品系列与 RAG 架构的对应关系。
watsonx Discovery 实现了模式的预处理、嵌入生成以及相关性存储和检索功能。对于某些类型的解决方案，watsonx Discovery 还可以用作用户的前端生成式 AI 应用程序。除了简单替换向量数据库之外，watsonx Discovery 还提供开箱即用的 NLP 丰富功能，包括实体提取、情感分析、情绪分析、关键词提取、类别分类、概念标记等。
对于聊天解决方案，watsonx Assistant 提供用户界面和会话能力，例如记住之前查询的主题。例如，如果用户要求“请介绍一下 Toast-o-matic”，然后问“它多少钱？“，watsonx Assistant 知道最后一个查询中的“它”指的是前一个查询中的烤面包机。
最后，watsonx.ai 可提供一系列大型语言模型，客户可以在云环境中进行选择。借助 watsonx.ai，客户可以轻松训练、验证、调整和部署生成式 AI、基础模型和机器学习功能，并在短时间内使用少量数据构建 AI 应用程序。
有些客户在当地无法使用 watsonx.ai，或者可能存在安全问题或监管要求，导致他们无法使用 watsonx.ai SaaS 解决方案。对于这些客户，我们提供 watsonx.ai 作为一组容器化服务，这些服务可以部署在客户数据中心内运行的 Red Hat Openshift 上，也可以部署在云服务提供商基础设施内的虚拟私有云 (VPC) 上。
大多数 LLM 都接受过以英语为主的文本的训练，其中包含一小部分其他语言（通常是西欧语言）的文本。对于需要多语言或本地化语言支持的应用程序，可以实施查询前和查询后翻译步骤，将输入翻译为经预处理的文档的“基本”语言（例如英语），并将模型输出翻译为目标语言例如西班牙语。下图显示了这种方法。
这种方法改变了基本 RAG 模式，如下所示（忽略嵌入生成步骤）：
用户输入的查询语言与预处理文档的主要语言不同。例如，一个西班牙语查询和一个以英语为主的文献库。
生成式 AI 应用程序提示大型语言模型将用户查询翻译为文档库的语言。在我们的示例中，是从西班牙语翻译为英语。
翻译后的查询用于检索与用户查询最相关的前 K 段信息。
翻译后的查询以及检索到的上下文将发送到 LLM 以生成响应。
生成式 AI 应用再次使用大型语言模型将生成的响应翻译成用户的目标语言。我们的例子中是从英语到西班牙语。
翻译后的回答以西班牙语呈现给最终用户。
体验表明，使用这种方法，非基本语言结果可以实现 80% 或更高的准确性，具体取决于上下文和所提交查询的类型。新兴的多语言模型在更大比例的不同语言上进行训练，有望实现更高的准确性。
对于任何业务场景，RAG 都是一个候选解决方案，在这些场景中，用户必须查阅大量文档和业务规则才能提供权威答案。这也是一种强大的解决方案，可为基于 LLM 的聊天机器人注入专有或特定领域的知识，防止出现幻觉。
候选用途包括：
保险承保和理赔。 RAG 在保险行业内有许多潜在的应用。承保员和经纪人需要深入了解数千页的文件，涵盖数百种保险产品的条款和条件。同样，索赔裁定员可能需要对相同的文件以及特定于个人客户的具有优先权和附加条款的合同有深入的了解。RAG 架构模式可以作为解决方案的架构“主干”，帮助承保人、经纪人和险损估价人查询产品和合同文档，从而更好地响应客户查询并提高流程效率。
呼叫中心坐席支持。 呼叫中心坐席需要深入了解成百上千种产品和服务，以及常见产品问题及其解决方案。RAG 模式是一个强大的架构基础，可用于创建解决方案，帮助坐席快速找到客户请求的答案。
客户聊天机器人。 RAG 是创建面向客户的问答聊天机器人的有力支撑。将大语言模型的自然语言能力与 RAG 的企业特定响应相结合，可以带来引人入胜的对话式客户体验。请注意，RAG 本身仅提供问答能力；它不具备“执行事务操作”的能力，即与企业系统交互以提取信息或更新记录。必须添加其他组件来检测用户意图并与企业系统交互。
支持/帮助台。与客户服务中心座席人员一样，IT 运营和支持人员也需要深入了解复杂系统部署配置，以及常见问题和以前出现过的问题及其解决方法。RAG 模式是构建解决方案的强大架构基础，可帮助支持人员快速找到所报告问题和观察到得问题的相关答案。
架构决策和注意事项
选择适合您项目的模型需考虑众多因素。
模型的许可证可能会限制其使用方式。例如，模型许可证可能会阻止将其用作商业应用程序的一部分。
用于训练此模型的数据集会直接影响模型在特定应用程序中的运行效果，并严重影响模型可能会生成无意义、令人反感或根本不需要的回复的风险。同样，使用受版权保护的数据或私有数据来训练的模型可能会导致用户承担法律责任。IBM 提供训练数据的全面透明度，并可对其模型引发的法律索赔提供赔偿。
模型的规模、训练时使用的参数数量以及上下文窗口的大小（模型可接受多长的文本段落）均会影响模型的性能、资源需求和吞吐量。遵循“越大越好”的理念并选择一个包含 200 亿个参数的模型固然十分诱人，但资源需求和准确性的提高（如果有的话）却可能无法证明此举是明智之举。最近的研究表明，对于某些解决方案，较小的模型可能明显优于较大的模型。
对模型进行任何微调均可能会影响其对任务的适用性。例如，IBM 提供两个版本的 Granite 模型：一种针对常规聊天应用程序进行了调整，而另一种则为遵循指令而进行了调整。
选择模型时的其他考量因素包括：
模型参数的选择（例如，模型温度），可平衡类似人类的文本与真实回复的创建。将模型温度设为较高的值会生成一致但可能较为乏味或过于简洁的回复，而将温度设为较低的值则可在回复中引入更多变化，但同时也会增大回复长度与内容方面的不可预测性。
模型防范措施的选择和实施，可防止出现无效或令人反感的结果。
模型的选择取决于应用程序、数据类型和语言支持要求。可能必须扩展嵌入模型，以便对行业或客户特定的术语或首字母缩略词进行准确的编码和搜索。
矢量数据库只是实现嵌入数据存储的一种选择。Watson Discovery 可提供额外的工具和功能，能够提高 RAG 解决方案的性能和准确性；而某些“传统”数据库会提供矢量存储和搜索，以及/或支持 RAG 解决方案的相似性搜索。
矢量数据库也有许多选项。直接嵌入到生成式 AI 应用程序中的简单内存数据库可提供出色的运行时性能，但可能无法很好地扩展到大型数据集，并且在与时俱进或扩展到多服务器配置的时候，可能会带来重大操作挑战。其他使用中央服务器架构的数据库更易于操作和扩展，但可能无法满足特定解决方案的性能需求。
有许多方法可用于集成检索和生成模型。检索前 K 段信息并使用它们来增强用户查询既简单又方便，但它可能缺乏回答复杂问题所需的细微差别。简单地通过关键字搜索也可能会得到满意的结果。
更复杂的解决方案可能会使用 LLM 从用户的原始查询中生成多个查询，并加以利用来检索更多的段落。可以添加其他逻辑来进一步排序并选择检索到的相关性最高的段落。
将数据输入 RAG 系统之前，对数据进行预处理是一个重要步骤，可确保输入数据的格式适合模型。简单的方法是将输入数据分解成固定大小且重叠的块，例如数据块的最后 10 个字符与下一个数据块的前 10 个字符相同，但这可能会忽略掉输入数据中的细微差别。
更高级的预处理可以操纵输入文本以删除常见的词尾，例如 stopper、stopping 和 stopped 都变为 stop；删除无信息量的“停止”词，例如 the、as、is 等；以及其他技术。这些可以大大提高检索到的信息的相关性，但会增加数据嵌入和用户提示阶段的复杂性。
更高级的技术可以对完整的句子进行操作，以尽可能多地保留文本中的含义。
由于任务的复杂性，评估 RAG 系统的性能可能具有挑战性。常见的评估指标包括困惑度、流畅度、相关性和连贯性，以及 BLU 和 ROUGE 指标。选择与任务的具体目标和期望结果相符的指标非常重要。
RAG 需要纯文本，转换方法的选择对数据质量有很大影响。例如，转换 PDF 文件时，如何处理表格、图像和其他元数据元素。
从 LLM 生成类似人类的响应需要大量的计算资源，通常可能需要几秒钟的时间，具体取决于模型的大小、用户查询的复杂度以及传递到模型的扩增后信息量。需要为大型用户群提供服务或需要快速响应的解决方案可能需要实施一种机制来缓存对频繁出现之查询的模型响应。
在 LLM 提示中嵌入专有信息、潜在机密信息和潜在个人身份信息是 RAG 模式的核心和必要条件。使用托管模型平台的组织必须了解提供商政策，例如提示的数据保留和使用政策（例如，提供商是否捕获提示数据，并将其用于模型重新训练？），加以控制，以防止提示数据“泄露”给其他用户等；并根据自己的信息安全政策和控制取得平衡。
虽然某些专有信息的传输是不可避免的，但组织可以通过在处理的数据中仅包含对最敏感信息的文档或 URL 引用来限制暴露。例如，不要将价格折扣表嵌入到 RAG 数据中，而应在内容中仅包含表格的描述以及内部文档或网站的参考或链接。
区域间通信的简单传输层安全 (TLS) 可能足以满足数据安全要求，但架构师可能需要考虑通过添加组件来提供额外的保护，以便在跨区域边界传递提示和响应之前对提示和响应进行加密。
部署区域之间的连接类型会影响一些非功能需求。通过公共互联网使用虚拟专用网 (VPN) 连接是一种低成本的选择，但它可能无法完全消除安全忧虑，也可能无法满足解决方案的响应时间或吞吐量要求。与模型托管环境建立专用网络连接的成本要高得多，但安全性要好得多，并且为架构师提供了控制网络延迟和带宽的能力。