ai-saas / saas-search

26 Mar, 2026

1 commit

24 Mar, 2026

4 commits

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

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

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

3.
这一阶段得到sku选择的结果即可（选中的sku的id，也可以为空值表示没找到匹配成功的，这种情况不需要拼接title后缀给重排输入），但是不用着急做image_url的替换和sku的置顶。等最后填充的时候判断有选中sku的时候直接做替换和置顶即可。
请你思考如何进行设计，提高性能的时候不带来复杂度的提升，可以适当的重构以降低修改后的代码行数。
@search/sku_intent_selector.py @query/style_intent.py
    tangwang
     
  • 814e352b   乘法公式配置化 Browse File »
    tangwang
     
  • 581dafae   debug工具，每条结果的打分中间过程展示 ... Browse File » 
    The backend now exposes a structured debug_info that is much closer to
the real ranking pipeline:

query_analysis now includes index_languages, query_tokens, query-vector
summary, translation/enrichment plan, and translation debug.
query_build now explains the ES recall plan: base-language clause,
translated clauses, filters vs post-filters, KNN settings,
function-score config, and related inputs.
es_request distinguishes the logical DSL from the actual body sent to
ES, including rerank prefetch _source.
es_response now includes the initial ES ranking window stats used for
score interpretation.
rerank now includes execution state, templates, rendered rerank query
text, window/top_n, service/meta, and the fusion formula.
pagination now shows rerank-window fetch vs requested page plus
page-fill details.
For each result in debug_info.per_result, ranking debug is now much
richer:

initial rank and final rank
raw ES score
es_score_normalized = raw score / initial ES window max
es_score_norm = min-max normalization over the initial ES window
explicit normalization notes explaining that fusion does not directly
consume an ES-normalized score
rerank input details: doc template, title suffix, template field values,
doc preview/length
fusion breakdown: rerank_factor, text_factor, knn_factor, constants, raw
inputs, final fused score
text subcomponents: source/translation/weighted/primary/support/fallback
evidence via matched_queries
richer style-intent SKU debug, including selected SKU summary and intent
texts
    tangwang
     
  • 8ae95af0   1. Stage Timings: 为每个阶段耗时补充起止时间戳。 ... Browse File » 
    2， 漏了一些重要的stage，比如「款式意图 SKU
预筛选（StyleSkuSelector.prepare_hits）」，补上这个stage
    tangwang
     

20 Mar, 2026

3 commits

  • 41856690   embedding logs Browse File »
    tangwang
     
  • a7cc9078   sku排序 Browse File »
    tangwang
     
  • deccd68a   Added the SKU pre-selection step in search/searcher.py right before ... Browse File » 
    ResultFormatter.format_search_results() runs.

What changed:

For each final paginated SPU hit, the searcher now scans
skus[].option1_value against the query text set built from the original
query, normalized query, rewritten query, and translations.
If no option1_value matches textually, it falls back to embedding
similarity and picks the SKU with the highest inner product against the
query embedding.
The matched SKU is promoted to the front of the SPU’s skus list.
The SPU-level image_url is replaced with that matched SKU’s image_src.
I left api/result_formatter.py unchanged because it already preserves
the SKU order and reads image_url from _source; updating the page hits
in searcher makes the formatter return the desired result automatically.

Verification:

ReadLints on the edited files: no errors
Passed targeted tests:
pytest tests/test_search_rerank_window.py -k "translated_query or
no_direct_option_match"
    tangwang
     

16 Mar, 2026

1 commit

13 Mar, 2026

3 commits

12 Mar, 2026

1 commit

11 Mar, 2026

1 commit

06 Mar, 2026

1 commit

04 Feb, 2026

1 commit

27 Jan, 2026

1 commit

25 Dec, 2025

1 commit

16 Dec, 2025

1 commit

08 Dec, 2025

1 commit

03 Dec, 2025

1 commit

  • 13320ac6   分面接口修改： ... Browse File » 
    {
  "facets": [
    {
      "field": "category1_name",
      "size": 15,
      "type": "terms"
    },
    "specifications.color",
    "specifications.size"
  ]
}

{
  "facets": [
    {"field": "category1_name", "size": 15, "type": "terms"},
    {"field": "specifications.color", "size": 10, "type": "terms"},
    {"field": "specifications.size", "size": 10, "type": "terms"}
  ]
}

之前是上面的接口形式，主要是考虑 属性的分面， 因为 款式都是有限的 不需要设定 "size": 10, "type": "terms" 这些参数。

但是从接口设计层面，最好按下面这样，这样的话 specifications.color 和 category1_name 的组装格式 完全一样。前端不需要感知 属性分面 和 类别等其他字段分面的差异。
    tangwang
     

02 Dec, 2025

2 commits

  • a3a5d41b   （sku_filter_dimension 支持多维度组合去重） ... Browse File » 
    后端请求模型变更（api/models.py）
SearchRequest.sku_filter_dimension 从 Optional[str] 改为 Optional[List[str]]。
语义：列表表示一个或多个“维度标签”，例如：
单维度：["color"]、["option1"]
多维度：["color", "size"]、["option1", "option2"]
描述更新为：对 维度组合进行分组，每个组合只保留一个 SKU。
结果格式化与去重逻辑（api/result_formatter.py）
ResultFormatter.format_search_results(..., sku_filter_dimension: Optional[List[str]] = None)，调用处已同步更新。
单维度旧逻辑升级为多维度逻辑：
新方法：_filter_skus_by_dimensions(skus, dimensions, option1_name, option2_name, option3_name, specifications)。
维度解析规则（按顺序处理，并去重）：
若维度是 option1 / option2 / option3 → 对应 option1_value / option2_value / option3_value。
否则，将维度字符串转小写后，分别与 option1_name / option2_name / option3_name 对比，相等则映射到对应的 option*_value。
未能映射到任何字段的维度会被忽略。
对每个 SKU：
按解析出的字段列表（例如 ["option1_value", "option2_value"]）取值，组成 key，如 ("red", "L")；None 用空串 ""。
按 key 分组，每个 key 只保留遇到的第一个 SKU。
若列表为空或所有维度都无法解析，则 不做过滤，返回原始 skus。
Searcher 参数类型同步（search/searcher.py）
Searcher.search(...) 中 sku_filter_dimension 参数类型从 Optional[str] 改为 Optional[List[str]]。
传给 ResultFormatter.format_search_results 时，直接传该列表。
前端参数格式调整（frontend/static/js/app.js）
输入框 #skuFilterDimension 依旧是一个文本框，但解析方式改为：
函数 getSkuFilterDimension()：
读取文本，如："color" 或 "color,size" 或 "option1, color"。
用逗号 , 拆分，trim() 后过滤空串，返回 字符串数组，例如：
"color" → ["color"]
"color,size" → ["color", "size"]
若最终数组为空，则返回 null。
搜索请求体中仍使用字段名 sku_filter_dimension，但现在值是 string[] 或 null：
    body: JSON.stringify({      // ...      sku_filter_dimension: skuFilterDimension,  // 例如 ["color", "size"]      debug: state.debug    })
文档更新（docs/搜索API对接指南.md）
请求体示例中的类型由：
"sku_filter_dimension": "string"
改为：
"sku_filter_dimension": ["string"]
参数表中：
从 string 改为 array[string]，说明为“维度列表，按组合分组，每个组合保留一个 SKU”。
功能说明章节“SKU筛选维度 (sku_filter_dimension)”已调整为 列表语义 + 组合去重，并补充了示例：
单维度：
      {        "query": "芭比娃娃",        "sku_filter_dimension": ["color"]      }
多维度组合：
      {        "query": "芭比娃娃",        "sku_filter_dimension": ["color", "size"]      }
使用方式总结
单维度去重（保持旧行为的等价写法）
旧："sku_filter_dimension": "color"
新："sku_filter_dimension": ["color"]
多维度组合去重（你新提的需求）
例如希望“每个 SPU 下，同一颜色+尺码组合只保留一个 SKU”：
    {      "query": "芭比娃娃",      "sku_filter_dimension": ["color", "size"]    }
    tangwang
     
  • c4263d93   支持 sku_filter_dimension ... Browse File » 
    sku_filter_dimension=color
sku_filter_dimension=option1 / option2 /option3
以上两种方式都可以
    tangwang
     

01 Dec, 2025

1 commit

29 Nov, 2025

1 commit

14 Nov, 2025

2 commits

13 Nov, 2025

2 commits

12 Nov, 2025

1 commit

11 Nov, 2025

4 commits

10 Nov, 2025

1 commit

08 Nov, 2025

2 commits