你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
为 Azure 上的 AI 工作负载提供数据设计
对于 AI 应用程序，设计良好的框架方法必须满足操作性、成本和安全性等非功能要求，并遵循 Azure 良好架构框架支柱的核心原则。 它还应考虑功能要求，例如数据引入、准备和验证。
你选择的 AI 模型会影响后续数据设计决策。 本文讨论需要扩充以增强结果相关性的基础模型的关键体系结构注意事项。 这些模型通常是生成模型。
生成 AI 模型已预生成或预先训练，使你能够立即使用它们，而无需进行修改。 但是，现用的模型通常不满足特定的工作负荷要求。 为了解决此问题，模型通过特定于上下文的数据进行扩充，以提高其性能。 例如，可以在各种用例中使用 GPT 模型。 这些应用程序包括从文档检索信息、提供 IT 支持人员以及汇总复杂信息。 若要使用基础模型来满足特定需求，请务必了解这些注意事项。
重要
数据设计是基于统计实验的迭代过程。 生成式 AI 应用程序将查询发送到包含提示和上下文数据的模型。 若要优化数据设计，应同时迭代提示数据和上下文数据。 迭代过程应包括预处理、选择嵌入和分块。 这些步骤有助于创建适合索引的数据。 有关详细信息，请参阅 设计和开发检索扩充生成 （RAG） 解决方案。
在试验和迭代时，请记住消耗用例。 根据实际查询模式调整数据设计。 通过优化和测试确定可接受的内容。
在解决方案中，可以使用生成式 AI 和歧视 AI 模型的组合来满足工作负荷要求。 有关训练数据的详细信息，请参阅 训练数据设计。
建议
下面是本文中提供的建议摘要。
| 建议 | 说明 |
|---|---|
| 预测用户查询。 | 了解与源数据相关的预期问题类型及其对新鲜度的期望。 这种理解有助于设计数据管道和索引，以提供相关的地面数据。 |
| 将数据外部化到搜索索引。 | 使用搜索索引，而不是直接从源系统查询。 根据工作负荷要求评估不同的索引技术。 创建功能矩阵来评估最适合你的需求。 考虑强大的搜索索引技术，如 Elasticsearch 或 AI 搜索。 ▪ 索引 |
| 制定引入策略。 | 制定涵盖数据引入和预处理的综合索引管理策略。 通过解决不一致和重复以及标准化到通用架构来删除干扰或无关的数据。 将源格式和类型转换为有助于查询和分析的数据类型。 ▪ 数据准备 ▪ 数据卷重新复制 |
| 设计索引以实现最大相关性。 | 启用特定字段上的筛选、排序和元数据处理等功能以提高查询效率。 例如，仅当想要搜索字段时，才可将字段标记为可搜索。 为了避免不必要的存储成本，请不要让每个字段在没有特定的用例的情况下进行检索。 ▪ 架构设计 ▪ 索引功能 ▪ 高效的查询 |
| 更新索引以防止推断过时的数据。 | 更新索引时，请考虑采用并行部署策略进行维护。 重新生成索引可确保处理删除和更新，因为索引将成为新的数据集。 此方法允许在使索引生效之前彻底测试数据。 对索引进行更改时，请使用代码更新协调架构修改。 这种做法可确保无缝转换。 ▪ 索引维护 |
数据类型
可以通过在推理期间使用上下文数据来增强生成 AI 模型，或通过微调过程进一步优化它们。 这两种方法都需要补充数据，以便为模型提供更多上下文。 该模型使用该上下文来回答用户查询，并根据预期形成答案。 通常，使用以下数据类型：
源数据 是生产中的现有数据。 此数据可以结构化，例如数据库中的数据，或半结构化的数据（如 JSON 文件）。 它也可以是非结构化的，如文档、图像和音频文件。
地面数据来自源数据 ，其中包含有关模型初始训练数据中未涵盖的主题的信息。 地面数据与用户查询相结合，形成在特定推理调用上下文中发送到大型语言模型的提示。 可以在推理调用中包含的其他数据是系统提示、一次性或几枪示例，以及上下文数据（如以前的交互）。
此数据应易于搜索并快速检索。 由于此要求，应将数据存储在针对搜索进行优化的索引中。 当用户等待答案时，实时访问此索引。 如果没有此数据，模型可能会生成不正确的结果，或者不适用于用户特别寻求的结果。
微调数据 是用于影响模型的信息，以便它可以适应将来推理请求的特定任务、域或响应样式。 例如，如果模型应提供特定语法样式的答案，该样式指南将用作微调数据。
用户数据 包括用户在与应用程序交互期间提供的信息。 与生成模型交互时，会发生有状态交互。 这些模型缺少固有内存，并将每个交互视为原子。
当你管理有状态交互（也称为聊天应用程序中的 TURN 数据 ）时，必须尽可能短地存储数据。 理想情况下，应在会话结束后销毁此数据。 但是，可能需要保留某些数据（例如原始问题或模型响应）超出会话持续时间的操作或符合性原因。 如果可能，请避免将此数据存储在会话之后。
索引
数据设计的核心包括有效地存储和管理基础数据。 此方法可确保可以扩充数据，以实现最高级别的相关性。
简单的 AI 策略可能涉及查询每个用户交互的源数据。 但是，由于直接数据源交互的成本高和复杂性，此方法并不可行。 相反，应在经过优化的索引中将源数据重新调整为副本，以便进行搜索和检索。 此方法的目标是改进模型的理解及其生成相关响应的能力。
请考虑一个银行工作负荷，用于存储与数据存储中用户帐户和首选项和财务交易相关的详细信息。 在使用 RAG 模式的生成 AI 方案中，使用上下文创建和索引数据，以便模型可以提供相关的响应。 例如，通过在推理过程中提供有关用户事务的相关数据，模型可以回答与上一季度用户支出模式相关的问题。
专用索引技术
考虑将基础数据外部化到搜索索引。 使用此方法，而不是直接从源系统查询。
使用搜索索引有好处。 可以根据预期的查询对数据的副本进行建模和转换。 对主源的直接查询存在问题，因为可能无法访问源数据。 索引可确保只要认为数据与应用程序相关，数据就保持可用。 还可以避免给源数据源系统造成压力。 此策略可确保与 AI 相关的查询不会影响其主要用例。
某些技术选项具有自索引功能。 索引可以联系数据源并合并其数据。 对于此选项，网络注意事项是关键。 如果索引需要连接到数据库，则可能存在网络延迟和可靠性等问题。
导入数据需要花费初始成本。 数据位于索引中后，无需再次移动数据，除非有更改或更新。 随着时间的推移，数据管理是索引设计的关键方面。 有关详细信息，请参阅 索引维护。
默认索引或自定义索引
某些技术支持自动为数据生成默认索引。 此索引是在使用最小输入的数据引入时生成的。 索引具有现用的功能。 对于概念证明和某些生产方案，默认索引可能是可以接受的。
某些方案可能要求你具有自定义索引架构，以便根据特定的工作负荷要求提高相关性。 这些要求决定了如何设计架构、启用索引功能以及包括相关元数据。
架构设计
可以将索引视为组织和优化数据以供检索的结构。 更具体地说，它们在表的文档和字段中组织数据。 请考虑以下几点：
索引拓扑。 评估是将单个索引中的所有数据并置还是分布在多个索引之间。 此决策显著影响文档之间的查询性能、索引维护、查询简单性和不同字段配置（或架构）。
例如，考虑请求特定语言内容的用户查询。 最简单的数据设计选择可能是将所有语言翻译为一种语言，并将其存储在单个索引中。 或者，数据可以存储在单个索引中的所有语言中。 此选项会导致每个语言的多个文档。 索引的筛选功能可用于将结果限制为所需语言。 或者，每个索引都可以在查询中按预期包含给定语言的翻译版本。
在某些情况下，可能需要多个搜索索引。 通过此方法，可以独立优化每个索引，以实现搜索查询的最大相关性。 例如，HR 员工手册和产品维护手册服务于不同的目的和受众。 通过单独为它们编制索引，可以针对每个查询定制架构和搜索查询，从而提高用户体验。 此方法可能非常复杂，需要业务流程协调程序来促进对每个索引的调用。 业务流程组件在 Azure 上的 AI 工作负荷的应用程序设计中进行了介绍。
注意
两个拓扑和数据分段策略之间的选择取决于工作负荷要求、用例和用户期望。
执行跨索引查询可能很有挑战性，可能会影响搜索相关性。 在最坏的情况下，可能会手动筛选结果，确定哪些符合条件。 此过程引入了延迟并增加了复杂性。 相比之下，单个索引方法更简单、更简单。 可以使用索引功能（如筛选）来改进相关性。
在某些情况下，合规性注意事项会导致需要单独的索引。 例如，如果业务需求要求在欧美之间隔离数据，则多个索引可能不可避免。
文档设计。 使数据设计与预期的用户查询保持一致，以优化相关性。 考虑每个文档应如何为查询提供服务。 对于搜索索引，请确定相关文档的优先级，并将结果细化为一个简明的集，其中包含相关信息。
字段设计。 配置索引字段以支持搜索性能和相关性。 索引字段应映射到要使可搜索、可检索、可筛选和可排序的文档属性。 它们包括嵌入、ID 或任何其他可提升搜索的数据。
索引功能
配置搜索索引字段以返回最相关的文档集。 决策取决于搜索索引技术和工作负荷要求支持的功能。
筛选、搜索和排序选项。 请考虑这些选项，因为它们与扩充用例直接相关。 例如， 可筛选结果 根据查询中提供的值确定 true 或 false，并返回相关文档。 为了 便于搜索，该属性指示搜索查询是否可以引用字段。 例如，可以检查文本字段是否包含特定文本，或者它是否在数学上与另一个向量相关。 可以选择将相对权重分配给该字段作为搜索查询的一部分。 还可以使结果集 可排序，按相关性列出结果。
权衡。 启用索引字段的功能会增加空间需求，从而影响成本。 仅添加要使用的功能。Metadata。 索引通常具有与索引字段关联的元数据。 元数据通过提供有关它的相关详细信息来帮助我们了解和管理数据。 设计索引时，请考虑元数据是可检索还是仅用于相关性确定。 该决策会影响计算成本，因为基础索引过程不同。 过多的元数据可能会不必要地增加索引的大小。
索引有许多技术选择。 许多共享类似的特征，例如前面列出的特征。 某些索引可能具有额外的功能，例如在编制索引期间处理文本和语言分析。 若要使文本更适合索引和搜索，请将文本拆分为标记，将其转换为小写，或删除非索引字。
高效查询
在生成式 AI 应用程序中使用地面数据来提高对用户查询的响应的准确性和相关性。 请考虑提前进行用户查询。 了解可以问什么问题，谁问他们，以及他们被问的频率。 此信息可帮助应用程序表单上下文并了解可能相关的结果。
典型的搜索类型包括：
矢量查询 根据高维空间中的向量表示形式或数据点搜索类似的项。
关键字搜索 在文本文档的整个内容中搜索。 它为大量文本数据编制索引和查询，通常用于搜索引擎、数据库和文档管理系统。
语义排名 根据搜索结果的语义相关性对搜索结果进行重新排序，从而提升搜索结果的相关性，从而将与语义上最相关的匹配项提升到列表顶部。
混合搜索 结合了不同的搜索类型，如矢量搜索、全文搜索和语义排名，以进一步提高搜索结果的相关性。
为了进一步提高模型性能，请合并搜索类型。
数据的存储和处理方式会影响查询效率。 每次将数据添加到索引时，都需要计算周期才能编制索引。 如果对同一计算资源执行索引和响应查询，则可能存在争用。 理想情况下，索引应侧重于有效回答查询和查找相关文档而不是过度编制索引的主要目标。
成本和性能是索引设计的关键驱动因素。 创建卷影副本等技术可以加快查询速度。 但是，数据重复通过索引进行，这会产生成本。
对于数据存储的技术选择，搜索索引（如 Elasticsearch 或 AI 搜索）提供强大的搜索功能，包括矢量化和基于相关性的搜索。 或者，考虑支持你拥有的数据类型和所需查询类型的数据库选项，因为它们已针对查询进行优化。 归根结底，它与选项和在团队中构建新技能集的投资提供的功能有关。
数据准备
地面数据基于现有数据，需要进行适合语义查询。 在索引中查找相关文档的某些查询可以是文本匹配。 其他查询需要模糊匹配。
在上下文数据准备好支持对模型的推理请求之前，有一个前期预处理步骤，旨在清理、转换和构建数据。 目标是降低干扰和偏差，高效搜索，并最大程度地提高索引搜索的相关性。 预处理的选择工具或逻辑取决于工作负荷团队，但有一些广泛的注意事项。
数据卷重新复制
数据卷重新复制涉及通过扩展或缩小数据范围来创建紧密索引来调整数据范围，以便增加相关性。 查询效率是另一个重大问题。 存储不必要的数据会对这两个目标产生负面影响。 例如，考虑用户的位置数据。 如果仅与城市部分相关，请仅存储城市文本而不是代表地址的全文进行优化。
下面是一些广泛的注意事项。
数据消除。 仅保留对产品功能至关重要的内容，放弃不必要的详细信息。 下面是一些常用示例。
定性消除。 从广泛范围过渡到更窄的相对数据的方法之一是选择仅选择为相关源数据编制索引，从而消除低质量数据。 挑战在于以编程方式识别与 AI 方案无关的内容。 虽然内容可能对其他意向（例如审核或完整性）有用，但在 AI 工作负载中包括内容可能会降低相关性。 标记此类内容的一种方法是在索引填充时间使用元数据（如果必须将内容添加到索引中）。
敏感数据。 将数据从源数据复制到索引也可能带来敏感信息。 尊重在源应用的数据分类标签，并保持对此数据集的敏感度级别相同。 处理具有个人信息的数据时，请勿存储个人数据，除非需要它来响应查询。 例如，在为电子邮件编制索引时应用数据分类。 如果电子邮件标记为敏感，请避免将其存储在常规敏感度数据存储中。
规范化和标准化文本。 解决拼写错误和标准化文本对于基于关键字的索引至关重要。 潜在的用例是翻译，尤其是在处理多语言内容时。
嵌入也需要这种类型的预处理，这使你可以根据字词的上下文和重要性来比较字词。 但是，单词区分大小写时会出现一个质询。 上下文很重要，而且可能存在细微差别，例如形容词“公民”与适当的名词“（本田）公民之间的语义差异”。
数据添加。 扩充上下文通常依赖于源数据中通常不存在的元数据。 例如，请考虑文本片段。 循环中的人员或 AI 会创建可以使用代码片段上下文回答的相关问题。 将这些问题与地面数据一起存储时，可以将用户查询与生成的查询进行比较，以评估文档相关性。 将此新数据与地面数据并置是扩充分块数据的强大方法。
另一个用例是在分析非结构化数据时找到的实体。 可以将这些实体添加到索引中，并用于搜索和筛选外部系统，或者用于执行复杂的计算。 例如，如果我们标识公司名称，我们可能会从外部数据库查找其行业或其他相关信息，并将其添加到我们的索引。
请考虑维护数据世系。 AI 工作负载跟踪数据源非常重要，因为当系统将各种组件聚合到一个索引中时，信息可能会丢失。 此信息可能永远不会向用户公开，但有关数据来源的信息对于内部数据管理团队至关重要。 此元数据不一定用于模型。 它有助于保持透明度和问责制。
权衡。 一方面，添加新数据会增加在数据集中查找相关性的可能性。 然而，这种好处是代价的。 具体而言，处理和管理该字段所需的计算资源。 收集和存储数据所花费的时间可能很大。 请注意，使用不必要的字段进行重载可能会给资源造成压力。处理文本数据。 考虑同义词、词干和语义邻近度等技术来增强相关性。 如果可能，将这些技术委托给工具。 某些技术（如 Elasticsearch 或 AI 搜索）提供在创建索引期间预处理数据的此类功能。
数据类型平滑
数据存储中的索引字段是用于特定用途的数据类型。 数值字段有助于高效查询，文本字段允许基于文本的搜索，布尔字段处理二进制信息。
源数据通常存在于各种类型的数据中，例如文本、图像和表，以及处理这些数据可能比较复杂。 可能需要提取键值对、识别语义分块的节标题、识别特定标识符等。
例如，如果源数据包含图像，则它们本身不可搜索。 它们需要转换为矢量表示形式，以实现高效的语义搜索和比较。 如果相关性与这些格式背后的数据相关联，请投资提取数据。 将源数据类型转换为有助于查询和分析的功能数据类型。
分块和嵌入
地面数据通常包含大量信息，但模型只能标记一定数量。 分块是一个重要的数据设计策略，因为它涉及将文档划分为可以单独处理和编制索引的较小部分。 此策略允许高效搜索和检索，尽管令牌存在限制。 检查所选大型语言模型可以处理的最大令牌数。 区块不应超过该限制。
有许多用于实现分块的技术。 有关详细信息，请参阅 分块方法。
嵌入也是启用矢量搜索功能的另一种设计策略。 嵌入是基于基础数据的 AI 模型生成的对象的数学表示形式。 它们存储在索引中，并添加更多上下文，以帮助复杂的查询生成具有更好相关性的结果。 有关详细信息，请参阅生成嵌入。
索引维护
一段时间内的维护是索引设计的关键方面。 对于静态数据，文档保持不变，索引维护非常简单。 但是，大多数索引都是动态的。 随着时间的推移，可能会添加新数据，索引架构可能需要新字段。 相反，如果某些数据和字段不再相关，可能需要将其删除。 索引器的常用技术选项具有自动处理更新的功能。 有关建议的索引特征的信息，请参阅 搜索索引的注意事项。
维护条件
功能更新。 如果应用程序功能发生更改，可能需要更新索引。 当提出新问题时，会出现这种情况。 若要适应这些更改，可能需要向索引添加新字段，或修改现有字段上的筛选、搜索或文本处理选项。
数据删除。 数据删除具有挑战性，因为你需要分析可用和缺失的数据，以确定无关紧要的内容。 若要从索引中排除过时的内容，请考虑使用阻止搜索引擎为特定页面或内容编制索引的元数据。 此外，选择存储选项时，请选择支持高效删除的技术。 例如，Blob 存储支持软删除。 如果使用 AI 搜索和从存储加载文档，Blob 存储可以检测已删除的文档并删除相应的条目。 此方法并不理想，但在重新编制索引成本高昂时，由于索引大小较大，因此有必要这样做。
被遗忘的权利概念是指个人有权将其个人数据从联机平台或数据库中删除。 确保已制定策略，以便在用于训练时删除个人数据。 可以通过重新编制数据集索引来解决此要求。 如果数据从事务数据库中删除，后续索引更新将反映这些更改。
保持兼容性。 应用程序通常需要特定的数据结构，任何偏差都可能会中断其功能。 例如，如果删除了某个字段，并且应用程序请求该字段，则可能会发生失败条件。 与传统数据库一样，请采用索引的向前兼容性思维模式，并保持一定程度的严格性。 对索引进行更改（如添加或删除字段）时，使用代码更新协调架构更改。
权衡。 针对索引添加、更新和删除操作的成本很高。 考虑更新的频率以及基于数据存储大小和效率的性能成本。 在索引中保留过时的文档会产生存储、维护和查询成本。
部署策略
部署策略。 有两个主要策略可用于更新索引。
并行部署。 在此方法中，具有更新的新索引与现有索引一起存在。 测试新索引并完全运行后，查询将切换为使用更新的索引。 应用程序仍不知道此开关，因为它仅与新索引交互。 如果在将新索引部署到生产用途后发现其他问题，则可以还原到旧索引。 此方法可最大程度地减少停机时间，并确保持续可用性。
当重新生成索引的成本合理且可以在合理的时间范围内完成时，并行更新效果良好。 一般情况下，努力使索引尽可能高效，因为较大的索引消耗更多的资源。 定期监视和维护索引，以避免不必要的增长。
提示
执行资源密集型数据预处理任务（如实体识别、查找和计算）时，请考虑保存结果的副本。 此方法可确保在需要重新生成索引时，可以避免重做所有计算。 由于删除或更新，某些计算可能不再适用，但许多计算仍将相关。
就地更新部署。 此方法直接修改现有索引。 节省重复成本可能会带来好处，但也会带来风险，因为潜在的停机和资源密集型操作。 如果索引很大，并且从头开始重新生成索引超过了所需的更新频率，则可以考虑使用就地更新。 但是，这种方法具有挑战性，并且存在违反服务级别目标（SLO）的风险。
权衡。 根据部署添加、更新和删除的就地更新，评估并行部署索引的成本。 在大多数情况下，应使用并排更新，而不是就地更新。 重新生成索引时，该过程会有效地处理删除和更新，因为它会创建一个全新的数据集。 此策略提供了测试数据的机会。 尽管并行部署暂时复制数据并会产生额外的成本，但测试和性能评估的优点通常证明此存储要求是正当的。 在使索引生效之前，请检查数据以确保它符合预期。计划更新。 可以定期刷新地面数据，而不是与数据源保持连续的实时通信。 此方法可确保数据通过计划的更新保持相关，从而无需持续交互。
紧急更新。 可能发生意外情况，例如意外的数据无意中泄漏到搜索索引中。 如果出现此问题，可能需要立即采取措施，例如删除特定文档或调整索引中的数据。 无论选择的部署策略如何，如并行更新或就地更新，始终规划紧急操作的可能性。
自我更新索引。 如果索引技术支持自动更新索引以使其与外部数据源保持同步，则它可能无法自动处理数据中的更改。 数据更改包括添加或删除，无需手动干预。 请记住，每个更改都会触发索引中的操作，该操作会消耗资源。 索引可能会对查询保持响应，但在更新过程中处理查询的容量可能会降低。
新鲜度操作
测量源数据创建或修改之间的时间范围及其作为指标添加到索引之间的时间范围，并针对 SLO 对其进行跟踪。 此指示器驱动有关更新数据管道设计的数据决策，以确保在需要时可在索引中使用数据。 索引应仅像需要一样新鲜。
若要保持新鲜度，可以完全重新生成索引，也可以以增量方式更新索引，使其与原始数据源保持同步。 这两种方法都确保索引保持最新且准确。
优化模型的前期投资可能比实现 RAG 模式、提示工程和数据扩充方法的成本更低。