想象一下我有两个数据源。一个来源正在为AP M\xc3\xb8ller - M\xc3\xa6rsk A调用 M\xc3\xa6rsk ，而另一个来源为AP M\xc3\xb8ller - M\xc3\xa6rsk A/S。现在我有很多公司，我想简化这些公司的命名。
\n\n这两个来源都在 elasticsearch 中建立了索引，但我是这项技术的新手，无法提出适当的搜索查询。我最初的想法是使用common它给出不错的结果，但我认为还有更好的方法。
有什么建议么？
\n\n稍微澄清一下。我的两个来源只是提供公司名称的数据源。我已将这些名称存储在每个源的自己的索引中 - 文档只是名称。
\n\n所以我有两个带有公司名称的索引（没有其他内容）。现在，对于索引中的每个公司名称，A我想在索引中找到相应的公司B。挑战在于公司名称的书写方式有很多种——它并不标准化。我希望以尽可能少的体力劳动和最小的错误风险来创建此链接。
鉴于不久前有人问过这个问题，OP 可能已经不再讨论这个问题了。例如，common 现在已被弃用。但如果它对其他人有帮助，这里有一些指南：
据我从问题中了解到的，问题是这样的：我在两个不同的数据源中有两个公司名称。一是：
\n\nAP M\xc3\xb8ller - M\xc3\xa6rsk A
\n\n另一个是：
\n\nAP M\xc3\xb8ller - M\xc3\xa6rsk A/S
\n\n假设它们代表同一家公司，问题是如何将它们解析为单个规范名称（例如，“M\xc3\xa6rsk”，如果在这种情况下这是一个合适的名称）。
\n\n此外，我们如何以尽可能自动化的方式在大量公司名称中执行此匹配过程？
\n\n一个警告 - 让此类任务可重复通常是值得的 - 即使您认为这将是一次性的清理工作，但它通常不会以这种方式结束（恕我直言）。
\n\n在这种情况下，通常不可能获得全自动匹配解决方案 - 通常需要一些手动干预。但你也许能够接近。
\n\n我会采取一些自由 - 例如，我会忽略“两个不同的数据源”方面。相反，我假设我们有一个总体列表，即两个来源的联合（因为每个列表中可能存在名称变体）。
\n\n以下是在类似领域（电影标题）中对我广泛起作用的方法。
\n\n全面披露：就我而言，我没有使用 ElasticSearch。我使用 Lucene 和一些自定义 Java。但在这个背景下，有很多相似之处。我下面的参考资料都是 ElasticSearch v7.5 功能。
\n\n问题表明数据已经被索引 - 但使用什么标记化步骤？一些建议（可能已经在OP的案例中实施）：
\n\n考虑保留 停用词。这不是一个硬性规定，但请考虑一下如果删除停用词，The The乐队会发生什么。没有什么可以索引的。在相对较短的文本（例如名称）中，停用词可能太重要而无法删除。
考虑使用ascii 折叠等来规范化文本（删除变音符号，例如\xc3\xa9to e；扩展连字，例如\xc3\xa6to ae；等等。这假设您使用的是基于拉丁语的文本。与其他脚本（中文等）不太相关。 ）。
考虑针对您的问题域进行定制。例如，可能存在命名法变体，例如在公司名称中表示单词“Limited”的“LTD”、“Ltd”等。或者在某些示例中使用“&”，但在其他示例中使用“and”。“Smith & Sons, Ltd”与“Smith and Sons Limited”。
其他转换（例如小写和删除标点符号）更加简单。
OP 可能无法访问其中的任何内容 - 但支持元数据对于确定两个名称变体是否引用同一实体至关重要。电影世界的一个例子：IMDb 中有两部电影名为“踢与尖叫” - 以及许多电视剧集。可以通过比较相关元数据来区分它们，例如：
\n\n我不知道对于公司来说相当于什么。
\n\n一种相当粗略的技术是将此类数据附加到每个公司名称中，从而增加每个可索引术语中可用的代币数量。
\n\n或者，可以在下游使用元数据数据来进一步验证两个术语是否匹配。
\n\n假设我们有简单的词边界索引术语（尽管还有很多其他方法 - ngrams、shingles等）。
\n\n现在，我们对每个公司名称（加上其他元数据，如果我们添加了它）执行搜索。
\n\n假设我们已经定义了一个阈值分数，搜索结果必须达到该阈值才能被视为匹配。分数应该可以轻松调整以调整匹配行为。
\n\n如果我们只得到一个超过此分数的匹配，我们可以假设我们有一个自动匹配：这两个名称代表同一家基础公司。
\n\n如果我们得到超过此分数的零个匹配项，那么我们可以假设该公司名称在我们的数据集中是唯一的。
\n\n如果我们获得多个匹配项，则可能需要手动干预，以确定名称是否相同。
\n\n目的是最大限度地减少误报匹配，同时最大限度地减少匹配失误。
\n\n你怎么知道？
\n\n我对此唯一好的答案是生成一组测试用例。最好的方法是研究数据，这样你就可以找到适当的狡猾和狡猾的案例来测试。
\n\n这一切听起来工作量很大。你实际做了多少，或者做了多少——多严格或多粗略——都取决于你。当然，取决于您的背景。
\n| 归档时间： |
|
| 查看次数： |
1080 次 |
| 最近记录： |