ai-saas / saas-search

07 Apr, 2026

1 commit

03 Apr, 2026

1 commit

02 Apr, 2026

1 commit

  • 465f90e1   添加LTR数据收集 ... Browse File » 
    目前在54训练数据里面，拆分44条train + 10
test，训练集显著提升但是test上不及基线
作为基础设施保留，以后可以考虑扩大数据集进行使用
    tangwang
     

01 Apr, 2026

2 commits

31 Mar, 2026

1 commit

30 Mar, 2026

1 commit

  • c3425429   在以下文件中完成精排/融合清理工作：[search/rerank_client.py](/data/saas-search/search/rerank_clie… ... Browse File » 
    …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 原逻辑返回。
    tangwang
     

23 Mar, 2026

1 commit

22 Mar, 2026

2 commits

21 Mar, 2026

1 commit

20 Mar, 2026

1 commit

18 Mar, 2026

1 commit

10 Mar, 2026

1 commit

11 Feb, 2026

1 commit

06 Jan, 2026

1 commit

  • d7d48f52   改动（mapping + 灌入结构） ... Browse File » 
    mappings/search_products.json：把原来的 title_zh/title_en/brief_zh/... 改成 按语言 key 的对象结构（ /products/_doc/1 { "title": {"en":...} } ）
同时在这些字段下 预置了全部 analyzer 语言:
arabic, armenian, basque, brazilian, bulgarian, catalan, chinese, cjk, czech, danish, dutch, english, finnish, french, galician, german, greek, hindi, hungarian, indonesian, italian, norwegian, persian, portuguese, romanian, russian, spanish, swedish, turkish, thai

实现为 type: object + properties，同时满足“按语言灌入”和“按语言 analyzer”。
索引灌入（全量/增量/transformer）已同步改完
indexer/document_transformer.py：输出从 title_zh/title_en/... 改为：
title: {<primary_lang>: 原文, en?: 翻译, zh?: 翻译}
brief/description/vendor 同理
category_path/category_name_text 也改为语言对象（避免查询侧继续依赖旧字段）
indexer/incremental_service.py：embedding 取值从 title_en/title_zh 改为从 title 对象里优先取 en，否则取 zh，否则取任一可用语言。
查询侧与配置、API/文档已同步
search/es_query_builder.py：查询字段统一改成点路径：title.zh / title.en / vendor.zh / vendor.zh.keyword / category_name_text.zh 等。
config/config.yaml：field boosts / indexes 里的字段名同步为新点路径。
API & formatter：
api/result_formatter.py 已支持新结构（并保留对旧 *_zh/_en 的兼容兜底）。
api/models.py、相关 docs/examples 里的 vendor_zh.keyword 等已更新为 vendor.zh.keyword。
文档/脚本：docs/、README.md、scripts/ 里所有旧字段名引用已批量替换为新结构。
    tangwang
     

07 Dec, 2025

1 commit

  • 0064e946   feat: 增量索引服务、租户配置和翻译功能集成 ... Browse File » 
    主要功能：
1. 增量数据获取服务
   - 新增 IncrementalIndexerService 提供单个SPU数据获取
   - 新增 /indexer/spu/{spu_id} API接口
   - 服务启动时预加载分类映射等公共数据
   - 提取 SPUDocumentTransformer 统一全量和增量转换逻辑
   - 支持根据租户配置进行语言处理和翻译

3. 租户配置系统
   - 租户配置合并到统一配置文件 config/config.yaml
   - 支持每个租户独立配置主语言和翻译选项
   - 租户162配置为翻译关闭（用于测试）

4. 翻译功能集成
   - 翻译提示词作为DeepL API的context参数传递
   - 支持中英文提示词配置
   - 索引场景：同步翻译，使用缓存
   - 查询场景：异步翻译，立即返回

测试：
- 新增 indexer/test_indexing.py 和 query/test_translation.py
- 验证租户162翻译关闭功能
- 验证全量和增量索引功能
    tangwang
     

05 Dec, 2025

1 commit

  • 7bc756c5   优化 ES 查询构建 ... Browse File » 
    将 must 子句改为 should 子句的多查询策略
实现以下查询类型：
base_query：主查询，使用 AND 操作符和 75% minimum_should_match
翻译查询：跨语言查询，boost=0.4
短语查询：短查询的精确短语匹配
关键词查询：基于提取名词的查询，boost=0.1
添加 _get_match_fields() 方法，支持中英文字段动态映射
4. 关键改进点
minimum_should_match 从 67% 提升到 75%
添加 operator: "AND" 确保所有词都匹配
使用 should 子句实现多策略融合
支持短语查询和关键词查询的智能触发
    tangwang