我目前正在研究Lucenes MoreLikeThis的修改版本,以符合我自己的目的。 有一件事我还是听不懂。 创建队列时,MoreLikeThis会搜索此术语的docFreq最高的字段。
// go through all the fields and find the largest document frequency
String topField = fieldNames[0];
int docFreq = 0;
for (int i = 0; i < fieldNames.length; i++) {
int freq = ir.docFreq(new Term(fieldNames[i], word));
topField = (freq > docFreq) ? fieldNames[i] : topField;
docFreq = (freq > docFreq) ? freq : docFreq;
}
此字段将在TermQuery中使用。这会产生奇怪的结果。
例如,假设您有两个字段“title”和“body”,并且有两个文档具有完全相同的标题,但它们不匹配,因为“标题”中的所有单词更经常出现在其他文件中“身体”,反之亦然。这对我来说似乎很奇怪。
另一个例子:我在一个系统中使用它,它通过依赖于用户的访问权限过滤结果,并且发生了生成查询的用户无法看到负责高docFreq的文档。选定的领域。生成的查询没有找到任何文档,尽管用户可以看到很多文档,包含确切的术语,只是在错误的字段中。
我想知道为什么他们不仅仅使用所有字段,或者至少使用最初出现这些字词的字段。 当然,这可能是性能问题。但是我已经实现了它以使用原始文档中出现该术语的所有字段,以及具有最高docFreq的字段。我在一个包含数千个文档的索引上测试了它,看不出任何差异(但我没有做任何基准)。
那么,任何人都可以告诉我为什么以这种方式实施它? 我能想到的唯一原因就是在一个包含大量字段的真正大指数上表现出色。
//编辑:我实施了第一个示例来澄清问题:http://pastebin.com/fwdENb3F
答案 0 :(得分:2)
您应该将MoreLikeThis
视为不适合所有用途的参考实现。
如果实现只针对一个字段,那么我们将会看到如下问题:为什么它只搜索标题字段并完全错过两个图书文档具有相同的作者。
您可以使用setFieldNames设置要查找相似性的字段。
创建自己版本的MoreLikeThis
听起来像是最好的方法,特别是考虑到你需要考虑ACL。