探索我们基于研究的 RAG 评估指标——阅读我们关于 Chainpoll的论文。
欢迎回到我们的 Mastering RAG 系列！让我们撸起袖子，深入研究构建企业RAG系统的复杂世界。
尽管互联网上充斥着有关简单 RAG 系统的文章，但构建强大的企业级解决方案的历程往往是一个谜。
但这篇博客不仅仅是一次理论之旅；它是帮助您采取行动的实用指南！从护栏在确保安全方面的重要性到查询重写对用户体验的影响，我们在这里提供可操作的见解和真实示例。无论您是经验丰富的开发人员还是掌舵的技术领导者，系好安全带，深入探索尖端企业 RAG 的错综复杂的世界！
在介绍 RAG 架构之前，我想先分享一项关于构建 RAG 系统时常见故障点的最新研究。研究人员分析了三个跨不同领域的案例研究，发现了七个常见的 RAG 故障点。
构建 RAG 系统的挑战
案例研究
认知审阅者
认知审阅器是一种 RAG 系统，旨在协助研究人员分析科学文献。研究人员定义研究问题或目标，并上传相关研究论文集。然后，系统根据所述目标对所有文档进行排序，以供研究人员进行人工审阅。此外，研究人员可以直接针对整个文档集提出问题。
人工智能导师
另一个 RAG 系统 AI Tutor 允许学生就某个单元提问，并根据学习内容获得答案。学生可以通过访问来源列表来验证答案。AI Tutor 集成到迪肯的学习管理系统中，索引所有内容，包括 PDF、视频和文本文档。该系统使用 Whisper 深度学习模型转录视频，然后再进行分块。RAG 管道包含一个用于查询泛化的重写器，聊天界面利用过去的对话作为每个问题的上下文。
生物医学问答
在生物医学问答案例研究中，使用 BioASQ 数据集创建了一个 RAG 系统，其中包含问题、文档链接和答案。该数据集由生物医学专家准备，包括特定领域的问答对。问题的答案可以是是/否、文本摘要、事实或列表。
RAG 系统的 7 个故障点
通过这些案例研究，他们确定了设计 RAG 系统时经常出现的七个故障点。
缺失内容（FP1）
提出的问题无法通过现有文档回答。在理想情况下，RAG 系统会回复“抱歉，我不知道”之类的消息。但是，对于与内容相关的问题，如果没有明确的答案，系统可能会被误导而提供答案。
错过了排名靠前的文档（FP2）
文档中存在问题的答案，但排名不够高，无法包含在返回给用户的结果中。虽然理论上所有文档都会被排名并在后续步骤中使用，但实际上只会返回排名前 K 的文档，其中 K 是根据性能选择的值。
不在上下文中 - 合并策略限制（FP3）
从数据库中检索到包含答案的文档，但无法将其放入生成响应的上下文中。当返回大量文档时，就会发生这种情况，从而导致合并过程，从而阻碍相关答案的检索。
未提取（FP4）
答案存在于上下文中，但模型无法提取正确的信息。这种情况通常发生在上下文中存在过多噪音或相互矛盾的信息时。
格式错误（FP5）
问题涉及以特定格式（例如表格或列表）提取信息，而模型忽略了该指令。
特异性不正确（FP6）
响应包含答案，但缺乏所需的特异性或过于具体，无法满足用户的需求。当 RAG 系统设计人员对给定问题有预先确定的结果时，例如教师寻求教育内容，就会发生这种情况。在这种情况下，应与答案一起提供具体的教育内容。当用户不确定如何表述问题并且过于笼统时，也会出现不正确的特异性。
不完整（FP7）
不完整的答案是准确的，但缺少一些信息，即使这些信息存在于上下文中并且可以提取。例如，对于“文档 A、B 和 C 中涵盖的要点是什么？”这样的问题，最好分别提出这些问题。
下表列出了他们从解决每个问题中吸取的教训。在构建我们的企业 RAG 系统时，我们将牢记这些教训。
如何构建企业 RAG 系统
现在我们已经确定了设计 RAG 系统时面临的常见问题，让我们来看看每个组件的设计需求和作用，以及构建它们的最佳实践。上面的 RAG 系统架构图提供了每个组件的使用位置和方式的背景信息。
用户身份验证
一切从这里开始——我们系统中的第一个组件！在用户开始与聊天机器人交互之前，我们需要出于各种原因对用户进行身份验证。身份验证有助于实现安全性和个性化，这对于企业系统来说是必不可少的。
访问控制
身份验证可确保只有授权用户才能访问系统。它有助于控制谁可以与系统交互以及他们可以执行哪些操作。
数据安全
保护敏感数据至关重要。用户身份验证可防止未经授权的个人访问机密信息，从而防止数据泄露和未经授权的数据操纵。
用户隐私
身份验证可确保只有目标用户才能访问其个人信息和帐户详细信息，从而帮助维护用户隐私。这对于与用户建立信任至关重要。
法律合规
许多司法管辖区和行业都有法规和法律，要求组织实施适当的用户身份验证以保护用户数据和隐私。遵守这些法规有助于避免法律问题和潜在的处罚。
问责制
身份验证通过将系统内的操作与特定用户帐户绑定来确保责任的可追溯性。这对于审计和跟踪用户活动至关重要，有助于识别和解决任何安全事件或可疑行为。
个性化和定制
身份验证使系统能够识别单个用户，从而实现用户体验的个性化和定制化。这可以包括定制的内容、偏好和设置。
AWS Cognito或Firebase Authentication等服务可以帮助您轻松地将用户注册和身份验证添加到移动和 Web 应用程序。
输入护栏
防止用户输入可能有害或包含私人信息的信息至关重要。最近的研究表明，越狱 LLM很容易。这就是输入护栏的作用所在。让我们看看我们需要护栏的不同场景。
匿名化
输入护栏可以匿名化或删除个人身份信息 (PII)，例如姓名、地址或联系方式。这有助于保护隐私并防止恶意泄露敏感信息。
限制子字符串
禁止可能被用于 SQL 注入、跨站点脚本 (XSS) 或其他注入攻击的某些子字符串或模式，可防止安全漏洞或不良行为。
限制主题
为了限制与特定主题相关的可能不适当、冒犯或违反社区准则的讨论或输入，过滤掉涉及仇恨言论、歧视或露骨内容的内容非常重要。
限制代码
防止可能危害系统安全或导致代码注入攻击的可执行代码的注入至关重要。
限制语言
验证文本输入是否采用正确的语言或脚本，以防止潜在的误解或处理错误。
检测即时注入
减轻注入误导性或有害提示的尝试，这些提示可能会操纵系统或以非预期的方式影响 LLM 的行为。
限制代币
对用户输入实施最大令牌或字符限制有助于避免资源耗尽并防止拒绝服务 (DoS) 攻击。
检测毒性
实施毒性过滤器来识别和阻止包含有害或辱骂性语言的输入。
为了保护您的 RAG 系统免受这些情况的影响，您可以利用Meta 的Llama Guard 。您可以自行托管它，也可以使用Sagemaker等托管服务。但是，不要指望它在检测毒性方面是完美的。
查询重写器
一旦查询通过了输入护栏，我们就会将其发送给查询重写器。有时，用户查询可能很模糊，或者需要上下文才能更好地理解用户的意图。查询重写是一种有助于解决此问题的技术。它涉及转换用户查询以增强清晰度、准确性和相关性。让我们来看看一些最流行的技术。
根据历史重写
在这种方法中，系统利用用户的查询历史来了解对话的背景并增强后续查询。让我们以信用卡查询为例。
查询历史记录：
“您有几张信用卡？”
“白金信用卡和金卡有年费吗？”
“比较两者的特点。”
我们必须根据用户的查询历史来识别上下文的演变，辨别用户的意图和查询之间的关系，并生成与演变上下文相一致的查询。
重写查询：“比较白金卡和金卡的特点。”
创建子查询
由于检索问题，复杂的查询可能难以回答。为了简化任务，查询被分解为更具体的子查询。这有助于检索生成答案所需的正确上下文。LlamaIndex 将此称为子问题查询引擎。
给定查询“比较白金信用卡和金卡的特点”，系统会为每张卡生成子查询，重点关注原始查询中提到的各个实体。
重写子查询：
- “白金信用卡有什么特点？”
- “金卡信用卡有什么特点？”
创建类似查询
为了增加检索到正确文档的机会，我们根据用户输入生成类似的查询。这是为了克服检索在语义或词汇匹配方面的局限性。
如果用户询问信用卡功能，系统会生成相关查询。使用同义词、相关术语或特定领域知识来创建符合用户意图的查询。
生成的类似查询：
“我想了解白金信用卡” -> “请告诉我白金信用卡的好处。”
编码器
一旦我们有了原始查询和重写查询，我们就会将它们编码为向量（数字列表）以供检索。选择编码器可能是构建 RAG 系统时最重要的决定。 让我们 探讨一下选择文本编码器的原因以及需要考虑的因素。
利用 MTEB 基准
要全面评估编码器的功能，首选来源是Massive Text Embedding Benchmark (MTEB)。此基准允许根据向量维度、平均检索性能和模型大小对编码器进行细致的选择。虽然 MTEB 提供了有价值的见解，但必须以一定程度的怀疑态度对待结果，因为没有一刀切的评估基准，并且模型训练数据的细节可能未完全披露。
MTEB 不仅提供了对 OpenAI、Cohere 和 Voyager 等流行嵌入性能的洞察，还揭示了某些开源模型表现出接近的性能水平。但是，需要注意的是，这些结果提供了一般概述，可能无法准确表明这些嵌入在您的域的特定上下文中的表现如何。因此，在做出最终选择之前，必须对您的数据集进行彻底的评估，强调自定义评估方法的重要性。
定制评估
编码器可能无法始终提供最佳性能，尤其是在处理敏感信息时。在这种情况下，自定义评估方法变得至关重要。以下是执行自定义评估的三种方法。
通过注释进行评估
生成专用数据集并设置注释以获得黄金标签。注释后，利用平均倒数排名 (MRR) 和正则化折扣累积增益 (NDCG) 等检索指标定量评估不同编码器的性能。
通过模型评估
遵循与注释方法类似的数据生成过程，但使用 LLM 或交叉编码器作为评估器。这允许在所有编码器之间建立相对排名。随后，对前三名编码器进行手动评估可以得出精确的性能指标。
通过聚类进行评估
采用不同的聚类技术，并分析不同 Silhouette 分数下的覆盖率（聚类数据量），表明聚类内的向量相似性。使用 HDBSCAN 等算法进行实验，调整其参数以获得最佳性能选择。这种基于聚类的评估提供了有关数据点分布和分组的宝贵见解，有助于选择符合特定指标的编码器。
选择文本编码器的考虑因素
在选择编码器时，您需要在私有编码器和公共编码器之间做出选择。您可能会倾向于使用私有编码器，因为它易于使用，但这两种选择之间需要权衡一些特定的利弊。这是一个重要的决定，它将决定您的系统的性能和延迟。
查询费用
确保语义搜索的流畅用户体验依赖于嵌入 API 服务的高可用性。OpenAI 和类似提供商提供可靠的 API，无需托管管理。然而，选择开源模型需要根据模型大小和延迟需求进行工程设计。较小的模型（最多 1.1 亿个参数）可以使用 CPU 实例托管，而较大的模型可能需要 GPU 服务来满足延迟要求。
索引成本
设置语义搜索涉及索引文档，这会产生不小的成本。由于索引和查询共享同一个编码器，因此索引成本取决于所选的编码器服务。为了方便服务重置或重新索引到备用向量数据库，建议单独存储嵌入。忽略此步骤将需要重新计算相同的嵌入。
存储成本
对于索引数百万个向量的应用程序，Vector DB 存储成本是一个至关重要的考虑因素。存储成本与维度成线性关系，OpenAI 的 1526 维嵌入会产生最大的存储成本。要估算存储成本，请计算每个文档的平均单位（短语或句子）并进行推断。
语言支持
为了支持您的非英语语言，请使用多语言编码器或使用翻译系统和英语编码器。
搜索延迟
语义搜索的延迟随嵌入的维度线性增长。选择较低维度的嵌入是最小化延迟的首选。
隐私
金融和医疗保健等敏感领域的严格数据隐私要求可能会降低 OpenAI 等服务的可行性。
文档摄取
文档摄取系统管理数据的处理和持久性。在索引过程中，每个文档被拆分成较小的块，然后使用嵌入模型将其转换为嵌入。然后将原始块和嵌入在数据库中进行索引。让我们看看文档摄取系统的组件。
文档解析器
文档解析器在从各种文档格式中主动提取结构化信息方面发挥着核心作用，尤其注重格式处理。这包括但不限于解析可能包含图像和表格的 PDF。
文档格式
文档解析器必须能够熟练处理各种文档格式，例如 PDF、Word、Excel 等，确保文档处理的适应性。这涉及识别和管理嵌入内容，例如超链接、多媒体元素或注释，以提供文档的全面表示。
表格识别
识别和提取文档中表格中的数据对于维护信息结构至关重要，尤其是在报告或研究论文中。提取与表格相关的元数据（包括标题、行和列信息）可增强对文档组织结构的理解。诸如Table Transformer之类的模型可用于完成此任务。
图像识别
OCR 应用于文档中的图像，以主动识别和提取文本，以便进行索引和后续检索。
元数据提取
元数据是指文档的主要内容之外的附加信息。它包括作者、创建日期、文档类型、关键字等详细信息。元数据提供了有价值的背景信息，有助于组织文档并通过考虑元数据属性来提高搜索结果的相关性。可以使用 NLP/OCR 管道提取元数据，并将其作为特殊字段与文档一起编入索引。
Chunker
如何决定标记（拆分）长文本可以决定嵌入的质量和搜索系统的性能。如果块太小，某些问题就无法回答；如果块太长，那么答案就会包含生成的噪音。您可以利用摘要技术来减少噪音、文本大小、编码成本和存储成本。
分块是一个重要但被低估的话题。它可能需要与特征工程类似的领域专业知识。例如，python 代码库的分块可能使用 def/class 之类的前缀来完成。阅读我们的博客以深入了解分块。
RAG 的分块技术
索引器
索引器 – 您猜对了 – 负责创建文档的索引，该索引用作结构化数据结构（快说 3 遍……）。索引器有助于实现高效的搜索和检索操作。高效的索引对于快速准确地检索文档至关重要。它涉及将块或标记映射到文档集合中的相应位置。索引器在文档检索中执行重要任务，包括创建索引以及添加、更新或删除文档。
索引器作为 RAG 系统的关键组件，面临着各种挑战和问题，这些挑战和问题会影响系统的整体效率和性能。
可扩展性问题
随着文档数量的增长，保持高效快速的索引变得具有挑战性。当系统难以处理越来越多的文档时，可能会出现可扩展性问题，从而导致索引和检索时间变慢。
实时指数更新
实时更新索引可能是一项挑战，尤其是在频繁添加、更新或删除文档的系统中。确保实时 API 和实时索引机制无缝运行且不影响系统性能是一项长期挑战。
一致性和原子性
在文档同时更新或修改的情况下实现一致性和原子性可能非常复杂。确保索引更新保持数据完整性（即使在同时发生更改的情况下）需要仔细的设计和实施。
优化存储空间
索引大量文档可能会产生大量的存储需求。优化存储空间，同时确保索引保持可访问性和响应性，这是一个持续的挑战，尤其是在存储成本令人担忧的情况下。
安全和访问控制
实施适当的安全措施和访问控制以防止未经授权修改索引至关重要。确保只有授权用户或流程才能执行 CRUD 操作有助于保护文档存储库的完整性。
监控和维护
定期监控索引器的运行状况和性能至关重要。检测索引失败、资源瓶颈或索引过时等问题需要强大的监控和维护程序，以确保系统长期平稳运行。
这些是一些困难但众所周知的软件工程挑战，可以通过遵循良好的软件设计实践来解决。
数据存储
由于我们要处理各种数据，因此我们需要为每种数据提供专用存储。了解每种存储类型的不同注意事项以及每种存储类型的具体用例至关重要。
嵌入
数据库类型：SQL/NoSQL
单独存储文档嵌入可以快速重新索引，而无需重新计算整个文档语料库的嵌入。此外，嵌入存储可充当备份，确保即使在系统发生故障或更新时也能保留关键信息。
文件
数据库类型：NoSQL
以原始格式存储文档对于持久存储至关重要。此原始格式是各种处理阶段（例如索引、解析和检索）的基础。它还为未来的系统增强提供了灵活性，因为原始文档保持完整并可根据需要重新处理。
聊天记录
数据库类型：NoSQL
聊天记录的存储对于支持 RAG 系统的对话功能至关重要。聊天记录存储允许系统回忆以前的用户查询、响应和偏好，使其能够根据用户的独特背景调整和定制未来的交互。这些历史数据是一种宝贵的资源，可以利用它进行研究来改进 ML 系统。
用户反馈
数据库类型：NoSQL/SQL
通过 RAG 应用程序内的各种交互机制系统地收集用户反馈。在大多数 LLM 系统中，用户可以使用点赞/点踩、星级评定和文本反馈来提供反馈。这一系列用户见解是一个宝贵的存储库，它囊括了用户体验和感知，为持续的系统增强奠定了基础。
矢量数据库
支持语义搜索的向量数据库是 RAG 的关键检索组件。然而，正确选择此组件对于避免潜在问题至关重要。在选择过程中需要考虑几个向量数据库因素。让我们来了解一下其中的一些。
召回率与延迟
在矢量数据库中，优化召回率（相关结果的百分比）与延迟（返回结果的时间）是一种权衡。Flat、HNSW（分层可导航小世界）、PQ（产品量化）、ANNOY 和 DiskANN 等不同指标在速度和召回率之间做出了不同的权衡。对您的数据和查询进行基准研究，以做出明智的决策。
成本
采用托管解决方案的云原生数据库通常根据数据存储和查询量计费。此模式适用于拥有大量数据的组织，可避免基础设施成本。主要考虑因素包括评估数据集增长、团队能力、数据敏感性以及了解托管云解决方案的成本影响。
另一方面，自托管使组织能够更好地控制其基础架构，并可能降低成本。但是，它伴随着管理和维护基础架构的责任，包括考虑可扩展性、安全性和更新。
插入速度与查询速度
平衡插入速度和查询速度至关重要。寻找能够处理具有高插入速度要求的流式用例的供应商。但是，对于大多数组织来说，优先考虑查询速度更为重要。评估峰值负载下的向量插入速度查询延迟，以做出明智的决策。
内存与磁盘索引存储
在内存和磁盘存储之间进行选择涉及速度和成本的权衡。虽然内存存储提供了高速，但有些用例需要存储比内存更大的向量。内存映射文件等技术允许扩展向量存储而不会影响搜索速度。DiskANN 中的 Vamana 等新索引可实现高效的内存外索引。
全文搜索与向量混合搜索
来源：https://www.pinecone.io/learn/hybrid-search-intro/
单独的向量搜索可能不是企业级应用程序的最佳选择。另一方面，混合搜索集成了密集和稀疏方法，需要额外的努力。实现密集向量索引、稀疏倒排索引和重新排序步骤是典型的做法。密集和稀疏元素之间的平衡可以通过Pinecone、Weaviate和Elasticsearch中称为 alpha 的参数进行调整。
过滤
实际的搜索查询通常涉及对元数据属性的过滤。预过滤搜索虽然看似自然，但可能会导致相关结果丢失。如果过滤后的属性只是数据集的一小部分，则后过滤搜索可能会出现问题。自定义过滤搜索（如Weaviate）将预过滤与使用倒排索引分片和 HNSW 索引分片的有效语义搜索相结合。
改进检索的技术
最近的研究表明，LLM 很容易被不相关的上下文分散注意力，并且由于 LLM 的注意力模式，拥有大量上下文（topK 检索文档）可能会导致遗漏某些上下文。因此，使用相关且多样化的文档来改进检索至关重要。让我们来看看一些经过验证的改进检索的技术。
假设文档嵌入（HyDE）
我们可以使用HyDE技术来解决检索性能不佳的问题，尤其是在处理简短或不匹配的查询时，这些查询会使查找信息变得困难。HyDE 采用一种独特的方法，使用由 GPT 等模型创建的假设文档。这些假设文档捕捉了重要的模式，但可能包含虚构或不正确的细节。然后，智能文本编码器将此假设文档转换为向量嵌入。与查询嵌入相比，这种嵌入有助于在集合中找到类似的真实文档。
实验表明，HyDE 比其他先进方法效果更好，使其成为提升 RAG 系统性能的有用工具。
查询路由
查询路由在处理多个索引时非常有用，可将查询定向到最相关的索引以实现高效检索。此方法可确保每个查询都定向到适当的索引，从而简化搜索过程，从而优化信息检索的准确性和速度。
在企业搜索中，数据来自各种来源（例如技术文档、产品文档、任务和代码存储库），查询路由成为一种强大的工具。例如，如果用户正在搜索与特定产品功能相关的信息，则可以智能地将查询路由到包含产品文档的索引，从而提高搜索结果的准确性。
重排器
当编码器的检索结果无法提供最佳质量时，可以使用重新排序器来提高文档排名。在跨编码器设置中使用开源编码器专用转换器（如BGE-large）已成为一种常见做法。最近的解码器专用方法（如RankVicuna、RankGPT和RankZephyr）进一步提高了重新排序器的性能。
引入重排序器有好处，可以减少响应中的LLM 幻觉并提高系统的域外泛化能力。但是，它也有缺点。复杂的重排序器可能会因计算开销而增加延迟，从而影响实时应用程序。此外，部署高级重排序器可能会占用大量资源，需要仔细考虑性能提升和资源利用率之间的平衡。
最大边际相关性（MMR）
MMR 是一种旨在增强响应查询时检索到的项目多样性、避免冗余的方法。MMR 并非只专注于检索最相关的项目，而是在相关性和多样性之间取得平衡。这就像在聚会上向人们介绍朋友。最初，它会根据朋友的喜好确定最匹配的人。然后，它会寻找略有不同的人。这个过程一直持续到达到所需的介绍次数。MMR 确保呈现一组更加多样化和相关的项目，从而最大限度地减少冗余。
原始 MMR
自动切割
Weaviate的自动剪切功能旨在通过检测得分接近的对象组来限制返回的搜索结果数量。它的工作原理是分析搜索结果的得分并识别这些值的显著跳跃，这可能表明从高度相关的结果过渡到不太相关的结果。
例如，考虑返回具有以下距离值的对象的搜索：
[0.1899、0.1901、0.191、0.21、0.215、0.23]。
Autocut 返回以下内容：
- 自动切割：1：[0.1899，0.1901，0.191]
- 自动切割：2：[0.1899, 0.1901, 0.191, 0.21, 0.215]
- 自动切割：3：[0.1899, 0.1901, 0.191, 0.21, 0.215, 0.23]
递归检索
来源：https://youtu.be/TRjq7t2Ms5I?si= D0z5sHKW4SMqMgSG&t=742
递归检索，又称从小到大的检索技术，嵌入较小的块进行检索，同时返回较大的父上下文以供语言模型合成。较小的文本块有助于更准确的检索，而较大的块则为语言模型提供更丰富的上下文信息。这种顺序过程通过最初关注较小、信息更密集的单元来优化检索的准确性，然后有效地将其链接到更广泛的上下文父块进行合成。
句子窗口检索
检索过程会获取单个句子并返回围绕该特定句子的文本窗口。句子窗口检索可确保检索到的信息不仅准确而且与上下文相关，从而提供有关主要句子的全面信息。
发电机
既然我们已经讨论了所有检索组件，现在让我们来谈谈生成器。它需要仔细考虑和权衡，主要是在自托管推理部署和私有 API 服务之间。这本身就是一个很大的话题，我将简要介绍一下，以免让您不知所措。
API 注意事项
在评估 LLM 的 API 服务器时，确定确保无缝集成和强大性能的功能的优先级至关重要。精心设计的 API 应充当流行 LLM 的简单启动器，同时还要解决生产就绪性、安全性和幻觉检测等关键问题。值得注意的是，HuggingFace 的 TGI 服务器体现了体现这些原则的一套全面功能。让我们了解 LLM 服务器中所需的一些最受欢迎的功能。
表现
高效的 API 必须优先考虑性能，以满足不同的用户需求。张量并行性是一项突出的功能，它有助于在多个 GPU 上更快地进行推理，从而提高整体处理速度。此外，连续批处理传入请求可确保增加总吞吐量，从而有助于提高系统的响应速度和可扩展性。量化的加入，特别是使用 bitsandbytes 和 GPT-Q，进一步优化了 API，以提高各种用例的效率。利用优化的 Transformer 代码的能力可确保在最流行的架构上进行无缝推理。
生成质量增强剂
为了提高生成质量，API 应包含可以转换输出的功能。logits 处理器包括温度缩放、top-p、top-k 和重复惩罚，允许用户根据自己的偏好自定义输出。此外，停止序列可以控制生成，使用户能够管理和优化内容生成过程。对数概率对于幻觉检测至关重要，它充当了额外的细化层，确保生成的输出与预期上下文一致并避免误导性信息。
安全
API 的安全性至关重要，尤其是在处理 LLM 和企业用例时。Safetensor 权重加载是一项基本功能，它有助于通过防止未经授权篡改模型参数来安全部署模型。此外，水印的加入增加了一层额外的安全性，使 LLM 的使用具有可追溯性和可问责性。
用户体验
在用户体验领域，令牌流成为无缝交互的关键功能。利用服务器发送事件 (SSE) 进行令牌流可增强 API 的实时响应能力，为用户提供更流畅、更具交互性的体验。这可确保用户可以逐步接收生成的内容，从而提高 LLM 的整体参与度和可用性。
自托管推理
自托管推理涉及在 AWS、GCP 或 Azure 等云服务提供商提供的服务器上部署 LLM。服务器（例如 TGI、Ray 或 FastAPI）的选择是一项关键决策，直接影响系统的性能和成本。考虑因素包括计算效率、部署的简易性以及与所选 LLM 的兼容性。
衡量 LLM 推理性能至关重要，而像Anyscale 的 LLMPerf Leaderboard这样的排行榜则非常有价值。它根据关键性能指标对推理提供商进行排名，包括首次标记时间 (TTFT)、标记间延迟 (ITL) 和成功率。负载测试和正确性测试对于评估托管模型的不同特征至关重要。
在新方法中，Predibase 的 LoRAX引入了一种高效服务微调 LLM 的创新方法。它解决了使用共享 GPU 资源服务多个微调模型的挑战。
私有API服务
OpenAI、Fireworks、Anyscale、Replicate、Mistral、Perplexity 和 Together 等公司提供的 LLM API 服务提供了替代部署方法。了解它们的功能、定价模型和LLM 性能指标至关重要。例如，OpenAI 的基于代币的定价（区分输入和输出代币）会显著影响使用 API 的总体成本。在比较私有 API 服务与自托管 LLM 的成本时，您必须考虑 GPU 成本、利用率和可扩展性问题等因素。对于某些人来说，速率限制可能是一个限制因素（哈哈！）。
改善 RAG 的提示技术
有几种提示技术可以提高 RAG 的输出。在我们的“掌握 RAG”系列第 2 部分中，我们深入探讨了最有效的 5 种提示技术。其中许多新技术的表现都超过了 CoT（思维链）。您还可以将它们结合起来以最大限度地减少幻觉。
LLM 针对 RAG 的提示技巧
输出护栏
输出护栏的功能与输入护栏类似，但专门用于检测生成的输出中的问题。作为RAG 评估的一部分，它专注于识别幻觉、竞争对手提及和潜在的品牌损害。目标是防止生成可能与品牌价值观不符的不准确或道德上有问题的信息。通过积极监控和分析输出，此护栏可确保生成的内容在事实上保持准确、符合道德规范并符合品牌的指导方针。
以下是一个可能损害企业品牌但会被适当的输出护栏阻止的响应示例：
有毒输出示例
用户反馈
一旦生成并提供了输出，从用户那里获得正面或负面的反馈都是很有帮助的。用户反馈对于改进 RAG 系统的飞轮非常有帮助，这是一个持续的过程，而不是一次性的努力。这不仅需要定期执行重新索引和重新运行实验等自动化任务，还需要采用系统方法来整合用户见解，从而实现实质性的系统增强。
系统改进最有效的杠杆在于主动修复底层数据中的问题。RAG 系统应包含一个迭代工作流程，用于处理用户反馈并推动持续改进。
用户互动及反馈收集
用户与 RAG 应用程序交互，并利用 👍/ 👎 或星级评分等功能提供反馈。这套多样化的反馈机制是用户体验和对系统性能的看法的宝贵资源库。
问题识别和诊断检查
收集反馈后，团队可以进行全面分析，以确定可能表现不佳的查询。这涉及检查检索到的资源并仔细检查，以辨别表现不佳是源于检索、生成还是底层数据源。
数据改进策略
一旦发现问题，尤其是那些根源于数据本身的问题，团队就可以制定战略计划来提高数据质量。这可能涉及纠正不完整的信息或重组组织混乱的内容。
评估和测试协议
实施数据改进后，系统必须对之前表现不佳的查询进行严格评估。然后，可以从这些评估中获得的见解有条不紊地集成到测试套件中，确保根据实际交互进行持续审查和改进。
通过积极让用户参与这个全面的反馈循环，RAG 系统不仅解决了通过自动化流程发现的问题，而且还利用了丰富的用户体验。
可观察性
构建 RAG 系统并不会随着系统投入生产而结束。即使拥有强大的护栏和用于微调的高质量数据，模型在投入生产后仍需要持续监控。除了延迟和成本等标准指标外，生成式 AI 应用程序还需要特定的LLM 可观察性来检测和纠正幻觉、域外查询和链故障等问题。现在让我们来看看 LLM 可观察性的支柱。
及时分析和优化
识别与提示相关的问题，并使用实时生产数据进行迭代，以使用强大的评估机制来识别和解决幻觉等问题。
LLM 应用程序中的可追溯性
从常见框架（如 Langchain 和 LlamaIndex）捕获 LLM 跟踪以调试提示和步骤。
信息检索增强
排除故障并评估 RAG 参数以优化对 LLM 性能至关重要的检索过程。
警报
如果系统行为与预期不符，例如错误增加、高延迟和幻觉，则会收到警报。
首先，实时监控对于观察生产环境中应用程序的性能、行为和整体运行状况至关重要。密切关注 SLA 合规性并设置警报以及时解决任何偏差。通过分析使用模式和资源消耗，有效跟踪与运行 LLM 应用程序相关的成本，以帮助您优化成本。
Galileo 的LLM Studio提供专门构建的 LLM 可观察性，可在用户投诉之前主动发出警报并立即采取纠正措施。Galileo 的护栏指标旨在监控模型的质量和安全性，涵盖基础性、不确定性、事实性、语气、毒性、PII 等方面。这些指标以前在评估和实验期间使用，现在可以无缝集成到监控阶段。
此外，您还可以灵活地注册自定义指标，以根据您的特定需求定制监控流程。利用监控数据生成的见解和警报，随时了解潜在问题、异常或需要注意的改进领域。这种全面的方法可确保您的 LLM 应用程序在实际场景中高效、安全地运行。
缓存
对于规模化运营的公司来说，成本可能成为一大障碍。在这种情况下，缓存是一种很好的省钱方法。缓存涉及将提示及其相应的响应存储在数据库中，以便随后检索它们以供使用。这种战略性缓存机制使 LLM 应用程序能够加快和节省响应，具有三个明显的优势。
增强生产推理
缓存有助于在生产过程中实现更快、更经济的推理。某些查询可以通过利用缓存响应实现接近零延迟，从而简化用户体验。
加速开发周期
在开发阶段，缓存被证明是一种福音，因为它消除了重复调用相同提示的 API 的需要。这可以缩短开发周期，并使其更经济。
数据存储
存储所有提示的综合数据库简化了 LLM 的微调过程。利用存储的提示-响应对简化了基于累积数据的模型优化。
如果您认真考虑，可以利用GPTCache来实现精确匹配和相似匹配的缓存。它提供了缓存命中率、延迟和召回率等有价值的指标，这些指标可以洞悉缓存的性能，从而实现持续改进以确保最佳效率。
多租户
SaaS 软件通常有多个租户，以平衡简单性和隐私性。对于 RAG 系统中的多租户，目标是构建一个不仅能有效查找信息而且尊重每个用户数据限制的系统。简而言之，每个用户与系统的交互都是独立的，确保系统只查看和使用针对该用户的信息。
构建多租户的简单方法之一是使用元数据。当我们将文档添加到系统时，我们会在元数据中包含特定用户的详细信息。这样，每个文档都与特定用户相关联。当有人搜索时，系统会使用此元数据进行筛选，仅显示与该用户相关的文档。然后，它会进行智能搜索，以找到对该用户最重要的信息。这种方法可以防止私人信息在不同用户之间混淆，从而确保每个人的数据安全且私密。
了解如何使用 Llamaindex 实现多租户。
结论
显然，构建一个强大且可扩展的企业 RAG 系统需要精心协调相互关联的组件。从用户身份验证到输入护栏、查询重写、编码、文档提取以及矢量数据库和生成器等检索组件，每一步都对系统性能的塑造起着至关重要的作用。
在不断发展的 RAG 系统格局中，我们希望本实用指南能够为开发人员和领导者提供可行的见解！
Galileo GenAI Studio 是面向构建 LLM 驱动应用程序的团队的领先平台，可进行快速评估、实验和可观察性。它由一套指标提供支持，用于识别和缓解幻觉。加入 1000 多名构建 LLM 驱动应用程序的开发人员，并获得早期访问权限！
转载于:https://www.rungalileo.io/blog/mastering-rag-how-to-architect-an-enterprise-rag-system
本文由 小马哥 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为:
2024/09/09 10:43
