- 概述
- Document Understanding 流程
- 快速入门教程
- 框架组件
- ML 包
- 概述
- Document Understanding - ML 包
- DocumentClassifier - ML 包
- 具有 OCR 功能的 ML 包
- 1040 - ML 包
- 1040 附表 C - ML 包
- 1040 附表 D - ML 包
- 1040 附表 E - ML 包
- 1040x - ML 包
- 3949a - ML 包
- 4506T - ML 包
- 709 - ML 包
- 941x - ML 包
- 9465 - ML 包
- 990 - ML 包 - 预览
- ACORD125 - ML 包
- ACORD126 - ML 包
- ACORD131 - ML 包
- ACORD140 - ML 包
- ACORD25 - ML 包
- 银行对账单 - ML 包
- 提单 - ML 包
- 公司注册证书 - ML 包
- 原产地证书 - ML 包
- 检查 - ML 包
- 儿童产品证书 - ML 包
- CMS1500 - ML 包
- 欧盟符合性声明 - ML 包
- 财务报表 (Financial statements) - ML 包
- FM1003 - ML 包
- I9 - ML 包
- ID Cards - ML 包
- Invoices - ML 包
- 中国发票 - ML 包
- 希伯来语发票 - ML 包
- 印度发票 - ML 包
- 日本发票 - ML 包
- 装运发票 - ML 包
- 装箱单 - ML 包
- 护照 - ML 包
- 工资单 - ML 包
- 采购订单 - ML 包
- 收据 - ML 包
- 汇款通知书 - ML 包
- UB04 - ML 包
- 水电费账单 - ML 包
- 车辆所有权证明 - ML 包
- W2 - ML 包
- W9 - ML 包
- 其他开箱即用的 ML 包
- 公共端点
- 硬件要求
- 管道
- Document Manager
- OCR 服务
- 深度学习
- 训练高效能模型
- 部署高效能模型
- Insights 仪表板
- 部署在 Automation Suite 中的 Document Understanding
- 在 AI Center 独立版中部署的 Document Understanding
- 许可
- 活动
- UiPath.Abbyy.Activities
- UiPath.AbbyyEmbedded.Activities
- UiPath.DocumentProcessing.Contracts
- UiPath.DocumentUnderstanding.ML.Activities
- UiPath.DocumentUnderstanding.OCR.LocalServer.Activities
- UiPath.Intelligent OCR.Activities
- UiPath.OCR.Activities
- UiPath.OCR.Contracts
- UiPath.OmniPage.Activities
- UiPath.PDF.Activities
Document Understanding 用户指南
训练高效能模型
The power of Machine Learning Models is that they are defined by training data rather than by explicit logic expressed in computer code. This means that extraordinary care is needed when preparing datasets because a model is only as good as the dataset that was used to train it. In that sense, what UiPath® Studio is to RPA workflows, a Document Type session (in Document UnderstandingDocument UnderstandingTM Cloud) is to Machine Learning capabilities. Both require some experience to be used effectively.
ML 模型可以从单一类型的文档中提取数据，尽管它可能涵盖几种不同的语言。 每个字段（“总金额”、“日期”等）必须具有一致的含义，这一点至关重要。 如果人类对字段的正确值感到困惑，那么 ML 模型也不会。
可能会出现歧义情况。例如，水电费账单是否就是另一种类型的发票？还是这两种不同的文档类型需要两种不同的 ML 模型？如果您需要提取的字段相同（即含义相同），则可以将其视为单个文档类型。但是，如果出于不同原因（不同的业务流程）需要提取不同的字段，则表明您需要将这些文档视为两种不同的文档类型，因此需训练两种不同的模型。
如有疑问，首先请训练一个模型，但要将文档保存在不同的 Document Manager 批次 中（请参阅视图顶部的“筛选器”下拉列表），以便稍后在需要时轻松将其分开。 这样，加标签工作不会丢失。 对于 ML 模型，数据越多越好。 因此，拥有包含大量数据的单个模型是一个很好的起点。
Document Manager 可用于构建两种类型的数据集：
- 训练数据集
- 评估数据集
这两种类型的数据集对于构建高性能 ML 模型都是必不可少的，并且其创建和维护都需要花费时间和精力。获取高性能 ML 模型需要代表生产文档流量的评估数据集。
每个数据集类型都以不同的方式标记：
- 训练数据集依赖于页面上代表您需要提取的不同信息的词的边框。
- 为训练集添加标签时，请关注页面本身和文字框。
- 评估数据集依赖字段值，这些值显示在侧边栏（适用于常规字段）或顶部栏中（适用于列字段）。
- 为评估集添加标签时，请注意侧边栏或顶部栏中字段名称下的值。这并不意味着您需要手动输入这些值。我们建议通过单击页面上的框并检查值的正确性来添加标签。
有关如何执行适当评估的更多详细信息，请参阅下文。
数据提取依赖于以下组件：
- 光学字符识别
- 文字和线条构建
- 将字符按词语分组中并将词语按从左到右的文本行分组
- 页面上每个词/框的机器学习模型预测
- 文本跨度的清理、解析和格式化
- 例如，将多行中的词语分到一个地址中，将日期格式化为标准 yyyy-mm-dd 格式
- 应用选择要返回的值的算法
- 对于文档有 2 页或更多页且某些字段在多页显示的情况
业务自动化需要检测和处理异常的方法，异常即自动化出错的实例。在传统自动化中，异常是非常明显的，因为当 RPA 工作流中断时，该工作流只会停止、挂起或引发错误。系统可以捕获该错误并进行相应的处理。但是，机器学习模型在做出错误的预测时不会引发错误。那么，我们如何确定 ML 模型何时出错并且需要触发异常处理流程？这通常涉及人工参与，可能会使用 Action Center。
到目前为止，捕获错误预测的最佳方法是强制执行业务规则。例如，我们知道发票上的净额加上税额必须等于总金额。或者，所订购组件的部件号必须为 9 位数字。当这些条件不成立时，我们就知道出现了问题，就可以触发异常处理流程。这是首选方法，也是强烈推荐的方法。您值得投入大量精力来构建这些类型的规则，即使使用复杂的正则表达式，或者甚至通过在数据库中查找来验证供应商名称或部件编号等。在某些情况下，您甚至可能希望提取一些其他不感兴趣的文档，而只是为了交叉引用和验证感兴趣的原始文档的某些值。
但是，在某些情况下，这些选项都不存在，但您仍想检测可能有错的预测。在这些情况下，您可以重新使用置信度。当预测的置信度较低（例如，低于 0.6）时，与置信度为 0.95 时相比，预测不正确的风险较高。但是，这种相关性相当弱。在许多情况下，提取的值虽然置信度较低，但其实是正确的。少数情况下，也有可能以高置信度（超过 0.9）提取一个不正确的值。出于这些原因，我们强烈建议用户尽可能依赖业务规则，并且仅在万不得已的情况下使用置信度。
Most components in the Document UnderstandingTM product return a confidence level. The main components of a Document UnderstandingTM workflow are Digitization, Classification and Extraction. Each of these has a certain confidence for each prediction. The Digitization and the Extraction confidence are both visually exposed in the Validation Station, so you can filter predictions and focus only on low confidence ones, to save time.
为了获得最佳的自动化率结果（处理文档流所需的人工工作量每年每人每月减少的百分比），您需要仔细遵循以下步骤：
要选择 OCR 引擎，您应该创建不同的 Document Manager 会话，配置不同的 OCR 引擎，并尝试将相同的文件导入每个文件中以检查差异。专注于要提取的区域。例如，如果您需要提取发票中作为徽标的一部分显示的公司名称，则可能需要查看哪个 OCR 引擎在徽标中的文本上效果更好。
您的默认选项应为“UiPath 文档 OCR”，因为它是免费包含在 Document Understanding 许可证中的。但是，如果需要使用某些不受支持的语言，或者涉及到一些非常难读的文档，您可能需要尝试使用 Google Cloud（仅限云端）或 Microsoft Read（云端或本地部署），它们的语言覆盖范围更广。这些引擎需要付出一定的成本，但其实很低，但是，如果您的业务流程中某些关键数据字段的准确性较高，则强烈建议使用现有的最佳 OCR – 稍后您将发现其可以节约您的时间，因为所有后续工作均依赖于此。
请注意，“数字化文档”活动的“将 OCR 应用于 PDF”设置默认设为“自动”，这将根据输入文档确定文档是否需要应用 OCR 算法。将“将 OCR 应用于 PDF”设置为“是”，确保检测到所有文本，尽管这可能会减慢您的流程，但可以避免（从徽标、页眉、页脚等）漏提取重要信息。
定义字段是一场需要与拥有业务流程本身的主题专家或领域专家进行的对话。对于发票，它将是应付账款流程的所有者。此对话非常重要，需要在标注任何文档之前进行以避免浪费时间，并且还需要一起查看至少 20 个随机选择的文档样本。为此，我们需要预留一个小时的时间段，通常需要在几天后重复该时间段，因为准备数据的人员会遇到模棱两可的情况或极端情况。
对话开始时通常会假设您需要提取 10 个字段，然后提取 15 个字段。下面的小节将介绍一些示例。
您需要了解的一些关键配置：
- 内容类型
这是最重要的设置，因为它决定值的后处理，尤其是对于“日期”（检测格式是美式还是非美式，然后将其转换为 yyyy-mm-dd 格式）和“数字”（检测小数分隔符，即逗号或句点）。“ID 编号”会清除冒号或散列符号之前的所有内容。“字符串”内容类型不执行任何清理操作，可以在您希望在 RPA 工作流中执行自己的解析时使用。
- 多行复选框
这用于解析可能出现在多行文本中的字符串，如地址。
- 多值复选框
这用于处理多选字段或其他可能包含多个值但未表示为表格列的字段。 例如，政府表单上的族群问题可能包含多个复选框，您可以在其中选择所有适用项。
- 隐藏字段
可以为标记为“隐藏”的字段加标签，但在导出数据时会保留这些字段，因此不会对其应用训练模型。当正在为字段加标签、字段太稀少或其优先级较低时，这很方便。
- 计分
这仅与评估管道相关，并且会影响准确性分数的计算方式。 使用 Levenshtein 评分的字段更宽松：如果 10 个字符中的单个字符有误，则分数为 0.9。 但是，如果评分是“ 精确匹配 ”，则评分会更严格：输入一个错误字符将导致分数为零。 只有字符串类型字段才能默认选择“Levenshtein”评分的选项。
水电费账单金额
总金额看似足够简单，但水电费账单中包含很多金额。有时，您需要支付总金额。有时，您只需要当前的账单金额，而不需要从以前的账单周期结转的金额。在后一种情况下，即使当前账单和总金额可以相同，您也需要以不同的方式标注标签。概念不同，金额通常也有所不同。
此外，当前账单金额有时可能由几个不同的金额、费用和税款组成，并且可能不会在账单上的任何位置显示。 此问题的一个可能解决方案是创建两个字段：一个“ 先前费用 ”字段和一个“ 总计 ”字段。 这两个在水电费账单上始终显示为不同的显式值。 然后，可以获得当前账单金额，作为两者之间的差额。 您甚至可能希望包括所有 3 个字段（先前费用、 总计和 当前费用），以便能够在当前账单金额显式出现在文档中的情况下进行一些一致性检查。 因此，在某些情况下，您可以选择一到三个字段。
发票上的采购订单编号
PO 编号可以显示为发票的单个值，也可以显示为发票上的行项目表格的一部分，其中每个行项目都有不同的 PO 编号。在本例中，设置两个不同的字段可能较合适：po-no 和 item-po-no。通过在视觉上和概念上保持每个字段的一致性，该模型可能会做得更好。但是，您需要确保“训练”和“评估”数据集都充分体现了这一点。
发票上的供应商名称和付款地址名称
公司名称通常出现在发票或水电费账单的顶部，但有时可能不可读，因为只有一个徽标，并且公司名称没有明确写出。 文本上也可能有一些印记、笔迹或皱纹。 在这些情况下，人们可能会在水电费账单 工资 单的“收款人”部分中标注右下角显示的名称。 该名称通常是相同的，但并不总是相同的，因为它是一个不同的概念。 付款可以支付给其他母公司、控股公司或其他联属公司实体，但其单据看起来会有所不同。 这可能会导致模型性能下降。 在这种情况下，您应该创建两个字段，即“ vendor-name ”和 “payment-addr-name”。 然后，您可以在供应商数据库中查找并使用匹配的数据库，或者在缺少供应商名称时使用“ payment-addr-name ”。
表格行
我们需要牢记两个不同的概念：表格行和文本行。表格行包含该行中所有列字段的所有值。有时，它们可能全部属于页面上同一行文本的一部分。在其他情况下，它们可能位于不同的行中。
如果表格行包含多行文本，则需要使用“/”热键对该表格行中的所有值进行分组。 执行此操作时，将出现一个绿色框，覆盖整个表格行。 这是一个表格示例，其中前两行包含多行文本，需要使用“/”热键进行分组，而第三行是单行文本，不需要进行分组。
这是一个表格示例，其中每个表格行都由一行文本组成。您无需使用“/”热键对这些活动进行分组，因为这是由 Document Manager 隐式完成的。
在从上到下读取的过程中，识别一行结束以及另一行开始的位置通常是 ML 提取模型的主要挑战，尤其是在没有可视水平线分隔行的表单等文档上。 在我们的 ML 包中，有一个特殊的模型，该模型经过训练，可以正确地将表格拆分为行。 此模型使用您使用“/”或“Enter”键标记的组进行训练，并以绿色透明框表示。
机器学习技术的主要优势是能够以高度多样性处理复杂问题。在估计训练数据集的大小时，我们会先查看字段的数量及其类型和语言数量。只要不是中文/日语/韩语，一个模型就可以处理多种语言。中日韩场景通常需要单独的训练数据集和模型。
字段分为 3 种类型：
- 常规字段（日期、总金额）
- 对于常规字段，每个字段至少需要 20-50 个文档样本。因此，如果您需要提取 10 个常规字段，则至少需要 200-500 个文档样本。如果您需要提取 20 个常规字段，则至少需要 400-1000 个文档样本。您需要的文档样本数量会随着字段数量的增加而增加。更多的字段意味着您需要更多的文档样本，大约增加 20 到 50 倍。
- 列字段（项目单价、项目数量）
- 对于列字段，每个列字段至少需要 50-200 个文档样本，因此，对于 5 个列字段，使用干净简单的布局，您可能会通过 300 个文档样本获得良好的结果。但对于高度复杂和多样化的布局，可能需要超过 1000 个文档样本。要涵盖多种语言，则假设每种语言涵盖所有不同的字段，您至少需要 200-300 个文档样本。因此，对于包含 2 种语言的 10 个标头字段和 4 个列字段，600 个文档样本可能就足够了（列和标头为 400 个文档样本，额外添加一种语言为 200 个），但在某些情况下可能需要 1200 个或更多文档样本。
- 分类字段（币种）
- 分类字段通常要求每个类至少提供 10 至 20 个文档样本。
上述准则假设您正在解决高度多样性的场景，例如具有数十到数百或数千种布局的发票或采购订单。但是，如果您要解决布局（少于 5 到 10 个）较少的税表或发票等低多样性场景，则数据集的大小更多地取决于布局的数量。在这种情况下，每个布局应从 20 到 30 页开始，并在需要时添加更多页面 - 尤其是当页面非常密集且要提取大量字段时。例如，创建一个用于从 2 个布局中提取 10 个字段的模型可能需要 60 页，但如果您需要从 2 个布局中提取 50 或 100 个字段，则可以从 100 或 200 页开始，并根据需要添加更多页面，以提高准确性。在这种情况下，常规字段/列字段的区别就不那么重要了。
这些估计值假定大多数页面都包含所有或大部分字段。对于包含多个页面的文档，但大多数字段位于单个页面上，则相关页数是大多数字段出现的页面的示例数量。
上面的数字是一般准则，不是严格的要求。通常，您可以从较小的数据集开始，然后继续添加数据，直到获得良好的准确性为止。这在将 RPA 工作与模型构建并行化时尤其有用。此外，可以使用模型的第一个版本预标注额外数据（请参阅 Data Manager 中的“设置”视图和“预测”按钮），这可以加快为额外的训练数据添加标签。
深度学习模型可以变得通用
您不需要在训练集中表示每个布局。实际上，生产文档流程中的大多数布局可能在训练集中有 0 个样本，或者 1 个或 2 个样本。这是可取的，因为您希望利用 AI 的强大功能来理解文档，并能够对训练期间未见过的文档作出正确的预测。每个布局的大量样本并不是强制性的，因为大多数布局可能根本不存在，或者仅出现 1 次或 2 次，而模型仍然能够根据从其他布局的学习情况进行正确预测。
训练开箱即用模型
为 Document Understanding 训练 ML 模型时，有三种主要类型的场景：
- 使用 AI Center 中的 DocumentUnderstanding ML 包从头开始训练新型文档
- 对预训练的开箱即用模型进行重新训练，可用于优化准确性
- 对预训练的开箱即用模型进行重新训练，以优化准确性以及添加一些新字段
本节标题为“创建训练集”的第一部分介绍了第一种场景的数据集大小估计值。
对于第二种场景，数据集的大小取决于预训练模型在您的文档上的运行效果。如果它们已经运行良好，则您可能只需要很少的数据，可能需要 50-100 页。如果它们在许多重要字段失败，则您可能需要更多数据，但相比于从头开始训练字段，一个良好的起点的数据集大小仍然会小 4 倍。
最后，对于第三种场景，从上述第二种场景的数据集大小开始，然后使用与从头开始训练相同的指导原则，根据新字段的数量增加数据集：每个新的常规字段至少 20-50 页，或每个列字段至少 50-200 页。
在所有这些情况下，所有文档都需要完全标记，包括开箱即用模型无法识别的新字段，以及开箱即用模型能够识别的原始字段。
分布不均匀的字段出现次数
有些字段可能出现在每个文档上（例如，日期、发票编号），而有些字段可能只出现在 10％ 的页面上（例如，处理费用、折扣）。在这种情况下，您需要制定业务决策。如果这些稀有字段对自动化并不重要，则可以使用该特殊字段的少量文档样本（10-15 个），即包含该字段值的页面。但是，如果这些字段至关重要，则需要确保在训练集中至少包含 30-50 个该字段的文档样本，以确保涵盖全部多样性。
平衡数据集
对于发票而言，如果数据集包含来自 100 个供应商的发票，但数据集的一半包含来自 1 个供应商的发票，则这是一个非常不平衡的数据集。完全平衡的数据集是指每个供应商出现相同次数的情况。数据集不需要达到完美平衡，但您应避免有超过 20% 的整个数据集来自任何一个供应商。如果达到某个点，增加数据就无济于事，它甚至可能影响其他供应商的准确性，因为该模型将极大地优化（过拟合）一个供应商。
代表性数据集
应当选择数据来涵盖可能在生产工作流中看到的文档多样性。例如，如果您收到英语发票，但其中有一些发票来自美国、印度和澳大利亚，则发票看起来可能会有所不同，因此您需要确保从这三种发票中均获取样本。这不仅与模型训练本身相关，也与标签相关。在标注文档时，您可能会发现需要从其中一些区域提取新的不同字段，例如印度的 GSTIN 代码或澳大利亚的 ABN 代码。请参阅定义字段部分中的详细信息。
为训练数据添加标签时，您需要重点关注 Document Manager 文档窗格中文字的边框。右侧或顶部侧栏中的解析值并不重要，因为它们不会用于训练。
每当字段在页面上多次出现时，只要它们表示相同的概念，则应为所有字段加上标签。
当 OCR 漏掉一个词语或弄错几个字符时，只要标记边框（如果有），如果没有漏掉或弄错的情况，则跳过这步，继续操作。无法在 Document Manager 中添加词，因为即使您这样做，该词在运行时仍会丢失，因此添加它根本无法帮助模型。
当您标记标签时，请保持警觉，注意可能具有多个或重复含义/概念的字段（以防您可能需要将一个字段拆分为两个单独的字段），或者不需要的字段（但如果为其添加标签，可能帮助您在 RPA 工作流中执行某些验证或自我一致性检查逻辑）。典型的示例是发票行项目中的数量、单价和行金额。“行金额”是数量和单价的乘积，但这在无需设置置信度的情况下检查一致性时非常有用。
要创建提取程序，请转到 Document Understanding 中的“ 提取 程序” 视图，然后单击右上角的“ 创建提取 程序” 按钮。 然后，您可以选择要使用的 文档类型、 ML 模型 和 版本 。 您可以在“提取程序”选项卡或“提取程序”的“ 详细信息 ”视图中监控进度，该视图包含指向 AI Center 管道的链接，您可以在其中实时查看详细日志。
评估 ML 模型时，最强大的工具是 evaluation_<package name>.xlsx AI Center 管道详细信息视图的 artifacts/eval_metrics 文件夹中生成的文件。 在第一张工作表上，您可以看到详细的准确性分数报告，包括总体分数，以及每个字段和每个批次的分数。
在此 Excel 文件中，您可以查看哪些预测失败以及对哪些文件失败，并且可以立即查看其是 OCR 错误还是 ML 提取错误或解析错误，以及是否可以通过 RPA 工作流中的简单逻辑进行修复，或者它需要不同的 OCR 引擎、更多的训练数据，或者改进 Document Manager 中的标签或字段配置。
此 Excel 文件对于识别需要应用于 RPA 工作流的最相关业务规则也非常有用，以便在路由到 Actions Center 中的验证站点以进行手动审核时捕获常见错误。 到目前为止，业务规则是检测错误的最可靠方法。
对于业务规则无法捕获的错误，您还可以使用置信度级别。此 Excel 文件还包含每个预测的置信度级别，因此您可以使用 Excel 功能（例如排序和筛选）来确定适合您的业务场景的置信度阈值。
总体而言， evaluation_<package_name>.xlsx Excel 文件是您需要重点关注的关键资源，以便从 AI 自动化中获得最佳结果。
在此步骤中，您应该关注模型错误及其检测方法。有 2 种主要方法用于检测错误：
- 通过执行业务规则
- 通过在客户组织 的记录系统中应用查找
- 通过强制执行最低置信度级别阈值
检测错误最有效、最可靠的方法是定义业务规则和查找。 置信度级别永远不可能达到 100％ 完美，始终会有一小部分（但非零）的正确预测（低置信度）或错误预测（高置信度）。 此外，也许最重要的是，缺失的字段没有置信度，因此置信度阈值永远无法捕获根本不会提取字段的错误。 因此，置信度级别阈值只能用作回退和安全网，而不能用作检测关键业务错误的主要方法。
业务规则示例：
- 净额加税额必须等于总金额
- 总金额必须大于或等于净额
- “发票编号”、“日期”和“总金额”（及其他字段）必须存在
- PO 编号（如果有）在 PO 数据库中必须存在
- 发票日期必须是过去的日期，且不能超过 X 个月
- 到期日期必须是未来日期，且不能超过 Y 天/月
- 对于每个行项目，数量乘以单价必须等于行金额
- 行金额之和必须等于净额或总金额
- 等等。
具体来说，列字段的置信度级别绝不应用作错误检测机制，因为列字段（例如，发票或 PO 上的行项目）可能包含数十个值，因此针对如此多的值设置最小阈值是特别不可靠的，因为一个值很有可能具有较低的置信度，这将导致多次不必要地路由大部分或全部文档以进行人工验证。
定义业务规则后，有时可能会保留少量没有业务规则的字段，或者业务规则不太可能捕获所有错误。为此，您可能需要使用置信度阈值作为最后的手段。
设置此阈值的主要工具是 Excel 电子表格，该电子表格由训练管道在 Outputs > artifacts > eval_metrics 文件夹中输出。
此 evaluation_<package name>.xlsx 文件包含每个字段对应的列，以及每个预测的置信度级别。 通过根据置信度列对表格进行排序，您可以查看任何给定字段的错误开始出现位置，并设置一个高于该级别的阈值，以确保仅发送正确提取的文档。
验证站点数据可以帮助改进模型预测，但事实证明，在大多数情况下，大多数错误并非归因于模型本身，而是归因于 OCR、标签错误或不一致问题，或者归因于后处理问题（例如，日期或数字格式设置）。因此，第一个关键方面是，应仅在验证和优化其他数据提取组件后使用验证站点数据，以确保较高的准确度，而剩下的唯一改进领域是模型预测本身。
第二个关键方面是，验证站点数据的信息密度低于 Document Manager 中标记的数据。从根本上讲，验证站点用户只关心一次获取正确的值。如果发票有 5 页，并且发票编号出现在每页上，则验证站点用户只需在第一页上对其进行验证。因此，80％ 的值保持未标记状态。在 Document Manager 中，所有值都已标记。
最后，请记住，需要将验证站点数据添加到手动标记的原始数据集，以便您始终拥有单个训练数据集，该数据集的大小会随时间而增加。 您始终需要在次要版本为 0（零）的 ML 包上进行训练，该版本是 UiPath 发布的开箱即用版本。
使用验证站点数据的注意事项
验证站点的数据量可能会大得多，因为它用于 Production 工作流。 您不希望数据集被验证站点数据淹没，因为上述信息密度问题可能会降低模型的质量。
建议将添加的数据量限制在 Document Manager 数据页数的 2 到 3 倍以内，除此之外，仅挑选那些您发现了主要故障的供应商或样本。 如果已知 Production 数据发生重大变化，例如使用新语言，或者将新的地理区域加入到业务流程中（从美国扩展到欧洲或南亚），则应添加这些语言和区域的代表性数据上传到 Document Manager 以进行手动标记。 验证站点数据不适用于此类主要作用域扩展。
验证站点数据的另一个潜在问题是余额。 在 Production 中，大多数流量来自供应商/客户/全球区域的一小部分是很常见的。 如果按原样允许进入训练集，可能会导致模型出现高度偏差，该模型在一小部分数据子集上表现良好，但在其余大部分数据上表现不佳。 因此，在将验证站点数据添加到训练集时要特别小心，这一点很重要。
以下是一个示例场景。您已选择合适的 OCR 引擎，在 Document Manager 中标记了 500 页，从而获得良好的性能，并且已在生产 RPA 工作流中部署了模型。验证站点将开始生成数据。您应该从验证站点中随机选取最多 1000 到 1500 页，并将其与前 500 页一起导入到 Document Manager 中，然后再次训练 ML 模型。之后，您应该非常仔细地查看 evaluation_<package name>.xlsx，以确定模型确实得到了改进，然后您应该将新模型部署到生产中。
请务必使用 Studio 开始屏幕中“模板”部分中的“Document Understanding™ 流程：Studio 模板”，以便在企业 RPA 架构中应用最佳实践。
