1
4
非直观置信值当数据库定位器运行时,它会尝试查找与文档OCR最匹配的记录。您看到的行为的关键是,它首先执行 真实的 模糊搜索,返回满足最小置信度的记录,以及 然后 定位器本身执行其他处理:根据记录是否符合定位器中定义的字段、搜索掩码或区域设置,增加或减少记录的可信度。 这种行为的好处是内存和处理效率。核心模糊搜索索引可以快速确定哪些记录满足初始置信阈值,然后数据库定位器只需将这些记录加载到内存中并进行后处理。另一种选择是,需要加载所有记录才能进行后处理,以防后处理将置信度推到阈值以上。这将更加直观,但效率较低。 可能的配置改进如果您只想搜索这一列,而其他列只是您想要返回的数据,那么请确保该列是唯一索引的列。打开数据库的属性时,会显示带有复选框的字段名称。选中的任何字段都会被编入索引,并且是定位器将尝试在文档上查找的内容的一部分。如果检查了一组实际上不在文档中的字段,尤其是如果定位器设置“空字段惩罚”的值为非零值,则可信度可能会降低。 使用KSMS时,无法在Project Builder中更改索引列,因为KSMS正在构建和服务索引。而是在KSMS管理中打开数据库的导入设置,并查看复选框中的“要使用的列”部分。如果通过上载文件而不是指向UNC路径来配置数据库,则需要再次上载该文件才能更改索引的列。 上下文对于任何将此作为传统数据库问题阅读的人: KTM中这种上下文中的“数据库”从CSV或关系数据库中获取记录,并为其编制索引以进行模糊匹配。这种核心的模糊搜索功能有几种用途,其中之一就是数据库定位器。 单独提及数据库定位器处理和模糊搜索的文档: 脚本帮助主题“特定列中的数据库查找”显示了如何使用脚本中的模糊搜索(从脚本窗口:help>scripting help,然后script Samples>Database Lookup in Specific Columns),但它也提到了模糊搜索本身,它与数据库定位器处理的某些其他设置不同。 |
2
2
只是想对Stephan已经很好的答案补充一些见解。首先,在使用搜索掩码时,数据库定位器(DBL)和最小可信度存在一些已知问题。对此,我们没有明确的解释,但我们观察到DBL可能会丢失置信度高于返回值的记录,尤其是在索引中处理数百万条记录时。我们搜索了一次客户id,并将阈值设置为。8,返回的记录数为100。DBL返回的记录范围为。8和。98,但这并不是最终的记录。不过,将最小置信度增加到1确实会产生这种效果。 此外,下面是如何计算数据库定位器中的信任度。首先,让我们看看DBL中存在的权重:
然后将每个子字段的置信度乘以权重。假设DBL找到的第一个名字的置信度为1,您说这“非常重要”-加权置信度值为1.8。对每个子字段重复此操作,记录的最终置信度是所有置信度和权重的和积。 下面是一个示例:假设四个子字段具有不同的权重。我们还假设我们的DBL找到了名字和姓氏的可靠匹配(名字为95%,姓氏为100%);这座城市很有信心,但邮政编码不是:
记录的总置信度为0.93,计算方法如下:
|