configs

tangwang
1 parent 35da3813
Showing 4 changed files with 123 additions and 0 deletions Show diff stats
config/config.yaml
docs/TODO-意图判断-2.md
docs/TODO-意图判断.md
docs/Untitled
@@ -186,6 +186,10 @@ query_config:
     - total_inventory
     - option1_name
     - option1_values
+    - option2_name
+    - option2_values
+    - option3_name
+    - option3_values
     - specifications
     - skus
  
@@ -0,0 +1,40 @@
+
+一、 增加款式意图识别模块
+意图类型： 颜色，尺码（目前只需要支持这两种）
+
+
+二、 意图判断
+- 意图召回层：
+每种意图，有一个召回词集合
+对query（包括原始query、各种翻译query 都做匹配）
+- 以颜色意图为例：
+有一个词表，每一行 都逗号分割，互为同义词，行内第一个为标准化词
+query匹配了其中任何一个词，都认为，具有颜色意图
+匹配规则： 用细粒度、粗粒度分词，看是否有在词表中的。原始query分词、和每种翻译的分词，都要用。
+
+
+三、 意图使用：
+  当前 SKU 置顶逻辑在「分页 + 详情回填」之后
+流程是：run_rerank → 按 from/size 切片 → page fill → _apply_sku_sorting_for_page_hits → ResultFormatter
+  要改为：  
+  1. 有款式意图的时候，才做sku筛选  
+  2. sku筛选的时机，改为在reranker之前，对所有内容（rerank输入的所有spus）做sku筛选
+  3. 从仅 option1 扩展到多个维度，识别的意图，包含意图的维度名（color）和维度名的泛化词list（color、颜色、colour、colors...），遍历spu的option1_name,option2_name,option3_name字段，看哪个能匹配上意图的维度名list，哪个匹配上了，则在这个维度筛选。
+    1. 比如匹配到option2_name，那么取每一个sku的option2_values。如果没匹配到任何一个，那么把三个属性值都用空格拼接起来。这个值要记录下来。有两个作用：
+      1. 用来跟query匹配，看哪个更query相关性更高，以此进行最优sku筛选，把选出来的sku置顶，并替换spu的image_url
+      2. 用来做rerank doc的title补充，从而参与rerank
+  4. Rerank doc （有款式意图的时候）要带上属性后缀，拼接到title后面。在调用 run_rerank 前，对每条 hit 生成「用于重排的 doc 文本」（标题 + 可选后缀）  
+
+- sku筛选的规则也要优化： 
+现在的逻辑是，先做包含的判断，找到第一个 option_value被query包含的，则直接认为匹配。没有匹配的再用embedding相似度。
+改为： 
+  1. 第一轮：遍历完，如果有且仅有一个被query包含，那么认为匹配。  
+  2. 第二轮：如果有多个符合（被query包含），跳到3。如果没有，对每个词都走泛化词表进行匹配。  
+  3. 第三轮：如果有多个，那么对这多个，走embedding相关性取最高的。如果一个也没有，则对所有的走embedding相关性取最高的
+  这个sku筛选也需要提取为一个独立的模块。
+
+细节备注：
+在重排窗口内，第一次 ES 查询会把 _source 裁成「重排模板需要的字段」，默认只有 title 等，不包含 skus / option*_name。因此，有意图的时候，需要给这一次的_source加上 skus / option*_name  
+
+5. TODO： 搜索接口里，results[].skus 不是全量子 SKU：由 sku_filter_dimension 控制在应用层按维度分组折叠，每个「维度取值组合」只保留一条 SKU（组内第一条）。请求未传该字段时，Pydantic 默认是 ["option1"]，等价于只按 option1_value 去重；服务端不会读取店铺主题的「主展示维」，需调用方与装修配置对齐并传入正确维度。因此当用户有款式等更细粒度意图、而款式落在 option2/option3（或对应 option*_name）时，若仍用默认只按 option1（常见为颜色）折叠，同一颜色下多种款式只会出现一条代表 SKU，无法从返回的 skus 里拿到该颜色下的全部款式行。（若业务需要全量子款，需传包含对应维度的 sku_filter_dimension，或传 null/[] 跳过折叠——以当前 ResultFormatter 实现为准。）
+
@@ -0,0 +1,41 @@
+
+
+增加款式意图识别模块。意图类型： 颜色，尺码（目前只需要支持这两种）
+
+一、 意图判断
+- 意图召回层：
+每种意图，有一个召回词集合
+对query（包括原始query、各种翻译query 都做匹配）
+- 以颜色意图为例：
+有一个词表，每一行 都逗号分割，互为同义词，行内第一个为标准化词
+query匹配了其中任何一个词，都认为，具有颜色意图
+匹配规则： 用细粒度、粗粒度分词，看是否有在词表中的。原始query分词、和每种翻译的分词，都要用。
+
+二、 意图使用：
+  当前 SKU 置顶逻辑在「分页 + 详情回填」之后
+流程是：run_rerank → 按 from/size 切片 → page fill → _apply_sku_sorting_for_page_hits → ResultFormatter
+  要改为：  
+  1. 有款式意图的时候，才做sku筛选  
+  2. sku筛选的时机，改为在reranker之前，对所有内容（rerank输入的所有spus）做sku筛选
+  3. 从仅 option1 扩展到多个维度，识别的意图，包含意图的维度名（color）和维度名的泛化词list（color、颜色、colour、colors...），遍历spu的option1_name,option2_name,option3_name字段，看哪个能匹配上意图的维度名list，哪个匹配上了，则在这个维度筛选。
+    1. 比如匹配到option2_name，那么取每一个sku的option2_values。如果没匹配到任何一个，那么把三个属性值都用空格拼接起来。这个值要记录下来。有两个作用：
+      1. 用来跟query匹配，看哪个更query相关性更高，以此进行最优sku筛选，把选出来的sku置顶，并替换spu的image_url
+      2. 用来做rerank doc的title补充，从而参与rerank
+  4. Rerank doc （有款式意图的时候）要带上属性后缀，拼接到title后面。在调用 run_rerank 前，对每条 hit 生成「用于重排的 doc 文本」（标题 + 可选后缀）  
+
+- sku筛选的规则也要优化： 
+现在的逻辑是，先做包含的判断，找到第一个 option_value被query包含的，则直接认为匹配。没有匹配的再用embedding相似度。
+改为： 
+  1. 第一轮：遍历完，如果有且仅有一个被query包含，那么认为匹配。  
+  2. 第二轮：如果有多个符合（被query包含），跳到3。如果没有，对每个词都走泛化词表进行匹配。  
+  3. 第三轮：如果有多个，那么对这多个，走embedding相关性取最高的。如果一个也没有，则对所有的走embedding相关性取最高的
+  这个sku筛选也需要提取为一个独立的模块。
+
+细节备注：
+intent 考虑由 QueryParser 编排、具体实现拆成独立模块，主义好，现有的分词等基础设施的复用，缺失的英文分词可以补充。
+在重排窗口内，第一次 ES 查询会把 _source 裁成「重排模板需要的字段」，默认只有 title 等，不包含 skus / option*_name。因此，有意图的时候，需要给这一次的_source加上 skus / option*_name  
+
+先仔细理解需求，查看代码，深度思考应该如何设计，和当前的系统较好的融合，给出统一的设计，可以根据需要适当改造当前的实现，降低整个系统的复杂度，提高模块化程度，而不是打补丁。修改后的最终状态应该是要足够简单、清晰、无冗余和分叉，模块间低耦合。多步思考确认最佳施工方案之后才进行代码修改。
+
+5. TODO： 搜索接口里，results[].skus 不是全量子 SKU：由 sku_filter_dimension 控制在应用层按维度分组折叠，每个「维度取值组合」只保留一条 SKU（组内第一条）。请求未传该字段时，Pydantic 默认是 ["option1"]，等价于只按 option1_value 去重；服务端不会读取店铺主题的「主展示维」，需调用方与装修配置对齐并传入正确维度。因此当用户有款式等更细粒度意图、而款式落在 option2/option3（或对应 option*_name）时，若仍用默认只按 option1（常见为颜色）折叠，同一颜色下多种款式只会出现一条代表 SKU，无法从返回的 skus 里拿到该颜色下的全部款式行。（若业务需要全量子款，需传包含对应维度的 sku_filter_dimension，或传 null/[] 跳过折叠——以当前 ResultFormatter 实现为准。）
+
@@ -0,0 +1,38 @@
+
+一、 增加款式意图识别模块
+意图类型： 颜色，尺码（目前只需要支持这两种）
+
+
+二、 意图判断
+- 意图召回层：
+每种意图，有一个召回词集合
+对query（包括原始query、各种翻译query 都做匹配）
+- 以颜色意图为例：
+有一个词表，每一行 都逗号分割，互为同义词，行内第一个为标准化词
+query匹配了其中任何一个词，都认为，具有颜色意图
+匹配规则： 用细粒度、粗粒度分词，看是否有在词表中的。原始query分词、和每种翻译的分词，都要用。
+
+
+三、 意图使用：
+  当前 SKU 置顶逻辑在「分页 + 详情回填」之后
+流程是：run_rerank → 按 from/size 切片 → page fill → _apply_sku_sorting_for_page_hits → ResultFormatter
+  要改为：  
+  1. 有款式意图的时候，才做sku筛选  
+  2. sku筛选的时机，改为在reranker之前，对所有内容（rerank输入的所有spus）做sku筛选
+  3. 从仅 option1 扩展到多个维度，识别的意图，包含意图的维度名（color）和维度名的泛化词list（color、颜色、colour、colors...），遍历spu的option1_name,option2_name,option3_name字段，看哪个能匹配上意图的维度名list，哪个匹配上了，则在这个维度筛选。
+    1. 比如匹配到option2_name，那么取每一个sku的option2_values。如果没匹配到任何一个，那么把三个属性值都用空格拼接起来。这个值要记录下来。有两个作用：
+      1. 用来跟query匹配，看哪个更query相关性更高，以此进行最优sku筛选，把选出来的sku置顶，并替换spu的image_url
+      2. 用来做rerank doc的title补充，从而参与rerank
+  4. Rerank doc （有款式意图的时候）要带上属性后缀，拼接到title后面。在调用 run_rerank 前，对每条 hit 生成「用于重排的 doc 文本」（标题 + 可选后缀）  
+
+- sku筛选的规则也要优化： 
+现在的逻辑是，先做包含的判断，找到第一个 option_value被query包含的，则直接认为匹配。没有匹配的再用embedding相似度。
+改为： 
+  1. 第一轮：遍历完，如果有且仅有一个被query包含，那么认为匹配。  
+  2. 第二轮：如果有多个符合（被query包含），跳到3。如果没有，对每个词都走泛化词表进行匹配。  
+  3. 第三轮：如果有多个，那么对这多个，走embedding相关性取最高的。如果一个也没有，则对所有的走embedding相关性取最高的
+  这个sku筛选也需要提取为一个独立的模块。
+
+细节备注：
+intent 考虑由 QueryParser 编排、具体实现拆成独立模块，主义好，现有的分词等基础设施的复用，缺失的英文分词可以补充。
+在重排窗口内，第一次 ES 查询会把 _source 裁成「重排模板需要的字段」，默认只有 title 等，不包含 skus / option*_name。因此，有意图的时候，需要给这一次的_source加上 skus / option*_name