我们使用solr版本3.5来搜索推文,我使用WordDelimiterFactory以下设置,以便能够搜索@username或#hashtags:
<filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="0" splitOnNumerics="0" preserveOriginal="1" handleAsChar="@#"/>
我看到了以下补丁,但这似乎没有像我预期的那样工作,我错过了什么？
https://issues.apache.org/jira/browse/SOLR-2059
但是搜索@username也#hashtag只返回用户名的结果,或者只返回hastag的结果.我怎样才能做到这一点？
整个字段类型:
<fieldType name="textnostem" class="solr.TextField" positionIncrementGap="100" autoGeneratePhraseQueries="true">
<analyzer type="index">
<charFilter class="solr.HTMLStripCharFilterFactory"/>
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.StopFilterFactory"
ignoreCase="true"
words="stopwords.txt"
enablePositionIncrements="true"
/>
<filter class="solr.WordDelimiterFilterFactory"
generateWordParts="1"
generateNumberParts="1"
catenateWords="1"
catenateNumbers="1"
catenateAll="0"
splitOnCaseChange="0"
splitOnNumerics="0"
preserveOriginal="1"
/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
<analyzer type="query">
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.StopFilterFactory"
ignoreCase="true"
words="stopwords.txt"
enablePositionIncrements="true"
/>
<filter class="solr.WordDelimiterFilterFactory"
generateWordParts="1"
generateNumberParts="1"
catenateWords="1"
catenateNumbers="1"
catenateAll="0"
splitOnCaseChange="0"
splitOnNumerics="0"
preserveOriginal="1"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer> …ShingleFilterFactory在solr(索引时间)中添加类型会导致在使用突出显示进行队列时更改行为.
示例文本:"在一艘船中,一条龙在一个盒子里"
没有ShingleFilterFactory两个"in"标记将单独突出显示.
<em>in</em> a ship a dragon was <em>in</em> a box
有了它,整个段将作为单个突出显示返回.
<em>in a ship a dragon was in</em>
为什么使用'ShingleFilterFactory'会影响突出显示？
编辑:
根据请求添加架构信息:
<fieldType name="text_general" class="solr.TextField" positionIncrementGap="100">
<analyzer type="index">
<charFilter class="solr.HTMLStripCharFilterFactory"/>
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true"/>
<filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
<filter class="solr.ShingleFilterFactory" maxShingleSize="2" outputUnigrams="true"/>
<filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
<analyzer type="query">
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
</fieldType>
text_general如上所述,使用包含木瓦过滤器的内容会产生异常大的高亮字段.
首先，我已经看到了lucene 文档，它告诉我们不要以百分比形式生成分数：
人们经常希望根据 Lucene 分数计算“百分比”，以确定什么是“100% 完美”匹配与“50%”匹配。这也称为“标准化分数”
不要这样做。
严重地。不要再试图以这种方式思考你的问题，它不会有好结果。
由于这些建议，我使用了另一种方法来解决我的问题。
然而，lucene的论证有几点我不太明白为什么它们在某些情况下会出现问题。
对于这篇文章的情况，我可以很容易地理解为什么它不好：如果用户进行搜索并看到以下结果：
如果 ProductA 在第一次搜索后被删除，那么用户下次再来时，如果看到以下结果，他会感到惊讶：
所以，这个问题正是Lucene的文档所指出的。
现在，我们再举一个例子。
想象一下，我们有一个电子商务网站，它使用“经典搜索”与语音搜索相结合。此处的拼音搜索是为了避免由于拼写错误而导致最大数量的空结果。相对于经典搜索的分数，拼音结果的分数非常低。
在这种情况下，第一个想法是只返回至少具有最高分数 10% 的结果。即使使用经典搜索，低于此阈值的结果也不会被视为与我们相关。
如果我这样做，我就不会遇到上述帖子的问题，因为如果删除文档，如果旧的第二个产品成为第一个产品，那么似乎合乎逻辑，并且用户不会感到非常惊讶（这与以下行为相同）如果我将分数保留为浮点值）。
此外，如果语音搜索的分数非常低，正如我们预期的那样，我们将保持相同的行为，仅返回相关分数。
所以我的问题是：像 Lucene 建议的那样标准化分数总是不好吗？我的例子是一个例外还是即使对于我的例子来说这样做也是一个坏主意？
我试图使solr返回与建议完全匹配,例如:
我正在使用此字段获取建议:
<fieldType name="textSpellShingle" class="solr.TextField" positionIncrementGap="100">
<analyzer>
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.ShingleFilterFactory" maxShingleSize="3" outputUnigrams="true"/>
<filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
</analyzer>
</fieldType>
任何想法如何使Solr返回精确匹配建议？