到 2024 年中期，创建一个令人印象深刻和令人兴奋的 AI 演示将变得轻而易举。只需一名强大的开发人员、一些巧妙的快速实验以及对强大基础模型的几次 API 调用，您通常可以在一个下午内构建一个定制的 AI 机器人。添加一个库，例如朗链或者骆驼指数使用 RAG 为您的 LLM 添加一些自定义数据——一个下午的工作可能会变成一个周末的项目。

但投入生产又是另一回事。您需要一个可靠、可观察、可调整且性能良好的大规模系统。超越人为的演示场景并考虑应用程序对代表实际客户行为的更广泛提示的响应至关重要。法学硕士可能需要访问其预训练数据集中通常缺少的丰富领域特定知识语料库。最后，如果您将 AI 应用于准确性至关重要的用例，则必须检测、监控和缓解幻觉。

虽然解决所有这些问题似乎很困难，但通过将基于 RAG 的应用程序分解为各个概念部分，然后采取有针对性的迭代方法根据需要改进每个部分，可以使其变得更易于管理。这篇文章将帮助您做到这一点。在本文中，我们将专注于用于创建 RAG 文档处理管道的技术，而不是检索时下游发生的技术。通过这样做，我们旨在帮助生成式 AI 应用程序开发人员更好地为从原型到生产的旅程做好准备。

现代数据湖：人工智能基础设施的重心

人们常说，在人工智能时代，数据就是你的护城河。为此，构建生产级 RAG 应用程序需要合适的数据基础架构来存储、版本控制、处理、评估和查询构成专有语料库的数据块。由于 MinIO 对人工智能采取数据优先的方法，我们对此类项目的默认初始基础设施建议是设置一个现代数据湖和一个矢量数据库。虽然在此过程中可能需要插入其他辅助工具，但这两个基础设施单元是基础。它们将成为将 RAG 应用程序投入生产后遇到的几乎所有任务的重心。

可以找到基于 MinIO 构建的现代数据湖参考架构这里。另一篇配套论文展示了该架构如何支持所有 AI/ML 工作负载这里。

RAG：文档管道步骤

评估

构建生产级 RAG 应用程序的关键早期步骤是设置评估框架 - 通常简称为评估。没有评估，您将无法可靠地了解系统的运行情况，无法知道哪些组件需要调整，也无法确定您是否取得了真正的进展。此外，评估还可以作为强制函数来澄清您要解决的问题。以下是一些最常见的评估技术：

• 启发式基于代码的评估- 使用各种措施（如输出标记计数、关键字存在/不存在、JSON 有效性等）以编程方式对输出进行评分。这些通常可以使用正则表达式和断言库进行确定性评估，以进行常规单元测试。

  
  

• 基于算法代码的评估- 使用各种众所周知的数据科学指标对输出进行评分。例如，通过将提示重新定义为排名问题，您可以使用推荐系统中的流行评分函数，例如归一化折扣累积增益 (NDCG) 或平均倒数排名 (MRR)。相反，如果可以将提示定义为分类问题，那么准确率、召回率和 F1 分数可能比较合适。最后，您可以使用 BLEU、ROUGE 和语义答案相似度 (SAS) 等指标将语义输出与已知的基本事实进行比较。

  
  

• 基于模型的评估- 使用一个模型对另一个模型的输出进行评分，详情见以法官身份评判法学硕士论文。这种技术越来越受欢迎，而且比人类的规模化成本要低得多。然而，在将项目从原型转移到生产的初始阶段，可靠地实施可能很棘手，因为评估者（在这种情况下是 LLM）通常会受到与底层系统本身类似的限制和偏见。密切关注该领域的研究、工具和最佳实践，因为它们正在快速发展。

  
  

• 人工评估- 要求人类领域专家提供最佳答案通常是黄金标准。虽然这种方法缓慢且昂贵，但不应忽视，因为它对于获得洞察力和构建初始评估数据集非常有价值。如果您想从所执行的工作中获得额外的收益，您可以使用AutoEval 做得对论文用合成的变化来补充人类专家生成的评估。

在决定使用哪种评估技术的同时，请考虑创建一个自定义基准评估数据集 - 通常用于 Hugging Face 排行榜的通用数据集，例如莫尔曼·卢数据集不行。您的自定义评估数据集将包含各种提示及其理想的响应，这些响应是特定于领域的，并且代表了您的实际客户将输入到您的应用程序中的提示类型。理想情况下，有人类专家可以协助创建评估数据集，但如果没有，请考虑自己做。如果您对猜测可能的提示没有信心，只需形成一个操作假设并继续前进，就好像它已经得到验证一样。随着更多数据的出现，您可以不断修改您的假设。

考虑对评估数据集中每一行的输入提示应用约束，以便 LLM 以具体的判断类型回答：二进制、分类、排名、数字或文本。混合判断类型将使您的评估保持合理的多样性并减少输出偏差。在其他条件不变的情况下，评估测试用例越多越好；但是，建议在此阶段注重质量而不是数量。最近关于 LLM 微调的研究利马：少即是多，协调一致论文表明，即使是 1000 行的小型评估数据集也可以显著提高输出质量，前提是它们是真实更广泛人群的代表性样本。对于 RAG 应用程序，我们通过轶事观察到使用由数十到数百行组成的评估数据集可以提高性能。

虽然您可以临时开始手动运行评估，但不要等太久才实施 CI/CD 管道来自动执行评估评分流程。每天或在与源代码存储库和可观察性工具连接的触发器上运行评估通常被认为是 ML-ops 的最佳实践。考虑使用开源 RAG 评估框架，例如拉格或者DeepEval帮助您快速启动并运行。使用数据湖作为包含版本化评估数据集和每次执行评估时生成的各种输出指标的表格的真实来源。这些数据将提供宝贵的见解，供以后在项目中使用，从而实现战略性和高度针对性的改进。

数据提取器

您最初开始原型设计时使用的 RAG 语料库很少足以让您投入生产。您可能需要不断用其他数据扩充语料库，以帮助 LLM 减少幻觉、遗漏和有问题的偏见类型。这通常是通过构建提取器和加载器逐个完成的，这些提取器和加载器将上游数据转换为可以在下游文档管道中进一步处理的格式。

虽然收集过多的数据可能会造成灾难性后果，但发挥创造力和打破常规是至关重要的，因为您需要了解公司可以访问的高质量信息来源。显而易见的可能性包括从存储在公司 OLTP 和数据仓库中的结构化数据中提取见解。公司博客文章、白皮书、已发表的研究和客户支持查询等来源也应考虑，前提是这些来源可以适当匿名化并清除敏感信息。向您的语料库添加少量高质量域内数据对性能的积极影响是不可低估的，因此不要害怕花时间探索、试验和迭代。以下是一些常用于引导高质量域内语料库的技术：

• 文档提取- 专有 PDF、办公文档、演示文稿和 Markdown 文件可以成为丰富的信息来源。存在一个庞大的开源和 SaaS 工具生态系统来提取这些数据。通常，数据提取器是特定于文件类型的（JSON、CSV、docx 等）、基于 OCR 或由机器学习和计算机视觉算法提供支持。从简单开始，然后根据需要添加复杂性。

  
  

• API 提取- 公共和私有 API 可以成为丰富的领域内知识来源。此外，精心设计的基于 JSON 和 XML 的 Web API 已经具有一些内置结构，可以更轻松地在有效负载内执行相关属性的有针对性的提取，同时丢弃任何被认为不相关的内容。存在一个庞大的经济实惠的低代码和无代码 API 连接器生态系统，可帮助您避免为每个要使用的 API 编写自定义 ETL - 如果没有专门的数据工程师团队，这种方法可能难以维护和扩展。

  
  

• Web 抓取工具- 网页被视为具有树状 DOM 结构的半结构化数据。如果您知道要获取哪些信息、信息位于何处以及信息所在的页面布局，那么即使没有详尽的 API，您也可以快速构建抓取工具来使用这些数据。许多脚本库和低代码工具都为 Web 抓取提供了有价值的抽象。

  
  

• 网络爬虫- 网络爬虫可以遍历网页并构建递归 URL 列表。此方法可以与抓取相结合，以根据您的标准扫描、汇总和过滤信息。从更大的范围来看，此技术可用于创建您自己的知识图谱。

  
  

无论使用哪种数据收集技术，都要抵制构建一次性脚本的冲动。相反，应用数据工程最佳实践将提取器部署为可重复且容错的 ETL 管道，将数据放入数据湖内的表中。确保每次运行这些管道时，关键元数据元素（如源 URL 和提取时间）都会被捕获并与每部分内容一起标记。元数据捕获对于下游数据清理、过滤、重复数据删除、调试和归因将非常有价值。

分块

分块将大型文本样本分解为较小的离散部分，以便放入 LLM 的上下文窗口。虽然上下文窗口越来越大（允许在推理过程中填充更多内容块），但分块仍然是在准确率、召回率和计算效率之间取得适当平衡的重要策略。

有效的分块需要选择合适的块大小。较大的块大小往往会保留一段文本的上下文和语义含义，但代价是允许上下文窗口内的总块数更少。相反，较小的块大小将允许将更多离散的内容块塞入 LLM 的上下文窗口。然而，如果没有额外的保护措施，每一段内容在脱离其周围上下文时都有可能降低质量。

除了分块大小之外，您还需要评估各种分块策略和方法。以下是一些可供考虑的标准分块方法：

• 固定大小策略- 在这种方法中，我们只需为内容块选择固定数量的标记，并相应地将内容分解为较小的块。通常，使用此策略时建议相邻块之间有一些重叠，以避免丢失太多上下文。这是最直接的分块策略，通常是在进一步探索更复杂的策略之前的一个很好的起点。

  
  

• 动态大小策略- 此方法使用各种内容特征来确定块的开始和结束位置。一个简单的例子是标点符号分块器，它根据句号和换行符等特定字符的存在来拆分句子。虽然标点符号分块器对于简单的短内容（即推文、字符限制的产品描述等）可能效果不错，但如果用于更长更复杂的内容，它将有明显的缺点。

  
  

• 内容感知策略- 内容感知分块器会根据所提取的内容和元数据的类型进行调整，并使用这些特性来确定每个分块的开始和结束位置。例如，HTML 博客的分块器使用标题标签来划分分块边界。另一个示例是语义分块器，它将每个句子的成对余弦相似度得分与其前面的句子进行比较，以确定上下文何时发生了足够大的变化，从而有必要划分新的分块。

  
  

您的 RAG 应用程序的最佳分块策略需要根据 LLM 的上下文窗口长度、底层文本结构、文本长度和语料库内容的复杂性进行调整。自由地尝试各种分块策略，并在每次更改后运行评估，以更好地了解给定策略的应用程序性能。在数据湖表中对分块内容进行版本控制，并确保每个块都有沿袭信息，以便将其追溯到上游数据提取步骤中的原始内容及其各自的元数据。

丰富

在许多情况下，RAG 期间为检索而索引的内容块在上下文上与您的应用程序在生产中遇到的实际提示不同。例如，如果您正在构建一个 AI 问答机器人，您可能拥有大量专有信息语料库，其中包含大量对客户查询的正确答案。然而，在原始形式下，您的语料库不太可能以问答对的格式预先组织，而这种格式对于基于相似性的嵌入检索来说是理想的。在这个例子中，如果在检索时，我们天真地在语料库中搜索与入站客户问题在语义上相似的原始内容块，我们可能会遇到检索结果集的次优相关性。这是因为我们正在比较上下文不同的项目（即问题与答案）的相似性。幸运的是，解决方案相对简单：我们可以利用 LLM 的强大功能，通过将它们重新语境化为假设问题来丰富我们的可能答案（即原始内容块）。然后，我们将这些假设问题索引到我们的向量数据库中，以便随后进行检索。这种技术称为假设文档嵌入（HyDE） ，说明了使用 LLM 在文档处理管道中丰富数据的强大功能。以下是使用此技术处理一些来自知名squad_v2 数据集：

 System Prompt: Given the provided snippet of text, generate three hypothetical questions that could be asked about it. Each question must be able to be answered using the information within the referenced snippet of text and only that information. Be concise. User Prompt: “At the 52nd Annual Grammy Awards, Beyoncé received ten nominations, including Album of the Year for I Am... Sasha Fierce, Record of the Year for "Halo", and Song of the Year for "Single Ladies (Put a Ring on It)", among others. She tied with Lauryn Hill for most Grammy nominations in a single year by a female artist. In 2010, Beyoncé was featured on Lady Gaga's single "Telephone" and its music video. The song topped the US Pop Songs chart, becoming the sixth number-one for both Beyoncé and Gaga, tying them with Mariah Carey for most number-ones since the Nielsen Top 40 airplay chart launched in 1992. "Telephone" received a Grammy Award nomination for Best Pop Collaboration with Vocals.” Response: Here are some questions that could be asked based on the provided text: * How many nominations did Beyoncé receive at the 52nd Annual Grammy Awards? * For which album was Beyoncé nominated for Album of the Year at the 52nd Annual Grammy Awards? * Which song earned Beyoncé a nomination for Record of the Year at the 52nd Annual Grammy Awards?

如果处理的语料库由长篇和/或主题复杂的内容组成，请考虑进行额外的预处理，以预先总结内容块，从而降低其语义维度。在检索时，您可以查询块摘要的嵌入，然后用非摘要文本替换上下文窗口插入。在对大型、复杂和/或频繁变化的语料库进行 RAG 时，此方法可以提高相关性。

标记化

2024 年的大型语言模型通常是基于转换器的神经网络，它们本身并不理解书面文字。传入的原始文本被转换为标记，然后是针对矩阵乘法运算优化的高维嵌入向量。此传入过程通常称为编码。反向的传出过程称为解码。许多 LLM 只能使用与训练它们时相同的标记化方案进行推理。因此，了解所选标记化策略的基础知识至关重要，因为它可能对性能产生许多微妙的影响。

尽管存在简单的字符和单词级标记方案，但在撰写本文时，几乎所有最先进的 LLM 都使用子词标记器。因此，我们在这里只关注该类别的标记器。

子词标记器以递归方式将单词拆分成更小的单元。这样，它们就可以理解词汇表之外的单词，而不会过度扩大词汇量 - 这是训练性能和 LLM 推广到未见过的文本的能力的关键考虑因素。

目前使用的一种流行的子词标记方法是字节对编码 (BPE)。从高层次上讲，BPE 算法的工作原理如下：

• 将单词拆分为子词单元的标记并将其添加到词汇表中。每个标记代表一个子词，该子词由训练语料库中常见相邻字符模式的相对频率决定。

  
  

• 用代表该对的单个标记替换上述步骤中的常见标记对，并将其添加到词汇表中。

  
  

• 递归重复上述步骤。

  
  

BPE 标记化通常是开始使用 RAG 应用程序的绝佳起点，因为它适用于许多用例。但是，假设您有大量高度专业化的领域语言，而这些语言在您选择的模型使用的预训练语料库的词汇表中没有得到很好的体现。在这种情况下，请考虑研究替代的标记化方法 - 或探索微调和低秩适应，这超出了本文的范围。上述词汇受限问题可能表现为在为医学、法律或晦涩难懂的编程语言等专业领域构建的应用程序中性能不佳。更具体地说，它将在包含高度专业化的语言/行话的提示中普遍存在。使用存储在数据湖中的 eval 数据集根据需要尝试不同的标记化方案及其在各种模型中的各自性能。请记住，标记器、嵌入和语言模型通常是紧密耦合的 - 因此更改一个可能需要更改其他。

结论

建立在 MinIO 对象存储之上的现代数据湖 - 为自信地将基于 RAG 的应用程序投入生产提供了基础架构。有了它，您可以创建评估和特定于域的评估数据集，这些数据集可以在数据湖表中存储和版本控制。使用这些评估，反复评估并逐步改进 RAG 应用程序文档管道的每个组件 - 提取器、分块器、丰富器和标记器 - 尽可能多地构建生产级文档处理管道。

如果您有任何疑问，请通过以下方式联系我们松弛！