algorithm – 计算上下文相关的文本关联

前端之家收集整理的这篇文章主要介绍了algorithm – 计算上下文相关的文本关联前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
假设我想将地址记录(或人名或其他)相互匹配,以合并最有可能引用相同地址的记录.基本上,我想我想计算文本值之间的某种相关性,并在该值超过某个阈值时合并记录.

例:
“West Lawnmower Drive 54 A”可能与“W. Lawn Mower Dr. 54A”相同,但与“East Lawnmower Drive 54 A”不同.

你会如何解决这个问题?是否有必要使用某种基于上下文的字典,在地址的情况下,知道“W”,“W”.和“西”是一样的吗?拼写错误(“搬运工”而不是“割草机”等)怎么样?

我认为这是一个棘手的问题 – 也许有一些众所周知的算法?

解决方法

一个好的基线,可能是一个不切实际的基准,就其相对较高的计算成本而言更重要的是它产生许多误报,将是通用的字符串距离算法,如

> Edit distance(又名Levenshtein距离)
> Ratcliff/Obershelp

取决于所需的准确度水平(BTW,应根据其recall and precision指定,即通常表示错过相关性是否比错误识别相关更重要),基于[某些]的本土生成过程以下启发式和想法可以做到这一点:

>标记输入,即将输入视为单词数组而不是字符串
>标记化还应保留行号信息
>使用常见替代品的短词典(例如,行末尾的“dr”=“驱动器”,“Jack”=“John”,“Bill”=“William”……来标准化输入…线路开头的“W”是“西”等.
>识别(有点像标记,如在POS标记中)某些实体的性质(例如邮政编码,扩展邮政编码,以及城市
>识别(查找)其中一些实体(例如,相对较短的数据库表可以包括目标区域中的所有城市/城镇
>识别(查找)一些与域相关的实体(如果所有/许多地址涉及法律专业人士,查找律师事务所名称或联邦建筑物可能会有所帮助.
>一般来说,更重视来自地址最后一行的令牌
>对具有特定实体类型的令牌施加更多(或更少)权重(例如:“Drive”,“Street”,“Court”应该比其前面的令牌少得多.
>考虑修改后的SOUNDEX算法来帮助规范化

考虑到上述情况,实现基于规则的评估程序.暂时地,规则可以实现为对树/类似阵列结构的访问者,其中最初解析输入(Visitor design pattern).
基于规则的框架的优点在于,每个启发式算法都有自己的功能,规则可以优先排序,即在链的早期放置一些规则,允许提前中止评估,具有一些强大的启发式(例如:不同的城市= >相关= 0,置信水平= 95%等……).

搜索相关性的一个重要考虑因素是需要先验地比较每个项目(此处地址)与每个其他项目,因此需要多达1/2 n ^ 2个项目级别的比较.因此,以预处理(解析,规范化…)的方式存储引用项并且可能具有可用作[非常粗略]的排序的摘要/键可能是有用的.可能相关性的指示符(例如,由5位ZIP-Code组成的密钥,后跟“主要”名称的SOUNDEX值).

猜你在找的HTML相关文章