【建议收藏】企业级 RAG 产品的搭建需要重点考虑哪些问题？

最新推荐文章于 2024-10-22 11:24:46 发布

程序员新亮

最新推荐文章于 2024-10-22 11:24:46 发布

阅读量542

点赞数

文章标签：人工智能

原文链接：https://mp.weixin.qq.com/s?__biz=MjM5NDM4MDIwNw==&mid=2448837596&idx=1&sn=53b8e8ac928ce3eb6c910f1b4d9dd42c&chksm=b32a804419cf384c36e034d483407c8e3740f7418e87e374bf2401cc2ccddf98b667df9aed04&scene=126&sessionid=0

版权

本文为译文，原文链接：https://www.rungalileo.io/blog/mastering-rag-how-to-architect-an-enterprise-rag-system

今天，我们将卷起袖子，深入研究构建企业级 RAG 系统的复杂世界。我们将揭示一些常见的挑战和误区，以及如何克服它们。

我们还将分享一些最佳实践和技巧，让您的 RAG 系统更加强大、灵活和可靠。

但这个博客不仅仅是一个理论之旅；它也是一个实践之旅。这是帮助您采取行动的实用指南！我们将通过一些真实的案例，展示如何使用 RAG 系统解决实际的业务问题。无论您是经验丰富的开发人员还是掌舵的技术领导者，都可以从中受益。

请系好安全带，跟我们一起深入了解尖端企业 RAG 的复杂世界！

在介绍 RAG 架构的细节之前，我先给大家分享一篇最新的研究报告，它揭示了构建 RAG 系统时常遇到的七大难题。这篇研究报告基于三个不同领域的案例研究，分析了 RAG 系统在实际应用中的表现和问题。

RAG 系统的挑战

认知评审员

认知评审员是一个专门为研究人员设计的 RAG 系统，它可以帮助他们快速分析科学文献。研究人员只需要输入一个研究问题或目标，然后上传一些相关的论文。系统会根据研究目标对这些论文进行排序，让研究人员可以方便地筛选和查看。此外，研究人员还可以直接向系统提问，获取针对整个文献集合的答案。

AI导师

AI Tutor 是一个面向学生的 RAG 系统，它可以根据学习内容回答学生的问题。学生可以通过查看答案的来源来验证其正确性。AI Tutor 集成到了迪肯大学的学习管理系统中，可以对所有的学习资料进行索引，包括 PDF、视频和文本文档。系统在对视频进行分块之前，使用了 Whisper 深度学习模型来转录视频内容。RAG 管道中还包含了一个重写器，用于对查询进行泛化，以及一个聊天界面，用于利用之前的对话来理解每个问题的上下文。

生物医学问答

生物医学问答是一个基于 BioASQ 数据集的 RAG 系统，该数据集包含了一些由生物医学专家制作的问题、文档链接和答案，涉及到特定领域的知识。这些问题的答案可能是/否、文本摘要、事实陈述或列表。

RAG 系统的 7 大难题

通过这些案例研究，研究人员发现了 RAG 系统在设计和实现过程中经常遇到的七大难题。

内容缺失 (FP1)

系统无法从现有的文档中找到问题的答案。理想情况下，系统应该回复“抱歉，我无法回答这个问题”之类的信息。但是，对于一些没有明确答案的问题，系统可能会误导性地给出一个答案。

文档排名不准 (FP2)

问题的答案存在于某个文档中，但该文档的排名太低，没有被包含在返回给用户的结果中。虽然理论上系统应该对所有的文档进行排序并在后续的步骤中使用，但实际上系统只会返回前 K 个文档，其中 K 是一个基于性能考虑的参数。

上下文不匹配 (FP3)

整合策略的局限，系统从数据库中检索到了包含答案的文档，但无法将其与生成答案的上下文相匹配。这种情况通常发生在系统返回了大量的文档，导致合并过程难以找到相关的答案。

提取失败 (FP4)

答案存在于上下文中，但模型无法提取出正确的信息。这种情况通常发生在上下文中有太多的噪声或冲突信息的时候。

格式错误 (FP5)

问题要求以特定的格式（例如表格或列表）提供信息，但模型没有遵循指令。

特异性不合适 (FP6)

答案包含在响应中，但没有达到用户期望的特异性或过于具体，无法满足用户的需求。这种情况通常发生在 RAG 系统的设计者对问题有预期的答案时（例如教师寻求教育内容），此时应该提供具有教育意义的内容和答案。当用户不清楚如何表达问题并且过于模糊时，也会出现特异性不合适的问题。

不完整 (FP7)

答案是正确的，但缺少了一些信息，即使这些信息存在于上下文中并且可以被提取出来。例如，“文件A、B、C中的主要观点是什么？”这样的问题。针对每个文件单独提问会更好。

下表包含他们从解决每个问题中学到的经验教训。在构建我们的企业 RAG 系统时，我们将牢记这些教训。

如何打造高效的 RAG 系统

在了解了 RAG 系统的常见问题和挑战后，我们接下来要探讨的是，如何设计和实现每个组件，以及如何遵循最佳实践。下面的 RAG 系统架构图展示了每个组件的位置和功能。

用户认证

这是我们系统的第一道关卡！在用户与聊天机器人进行交流之前，我们需要对用户进行身份验证。这样做不仅有利于保障安全性和个性化，也是企业系统的基本要求。

访问控制

身份验证保证了只有合法用户才能使用系统。它可以帮助我们管理用户的权限和操作。

数据安全

数据是我们系统的核心资产，必须加以保护。用户身份验证可以防止未授权的人员窃取或篡改机密信息，避免数据泄露和损坏。

用户隐私

身份验证也可以保护用户的个人信息和账户详情，不让他们被他人查看或滥用。这是建立用户信任的重要前提。

合法合规

很多国家和行业都有相关的法律法规，要求企业实施合理的用户身份验证，以维护用户数据和隐私的安全。遵守这些规定可以帮助我们避免法律风险和潜在的惩罚。

问责制

身份验证还可以让我们追踪和记录用户在系统中的行为，从而实现问责制。这对于审计和监控用户活动，识别和处理任何安全事件或可疑行为非常有用。

个性化和定制

身份验证让系统能够识别每个用户，从而提供个性化和定制的用户体验。这包括为用户提供适合他们的内容、偏好和设置。

AWS Cognito 或 Firebase Authentication 等服务可以帮助你轻松地为你的移动和 Web 应用程序添加用户注册和身份验证的功能。

输入护栏

用户输入的内容可能会对系统造成危害或泄露个人信息。最近的研究显示，法学硕士很容易被越狱。因此，我们需要在系统中设置输入护栏，来防范各种风险。下面我们来看看输入护栏可以应对的不同场景。

匿名化

输入护栏可以对个人身份信息 (PII)，如姓名、地址或联系方式，进行匿名或编辑。这样可以保护用户的隐私，防止有人恶意泄露或利用这些信息。

限制子字符串

输入护栏可以禁止一些可能用于 SQL 注入、跨站点脚本 (XSS) 或其他注入攻击的子字符串或模式，从而避免系统出现安全漏洞或异常行为。

限制主题

输入护栏可以过滤掉一些可能与不适当、冒犯或违反社区规范的特定主题相关的内容，如仇恨言论、歧视或色情内容。这样可以维护系统的良好氛围和声誉。

限制代码

输入护栏可以阻止用户输入一些可能危害系统安全或导致代码注入攻击的可执行代码。这样可以保护系统的完整性和稳定性。

限制语言

输入护栏可以检测用户输入的文本是否使用了正确的语言或脚本，从而避免在处理过程中产生误解或错误。

检测提示注入

输入护栏可以减少用户试图注入一些误导性或有害的提示的可能性，这些提示可能会以意想不到的方式影响系统或法学硕士的行为。

限制Token

输入护栏可以对用户输入的Token或字符数量进行限制，从而防止系统资源被耗尽或遭受拒绝服务 (DoS) 攻击。

检测毒性

输入护栏可以实施毒性过滤器，来识别和阻止包含有害或辱骂性语言的输入。这样可以保护系统和用户免受不良影响。

为了让你的 RAG 系统能够有效地使用输入护栏，你可以借助 Meta 的 Llama Guard 服务。你可以选择自己托管或使用 Sagemaker 等托管服务。不过，你也要知道，它并不能完全保证检测出所有的毒性内容。

查询重写器

用户输入的查询可能不够清楚或需要上下文才能明确用户的意图。查询重写就是一种解决这个问题的技术。它可以改变用户查询的形式，让它更清晰、精确和相关。下面我们来看看一些常用的技术。

根据历史重写

这种方法利用了用户的查询历史，来理解对话的上下文，并优化后续的查询。我们以信用卡查询为例。

查询历史：

“你有多少张信用卡？”

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

“比较两者的特点。”

系统根据用户的查询历史，识别出上下文的变化，判断出用户的意图和查询之间的关系，并生成与上下文一致的查询。

重写查询：“比较白金信用卡和金卡信用卡的优劣。”

创建子查询

复杂的查询可能难以一次性回答。为了简化任务，系统可以把查询分解成更具体的子查询。这样可以帮助系统检索出生成答案所需的正确的上下文。LlamaIndex 把这个过程称为子问题查询引擎。

给定查询“比较白金信用卡和金卡信用卡的功能”，系统会为每张卡生成子查询，这些子查询都关注原始查询中提到的实体。

重写的子查询：

“白金信用卡有哪些功能？”

“金卡信用卡有哪些功能？”

创建类似的查询

为了提高检索正确文档的概率，系统可以根据用户输入生成类似的查询。这是为了弥补检索在语义或词汇匹配方面的不足。

如果用户询问信用卡功能，系统会生成相关的查询。使用同义词、相关词或领域知识来创建更符合用户意图的查询。

生成的类似查询：“我想了解白金信用卡”->“介绍一下白金信用卡的特色。”

编码器

我们把用户输入的查询和我们重写的查询都转换成向量（一串数字），以便进行检索。选择合适的编码器是构建 RAG 系统的关键步骤。我们来看看选择文本编码器的原因和注意事项。

利用 MTEB 基准

要全面评估编码器的功能，最好的参考是大规模文本嵌入基准(MTEB)。这个基准可以让我们根据向量的维度、检索的平均性能和模型的大小来对比不同的编码器。不过，我们也不能完全相信这个基准的结果，因为它并不是万能的，而且模型的训练数据的细节可能没有公开。

MTEB 不仅给我们展示了 OpenAI、Cohere 和 Voyager 等流行嵌入的性能，还告诉我们一些开源模型也有相近的性能水平。但是，我们要注意，这些结果只是一个大概的概览，可能不能准确反映这些嵌入在我们的领域和上下文中的表现。所以，在最终选择之前，我们必须对我们的数据集进行深入的评估，强调定制评估方法的重要性。

定制评估

编码器可能不能始终保持最佳的性能，特别是在处理一些敏感的信息时。这时候，定制评估方法就显得非常必要。下面是三种进行定制评估的方法。

通过注释评估

生成专门的数据集，并设置注释来获得标准的答案。注释完成后，利用平均倒数排名 (MRR) 和标准化折扣累积增益 (NDCG) 等检索指标来量化不同编码器的性能。

按模型评估

遵循与注释方法类似的数据生成过程，但使用 LLM 或交叉编码器作为评估器。这样可以在所有编码器之间建立相对的排名。然后，对前三名的编码器进行人工评估，可以得到更精确的性能指标。

聚类评价

采用不同的聚类技术，并分析不同 Silhouette 分数的覆盖范围（聚类的数据量），显示出聚类内的向量的相似度。尝试 HDBSCAN 等算法，调整它们的参数，以获得最佳的性能选择。这种基于聚类的评估可以提供有关数据点的分布和分组的有价值的见解，有助于选择符合特定指标的编码器。

选择文本编码器的考虑

选择编码器时，你需要在私有编码器或公共编码器之间做出决定。私有编码器可能更方便使用，但是这两个选项之间有一些特定的权衡。这是一个重要的决定，会影响系统的性能和延迟。

查询费用

保证语义搜索的流畅的用户体验，依赖于嵌入 API 服务的高可用性。OpenAI 和类似的提供商提供了可靠的 API，省去了托管管理的麻烦。但是，如果选择开源模型，就需要根据模型的大小和延迟的需求进行工程设计。较小的模型（最多 110M 参数）可以使用 CPU 实例托管，而较大的模型可能需要 GPU 服务来满足延迟要求。

索引成本

建立语义搜索涉及到索引文档，这会带来不小的成本。由于索引和查询使用的是同一个编码器，所以索引成本取决于选择的编码器服务。为了方便服务的重置或重新索引到其他的向量数据库，建议单独存储嵌入。如果忽略这一步骤，就需要重新计算相同的嵌入。

存储成本

对于需要索引数百万个向量的应用程序，向量数据库的存储成本是一个重要的考虑因素。存储成本与维度成正比，OpenAI 在 1526 维中的嵌入会产生最大的存储成本。要估算存储成本，需要计算每个文档的平均单位（短语或句子）并进行推断。

语言支持

为了支持你的非英语语言，你可以使用多语言编码器或使用翻译系统和英语编码器。

搜索延迟

语义搜索的延迟随着嵌入的维度线性增加。选择较低维的嵌入可以尽量减少延迟。

隐私

金融和医疗保健等敏感领域的数据隐私要求可能会限制 OpenAI 等服务的使用。

文档摄取

文档摄取系统负责数据的处理和存储。在索引过程中，每个文档被切分成更小的片段，然后用嵌入模型把它们转换成向量。接着，原始片段和向量在数据库中建立索引。我们来看看文档摄取系统的几个部分。

文档解析器

文档解析器的核心作用是从不同的文档格式中提取出结构化的信息，特别注意格式的处理。这包括解析可能包含图片和表格的 PDF 等。

文档格式

文档解析器必须能够处理多种文档格式，比如 PDF、Word、Excel 等，保证文档处理的灵活性。这涉及识别和管理嵌入的内容，比如超链接、多媒体元素或注释，以呈现文档的完整内容。

表格识别

从文档中的表格中识别和提取数据对于保持信息的结构性很重要，尤其是在报告或研究论文中。提取表格相关的元数据，包括标题、行和列信息，可以加深对文档组织结构的理解。Table Transformer 等模型可以帮助完成这项任务。

图片识别

OCR 用于文档中的图片，以识别和提取文本，使其可以用于索引和检索。

元数据提取

元数据是指文档的附加信息，不属于其主要内容。它包括作者、创建日期、文档类型、关键词等细节。元数据提供了有用的上下文，有助于组织文档并提高搜索结果的相关性。可以使用 NLP/OCR 管道提取元数据，并将文档作为特殊字段进行索引。

分块器

你决定如何分割（切分）长文本会影响向量的质量和搜索系统的性能。如果片段太小，就无法回答一些问题；如果片段太长，就会包含多余的噪声。你可以利用摘要技术来减少噪声、文本大小、编码成本和存储成本。分块是一个重要但被忽视的话题。它可能需要类似于特征工程的领域专业知识。比如，Python 代码库的分块可以使用 def/class 等前缀来完成。

索引器

没错，索引器的作用是创建文档索引，这是一种结构化的数据结构（比如说快 3 倍……）。索引器有助于高效的搜索和检索操作。高效的索引对于快速准确的文档检索非常重要。它涉及把片段或标记映射到文档集合中的相应位置。索引器执行文档检索中的重要任务，包括创建索引以及添加、更新或删除文档。

索引器是 RAG 系统的关键部分，面临着各种可能影响系统效率和性能的挑战和问题。

可扩展性问题

随着文档量的增加，保持高效、快速的索引变得有挑战性。当系统难以处理越来越多的文档时，可能会出现可扩展性问题，导致索引和检索时间变慢。

实时索引更新

让索引实时保持最新可能有挑战性，尤其是在频繁添加、更新或删除文档的系统中。确保实时 API 和实时索引机制顺畅运行而不影响系统性能是一项持续的挑战。

一致性和原子性

面对并发的文档更新或修改，实现一致性和原子性可能很复杂。即使存在同时发生的变化，也需要精心设计和实现，以确保索引的更新保持数据完整性。

优化存储空间

对大量文档建立索引可能会占用相当大的存储空间。优化存储空间，同时确保索引保持可访问性和响应能力是一项持续的挑战，尤其是在存储成本受到关注的情况下。

安全和访问控制

实施适当的安全措施和访问控制以防止对索引进行未经授权的修改非常重要。确保只有授权的用户或进程才能执行 CRUD 操作有助于保护文档库的完整性。

监控和维护

定期监控索引器的运行状态和性能非常重要。检测索引故障、资源瓶颈或过期索引等问题需要强大的监控和维护程序，以确保系统随着时间的推移稳定运行。

这些是一些困难但众所周知的软件工程挑战，可以通过遵循良好的软件设计实践来解决。

数据存储

我们处理的数据有多种多样，所以我们需要为每种数据提供专门的存储。了解每种存储类型的特点和适用场景是很重要的。

Embeddings 嵌入

数据库类型：SQL/NoSQL

把文档的嵌入单独存储起来，可以方便我们快速地重新索引，而不用重新计算整个文档语料库的嵌入。而且，嵌入的存储也可以作为备份，即使系统出现故障或更新，也能保证关键信息的安全。

文件

数据库类型：NoSQL

把文档的原始格式存储起来，是持久化的必要条件。这种原始格式是各个处理阶段的基础，比如索引、解析和检索。它也为未来的系统改进提供了灵活性，因为原始文档不会改变，可以根据需要重新处理。

聊天记录

数据库类型：NoSQL

把聊天的历史记录存储起来，是支持 RAG 系统的对话功能的必要条件。聊天的历史记录存储可以让系统调用之前的用户查询、回复和偏好，使其能够根据用户的特定上下文来调节和定制未来的互动。这些历史数据也是利用机器学习来改善系统的宝贵资源。

用户反馈

数据库类型：NoSQL/SQL

用户反馈是通过 RAG 应用程序内的各种互动方式收集的。在大多数法学硕士系统中，用户可以通过点赞/点踩、星级评价和文本反馈来提供反馈。这些用户的见解构成了一个有价值的库，包含了用户的体验和感受，为持续的系统改进提供了基础。

向量数据库

支持语义搜索的向量数据库是 RAG 的重要检索部分。但是，正确选择这个部分是避免潜在问题的关键。在选择过程中，需要考虑几个向量数据库的因素。我们来看看其中的一些。

召回率与延迟

在向量数据库中，召回率（相关结果的比例）和延迟（返回结果的时间）是需要权衡的。Flat、HNSW（分层导航小世界）、PQ（产品量化）、ANNOY和DiskANN等不同的索引在速度和召回率之间有不同的平衡。对你的数据和查询进行基准测试，以做出明智的选择。

成本

有托管方案的云原生数据库通常根据数据存储和查询量来收费。这种模式适合有大量数据的组织，省去了基础设施的成本。主要的考虑因素包括评估数据集的增长、团队的能力、数据的敏感性，以及了解托管云方案的成本影响。

另一方面，自托管可以让组织对自己的基础设施有更多的控制，也可能降低成本。但是，它也带来了管理和维护基础设施的责任，包括可扩展性、安全性和更新的考虑。

插入速度与查询速度

平衡插入速度和查询速度是很重要的。寻找能够处理有高插入速度需求的流式用例的供应商。但是，对于大多数组织来说，查询速度更为重要。评估峰值负载时的向量插入速度和查询延迟，以做出明智的决策。

内存中与磁盘上索引存储

在内存和磁盘存储之间选择，涉及到速度和成本的权衡。虽然内存存储提供了高速，但有些用例需要存储超过内存的向量。内存映射文件等技术可以在不影响搜索速度的情况下扩展向量存储。DiskANN 中的 Vamana 等新索引保证了高效的内存外索引。

全文搜索与向量混合搜索

对于企业级应用程序来说，单纯的向量搜索可能不够理想。另一方面，集成密集和稀疏方法的混合搜索需要更多的工作。常见的做法是实现密集向量索引、稀疏倒排索引和重新排序步骤。密集元素和稀疏元素之间的平衡可以通过 Pinecone、Weaviate 和 Elasticsearch 中的 alpha 参数来调节。

过滤

现实世界的搜索查询通常涉及元数据属性的过滤。预过滤搜索看起来很自然，但可能会导致错过相关结果。如果过滤的属性只占数据集的一小部分，那么过滤后的搜索可能会有问题。自定义过滤搜索，比如 Weaviate，将预过滤和使用倒排索引分片和 HNSW 索引分片的高效语义搜索结合起来。

改进检索的技术

最近的研究表明，法学硕士容易被无关的上下文干扰，并且由于法学硕士的注意力机制，拥有大量的上下文（topK 检索文档）可能会导致遗漏一些上下文。因此，改进相关和多样化文档的检索非常重要。我们来看看一些验证过的改进检索的技术。

假设文档嵌入 (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]。

自动剪切返回以下内容：

自动剪切：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]

递归检索

递归检索，又称从小到大检索技术，先嵌入较小的块进行检索，再返回较大的父上下文以进行语言模型的生成。较小的文本块有助于更精确的检索，而较大的文本块为语言模型提供更丰富的上下文信息。这个顺序过程通过先关注更小、信息更密集的单元来优化检索的准确性，然后将这些单元有效地连接到更广泛的上下文父块以进行生成。

句子窗口检索

检索过程获取单个句子并返回该句子周围的文本窗口。句子窗口检索确保检索到的信息不仅准确而且与上下文相关，提供主句周围的完整信息。

生成器

现在我们已经讨论了所有检索组件，让我们来谈谈生成器。主要需要在自托管推理部署和私有 API 服务之间进行仔细的考虑和权衡。这本身就是一个很大的话题，我将简要介绍一下，以免让你感到困惑。

API注意事项

如果你想用法学硕士来为你的公众号写出爆款文章，那么你需要选择一个合适的 API 服务器来部署你的模型。一个好的 API 服务器应该能够让你轻松地使用流行的 LLM，同时还要考虑生产环境、安全性和幻觉检测等重要因素。HuggingFace 的 TGI 服务器就是一个很好的例子，它提供了一系列的功能来满足你的需求。下面我们来看看 LLM 服务器需要具备的一些常见的功能。

性能

一个高效的 API 服务器必须能够根据不同的用户需求提供高性能的服务。张量并行性是一项重要的功能，它可以在多个 GPU 上快速地进行推理，提升整体的处理速度。此外，连续批处理传入的请求可以提高总的吞吐量，从而提升系统的响应速度和可扩展性。量化的技术，比如比特和字节和 GPT-Q，可以进一步优化 API，提高各种场景的效率。利用优化的转换器代码，可以保证对最流行的架构进行无缝的推理。

质量

为了提高生成的质量，API 服务器应该提供一些可以调整输出的功能。Logits 处理器包括温度缩放、top-p、top-k 和重复惩罚，让用户可以根据自己的喜好定制输出。此外，停止序列可以让用户控制生成的过程，使用户可以管理和完善内容的生成。对数概率可以用于幻觉检测，作为一个额外的优化层，确保生成的输出与预期的上下文一致，并避免误导的信息。

安全

API 服务器的安全性是非常重要的，尤其是在处理法学硕士和企业场景时。Safetensors 是一种可以保护模型参数和数据的技术，防止未经授权的访问和篡改。此外，水印的技术可以增加一个额外的安全层，实现法学硕士使用的可追溯性和问责制。

用户体验

在用户体验方面，令牌流是一种可以实现无缝交互的关键功能。利用服务器发送事件（SSE）进行令牌流可以增强 API 的实时响应能力，为用户提供更流畅、更有互动性的体验。这可以保证用户可以逐步地接收生成的内容，从而提高法学硕士的整体参与度和可用性。

自托管推理

自托管推理指的是在 AWS、GCP 或 Azure 等云服务提供商提供的服务器上部署 LLM。选择服务器（例如 TGI、Ray 或 FastAPI）是一个直接影响系统性能和成本的关键决策。需要考虑的因素包括计算效率、部署便利性以及与所选法学硕士的兼容性。

衡量 LLM 推理性能是非常重要的，而 Anyscale 的 LLMPerf 排行榜等排行榜可以提供很有价值的参考。它根据关键的性能指标对推理提供商进行排名，包括首次令牌时间 (TTFT)、令牌间延迟 (ITL) 和成功率。负载测试和正确性测试对于评估托管模型的不同特性是非常必要的。

在新的方法中，Predibase 的 LoRAX 提出了一种创新的方法来有效地为经过微调的法学硕士提供服务。它解决了使用共享 GPU 资源服务多个微调模型的挑战。

私有 API 服务

OpenAI、Fireworks、Anyscale、Replicate、Mistral、Perplexity 和 Together 等公司提供的 LLM API 服务是另一种部署的选择。了解它们的功能、定价模型和 LLM 绩效指标是非常重要的。例如，OpenAI 基于代币的定价（输入和输出代币之间存在区别）可以显著影响使用 API 的总体成本。在比较私有 API 服务与自托管 LLM 的成本时，你必须考虑 GPU 成本、利用率和可扩展性问题等因素。对于某些人来说，速率限制可能是一个限制因素（哈！）。

改进 RAG 的提示技术

有多种提示技术可以用于改进 RAG 的输出。在 Mastering RAG 系列的第 2 部分中，我们详细介绍了 5 个最有效的方法。其中许多新技术都超越了 CoT（思想链）的性能。你还可以将它们结合起来以尽量减少幻觉。

输出护栏

输出护栏的功能与其对应的输入护栏类似，但专门用于检测生成的输出中的问题。作为 RAG 评估的一部分，它专注于识别幻觉、竞争对手提及和潜在的品牌损害。目标是防止生成可能与品牌价值观不符的不准确或道德上有问题的信息。通过积极监控和分析输出，该护栏可以确保生成的内容保持事实准确、道德合理且符合品牌准则。

以下是可能损害企业品牌但会被适当的输出护栏阻止的响应示例：

有毒输出示例。

用户反馈

当你用法学硕士为你的公众号生成了内容后，及时收集用户的反馈是非常有益的。用户反馈可以帮助你改进 RAG 系统，让它更符合你的目标和期望。这是一个持续的过程，而不是一次性的努力。你不仅需要定期执行自动化任务（例如重新索引和实验重新运行），还需要采用系统化的方法来整合用户的意见，以实现实质性的系统提升。

系统改进最有影响力的杠杆在于主动修复底层数据中的问题。RAG 系统应该包含一个用于处理用户反馈和推动持续改进的迭代工作流程。

用户交互和反馈收集

用户与 RAG 应用程序交互，并利用 👍/ 👎 或星级评级等功能来提供反馈。这种多样化的反馈机制可以作为评估用户体验和系统性能的宝贵来源。

问题识别和诊断检查

收集反馈后，你可以进行全面分析，以识别可能存在问题的查询。这涉及检查检索到的资源并仔细检查，以判断问题是出在检索、生成还是底层数据源上。

数据改进策略

一旦发现问题，特别是那些源于数据本身的问题，你就可以制定战略性的计划来提高数据质量。这可能涉及纠正不完整的信息或重组组织不良的内容。

评估和测试协议

实施数据改进后，系统必须对之前存在问题的查询进行严格的评估。从这些评估中获得的见解可以有序地集成到测试套件中，确保基于现实世界的交互进行持续的检查和改进。

通过积极让用户参与这个全面的反馈循环，RAG 系统不仅可以解决通过自动化流程发现的问题，还可以利用丰富的用户体验。

可观测性

构建 RAG 系统并不意味着任务完成。即使有强大的护栏和用于微调的高质量数据，模型在投入生产后也需要持续监控。除了延迟和成本等常规指标之外，生成式 AI 应用程序还需要特定的 LLM 可观察性来检测和纠正幻觉、域外查询和链故障等问题。现在让我们来看看 LLM 可观察性的要素。

及时分析和优化

及时识别和解决与提示相关的问题，并使用实时生产数据进行迭代，以利用强大的评估机制来识别和解决幻觉等问题。

LLM应用中的可追溯性

利用 Langchain 和 LlamaIndex 等常用框架捕获 LLM 跟踪，以便调试提示和步骤。

信息检索增强

对 RAG 参数进行故障排除和评估，以优化对 LLM 性能至关重要的检索流程。

警报

如果系统行为与预期不一致，例如错误增加、高延迟和幻觉，则会收到警报。

首先，实时监控对于观察生产环境中应用程序的性能、行为和整体运行状况至关重要。密切关注 SLA 合规性并设置警报，以便及时解决任何偏差。通过分析使用模式和资源消耗，有效跟踪与运行 LLM 应用程序相关的成本，帮助你优化成本。

此外，你还可以灵活地注册自定义指标，以便根据你的特定需求定制监控流程。利用监控数据生成的见解和警报，随时了解潜在问题、异常情况或需要注意的改进领域。这种全面的方法可以确保你的法学硕士应用在现实场景中高效、安全地运行。

缓存

对于大规模运营的公司来说，成本可能成为一个障碍。在这种情况下，缓存是一种省钱的好方法。缓存涉及在数据库中存储提示及其相应的响应，以便能够检索它们以供后续使用。这种战略性缓存机制使 LLM 应用程序能够加快并节省响应速度，并具有三个明显的优势。

提升的生产推理

缓存可以帮助在生产过程中进行更快且更具成本效益的推理。某些查询可以通过利用缓存的响应来实现接近零的延迟，从而简化用户体验。

加速的开发周期

在开发阶段，缓存是一个福音，因为它消除了重复调用相同提示的 API 的需要。这可以带来更快、更经济的开发周期。

数据存储

存储所有提示的综合数据库可以简化法学硕士的微调过程。利用存储的提示响应对可以简化基于累积数据的模型优化。

如果你是认真的，你可以利用 GPTCache 来实现精确匹配和相似匹配的缓存。它提供了有价值的指标，例如缓存命中率、延迟和召回率，这些指标可以帮助你深入了解缓存的性能，从而实现持续改进以确保最佳效率。

多租户

SaaS 软件通常需要同时服务多个租户，同时保证简单性和隐私性。对于 RAG 系统中的多租户，目标是构建一个既能高效地检索信息，又能尊重每个用户的数据隐私的系统。简而言之，每个用户与系统的交互都是独立的，确保系统只查看和使用适合该用户的信息。

构建多租户的简单方法之一是使用元数据。当我们向系统添加文档时，我们会在元数据中包含特定的用户信息。这样，每个文档都与特定用户相关联。当有人搜索时，系统使用这个元数据来过滤并只显示与该用户相关的文档。然后，它会进行智能搜索，找到该用户最感兴趣的信息。这种方法可以避免不同用户之间的私密信息混淆，从而保障每个人的数据安全和私密。

了解如何使用 Llamaindex 实现多租户。