站在產品經理的角度，是否需要提升這兩個指標，具體又該如何與研發工程師協作呢？
如圖所示：
我們希望從全集中，選取中正確的部分（T），但是不可避免的會混雜壹些誤判（將錯的視作了正確的），因而得到了Precision 與 Recall
搜索的基礎模型，就是壹個按照詞對於文檔內容建立索引，再響應用戶檢索詞，按照索引結構篩選出對應文檔的過程。這也就是，為什麽我們在談及搜索的時候，總是不能免俗的要提到準確率和召回率的原因。
對於純數據指標的優化而言，算法依賴的有三：更準確、更大規模的樣本數據；更優化的模型；更強大的算力。
更優化的模型，往往趨近於模型、數學層面。當我們應用了更新的模型時，通常能夠得到更好的分類、預測效果。從早期的決策樹、機器學習方法 到如今的深度學習，模型的復雜度逐漸上升，模型的產出效果也得到了極大的提升。
強大的算力，從理想態回落到現實態，優化的計算模型是依賴計算能力支撐的。正所謂”壹力降十會“，只有足夠強大的計算能力作為後盾，我們才能夠支撐模型的在線、工業化應用。以我們熟悉的搜索引擎谷歌為例，谷歌的雲計算中心每天的耗電量相當於瑞士的日內瓦市整個城市的耗電量。
更準確、更大規模的樣本數據。算力支持下的模型，本質上是在做壹種擬合，即，在樣本數據的壹次又壹次“模考”中考出盡可能高的分數。樣本數據，作為讓模型擬合的對象，只有足夠豐富和準確，才能夠“訓練“出好的算法。否則，只會如那句老話”garbage in,garbage out”，提供給算法模型噪聲過大的數據， 最後只能得到壹塌糊塗的模型輸出。
從上面三者不難看出，和產品經理有關的是更多、更好樣本數據。
所以，我們才會不斷的進行標註，就像教授小朋友壹樣，不厭其煩的累積足夠多的正負樣本給算法作為計算的基礎，從而提升算法的有效性。在具體的工業應用中，我們還可以通過建設各種專向詞典的方式，如城市詞典、公司詞典、明星詞典，以近乎標準答案的輸入提升算法所依賴的數據質量。
產品經理思考的是什麽？特定場景下的用戶滿意度。
當用戶使用搜索時，需要是在最短的時間裏，收獲自己滿意的結果。
準確 和 召回指標，是我們對於用戶滿意的搜索結果的基礎描述，而非完備描述。
即，準確 和 召回不超過壹定閾值是不行的，但是當超過壹定閾值之後，這兩個指標對於用戶滿意度的貢獻就會邊際效應遞減。
產品經理需要結合場景，更多的去思考用戶會因何而滿意。
壹個典型Case，用戶搜“天氣”。他只需要壹個準確的天氣結果，就可以了。
用戶不關心召回率，即用戶不關心我們從全網10W的天氣網站裏，給他召回了9W 還是 9.9W的結果。弱水三千，壹瓢足已。
進壹步，當用戶搜索意圖特別明確的時候，我們甚至可以不需要讓用戶點擊鏈接，而是直接將結果前置到搜索結果頁面上就可以了，這就是百度搜索阿拉丁卡片的意義。
從提升用戶滿意度這個角度出發，還會有更多可以思考的問題。
比如，用戶搜索“iPhone”的時候，意圖是相對不明確的。
他究竟是想要購買iPhone，查看iPhone相關的評測文章，還是訪問蘋果官網呢？
在這種情況下，我們只能根據統計的角度，按照大多數人的偏好進行結果的排序
再進壹步呢？
就是產品經理要發力的場景了，如何通過交互來細化用戶的意圖。
這也是今天我們看到相關搜索會被插入到搜索結果裏的願意，讓用戶能夠更快的通過相關搜索的建議，細化自己的意圖，從而給機器更多有效的輸入。
指標是重要的，指標能夠讓不同的團隊圍繞業務達成壹致性的評價指標；
指標不是唯壹，物理世界是立體而豐富的，指標是我們對於物理世界的降維、數據化擬合，過程中也壹定損失了壹些信息。
比如，在準確率 和 召回率的角度，我們有如下預設
但事實上，很多搜索結果是高度同質化，可以被相互替代的；在不同結果中，相對越權威的網站，其提供的結果權重相對越高。
所以，對於策略產品經理而言。當然可以追指標，但是在追指標之余，還需要站在時間的維度，階段性的反思、重構場景：
想想在當下的場景下，用戶的需求有什麽特別之處？是否需要新的策略來滿足？是否需要新的指標來衡量？才能夠帶來更多的可能性。