02 Dec, 2025
2 commits
-
后端请求模型变更（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 以上两种方式都可以
01 Dec, 2025
1 commit
-
不同维度（不同的 name）：求交集 相同维度（相同的 name）：求并集
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
1 commit
25 Nov, 2025
2 commits
-
主要是对 分类 属性 子sku 等重要字段的处理。 参考文档《 @docs/索引字段说明v2-mapping结构.md 》《 @docs/索引字段说明v2.md 》 feat: 1. 更新 field_types.py 添加 hanlp_index/hanlp_standard 分析器映射（映射到 CHINESE_ECOMMERCE/CHINESE_ECOMMERCE_QUERY） 支持 keyword_normalizer 配置（用于 vendor.keyword 的 lowercase normalizer） 更新 get_default_analyzers() 添加 hanlp 分析器和 lowercase normalizer 修复 image_embedding 的 url 字段类型为 text 2. 更新 config.yaml（32-207行） 移除无用字段：handle, seo_title, seo_description, seo_keywords, shoplazza_created_at, shoplazza_updated_at 添加中英文字段：title_zh, title_en, brief_zh, brief_en, description_zh, description_en, vendor_zh, vendor_en 添加 category 多层级字段：category_path_zh, category_path_en, category_name_zh, category_name_en, category_id, category_name, category_level, category1_name, category2_name, category3_name 添加 specifications 嵌套字段 添加 option 名称字段：option1_name, option2_name, option3_name 添加 SKU 扁平化字段：sku_prices, sku_weights, sku_weight_units, total_inventory 更新 skus 嵌套结构以匹配目标 mapping 添加 image_embedding 嵌套字段 更新 indexes 配置以使用新字段名 3. 更新 config_loader.py 添加 keyword_normalizer 字段支持 4. 重构 spu_transformer.py 添加 load_option_data() 方法从 option 表加载数据 更新 transform_batch() 加载 option 数据 重构 _transform_spu_to_doc()： 实现中英文字段映射（暂时只填充中文） 实现 category 多层级字段映射和 category_path 解析 实现 specifications 构建（从 option 表获取 name，从 SKU 获取 value） 实现 option 名称字段映射 实现 SKU 扁平化字段计算 更新 skus 嵌套结构 重构 _transform_sku_row() 以匹配新的 SKU 结构 移除 SEO 和 handle 字段的处理
20 Nov, 2025
2 commits
18 Nov, 2025
2 commits
17 Nov, 2025
1 commit
14 Nov, 2025
21 commits
13 Nov, 2025
4 commits
-
主要变更： 1. 去掉数据源应用结构配置化，我们只针对店匠的spu sku表设计索引，数据灌入流程是写死的(只是满足测试需求，后面外层应用负责数据全量+增量灌入)。搜索系统主要关注如何适配外部搜索需求 目前有两个数据灌入脚本，一种是之前的，一种是现在的从两个店匠的表sku表+spu表读取并且以spu为单位组织doc。 - 配置只关注ES搜索相关配置，提高可维护性 - 创建base配置（店匠通用配置） 2. 索引结构重构（SPU维度） - 所有客户共享search_products索引，通过tenant_id隔离 - 支持嵌套variants字段（SKU变体数组） - 创建SPUTransformer用于SPU数据转换 3. API响应格式优化 - 约定一套搜索结果的格式，而不是直接暴露ES doc的结构(_id _score _source内的字段） - 添加ProductResult和VariantResult模型 - 添加suggestions和related_searches字段 (预留接口，逻辑暂未实现) 4. 数据导入流程 - 创建店匠数据导入脚本（ingest_shoplazza.py） - Pipeline层决定数据源，配置不包含数据源信息 - 创建测试数据生成和导入脚本 5. 文档更新 - 更新设计文档，反映新架构 - 创建BASE_CONFIG_GUIDE.md使用指南
11 Nov, 2025
1 commit
-
## 🎯 Major Features - Request context management system for complete request visibility - Structured JSON logging with automatic daily rotation - Performance monitoring with detailed stage timing breakdowns - Query analysis result storage and intermediate result tracking - Error and warning collection with context correlation ## 🔧 Technical Improvements - **Context Management**: Request-level context with reqid/uid correlation - **Performance Monitoring**: Automatic timing for all search pipeline stages - **Structured Logging**: JSON format logs with request context injection - **Query Enhancement**: Complete query analysis tracking and storage - **Error Handling**: Enhanced error tracking with context information ## 🐛 Bug Fixes - Fixed DeepL API endpoint (paid vs free API confusion) - Fixed vector generation (GPU memory cleanup) - Fixed logger parameter passing format (reqid/uid handling) - Fixed translation and embedding functionality ## 🌟 API Improvements - Simplified API interface (8→5 parameters, 37.5% reduction) - Made internal functionality transparent to users - Added performance info to API responses - Enhanced request correlation and tracking ## 📁 New Infrastructure - Comprehensive test suite (unit, integration, API tests) - CI/CD pipeline with automated quality checks - Performance monitoring and testing tools - Documentation and example usage guides ## 🔒 Security & Reliability - Thread-safe context management for concurrent requests - Automatic log rotation and structured output - Error isolation with detailed context information - Complete request lifecycle tracking 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com>