f******k
发帖数: 43 | 1 一个公司信息的数据库，想检查其中是否有同一公司的多条记录，因为同一公司名可能
存在多种记法。比如ABC Tech, ABC Technology, ABC Technology, Inc, ABC, Inc等等
。尽管这些表达有可能其实是不同公司，但更有可能是同一公司。因此想把它们找出来
并返回给相关人员核查。这种核查不是针对某一家公司，而是数据库中所有公司。因此
XYZ公司可能也存在这种问题。同时仅从字符串编辑距离上看，ABC vs XYZ比与ABC Tec
hnology还小，但ABC和XYZ不太可能是同一条记录，而和ABC Technology反而更可能是同
一个公司。
当然，也存在记录输入错误，将ABC Tech输成了ABC Teck从而存在两条记录，但实际是
同一个公司。这种也希望能检查出来。
所以有什么更好的办法使聚类的结果更准确么？谢谢 |
S*A
发帖数: 7142 | 2 这个设计自然语言的理解，不是简单的问题，大概是
需要一些智能的。
我的思路大概如下。
应该有不同的属性提供一个 scoring system。
例如 Levenshtein distance 是一个 score.
然后 A 是否是 B 的子集合也是一个 score.
复杂一点的可以试图把词归类，在里面提取行业的相似程度。
例如 food 和厨房比较接近。
然后 Inc, company 之类的区分意义不大的词可以去。
总之，可以用已有的数据库里已知公司不同的别名
来帮助开发这样的多属性 scoring system，寻找容易区分
公司是否相似的属性。
然后就是对这个系列的属性 score 试图去 fit 一个总体
是否同公司的输出。简单可以自己定些规则，例如某个 score
> 临界就认为相似。复杂点的可以套用 machine learning
的框架实现，可以用已知的数据 set 去训练这个是否的输出。
这样比较精确微调提高匹配程度。
等等
Tec
是同
【在 f******k 的大作中提到】
: 一个公司信息的数据库，想检查其中是否有同一公司的多条记录，因为同一公司名可能
: 存在多种记法。比如ABC Tech, ABC Technology, ABC Technology, Inc, ABC, Inc等等
: 。尽管这些表达有可能其实是不同公司，但更有可能是同一公司。因此想把它们找出来
: 并返回给相关人员核查。这种核查不是针对某一家公司，而是数据库中所有公司。因此
: XYZ公司可能也存在这种问题。同时仅从字符串编辑距离上看，ABC vs XYZ比与ABC Tec
: hnology还小，但ABC和XYZ不太可能是同一条记录，而和ABC Technology反而更可能是同
: 一个公司。
: 当然，也存在记录输入错误，将ABC Tech输成了ABC Teck从而存在两条记录，但实际是
: 同一个公司。这种也希望能检查出来。
: 所以有什么更好的办法使聚类的结果更准确么？谢谢
|
z****e
发帖数: 54598 | 3 你这么说人家能看懂么？
我也看得一知半解的，统计的水还是太深了
不过我说一个相对容易点的哈
建立tdm
然后normalize下
最后点乘计算cos夹角
因为cos是递减函数
所以值越大，夹角越小，越接近
这个很容易算，不过有模型可以优化，需要人工介入比较好撒
【在 S*A 的大作中提到】
: 这个设计自然语言的理解，不是简单的问题，大概是
: 需要一些智能的。
: 我的思路大概如下。
: 应该有不同的属性提供一个 scoring system。
: 例如 Levenshtein distance 是一个 score.
: 然后 A 是否是 B 的子集合也是一个 score.
: 复杂一点的可以试图把词归类，在里面提取行业的相似程度。
: 例如 food 和厨房比较接近。
: 然后 Inc, company 之类的区分意义不大的词可以去。
: 总之，可以用已有的数据库里已知公司不同的别名
|
g*****g
发帖数: 34805 | 4 都是没实践过的瞎出主义，上个 Lucene，Tokenized fuzzy search就搞定了。 |
z****e
发帖数: 54598 | 5 相似要找出来
不难
text clustering就可以搞定了
先建tdm
然后按照上面的方法去做clustering
bottom up比较好
就是慢一点 |
z****e
发帖数: 54598 | 6 对哦，忘记用轮子了，看来还是对轮子不够熟悉
【在 g*****g 的大作中提到】
: 都是没实践过的瞎出主义，上个 Lucene，Tokenized fuzzy search就搞定了。
|
i**i
发帖数: 1500 | 7 哪里用那么麻烦。
parse:
1. 提取公司类型 llc,s corp etc.
2. 缩写-> 全称。 tech -> technology
3. 剩下的是公司的名字。对于英文名字可以把单词按字典排序.
做一个函数算单词的距离。
然后跟库比对。肯定八九不离十。 |
i**i
发帖数: 1500 | 8 full text search 在这种情况下效果不一定好。
lucene的stemmers在这里没有道理
【在 g*****g 的大作中提到】
: 都是没实践过的瞎出主义，上个 Lucene，Tokenized fuzzy search就搞定了。
|
g*****g
发帖数: 34805 | 9 我们用来搜电影 title, 人名，跟这个 use case一模一样， 效果好不好你比我清楚？
【在 i**i 的大作中提到】
: full text search 在这种情况下效果不一定好。
: lucene的stemmers在这里没有道理
|
b*******s
发帖数: 5216 | 10 http://flamingo.ics.uci.edu/
is this what u want?
等等
Tec
是同
【在 f******k 的大作中提到】
: 一个公司信息的数据库，想检查其中是否有同一公司的多条记录，因为同一公司名可能
: 存在多种记法。比如ABC Tech, ABC Technology, ABC Technology, Inc, ABC, Inc等等
: 。尽管这些表达有可能其实是不同公司，但更有可能是同一公司。因此想把它们找出来
: 并返回给相关人员核查。这种核查不是针对某一家公司，而是数据库中所有公司。因此
: XYZ公司可能也存在这种问题。同时仅从字符串编辑距离上看，ABC vs XYZ比与ABC Tec
: hnology还小，但ABC和XYZ不太可能是同一条记录，而和ABC Technology反而更可能是同
: 一个公司。
: 当然，也存在记录输入错误，将ABC Tech输成了ABC Teck从而存在两条记录，但实际是
: 同一个公司。这种也希望能检查出来。
: 所以有什么更好的办法使聚类的结果更准确么？谢谢
|
|
|
i**i
发帖数: 1500 | 11 好吧。那你能不能给科普一下netflix选的（或者自己做的）suggestion算法是什么？
【在 g*****g 的大作中提到】
: 我们用来搜电影 title, 人名，跟这个 use case一模一样， 效果好不好你比我清楚？
|
b*******s
发帖数: 5216 | 12 人家讲的是模式识别，扯什么统计
【在 z****e 的大作中提到】
: 你这么说人家能看懂么？
: 我也看得一知半解的，统计的水还是太深了
: 不过我说一个相对容易点的哈
: 建立tdm
: 然后normalize下
: 最后点乘计算cos夹角
: 因为cos是递减函数
: 所以值越大，夹角越小，越接近
: 这个很容易算，不过有模型可以优化，需要人工介入比较好撒
|
g*****g
发帖数: 34805 | 13 consumer faced的那个不是我做的，不敢说。我们内部有一些内容管理需要搜索，我老
写的 API, 就是
Elastic search 缺省的 tokenized term search效果就很好。楼主说的所有 case我都
试过。想优化还有一堆的权制可以调。这是Apache的顶级轮子，让你写一年也赶不上。
【在 i**i 的大作中提到】
: 好吧。那你能不能给科普一下netflix选的（或者自己做的）suggestion算法是什么？
|
z****e
发帖数: 54598 | 14 装逼犯，我说的压根不是统计，是线性代数
【在 b*******s 的大作中提到】
: 人家讲的是模式识别，扯什么统计
|
z****e
发帖数: 54598 | 15 不知道古德霸那个api怎么用，没怎么用过
你这里面abc都是首词，所以可以加大第一个单词的权重
找最相似的，比如第一个单词权重都是50％，如果第一个单词一样，剩下单词都不一样
那么有50％相似度，你可以建立一个score或者weight来判断
这样就不会导致abc和xy和abc和abc technology有所不同了
找完了第一个之后再找类似的，abc不小心打成adc这样就接近了
等等
Tec
是同
【在 f******k 的大作中提到】
: 一个公司信息的数据库，想检查其中是否有同一公司的多条记录，因为同一公司名可能
: 存在多种记法。比如ABC Tech, ABC Technology, ABC Technology, Inc, ABC, Inc等等
: 。尽管这些表达有可能其实是不同公司，但更有可能是同一公司。因此想把它们找出来
: 并返回给相关人员核查。这种核查不是针对某一家公司，而是数据库中所有公司。因此
: XYZ公司可能也存在这种问题。同时仅从字符串编辑距离上看，ABC vs XYZ比与ABC Tec
: hnology还小，但ABC和XYZ不太可能是同一条记录，而和ABC Technology反而更可能是同
: 一个公司。
: 当然，也存在记录输入错误，将ABC Tech输成了ABC Teck从而存在两条记录，但实际是
: 同一个公司。这种也希望能检查出来。
: 所以有什么更好的办法使聚类的结果更准确么？谢谢
|
g*****g
发帖数: 34805 | 16 Lucene的fuzzy search是基于Levenshtein distance的。加上tokenize调一下权重足以。 |
z****e
发帖数: 54598 | 17 Levenshtein distance是string matrices
他这里面貌似还有terms matrices的东西
【在 g*****g 的大作中提到】
: Lucene的fuzzy search是基于Levenshtein distance的。加上tokenize调一下权重足以。
|
z****e
发帖数: 54598 | 18 还有一个就是过滤掉频繁出现的关键字
比如technolog, company, co.jp, com这些
直接全部无视都没啥问题，不管怎样，这些频繁出现的字眼权重一定要降低
不过如果能有轮子搞定，那还是直接上轮子了 |
d*******r
发帖数: 3299 | 19 大牛能否比较下 Lucene&Solr VS ElasticSearch 分别的优缺点和适用范围?
【在 g*****g 的大作中提到】
: consumer faced的那个不是我做的，不敢说。我们内部有一些内容管理需要搜索，我老
: 写的 API, 就是
: Elastic search 缺省的 tokenized term search效果就很好。楼主说的所有 case我都
: 试过。想优化还有一堆的权制可以调。这是Apache的顶级轮子，让你写一年也赶不上。
|
z****e
发帖数: 54598 | 20 ElasticSearch不是基于lucence的吗？
【在 d*******r 的大作中提到】
: 大牛能否比较下 Lucene&Solr VS ElasticSearch 分别的优缺点和适用范围?
|
|
|
g*****g
发帖数: 34805 | 21 Solr/ES都是基于Lucene的，Lucene是一个搜索的库，Solr/ES是之上提供了应用级的支
持。
个人觉得ES比较先进，flexible schema, good scalability.
【在 d*******r 的大作中提到】
: 大牛能否比较下 Lucene&Solr VS ElasticSearch 分别的优缺点和适用范围?
|
z****e
发帖数: 54598 | 22 酱紫啊，先试试用看了
thx
【在 g*****g 的大作中提到】
: Solr/ES都是基于Lucene的，Lucene是一个搜索的库，Solr/ES是之上提供了应用级的支
: 持。
: 个人觉得ES比较先进，flexible schema, good scalability.
|
i**i
发帖数: 1500 | 23 如虫子所说，这种情况下用轮子是最简单的。 这种要求不高的情况一般的算法都足够
了。
我以前用过n-gram也不错。
用lunrjs做了一个demo.
http://plnkr.co/edit/9btihuQDQNGL8Fci9dx8?p=preview
{name:"Oak Hill Capital Partners"},
{name:"Oaktree Capital Management"},
{name:"Oberto Sausage Company"},
{name:"Oberweis Dairy"},
{name:"Occidental Petroleum"},
{name:"Oceaneering International"},
{name:"Ocean Spray"},
{name:"OCZ Technology"},
{name:"Odwalla Inc."},
{name:"O.F. Mossberg & Sons"},
{name:"Office Depot"},
{name:"OfficeMax"},
{name:"Olan Mills"},
{name:"Old Dominion Freight Line"},
{name:"Olin Corporation"},
{name:"Olympic Steel"},
{name:"Omaha Steaks"},
{name:"Omni Air International"},
{name:"The Omni Group"},
{name:"Omnicare"},
{name:"Omnicom Group"},
{name:"ON Semiconductor"},
{name:"ONEOK"},
{name:"Onvia"},
{name:"Open Interface North America"},
{name:"OpenTable"},
{name:"Opower"},
{name:"Oracle Corporation"},
{name:"Oracle Financial Services Software"},
{name:"Orbital Sciences Corporation"},
{name:"Oreck Corporation"},
{name:"O'Reilly Auto Parts"},
{name:"O'Reilly Media"},
{name:"Oshkosh Corporation"},
{name:"OSI Restaurant Partners"},
{name:"Overcast Media"},
{name:"Overstock.com, Inc."},
{name:"Owens Corning"},
{name:"Owens-Illinois"},
{name:"ABC Technology, LLC"} |
S*A
发帖数: 7142 | 24 虽然例子里面用 sub string Levenshtein distance 就可以匹配上了。
但是 LZ 都说了，Levenshtein distance 不一定够用。
所以 Lucene的fuzzy search 不见得一定够用。
我可以举个例子，因为我对花花草草比较熟悉：
John Deere Landscapes 和 Lesco， Inc 没有相同的 sub string，
但是这是同一个公司。因为 branding 的需要，这种情况很常见的。
保洁，飘柔等等。
我就是提些思路如何引入 Levenshtein distance 以外的衡量指标，
说的不清楚还请包含。
当然如果可以简化成用 Sub String Levenshtein distance 那
就简单多了，上轮子也可以。 |
d*******r
发帖数: 3299 | 25 多谢多谢！过来人一句话，省很多自己研究的时间。
【在 g*****g 的大作中提到】
: Solr/ES都是基于Lucene的，Lucene是一个搜索的库，Solr/ES是之上提供了应用级的支
: 持。
: 个人觉得ES比较先进，flexible schema, good scalability.
|
w******w
发帖数: 126 | |
x*******6
发帖数: 262 | 27 有木大牛比较下es和solr?我现在用solr的理由就是solr admin console好用，貌似es
没有现成的admin console?另外spring-data-solr是一个mainproject,可以用
repository什么的比较方便。 |
g*****g
发帖数: 34805 | 28 有 3rd party plugin， 开源的。
es
【在 x*******6 的大作中提到】
: 有木大牛比较下es和solr?我现在用solr的理由就是solr admin console好用，貌似es
: 没有现成的admin console?另外spring-data-solr是一个mainproject,可以用
: repository什么的比较方便。
|
g*****g
发帖数: 34805 | 29 不是说你说的是错的，而是说你指点的不 practical. 需要写轮子的人必然很熟悉轮子
。剩余的人不需要写轮子。先看够不够用，再补充。Lucene fuzzy search给你返回一
个 score，要加权其他算法，要 plugin同义词都很容易。同义词的支持都是内建的。
【在 S*A 的大作中提到】
: 虽然例子里面用 sub string Levenshtein distance 就可以匹配上了。
: 但是 LZ 都说了，Levenshtein distance 不一定够用。
: 所以 Lucene的fuzzy search 不见得一定够用。
: 我可以举个例子，因为我对花花草草比较熟悉：
: John Deere Landscapes 和 Lesco， Inc 没有相同的 sub string，
: 但是这是同一个公司。因为 branding 的需要，这种情况很常见的。
: 保洁，飘柔等等。
: 我就是提些思路如何引入 Levenshtein distance 以外的衡量指标，
: 说的不清楚还请包含。
: 当然如果可以简化成用 Sub String Levenshtein distance 那
|
G**Y
发帖数: 33224 | 30 你这个问题的定义，太vague
等你把问题定义清楚，solution，就显然了。
等等
Tec
是同
【在 f******k 的大作中提到】
: 一个公司信息的数据库，想检查其中是否有同一公司的多条记录，因为同一公司名可能
: 存在多种记法。比如ABC Tech, ABC Technology, ABC Technology, Inc, ABC, Inc等等
: 。尽管这些表达有可能其实是不同公司，但更有可能是同一公司。因此想把它们找出来
: 并返回给相关人员核查。这种核查不是针对某一家公司，而是数据库中所有公司。因此
: XYZ公司可能也存在这种问题。同时仅从字符串编辑距离上看，ABC vs XYZ比与ABC Tec
: hnology还小，但ABC和XYZ不太可能是同一条记录，而和ABC Technology反而更可能是同
: 一个公司。
: 当然，也存在记录输入错误，将ABC Tech输成了ABC Teck从而存在两条记录，但实际是
: 同一个公司。这种也希望能检查出来。
: 所以有什么更好的办法使聚类的结果更准确么？谢谢
|
|
|
B***i
发帖数: 724 | 31 建议楼主看一下local alignment ( smith-waterman algorith) 吧, |
N******K
发帖数: 10202 | 32 你这猴子搬弄工具 只曾笑料
【在 z****e 的大作中提到】
: 你这么说人家能看懂么？
: 我也看得一知半解的，统计的水还是太深了
: 不过我说一个相对容易点的哈
: 建立tdm
: 然后normalize下
: 最后点乘计算cos夹角
: 因为cos是递减函数
: 所以值越大，夹角越小，越接近
: 这个很容易算，不过有模型可以优化，需要人工介入比较好撒
|
N******K
发帖数: 10202 | 33 这就好比文科傻妞 分不清工科和理科一样
【在 b*******s 的大作中提到】
: 人家讲的是模式识别，扯什么统计
|
H****S
发帖数: 1359 | 34 Lucene 基本上是吧document看作bag of words，所以如果希望abc是在document的最前
面，best bet是用Term payload.
关于第二个问题，可以去看看Lucene提供的Porter stemmer |
f******k
发帖数: 43 | 35 多谢各位的热烈，专业的建议。后来用的办法是用两套打分规则，取高的。第一套是先
将The，Inc，Ltd这种无意义的词删除，将Technology，Management这种常见词替成1，
2个字母的缩写。然后计算编辑距离，距离越短，分数越高，认为相似度越高；第二套
是原始公司名全按单词拆开，所有公司名的组成单词汇总，计算出现次数；包含仅出现
一次单词的公司名，被认为很有可能是unique的，给0分；包含只出现过两次单词的公
司名被认为很有可能是一对duplicates，给一个高分，其他次数给分递减。
先用1万多的数据跑了一下，发现编辑距离的准确度高些，第二个方法基本不太准；由
于客户多是金融公司，大家起名都非常相似，比如ABC capital，ABC Capital
Management这种差异大部分情况其实是不同公司；个别的甚至仅ltd和lnc的差异就是两
家公司。所以false positive比较大。由于我们的数据是从专业的第三方买来了，所以
拼写错误的情况极为罕见，1万多里目前就发现1，2个。
而真正的重复对绝大部分集中在处理过的公司名的编辑距离是0或1上。这些重复对在原
始名上的差异主要是一个是全称，一个少了llc，inc，group这种后缀。也有同一家公
司的不同分支，比如ABC Private Equity，ABC ventures也被以很低的编辑距离找出来
了。
我不是学和专门做这方面的，只是公司想清理下客户数据，提高数据质量。大家提到的
好多专业内容不太懂，我会再去研究下，改进目前方法的质量。 |
S*A
发帖数: 7142 | 36 嗯，这个和我的预想比较接近，就是不能简单依赖通用的
text search, 需要加入 domain specific 的 knowledge。
关键在于，你需要塞选过数据之后，得出你现在公司重复的
不同原因。你现在的总结是，有些是简单拼写错误，（其少数）。
有些是漏掉些不关键的字，还有是公司不同的不同叫法。
所以比较常见的做法是针对不同的原因给不同的评分标准，
然后把这些不同的评分结果通过算法和数据训练合并起来。
公司的不同叫法和子公司这个必须要利用一些名字以外的
信息区分开来。你的例子里面有矛盾的两个方面，例如多
个 management 是个不同公司，差个 ventures 是同一个
公司等等。这些最好有外部信息来帮助判别。例如你如果
可以找出一个公司所有的分公司的信息就会有帮助。 |
m******n
发帖数: 187 | 37 赞。我们组正在用ES
【在 g*****g 的大作中提到】
: Solr/ES都是基于Lucene的，Lucene是一个搜索的库，Solr/ES是之上提供了应用级的支
: 持。
: 个人觉得ES比较先进，flexible schema, good scalability.
|
