- 概述
- 入门指南
- 活动
- Insights 仪表板
- 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 包
- 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 包
- InvoicesAustralia - ML 包
- 中国发票 - ML 包
- 希伯来语发票 - ML 包
- 印度发票 - ML 包
- 日本发票 - ML 包
- 装运发票 - ML 包
- 装箱单 - ML 包
- 工资单 - ML 包
- 护照 - ML 包
- 采购订单 - ML 包
- 收据 - ML 包
- 汇款通知书 - ML 包
- UB04 - ML 包
- 水电费账单 - ML 包
- 车辆所有权证明 - ML 包
- W2 - ML 包
- W9 - ML 包
- 其他开箱即用的 ML 包
- 公共端点
- 流量限制
- OCR 配置
- 管道
- OCR 服务
- 支持的语言
- 深度学习
- 训练高效能模型
- 部署高效能模型
- 许可
训练高效能模型
机器学习模型的强大功能在于,它们是由训练数据定义的,而不是由计算机代码中表示的显式逻辑定义的。 这意味着在准备训练数据集时需要格外小心,因为模型最高仅能达到与训练数据集一样好的效果。 从这个意义上说, UiPath™ Studio 之于RPA工作流,文档类型会话(在 Document Understanding TM Cloud 中)对于机器学习功能来说就像是一样。 两者都需要一定的经验才能有效使用。
ML 模型可以从单一类型的文档中提取数据,尽管它可能涵盖几种不同的语言。 每个字段(“总金额”、“日期”等)必须具有一致的含义,这一点至关重要。 如果人类对字段的正确值感到困惑,那么 ML 模型也不会。
可能会出现歧义情况。例如,水电费账单是否就是另一种类型的发票?还是这两种不同的文档类型需要两种不同的 ML 模型?如果您需要提取的字段相同(即含义相同),则可以将其视为单个文档类型。但是,如果出于不同原因(不同的业务流程)需要提取不同的字段,则表明您需要将这些文档视为两种不同的文档类型,因此需训练两种不同的模型。
如有疑问,首先请训练一个模型,但要将文档保存在不同的 Document Manager 批次 中(请参阅视图顶部的“筛选器”下拉列表),以便稍后在需要时轻松将其分开。 这样,加标签工作不会丢失。 对于 ML 模型,数据越多越好。 因此,拥有包含大量数据的单个模型是一个很好的起点。
Document Manager 可用于构建两类数据集:训练数据集和评估数据集。
- 模型总体准确度 – 这用作 Document Understanding 提取程序详细信息视图和 AI Center 工件文件夹(也可从 Document Understanding 访问)中显示的主要分数。
- 模型总体分数和字段级别 F1 分数 – 由于历史原因,在 AI Center 的工件文件夹(也可从 Document Understanding 访问)中提供此分数。
- AI Center 工件文件夹中提供的 Excel 文件中每个字段和每个批次的详细指标以及并排性能比较(也可从 Document Understanding 访问)。
可以将模型作为训练的一部分进行评分,因为训练集会自动在训练数据和验证数据之间以 80%/20% 的比例随机拆分,并且分数是根据验证数据计算的。
随着数据集的增加,“ 训练”和“验证”拆分都在发展,这意味着分数无法随时间直接比较(这是数据科学家感兴趣的内容)。 但是,它们确实反映了模型在最新数据上的性能,因此更能代表模型在当前 Production 数据上的当前性能(这是业务流程所有者感兴趣的内容)。
- 您无需冒查看基于过时数据(可能已存在多年)的分数的风险。
- 您可以减少需要添加标签的工作量。
- 您标记的所有数据都有助于实际改进模型,从而更快地提高性能。
数据提取依赖于以下组件:
- 光学字符识别
- OCR 后处理
- 文字和线条构建
- 将字符分组为单词和将单词分组为文本行
- 页面上每个词/框的机器学习模型预测
- 数据规范化
- 例如,将多行中的词语分到一个地址中,将日期格式化为标准 yyyy-mm-dd 格式
- 值选择
- 对于文档有两页或更多页且某些字段在多页显示的情况,应用一种算法来选择实际返回特定值的多个实例中的哪一个。
业务自动化需要检测和处理异常的方法,异常即自动化出错的实例。在传统自动化中,异常是非常明显的,因为当 RPA 工作流中断时,该工作流只会停止、挂起或引发错误。系统可以捕获该错误并进行相应的处理。但是,机器学习模型在做出错误的预测时不会引发错误。那么,我们如何确定 ML 模型何时出错并且需要触发异常处理流程?这通常涉及人工参与,可能会使用 Action Center。
到目前为止,捕获错误预测的最佳方法是强制执行业务规则。例如,我们知道发票上的净额加上税额必须等于总金额。或者,所订购组件的部件号必须为 9 位数字。当这些条件不成立时,我们就知道出现了问题,就可以触发异常处理流程。这是首选方法,也是强烈推荐的方法。您值得投入大量精力来构建这些类型的规则,即使使用复杂的正则表达式,或者甚至通过在数据库中查找来验证供应商名称或部件编号等。在某些情况下,您甚至可能希望提取一些其他不感兴趣的文档,而只是为了交叉引用和验证感兴趣的原始文档的某些值。
但是,在某些情况下,这些选项都不存在,但您仍想检测可能有错的预测。在这些情况下,您可以重新使用置信度。当预测的置信度较低(例如,低于 0.6)时,与置信度为 0.95 时相比,预测不正确的风险较高。但是,这种相关性相当弱。在许多情况下,提取的值虽然置信度较低,但其实是正确的。少数情况下,也有可能以高置信度(超过 0.9)提取一个不正确的值。出于这些原因,我们强烈建议用户尽可能依赖业务规则,并且仅在万不得已的情况下使用置信度。
Document Understanding TM产品中的大多数组件都会返回置信度。 Document Understanding TM工作流的主要组件是数字化、分类和提取。 其中每个变量的每个预测都有一定的置信度。 “数字化”和“提取”的置信度都以可视方式显示在“验证站点”中,因此您可以筛选预测并仅关注低置信度预测,以节省时间。
为了获得最佳的自动化率结果(处理文档流所需的人工工作量每年每人每月减少的百分比),您需要仔细遵循以下步骤:
对于欧洲基于拉丁语的语言,您的默认选项应为 UiPath 文档 OCR 或 UiPath Chinese-Japanese-Korean OCR。 如果您需要处理其他语言,包括西里尔语、梵文脚本、泰语、越南语、阿拉伯语、希伯莱语或波斯语,您可能更喜欢 Microsoft Azure Read OCR (仅限 Cloud)、 Google Cloud Vision OCR (仅限 Cloud)或 Omnipage OCR (活动在 Studio 中打包)。 有必要使用不同的 OCR 引擎创建几个不同的 Document Manager 会话,以检查哪个引擎在您的文档上效果最佳。 稍后在项目中更改 OCR 引擎的成本可能很高。
请注意,“ 数字化文档” 活动的“将 OCR 应用于 PDF ”设置默认设置为 “自动 ”,这意味着在处理 .pdf 默认情况下,数字化会尝试从 .pdf 文档中抓取尽可能多的文本, 并合并结果。
但是, .pdf 文档有时会损坏或格式异常,从而导致提取的文本出错。 在这种情况下,请将“将 OCR 应用于 PDF”设置为 “是”。
在所有 .pdf 文档 中应用 OCR 的另一个好处 使用 UiPath 文档 OCR 的 UiPath 文档 OCR 可识别表单,这些复选框是文档的关键元素。 但请注意,对所有内容应用 OCR 会稍微降低数字化速度。
定义字段是一场需要与拥有业务流程本身的主题专家或领域专家进行的对话。对于发票,它将是应付账款流程的所有者。此对话非常重要,需要在标注任何文档之前进行以避免浪费时间,并且还需要一起查看至少 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 个样本。
数据集大小的建议范围基于“计算器”选项卡中提供的信息。对于只有少量常规字段和清晰文档布局的更简单场景,使用低橙色范围的数据集才可能获得良好的结果。对于复杂场景,尤其是涉及多列的复杂表格,需要高橙色甚至绿色范围的数据集才能获得良好的结果。
此外,这些估计值假定大多数页面都包含所有或大部分字段。如果您的文档包含多个页面,但大多数字段位于单个页面上,则相关页数是大多数字段出现的页面的示例数量。
上面的数字是一般准则,不是严格的要求。通常,您可以从较小的数据集开始,然后继续添加数据,直到获得良好的准确性为止。这在将 RPA 工作与模型构建并行化时尤其有用。此外,可以使用模型的第一个版本预标注额外数据(请参阅 Data Manager 中的“设置”视图和“预测”按钮),这可以加快为额外的训练数据添加标签。
深度学习模型可以变得通用
您不需要在训练集中表示每个布局。实际上,生产文档流程中的大多数布局可能在训练集中只有 0 个样本,或者可能只有 1 个或 2 个样本。这是可取的,因为您希望利用 AI 的强大功能来理解文档,并能够对训练期间未见过的文档作出正确的预测。每个布局的大量样本并不是强制性的,因为大多数布局可能根本不存在,或者仅出现 1 次或 2 次,而模型仍然能够根据从其他布局的学习情况进行正确预测。
训练开箱即用模型
一种常见情况是从发票中提取数据,对此我们有一个预训练的开箱即用模型,但还有另外 2 个常规字段和 1 个列字段是预训练的发票模型无法识别的。 在这种情况下,与从头开始训练所有字段相比,您通常需要小得多的数据集。 当您在 Document Understanding Cloud 中创建文档类型时,系统会提供数据集大小估计值,然后可以在“数据集诊断”视图中访问它。 但是,请记住,用于训练模型的任何文档都必须完全标记,包括开箱即用模型无法识别的新字段,以及开箱即用模型确实可以识别。
分布不均匀的字段出现次数
有些字段可能出现在每个文档上(例如,日期、发票编号),而有些字段可能只出现在 10% 的文档上(例如,处理费用、折扣)。 在这些情况下,您需要制定业务决策。 如果这些稀有字段对您的自动化并不重要,则可以使用该特定字段的少量样本(10-15 个),即包含该字段值的页面。 但是,如果这些字段至关重要,则需要确保在训练集中至少包含该字段的 30-50 个样本,以确保涵盖全部多样性。
平衡数据集
对于发票,如果数据集包含来自 100 个供应商的发票,但数据集的一半仅包含来自一个供应商的发票,则这是一个非常不平衡的数据集。 完全平衡的数据集是指每个供应商出现相同次数的情况。 数据集不需要完全平衡,但应避免超过整个数据集的 20% 来自任何单个供应商。 在某些时候,更多的数据无济于事,甚至可能会降低其他供应商的准确性,因为该模型会极大地优化(过拟合)一个供应商。
代表性数据集
应当选择数据来涵盖可能在生产工作流中看到的文档多样性。例如,如果您收到英语发票,但其中有一些发票来自美国、印度和澳大利亚,则发票看起来可能会有所不同,因此您需要确保从这三种发票中均获取样本。这不仅适用于模型训练本身,也适用于标注目的,因为在标注文档时,您可能会发现需要从其中一些区域提取新的不同字段,例如印度的 GSTIN 代码或澳大利亚的 ABN 代码。
训练/验证拆分
任何训练数据集都会在后台自动拆分为训练集(随机选择的 80%)和验证集(随机选择的 20%)。 在训练深度学习模型期间,训练集用于反向传播,这是实际修改网络中节点权重的部分,而验证集仅用于知道何时停止训练。 换句话说,它用于防止训练集过拟合。
这就是在任何训练运行结束时获得完整评估分数的方式:我们返回验证集的分数。 从技术上讲,此集合并不用于训练网络,仅用于防止过度拟合。 但是,由于它是从整个数据集中随机选择 20% 的,因此它确实往往以类似的方式分布到训练集。 这种一致性是件好事,因为这意味着您获得的分数反映了模型从数据中学习的能力,而这正是我们通常关心的内容。 如果模型无法学习,则意味着数据不一致或模型存在限制,这是我们在训练模型时需要立即了解的关键信息。
这种方法的缺点是,随着数据集的增长,不一定能将分数完全进行比较,而且分数并不能反映模型的泛化能力,只能反映其学习能力。 但是,类比比较和衡量泛化能力属于技术和数据科学问题,对大多数自动化而言,它们只会间接影响业务绩效或 ROI。
为训练数据添加标签时,您需要重点关注 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 流程模板 ,以便在企业 RPA 架构中应用最佳实践。