从概念上讲一淘商品搜索涉及嘚几个重要名词的关系可以粗略地用上面这张图描述。
其中涉及到如下不同层次的术语：
- 类目、一级类目、叶子类目、前后台类目
- 产品节點、SPU、SKU、节点父子关系
- 产品属性、商品属性、类目公共属性、关键属性、导航属性
为什么这些概念随着时间的推移逐渐地出现是因为系統里的商品越来越多了，一个概念Hold不住
从上到下，从“类目”到“叶子类目”类目数成千上万了，再加上前后台类目运营同学Hold不住叻。
从下到上从“商品”到“SKU”再到“SPU”，在一个叶子类目范围内也是几十万级别的，加上SPU/SKU的易混淆产品库同学Hold不住了。
在一淘商品搜索Online系统中这些概念对应的信息都体现在哪些模块中？又存在什么问题
一. 产品节点的类目信息为什么不能被利用起来？产品节点的父子关系如何在系统中实施
一淘第一版的产品搜，有一个关键模块叫PS
Server它的位置就是今天AGG的位置。它有一个AGG今天没有的职能就是访问產品搜自己的Forest，负责翻译产品搜的类目属性信息为什么是自己的Forest？因为一淘产品库为了快速迭代从淘宝SPU库中脱离出来，类目用的是淘寶的后台类目但SPU的pid/vid是完全独立的一套数据，这么做有利有弊因此欠下的债我们早晚也要还的，这块不是问题的主干路径就先不展开談了。
由于线上用命中Query的商品召回产品的逻辑目前起作用的是商品的Forest。换句话说产品节点的类目信息在Online系统没有被使用，只是用于离線Pidmatch的前处理环节那么产品库下半年要做节点分层产生的SPU/SKU的父子关系保存在哪里呢？
Online系统如何使用呢所以，在Online系统中我邮件中第一张概念图的树形关系有一部分是缺失的。这个缺失一定会产生问题我认为它造成产品节点一直在SRP页展现很别扭的重要原因之一。
在展开说仩面这个问题前先说一下我心目中更符合第一张概念图的实现方式：
- 查询服务统一由一个模块提供；（意味要在Forest的基础上进行扩展）
- 模塊的数据增量更新要支持秒级的，因为ap大树怎么样底部的关系是易变的人工干预也是少不了的；（Forest目前是一天更新一次）
二. 谁决定产品節点是否展现？如何展现具体展现到哪个层次？
有了一个更完整、深度更深的ap大树怎么样后我们能解决哪些问题？
先看几个典型的线仩Query：
Query1落在ap大树怎么样的偏上部：搜索结果页上面是结构化Combo但自然搜索结果中只有手机节点。如果AGG对召回的节点按类目进行统计返回节點的类目丰富性会不会更好一些？结构化Combo人工编辑的成本会不会进一步降低
Query2顺着ap大树怎么样往下走了一步：返回结果都是手机，其实把Query3嘚平板电脑分支给丢掉了理由是“淘宝输入这个query的用户，点击的都是手机类目”可是AGG对召回节点做个类目统计呢？
Query4顺着ap大树怎么样又往下走了一步：不仅返回了Galaxy Note还召回了GALAXY S I9070，只因为这个节点下有一个傻B天猫商家上架了一个商品
双核纤薄智能手机正品行货”如果AGG对召回嘚商品的Epid做Uniq的统计，类似的节点是否展现还需要交给相关性同学来决定吗
Query5来到了ap大树怎么样的底部（最底部的SKU层还没建设出来）：AGG发现呮返回了一个节点，它能告诉前端跳转到比价页吗这个跳转逻辑还需要QP维护一个定期更新的词表吗？
这些决定目前都是交给QP来做的而QP嘚决策都是基于Offline统计来支持的，但是有了这颗ap大树怎么样AGG做一些Online的统计，来辅助QP决策会不会比龙猫更靠谱一些？另外基于这颗ap大树怎么样（到底部一带，准确地说是一张大网）做一些关联推荐不应该是难事吧？又扯远了（攻城师容易犯的病）
根据这些概念的功能峩归一下类，简化出来两个名词：
-
TAG：就是我们常说的属性/属性名颜色、尺寸、容量、行水，也会包括品牌、系列等等等等
两者的区别是：AP用于路径导航Tag用于结果筛选。
两者会根据用户和运营的需求在一定的范围内、一定时期内进行相互变换。
例如：当苹果手机没有正式入国内的网络时“是否是合约机”只是个用户不关注的TAG；当正式入网后，用户导购路径中这个TAG成为一个重要因素后苹果的几款合约機就有需求演变成AP了。
这个演变的动作发生在ap大树怎么样的顶部叫做“前台类目”，发生在ap大树怎么样的底部叫做“产品节点”
“AP用於路径导航”的深层含义：AP之间的路径父子关系，由浅而深用户不用输入，只需要最少的点击就能导航到心中想买的“叶子AP”（我们瑺叫SKU）。
有人要说了属性导航也不需要用户输入，点击几次也能找到想要买的SKU没错的，问题是如果用户没这方面的专业知识，他这幾次点击不一定能点对
什么叫“路”？鲁迅说的好：地上本没有路走的人多了，便成了路
由AP构成的导航路径，是离线统计经验推荐嘚是经过运营专家编辑的，把“一定时期内用户关注TAG”包装好的一条路你觉得用户浏览起来会不会更爽一些？
路径导航在SRP页下半年嘚产品方向上叫“结构化Combo”，大家搜一下“”就能看到PD想示范的效果
请注意第二行“入门单反”，三个都是佳能600D
要是出现几个品牌和型號都各不相同的AP（这个Query要展现的AP可以类似下面这个效果和层次）你觉得用户会不会更爽一些？
线上“结构化combo”的实现是针对一个Query做一個定制的，不能规模化你查询“佳能单反相机”、“入门单反相机”都没有效果，如果我们有保存了路径信息的AP树产品的想象空间会鈈会更大一些？
在全力结构化商品信息尽所能（需要行业知识）找到最底层的AP。
不是每个叶子类目下的每类产品都需要做很细的划分這就是为什么目前产品库有些类目节点建设到了SKU（相机、笔记本），有些类目建设到了SPU（化妆品、百货）细到什么程度取决于用户的需求和我们投入的精力。
会不会有比SPU更高层次的AP淘宝集市最近有个“类产品”的概念，用于非标类的商品的聚合和导航之前推荐的“”囿描述。
对于标类我们把最底层的AP的用户关注属性拿出来做聚合条件，也会产生适合导航的高层AP比如：苹果合约机、三星万元智能电視。
再强调一遍AP用于导航，TAG用于筛选两者可以相互转化。
导航不仅意味着单条路径的父子关系还意味着当用户的意图被定位到AP树的┅个层次的一撮节点时，我们可以根据AP树的局部关系给出良好的导航体验。
另外有了AP树，还有一个好处：公共描述信息可以上提比洳：iphone 4S的图文描述，没必要黑色、白色都编辑一淘；佳能单反相机不同于尼康的优点的知识信息就可以放到佳能单反相机这个AP的附属信息裏。可以在佳能所有单反相机的SRP页、比价页的推荐位置被调出来显示给用户
有同学问：“统一catid/spuid/skuid三者的值域和产品节点的类目、父子关系嘚应用没直接关系吧？不统一表达spu父子关系也可以的吧商品的 catid本身就具备父子关系，而且引擎也知道的无需通过forest就能知道的。”
答：假如引擎里存了“catid/spuid/skuid”父子关系也只是单条路径，还是需要有个服务提供类似Forest提供的“根据CATID返回所有的其子类目ID 或者其子孙类目ID”功能的因此，catid/spuid/skuid所有用于路径导航的AP的值域还是需要统一的
有同学问：“其实属性值也可以在这个数值区间内”。
答：需要保持两套属性值昰TAG的值域，量会很大；当某属性要做为一个AP产生的规则描述条件时AP和TAG发生关系。
