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