构建企业级 RAG 系统的高级指南 [译]

构建企业级 RAG 系统的高级指南 [译]

原文：Mastering RAG: How To Architect An Enterprise RAG System

欢迎再次加入我们的“RAG 系统高级掌握”系列！我们将深入了解构建企业级 RAG (Retrieval-Augmented Generation) 系统的复杂世界。

网络上虽然不乏关于简易 RAG 系统的文章，但要构建一个坚固的企业级解决方案，过程却充满未知。许多开发者甚至不知道构建 RAG 系统时最关键的决策是什么…

这篇博客不只是理论探讨，更是一个实践指南，旨在助您一臂之力！我们将从保障安全的关键措施到查询重写如何影响用户体验，提供实用的洞见和实际案例。无论您是资深开发者还是技术领袖，都请准备好深入探索先进的企业级 RAG 系统的世界！

在深入 RAG 架构之前，我想与您分享一项最新研究，探讨构建 RAG 系统时常见的失败因素。研究人员分析了三个不同领域的案例，发现了七个常见的 RAG 系统失败点。

构建 RAG 系统的挑战

案例研究

认知审查员 (Cognitive Reviewer)

认知审查员是一个旨在帮助研究人员分析科学文献的 RAG 系统。研究人员定义研究问题或目标，并上传相关研究论文集。系统随后根据设定的目标对所有文档进行评估，供研究人员进行手动审查。此外，研究人员还可以针对整套文档集提出具体问题。

AI 导师

AI 导师是一个特殊的 RAG 系统，它允许学生就学习单元提出问题，并从相关学习材料中得到答案。学生们可以通过查询一个来源列表来核实这些答案。这个系统被集成到 Deakin 大学的学习管理系统中，对各种格式的内容进行索引，包括 PDF 文件、视频和文本文档。系统在处理这些内容之前，会先利用 Whisper 这个先进的深度学习模型对视频内容进行文字转换。RAG 系统还包含了一个查询重写功能，以泛化问题，并且聊天界面能够使用以往的对话记录，为每个问题提供上下文。

生物医学问答案例

在生物医学问答的案例研究中，研究者们使用包含问题、文档链接和答案的 BioASQ 数据集创建了一个 RAG 系统。这个数据集是由生物医学专家编制的，包括了特定领域的问答对。这些问题的答案形式多样，包括是非题、文本摘要、具体事实或是列表形式。

RAG 系统的七大挑战点

通过这些案例研究，研究者们发现了在构建 RAG 系统时常遇到的七大挑战。

缺失内容 (FP1)

有时会出现一种情况，即用现有文档无法回答提出的问题。在最理想的情况下，RAG 系统会诚实地回复“对不起，我不知道”。但对于那些没有明确答案的问题，系统可能误导性地给出一个答案。

未覆盖排名靠前的文档 (FP2)

有时问题的答案虽然存在于某个文档中，但该文档的排名不够高，因此没有被包含在用户看到的结果中。实际上，虽然所有文档理论上都会被排名并用于后续步骤，但实践中通常只有排名前 K 的文档被选出来展示给用户，而这个 K 值是基于性能考虑而选定的。

答案被遗漏 - 综合策略的局限 (FP3)

虽然包含答案的文档被从数据库中检索出来，但它们没有被有效地整合到用于生成回答的上下文中。这种情况通常发生在检索到大量文档时，由于需要进行综合处理，可能导致关键答案被忽略。

信息未被提取 (FP4)

即使答案存在于上下文中，模型有时也未能提取出正确的信息。这种情况通常发生在上下文中存在过多干扰信息或信息相互矛盾时。

回答格式不符 (FP5)

当问题要求以特定格式提取信息，比如表格或列表时，模型有时会忽视这一要求，导致回答格式与问题要求不符。

精准性不足（FP6）

回答虽然涵盖了问题的答案，但要么缺乏必要的精准度，要么过于具体，没有切中用户的实际需求。这通常出现在 RAG 系统的设计者对某个问题有既定的答案预期，例如教师寻找教育类内容时。在这类情况下，应该提供符合教育目的的具体内容作为答案。当用户不确定如何明确提问，或问题表述过于泛泛时，也容易导致答案的精准性不足。

答案不全面（FP7）

有时候，即使答案本身没有错误，也可能因为缺少某些信息而显得不够全面。这些信息虽然在上下文中已有提及，且理论上可以提取出来，但在回答中并未出现。例如，针对“文档 A、B 和 C 中包含哪些关键内容？”这样的问题，更合理的做法是分别对每个文档提出单独的问题。

下表概述了他们在解决每项问题时所吸取的经验教训。在我们构建企业级 RAG 系统时，将会充分考虑这些宝贵的经验。

构建企业级 RAG 系统的方法

在明确了设计 RAG 系统时常见的问题后，我们来探讨系统设计的需求、各组件的作用，以及构建这些组件时的最佳实践。上方展示的 RAG 系统架构图，为我们提供了每个组件在哪里以及如何被使用的背景信息。

用户认证

一切从这里开始——我们系统中的首个环节！在用户与聊天机器人开始互动前，我们出于多种原因需要对用户进行认证。在企业系统中，认证不仅有助于保障安全，还能实现个性化服务。

访问控制

通过认证，我们确保只有授权的用户能够访问系统。这一措施帮助我们控制哪些用户能与系统互动，以及他们被允许执行哪些操作。

数据安全

保护敏感数据的安全至关重要。用户认证机制防止未授权人员接触到机密信息，从而预防数据泄露和非法数据操作。

用户隐私

认证过程还有助于维护用户隐私，确保只有用户本人才能够访问到自己的个人信息和账户详情。这对于建立用户对系统的信任是至关重要的。

法律遵从性

遵守法律法规是必不可少的。许多地区和行业都有规定，要求企业实施有效的用户认证措施来保护用户的数据和隐私。遵循这些规定，有助于企业避免法律纠纷和潜在的处罚。

责任追踪

认证机制确保了系统内的每一项操作都可以追溯到特定用户，这对于审计和监控用户活动非常重要。这样不仅有助于识别安全事件，还能及时发现和处理任何可疑行为。

个性化与定制体验

通过身份验证，系统能够识别每一个用户，从而提供个性化的用户体验，如定制内容、偏好和设置。

服务如 AWS Cognito 和 Firebase Authentication 能够帮助您轻松地在移动和网页应用中加入用户注册和登录功能。

输入安全防护

确保用户输入不会含有可能造成伤害或泄露私人信息是非常关键的。近期研究显示，攻破大语言模型是可能的。在这种情况下，输入安全防护的作用就显得尤为重要。我们来探讨需要进行安全防护的几种情况。

信息匿名处理

输入安全防护能够对个人身份信息（如姓名、地址或联系方式）进行匿名处理或删除，以保护用户隐私，避免敏感信息的恶意泄露。

禁止特定字符串

防止特定字符串或模式的使用，如那些可能被用于 SQL 注入、跨站脚本攻击（XSS）等，有助于预防安全漏洞或不期望的行为。

限制敏感话题

为防止涉及不恰当、冒犯性或违反社区准则的话题，重要的是过滤掉包含仇恨言论、歧视或露骨内容的讨论和输入。

阻止代码注入

阻止可执行代码的注入至关重要，以避免系统安全受损或发生代码注入攻击。

语言限制

确保文本输入符合预定的语言或文字，避免误解或处理错误。

防范提示注入

防止注入误导性或有害的提示，这可能误导系统或以非预期方式影响大语言模型的行为。

输入限制

对用户输入实施最大字符数限制，帮助防止资源耗尽和拒绝服务攻击（DoS）。

过滤有害内容

实施过滤器以识别和屏蔽含有有害或辱骂性语言的输入。

为保障您的 RAG 系统免受这些风险，您可以使用 Meta 的 Llama Guard。您可以选择自行部署或使用类似 Sagemaker 这样的托管服务。但请注意，它在检测有害内容方面可能并非完美无瑕。

查询优化器

当查询内容满足基本要求后，我们将其送至查询优化器。有时，用户的查询可能模糊不清，或者需要更多上下文信息才能更好地理解其真正意图。查询优化正是为了解决这个问题。它的作用在于改进用户查询，使其更加清晰、精确和相关。下面我们将介绍一些最常用的优化技术。

结合历史记录进行重写

这种方法利用用户之前的查询记录，以此来理解对话的上下文，并改善后续的查询效果。以信用卡咨询为例：

查询历史：

“你有多少张信用卡？”

“白金和黄金信用卡有年费吗？”

“比较两者的特点。”

我们需要根据用户的查询历史来追踪上下文的变化，识别用户意图及查询之间的联系，并生成与之相匹配的改进查询。

改写后的查询：“比较白金和黄金信用卡的特点。”

分解成子查询

由于检索问题，回答复杂的查询可能比较困难。为了简化这一任务，我们会将查询分解为更具体的子查询。这有助于找到生成答案所需的正确上下文。LlamaIndex 把这个过程称为子问题查询引擎。

例如，针对“比较白金和黄金信用卡的特点”这一查询，系统会为每种卡生成专注于单独一个实体的子查询。

改写后的子查询：

1. “白金信用卡有哪些特点？”
2. “黄金信用卡有哪些特点？”

生成类似查询

为了提高检索正确信息的可能性，我们会根据用户输入生成类似的查询。这是为了解决检索在语义或词汇匹配方面可能遇到的限制。

如果用户询问信用卡的特点，系统会生成相关的查询。我们会利用同义词、相关术语或专业知识来创造与用户意图相符的查询。

生成的类似查询：

“我想了解白金信用卡” -> “介绍一下白金信用卡的好处。”

编码器

在我们得到原始和改写后的查询后，我们将它们转化为向量（一系列数字），以便于进行检索。选择合适的编码器可能是构建你的 RAG 系统中最关键的一步。接下来我们将探讨选择文本编码器时需要考虑的因素及其重要性。

利用 MTEB 基准进行评估

要全面评估编码器的能力，Massive Text Embedding Benchmark（MTEB）是一个理想的选择。这个基准测试允许我们根据向量的维度、检索性能的平均水平以及模型的大小来精选编码器。尽管 MTEB 提供了有益的洞见，但我们需要保持一定的谨慎态度，因为没有哪个评估标准能够万能适用，而且模型训练数据的详细信息可能未被完全披露。

MTEB 不仅揭示了 OpenAI、Cohere 和 Voyager 等流行嵌入技术的性能，也显示了一些开源模型在性能上的接近程度。但请注意，这些结果仅提供一个概览，并不能精确反映这些嵌入技术在特定领域的实际表现。因此，在做出最终决定前，对自己的数据集进行深入评估至关重要，这突显了定制评估方法的重要性。

定制评估方法

特别是在处理敏感信息时，编码器可能不总是能提供最优表现。在这些情况下，采用定制的评估方法变得非常重要。这里有三种定制评估的方法。

基于标注的评估

创建一个专门的数据集，并进行标注以获得准确标签。标注完成后，使用诸如平均倒数排名（MRR）和归一化折扣累积增益（NDCG）等指标来量化评估不同编码器的性能。

基于模型的评估

采用与标注方法相似的数据生成过程，但将大语言模型或交叉编码器作为评估工具。这样可以在所有编码器中建立相对等级。然后，对排名前三的编码器进行人工评估，以获得精确的性能数据。

基于聚类的评估

使用多种聚类方法，并在不同的轮廓得分下分析数据聚类的覆盖率，以判断聚类内的向量相似度。试验不同算法，如 HDBSCAN，并调整参数以达到最佳性能。基于聚类的评估能够提供关于数据点分布和分组的重要见解，帮助选择与特定指标相符的编码器。

选择文本编码器的考虑因素

在选择编码器时，你将面临选择私有编码器还是公共编码器的抉择。虽然私有编码器因其易用性而具有吸引力，但在这两种选择之间需要权衡其特定优缺点。这个决策至关重要，它直接影响到你的系统的性能和响应速度。

查询成本

为了保证语义搜索带来流畅的用户体验，必须依赖于嵌入 API 服务的高效运行。OpenAI 及其他类似服务提供商提供的可靠 API 免除了你管理托管服务的烦恼。但是，选择一个开源模型则需要根据模型的大小和响应时间需求进行一定的工程调整。对于较小的模型（参数最多 110M），可以通过 CPU 实例来托管；而对于更大的模型，则可能需要通过 GPU 来提供服务，以满足对响应时间的要求。

索引成本

构建语义搜索系统时，需要对文档进行索引，这一过程伴随着相当的成本。由于索引和查询过程使用的是同一编码器，因此索引的成本与你选择的编码器服务直接相关。为了便于服务重启或向另一个向量数据库重新索引，建议单独存储嵌入向量。如果忽略这一步骤，将需要重新计算相同的嵌入向量。

存储成本

对于需要索引数百万向量的应用来说，向量数据库的存储成本非常关键。存储成本与向量的维度成线性关系，而 OpenAI 的嵌入向量在 1526 维度上的存储成本最高。为了估算存储成本，你需要计算每份文档中平均的单元（短语或句子）数量，并据此推算。

语言支持

要支持非英语语言，你可以选择使用多语言编码器，或者结合使用翻译系统和英语编码器。

搜索延迟

语义搜索的响应时间随着嵌入向量的维度线性增加。因此，选择低维度的嵌入向量是为了减少延迟的更佳选择。

隐私

在金融和医疗等敏感领域，严格的数据隐私要求可能使得使用 OpenAI 这类服务变得不太适合。

文档摄入

文档摄入系统负责处理和保存数据。在索引过程中，每份文档都会被分割成更小的片段，这些片段随后被转换成嵌入向量。接着，原始片段和它们的嵌入向量会一起被存储到数据库中。下面我们来详细了解一下文档摄入系统的各个组成部分。

文档解析器

文档解析器在从各类文档格式中提取结构化信息方面发挥着核心作用，尤其擅长处理不同的格式。它不仅能解析包括图像和表格在内的 PDF 文件。

文档格式

文档解析器需能熟练处理多种文档格式，如 PDF、Word、Excel 等，以适应不同的文档处理需求。这包括识别和处理嵌入式内容，例如超链接、多媒体元素或注释，以全面展示文档内容。

表格识别

在文档中识别和提取表格数据对于保持信息结构尤为重要，这在报告或研究论文中尤其如此。提取表格相关的元数据，如表头、行列信息，有助于更好地理解文档的组织结构。此类任务中，模型如 Table Transformer 可能非常有用。

图像识别

在文档中的图像上应用 OCR 技术，以识别和提取文本，便于索引和后续检索。

元数据提取

元数据是指文档的附加信息，不包含在主要内容中。它涵盖了作者、创建日期、文档类型、关键词等细节。元数据提供重要的背景信息，有助于组织文档，并通过考虑元数据特征来提高搜索结果的相关性。可以通过 NLP/OCR 流水线提取元数据，并将其作为特殊字段与文档一起索引。

分块器

长文本的分词（拆分）方式将直接影响嵌入的质量和搜索系统的性能。如果分块过小，可能无法回答某些问题；如果分块过大，则可能包含过多无关信息。利用 summarisation 技术可以减少噪声、文本大小、编码和存储成本。分块是一个重要但经常被忽视的环节，它可能需要类似于特征工程的专业知识。比如，对于 Python 代码库，可能会采用像 def/class 这样的前缀进行分块。

深入了解分块的更多细节，可以观看这个视频。

索引器

索引器的任务是创建文档的索引，这是一种结构化的数据结构，它极大地促进了高效的搜索和检索操作。快速准确的索引对文档检索至关重要。索引器将文档中的块或标记映射到文档集合中的相应位置，执行创建索引、添加、更新或删除文档等关键任务。

作为复合型检索生成（RAG）系统的核心组件，索引器面临着各种挑战和问题，这些挑战和问题会影响系统的整体效率和性能。

可扩展性问题

随着文档数量的增长，如何保持索引的效率和速度变得越来越有挑战性。系统在处理越来越多的文档时可能会遇到困难，这可能导致索引和检索速度变慢。

实时索引更新

要实时更新索引是一项挑战，尤其是在文档经常变动的系统中。我们需要确保实时 API 和索引机制能够顺畅运行，同时不影响系统的整体性能。

一致性和原子性

在文档同时被更新或修改的情况下，保持索引的一致性和原子性是一项复杂的任务。我们必须精心设计和实施，以确保即使面对多重变化，索引更新也能保持数据的完整性。

优化存储空间

处理大量文档时，索引可能需要大量的存储空间。如何在确保索引既快速又方便访问的同时，还要节约存储空间，这是一个持续的挑战，特别是在存储成本成为考虑因素时。

安全性和访问控制

实施合适的安全措施和访问控制来防止未经授权的索引更改非常重要。我们要确保只有经过授权的用户或程序才能进行增删改查操作，以保护文档库的完整性。

监控和维护

定期监控索引器的健康状况和性能是必不可少的。我们需要通过强大的监控和维护程序来及时发现各种问题，如索引失败、资源瓶颈或过时的索引，以确保系统能够长期稳定运行。

这些是软件工程中一些棘手但众所周知的挑战，我们可以通过遵循优秀的软件设计实践来应对这些挑战。

数据存储

考虑到我们需要处理多种类型的数据，为每种数据设置专门的存储空间变得至关重要。了解每种存储方式的特点及其特定应用场景是关键。

嵌入式

数据库类型：SQL/NoSQL

将文档嵌入式独立存储有助于快速地重新索引，而无需为整个文档库重新计算嵌入式。此外，嵌入式存储还可以作为重要信息的备份，以防系统故障或更新时数据丢失。

文档

数据库类型：NoSQL

原始格式的文档存储对于持久化至关重要。这种原始格式是后续多种处理阶段，比如索引、解析和检索的基础。保留原始文档的完整性，为系统未来的升级提供了灵活性，使其可以根据需要重新处理。

聊天历史

数据库类型：NoSQL

存储聊天历史对于增强 RAG 系统的对话功能至关重要。它让系统能够回溯用户以往的查询、反馈和偏好，从而根据用户的独特情境调整和定制未来的互动。这些历史数据对于通过研究来提升机器学习系统的性能来说，是极其宝贵的资源。

用户反馈

数据库类型：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 索引分片的有效语义搜索。

提升检索效果的技巧

近期的研究显示，大语言模型很容易被无关的上下文所干扰，并且当有大量的上下文（即 topK 检索出的文档）时，可能会因为大语言模型的注意力模式而忽略掉一些重要上下文。因此，选取相关性高且内容多样的文档来提高检索质量是至关重要的。下面我们来探讨一些已被证实有效的提升检索效果的技巧。

假想文档嵌入技术（HyDE）

HyDE 技术能有效解决搜索效果不佳的问题，尤其是在处理简短或不匹配的查询时更为明显。HyDE 的独特之处在于它利用像 GPT 这样的模型生成的假想文档。这些文档虽然可能包含一些虚构或错误的信息，但能够捕捉到关键的模式。随后，一个智能的文本编码器将这些假想文档转换成向量形式的嵌入，这有助于在文档库中更准确地找到与查询内容相似的实际文档。

实验显示，HyDE 在改善检索效果方面比其他先进技术更为出色，为提升 RAG 系统的性能提供了有效工具。

查询引导

在处理多个索引时，查询引导技术显得尤为重要。它能将查询有效地定向到最相关的索引，从而实现更高效的信息检索。这种方法确保了每个查询都被精确地指向合适的索引，提高了检索的准确性和速度。

在企业搜索场景中，查询引导尤其重要。例如，当需要从技术文档、产品说明、任务和代码库等不同来源索引的数据中检索信息时，如果用户正在查找与某一产品特性相关的信息，系统可以智能地将查询引导至包含该产品文档的索引，从而提高搜索结果的精准度。

重排序器

当初始的编码器检索结果不够理想时，可以使用重排序器来提升文档的排名效果。目前，使用像 BGE-large 这样的开源编码器转换器在交叉编码器配置中已成为常规做法。近期的一些仅解码器方法，例如 RankVicuna、RankGPT 和 RankZephyr，进一步增强了重排序器的性能。

引入重排序器的好处包括减少了在生成式任务中常见的 LLM 幻觉现象，并提高了系统在处理非特定领域内容时的适应能力。然而，这种做法也有其缺点，如更复杂的重排序器可能会增加计算负担，影响实时应用的响应速度。此外，部署这些先进的重排序器可能会非常消耗资源，因此需要在性能提升和资源使用之间找到一个合理的平衡点。

最大边际相关性 (Maximal Marginal Relevance, MMR)

MMR 是一种用于提升搜索结果多样性并减少重复内容的方法。它不仅关注搜索结果的相关性，还致力于在相关性和多样性之间找到一个平衡点。可以把它比作在派对上为朋友寻找合适的交际对象：先根据朋友的喜好找到最匹配的人，然后再寻找一个稍微有些不同的人，如此反复，直至完成预定数量的介绍。MMR 确保最终呈现的内容既多样又相关，有效减少了重复信息。

原始的 MMR

原始的 MMR

自动筛选 (Autocut)

来自 Weaviate 的自动筛选功能，旨在通过识别分数相近的对象群组，从而控制搜索结果的数量。这个功能通过分析搜索结果的得分，并寻找分数之间的明显跳跃来工作，这种跳跃通常意味着从高相关性到低相关性结果的变化。

例如，假设一个搜索返回了以下的距离值：

[0.1899, 0.1901, 0.191, 0.21, 0.215, 0.23]。

那么，自动筛选的结果会是：

• 自动筛选：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

递归检索（Recursive retrieval），也就是从小到大的检索技术，是一种在检索时嵌入较小数据块，同时为语言模型的合成提供较大父级上下文的方法。这种方法通过使用较小的文本块实现更精确的检索，并且利用较大的数据块为语言模型提供更为丰富的上下文信息。在这个顺序过程中，首先聚焦于小而信息密集的单元来提高检索的准确性，然后将它们有效地与更宽广的上下文父级块连接，以便进行合成。

句子窗口检索

句子窗口检索（Sentence window retrieval）的过程是先锁定一个特定句子，然后返回该句子周围的一段文本。这种方法确保检索到的信息不仅准确无误，而且在上下文上也是相关的，为主要句子周围提供全面的信息。

生成器

讨论完所有检索组件之后，我们来看看生成器。在生成器的设计上需要细致考虑和在不同方面进行权衡，尤其是在自托管推理部署与私有 API 服务之间的选择。这是一个相当广泛的议题，在此我只简要说明，以免内容过于复杂。

API 考量

在评估大语言模型 (LLM) 的 API 服务器时，我们首先要考虑的是那些能够确保系统无缝集成和高效运行的特性。一个好的 API 应该能简便地启动流行的大语言模型，同时还需考虑到生产准备、安全保障和幻觉检测等关键因素。例如，HuggingFace 的 TGI 服务器就包括了这些要素的综合特性。下面我们来看看大语言模型服务器中一些重要的功能。

性能

高效的 API 需要优先考虑性能，以适应不同用户的需求。例如，使用多个 GPU 加速推理计算的“张量并行”功能，可以显著提高处理速度。另外，对进入请求的连续批处理也有助于提升系统的整体吞吐量，使系统更加快速响应和容易扩展。通过特定的量化技术，比如 bitsandbytes 和 GPT-Q，API 的效率得到了进一步优化，适用于多种场景。优化的 transformers 代码的使用也确保了在流行架构上的高效推理。

生成质量提升

为了提高内容生成的质量，API 应集成一些能够改善输出的功能。比如，logits 处理器可以通过温度缩放、top-p、top-k 和重复惩罚等方法，让用户根据自己的偏好定制输出结果。此外，设置结束序列可以让用户更好地控制内容生成，以精确调整输出内容。而对数概率则是检测幻觉的关键，它有助于确保生成内容的准确性，避免产生误导信息。

安全性

API 的安全性尤为重要，尤其是在处理大语言模型和企业级应用时。例如，Safetensors 的权重加载功能能防止模型参数被未授权篡改，保证了模型的安全部署。此外，加入水印功能可以提高使用大语言模型时的追踪性和责任性。

用户体验

在用户体验方面，令牌流式传输是一个关键特性，能够实现平滑的互动体验。使用服务器发送事件 (SSE) 进行令牌流式传输能够增强 API 的实时响应性，为用户提供更流畅、更互动的体验。这确保用户能够逐步接收到生成的内容，从而提升整体的参与感和易用性。

自助式推理部署

自助式推理部署是指在云服务商（比如 AWS、GCP 或 Azure）提供的服务器上部署大语言模型 (LLM)。选择何种服务器，如 TGI、Ray 或 FastAPI，是个关键决策，它直接关系到系统的性能和成本。需要考虑的因素包括计算效率、部署的简易性，以及与选用的大语言模型的兼容性。

衡量大语言模型推理性能非常关键。像 Anyscale’s LLMPerf 排行榜 这样的资源是极其宝贵的。它根据关键的性能指标，如首个 Token 到达时间 (TTFT)、Token 间延迟 (ITL) 和成功率，对推理服务提供者进行排名。为了评估不同托管模型的特点，进行负载测试和正确性测试是非常重要的。

在新的方法中，Predibase’s LoRAX 提出了一种高效服务多个微调过的大语言模型的创新方式，解决了利用共享 GPU 资源同时服务多个微调模型的难题。

私有 API 服务

OpenAI、Fireworks、Anyscale、Replicate、Mistral、Perplexity 和 Together 等公司提供的大语言模型 API 服务，展示了不同的部署选择。理解这些服务的功能、定价模式，以及大语言模型性能指标非常重要。例如，OpenAI 的基于 Token 的定价模式，区分了输入和输出 Token，这可能会显著影响使用 API 的总体成本。在比较私有 API 服务与自助部署大语言模型的成本时，要考虑 GPU 成本、使用率和扩展性等因素。对于一些用户来说，速率限制可能成为一个制约因素。

提升 RAG 输出的提示技巧

为了提升 RAG 输出，有多种提示技巧可用。在我们的掌握 RAG 系列第二部分中，我们深入研究了五种最有效的方法。许多新技巧的表现甚至超过了思维链 (CoT)。你还可以将这些技巧结合起来，以尽量减少幻觉现象。

针对 RAG 的大语言模型提示技巧

针对 RAG 的大语言模型提示技巧

输出监控机制

输出监控机制的作用与输入监控类似，但专门用来检测生成内容中的问题。它主要关注于识别内容生成过程中的虚假信息、提及竞争对手的情况，以及可能对品牌造成损害的内容，这是RAG 评估的重要环节。其目的是避免产生不准确或在伦理上有争议的信息，这些信息可能与品牌价值观相悖。通过对生成内容的持续监控和分析，这个机制确保内容在事实上准确无误，符合伦理标准，并与品牌指南保持一致。

以下是一个例子，显示了一个可能对企业品牌造成伤害的输出内容，但在合适的输出监控机制下会被拦截：

有害输出内容的例子

有害输出内容的例子

用户反馈的重要性

当输出内容生成并提供给用户后，收集用户的正面或负面反馈非常重要。用户的反馈对于持续改进 RAG 系统至关重要，因为这是一个不断进化的过程，而非一次性完成的任务。这不仅包括像重新索引和重复进行实验这样的自动化任务，也包括将用户的洞见系统性地融入，从而实现系统的实质性提升。

要想有效改进系统，最关键的是及时解决基础数据中出现的问题。RAG 系统应当包含一个循环迭代的工作流程，用于处理用户的反馈并推动持续的改进。

用户互动与反馈搜集

用户在使用 RAG 应用时，可以通过👍/ 👎按钮或星级评分等方式提供反馈。这些不同的反馈方式构成了一个关于用户体验和对系统性能评价的宝贵信息库。

问题识别与诊断检查

在收集到反馈之后，团队会进行全面的分析，识别出可能表现不佳的查询请求。这包括检查检索到的资源，并仔细分析，以确定性能不佳是由于检索、内容生成还是基础数据源的问题。

数据改善策略

一旦发现问题，特别是那些源于数据本身的问题，团队将制定策略来提高数据质量。这可能包括修正不完整的信息或重新组织结构混乱的内容。

评估与测试流程

在实施了数据改进措施之后，系统需要对之前表现不佳的查询进行严格的评估。从这些评估中得到的洞见随后会被有序地整合到测试流程中，确保基于真实用户互动的持续监控和优化。

通过让用户积极参与到这个全面的反馈循环中，RAG 系统不仅能够解决通过自动化流程发现的问题，还能够深入挖掘和利用用户的丰富体验。

可观测性

构建 RAG（Retrieval-Augmented Generation）系统的过程不仅仅是将其投入生产环节就结束了。哪怕系统配置了强大的安全措施并使用高质量数据进行了微调，一旦运行起来，模型还是需要不断的监控。生成式 AI 应用除了需要关注常规指标，如响应时间和成本外，还必须具备特定的大语言模型可观测性，以便及时发现和解决模型生成的错误信息、偏离主题的查询请求和链路故障等问题。现在，让我们来了解一下构建大语言模型可观测性的关键要素。

提示分析和优化

通过实时监控生产数据，发现和解决与提示相关的问题，如模型产生的虚假信息等，利用有效的评估机制进行迭代优化。

大语言模型应用的可追溯性

利用 Langchain、LlamaIndex 等常见框架，捕获大语言模型的操作轨迹，以便更好地调试提示和步骤。

信息检索的改进

分析并调整 RAG 参数，优化信息检索过程，这对提升大语言模型的表现至关重要。

警报系统

当系统的行为出现异常，比如错误率升高、响应延迟或模型生成错误信息时，立即发出警报。

最重要的是，实时监控能够帮助您实时了解应用在生产环境中的表现、行为和整体状况。密切关注是否符合服务水平协议（SLA），并设置警报系统，以便及时应对任何偏差。通过分析使用模式和资源消耗，有效追踪运行大语言模型应用的成本，并进行成本优化。

Galileo 的大语言模型工作室提供了专门为大语言模型设计的可观测性工具，能够在用户反馈之前主动发出警报并及时采取纠正措施。Galileo 设定了一系列监控指标，以确保模型的质量和安全，涉及到实际应用情况、不确定性、事实性、语调、有害性、个人识别信息（PII）等方面。这些在模型评估和试验阶段使用的指标，现在可以无缝集成到监控阶段。

此外，您还可以自定义监控指标，以满足特定需求。利用监控数据产生的洞察和警报，及时了解可能出现的问题、异常或需改进的领域。这种全面的监控方法确保了您的大语言模型应用在现实世界中能够高效且安全地运行。

缓存策略

对于大规模运营的公司，成本是一个不容忽视的问题。缓存是一种节约成本的有效方式。缓存机制指的是将提示及其对应的响应存储在数据库中，以便之后重复使用。这种策略不仅可以提高大语言模型应用的响应速度，还能降低成本，具有三大优势。

增强生产效率

在生产环节中，缓存的使用大大提升了推理的速度和成本效率。借助缓存响应，某些查询几乎能够瞬间得到结果，这极大地优化了用户的体验。

开发周期加速

在开发阶段，缓存的应用显著降低了重复调用 API 的需求，特别是在处理相同的提示时。这不仅加快了开发的速度，也降低了成本。

数据存储与管理

建立一个全面的数据库，存储所有的提示信息，对大语言模型 (LLM) 的微调至关重要。这种存储的提示与响应配对，使得基于累积数据对模型进行优化变得更加高效。

如果你打算深入研究，可以尝试使用 GPTCache 来实施精确及相似匹配的缓存策略。它提供了缓存命中率、延迟和回调等关键指标，帮助你深入了解缓存的性能，并不断完善，以实现最优效率。

多租户系统构建

在 SaaS 软件中，通常需要处理多个租户，平衡简单性和隐私性。在 RAG 系统的多租户构建中，核心目标是打造一个既能高效查找信息，又能严格遵守用户数据隐私的系统。简而言之，系统确保每个用户的数据互不干扰，只处理和利用指定用户的信息。

构建多租户系统的一个有效方法是应用元数据。向系统中添加文档时，会附带具体用户信息的元数据。这样，每份文档都与特定用户绑定。用户进行搜索时，系统利用这些元数据进行筛选，只展示与该用户相关的文档，并智能地搜索对用户最重要的信息。这种做法有效避免了不同用户间的私密信息混淆，确保每位用户的数据安全和隐私。

可以在这里学习如何利用 Llamaindex 实现多租户系统。

结论

显然，构建一个坚固且可扩展的企业级 RAG 系统，需要精心整合多个互相关联的组件。从用户认证、输入限制、查询重构、编码、文档输入到检索组件，如向量数据库和生成器，每个环节都对系统的整体性能产生重要影响。

在不断演变的 RAG 系统领域，我们希望这份指南能够为开发者和决策者提供实用的洞察和指导！