对于搜索业务而言，绕不开的指标是准确率与召回率。
站在产品经理的角度，是否需要提升这两个指标，具体又该如何与研发工程师协作呢？
什么是准确率（Precision） 与 召回率（Recall）
如图所示：
我们希望从全集中，选取中正确的部分（T），但是不可避免的会混杂一些误判（将错的视作了正确的），因而得到了Precision 与 Recall
- Precision: 筛选出的正样本中，有多少判断对了。
- Recall：在全部正样本中，有多少被筛选出了。
搜索的基础模型，就是一个按照词对于文档内容建立索引，再响应用户检索词，按照索引结构筛选出对应文档的过程。这也就是，为什么我们在谈及搜索的时候，总是不能免俗的要提到准确率和召回率的原因。
指标出发，如何对准确率、召回率产生贡献
对于纯数据指标的优化而言，算法依赖的有三：更准确、更大规模的样本数据；更优化的模型；更强大的算力。
更优化的模型，往往趋近于模型、数学层面。当我们应用了更新的模型时，通常能够得到更好的分类、预测效果。从早期的决策树、机器学习方法 到如今的深度学习，模型的复杂度逐渐上升，模型的产出效果也得到了极大的提升。
强大的算力，从理想态回落到现实态，优化的计算模型是依赖计算能力支撑的。正所谓”一力降十会“，只有足够强大的计算能力作为后盾，我们才能够支撑模型的在线、工业化应用。以我们熟悉的搜索引擎谷歌为例，谷歌的云计算中心每天的耗电量相当于瑞士的日内瓦市整个城市的耗电量。
更准确、更大规模的样本数据。算力支持下的模型，本质上是在做一种拟合，即，在样本数据的一次又一次“模考”中考出尽可能高的分数。样本数据，作为让模型拟合的对象，只有足够丰富和准确，才能够“训练“出好的算法。否则，只会如那句老话”garbage in,garbage out”，提供给算法模型噪声过大的数据， 最后只能得到一塌糊涂的模型输出。
从上面三者不难看出，和产品经理有关的是更多、更好样本数据。
所以，我们才会不断的进行标注，就像教授小朋友一样，不厌其烦的累积足够多的正负样本给算法作为计算的基础，从而提升算法的有效性。在具体的工业应用中，我们还可以通过建设各种专向词典的方式，如城市词典、公司词典、明星词典，以近乎标准答案的输入提升算法所依赖的数据质量。
业务出发，准确与召回不是唯一
产品经理思考的是什么？特定场景下的用户满意度。
当用户使用搜索时，需要是在最短的时间里，收获自己满意的结果。
准确 和 召回指标，是我们对于用户满意的搜索结果的基础描述，而非完备描述。
即，准确 和 召回不超过一定阈值是不行的，但是当超过一定阈值之后，这两个指标对于用户满意度的贡献就会边际效应递减。
产品经理需要结合场景，更多的去思考用户会因何而满意。
一个典型Case，用户搜“天气”。他只需要一个准确的天气结果，就可以了。
用户不关心召回率，即用户不关心我们从全网10W的天气网站里，给他召回了9W 还是 9.9W的结果。弱水三千，一瓢足已。
进一步，当用户搜索意图特别明确的时候，我们甚至可以不需要让用户点击链接，而是直接将结果前置到搜索结果页面上就可以了，这就是百度搜索阿拉丁卡片的意义。
从提升用户满意度这个角度出发，还会有更多可以思考的问题。
比如，用户搜索“iPhone”的时候，意图是相对不明确的。
他究竟是想要购买iPhone，查看iPhone相关的评测文章，还是访问苹果官网呢？
在这种情况下，我们只能根据统计的角度，按照大多数人的偏好进行结果的排序
再进一步呢？
就是产品经理要发力的场景了，如何通过交互来细化用户的意图。
这也是今天我们看到相关搜索会被插入到搜索结果里的愿意，让用户能够更快的通过相关搜索的建议，细化自己的意图，从而给机器更多有效的输入。
如何理解指标
指标是重要的，指标能够让不同的团队围绕业务达成一致性的评价指标；
指标不是唯一，物理世界是立体而丰富的，指标是我们对于物理世界的降维、数据化拟合，过程中也一定损失了一些信息。
比如，在准确率 和 召回率的角度，我们有如下预设
- 召回越多越好
- 所有结果是同等重要的。
但事实上，很多搜索结果是高度同质化，可以被相互替代的；在不同结果中，相对越权威的网站，其提供的结果权重相对越高。
所以，对于策略产品经理而言。当然可以追指标，但是在追指标之余，还需要站在时间的维度，阶段性的反思、重构场景：
想想在当下的场景下，用户的需求有什么特别之处？是否需要新的策略来满足？是否需要新的指标来衡量？才能够带来更多的可能性。
