想到哪，yy到哪。纯属YY，欢迎讨论！
搜索，我看到或者理解到的发展方式，这里强调的是看到、理解到的，并非一一经历到，存在错误或者误解的地方，自行消化。哈哈
当前从网络上听到、看见到、经历到的几种发展方式

1. 发展方式

1.1 依托门户入口

依托门户入口流量，期待从这里入口，打开搜索的市场。雅虎中国的搜索、新浪门户搜索等。

1.2 依托某种网站

依托特殊覆盖的pc网站，期待每次“关联”的请求，打开搜索的市场。万网搜索、esou搜索。

1.3 依托某种概念、新产品

在航母上驻扎一个新产品，靠航母效应。阿里云开放搜索。

1.4 依托技术托管、出售技术

早期百度的起家。

1.5 顺着无线的新型市场的未成熟

神马搜索、百度无线搜索

1.6 依托强大的浏览器用户

360搜索、搜狗搜索

1.7 依托一个个真实的垂直需求

成功的案例：某数字公司确实是凭借入口，抢夺了市场。浏览器入口。失败的或者没有起色的案例：数数都是了。

那么，怎么样的推销 “搜索产品”或者“定位搜索产品”或者”实践搜索平台“，才靠谱，或者说是否能发展起来？我说说发展不好的东西吧。也就是搜索自身的一些特点。

2. 存储和检索兼并的，效果是重点    

要考虑数据的存储、数据的检索。不能浪费成本！而这还不算神马，效果优先的时候到了。90% ok就上，有时候等于没上。连续几次bad case 搜索，用户就受到伤害了，不会再选择了。基本没伤害，等于没有任何“利益”导向，多在光域网场景、或者说数据本身表意范围明确，多在垂直场景。

3. 业务场景强相关的    

分词、排序、数据格式、展示，这些都是因业务场景而必须具体制度的。    

在谈细分人群，然后走个性化排序的时候。忽略了业务垂直特性，eg 在房产里面输入 美妆，弹出 女装信息明显不合理的。因为忽略了垂直业务特性。

4. 搜索动态过程

任何搜索的产品都是，并且必须是动态的过程，不可能理解是是一次性的。    

如果是一次性接入而无升级、优化，这个搜索其实是没有生命力的。    

数据没有变化，搜索质量没有持续跟进，这其实就沦落一般的业务需求了，而没有体现搜索的价值。  

-----帮助改善数据发现、展示的效果，并且是动态持续的过程。

5. 实际过程资源的不自觉的倾斜      

架构师会一味的追求架构，大部分时间用在设计上。引擎工程师会关注每个细小点的性能优化。算法工程师，必须首先寻求业务场景，然后是持续的迭代优化效果。      

上层的KPI分解到搜索团队，就变味了。整个互联网的大的现象：短期效果优先。架构的改动更能立竿见影，而引擎的优化，是需要多场景配合并且是“隐藏”的，算法就更悲曲了，持续优化基本无望，除了豆瓣那种就本着算法迭代、反复迭代提升数据沉淀、产品口碑。

6. 发展思路导致侧重点的不同      

产品经理来看搜索，只追着算法团队转。技术经理来看搜索，只追着架构团队转。非技术非产品的，来看搜索，看不到架构、看不到算法，要的就是最终的速度、首页效果！架构+引擎+算法构成了搜索产品的三大核心块。      

正确的领导搜索产品的理念、方式非常关键。谋求人的发展or 谋求产品的发展也是很有趣的现象。谋求人的发展然后发展产品，谋求产品的发展然后谋求人的发展。好比，系统要兼顾 卖家+买家+平台三方的利益，才可能实现持续化、健康发展。

7. 开源技术 和 自研发技术    

 其实，各有优缺点。市场的选择、业务的选择可能是个不错的标准。      在云趋势下，包容是首要的、也是必须的。一统天下、一套系统，肯定走不远，也缺少生命力。势必在自研发和开源引擎上做兼容、吸收。

8. 为何过去没有先例 通用搜索    

百度、google搜索做了这么多年，这么强大，为何他们从不提通用搜索？开放搜索？云搜索？
       通用搜索、平台化搜索应该是垂直搜索的代名词，立足垂直搜索才是通用搜索的基础点？！通用搜索在云计数的兴起时刻，又登陆了，尝试着能有一席之地在互联网产品发展。贴近用户需求、解决用户需求，口碑的积累非常关键。一开始打口号、宣传什么好的技术，对用户来说看不到实惠。因为接入通用搜索的，首先并且大部分是技术。对技术来讲，易用、快捷、稳定是王道。架构、引擎、算法，需要养，但不是战。找需求、解决需求、来客户的过程中，推动养转为战。

9. 通用搜索计费问题

从浅层次面或者直观面看，数据量、访问量计费。

优势：可以理解性、收费可解释性、预算可以空等。既可以帮助业务方，也可以帮助平台。

劣势：通用平台化后的入驻业务，往往有两个极端，一个是数据量大，访问量小，或者说自然搜索访问少，而数据聚合性导出非常多。

另外一个是访问量大，数据少。从真实的消耗资源看，访问量大、数据量小，并没有增加多少资源消耗，相比系统越NB，消耗的资源越少。而数据量大，从磁盘+内存的绝对资源就在那里了。外加，深度翻页、大区间等数据帅选，资源消耗巨大，把访问频次降低了，而增加了单次对资源的hold时间。也间接的导致：合并请求、加大请求复杂度、带来系统稳定性风险。

改进的思路

简单query计费因子偏小、复杂query计费因子偏大、数据量单独计费并且总体上鼓励简单query，促进请求优先。（试图推动业务的活跃性、搜索不活跃，慢慢就死掉了业务）。这样收费，可解释性、预算可控性相对复杂些。复杂query+简单query的比例，业务方往往自己也不是特别清楚。其实，系统可以帮助分析的，收费分试运行+正常计费阶段。第一阶段，由平台统计分析，给出query分布情况，之后调整计费模式。

10. 招聘定位    

通用平台化，在平台稳定后，可能最最麻烦、吃力的事情就是：接业务。每一个新的业务上来，面临沟通、定制schema、查询实现、查询优化、性能、计费、异常等各种答疑、建议、排查。平台人自己苦逼后，就希望交给PE、运维、技术支持来管理。这种做法让我想到如下：      

有一家医院致力于成为行业最优秀的医院，然后计划招聘门诊技术支持，负责接待-沟通外面前来就医的“客户需求”。因为同各种各样的“外面用户沟通、交流、 问诊”太费时间、经历、折腾。如果“大夫”亲自问诊，会把大夫经历分散。如果大夫不亲自问诊，由技术支持间接反馈，然后大夫再处理。    

每一个搜索业务，沟通-索引方案制定-连调，应该是平台人亲自处理。一个技术支持，不熟悉底层细节、不深入系统内部看问题，一个业务需求会辗转消耗更多时间、成本的。    

经验看，由平台人轮流值班接客，然后流程平台沉淀过去变动、调整、优化信息。这样方便持续的迭代。    

必须有相应的流程、变更积累。否则一旦换人，很多看不眼的配置、优化，可能直接影响性能、结果。并且，1V1的后备，不出现”单点“，过程积累非常重要。