文档模型

当“文档模块”（DocIQ）读取一份文档——一份简历、一张发票、一张采购订单——文档模型会告诉它要提取什么内容、填到哪条记录里。获得一个文档模型有三种方式，而且有严格的先后顺序。

采用组织的默认模型。 平台自带一个庞大的模型库，涵盖简历、发票、采购订单和入职核对清单等。采用一个默认模型不花任何成本，并且这个组织今后的每一次构建，看到的都是同一套字段。
当某个字段确实缺失时，扩展一个默认模型。 联系你的 iMBrace 联系人。把一个字段加进默认模型，会让它出现在每一个组织面前，而不是为单个客户单独拉出一个分支模型。
只有在不存在默认模型的地方，才自己编写，并且要用平台自身的风格来写，这样将来的默认模型才能干净利落地取代它。

不要做的事

把模型管理当作一个独立、刻意的步骤来做，绝不要把它当成某次构建的副产品。 在正在运行的构建之外创建或修改文档模型，这样每一个读取某类文档的构建，指向的都是同一个、唯一的模型。
不要把模型的选择交给运气。 如果某一步总是读取同一类文档，就明确告诉它该用哪个模型，这样每一份文档都会落在你预期的那张数据表上。

在一项设计开始依赖它之前，先用几份你自己的文档，逐一核查以下每一点：

一个字段很多的模型。 一个有几十个字段的模型，拆成几轮各有侧重的核查，会更容易验证。不管模型大小，都要把每一次结果对照字段清单逐一核查，确保每个字段都有着落。
嵌套行。 发票上的明细行、简历工作经历里的各段任职：在你的测试集里确认，每一条子行都落在与其父记录相链接的那张数据表上。
一份其实是表格的文档——比如一份价目表、一份对账单——它对应的是许多条记录，而不是一条。要把它当作若干行来读取。
一份看起来不像自己类型的文档。 在测试集里加入一些不典型的样本——比如一份没有职责部分的职位描述、一份缺少标准标题的表单——并确保智能体会把无法识别的文档如实报告为“无法识别”，而绝不会谎报成功。
面向整个组织的设置。 文档模块的模型设置是在整个组织范围内共享的。把你的构建测试时所用的设置，记录在你的测试集旁边，并且每当设置发生变化，就重新跑一遍测试集。
模型运行在哪里。 由哪个模型来读取你的文档，是按安装环境、按组织分别设置的。如果个人数据必须留在本地，就要请负责这套安装的人确认：文档模块所用的每一个模型——无论用于阅读还是用于检索——都运行在这套部署内部，然后才能放入第一份真实文档。

模型越少，越省成本、也越准确。 分类时，会把每一份文档与组织里的每一个模型逐一比对，所以每一个用不上的模型，都会增加成本和出错的空间。只保留你在用的模型；如果某一步总是读取同一类文档，就让它指向那类文档对应的数据表，把模型固定下来。
对任何你会用来分组或制图的字段，给它一个封闭的词表。 在字段的说明里列出所有允许的取值，这样分组和制图，用的就是一套固定、已知的术语。
用一份文档是什么、又不是什么，来描述每一种文档类型。 说明里点出那些和它极为相似、但并不是它的类型，正是让不同类型彼此区分开的关键。