TODO-意图判断.md 8.46 KB
Edit Raw Blame History


增加款式意图识别模块。意图类型： 颜色，尺码（目前只需要支持这两种）

一、 意图判断


意图召回层：
每种意图，有一个召回词集合
对query（包括原始query、各种翻译query 都做匹配）
以颜色意图为例：
有一个词表，每一行 都逗号分割，互为同义词，行内第一个为标准化词
query匹配了其中任何一个词，都认为，具有颜色意图
匹配规则： 用细粒度、粗粒度分词，看是否有在词表中的。原始query分词、和每种翻译的分词，都要用。


二、 意图使用：
  当前 SKU 置顶逻辑在「分页 + 详情回填」之后
流程是：run_rerank → 按 from/size 切片 → page fill → _apply_sku_sorting_for_page_hits → ResultFormatter
  要改为：  


有款式意图的时候，才做sku筛选

sku筛选的时机，改为在reranker之前，对所有内容（rerank输入的所有spus）做sku筛选
从仅 option1 扩展到多个维度，识别的意图，包含意图的维度名（color）和维度名的泛化词list（color、颜色、colour、colors...），遍历spu的option1_name,option2_name,option3_name字段，看哪个能匹配上意图的维度名list，哪个匹配上了，则在这个维度筛选。


比如匹配到option2_name，那么取每一个sku的option2_values。如果没匹配到任何一个，那么把三个属性值都用空格拼接起来。这个值要记录下来。有两个作用：


用来跟query匹配，看哪个更query相关性更高，以此进行最优sku筛选，把选出来的sku置顶，并替换spu的image_url
用来做rerank doc的title补充，从而参与rerank


Rerank doc （有款式意图的时候）要带上属性后缀，拼接到title后面。在调用 run_rerank 前，对每条 hit 生成「用于重排的 doc 文本」（标题 + 可选后缀）


sku筛选的规则也要优化： 
现在的逻辑是，先做包含的判断，找到第一个 option_value被query包含的，则直接认为匹配。没有匹配的再用embedding相似度。
改为： 


第一轮：遍历完，如果有且仅有一个被query包含，那么认为匹配。

第二轮：如果有多个符合（被query包含），跳到3。如果没有，对每个词都走泛化词表进行匹配。

第三轮：如果有多个，那么对这多个，走embedding相关性取最高的。如果一个也没有，则对所有的走embedding相关性取最高的
这个sku筛选也需要提取为一个独立的模块。


细节备注：
intent 考虑由 QueryParser 编排、具体实现拆成独立模块，主义好，现有的分词等基础设施的复用，缺失的英文分词可以补充。
在重排窗口内，第一次 ES 查询会把 source 裁成「重排模板需要的字段」，默认只有 title 等，不包含 skus / option*name。因此，有意图的时候，需要给这一次的source加上 skus / option*name  

先仔细理解需求，查看代码，深度思考应该如何设计，和当前的系统较好的融合，给出统一的设计，可以根据需要适当改造当前的实现，降低整个系统的复杂度，提高模块化程度，而不是打补丁。修改后的最终状态应该是要足够简单、清晰、无冗余和分叉，模块间低耦合。多步思考确认最佳施工方案之后才进行代码修改。


TODO： 搜索接口里，results[].skus 不是全量子 SKU：由 sku_filter_dimension 控制在应用层按维度分组折叠，每个「维度取值组合」只保留一条 SKU（组内第一条）。请求未传该字段时，Pydantic 默认是 ["option1"]，等价于只按 option1_value 去重；服务端不会读取店铺主题的「主展示维」，需调用方与装修配置对齐并传入正确维度。因此当用户有款式等更细粒度意图、而款式落在 option2/option3（或对应 option*name）时，若仍用默认只按 option1（常见为颜色）折叠，同一颜色下多种款式只会出现一条代表 SKU，无法从返回的 skus 里拿到该颜色下的全部款式行。（若业务需要全量子款，需传包含对应维度的 skufilter_dimension，或传 null/[] 跳过折叠——以当前 ResultFormatter 实现为准。）


GPT5.4 主要思路：
我准备按这条线改，尽量把逻辑收束成两个新模块而不是继续堆在 Searcher 里：

QueryParser 负责产出统一的“款式意图分析结果”，包含：命中的意图类型、标准化值、命中的 query 变体、分词结果、维度候选词。
独立的 SKU 选择模块负责：维度解析、候选值抽取、三阶段匹配、选中 SKU 后的主图替换，以及生成 rerank 用的属性后缀。
Searcher 只编排：解析 query -> 首次 ES 召回 -> 若有款式意图则对 rerank 窗口内全部 hits 做 SKU 预筛选并补充 rerank doc 文本 -> run_rerank -> 分页 -> page fill -> ResultFormatter。这样旧的页内 SKU 置顶逻辑可以下沉或删除，避免前后两个阶段重复做同一件事。我再补看一下你最近写的意图草稿文档，确认有没有现成词表示例或边界条件，避免我这边把词表格式和你预期做偏。

意图匹配的性能优化：
上面一版实现，性能上完全无法接受。因此进行了一轮策略简化

prompt
style_sku_prepare_hits阶段耗时太长。请根据需求，思考优化的方法，给出性能优化的方案。


_select_by_embedding，有缓存吗，option_value的值是有限的，之前已经算过的，就不用再算了。不仅仅是embedding相似的结果，整个option_value的匹配结果，是有包含、还是没包含，相似度多少，都不用重新计算。比如之前已经有一个sku的某个属性值叫做“卡其色”，已经算出来是否文本匹配了，那么不需要再去做文本匹配。如果已经算出来向量的相似度，那么不需要再去取向量以及计算相似度。
匹配可以适当的优化：
匹配流程简化：
1）找到第一个文本匹配的，如果有直接匹配成功。不需要考虑匹配多个的情况。
2）如果全部都没有匹配，那么进行embedding筛选。


匹配规则：
option_name的匹配，直接看规范化后的option_name是不是意图维度的泛化词之一（比如颜色、color、colour），如果没有匹配的，现在应该是把所有维度都算上，这样匹配成本和比较成本太高了，去掉这些逻辑，这种情况不需要加后缀、不需要选择sku。
ption_value的匹配。意图检测的时候，有匹配的query中的命中的词，这个词被包含在属性值中，那么就算匹配。属性值被包含在query（包括翻译文本）中，也算匹配。提高匹配的覆盖率。


这一阶段得到sku选择的结果即可（选中的sku的id，也可以为空值表示没找到匹配成功的，这种情况不需要拼接title后缀给重排输入），但是不用着急做image_url的替换和sku的置顶。等最后填充的时候判断有选中sku的时候直接做替换和置顶即可。
请你思考如何进行设计，提高性能的时候不带来复杂度的提升，可以适当的重构以降低修改后的代码行数。
@search/sku_intent_selector.py @query/style_intent.py 


修改结果：
核心变化在 search/sku_intent_selector.py 和 search/searcher.py。

现在的策略是：


option_name 只做规范化后 alias 精确匹配；任何意图维度没 resolve 到字段，就直接不选 SKU、不加 suffix。
option_value 文本匹配改成顺序扫描 SKU，找到第一个命中的就直接返回，不再收集多个候选再比较。
文本匹配规则支持两种：


query 命中的意图词被属性值包含
属性值被 query/translation 包含

只有当所有 SKU 都没有文本命中时，才做 embedding 选择。
prepare_hits() 现在只产出决策和 _style_rerank_suffix，不再提前改 _source；真正的 image_url 替换和 SKU 置顶统一后移到 apply_precomputed_decisions()。
加了请求级缓存，避免同一个 option_value/selection_text 在一次请求里重复做文本判断、取向量和算相似度。
顺手删掉了旧的 generalized match / fallback_text 路径，代码比之前更短也更直。


另外补了回归测试，覆盖了：


翻译文本命中后正确选 SKU
多个文本命中时取第一个
option_name 不命中 alias 时不做 SKU 选择
无文本命中时走 embedding fallback


验证过：


pytest tests/test_search_rerank_window.py -q 通过
变更文件 lint 无报错