09 Apr, 2026
3 commits
-
category_taxonomy_profile - 原 analysis_kinds 混用了“增强类型”（content/taxonomy）与“品类特定配置”，不利于扩展不同品类的 taxonomy 分析（如 3C、家居等） - 新增 enrichment_scopes 参数：支持 generic（通用增强，产出 qanchors/enriched_tags/enriched_attributes）和 category_taxonomy（品类增强，产出 enriched_taxonomy_attributes） - 新增 category_taxonomy_profile 参数：指定品类增强使用哪套 profile（当前内置 apparel），每套 profile 包含独立的 prompt、输出列定义、解析规则及缓存版本 - 保留 analysis_kinds 作为兼容别名，避免破坏现有调用方 - 重构内部 taxonomy 分析为 profile registry 模式：新增 _get_taxonomy_schema(profile_name) 函数，根据 profile 动态返回对应的 AnalysisSchema - 缓存 key 现在按“分析类型 + profile + schema 指纹 + 输入字段哈希”隔离，确保不同品类、不同 prompt 版本自动失效 - 更新 API 文档及微服务接口文档，明确新参数语义与使用示例 技术细节： - 修改入口：api/routes/indexer.py 中 enrich-content 端点，解析新参数并向下传递 - 核心逻辑：indexer/product_enrich.py 中 enrich_products_batch 增加 profile 参数；_process_batch_for_schema 根据 scope 和 profile 动态获取 schema - 兼容层：若请求同时提供 analysis_kinds，则映射为 enrichment_scopes（content→generic，taxonomy→category_taxonomy），category_taxonomy_profile 默认为 "apparel" - 测试覆盖：新增 enrichment_scopes 组合、profile 切换及兼容模式测试
-
- `/indexer/enrich-content` 路由`enriched_taxonomy_attributes` 与 `enriched_attributes` 一并返回 - 新增请求参数 `analysis_kinds`（可选，默认 `["content", "taxonomy"]`），允许调用方按需选择内容分析类型，为后续扩展和成本控制预留空间 - 重构缓存策略：将 `content` 与 `taxonomy` 两类分析的缓存完全隔离，缓存 key 包含 prompt 模板、表头、输出字段定义（即 schema 指纹），确保提示词或解析规则变更时自动失效 - 缓存 key 仅依赖真正参与 LLM 输入的字段（`title`、`brief`、`description`），`image_url`、`tenant_id`、`spu_id` 不再污染缓存键，提高缓存命中率 - 更新 API 文档（`docs/搜索API对接指南-05-索引接口（Indexer）.md`），说明新增参数与返回字段 技术细节： - 路由层调整：在 `api/routes/indexer.py` 的 enrich-content 端点中，将 `product_enrich.enrich_products_batch` 返回的 `enriched_taxonomy_attributes` 字段显式加入 HTTP 响应体 - `analysis_kinds` 参数透传至底层 `enrich_products_batch`，支持按需跳过某一类分析（如仅需 taxonomy 时减少 LLM 调用） - 缓存指纹计算位于 `product_enrich.py` 的 `_get_cache_key` 函数，对每种 `AnalysisSchema` 独立生成；版本号通过 `schema.version` 或 prompt 内容哈希隐式包含 - 测试覆盖：新增 `analysis_kinds` 组合场景及缓存隔离测试
-
字段生成 - 新增分类法属性富化能力，遵循 enriched_attributes 相同的字段结构和处理逻辑，仅提示词和解析维度不同 - 引入 AnalysisSchema 抽象类，使内容富化（content）与分类法富化（taxonomy）共享批处理、缓存、提示词构建、Markdown 解析及归一化流程 - 重构 product_enrich.py 中原有的富化管道，将通用逻辑抽取至 _process_batch_for_schema、_parse_markdown_to_attributes 等函数，消除代码重复 - 在 product_enrich_prompts.py 中添加分类法提示词模板（TAXONOMY_ANALYSIS_PROMPT）及 Markdown 表头定义（TAXONOMY_HEADERS） - 修复 Markdown 解析器在空单元格时的行为：原实现会跳过空单元格导致列错位，现改为保留空值，确保稀疏的分类法属性列正确对齐 - 更新 document_transformer.py 中 build_index_content_fields 函数，将 enriched_taxonomy_attributes（中/英）写入最终索引文档 - 调整相关单元测试（test_product_enrich_partial_mode.py 等）以覆盖新字段路径，测试通过（14 passed） 技术细节： - AnalysisSchema 包含 schema_name、prompt_template、headers、field_name_prefix 等元数据 - 缓存键区分内容/分类法：`enrich:{schema_name}:{product_id}`，避免缓存污染 - 分类法解析使用与 enriched_attributes 相同的嵌套结构：`{"attribute_key": "value"}`，支持多行表格 - 批处理大小与重试逻辑保持与原有内容富化一致
07 Apr, 2026
2 commits
-
- consolidate suggestion rebuild flow into build_suggestions.sh via --rebuild and remove the redundant rebuild_suggestions.sh wrapper - make suggestion versioned index names use microseconds and handle index-create retries/timeouts without false already_exists failures - treat create requests as successful when the index was created server-side, then explicitly wait for shard readiness and surface allocation diagnostics - clean up freshly created suggestion indices on rebuild failure to avoid leaving red orphan indices behind - make rebuild smoke tests target the local backend by default, with SUGGESTIONS_SMOKE_BASE_URL as the explicit override - add unit coverage for microsecond versioned index names and cleanup on unallocatable index failures
-
2. issues文档
04 Apr, 2026
1 commit
-
Exact Match High Relevant Low Relevant Irrelevant to Fully Relevant Mostly Relevant Weakly Relevant Irrelevant
01 Apr, 2026
5 commits
-
都会合并成数组，和 qanchors / enriched_tags 的处理方式保持一致，更符合你现在这套 ES mapping 的灌入方式。ES 的 text 字段本身支持数组，所以像 value.zh: ["舒适", "无鞋带设计"] 这种写法是可以正常入库的；nested 只是外层对象数组，不影响内部语言字段存数组。
-
`indexer/product_enrich.py`，不是再补一层判断。 根因有两个：缓存 key 按内容复用，但缓存值里还带着旧商品的 `id/title_input`；同时内部分析结果在历史上混用了 `tags` 和 `enriched_tags`。这样一旦命中旧缓存，`build_index_content_fields()` 会因为 `id` 对不上把结果丢掉，最后对外就变成全空。 现在的处理是： - 内部分析结果统一用 `tags` 作为 LLM/缓存层字段。 - 对外只在 `build_index_content_fields()` 封装时映射成 `enriched_tags`，`enriched_attributes` 里也统一产出 `name="enriched_tags"`。 - 读取缓存时会先做归一化：把旧缓存里的 `enriched_tags` 兼容成内部 `tags`，并把命中的缓存结果重绑到当前请求商品的 `id/title_input`。 - 写缓存时也统一写成归一化后的内部结构，并且空内容不再写入缓存。
31 Mar, 2026
2 commits
30 Mar, 2026
4 commits
-
must里面的两个combined_fields查询，boost分别设置为2和0.6，和其他查询条件一起，都放到should里面，设置minimum_should_match==1 2. 如果keywords_query跟combined_fields主查询的query一样，那么不需要再添加了
-
…nt.py)、[search/searcher.py](/data/saas-search/search/searcher.py)、[frontend/static/js/app.js](/data/saas-search/frontend/static/js/app.js) 以及 [tests/test_rerank_client.py](/data/saas-search/tests/test_rerank_client.py)。 主要修复内容如下： - 精排现依据融合阶段得分进行排序，而非仅依据原始的 `fine_score`。 - 最终重排不再依赖独立的 `fine_scores` 数组（该数组在精排排序后可能产生同步偏差），而是直接读取命中结果附带的 `_fine_score`。 - 精排与最终重排现均通过同一计算路径生成融合调试信息，该路径同时也决定实际排序结果，从而保证记录逻辑与生产逻辑保持一致。 - 调试信息载荷更加清晰：精排和最终重排阶段都会暴露融合输入/因子以及规范的 `fusion_summary`，前端界面现在会渲染该摘要信息。 主要问题：阶段逻辑重复且存在并行的数据通道：一个通道用于计算排序，另一个通道用于组装调试字段，还有第三个通道用于传递辅助数组。这造成了潜在的差异风险。本次重构通过将阶段得分作为唯一事实来源，并让调试/前端直接消费其输出而非事后重构，降低了该风险。 验证结果： - `./.venv/bin/python -m pytest -q tests/test_rerank_client.py tests/test_search_rerank_window.py` - `./.venv/bin/python -m py_compile search/rerank_client.py search/searcher.py` 结果：`22 passed`。 当前的主流程： 1. Query 解析 2. ES 召回 3. 粗排：只用 ES 内部文本/KNN 信号 4. 款式 SKU 选择 + title suffix 5. 精排：轻量 reranker + 文本/KNN 融合 6. 最终 rerank：重 reranker + fine score + 文本/KNN 融合 7. 分页、补全字段、格式化返回 主控代码在 [searcher.py](/data/saas-search/search/searcher.py)，打分与 rerank 细节在 [rerank_client.py](/data/saas-search/search/rerank_client.py)，配置定义在 [schema.py](/data/saas-search/config/schema.py) 和 [config.yaml](/data/saas-search/config/config.yaml)。 **先看入口怎么决定走哪条路** 在 [searcher.py:348](/data/saas-search/search/searcher.py#L348) 开始，`search()` 先读租户语言、开关、窗口大小。 关键判断在 [searcher.py:364](/data/saas-search/search/searcher.py#L364) 到 [searcher.py:372](/data/saas-search/search/searcher.py#L372)： - `rerank_window` 现在是 80，见 [config.yaml:256](/data/saas-search/config/config.yaml#L256) - `coarse_rank.input_window` 是 700，`output_window` 是 240，见 [config.yaml:231](/data/saas-search/config/config.yaml#L231) - `fine_rank.input_window` 是 240，`output_window` 是 80，见 [config.yaml:245](/data/saas-search/config/config.yaml#L245) 所以如果请求满足 `from_ + size <= rerank_window`，就进入完整漏斗： - ES 实际取前 `700` - 粗排后留 `240` - 精排后留 `80` - 最终 rerank 也只处理这 `80` - 最后再做分页切片 如果请求页超出 80，就不走后面的多阶段漏斗，直接按 ES 原逻辑返回。
27 Mar, 2026
7 commits
-
coarse_rank.output_window -> 再做 SKU 选择和 title suffix -> 精排调用轻量 reranker 裁到 fine_rank.output_window -> 最终重排调用现有 reranker，并在最终融合里加入 fine_score。同时把 reranker client/provider 改成了按 service_profile 选不同 service_url，这样 fine/final 可以共用同一套服务代码，只起不同实例。
-
TODO-keywords限定-done.txt
-
重排融合：之前有knn的配置bias和exponential。现在，文本和图片的embedding相似需要融合，融合方式是dis_max，因此需要配置： 1）各自的权重和tie_breaker 2）整个向量方面的权重（bias和exponential）
26 Mar, 2026
2 commits
25 Mar, 2026
5 commits
-
@config/dictionaries/style_intent_color.csv @config/dictionaries/style_intent_size.csv @query/style_intent.py @search/sku_intent_selector.py 1. 两个csv词典，分为三列， - 英文关键词 - 中文关键词 - 标准属性名称词 三列都可以允许逗号分割。补充的第三列使用在商品属性中，使用的是标准的英文名称 2. 判断意图的时候，中文词用中文翻译名去匹配，如果不存在中文翻译名，则用原始 query，英文词同理 3. SKU 选择的时候，用每一个 SKU 的属性名去匹配。 匹配规则要大幅度简化，并做性能优化： 1）文本匹配规则只需要看规范化后的属性值是否包含了词典配置的第三列"标准属性名称词"，如果包含了，则认为匹配成功。 找到第一个匹配成功的即可。如果都没有成功，后面也不再需要用向量匹配。 暂时废弃向量匹配、双向匹配等复杂逻辑。
24 Mar, 2026
4 commits
-
加了一个过滤/降权词典，query中有独立分词匹配到指定的触发词，将过滤带某些分词的商品（比如fitted/修身，过滤宽松、loose、relaxed、baggy,slouchy等商品） 2. reranker的query使用翻译后的
-
上面一版实现，性能上完全无法接受。因此进行了一轮策略简化 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
-
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
23 Mar, 2026
5 commits
-
子句都变成了一个带有以下结构的命名布尔查询： must：combined_fields should：加权后的 best_fields 和 phrase 子句 主要改动位于 search/es_query_builder.py，但此次调整沿用了现有语言路由设计，并未引入一次性分支。额外的 should 子句权重现在通过 config/schema.py、config/loader.py、search/searcher.py 以及 config/config.yaml 进行配置驱动，从而保持结构的集中管理。