传统电商搜索面对的通常是这样的 Query：

男士、黑色、防水、冲锋衣。

用户给出品类词、属性词和品牌词，搜索系统通过倒排索引、属性过滤、向量召回、个性化召回等方式找到相关商品。

但随着 Chatbot、对话式导购和自然语言搜索逐渐进入电商，用户开始提出完全不同的问题：

下个月要去北欧，想买一件冲锋衣，但又不要太像冲锋衣。

这句话看起来是在搜索“冲锋衣”，实际上包含了多个相互独立、甚至看似矛盾的需求：

用户希望保留冲锋衣的防风、防雨等功能；
使用场景是北欧旅行；
商品最好适合城市活动和日常穿着；
用户不喜欢传统冲锋衣的专业户外视觉；
“不像冲锋衣”针对的是外观，而不是功能。

这类 Query 已经不能简单理解为关键词匹配，也不能只依赖一个整体的语义向量。

真正的问题是：

搜索系统能否理解用户希望保留哪些特征、削弱哪些特征，并在商品空间中找到满足这种组合条件的商品？

要解决这个问题，电商需要建设的不是一个更大的标签库，也不是一个单纯的向量数据库，而是一套完整的商品语义知识底座。

一、为什么继续增加标签不够

面对复杂自然语言 Query，一种直观方案是继续给商品增加标签。

例如针对服装商品，可以增加：

防水
防风
城市感
户外感
通勤感
极简感
专业装备感
日常感
轻户外
旅行适配

这种方式短期内有效，因为标签容易过滤、排序和解释。

但如果把它作为长期方案，会遇到几个明显的问题。

1. 用户语言是开放集合

用户不会严格使用平台定义的标签。

“不要太像冲锋衣”还可能被表达成：

不要像马上要去爬雪山；
不要太像户外博主；
别有太强的装备感；
平时上班也能穿；
想要防雨，但不要太专业；
要有冲锋衣功能，但看起来像普通夹克。

这些表达方式几乎无法提前穷举。

2. 审美概念不是孤立标签

商品为什么“看起来像冲锋衣”？

可能是因为：

外露的防水拉链；
高对比拼色；
宽大的专业帽檐；
复杂的功能口袋；
硬挺的面料；
明显的户外品牌标识；
专业登山式轮廓。

这些视觉元素组合在一起，才形成“冲锋衣感”。

因此，“冲锋衣感”不是一个简单标签，而是多个商品特征共同产生的感知结果。

3. 标签无法自然表达关系

标签可以表达“这件商品有防水功能”，但很难表达：

这件商品功能上接近冲锋衣；
视觉上更接近通勤夹克；
它保留了户外性能，但弱化了专业装备感；
它比另一件商品更适合城市旅行；
它适合短时降雨，但不适合持续暴雨。

这些都不是单一标签，而是关系、条件和程度。

因此，下一代商品知识体系不能只是无限扩张的标签集合。

二、商品 Wiki 也不能被理解成“给每件商品写百科”

另一种思路是为商品建设类似维基百科的商品 Wiki。

这种思路比标签库更接近正确方向，因为 Wiki 可以保存更丰富的知识，例如：

商品的功能和结构；
设计元素；
视觉风格；
适用场景；
用户评价；
与其他概念的关系；
每个结论的证据来源。

但对于淘宝这样的平台，如果把商品 Wiki 理解为给每个 SKU 建立一个页面，并显式记录大量商品之间的关系，同样不可行。

假设平台有 (N) 个商品，如果任意商品之间都可能建立关系，关系规模最坏会接近：

[ O(N^2) ]

即使每个商品只保存一千个相似商品，在十亿级商品规模下，也会产生万亿级关系。

更重要的是，很多商品关系并不稳定。

例如：

商品 A 是否比商品 B 更值得买，取决于价格；
哪件更适合北欧，取决于月份和活动方式；
哪件更不像冲锋衣，取决于用户对“冲锋衣感”的理解；
哪件更适合某个用户，取决于个人偏好和历史行为。

这些关系不应该永久存储在知识图谱中，而应该在 Query 到来后动态计算。

因此，商品 Wiki 更准确的定义应该是：

一套由商品事实、概念知识、商品到概念的映射、多维向量和证据系统共同组成的商品语义底座。

三、整体架构：四类数据共同表达商品

一套可扩展的商品语义底座，可以由四个核心部分组成：

[ \text{商品语义底座}

\text{商品事实库} + \text{概念知识图谱} + \text{多维向量索引} + \text{行为与实时状态} ]

它们分别回答不同的问题。

模块	回答的问题
商品事实库	商品实际上是什么
概念知识图谱	商品概念之间有什么关系
多维向量索引	商品在语义和视觉上像什么
用户行为系统	用户实际偏好什么
实时状态系统	商品现在是否值得被推荐
在线推理层	当前 Query 下哪些特征更重要

整体数据流可以表示为：

标题、参数、详情、图片、视频、评价、行为
                  ↓
          多模态商品理解模型
                  ↓
 ┌────────────────┼────────────────┐
 ↓                ↓                ↓
商品事实库     概念知识图谱       多维向量索引
 └────────────────┼────────────────┘
                  ↓
           商品语义服务层
                  ↓
      Query 理解与动态召回路由
                  ↓
          多路召回与候选融合
                  ↓
       多模态精排与个性化重排
                  ↓
             商品结果

逻辑上，它是一套统一的商品知识底座。

物理上，它一定由多个不同的存储和检索系统组成。

四、第一层：商品事实库

商品事实库用于保存确定、可验证、可过滤的信息。

例如一件外套可以包含：

所属 SPU 与 SKU；
品牌和类目；
材质；
颜色；
重量；
防水指数；
是否有帽子；
是否有保暖层；
面料层数；
版型；
尺码；
价格；
库存；
配送信息。

这部分信息适合使用：

KV 存储；
列式数据库；
倒排索引；
Bitmap 属性索引；
实时特征存储。

事实层最重要的特点是：不能只保存结论，还要保存证据和置信度。

例如商家标题写着“防水外套”，但没有提供防水指数，用户评价中又大量提到“只能挡小雨”。

系统不应该简单写成：

防水：是

而应该保留更完整的信息：

商家声明：防水
技术参数：缺失
用户体验：适合短时小雨
综合置信度：中

否则，后续模型很容易把营销文案误认为客观事实。

同时，稳定信息和实时信息应该分开存储。

稳定信息包括：

材质；
结构；
设计；
功能；
风格；
视觉特征。

实时信息包括：

价格；
库存；
促销；
配送时间；
销量变化。

这样可以避免价格或库存变化触发整个商品语义系统重新计算。

五、第二层：概念知识图谱

知识图谱的核心节点不应该是海量 SKU，而应该是相对稳定的商品概念。

1. 概念节点

概念图谱可以包含以下几类节点。

商品分类

外套
防水外套
冲锋衣
硬壳
软壳
风衣
通勤夹克

功能概念

防水
防风
透湿
保暖
耐磨
轻量
可叠穿

设计元素

压胶拉链
隐藏拉链
高对比拼色
大帽檐
多口袋
哑光面料
大 Logo
直筒轮廓

风格与审美

城市感
户外感
极简
专业装备感
轻户外
商务休闲
日常感
机能感

使用场景

北欧旅行
城市步行
日常通勤
轻徒步
高海拔登山
雨天骑行

环境条件

大风
持续降雨
低温
高湿度
昼夜温差
长时间户外活动

2. 概念关系

图谱需要表达的不只是“属于”，还包括概念之间的功能、视觉和替代关系。

例如：

冲锋衣
  ├── 核心功能 → 防水
  ├── 核心功能 → 防风
  ├── 常见结构 → 压胶拉链
  ├── 常见视觉 → 专业户外感
  ├── 相邻品类 → 软壳
  └── 相邻品类 → 都市防水夹克

可以设计的边包括：

is_a：属于某个上位概念；
has_function：具备某项功能；
suitable_for：适合某种场景；
has_visual_cue：具有某种视觉符号；
causes_perception：某个元素会增强某种感知；
weakens_perception：某个元素会削弱某种感知；
similar_to：与另一个概念相似；
alternative_to：可作为另一个品类的替代；
conflicts_with：两个概念存在冲突；
requires：某个场景要求某种能力；
insufficient_for：某项能力不足以满足某场景。

图谱中还应该保存关系强度、适用条件、来源和时效性。

例如：

北欧秋季旅行 → 需要防风

权重：0.86
条件：城市活动、户外步行时间较长
来源：气候知识、旅行内容、历史购买反馈

这种关系比简单标签更能支持 Query 推理。

六、第三层：商品到概念的稀疏映射

商品不需要与大量其他商品建立显式关系。

更合理的方法是，让每件商品连接少量高价值概念。

例如：

商品 A
├── 冲锋衣功能       0.83
├── 防风             0.91
├── 防水             0.86
├── 城市通勤         0.84
├── 极简风格         0.81
├── 户外视觉         0.25
├── 专业登山视觉     0.14
└── 北欧城市旅行     0.77

每条映射至少应包含：

item_id
concept_id
score
confidence
evidence_source
model_version
updated_at

这类关系的规模约为：

[ O(NK) ]

其中 (N) 是商品数量，(K) 是每件商品连接的概念数量。

只要将 (K) 控制在几十到几百以内，就比 SKU–SKU 图更容易扩展。

商品到概念的映射，可以来自：

商家结构化参数；
商品标题和详情页；
图片和视频理解；
用户评价；
人工标注；
行为反馈；
多模态模型推断。

其中模型推断出的关系必须带有置信度和证据，不能被当作绝对事实。

七、第四层：多维商品向量

只给每件商品生成一个统一向量，无法很好地解决复杂 Query。

因为“冲锋衣，但不要太像冲锋衣”同时表达了：

功能上接近冲锋衣；
视觉上远离传统冲锋衣；
风格上接近城市通勤；
场景上适合北欧旅行。

如果所有信息都压缩进一个向量，功能、品类、风格和视觉很容易纠缠在一起。

更合理的方式是，为商品生成多个语义空间中的表示：

Item
├── 文本语义向量
├── 视觉向量
├── 功能向量
├── 风格向量
├── 场景向量
├── 材质与结构向量
└── 用户体验向量

这些向量分别承担不同职责。

向量	表达内容
文本语义向量	标题、参数和描述的整体含义
视觉向量	轮廓、颜色、图案和设计语言
功能向量	防风、防水、透气、保暖、耐磨
风格向量	城市、极简、户外、正式、休闲
场景向量	通勤、旅行、徒步、商务、运动
体验向量	用户评价中的舒适、闷热、显瘦等感受

这使得系统可以分别判断：

功能相似度：高
城市风格相似度：高
专业户外视觉相似度：低
北欧旅行适配度：高

也就是说，系统不再只是寻找“最像 Query 的商品”，而是在不同语义空间中寻找满足不同方向约束的商品。

八、标签、Graph 和向量不是替代关系

三种表示形式各自适合解决不同问题。

标签负责硬约束

例如：

价格低于 1500 元；
防水指数高于 10000 mm；
黑色；
有帽子；
可配送；
有用户尺码。

这类条件必须稳定、精确和可过滤。

Graph 负责关系和推理

例如：

北欧旅行
→ 可能面临大风和降雨
→ 需要防风、防雨和可叠穿

以及：

不要像冲锋衣
→ 降低传统冲锋衣视觉符号
→ 少拼接、低 Logo、隐藏拉链、日常版型

向量负责开放语言和模糊感觉

用户说“不要像马上要去爬珠峰”，平台不可能为这句话提前建立标签。

但语义模型可以把它映射到：

专业装备感；
高强度户外视觉；
登山感；
复杂功能设计。

因此，可以把三者的职责总结为：

标签是硬约束，Graph 是推理骨架，向量是泛化机制。

九、复杂 Query 如何被系统处理

仍然以这句话为例：

下个月要去北欧，想买件冲锋衣，但不要太像冲锋衣。

第一步：Query 结构化

模型先把 Query 转化为 Intent Frame：

任务：购买旅行外套

时间：下个月
地点：北欧

目标：
冲锋衣或具备冲锋衣功能的外套

必须保留：
防风、防雨、可叠穿

希望增加：
城市感、简洁、日常可穿

希望降低：
专业登山感、强户外感、传统冲锋衣外观

不确定：
具体国家、活动方式、预算、温度

这里最关键的是明确区分：

保留：冲锋衣的功能
降低：冲锋衣的视觉

第二步：Graph 展开

概念图谱把自然语言意图转换为可执行的概念集合。

例如：

北欧旅行
├── 防风       0.95
├── 防雨       0.88
├── 可叠穿     0.76
└── 城市步行   0.72

不要像冲锋衣
├── 专业户外感   -0.87
├── 大 Logo      -0.65
├── 复杂拼接     -0.59
├── 装备感帽檐   -0.48
├── 城市感        0.91
└── 极简感        0.79

第三步：生成多个 Query 向量

系统不只生成一个整体 Query Embedding，而是生成：

Q_function
Q_style
Q_scene
Q_visual_positive
Q_visual_negative

例如：

Q_function = 防风 + 防水 + 可叠穿
Q_scene = 北欧城市旅行
Q_style = 城市 + 极简 + 日常
Q_negative = 专业户外感 + 登山装备感

这些向量可以通过一个 Learned Composer 生成，而不是完全依靠人工向量加减。

十、召回系统不会消失，而是变成动态路由

即使有了知识图谱和多向量表示，文本召回、属性召回、向量召回、个性化召回依然有价值。

改变的是：它们不再机械地对每个 Query 运行相同配额。

系统可以增加一个 Retrieval Router，根据 Query 意图动态决定调用哪些召回能力。

Query Intent
     ↓
Retrieval Router
     ├── 文本召回
     ├── 属性召回
     ├── 功能向量召回
     ├── 视觉风格召回
     ├── 场景向量召回
     ├── 图谱概念召回
     ├── 个性化召回
     └── 热门与业务兜底

对于“北欧旅行但不要太像冲锋衣”的 Query，可以重点使用：

召回方式	作用
功能向量召回	找到具备冲锋衣功能的商品
视觉风格召回	找到城市、简洁、日常外观
图谱概念召回	找到软壳、都市防水夹克等替代品类
属性召回	保证防风、防雨等基础条件
文本召回	避免遗漏明确相关商品
个性化召回	结合用户历史审美

因此，未来不是取消多路召回，而是：

从固定多路召回，转向由用户意图驱动的动态召回。

十一、排序阶段应使用多空间打分

候选商品生成后，可以先处理硬条件：

无库存则过滤；
尺码不匹配则过滤；
无法配送则过滤；
明确不满足防雨要求则降级；
价格不符合预算则过滤或降权。

随后进行多维打分：

[ \begin{aligned} Score(i)= &;w_f \cdot Sim(Q_f,I_f)\ +&;w_s \cdot Sim(Q_s,I_s)\ +&;w_v \cdot Sim(Q_v,I_v)\ +&;w_c \cdot Sim(Q_c,I_c)\ +&;w_g \cdot GraphMatch(Q,i)\ +&;w_p \cdot PersonalScore(u,i)\ -&;w_n \cdot Sim(Q_{negative},I_v)\ -&;ConstraintPenalty(i) \end{aligned} ]

其中：

(Q_f) 和 (I_f) 表示功能向量；
(Q_s) 和 (I_s) 表示风格向量；
(Q_v) 和 (I_v) 表示视觉向量；
(Q_c) 和 (I_c) 表示场景向量；
(Q_{negative}) 表示用户明确排斥的特征；
(GraphMatch) 表示概念图谱匹配程度；
(PersonalScore) 表示个性化偏好。

这里不能简单地把所有正负条件提前压成一个向量。

因为：

“需要冲锋衣”和“不要像冲锋衣”分别在功能空间和视觉空间中成立。

十二、商品间关系应按需计算

在淘宝体量下，以下关系不应该永久存储：

哪件更适合北欧旅行；
哪件更不像冲锋衣；
哪件更适合当前用户；
哪件当前性价比更高；
哪件在当前候选集合中更值得推荐。

这些关系依赖：

当前 Query；
当前用户；
当前时间；
当前价格；
当前库存；
当前候选集合。

因此，更合理的流程是：

全站商品
    ↓
倒排、属性和向量召回数千件
    ↓
对候选商品动态计算关系
    ↓
多模态精排
    ↓
输出几十件结果

也就是说：

稳定关系存储在概念层，动态关系计算在候选层。

十三、物理存储应该如何分工

一套商品语义知识底座不应强行使用同一个数据库。

不同数据适合不同系统：

数据类型	推荐存储方式
商品基本事实	KV 或列式数据库
价格与库存	实时 KV、流式系统
文本关键词	倒排索引
结构化属性	Bitmap 或属性索引
概念关系	图数据库或图计算系统
商品到概念映射	稀疏列式表、倒排表
多模态向量	分片 ANN 索引
用户行为	行为图、序列特征库
Item–Item 近邻	Top-K 邻居缓存
排序特征	Feature Store

逻辑上，它们共同构成商品知识库。

工程上，它们必须被拆分成多个高性能系统。

十四、如何建设商品知识生产流水线

商品知识并不是一次性人工录入完成的，而是通过持续的数据处理生成。

商品新增或更新
      ↓
类目识别
      ↓
文本属性抽取
      ↓
图片与视频理解
      ↓
评价体验提取
      ↓
多来源信息融合
      ↓
冲突检测
      ↓
商品事实写入
      ↓
商品到概念映射
      ↓
多维向量生成
      ↓
索引更新

每个模型生成的结论都需要保存：

数据来源；
置信度；
模型版本；
生成时间；
有效期；
冲突状态；
可追溯证据。

否则，商品知识库很容易变成一个无法治理的模型结论堆积系统。

十五、标签应该成为知识库的物化视图

未来标签仍然重要，但它不应该是商品知识的唯一来源。

更合理的关系是：

商品图片
+ 商品参数
+ 设计元素
+ 概念图谱
+ 用户评价
        ↓
  商品语义理解
        ↓
连续特征与概念分数
        ↓
根据线上需求物化标签

例如系统可以计算出：

户外视觉强度：0.28
城市感：0.83
专业装备感：0.19
通勤适配度：0.88

线上为了快速过滤，可以物化为：

low_outdoor_aesthetic
high_urban_style
commute_compatible

因此，标签不再是底层知识本身，而是底层知识面向检索系统的一种高性能投影。

十六、落地时应该从垂类开始

这套系统不适合一开始覆盖所有类目。

更现实的落地方式，是先选择一个同时具有强视觉、强场景和复杂审美表达的类目。

例如：

外套；
女装；
鞋类；
家居；
家装；
箱包。

第一阶段可以只建设：

30～50 个功能概念；
30～50 个视觉风格维度；
20～30 个使用场景；
文本、视觉、功能、风格四类向量；
一套复杂自然语言 Query 测试集。

第二阶段再加入：

Query Intent 结构化；
正向和负向需求识别；
动态召回路由；
Graph Query Expansion。

第三阶段再引入：

多模态精排；
个性化语义权重；
用户对风格概念的个人定义；
可解释推荐。

十七、评估指标也需要变化

传统搜索主要关注：

CTR；
CVR；
GMV；
停留时长；
加购率。

复杂自然语言搜索还需要增加一套新的评估指标。

指标	评价内容
Intent Recall	是否覆盖用户真实需求
Hard Constraint Violation	是否违反明确硬条件
Negative Intent Violation	是否出现用户明确不要的特征
Preserve–Change Accuracy	是否保留该保留的、改变该改变的
Function–Style Separation	是否区分商品功能和商品外观
Query Reformulation Rate	用户是否需要反复改写 Query
Explanation Grounding	推荐理由是否有事实证据
Diversity	是否提供不同品类的合理替代
Latency	复杂推理是否满足在线要求

其中一个尤其重要的指标是：

[ \text{Negative Intent Violation Rate} ]

传统搜索主要关注用户“想要什么”。

自然语言搜索还必须认真处理用户“明确不要什么”。

结语

下一代电商搜索面对的，不再只是标准化商品词，而是生活场景、功能需求、审美偏好和负向条件的混合表达。

用户搜索的也不再只是一个类目，而是一个目标商品区域：

冲锋衣的功能
+
北欧旅行的场景适配
+
城市外套的日常感
-
传统冲锋衣的专业户外视觉

要支撑这种检索，平台不能只继续增加标签，也不能试图建立一个覆盖所有 SKU 关系的巨大商品图谱。

更可行的设计是：

商品事实使用结构化数据库保存，稳定的概念关系放入 Graph，开放语义和视觉感知放入多维向量空间，复杂的商品关系在 Query 到来后动态计算。

在这个体系中：

标签负责精确过滤；
Graph 负责概念推理；
向量负责开放表达；
多模态模型负责理解商品；
动态召回负责生成候选；
在线排序负责完成最终组合。

最终，商品知识库不应该只是保存“商品有什么属性”。

它应该帮助搜索系统理解：

用户为什么需要这件商品、希望保留什么、希望去掉什么，以及什么商品能够以另一种方式满足同一个需求。

分类： I’m CEO bitch

从标签库到商品语义底座：如何为下一代电商搜索设计知识库、Graph 与向量系统