垂直搜索新问题

简介: 假期重新把之前在新浪博客里面的文字梳理了下,搬到这里。

当大家都在关注搜索的速度的时候,往往伴随业务的快速发展,数据服务质量成为了实时搜索或者垂直搜索中的新问题。实时搜索和垂直搜索是不一样的问题,下面的问题就是垂直场景下得实时搜索问题。也可以理解垂直搜索都不实时,其他的实时先排队吧。问题比较抽象,只谈总体上的现象,对于具体如何解绝问题的细节,不做说明。有些不具有通用性,有些和场景相关,很难有最佳方式,不代表没有解决方法。首先是有问题意识,然后自然有解决方法。

问题:
(1)
个性化排序
伴随业务发展需要,同时细分用户群体,为了最大程度优化服务质量、满足更大群体的具体业务场景,个性化的排序越来越引起高度重视。传统的文本相关性只是第一维的参考,针对业务多维度综合得分的二维排序最终影响排序。而一个平台上面临的服务群体、服务场景多种多样,有行业属性、地域属性、技术属性、运营属性等,很难完全统一,完全归一化到一个计算公式中去。相反,针对类目、行业等属性,局部优化,影响和改进进度和风险都大大都到控制。应用更希望有针对性的个个优化,而不寻求一个统一的模型,兼容各方面维度需求。

对于引擎来说,单维度排序实现是比较容易的,但是当出现10个、20甚至50多个维度的时候,索引结构变得臃肿,schema管理起来费劲。
另外,直接单维度原始值,非常容易引起作弊,从而影响公平性。这是个性化排序需要深入防范的,在突出重点因子的时候,是需要平衡其他因子的,否则钻孔子、作弊就会影响服务的客观性。

(2)
一致性
由于垂直,使得业务领域或者边界相对来说比较清晰。业务的主体属性、主体行为,相关的结果某种程度是可控的。但是一个垂直平台上绝不是单一的一个服务,相反是高度聚合的相关联的、专业的、全面的服务产品。从入口到帮助到离开,与核心应用相关的各种辅助、促进、支持的信息一应俱全。而具体服务满足个性化、特殊阶段等需求,使得数据存在某些不一致性。而这种不一致性,伴随应用扩展,更加清晰。
例如 图片的分类和文本描述的不一致性,图片的文本属性和图片直观的感受不一致,具体商品的价格和排序的价格或者标榜的价格不直接吻合,可能只有店铺中得一件商品是哪个最低价,误导用户全部商品都是哪个最低价。频繁的来回修改属性、风格、模板等,为了争取排序机会,而实际有效变动很少,变动的贡献值的度量化变得复杂。个别用户的粉丝、关注呈异常增长趋势,这与业务总体趋势极为不一致,对突发和非常规的监控成为垂直场景中,最容易忽视的环境。因为这些不一致不影响功能,似乎被认作锦上添花之举。实际上,各个创业公司在细分市场上打拼,玩的就是细致、专注、一丝不苟。当一致性的存在被放大或者默许,高质量的信息就会被稀释,甚至完全淹没。为什么很多应用前景都是乐观的,而实际总是没有大的突破,我觉的和细节处理有很大关联,只追求上线的那刻,忽视了后续持续的质量提升,因为后面的工作好比鸡蛋里找骨头。

(3)
数据挖掘
没有挖掘的搜索,最终就是一个弱化的存储。没有挖掘的垂直市场,应用迟早断送了用户群体。垂直化数据本身就非常具有一定局限性、自包含性、内容为主型。在平台上,不推新破旧,不时时对用户提供小惊喜,热度过后,口碑是否能持续和忠实粉丝不流失,不得不考虑。如果只是短期应付,不考虑更长期的发展,这个产品走不远。垂直的应用往往可以简单理解为一个工具,一个工具最重要的是轻巧、舒适、小创意。体验为王!

(4)
归一化
信息来源的丰富,评论、分享、图片、商品、转发、关注、粉丝、交易、成交、更新、价格....
既有具体维度的需求,也有综合维度的需求。需要对多来源信息贡献值进行归一化。好处就是,提升默认排序的质量,减少交互或者导航的成本,通过首页的高质量信息,逐步在用户阅读、浏览过程中,自然的导航到准确或者扩展信息源。避免页面过多的选择、点击或者跳转。这个与目前垂直的"丰富性"“明确性似乎背道而驰。在本身边界、业务场景相对单一的场景下,继续追求统一、简单,显得有点强人所难。如果说做到什么样的归一化最好呢,可以拿手机体验做参照,页面可以做到和手机一样的体验,归一化就差不多到位了。这是个人理解的,不一定合理。

另外,归一化后,垂直服务对为输出可能更容易维护。利于,有归一化度量的用户质量”(关注、粉丝、分享、评论)或者特征集(分享兴趣、关注兴趣、转发兴趣等),这样其他垂直对用户排序可以参照用户质量,对用户关联推荐,可以直接引用特征集等。

归一化和挖掘输出紧密关联,归一化细分更多、更丰富丰富,挖掘就更加容易发现和输出新内容。

所有这些问题,最后离不开搜索的支持,离不开索引的设计、排序的优化。

目录
相关文章
|
5月前
|
数据采集 存储 API
手动给docusaurus添加一个搜索
如果algolia不能自动配置的话,我教你手动给docusaurus添加一个搜索
手动给docusaurus添加一个搜索
|
5月前
|
前端开发 JavaScript 容器
一个可搜索的表格
一个可搜索的表格
|
人工智能 自然语言处理 数据库
联合搜索:搜索中的所有需求
现如今各行各业内容和数据量逐年增长,内容碎片化已成为现实问题。各大公司在众多平台上每个方向都有内容。当有如此多的搜索选项时,如何确保用户获得他们想要的信息? 在本文中了解业务方向(在客户服务、营销或运营方面)如何集中搜索以减少客户和团队的搜索工作,并简化内容源之间的可查找性。
224 0
|
前端开发 程序员 开发者
搜索区域 | 学习笔记
快速学习搜索区域
100 0
搜索区域 | 学习笔记
|
搜索推荐 安全 Java
html+css实战134-搜索-布局和文本框
html+css实战134-搜索-布局和文本框
140 0
html+css实战134-搜索-布局和文本框
|
机器学习/深度学习 算法 搜索推荐
DARTS+:DARTS 搜索为何需要早停?
近日,华为诺亚 方舟实验室的作者们提出一种可微分的神经网络架构搜索算法 DARTS+,将早停机制(early stopping)引入到原始的 DARTS[1] 算法中,不仅减小了 DARTS 搜索的时间,而且极大地提升了 DARTS 的性能。相关论文《DARTS+: Improved Differentiable Architecture Search with Early Stopping》已经公开(相关代码稍后也会开源)。
221 0
DARTS+:DARTS 搜索为何需要早停?
|
搜索推荐 索引 监控
垂直搜索新问题
当大家都在关注搜索的速度的时候,往往伴随业务的快速发展,数据服务质量成为了实时搜索或者垂直搜索中的新问题。实时搜索和垂直搜索是不一样的问题,下面的问题就是垂直场景下得实时搜索问题。也可以理解垂直搜索都不实时,其他的实时先排队吧。问题比较抽象,只谈总体上的现象,对于具体如何解绝问题的细节,不做说明。.
1556 4
|
算法 JavaScript 前端开发
前端做模糊搜索
通过搜索关键字bi会匹配到好几个结果 这个和一些编辑器的搜索功能很像,比如sublime text,不需要知道关键字的完整拼写,只需要知道其中的几个字母即可。 那么这个功能在前端我们如何去实现呢?
4858 0
|
存储 容器
宽度搜索 leetcode 515
您需要在二叉树的每一行中找到最大的值。 示例: 输入: 1 / \ 3 2 / \ \ 5 3 9 输出: [1, 3, 9] 思路:层序遍历的基础上,用一个容器存储每层中的元素值。
723 0