02 Mar, 2026
2 commits
-
- 新增 `suggestion` 模块： - `suggestion/mapping.py`：`search_suggestions` mapping 生成（多语言 `completion` + `search_as_you_type`） - `suggestion/builder.py`：全量构建程序（扫描 `search_products` 的 `title/qanchors` + MySQL `shoplazza_search_log`） - `suggestion/service.py`：在线查询服务（suggestion 检索 + 结果直达商品二次查询） - `suggestion/__init__.py` - 接入 API 服务初始化： - `api/app.py` 新增 `SuggestionService` 初始化和 `get_suggestion_service()` - 接口实现： - `api/routes/search.py` 的 `GET /search/suggestions` 从“空框架”改为真实调用 - 支持参数： - `q`, `size`, `language` - `with_results`（是否直达商品） - `result_size`（每条 suggestion 商品数） - `debug` - 继续要求 `X-Tenant-ID`（或 query 的 `tenant_id`） - 模型补充： - `api/models.py` 增加 suggestion 请求/响应字段（`language`, `resolved_language`, `with_results`, `result_size`） - CLI 全量构建命令： - `main.py` 新增 `build-suggestions` - 使用方式： - `python main.py build-suggestions --tenant-id 1 --recreate` - 可选：`--days 30 --batch-size 500 --min-query-len 1 --es-host ...` --- 关键实现逻辑（已编码） - 语言归属优先级（按你要求）： - `shoplazza_search_log.language` > `request_params.language` > 脚本/模型兜底 - 候选词聚合键： - `(tenant_id, lang, text_norm)`（文档唯一） - 评分： - 基于 `query_count_30d/7d + qanchor_doc_count + title_doc_count` 的离线分 - 结果直达： - 对每条 suggestion 在 `search_products_tenant_{id}` 做二次查询（`qanchors/title` 组合） --- 变更文件 - `api/app.py` - `api/models.py` - `api/routes/search.py` - `main.py` - `suggestion/__init__.py` - `suggestion/mapping.py` - `suggestion/builder.py` - `suggestion/service.py` -
- 新增 /indexer/build-docs 与 /indexer/build-docs-from-db 接口：前者接收上游传入的 SPU/SKU/Option 原始行数据构建 ES doc（不写 ES），后者在测试场景下基于 tenant_id+spu_ids 内部查库并复用同一套文档构建逻辑 - 调整增量与全量索引 SQL 与聚合逻辑：移除 shoplazza_product_spu.compare_at_price 读取，统一从 SKU 表聚合最大 compare_at_price，修复 1054 列不存在错误，保证 ES 字段 compare_at_price 来源与索引字段说明v2 保持一致 - 更新 SPUDocumentTransformer：完善价格区间计算、compare_at_price 聚合以及多语言字段输出，确保输出结构与 mappings/search_products.json、Java 侧 ProductIndexDocument 完全对齐 - 为 indexer 模块补充 README 与 prompts：系统化说明 Java 调度 + Python 富化的职责划分、翻译缓存方案（Redis translation:{tenant_id}:{target_lang}:{md5(text)}）以及 HTTP 接口使用方式 - 更新顶层 README、搜索API对接指南与测试Pipeline说明：增加关于 indexer 专用服务（serve-indexer, 端口6004）、正式文档构建接口以及手动链路验证（MySQL → build-docs → ES 查询对比）的说明 - 清理并修正 ES 诊断脚本 docs/常用查询 - ES.md：统一改为 per-tenant 索引 search_products_tenant_{tenant_id}，修正过期字段名（keywords 等）和分面聚合字段（去掉 .keyword，使用当前 mapping 中的字段） Made-with: Cursor
06 Feb, 2026
1 commit
-
--- 1. `search/es_query_builder.py`：`_all` 分支 - **普通字段**（如 `tags_all`, `category1_name_all`）： - 键以 `_all` 结尾时，先去掉后缀得到 ES 字段名。 - 若值为**数组**：生成 `bool.must`，内含多个 `term`，即多值 **AND**。 - 若值为**单值**：生成一个 `term`。 - **specifications_all**： - 值为 `[{name, value}, ...]` 时，为每一项生成一个 nested 查询，全部放入同一个 `bool.must`，即列表内所有规格条件都要满足（AND）。 原有逻辑不变：不带 `_all` 的字段，数组仍为 OR（`terms`），单值仍为 `term`。 2. `api/models.py`：filters 说明 - 在 `filters` 的 `description` 中补充： - 字段名加 `_all` 表示 AND（如 `tags_all: ['A','B']` 表示同时包含 A 和 B）。 - `specifications_all` 表示列表内所有规格条件都要满足。 3. `docs/搜索API对接指南.md`：文档 - 在 3.3.1 开头说明：任意字段名可加 `_all` 后缀表示多值 AND。 - 在格式示例中增加 `tags_all`、`category1_name_all` 示例。 - 在「支持的值类型」中说明：数组在带 `_all` 时为 AND。 - 新增小节「`*_all` 语义（多值 AND）」：说明用法及 `specifications_all` 行为。 - 在「常用过滤字段」中补充：以上字段均可加 `_all` 后缀。 --- **使用示例** ```json { "filters": { "tags": ["手机", "促销"], "tags_all": ["手机", "促销", "新品"] } } ``` - `tags`：命中「手机」或「促销」或两者都有（OR）。 - `tags_all`：必须同时包含「手机」「促销」「新品」三个标签（AND）。
05 Feb, 2026
2 commits
-
- API：新增请求参数 ai_search，开启时在窗口内走重排流程 - 配置：RerankConfig 移除 enabled/expression/description，仅保留 rerank_window 及 service_url/timeout_sec/weight_es/weight_ai；默认超时 15s - 重排流程：ai_search 且 from+size<=rerank_window 时，ES 取前 rerank_window 条， 调用外部 /rerank 服务，融合 ES 与重排分数后按 from/size 分页；否则不重排 - search/rerank_client：新增模块，封装 build_docs、call_rerank_service、 fuse_scores_and_resort、run_rerank；超时单独捕获并简短日志 - search/searcher：移除 RerankEngine，enable_rerank=ai_search，使用 config.rerank 参数 - 删除 search/rerank_engine.py（本地表达式重排），统一为外部服务一种实现 - 文档：搜索 API 对接指南补充 ai_search 与 relevance_score 说明 - 测试：conftest 中 rerank 配置改为新结构 Co-authored-by: Cursor <cursoragent@cursor.com>
27 Jan, 2026
1 commit
-
2. 返回query_normlized
26 Jan, 2026
1 commit
-
文档： 翻译模块说明.md
24 Jan, 2026
1 commit
-
2. 设置sku_filter_dimension参数的默认值为option1
06 Jan, 2026
3 commits
-
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/ 里所有旧字段名引用已批量替换为新结构。
31 Dec, 2025
1 commit
27 Dec, 2025
1 commit
25 Dec, 2025
1 commit
-
问题：nested 聚合统计的是嵌套文档（specifications 条目）数量，而不是产品（父文档）数量。 修复内容： 在 es_query_builder.py 中：为 specifications 分面的聚合添加了 reverse_nested 子聚合，用于统计产品数量： "aggs": { "product_count": { "reverse_nested": {} } } 在 result_formatter.py 中：更新读取逻辑，从 product_count.doc_count 读取产品数量，而不是直接使用 doc_count。 修复效果： 之前：分面显示 62（统计了 62 个嵌套文档/规格条目） 现在：分面显示实际的产品数量（例如 2），与搜索结果数量一致
22 Dec, 2025
1 commit
19 Dec, 2025
2 commits
-
1. api/indexer_app.py（索引服务，端口 6004） 在 startup_event() 中添加线程池大小配置 使用 anyio.to_thread.current_default_thread_limiter() 设置线程池大小为 48 添加日志记录，便于确认配置是否生效 2. api/app.py（搜索服务，端口 6002） 在 startup_event() 中添加线程池大小配置 同样设置为 48 个线程 添加日志记录
-
1. 添加 asyncio 导入 在文件顶部添加 import asyncio，用于在线程池中执行同步阻塞操作 2. 修改 /indexer/reindex 路由（全量索引） 使用 loop.run_in_executor() 将 service.bulk_index() 放到线程池执行 避免阻塞事件循环，允许其他请求并行处理 3. 修改 /indexer/index 路由（增量索引） 使用 loop.run_in_executor() 将 service.index_spus_to_es() 放到线程池执行 确保全量索引和增量索引可以并行执行 工作原理 线程池执行：同步阻塞操作（如数据库查询、ES 写入）在线程池中执行，不阻塞事件循环 并发支持： 全量索引占用一个线程 增量索引可同时使用其他线程 多个增量请求可并行处理 资源管理： 数据库连接池（pool_size=10, max_overflow=20）可支持并发请求 uvicorn 默认线程池（40 个线程）可处理多个并发请求
18 Dec, 2025
2 commits
-
新增：scripts/recreate_index.py 功能：初始化 indexer 的 ES/DB 服务，然后调用 BulkIndexingService.bulk_index(…, recreate_index=True) 为指定 tenant_id 做「删除并重建索引 + 全量导入」。 用法示例： cd /home/tw/SearchEngine# 使用默认 batch_size=500python scripts/recreate_index.py 162# 指定 batch_sizepython scripts/recreate_index.py 162 --batch-size 1000 脚本依赖和 Indexer API 一样的环境变量：DB_HOST/DB_PORT/DB_DATABASE/DB_USERNAME/DB_PASSWORD、ES_HOST/ES_USERNAME/ES_PASSWORD。 2. 清理与引用更新 原来的 scripts/recreate_index.sh 已经删除。 api/routes/indexer.py 里的说明改成引用 scripts/recreate_index.py。 docs/搜索API对接指南.md 中的提示也从 .sh 改为： > python scripts/recreate_index.py <tenant_id> [--batch-size 500]
-
新增 api/indexer_app.py，在独立进程（默认 6004）中初始化 ES + DB + 索引服务，并复用 api/routes/indexer.py 一套路由 新增 api/service_registry.py，通过注册表向索引路由注入 ES 客户端和索引服务，消除重复代码与循环依赖 main.py 增加 serve-indexer 子命令；scripts/start.sh / stop.sh / start_backend.sh / start_indexer.sh 支持独立管理索引进程 文档中所有索引相关示例由 6002/indexer/* 统一调整为 6004/indexer/*
09 Dec, 2025
2 commits
-
因为请求改成了两个list， 响应也是对应的两个list，一个是spu_ids对应的响应的list，每个id对应的有处理结果 indexed、deleted、failed，如果是failed会带msg。 delete_spu_ids也是对应一个list，对应的结果又deleted / failed。 2. API文档对应修改
-
tenant_id spu_ids delete_spu_ids spu_ids里面的，如果is_delete字段为1，我这边也要做删除。 delete_spu_ids的 直接删除 为您的变更输入提交说明。以 '#' 开始的行将被忽略，而一个空的提交
08 Dec, 2025
2 commits
-
新增功能： - 新增 POST /indexer/index 增量索引接口，支持按SPU ID列表进行增量索引 - 新增 indexer/indexer_logger.py 索引日志模块，统一记录全量和增量索引日志到 logs/indexer.log（JSON格式） - IncrementalIndexerService 新增 index_spus_to_es 方法，实现增量索引功能 接口重命名： - POST /indexer/bulk -> POST /indexer/reindex（全量重建索引） - POST /indexer/incremental -> POST /indexer/index（增量索引） - POST /indexer/spus -> POST /indexer/documents（查询文档） 日志系统： - 全量和增量索引操作统一记录到 logs/indexer.log - 记录请求参数、处理过程、ES写入结果、成功/失败统计等关键信息 - 支持按索引类型、租户ID、SPU ID等维度查询日志 文档更新： - 更新接口文档，包含新的接口命名和增量索引接口说明 - 添加日志查询示例（grep和jq两种方式）
-
- 新增批量索引接口: POST /indexer/bulk - 全量索引功能 - SPU接口改进: POST /indexer/spus - 支持批量获取SPU文档（最多100个） 新增 全量索引服务 indexer/bulk_indexing_service.py docs/搜索API对接指南.md - 新增索引接口文档: 详细的批量索引和SPU索引接口说明 - 请求示例: 提供完整的curl命令示例
07 Dec, 2025
1 commit
-
主要功能： 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翻译关闭功能 - 验证全量和增量索引功能
05 Dec, 2025
1 commit
-
2. queries
04 Dec, 2025
1 commit
-
核心功能： - 添加 multi_select 字段到 FacetConfig（默认为 true） - 实现 post_filter 支持 disjunctive faceting - 后端自动标记 facet 值的 selected 状态 - 支持 specifications 和普通字段的 multi-select 技术改进： - ESQueryBuilder: 分离 conjunctive/disjunctive filters - ResultFormatter: 根据 current_filters 标记 selected - Searcher: 传递 facet_configs 给 query builder 文档更新： - 添加 multi_select_faceting.md 详细文档 - 更新 API 对接指南，说明新功能 - 添加测试脚本 test_multi_select_facet.py 业界标准： - 遵循 Elasticsearch/Algolia/Amazon 的最佳实践 - 提供探索式搜索体验 - 前后端职责清晰分离
03 Dec, 2025
2 commits
-
{ "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 的组装格式 完全一样。前端不需要感知 属性分面 和 类别等其他字段分面的差异。
02 Dec, 2025
4 commits
-
1. 加了一个配置searchable_option_dimensions，功能是配置子sku的option1_value option2_value option3_value 哪些参与检索（进索引、以及在线搜索的时候将对应字段纳入搜索field）。格式为list，选择三者中的一个或多个。 2. 索引 @mappings/search_products.json 要加3个字段 option1_values option2_values option3_values，各自的 数据灌入（mysql->ES）的模块也要修改，这个字段是对子sku的option1_value option2_value option3_value分别提取去抽后得到的list。 searchable_option_dimensions 中配置的，才进索引，比如 searchable_option_dimensions = ['option1'] 则 只对option1提取属性值去重组织list进入索引，其余两个字段为空 3. 在线 对应的将 searchable_option_dimensions 中 对应的索引字段纳入 multi_match 的 fields，权重设为0.5 （各个字段的权重配置放到一起集中管理） 1. 配置文件改动 (config/config.yaml) ✅ 在 spu_config 中添加了 searchable_option_dimensions 配置项，默认值为 ['option1', 'option2', 'option3'] ✅ 添加了3个新字段定义：option1_values, option2_values, option3_values，类型为 KEYWORD，权重为 0.5 ✅ 在 default 索引域的 fields 列表中添加了这3个字段，使其参与搜索 2. ES索引Mapping改动 (mappings/search_products.json) ✅ 添加了3个新字段：option1_values, option2_values, option3_values，类型为 keyword 3. 配置加载器改动 (config/config_loader.py) ✅ 在 SPUConfig 类中添加了 searchable_option_dimensions 字段 ✅ 更新了配置解析逻辑，支持读取 searchable_option_dimensions ✅ 更新了配置转换为字典的逻辑 4. 数据灌入改动 (indexer/spu_transformer.py) ✅ 在初始化时加载配置，获取 searchable_option_dimensions ✅ 在 _transform_spu_to_doc 方法中添加逻辑： 从所有子SKU中提取 option1, option2, option3 值 去重后存入 option1_values, option2_values, option3_values 根据配置决定哪些字段实际写入数据（未配置的字段写空数组） =
-
后端请求模型变更（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"] } -
sku_filter_dimension=color sku_filter_dimension=option1 / option2 /option3 以上两种方式都可以
-
query config/ranking config优化
01 Dec, 2025
1 commit
29 Nov, 2025
1 commit
27 Nov, 2025
2 commits
-
1. 搜索API对接指南.md 在“精确匹配过滤器”部分添加了 specifications 嵌套过滤说明 支持单个规格过滤和多个规格过滤（OR 逻辑） 在“分面配置”部分完善了 specifications 分面说明 添加了两种分面模式：所有规格名称和指定规格名称 在“常见场景示例”部分添加了场景5-8，包含规格过滤和分面的完整示例 2. 搜索API速查表.md 在“精确匹配过滤”部分添加了 specifications 过滤的快速参考 在“分面搜索”部分添加了 specifications 分面的快速参考 更新了完整示例，包含 specifications 的使用 3. Search-API-Examples.md 在“过滤器使用”部分添加了示例4-6，展示 specifications 过滤 在“分面搜索”部分添加了示例2-3，展示 specifications 分面 更新了 Python 和 JavaScript 完整示例，包含 specifications 的使用 在“常见使用场景”部分添加了场景2.1，展示带规格过滤的搜索结果页 4. 索引字段说明v2.md 更新了 specifications 字段的查询示例，包含 API 格式和 ES 查询结构 添加了两种分面模式的说明和示例 更新了“分面字段”说明，明确支持指定规格名称的分面 5. 补充参数 参数说明：sku_filter_dimension 是可选参数，用于按指定维度过滤每个SPU下的SKU 支持的维度： 直接选项字段：option1、option2、option3 规格名称：通过 option1_name、option2_name、option3_name 匹配（如 color、size）
-
1. 搜索API对接指南.md 在“精确匹配过滤器”部分添加了 specifications 嵌套过滤说明 支持单个规格过滤和多个规格过滤（OR 逻辑） 在“分面配置”部分完善了 specifications 分面说明 添加了两种分面模式：所有规格名称和指定规格名称 在“常见场景示例”部分添加了场景5-8，包含规格过滤和分面的完整示例 2. 搜索API速查表.md 在“精确匹配过滤”部分添加了 specifications 过滤的快速参考 在“分面搜索”部分添加了 specifications 分面的快速参考 更新了完整示例，包含 specifications 的使用 3. Search-API-Examples.md 在“过滤器使用”部分添加了示例4-6，展示 specifications 过滤 在“分面搜索”部分添加了示例2-3，展示 specifications 分面 更新了 Python 和 JavaScript 完整示例，包含 specifications 的使用 在“常见使用场景”部分添加了场景2.1，展示带规格过滤的搜索结果页 4. 索引字段说明v2.md 更新了 specifications 字段的查询示例，包含 API 格式和 ES 查询结构 添加了两种分面模式的说明和示例 更新了“分面字段”说明，明确支持指定规格名称的分面
26 Nov, 2025
2 commits
14 Nov, 2025
2 commits