11 Apr, 2026
1 commit
-
这次代码侧的核心变化是： - 删除了 `indexer/product_enrich.py`、`indexer/product_enrich_prompts.py` 及相关单测。 - 在 [api/routes/indexer.py](/data/saas-search/api/routes/indexer.py:55) 移除了 `/indexer/enrich-content` 路由；现在这个路径在本仓库 indexer 服务里会是 `404`，对应契约测试也已改成校验移除状态：[tests/ci/test_service_api_contracts.py](/data/saas-search/tests/ci/test_service_api_contracts.py:345)。 - 在 [api/routes/indexer.py](/data/saas-search/api/routes/indexer.py:183)、[indexer/document_transformer.py](/data/saas-search/indexer/document_transformer.py:109)、[indexer/incremental_service.py](/data/saas-search/indexer/incremental_service.py:587)、[indexer/spu_transformer.py](/data/saas-search/indexer/spu_transformer.py:223) 去掉了构建 doc 时自动补 `qanchors` / `enriched_*` 的本地 LLM 富化逻辑。现在 `build-docs` / `reindex` / `index` 只负责基础文档构建。 - 在 [config/schema.py](/data/saas-search/config/schema.py:316)、[config/loader.py](/data/saas-search/config/loader.py:824)、[config/env_config.py](/data/saas-search/config/env_config.py:37)、[config/config.yaml](/data/saas-search/config/config.yaml:32) 清掉了旧实现专用的 `product_enrich` 和 anchor cache 配置面。 重要文档也一起同步了，重点是把“能力已迁出、本仓库不再内置生成”写明确： - [README.md](/data/saas-search/README.md:113) - [docs/搜索API对接指南-00-总览与快速开始.md](</data/saas-search/docs/搜索API对接指南-00-总览与快速开始.md:108>) - [docs/搜索API对接指南-05-索引接口（Indexer）.md](</data/saas-search/docs/搜索API对接指南-05-索引接口（Indexer）.md:647>) - [docs/搜索API对接指南-07-微服务接口（Embedding-Reranker-Translation）.md](</data/saas-search/docs/搜索API对接指南-07-微服务接口（Embedding-Reranker-Translation）.md:441>) - [docs/工作总结-微服务性能优化与架构.md](</data/saas-search/docs/工作总结-微服务性能优化与架构.md:96>) - [docs/缓存与Redis使用说明.md](</data/saas-search/docs/缓存与Redis使用说明.md:186>) - [indexer/README.md](/data/saas-search/indexer/README.md:508) - [indexer/ANCHORS_AND_SEMANTIC_ATTRIBUTES.md](/data/saas-search/indexer/ANCHORS_AND_SEMANTIC_ATTRIBUTES.md:1) 验证做了两步： - `python3 -m compileall ...` 通过 - `source activate.sh && python -m pytest tests/ci/test_service_api_contracts.py -q` 通过，`31 passed` 剩下我认为仍有“旧信息”但暂时没动的，主要是历史记录类文档，不算当前对接口径： - [docs/issues/issue.md](/data/saas-search/docs/issues/issue.md:295) - [docs/issues/issue.txt](/data/saas-search/docs/issues/issue.txt:468) - [docs/issues/issue-2026-03-29-索引修改-done-0330.md](</data/saas-search/docs/issues/issue-2026-03-29-索引修改-done-0330.md:23>) - [docs/issues/issue-2026-04-04-增加多模态标注-TODO.md](</data/saas-search/docs/issues/issue-2026-04-04-增加多模态标注-TODO.md:1>) 另外，工作区里原本就有 `.env` 修改和未跟踪的 `AGENTS.md`，我没有动它们。
10 Apr, 2026
1 commit
09 Apr, 2026
2 commits
-
问题背景： - scripts/ 目录下混有服务启动、数据转换、性能压测、临时脚本及历史备份目录 - 存在大量中间迭代遗留信息，不利于维护和新人理解 - 现行服务编排已稳定为 service_ctl up all 的集合：tei / cnclip / embedding / embedding-image / translator / reranker / backend / indexer / frontend / eval-web，不再保留 reranker-fine 默认位 调整内容： 1. 根 scripts/ 收敛为运行、运维、环境、数据处理脚本，并新增 scripts/README.md 说明文档 2. 性能/压测/调参脚本整体迁至 benchmarks/ 目录，同步更新 benchmarks/README.md 3. 人工试跑脚本迁至 tests/manual/ 目录，同步更新 tests/manual/README.md 4. 删除明确过时内容： - scripts/indexer__old_2025_11/ - scripts/start.sh - scripts/install_server_deps.sh 5. 同步修正以下文档中的路径及过时描述： - 根目录 README.md - 性能报告相关文档 - reranker/translation 模块文档 技术细节： - 性能测试不放常规 tests/ 的原因：这类脚本依赖真实服务、GPU、模型和环境噪声，不适合作为稳定回归门禁；benchmarks/ 更贴合其定位 - tests/manual/ 仅存放需要人工启动依赖、手工观察结果的接口试跑脚本 - 所有迁移后的 Python 脚本已通过 py_compile 语法校验 - 所有迁移后的 Shell 脚本已通过 bash -n 语法校验 校验结果： - py_compile: 通过 - bash -n: 通过
-
2. 删掉自动推断 taxonomy profile的逻辑，build_index_content_fields() 3. 所有 taxonomy profile 都输出 zh/en”，并把按行业切语言的逻辑去掉 只接受显式传入的 category_taxonomy_profile
08 Apr, 2026
1 commit
-
Previously, both `b` and `k1` were set to `0.0`. The original intention was to avoid two common issues in e-commerce search relevance: 1. Over-penalizing longer product titles In product search, a shorter title should not automatically rank higher just because BM25 favors shorter fields. For example, for a query like “遥控车”, a product whose title is simply “遥控车” is not necessarily a better candidate than a product with a slightly longer but more descriptive title. In practice, extremely short titles may even indicate lower-quality catalog data. 2. Over-rewarding repeated occurrences of the same term For longer queries such as “遥控喷雾翻滚多功能车玩具车”, the default BM25 behavior may give too much weight to a term that appears multiple times (for example “遥控”), even when other important query terms such as “喷雾” or “翻滚” are missing. This can cause products with repeated partial matches to outrank products that actually cover more of the user intent. Setting both parameters to zero was an intentional way to suppress length normalization and term-frequency amplification. However, after introducing a `combined_fields` query, this configuration becomes too aggressive. Since `combined_fields` scores multiple fields as a unified relevance signal, completely disabling both effects may also remove useful ranking information, especially when we still want documents matching more query terms across fields to be distinguishable from weaker matches. This update therefore relaxes the previous setting and reintroduces a controlled amount of BM25 normalization/scoring behavior. The goal is to keep the original intent — avoiding short-title bias and excessive repeated-term gain — while allowing the combined query to better preserve meaningful relevance differences across candidates. Expected effect: - reduce the bias toward unnaturally short product titles - limit score inflation caused by repeated occurrences of the same term - improve ranking stability for `combined_fields` queries - better reward candidates that cover more of the overall query intent, instead of those that only repeat a subset of terms
07 Apr, 2026
1 commit
03 Apr, 2026
1 commit
02 Apr, 2026
1 commit
01 Apr, 2026
4 commits
31 Mar, 2026
4 commits
30 Mar, 2026
4 commits
-
…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
8 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
4 commits
25 Mar, 2026
8 commits
-
（之前因为错误将attention方法该回到TRITON_ATTN，性能相比于之前的vllm版本更差。但是那个错误是能解决的。已修复保持FLASHINFER）
-
报错），并允许通过配置或环境变量让 vLLM 自行选择 attention。 -- 临时版本
-
这两个配置、四种情况： backend: qwen3_vllm | qwen3_vllm_score instruction_format: compact | standard 调用 python scripts/benchmark_reranker_random_titles.py 100,200,400,600,800,1000 --repeat 5 产出性能测试报告 平均延迟（ms，客户端 POST /rerank 墙钟，--seed 99） backend instruction_format n=100 n=200 n=400 n=600 n=800 n=1000 qwen3_vllm compact 213.5 418.0 861.4 1263.4 1744.3 2162.2 qwen3_vllm standard 254.9 475.4 909.7 1353.2 1912.5 2406.7 qwen3_vllm_score compact 239.2 480.2 966.2 1433.5 1937.2 2428.4 qwen3_vllm_score standard 299.6 591.8 1178.9 1773.7 2341.6 2931.7 归纳： 在本机 T4、当前 vLLM 与上述 YAML（max_model_len=160、infer_batch_size=100 等）下，两种后端都是 compact 快于 standard；整体最快为 qwen3_vllm + compact（n=1000 ≈ 2.16 s），最慢为 qwen3_vllm_score + standard（≈ 2.93 s）。其他 GPU / vLLM 版本下排序可能变化。