09 Apr, 2026
2 commits
-
- 数据转换放到 scripts/data_import/README.md - 诊断巡检放到 scripts/inspect/README.md - 运维辅助放到 scripts/ops/README.md - 前端辅助服务放到 scripts/frontend/frontend_server.py - 翻译模型下载放到 scripts/translation/download_translation_models.py - 临时图片补 embedding 脚本收敛成 scripts/maintenance/embed_tenant_image_urls.py - Redis 监控脚本并入 redis/，现在是 scripts/redis/monitor_eviction.py 同时我把真实调用链都改到了新位置： - scripts/start_frontend.sh - scripts/start_cnclip_service.sh - scripts/service_ctl.sh - scripts/setup_translator_venv.sh - scripts/README.md 文档里涉及这些脚本的路径也同步修了，主要是 docs/QUICKSTART.md 和 translation/README.md。 -
问题背景： - 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: 通过
02 Apr, 2026
1 commit
19 Mar, 2026
1 commit
-
中采用了最优T4配置：ct2_inter_threads=2、ct2_max_queued_batches=16、ct2_batch_type=examples。该设置使NLLB获得了显著更优的在线式性能，同时大致保持了大批次吞吐量不变。我没有将相同配置应用于两个Marian模型，因为聚焦式报告显示了复杂的权衡：opus-mt-zh-en 在保守默认配置下更为均衡，而 opus-mt-en-zh 虽然获得了吞吐量提升，但在 c=8 时尾延迟波动较大。 我还将部署/配置经验记录在 /data/saas-search/translation/README.md 中，并在 /data/saas-search/docs/TODO.txt 中标记了优化结果。关键实践要点现已记录如下：使用CT2 + float16，保持单worker，将NLLB的 inter_threads 设为2、max_queued_batches 设为16，在T4上避免使用 inter_threads=4（因为这会损害高批次吞吐量），除非区分在线/离线配置，否则保持Marian模型的默认配置保守。
18 Mar, 2026
3 commits
-
Implemented CTranslate2 for the three local translation models and switched the existing local_nllb / local_marian factories over to it. The new runtime lives in local_ctranslate2.py, including HF->CT2 auto-conversion, float16 compute type mapping, Marian direction handling, and NLLB target-prefix decoding. The service wiring is in service.py (line 113), and the three model configs now point at explicit ctranslate2-float16 dirs in config.yaml (line 133). I also updated the setup path so this is usable end-to-end: ctranslate2>=4.7.0 was added to requirements_translator_service.txt and requirements.txt, the download script now supports pre-conversion in download_translation_models.py (line 27), and the docs/config examples were refreshed in translation/README.md. I installed ctranslate2 into .venv-translator, pre-converted all three models, and the CT2 artifacts are now already on disk: models/translation/facebook/nllb-200-distilled-600M/ctranslate2-float16 models/translation/Helsinki-NLP/opus-mt-zh-en/ctranslate2-float16 models/translation/Helsinki-NLP/opus-mt-en-zh/ctranslate2-float16 Verification was solid. python3 -m compileall passed, direct TranslationService smoke tests ran successfully in .venv-translator, and the focused NLLB benchmark on the local GPU showed a clear win: batch_size=16: HF 0.347s/batch, 46.1 items/s vs CT2 0.130s/batch, 123.0 items/s batch_size=1: HF 0.396s/request vs CT2 0.126s/request One caveat: translation quality on some very short phrases, especially opus-mt-en-zh, still looks a bit rough in smoke tests, so I’d run your real quality set before fully cutting over. If you want, I can take the next step and update the benchmark script/report so you have a fresh full CT2 performance report for all three models.
-
batch×并发矩阵”彻底分开展示。 改动在这几处： scripts/benchmark_translation_local_models.py：新增 --suite extended，支持 batch_size=1,4,8,16,32,64、concurrency=1,2,4,8,16,64、以及 batch_size * concurrency <= 128 的组合矩阵；并且单场景模式现在只加载目标模型，load_seconds 更干净，也支持 --disable-cache。 translation/README.md：把性能章节拆成了 batch_sweep、concurrency_sweep、batch x concurrency matrix 三块，补了这次复测的参数、复现命令和摘要表。 perf_reports/20260318/translation_local_models/README.md：新增本轮补测摘要。 完整结果在 translation_local_models_extended_221846.md 和 translation_local_models_extended_221846.json。 这次补测的核心结论很明确： 在线单条请求应该看 concurrency_sweep，也就是固定 batch_size=1 的表。 离线批量吞吐应该看 batch_sweep，4 个方向的最高 raw throughput 都出现在 batch_size=64，但更均衡的默认值仍更像 batch_size=16。 当前本地 seq2seq backend 有单模型锁，提升客户端并发几乎不涨吞吐，主要是把排队时间变成更高的 p95；所以并发更像“延迟预算”问题，不是“扩容吞吐”手段。 本轮在线单条里最快的是 opus-mt-zh-en；最慢、且并发放大最明显的是 nllb-200-distilled-600m en->zh。
17 Mar, 2026
4 commits
-
多个独立翻译能力”重构。现在业务侧不再把翻译当 provider 选型，QueryParser 和 indexer 统一通过 6006 的 translator service client 调用；真正的能力选择、启用开关、model + scene 路由，都收口到服务端和新的 translation/ 目录里了。 这次的核心改动在 config/services_config.py、providers/translation.py、api/translator_app.py、config/config.yaml 和新的 translation/service.py。配置从旧的 services.translation.provider/providers 改成了 service_url + default_model + default_scene + capabilities，每个能力可独立 enabled；服务端新增了统一的 backend 管理与懒加载，真实实现集中到 translation/backends/qwen_mt.py、translation/backends/llm.py、translation/backends/deepl.py，旧的 query/qwen_mt_translate.py、query/llm_translate.py、query/deepl_provider.py 只保留兼容导出。接口上，/translate 现在标准支持 scene，context 作为兼容别名继续可用，健康检查会返回默认模型、默认场景和已启用能力。
12 Mar, 2026
2 commits
11 Mar, 2026
3 commits
-
去掉 START_* 控制变量逻辑，默认只启动核心服务 backend/indexer/frontend。 可选服务改为显式命令：./scripts/service_ctl.sh start embedding translator reranker tei cnclip。 统一 translator 端口读取为 TRANSLATION_PORT（移除 TRANSLATOR_PORT 兼容）。 保留未知服务强校验。 关键文件：service_ctl.sh “重名/歧义”修复 frontend 端口命名统一：FRONTEND_PORT 为主，PORT 仅后备。 start_frontend.sh 显式导出 PORT="${FRONTEND_PORT}"，避免配置了 FRONTEND_PORT 但服务仍跑 6003 的问题。 文件：start_frontend.sh、frontend_server.py、env_config.py 日志/PID 命名治理继续收口 统一规则继续落地为 logs/<service>.log、logs/<service>.pid。 cnclip 保持 logs/cnclip.log + logs/cnclip.pid。 文件：service_ctl.sh、start_cnclip_service.sh、stop_cnclip_service.sh backend/indexer 启动风格统一补齐相关项 frontend/translator 也对齐到 set -euo pipefail，并用 exec 直启主进程。 文件：start_frontend.sh、start_translator.sh、start_backend.sh、start_indexer.sh legacy 入口清理 删除：start_servers.py、stop_reranker.sh、stop_translator.sh。 reranker 停止逻辑并入 service_ctl（含 VLLM::EngineCore 清理）。 benchmark 脚本改为统一入口：service_ctl.sh stop reranker。 文件：benchmark_reranker_1000docs.sh
10 Mar, 2026
1 commit
-
1. 新增 `scripts/init_env.sh` - 若 `.env` 不存在，从 `.env.example` 复制生成 - 支持 `--force`：覆盖 `.env` 并备份为 `.env.bak` - 首次搭建时统一执行：`./scripts/init_env.sh` 2. 统一加载逻辑 `scripts/lib/load_env.sh` - 移除 `activate.sh` 和 `service_ctl.sh` 中的重复解析逻辑 - 使用共享的 `load_env_file`，并改为 `eval "$(printf 'export %s=%q\n' "$key" "$value")"` 安全导出 - 支持含 ``、`$`、空格等特殊字符的值（需在 `.env` 中用引号包裹） 3. 使用方式 - **activate.sh**：`source scripts/lib/load_env.sh` 后调用 `load_env_file` - **service_ctl.sh**：同上，去掉内联的 `load_env_file` 实现 - **create_tenant_index.sh**：改为使用共享 loader，不再用 `set -a; source .env` 4. 文档更新 - **README.md**：在快速开始中加入 `./scripts/init_env.sh` - **docs/QUICKSTART.md**：说明 `init_env.sh` 用法，并强调含特殊字符的密码需加引号 - **.env.example**：补充注释说明引号规则 5. setup.sh - 用 `./scripts/init_env.sh` 替代原先的 `cp .env.example .env` --- **推荐流程**： ```bash ./scripts/create_venv.sh ./scripts/init_env.sh 从 .env.example 生成本地 .env source activate.sh ./run.sh ``` **密码写法**：若密码包含 ``、`$`、`&`、空格等，需加引号，例如： ```env DB_PASSWORD="qY8tgodLoA&KTyQ" ES_PASSWORD="4hOaLaf41y2VuI8y" ```
09 Mar, 2026
1 commit
-
config/config.yaml: - qwen3_vllm: enable_prefix_caching true（启用前缀缓存） - qwen3_vllm: enforce_eager false（允许 CUDA graph 加速） reranker/backends/qwen3_vllm.py: - TokensPrompt 导入改为 vllm.inputs.data（官方路径，兼容性更好） - 缺失 token 时使用 logprob=-10，与官方一致（原为 1e-10） - 使用批量 apply_chat_template 替代逐条调用，提升效率 - logprobs 访问改为官方模式：token not in last 时 -10，否则 last[token].logprob 其他: docs、embeddings、README 等文档更新 Made-with: Cursor
08 Mar, 2026
3 commits
07 Mar, 2026
2 commits
06 Mar, 2026
2 commits
02 Mar, 2026
1 commit
-
- 新增 /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
27 Jan, 2026
1 commit
-
- config: 新增 SUPPORTED_INDEX_LANGUAGES（38 种语言）、DEFAULT_INDEX_LANGUAGES、 normalize_index_languages、resolve_index_languages；get_tenant_config 统一注入 index_languages - config.yaml: 租户配置改用 index_languages，默认 [en,zh]，保留 translate_to_* 兼容解析 - query/translator: translate_for_indexing 改为接收 index_languages，返回多语言 Dict - query/query_parser: 翻译目标从 index_languages 解析，need_wait_translation 按 index_langs 判断 - search/searcher: enable_translation 改为基于 index_languages 是否非空 - indexer: document_transformer 按 index_languages 填多语言字段；indexing_utils 仅多语言时初始化翻译器 - tests: 租户配置与索引测试改为断言 index_languages - README: 更新 TODO 说明已支持 index_languages
06 Jan, 2026
2 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/ 里所有旧字段名引用已批量替换为新结构。
04 Jan, 2026
1 commit
31 Dec, 2025
1 commit
22 Dec, 2025
2 commits
18 Dec, 2025
1 commit
17 Dec, 2025
1 commit
16 Dec, 2025
1 commit
02 Dec, 2025
1 commit
-
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 根据配置决定哪些字段实际写入数据（未配置的字段写空数组） =
29 Nov, 2025
1 commit
28 Nov, 2025
1 commit
-
脚本：scripts/csv_to_excel_multi_variant.py 主要功能： 单一款式商品（S 类型）- 30% 商品属性为 S 不填写 option1/option2/option3 包含所有商品信息（标题、描述、价格、库存等） 多款式商品（M+P 类型）- 70% M 行（商品主体）： 商品属性为 M 填写商品主体信息（标题、描述、SEO、分类等） option1="color", option2="size", option3="material" 不填写价格、库存、SKU 等子款式信息 P 行（子款式）： 商品属性为 P 商品标题与 M 行一致 option1/2/3 填写具体值（color、size、material 的笛卡尔积） 每个 SKU 有独立的价格、库存、SKU 编码等 多款式商品生成规则： Color（颜色）：从 color1 到 color30 中随机选择 2-10 个 Size（尺寸）：从 1-30 中随机选择 4-8 个 Material（材质）：从商品标题按空格分割后的最后一个字符串提取（去掉特殊字符） 笛卡尔积：生成所有组合的 P 行（例如：3 个颜色 × 5 个尺寸 × 1 个材质 = 15 个 SKU）
27 Nov, 2025
1 commit
-
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 查询结构 添加了两种分面模式的说明和示例 更新了“分面字段”说明，明确支持指定规格名称的分面