你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

准备

Azure AI 服务
Azure AI 搜索
Azure OpenAI 服务
Azure 机器学习

检索扩充生成 (RAG) 开发和试验的第一阶段是准备。 在这一阶段,首先要定义解决方案的业务领域。 一旦确定了领域,就可以开始同时执行文档分析、收集文档和收集与该领域相关的示例问题。 由于这些步骤是相互关联,因此它们价格并行进行。 文档分析可帮助你确定应收集的具体测试文档和测试查询。 这些问题进一步相互关联,因为必须能从文档内容中找到答案,并且文档要必须能够回答相关问题。

本文是一系列文章的其中一篇。 阅读简介

确定解决方案领域

此过程的第一步是明确定义解决方案或用例的业务需求。 这些要求有助于确定解决方案旨在解决哪类问题,以及哪些源数据或文档有助于解决这些问题。 在后期阶段,解决方案领域有助于为嵌入模型战略提供信息。

文档分析

文档分析的目标是收集有关文档库的足够信息,以帮助你了解:

  • 文档的不同分类 - 例如,是否具有产品规格、季度报告、汽车保险合同、健康保险合同等。
  • 不同的文档类型 - 例如,是否有 PDF、Markdown 文件、HTML 文件、DOCX 文件等。
  • 安全约束 - 例如,文档是可公开访问还是需要身份验证和授权才能访问它们
  • 文档的结构 - 例如,文档长度、主题分隔符以及它们是否具有上下文相关的图像或表格数据

以下部分讨论此信息如何帮助你了解加载和分块策略。

文档分类

你需要了解文档的不同分类,以帮助确定所需的测试文档数。 分析的这一部分不仅应该告诉你保险或财务等高级分类,还应告知子分类,如医疗保险与汽车保险文件。 还需要了解子分类是否具有不同的结构或内容。

目标是了解你拥有的所有不同文档变体。 这种理解有助于确定所需测试文档的数量和细分。 你不希望在试验中过度或低估特定文档分类。

文档类型

了解语料库中的不同文件格式有助于你确定测试文档的数量和细目分类。 例如,如果你有用于季度报告的 PDF 和 Office Open XML 文档类型,则需要针对每种文档类型进行文档测试。 了解文档类型还有助于了解加载和分块文档的技术要求,例如适合处理这些文件格式的特定库。

安全约束

了解安全约束对于确定加载和分块策略至关重要。 例如,你需要确定部分或全部文档是否需要身份验证、授权或网络可见性。 如果文档位于安全范围内,请确保你的代码可以访问它们,或者实施一个流程将文档安全地复制到处理代码可访问的位置。

请注意,文档有时会引用对文档上下文很重要的多媒体,例如图像或音频。 该媒体也可能会受到与文档本身类似的访问控制。 如果该媒体需要身份验证或网络查看,则你再次需要确保代码可以访问该媒体,或者你有一个可以访问并可以复制该内容的先前流程。

如果工作负荷要求不同的用户只能访问不同的文档或文档段,请确保了解如何在分块解决方案中保留这些访问权限。

文档结构

你需要了解文档的结构,包括文档的布局方式和文档中的内容类型。 了解文档的结构和内容有助于你做出以下决定:

  • 文档是否需要预处理来清理干扰、提取媒体、重新设置格式或批注要以忽略的项
  • 要忽略或排除文档中的哪些内容
  • 要在文档中捕获的内容
  • 如何对文档进行分块
  • 如何处理图像、表、图表和其他嵌入媒体

以下是一些可用于帮助你做出这些决定的分类问题。

有关可考虑忽略的常见项的问题

某些结构元素可能不会向文档添加含义,因此在分块时可以安全地忽略。 在某些情况下,这些元素可以向索引添加有价值的上下文和帮助,但并非所有内容都有助于进行相关性查询。 下面是一些有关常见文档功能的问题,你需要评估这些功能以查看它们是否添加相关性或应被忽略。

  • 文档是否包含目录?
  • 有页眉和页脚吗?
  • 是否有版权或免责声明?
  • 是否有脚注或尾注?
  • 是否有水印?
  • 是否有批注或注释?

有助于通知预处理和分块策略的问题

以下有关文档结构的问题提供了见解,可帮助你了解是否需要预处理文档,以便更轻松地处理文档,并帮助告知分块策略。

  • 是否存在多列数据或多列段落? 你不希望将多列内容当作单列内容来解析。
  • 文档的结构如何? 例如,HTML 文件有时使用表作为其布局,这些布局需要与嵌入式表格数据区分开来。
  • 有多少段落? 段落有多长? 段落的长度是否大致相同?
  • 文档中有哪些语言、语言变体或方言?
  • 文档是否包含 Unicode 字符?
  • 数字是什么格式? 它们使用的是逗号还是小数? 它们是否一致?
  • 文档中哪些内容是统一的,哪些不统一?
  • 是否存在可以提取语义含义的标头结构?
  • 是否有项目符号或有意义的缩进?

有关图像的问题

了解文档中的图像有助于确定图像处理策略。 你需要了解诸如图像类型、图像是否有足够的分辨率来处理以及图像是否包含所有所需信息等信息。 以下问题可帮助你了解图像处理要求。

  • 文档是否包含图像?
  • 图像的分辨率是多少?
  • 图片中是否嵌入了文字?
  • 是否有没有增加价值的抽象图像? 例如,图标可能不会添加任何语义值。 为图像添加说明实际上可能有害,因为图标视觉对象通常与文档内容无关。
  • 图像与周围文本之间的关系是什么? 在确定图像是具有独立内容,还是将图像传递给大型语言模型以获取文本表示形式时,你应使用该图像周围的上下文。 描述文字是周围文本的一个示例,该文本可能不包含在图像中有价值的上下文。
  • 图像是否有丰富的文本表示形式,例如辅助功能说明?

有关表、图表和其他丰富内容的问题

了解表、图表和其他媒体中封装的信息有助于了解要处理什么信息以及如何处理这些信息。 以下问题可帮助你了解表、图表和其他媒体处理要求。

  • 文档中是否有数字图表?
  • 文档是否包含表格?
    • 是复杂表格(嵌套表)还是简单表格?
    • 表格是否有描述文字?
    • 表的长度是多少? 长表可能需要在区块中重复标头。
  • 是否有其他类型的嵌入式媒体,如视频或音频?
  • 文档中是否有数学公式/科学表示法?

收集有代表性的测试文档

在这一步中,要收集的文档是在生产解决方案中使用的文档的最佳代表。 文档必须针对已定义的用例,并能回答在问题收集并行阶段收集到的问题。

注意事项

在评估潜在的代表性测试文档时要考虑这些方面:

  • 针对性 - 文档必须满足对话应用程序的业务要求。 例如,如果正在构建一个聊天机器人,其任务是帮助客户执行银行业务,则文档就应该符合这一要求,例如显示如何开户和销户的文档。 这些文档必须能够解决在并行步骤中收集的测试问题。 如果文档中没有与问题相关的信息,则无法做出有效的答复。
  • 代表性 - 文档应能代表解决方案将使用的不同类型文档。 例如,汽车保险文档就不同于医疗保险或人寿保险文档。 假设使用案例要求解决方案支持所有三种类型,而您只有两份汽车保险文件。 你的解决方案对健康保险和人寿保险效果都不佳。 每种变体至少要有两个。
  • 实体文档质量 - 文档需要保持可用状态。 例如,扫描图像可能无法提取到可用信息。
  • 文档内容质量 - 文档必须具有较高的内容质量。 不应出现拼写错误或语法错误。 如果为大型语言模型提供的内容质量不佳,那么它们的表现也就不会太好。

这一步骤的成功要素是要有定性的自信,即对特定领域的测试文档有很好的代表性。

测试文档指南

  • 首先选择真实文档而不是合成文档。 真实文档必须完成清理程序,以去除个人身份信息 (PII)。
  • 为了确保您能够处理各种场景(包括预测的未来场景),请考虑有选择性地使用合成数据扩充您的文档。
    • 如果必须使用合成数据,请尽量使其接近真实数据。
  • 确保文档能够解决正在收集的问题。
  • 每个文档变体至少应有两个文档。
  • 可以使用大型语言模型或其他工具来帮助评估文档质量。

收集测试查询

在这一步中,要收集测试查询,用来评估分块、搜索解决方案和提示工程。 在收集代表性文档的过程中,要同步进行这项工作,因为不仅要收集查询,还要收集代表性文档是如何解决查询的。 有了示例查询,再加上示例文档中涉及这些查询的部分,就可以在尝试不同策略和方法时,对 RAG 解决方案的每个阶段进行评估。

收集测试查询输出

此阶段的输出包括收集代表性测试查询步骤和收集代表性测试文档步骤的内容。 输出是一个包含以下数据的集合:

  • 查询 - 问题,表示合法用户的潜在提示。
  • 上下文 - 文档中涉及查询的所有实际文本的集合。 对于每一段上下文,都应包括页面和实际文本。
  • 答案 - 对查询的有效响应。 响应可以是可以直接来自文档的内容,也可以是根据一个或多个上下文重新表述。

创建合成查询

对于特定领域的主题专家 (SME) 来说,为用例准备一份全面的问题清单往往是一项挑战。 战胜这一挑战的办法之一是根据收集到的代表性测试文档来生成合成问题。 以下是从代表性文档中生成合成问题的实际方法:

  1. 文档分块 - 将文档分解为若干区块。 这一分块步骤并不是将分块策略用于整体解决方案。 这是用于生成综合查询的一次性步骤。 如果文档数量合理,分块工作可以手动完成。

  2. 为每个区块生成查询 - 为每个语块手动或使用大型语言模型生成查询。 在使用大型语言模型时,我们通常会首先为每个区块生成两个查询。 大型语言模型也可用于创建答案。 以下示例演示了为区块生成问题和答案的提示。

    Please read the following CONTEXT and generate two question and answer json objects in an array based on the CONTEXT provided. The questions should require deep reading comprehension, logical inference, deduction, and connecting ideas across the text. Avoid simplistic retrieval or pattern matching questions. Instead, focus on questions that test the ability to reason about the text in complex ways, draw subtle conclusions, and combine multiple pieces of information to arrive at an answer. Ensure that the questions are relevant, specific, and cover the key points of the CONTEXT.  Provide concise answers to each question, directly quoting the text from provided context. Provide the array output in strict JSON format as shown in output format. Ensure that the generated JSON is 100 percent structurally correct, with proper nesting, comma placement, and quotation marks. There should not be any comma after last element in the array.
    
    Output format:
    [
      {
        "question": "Question 1",
        "answer": "Answer 1"
      },
      {
        "question": "Question 2",
        "answer": "Answer 2"
      }
    ]
    
    CONTEXT:
    
  3. 验证输出 - 验证问题是否与用例相关,以及答案是否解决了问题。 此验证应由 SME 来执行。

未解决的查询

重要的是,要收集文档未能解决的查询和已解决的查询。 在测试解决方案时,尤其是测试大型语言模型时,需要确定解决方案应如何响应其没有足够上下文来回答的查询。 响应无法解决的查询的方法包括:

  • 回答说不知道
  • 回答说不知道,并提供一个链接,让用户能找到更多信息

收集嵌入式媒体的测试查询

与文本一样,你应该收集多种问题,这些问题涉及使用嵌入式媒体来生成高度相关的答案。 如果您有带有图形、表格、屏幕截图的图像,请确保您的问题涵盖所有用例。 如果您在文档分析部分的图像部分中确定图像之前或之后的文本是回答某些问题所必需的,请确保您的测试查询中包含这些问题。

收集测试查询指南

  • 确定是否有一个包含真实客户问题的系统可供使用。 例如,如果要构建一个聊天机器人来回答客户的问题,则可以使用服务台、常见问题或票证系统中的客户问题。
  • 用例的客户或 SME 应充当质量把关人,确定收集的文档、相关的测试查询以及文档中的查询答案是否全面、具有代表性且正确无误。
  • 应定期审查问题和答案的正文,以确保它们继续准确反映源文档。

后续步骤