【发布时间】:2015-10-27 14:27:15
【问题描述】:
我有一个文件中所有单词的频率计数(我用来分析和索引数据:elasticsearch),单词的频率遵循 zipf 定律。我如何使用这些知识来改进我的搜索?相反,我如何使用它来完成任何对我有利的事情?
【问题讨论】:
我有一个文件中所有单词的频率计数(我用来分析和索引数据:elasticsearch),单词的频率遵循 zipf 定律。我如何使用这些知识来改进我的搜索?相反,我如何使用它来完成任何对我有利的事情?
【问题讨论】:
我认为这是一个非常有趣的问题,我很难过这么长时间没有答案或评论。 Zipfian 分布是一种现象,不仅发生在语言中,而且远不止于此。
在这种情况下,Zipfian 分布或 Zipf 定律是词的秩频分布。但也许更重要的是,帕累托分布意味着大约 20% 的单词(原因)占任何给定正文或正文中大约 80% 的单词出现(结果)。 elasticsearch 背后的大脑 Lucene 以多种方式解释了这一点,而且通常超出了 zipf 定律。您的结果通常会包含 zipfian 分布。
这里的一个问题是,在大多数文本中,最常见的词实际上包含最少的上下文。通常是一篇文章或具有非常有限的上下文。英语中最常见的前 3 个单词是:“the”、“of”和“to”。 Elasticsearch 实际上带有一个stop words 列表,它将通过忽略文章来优化索引。
Elasticsearch 停用词:
a, an, and, are, as, at, be, but, by, for, if, in, into, is, it, no, not, of, on, or, such, that, the, their, then, there, 这些,他们, this, to, was, will, with
实际上,出现频率最低的单词包含最多的上下文是很常见的。因此,在进行文本搜索时,您可能会寻找频率最低的词。
elasticsearch 和 lucene 都是基于这些东西构建的,并且针对这些东西进行了很好的优化。一个简单的用于缓存索引的LRU eviction policy 实际上效果很好,因为您的 80% 的搜索可能会使用 20% 的实际索引,由于可预测的工作负载,缓存污染既不频繁,影响也很小。因此,如果您分配的缓存大小大于总索引大小的 20%,则应该没问题。如果索引不在缓存中,它将从磁盘读取(通常是 mmap),您可以通过使用具有快速随机读取的驱动器(如 SSD)来优化性能。
有一个有趣的article。您的数据集中的总单词排名可能与大多数其他数据集中的单词排名非常相似。因此,优化性能和相关性留给那些可能最不常出现但可能最常被搜索的单词。这可能是与您的应用程序所针对的人口统计/职业相关的术语。
但是,这些优化可能为时过早。就像我说的那样,lucene 和 elasticsearch 都在考虑这些原则的情况下为提高搜索的有效性和效率做出了自己的贡献。就像我之前所说的,一个简单的 LRU 缓存在这种情况下工作得很好,而且 LRU 既常见(已经是 ES 的一部分)又相对简单。可能值得的情况通常是您有很多行话或特定语言或多语种的情况。对于像新闻网站这样的东西,您可能需要更广泛的解决方案,因为您涵盖的主题范围很广,其中包括许多不同的词和主题。这些通常是您在配置 elasticsearch 时要考虑的事情,但是修改分析器可能很复杂,并且可能很难有效地完成,特别是如果您有大量具有不同术语的主题需要索引,但是这很可能对提高搜索相关性的影响最大。
【讨论】: