下面的 RAG 系统架构图提供了每个组件的使用位置和方式的上下文，接下来我们将逐步讲解每个组件的设计需求和作用，以及构建这些组件的最佳实践。
源文地址：https://www.rungalileo.io/blog/mastering-rag-how-to-architect-an-enterprise-rag-system#generator
1、用户认证【User authentication】
在用户开始与聊天机器人互动之前，我们需要出于各种原因对用户进行身份验证。身份验证有助于确保安全性 和个性化，这对于企业系统来说是必不可少的。
- 数据安全【Data Security】：保护敏感数据至关重要。用户身份验证可防止未经授权的个人访问机密信息，从而防止数据泄露和未经授权的数据操纵。
- 问责制【Accountability】：身份验证通过将系统内的操作与特定用户账户关联来确保问责制。这对于审计和跟踪用户活动至关重要，有助于识别和解决任何安全事件或可疑行为。
- 个性化和定制【Personalization and Customization】：身份验证允许系统识别单个用户，从而实现个性化和定制用户体验。这可以包括定制内容、偏好和设置。
参考： AWS Cognito or Firebase Authentication
2、输入护栏【Input guardrail】
防止有害或包含隐私信息的 用户输入 至关重要。需要护栏的场景包含：
- 限制子字符串【Restrict substrings】：禁止某些子字符串或模式，这些子字符串或模式可能会被利用进行 SQL 注入、跨站点脚本 (XSS) 或其他注入攻击，从而防止安全漏洞或不需要的行为。
- 限制主题【Restrict topics】：为了限制讨论或输入与特定主题相关的内容，这些主题可能不当、冒犯或违反社区准则，因此过滤掉包含仇恨言论、歧视或色情内容的内容很重要。
- 限制代码【Restrict code】：必须防止注入可执行代码，否则可能会破坏系统安全或导致代码注入攻击。
- 限制tokens【Limit tokens】：对用户输入强制执行最大令牌或字符限制有助于避免资源耗尽并防止拒绝服务 (DoS) 攻击。
- 检测毒性【Detect toxicity】：实施毒性过滤器来识别和阻止包含有害或辱骂语言的输入。
参考：大模型用于内容风控 LLama Guard ，您可以自己托管它，也可以使用 Sagemaker 等托管服务。但是，请不要指望它能完美地检测毒性内容。
3、查询重写器【Query rewriter】
用户查询可能含糊不清，或者需要上下文才能更好地理解用户的意图。查询重写是一种有助于解决此问题的技术。它涉及转换用户查询以提高清晰度、准确性和相关性。让我们来看看一些最常用的技术：
- 基于历史记录重写【Rewrite based on history】：这种方法中，系统利用用户的查询历史记录来理解对话的上下文并改进后续查询。
- 创建子查询【Create subqueries】：由于检索问题，复杂查询可能难以回答。为了简化任务，查询会被分解成更具体的子查询。这有助于检索生成答案所需的正确上下文。LlamaIndex refers to this as a sub question query engine
- 创建相似查询【Create similar queries】：为了提高检索相关文档的可能性，我们会根据用户输入生成类似的查询。这可以克服检索在语义或词汇匹配方面的限制。如：我想知道白金信用卡 -> 告诉我白金信用卡的优点
4、编码器【Encoder】
用户输入的查询和我们重写的查询都转换成向量（一串数字），以便进行检索。选择合适的编码器是构建 RAG 系统的关键步骤。选择文本编码器的原因和注意事项。
利用 MTEB 基准【Leveraging MTEB benchmarks】
MTEB（Massive Text Embedding Benchmark）是一堆衡量文本嵌入模型的评估指标合集，与之对应的中文评估指标是 C-MTEB （flag-embedding开源项目）。
MTEB 不仅给我们展示了 OpenAI、Cohere 和 Voyager 等流行嵌入的性能，还告诉我们一些开源模型也有相近的性能水平。
但是，我们要注意，这些结果只是一个大概的概览，可能不能准确反映这些嵌入在我们的领域和上下文中的表现。所以，在最终选择之前，我们必须对我们的数据集进行深入的评估，强调定制评估方法的重要性。
- 查询成本【Querying cost】：确保语义搜索的流畅用户体验依赖于嵌入式 API 服务的高可用性。OpenAI 和类似的供应商提供可靠的 API，消除了托管管理的需要。然而，选择开源模型需要根据模型大小和延迟需求进行工程方面的投入。较小的模型（最多 1.1 亿参数）可以利用 CPU 实例托管，而较大的模型可能需要 GPU 服务来满足延迟要求。
- 索引成本【Indexing cost】：设置语义搜索涉及对文档进行索引，这会产生非平凡的成本。由于索引和查询共享相同的编码器，因此索引成本取决于所选择的编码器服务。为了方便服务重置或重新索引到其它向量数据库，建议单独存储嵌入向量。忽略此步骤将需要重新计算相同的嵌入向量。
- 存储成本【Storage Cost】：对于索引数百万个向量的应用程序，向量数据库的存储成本是一个重要因素。存储成本与维度线性扩展，OpenAI 在 1526 维度的嵌入向量产生最大的存储成本。要估计存储成本，请计算每个文档的平均单位（词组或句子）并进行外推。
- 搜索延迟【Search latency】：语义搜索的延迟与嵌入向量的维度成线性比例增长。为了尽量减少延迟，最好选择较低维度的嵌入向量。
5、文档摄取【Document ingestion】
文档摄取系统管理着数据的处理和持久化。在索引过程中，每个文档都会被分成较小的块，然后使用嵌入模型转换为嵌入向量。然后将原始块和嵌入向量一起编入索引数据库。让我们看看文档摄取系统的组件。
- 文档解析器【Document parser】：文档解析器的核心作用是从不同的文档格式中提取出结构化的信息，特别注意格式的处理。这包括解析可能包含图片和表格的 PDF 等。
- 文档格式【Document formats】：文档解析器必须能够处理多种文档格式，比如 PDF、Word、Excel 等，保证文档处理的灵活性。这涉及识别和管理嵌入的内容，比如超链接、多媒体元素或注释，以呈现文档的完整内容。
- 表格识别【Table recognition】：从文档中的表格中识别和提取数据对于保持信息的结构性很重要，尤其是在报告或研究论文中。提取表格相关的元数据，包括标题、行和列信息，可以加深对文档组织结构的理解。Table Transformer 等模型可以帮助完成这项任务。
- 图像识别【Image recognition】：光字符识别 (OCR) 应用于文档中的图像，以主动识别和提取文本，使其可以进行索引和后续检索。
- 元数据提取【Metadata extraction】：元数据是指文档的附加信息，不属于其主要内容。它包括作者、创建日期、文档类型、关键词等细节。元数据提供了有用的上下文，有助于组织文档并提高搜索结果的相关性。可以使用 NLP/OCR 管道提取元数据，并将文档作为特殊字段进行索引。
6、分块器【Chunker】
您决定如何对长文本进行分词 (拆分) 可以决定嵌入向量质量和搜索系统的性能。如果块太小，则无法回答某些问题；如果块太长，则答案会包含生成的噪音。您可以利用summarisation 技术来减少噪音、文本大小、编码成本和存储成本。
分块是一个重要但经常被低估的主题。它可能需要类似于特征工程的领域专业知识。例如，针对 Python 代码库的拆块可能会使用 def/class 等前缀来完成。
7、索引器【Indexer】
索引器的作用是创建文档索引，这是一种结构化的数据结构（比如说快 3 倍……）。索引器有助于高效的搜索和检索操作。
高效的索引对于快速准确的文档检索非常重要。它涉及把片段或标记映射到文档集合中的相应位置。索引器执行文档检索中的重要任务，包括创建索引以及添加、更新或删除文档。
索引器是 RAG 系统的关键部分，面临着各种可能影响系统效率和性能的挑战和问题。
- 可扩展性问题【Scalability issues】：随着文档量的增加，保持高效、快速的索引变得有挑战性。当系统难以处理越来越多的文档时，可能会出现可扩展性问题，导致索引和检索时间变慢。
- 实时索引更新【Real-time index updates】：让索引实时保持最新可能有挑战性，尤其是在频繁添加、更新或删除文档的系统中。确保实时 API 和实时索引机制顺畅运行而不影响系统性能是一项持续的挑战。
- 一致性和原子性【Consistency and atomicity】：面对并发的文档更新或修改，实现一致性和原子性可能很复杂。即使存在同时发生的变化，也需要精心设计和实现，以确保索引的更新保持数据完整性。
- 优化存储空间【Optimizing storage space】：对大量文档建立索引可能会占用相当大的存储空间。优化存储空间，同时确保索引保持可访问性和响应能力是一项持续的挑战，尤其是在存储成本受到关注的情况下。
- 安全和访问控制【Security and access control】：实施适当的安全措施和访问控制以防止对索引进行未经授权的修改非常重要。确保只有授权的用户或进程才能执行 CRUD 操作有助于保护文档库的完整性。
- 监控和维护【Monitoring and maintenance】：定期监控索引器的运行状态和性能非常重要。检测索引故障、资源瓶颈或过期索引等问题需要强大的监控和维护程序，以确保系统随着时间的推移稳定运行。
这些是一些困难但众所周知的软件工程挑战，可以通过遵循良好的软件设计实践来解决。
8、数据存储【Data storage】
我们处理的数据有多种多样，所以我们需要为每种数据提供专门的存储。了解每种存储类型的特点和适用场景是很重要的。
- Embeddings：【数据库类型：SQL/NoSQL】把文档的嵌入单独存储起来，可以方便我们快速地重新索引，而不用重新计算整个文档语料库的嵌入。而且，嵌入的存储也可以作为备份，即使系统出现故障或更新，也能保证关键信息的安全。
- 文件【Documents】：【数据库类型：NoSQL】把文档的原始格式存储起来，是持久化的必要条件。这种原始格式是各个处理阶段的基础，比如索引、解析和检索。它也为未来的系统改进提供了灵活性，因为原始文档不会改变，可以根据需要重新处理。
- 聊天记录【Chat history】：【数据库类型：NoSQL】把聊天的历史记录存储起来，是支持 RAG 系统的对话功能的必要条件。聊天的历史记录存储可以让系统调用之前的用户查询、回复和偏好，使其能够根据用户的特定上下文来调节和定制未来的互动。这些历史数据也是利用机器学习来改善系统的宝贵资源。
- 用户反馈【User feedback】：【数据库类型：NoSQL/SQL】用户反馈是通过 RAG 应用程序内的各种互动方式收集的。在大多数LLM系统中，用户可以通过点赞/点踩、星级评价和文本反馈来提供反馈。这些用户的见解构成了一个有价值的库，包含了用户的体验和感受，为持续的系统改进提供了基础。
9、向量数据库【Vector database】
支持语义搜索的向量数据库是 RAG 的重要检索部分。但是，正确选择这个部分是避免潜在问题的关键。在选择过程中，需要考虑几个向量数据库的因素。我们来看看其中的一些。
- 召回率与延迟【Recall vs. Latency】：在向量数据库中，召回率（相关结果的比例）和延迟（返回结果的时间）是需要权衡的。象 Flat、HNSW、PQ、ANNOY 和 DiskANN 等不同的索引在速度和召回率之间有不同的平衡。对你的数据和查询进行基准测试，以做出明智的选择。
- 成本【Cost】：具有托管解决方案的云原生数据库通常根据数据存储和查询量计费。对于拥有大量数据的组织来说，这种模式可以避免基础设施成本。主要考虑因素包括评估数据集增长、团队能力、数据敏感性以及了解托管云解决方案的成本影响。另一方面，自托管可以让组织对自己的基础设施有更多的控制，也可能降低成本。但是，它也带来了管理和维护基础设施的责任，包括可扩展性、安全性和更新的考虑。
- 插入速度与查询速度【Insertion speed vs. Query speed】：平衡插入速度和查询速度是很重要的。寻找能够处理有高插入速度需求的流式用例的供应商。但是，对于大多数组织来说，查询速度更为重要。评估峰值负载时的向量插入速度和查询延迟，以做出明智的决策。
- 内存 vs. 磁盘索引存储【In-memory vs. On-disk index storage】：在内存存储和磁盘存储之间进行选择涉及速度和成本的权衡。虽然内存存储提供高速性能，但某些用例需要存储大于内存的向量。内存映射文件等技术可以在不影响搜索速度的情况下扩展向量存储。DiskANN 中的 Vamana 等新索引承诺提供高效的内存外索引。
10、提高检索效率的技术【Techniques for improving retrieval】
最近的研究表明，大型语言模型(LLMs)很容易被无关的上下文所分散注意力，而且拥有大量上下文（检索到的 topK 文档）可能会因为LLMs的注意力模式而错过某些上下文。因此，利用相关和多样化的文档来提高检索是至关重要的。让我们看一些提高检索的已证实技术。
10.1 假设文档嵌入 (HyDE)【Hypothetical document embeddings】
我们可以使用 HyDE 技术来解决检索性能低的问题，特别是在处理可能导致查找信息困难的短查询或不匹配查询时。HyDE 采用独特的方法，使用 GPT 等模型创建的假设文档。
这些假设的文档捕捉了重要的模式，但可能包含虚构或错误的细节。然后，智能文本编码器将这个假设文档转换为向量嵌入。
这种嵌入比直接嵌入查询更能在集合中找到相似的真实文档。
实验表明，HyDE 比其他先进方法效果更好，使其成为提高 RAG 系统性能的有力工具。
10.2 查询路由【Query routing】
在处理多个索引时，查询路由是有益的，它将查询引导到最相关的索引，以实现高效的检索。这种方法通过确保每个查询都引导到合适的索引来简化搜索过程，从而优化信息检索的准确性和速度。
在企业搜索的场景下，数据来自不同的来源（比如技术文档、产品文档、任务和代码仓库），查询路由是一个强大的工具。
比如，如果用户正在搜索与特定产品功能相关的信息，那么查询可以智能地路由到包含产品文档的索引，从而提高搜索结果的精确度。
10.3 重新排序【Reranker】
当从编码器检索的结果不能提供最佳质量时，会使用重新排名器来增强文档排名。利用开源的 encoder-only transformers 如 BGE-large 已成为常见做法，最近的 encoder-only transformers方法，比如 RankVicuna、RankGPT 和 RankZephyr 进一步提高了重新排序器的性能。
引入重新排序器有好处，可以减少 LLM 回复中的幻觉，并提高系统的域外泛化能力。但是，它也有缺点。复杂的重新排序可能会因为计算开销而增加延迟，从而影响实时应用程序。
此外，部署高级重新排序器可能会占用大量的资源，需要仔细考虑性能提升和资源利用率之间的平衡。
10.4 最大边际相关性 (MMR)【Maximal Marginal Relevance】
MMR 是一种旨在增强响应查询的检索项目的多样性，避免冗余的方法。MMR 不仅关注检索最相关的项目，而且实现了相关性和多样性之间的平衡。
这就像在聚会上向人们介绍朋友一样。首先，它根据朋友的喜好来识别最适合的人。
然后，它会寻找有些不同的人。这个过程持续进行，直到达到想要介绍的人数。MMR 确保呈现出更多样化和相关的项目集，从而最大程度地减少冗余。
10.5 句子窗口检索【Sentence window retrieval】
检索过程获取单个句子并返回该句子周围的文本窗口。句子窗口检索确保检索到的信息不仅准确而且与上下文相关，提供主句周围的完整信息。
11、生成器【Generator】
现在我们已经讨论了所有检索组件，让我们来谈谈生成器。主要需要在自托管推理部署和私有 API 服务之间进行仔细的考虑和权衡。这本身就是一个很大的话题，我将简要介绍一下，以免让你感到困惑
API注意事项【API considerations】
在评估 LLMs 的 API 服务器时，优先考虑确保无缝集成和强大性能的功能至关重要。一个设计良好的 API 应该作为流行的 LLMs 的简单启动器，同时还要解决关键考虑因素，如生产就绪性、安全性和幻觉检测。
值得注意的是 TGI server from HuggingFace 体现了这些原则的一套全面功能。让我们了解一下在 LLM 服务中需要的一些最受欢迎的功能。
11.1 性能【Performance】
- 一个高效的 API 必须优先考虑性能，以满足不同用户需求。张量并行性是一种在多个 GPU 上实现更快推断的功能，增强了整体处理速度。
- 此外，持续批处理传入请求确保了总吞吐量的增加，有助于实现更响应迅速和可扩展的系统。
- 使用位和字节以及 GPT-Q 进行量化进一步优化了 API，在各种用例中提高了效率。利用优化的转换器代码，可以保证对最流行的架构进行无缝的推理。
11.2 质量【Generation quality enhancers】
- 为了提高生成质量，API 应该包含能够转换输出的功能。logits 处理器包括温度缩放、top-p、top-k 和重复惩罚，允许用户根据自己的偏好自定义输出。
- 此外，停止序列提供了对生成的控制，使用户可以管理和优化内容生成过程。对数概率对幻觉检测至关重要，它作为一种额外的精炼层，确保生成的输出与预期的上下文一致，避免误导性信息。
11.3安全【Security】
- API 的安全性至关重要，特别是在处理 LLMs 和企业应用场景。
- Safetensors 是一种可以保护模型参数和数据的技术，通过防止未经授权的模型参数篡改来有助于模型的安全部署。
- 此外，包含水印技术增加了一层额外的安全性，使得追踪和追责在 LLMs 的使用中成为可能。
11.4 用户体验【User experience】
- 在用户体验方面，token streaming emerges 是一种可以实现无缝交互的关键功能。
- Utilizing Server-Sent Events (SSE) for token streaming 可以增强 API 的实时响应能力，为用户提供更流畅、更有互动性的体验。
- 这可以保证用户可以逐步地接收生成的内容，提高了 LLM 的整体参与度和可用性。
11.5 自托管推理【Self-hosted inference】
- 自托管推理涉及将 LLMs 部署到由云服务提供商（如 AWS、GCP 或 Azure）提供的服务器上。
- 服务的选择，例如 TGI、Ray 或 FastAPI，是一个关键决定，直接影响系统的性能和成本。考虑因素包括计算效率、部署便利性和与所选 LLM 的兼容性。
- 衡量 LLM 推理性能是非常重要的，可参考 Anyscale's LLMPerf Leaderboard 的排名。它根据关键的性能指标对推理提供商进行排名，包括首次令牌时间 (TTFT)、令牌间延迟 (ITL) 和成功率。负载测试和正确性测试对于评估托管模型的不同特性是非常必要的。
- 在新方法中，Predibase's LoRAX 以一种创新的方式高效地提供了精细调整的 LLMs。它解决了使用共享 GPU 资源服务多个精细调整模型的挑战。
11.6 私有 API 服务【Private API services】
- 像 OpenAI、Fireworks、Anyscale、Replicate、Mistral、Perplexity 和 Together 这样的公司提供的 LLM API 服务提供了替代部署方法。了解它们的功能、定价模型和 LLM 性能指标至关重要。
- 例如，OpenAI 的基于令牌的定价模型，区分输入和输出令牌，可以极大地影响使用 API 的总成本。
- 在比较私有 API 服务与自托管 LLMs 的成本时，必须考虑 GPU 成本、利用率和可扩展性等因素。对于一些情况来说，速率限制可能是一个限制因素。
参考：
- Text Generation Inference：https://github.com/huggingface/text-generation-inference
- LoRAX： https://github.com/predibase/lorax
12、改进 RAG 的提示技术【Prompting techniques for improving RAG】
存在许多用于改进 RAG 输出的提示技术。在我们的 RAG 掌握系列的第二部分中，我们深入探讨了前 5 种最有效的方法。许多这些新技术超越了 CoT（思维链）的性能。您还可以将它们组合起来，以最小化幻觉。
13、输出护栏【Output guardrail】
- 输出保护栏的功能与其输入对应物类似，但专门设计用于检测生成的输出中的问题。
- 它侧重于识别幻觉、竞争对手提及以及可能导致品牌损害的问题，作为 RAG 评估 的一部分。其目标是防止生成不准确或伦理上可疑的信息，这些信息可能与品牌的价值观不符。
- 通过积极监控和分析输出，这个保护栏确保生成的内容保持事实准确、符合道德标准，并与品牌的准则一致。
14、用户反馈【User feedback】
一旦生成并提供输出，从用户那里获得积极或消极的反馈是非常有帮助的。用户反馈对于改进 RAG 系统的推动力量非常重要，这是一个持续的过程，而不是一次性的努力。
这不仅包括定期执行自动化任务，如重新索引和实验重新运行，还包括系统性地整合用户见解以实现实质性的系统增强。
系统改进中最具影响力的措施在于对基础数据中的问题进行积极补救。RAG 系统应包括一个用于处理用户反馈和推动持续改进的迭代工作流程。
14.1 用户交互和反馈收集【User interaction and feedback collection】
- 用户与 RAG 应用进行互动，并利用诸如👍/👎或星级评价等功能提供反馈。这一多样化的反馈机制集合起来作为用户对系统性能的体验和感知的宝贵库存。
14.2 问题识别和诊断检查【Issue identification and diagnostic inspection】
- 收集反馈后，团队可以进行全面的分析，以识别可能性能不佳的查询。这涉及检查检索到的资源并仔细审查，以确定性能不佳是否源自检索、生成或底层数据源。
14.3 数据改进策略【Data improvement strategies】
- 一旦识别出问题，特别是那些根源于数据本身的问题，团队就可以战略性地制定计划来提升数据质量。这可能涉及纠正不完整的信息或重组组织不佳的内容。
14.4 评估和测试协议【Evaluation and testing protocols】
-
在实施数据改进后，系统必须经过严格的评估，以前性能不佳的查询。从这些评估中获得的见解可以系统地整合到测试套件中，确保根据真实世界的交互进行持续的审查和完善。
-
通过积极参与用户在这一全面反馈循环中，RAG 系统不仅解决了通过自动化过程识别出的问题，还利用了用户体验的丰富性。
15、可观测性【Observability】
构建 RAG 系统并不意味着任务完成。即使有强大的护栏和用于微调的高质量数据，模型在投入生产后也需要持续监控。
除了延迟和成本等常规指标之外，生成式 AI 应用程序还需要特定的 LLM 可观察性来检测和纠正幻觉、域外查询和链故障等问题。现在让我们来看看 LLM 可观察性的要素。
15.1 提示分析和优化【Prompt analysis and optimization】
- 使用实时生产数据识别与提示相关的问题，并通过强大的评估机制迭代，以识别和解决幻觉等问题。
15.2 LLM应用的可追溯性【Traceability in LLM applications】
- 利用 Langchain 和 LlamaIndex 等常用框架捕获 LLM 跟踪数据，以便调试提示和步骤。
15.3 信息检索增强【Information retrieval enhancement】
- 排除故障并评估RAG参数，以优化对LLM性能至关重要的检索过程
15.4 警报【Alerting】
- 如果系统行为与预期不符，例如错误增加、高延迟和幻觉等，即可收到警报。
- 首先和最重要的是，实时监控对于观察应用程序在生产环境中的性能、行为和整体健康状况至关重要。要密切关注 SLA 符合情况，并设置警报，以及时解决任何偏差。通过分析使用模式和资源消耗来有效跟踪运行LLM应用程序所涉及的成本，以帮助您进行成本优化。
- Galileo's LLM Studio 提供了专门设计的LLM可观测性，以在用户投诉之前主动发出警报并立即采取纠正措施。
- Galileo 的防护指标旨在监控您模型的质量和安全性，涵盖基础、不确定性、真实性、语调、毒性、PII 等方面。这些指标先前用于 评估 和 实验，现在可以无缝集成到监控阶段。
- 此外，您还可以灵活注册自定义指标，以定制监控过程以满足您的具体需求。利用从监控数据中生成的见解和警报，了解需要关注的潜在问题、异常情况或改进领域。这种全面的方法确保您的LLM应用程序在现实场景中高效安全地运行。
16、缓存【Caching】
对于大规模运营的公司来说，成本可能成为障碍。缓存是一种在这种情况下节省资金的好方法。缓存涉及将提示及其对应的响应存储在数据库中，以便以后检索使用。这种战略性缓存机制使大型语言模型应用程序能够通过以下三个显着优势来加快和节省响应成本：
- 增强生产推理【Enhanced production inference】：缓存有助于在生产过程中更快速、更经济地进行推理。通过利用缓存的响应，某些查询可以实现接近于零的延迟，从而简化用户体验。
- 加速开发周期【Accelerated development cycles】：在开发阶段，缓存被证明是一项福音，因为它消除了为相同的提示重复调用 API 的需要。这可以带来更快速、更经济的开发周期。
- 数据存储【Data storage】：一个存储所有提示的综合数据库的存在简化了大型语言模型的微调过程。利用存储的提示-响应对可以简化基于累积数据的模型优化。
如果您想要认真实施缓存，您可以利用 GPTCache 来缓存完全匹配和相似匹配的响应。它提供了诸如缓存命中率、延迟和召回率等值得的指标，这些指标可以洞察缓存的性能，从而实现持续优化以确保最佳效率。
参考GPTCache：https://github.com/zilliztech/GPTCache
17、多租户【Multi-tenancy】
SaaS 软件通常有多个租户，需要平衡简单性和隐私性。对于 RAG 系统的多租户，目标是构建一个不仅能有效地查找信息，而且还能尊重每个用户数据限制的系统。用更简单的术语来说，系统会隔离每个用户的交互，确保系统只会查看和使用针对该用户的相关信息。
构建多租户的一种简单方法是使用元数据。当我们将文档添加到系统时，我们在元数据中包含特定的用户信息。
这样，每个文档都与特定用户相关联。当用户搜索时，系统会使用此元数据进行过滤，只显示与该用户相关的文档。然后，它会进行智能搜索以找到该用户最重要的信息。
这种方法可以防止不同用户之间的私人信息混淆，从而保持每个人的数据安全和私密。
了解如何使用 multi-tenancy using Llamaindex
总结【Conclusion】
构建一个强大且可扩展的企业级 RAG 系统显然需要仔细协调互连的组件。从用户身份验证到输入护栏、查询重写、编码、文档摄取和检索组件（例如向量数据库和生成器），每个步骤都在塑造系统性能方面发挥着关键作用。
参考
