前段時間在給一家世界500強企業做諮詢，課題是企業級門戶的搜索策略。
光看這個課題，大家肯定會聯想到谷歌，Bing，百度之類的搜索引擎。對企業搜索有些接觸的人，也許會聯想到Autonomy（國外知名搜索服務提供商），或是拓爾思（國內知名企業搜索服務商）。
雖然說採用這些成熟產品不失爲是一種快捷有效的實現方法，但是，企業的特有業務形態和長遠技術規劃將往往促使他們做出更穩妥的決定：比如，從世界的頂級諮詢公司購買解決方案，再決定是否採購成熟的技術和服務組件或與本土IT公司合作開發，打造企業自主知識產權的產品。
爲什麼這麼做？我認爲有三個原因：1、地域及環境因素；2-制約與反制約的博弈。3-長遠規劃需要。
那麼到底該如何爲一個企業來做搜索策略的設計呢？
具體到這個案例，我們首先來看看具體的客戶需求（場景）：一個數十萬員工的企業，分支機構分佈在世界各地，需要在企業內部門戶上提供面向全體員工的統一搜索服務，搜索的內容包括企業內應用所產生的業務數據以及企業員工相關信息。其次，用戶基於預算及長遠考慮，並不打算購買成熟的企業搜索產品。
再來看看數據分析，企業內部每天產生的有效業務數據在300萬條記錄左右，假設這300萬條數據都屬於可被搜索的範圍。
從案例的背景，我們可以理解和分析得出：
1-以企業內部應用爲搜索界定範圍，以應用產生的業務數據爲搜索目標（屬於ESI範疇），以企業的所有員工爲搜索服務的提供對象。因此，是橫跨企業內部多業務域、多應用的核心級別項目。
2-設計的重點在於數據的獲取（創建索引）和隱私的控制（安全搜索）。
3-需要採用開源的搜索組件和服務，比如基於Solr技術。
4-索引數據將非常龐大，需要做一些優化策略來解決性能風險。
Ø 首先，做業務的頂層設計
我們將這種搜索應用稱爲“企業統一搜索”。企業統一搜索的入口將放置在企業的內部門戶portal，這也是因爲需要基於portal的一部分有效資源。比如，4A訪問控制，搜索結果對應app的sso訪問跳轉。
對於搜索的信息分類設計，從搜索結果的展現形式上來看，可以將搜索劃分爲搜索信息，搜索企業員工，搜索應用，搜索知識，搜索圖片，搜索視頻等。
對於搜索的展現設計，要符合流行的google，百度展現要求，即以標題+簡介+關鍵項爲展現基礎，其中關鍵項基於業務的不同而所指不同，比如，包括圖片縮略，時間，作者，tags，url，icon等。具體由企業統一搜索應用提供不同的展現模版供其它應用調用。
對於搜索的準確性要求，需要通過搜索權重管理，faccted search，Poka-yoke技術，相關搜索技術等來滿足。
對於數據採集的設計，要求企業統一搜索提供統一的index索引接口，由其它app進行推送。同時，也要考慮索引失效的問題和人工干預的需要。另外，採用爬蟲技術解決某些app無法通過接口調用推送數據而提供搜索服務的問題，爬蟲技術（Spider）將主動定期爬取目標系統頁面有價值的數據。
對於權限設計是企業搜索和互聯網搜索的最大不同，企業內部的業務信息大都是有瀏覽範圍控制的，因此在做搜索的數據訪問權限設計時，最大問題是權限的推送和搜索控制。
Ø 接下來，做技術解決方案的探討
常見搜索的邏輯如下所示：
或者：
而在企業搜索中，我們需要這樣的技術架構：
在處理邏輯上，我們採用下面的流程：
從搜索的技術層面考慮，主要解決這麼幾個問題：
1- 數據採集
提供統一的數據index接口，接口內容包括數據類型，來源，URL，主題，正文，標籤，摘要，創建人，創建時間，保存期限，可訪問角色，可訪問用戶，可訪問組織等。
提供一個spider程序，定向爬取目標系統頁面內容，並自動調用index接口，建立索引。
提供一箇中間數據文本，部分對應系統可以通過導出數據到中間文本方式提供索引數據。
2-權限控制
通過接口採集數據的可瀏覽角色，用戶和組織範圍，將實際業務中可能出現的場景基本覆蓋。
還提供兩種場景，其一，搜索結果中可展示，但點擊無法瀏覽詳情，即通過目標應用來控制實際的瀏覽權限。但此方案將導致部分重要信息出現標題或摘要泄漏情況。其二，通過solr控制搜索結果，將無權限訪問的數據直接過濾掉，不出現在搜索結果中。但這種處理方式非常容易出現效率問題。
因此，我們一般會建議用戶建立企業內部信息索引建立規範，比如，允許全員公開的數據推送索引，允許以組織層級公開的數據推送索引，允許以角色公開的數據推送索引，允許以好友圈子公開的數據推送索引；其它類型的數據建議不推送索引，如有必要，可以由應用提供單獨的搜索服務調用方式，供企業統一搜索調用，進行統一的UI展現。
3-規則引擎
規則引擎主要解決除搜索權重，faccted search，相關搜索，敏感詞等之外的業務邏輯規則。比如，關鍵用戶信息的隱藏處理，索引外信息的獲取和拼裝，索引自修復規則等。
4-UE設計
除了前面提到的Poka-yoke技術，faccted技術，相關搜索技術，在搜索展現上還要體現不同信息的匯聚關聯性。比如，關聯搜索提示，高級搜索，搜索糾錯等。
搜索的體驗異常重要，例如，在搜索員工時，在搜索結果中需要將本部門的同事放在首位，其次是本公司的員工，再是關鍵用戶。
5-性能和命中率設計
如果一次搜索花費了30秒纔出現結果，而且沒有滿意的搜索內容，那麼這種體驗將是致命的。
因此，對於性能的設計要考慮的index的檢索效率優化，規則邏輯處理效率優化，UI渲染效率優化等。比如，就用戶每天300萬條業務數據推送到索引來看，如果不及時有效的做索引數據的清理，將會在很短的時間內讓索引庫龐大不堪，在不採取分佈式的存儲策略前，只能定期的做清理來緩解效率的問題。況且，企業內能真正採用分佈式存儲架構的還真爲數不多。
關於命中率的問題，一般通過調整權重指標，做好日常的受控詞表維護往往能很快解決。關於權重指標，這裏一般分爲業務權重和數據項權重，比如業務權重是按照數據來源app重要程度來劃分權重，數據項權重一般是基於數據的業務屬性的重要性來劃分權重，比如關鍵詞出現在標題中就比出現在正文中的權重要高。
6-非結構化數據的展現問題
現在企業的數據中有 80% 屬於非結構化信息。這其中包括了Word文檔，Excel表格，PDF文件，掃描圖片，電子郵件，電話記錄、語音留言、紙質文檔、照片、網頁、視頻以及其他形式的內容。由於很多企業缺乏能夠理解並有效利用這些內容的技術，使得非常有價值又充滿戰略意義的資源常常無法發揮其作用。因此，在搜索的展現過程中，要充分的考慮這類非格式化數據的展現，比如，搜索到的是圖片，一般需要在搜索結果中直線展現縮略圖，點擊伸展瀏覽大圖；如果搜索的是一段音頻或視頻，那麼需要在結果展現中能進行快捷播放，而不是僅僅跳轉到目標頁面。