以正确的置信度在单个列上使用数据库定位器进行搜索？
Search with a Database Locator on a single column with correct confidence?
我已经使用 Kofax Transformation Modules 3 年了，但我仍然不确定数据库定位器的工作原理。
我有一个非常简单的数据库，有很多列。
我有一个很简单的PDF文档，OCR就搞定了
我想根据单个列的值从数据库中检索一条记录。
因此，如果在文档中找到此列中的值，我希望数据库定位器 return 相应的记录，置信度为 100%（或针对该单个值的 OCR 置信度）。
最后但同样重要的是，我希望这种信心能够与我在数据库定位器的属性（常规选项卡）中设置的 "minimum confidence" 一起使用。
不过好像不太可能。
看，我的 PDF 文档包含一个由 OCR 读取的值，该值与数据库列 100% 匹配。
定位器 return 具有所谓的 100% 置信度的记录，因为我在该单列上设置了搜索掩码。
但如果我将最低置信度设置为高于 34%，则该记录不是 returned。
这是为什么？如何修复？
我真的必须使用脚本定位器来做我想做的事吗，这看起来并不复杂？
不直观的置信度值
当数据库定位器运行时，它会尝试查找与文档 OCR 最匹配的记录。您看到的行为的关键在于，它首先进行 actual 模糊搜索，返回满足最小置信度的记录，然后 then 定位器本身进行额外处理：根据记录是否满足定位器中定义的字段、搜索掩码或区域设置来增加或减少记录的置信度。
这种行为的好处是内存和处理效率。核心模糊搜索索引可以快速确定哪些记录满足初始置信度阈值，然后Database Locator 只需将这些记录加载到内存中并进行post 处理。替代方案是需要加载所有记录以进行 post 处理，以防 post 处理将置信度推高至阈值以上。那会更直观，但效率较低。
可能的配置改进
如果您只想搜索该列，而其他列只是您要返回的数据，请确保该列是唯一的索引列。当您打开数据库的属性时，它会显示带有复选框的字段名称。任何被选中的字段都会被编入索引，并且是定位器将尝试在文档中查找的内容的一部分。如果您检查了一堆实际上不在文档中的字段，您的信心可能会降低，特别是如果您还为定位器设置 "Penalty for empty fields".
设置了 non-zero 值
使用 KSMS 时，无法在 Project Builder 中更改索引列，因为 KSMS 正在构建和提供索引。相反，在 KSMS 管理中打开数据库的导入设置，然后看到有一个 "Columns to Use" 复选框部分。如果您通过上传文件而不是指向 UNC 路径来配置数据库，则需要再次上传它才能更改索引的列。
上下文
对于将此作为传统数据库问题阅读的任何人： KTM 中此上下文中的 "database" 从 CSV 或关系数据库中获取记录并为它们编制索引以进行模糊匹配。这个核心模糊搜索功能有几种使用方式，其中之一是数据库定位器。
提及数据库定位器处理与模糊搜索分开处理的文档：
脚本帮助主题 "Database Lookup in Specific Columns" 展示了如何使用脚本中的模糊搜索（来自脚本 window：帮助 > 脚本帮助，然后是脚本示例 > 特定列中的数据库查找），但它也有一些提及模糊搜索本身与数据库定位器处理的其他一些设置分开。
只是为了向 Stephan 已经很好的回答添加更多见解。首先，数据库定位器 (DBL) 和使用搜索掩码时的最低置信度存在一些已知问题。我们对此没有明确的解释，但我们观察到 DBL 可能会错过比返回的记录具有更高置信度的记录，尤其是在处理索引中的数百万条记录时。我们搜索了一次客户id，并将阈值设置为0.8，返回的记录数为100。DBL 返回了0.8 和0.98 范围内的记录，但不是最终确实存在的记录。不过，将最小置信度增加到 1 确实产生了它。
此外，这里是数据库定位器的置信度是如何计算的。首先，让我们看看DBL中存在的权重：
- 必须存在：1.8
- 高：1.4
- 正常：1
- 低：0.6
- 非常低：0.2
然后将每个子字段的置信度乘以权重。假设 DBL 找到了置信度为 1 的名字，而您说它是 "very important" - 加权置信度值为 1.8。对每个子字段重复此操作，记录的最终置信度是所有置信度和权重的总和。
举个例子：假设有四个子字段具有不同的权重。我们还假设我们的 DBL 找到了名字和姓氏的自信匹配（名字为 95%，姓氏为 100%）；对这个城市有信心，但不是邮政编码：
First Name Street Zip City
--------------------- ------------ -------- ------ ------
Importance (weight) 1.4 1.4 0.2 0.2
Confidence 0.95 1 0.2 1
weighted Confidence 1.33 1.4 0.04 0.2
--
TOTAL: 93%
记录的总置信度为 0.93，计算方法如下：
(1.33 + 1.4 + 0.04 + 0.2 ) / (1.4 + 1.4 + 0.2 + 0.2) = 0.928125
我已经使用 Kofax Transformation Modules 3 年了，但我仍然不确定数据库定位器的工作原理。
我有一个非常简单的数据库，有很多列。 我有一个很简单的PDF文档，OCR就搞定了
我想根据单个列的值从数据库中检索一条记录。 因此，如果在文档中找到此列中的值，我希望数据库定位器 return 相应的记录，置信度为 100%（或针对该单个值的 OCR 置信度）。
最后但同样重要的是，我希望这种信心能够与我在数据库定位器的属性（常规选项卡）中设置的 "minimum confidence" 一起使用。
不过好像不太可能。
看，我的 PDF 文档包含一个由 OCR 读取的值，该值与数据库列 100% 匹配。
定位器 return 具有所谓的 100% 置信度的记录，因为我在该单列上设置了搜索掩码。
但如果我将最低置信度设置为高于 34%，则该记录不是 returned。
这是为什么？如何修复？
我真的必须使用脚本定位器来做我想做的事吗，这看起来并不复杂？
不直观的置信度值
当数据库定位器运行时，它会尝试查找与文档 OCR 最匹配的记录。您看到的行为的关键在于，它首先进行 actual 模糊搜索，返回满足最小置信度的记录，然后 then 定位器本身进行额外处理：根据记录是否满足定位器中定义的字段、搜索掩码或区域设置来增加或减少记录的置信度。
这种行为的好处是内存和处理效率。核心模糊搜索索引可以快速确定哪些记录满足初始置信度阈值，然后Database Locator 只需将这些记录加载到内存中并进行post 处理。替代方案是需要加载所有记录以进行 post 处理，以防 post 处理将置信度推高至阈值以上。那会更直观，但效率较低。
可能的配置改进
如果您只想搜索该列，而其他列只是您要返回的数据，请确保该列是唯一的索引列。当您打开数据库的属性时，它会显示带有复选框的字段名称。任何被选中的字段都会被编入索引，并且是定位器将尝试在文档中查找的内容的一部分。如果您检查了一堆实际上不在文档中的字段，您的信心可能会降低，特别是如果您还为定位器设置 "Penalty for empty fields".
设置了 non-zero 值使用 KSMS 时，无法在 Project Builder 中更改索引列，因为 KSMS 正在构建和提供索引。相反，在 KSMS 管理中打开数据库的导入设置，然后看到有一个 "Columns to Use" 复选框部分。如果您通过上传文件而不是指向 UNC 路径来配置数据库，则需要再次上传它才能更改索引的列。
上下文
对于将此作为传统数据库问题阅读的任何人： KTM 中此上下文中的 "database" 从 CSV 或关系数据库中获取记录并为它们编制索引以进行模糊匹配。这个核心模糊搜索功能有几种使用方式，其中之一是数据库定位器。
提及数据库定位器处理与模糊搜索分开处理的文档： 脚本帮助主题 "Database Lookup in Specific Columns" 展示了如何使用脚本中的模糊搜索（来自脚本 window：帮助 > 脚本帮助，然后是脚本示例 > 特定列中的数据库查找），但它也有一些提及模糊搜索本身与数据库定位器处理的其他一些设置分开。
只是为了向 Stephan 已经很好的回答添加更多见解。首先，数据库定位器 (DBL) 和使用搜索掩码时的最低置信度存在一些已知问题。我们对此没有明确的解释，但我们观察到 DBL 可能会错过比返回的记录具有更高置信度的记录，尤其是在处理索引中的数百万条记录时。我们搜索了一次客户id，并将阈值设置为0.8，返回的记录数为100。DBL 返回了0.8 和0.98 范围内的记录，但不是最终确实存在的记录。不过，将最小置信度增加到 1 确实产生了它。
此外，这里是数据库定位器的置信度是如何计算的。首先，让我们看看DBL中存在的权重：
- 必须存在：1.8
- 高：1.4
- 正常：1
- 低：0.6
- 非常低：0.2
然后将每个子字段的置信度乘以权重。假设 DBL 找到了置信度为 1 的名字，而您说它是 "very important" - 加权置信度值为 1.8。对每个子字段重复此操作，记录的最终置信度是所有置信度和权重的总和。
举个例子：假设有四个子字段具有不同的权重。我们还假设我们的 DBL 找到了名字和姓氏的自信匹配（名字为 95%，姓氏为 100%）；对这个城市有信心，但不是邮政编码：
First Name Street Zip City
--------------------- ------------ -------- ------ ------
Importance (weight) 1.4 1.4 0.2 0.2
Confidence 0.95 1 0.2 1
weighted Confidence 1.33 1.4 0.04 0.2
--
TOTAL: 93%
记录的总置信度为 0.93，计算方法如下：
(1.33 + 1.4 + 0.04 + 0.2 ) / (1.4 + 1.4 + 0.2 + 0.2) = 0.928125