我使用的是solr4.1和qt=dismax。我也有一套类似的solr1.4。
当我用pf字段查询solr 4.1时，返回的结果在顶部没有匹配短语的文档。在我之前安装的solr 1.4中，我得到了正确的结果，即有短语的文档确实比没有短语的文档排名更高。
在solrconfig.xml中有这样的配置:
<requestHandler name="dismax" class="solr.SearchHandler" >
<lst name="defaults">
<str name="defType">dismax</str>
<str name="echoParams">explicit</str>
<float name="tie">1.0</float>
</lst>
</requestHandler>
My Query看起来像这样:
qt = dismax& q =产品% 20 manager& qf = summ_svc_descr +技能+ past_proj_tag + past_proj_name + past_proj_descr + login_name + business_name + primary_state + primary_country + primary_city +口号+ dtl_svc_descr +关键词+ about_us + parent_cat_name +经验+证书+ past_cat_name +组织+ company_login_name + company_business_name& fl = dtl_svc_descr + uniq_id, login_name, login_userid, parent_cat_name, parent_cat_id, net_score, business_name, business_name_sort, primary_state, primary_country, primary_city primary_zip, reviews_12mos reviews_positive_12mos feedback_avg_12mos、earnings_12mos reviews_positive_6mos, reviews_6mos, feedback_avg_6mos, earnings_6mos, earnings_overall,标语,summ_svc_descr, hourly_rate, is_individual, user_id,分数,tier_seller_id, file_upload_id, file_upload_name, new_provider, is_team, team_cnt,集中,技能,portfolio_yn, jobs_accepted_12mos, is_agent, company_userid, company_login_name, company_business_name available_y * *和pf = summ_svc_descr ^ ^ 1.8 + 1.2 +技能past_proj_tag + past_proj_name + past_proj_descr +经验+证书+标语^ 1.8 + dtl_svc_descr ^ 1.2 +关键词+ about_us ^ 1.2 * *,行= 25,= 0开始,wt = json
当我检查调试输出时，我看到parsedquery也对短语求值:
parsedquery_toString: "+((skills:product | about_us:product |关键词:product | past_proj_name:product | past_proj_descr:product |Past_cat_name:product | summ_svc_descr:product | past_proj_tag:product| company_login_name:product | parent_cat_name:product |Business_name:product | login_name:product |Company_business_name:product |凭证:product |经验:product | dtl_svc_descr:product | primary_state:product |Primary_country:product | primary_city:product | groups:product |广告语:产品)~1.0(技能:管理| about_us:管理|关键词:管理|Past_proj_name:manag | past_proj_descr:manag | past_cat_name:manag |Summ_svc_descr: managag | past_proj_tag: managag | company_login_name: managag| parent_cat_name:manag | business_name:manag | login_name:managCompany_business_name: management |资历:management |经验:managementDtl_svc_descr:manager | primary_state:manager | primary_country:manager| primary_city:manager | groups: manager | tagline: manager)~1.0)~2)(技能:"产品管理"~1^1.8 | about_us:"产品管理"~1^1.2 |关键词:"product manager"~1 | past_proj_name:"product manager"~1 |Past_proj_descr:"product manager "~1 | summ_svc_descr:"product manager .管理"~1^1.2 | past_proj_tag:"产品管理"~1 |经验:"产品管理"manager "~1 |凭证:"product manager "~1 | dtl_svc_descr:"product等"~ 1 ^ 1.2 |标语:"产品等"~ 1 ^ 1.8)~ 1.0"
我发现了这个问题。为了每个人的利益而发布答案。
pf参数和输出本身没有问题。这只是一个更深层次问题的征兆。
有一个自定义的相似性类(由开发人员在我之前工作，因为我从模式文件中发现)定义，导致许多文档的fieldNorm为0。多亏了详细的debugQuery输出，我能够找到问题，并且还弄清楚了如何实现每个字段的相似性。此外，我曾尝试使用Solr提供的默认相似性类，但这并没有帮助获得结果，因为我没有重新索引文档。如果我重新索引文档，就会更清楚地发现自定义相似性是罪魁祸首。
Solr在索引和查询时使用Similarity类。因此，无论何时选择更改模式中的相似性类，如果希望新的相似性类完全生效，很可能需要重新索引所有文档。