利用開源做的搜尋結果排序目前主要兩種計算方式：索引時做好了score計算和查詢時動態計算。各有優缺點，適合不同業務。
搜尋結果排序需要考慮的點比較多，比如設定不同字段不同比率來計算score，這些欄位的**是否一致，其包含的資訊多大，其如何儲存。如果需要動態調整，那麼其改動成本多大（人員，硬體，時間，金錢等）？如果多台機器，那麼是否需要mapreduce，結果是否cache，cache更新，資料一致性。如果有預處理又該如何做。索引和搜尋如何協調一致等。
比較講究的還需要不斷修改搜尋結果排序演算法來達到準確，快速的目的。
還不確定的，垂直搜尋，隨便找個開源分詞的，然後設定死與score相關的字段的比率就夠了。
好的搜尋結果排序不在於一時，而在於不斷改進，一如我相信美好的東西是需要反覆鍛造。
再說搜尋結果排序策略
很多平台 會開發自己的搜素，如果要排序維度越多排序的難度越大。因其所涉及的排序引數和考量因素會很複雜，但終究沒有理想排序的結果原因不是不知道引數 因素的是否完備，而是其數學建模的不合理性 img 這類很明顯看到的結果是發散的，因為搜素小吃的目標人群無法判定，可能有美食者 經營者 學習者 研究者等等，...
使用lucene對搜尋結果排序
lucene預設根據匹配度對搜尋結果降序排,如果對某個域進行排序?通常分兩步 step1 建索引時 newfield audittime row.get audittime tostring 關鍵點是你需要排序的字段建索引時應該採用 field.index.un tokenized,至於需不需要 f...
使用lucene對搜尋結果排序
lucene預設根據匹配度對搜尋結果降序排,如果對某個域進行排序?通常分兩步 step1 建索引時 newfield audittime row.get audittime tostring 關鍵點是你需要排序的字段建索引時應該採用 field.index.un tokenized,至於需不需要 f...