很多平台**會開發自己的搜素，如果要排序維度越多排序的難度越大。因其所涉及的排序引數和考量因素會很複雜，但終究沒有理想排序的結果原因不是不知道引數/因素的是否完備，而是其數學建模的不合理性；
[img]
這類很明顯看到的結果是發散的，因為搜素小吃的目標人群無法判定，可能有美食者、經營者、學習者、研究者等等，所以更夠根據全網的資料和使用者的搜素趨勢來加權處理乙個比較廣泛的結果是難能可貴的；
這樣有人會問，那我什麼也找不到啊？這是什麼結果啊？
（猜你喜歡，是個更高的境界，下面再說）
但就初次使用者的需求難以確定的特性，這樣的結果，存在20%匹配的機率，剩下的80%中會有20%使用者根據推薦，採用更為精確的二次搜尋來滿足搜尋需求；
這樣的建模是非常有道理的，然而對於垂直的平台**這個數字就非常不合理了；
下面我們再來看一下，這樣的初次查詢時按照怎樣的維度來構建的。這要看我們的老大哥谷歌了，
[img]
從時空隧道我們可以看到主要的維度劃分，當然這不是全部，比如資訊、論壇以及現在的實時性內容如微博等。
這裡就不得不說下「猜你喜歡」，在全網搜尋引擎中目前也只有谷歌做到了，「試試手氣」=「猜你喜歡」 對使用者行為的二次猜測，看起來很簡單做起來非常之難；
從技術角度來看，google的搜素排序演算法是領先的！！！
搜尋結果排序
利用開源做的搜尋結果排序目前主要兩種計算方式 索引時做好了score計算和查詢時動態計算。各有優缺點，適合不同業務。搜尋結果排序需要考慮的點比較多，比如設定不同字段不同比率來計算score，這些欄位的 是否一致，其包含的資訊多大，其如何儲存。如果需要動態調整，那麼其改動成本多大 人員，硬體，時間，金...
使用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...