ai-saas / saas-search

Commit e874eb508691b8515790db5a739a3c9cac650865

Authored by tangwang
1 parent 6823fe3e

docs

Showing 4 changed files with 38 additions and 12 deletions   Show diff stats
Inline Side-by-side
config/config.yaml
  Show/Hide comments   View file @e874eb5
... ... @@ -31,9 +31,9 @@ field_boosts:
31 31 category_path: 1.5
32 32 category_name_text: 1.5
33 33 tags: 1.0
34   - option1_values: 0.5
35   - option2_values: 0.5
36   - option3_values: 0.5
  34 + option1_values: 0.6
  35 + option2_values: 0.4
  36 + option3_values: 0.4
37 37  
38 38 # Query Configuration（查询配置）
39 39 query_config:
... ...
docs/TODO.txt
  Show/Hide comments   View file @e874eb5
... ... @@ -245,6 +245,17 @@ config/environments/<env>.yaml
245 245  
246 246  
247 247  
  248 +
  249 +
  250 +检索相关性优化：
  251 +原始搜索词和翻译的词，都需要有对应的主干分析
  252 +这个主干可以根据词性简单提取名词即可
  253 +在搜索时，原始词和主干都成对地出现，原始词和trunk_keywords一起组成一个或查询。
  254 +有一种方案是把原始词和主干词拼接起来。但是bm25要调tf系数。
  255 +
  256 +
  257 +
  258 +
248 259 nllb-200-distilled-600M性能优化
249 260 已完成（2026-03）
250 261 - CTranslate2 迁移 + float16 转换
... ...
docs/搜索API对接指南-07-微服务接口（Embedding-Reranker-Translation）.md
  Show/Hide comments   View file @e874eb5
... ... @@ -264,9 +264,9 @@ curl "http://localhost:6007/health"
264 264 - 如果是en-zh互译、期待更高的速度，可以考虑`opus-mt-zh-en` / `opus-mt-en-zh`。（质量未详细评测，一些文章说比blib-200-600m更好，但是我看了些case感觉要差不少）
265 265  
266 266 **实时翻译选型建议**:
267   -- 在线 query 翻译如果只是 `en/zh` 互译，优先使用 `opus-mt-zh-en` 或 `opus-mt-en-zh`，它们是当前已测本地模型里延迟最低的一档。
  267 +- 在线 query 翻译如果只是 `en/zh` 互译，优先使用 `opus-mt-zh-en` 或 `opus-mt-en-zh`。
268 268 - 如果涉及其他语言，或对质量要求高于本地轻量模型，优先考虑 `deepl`。
269   -- `nllb-200-distilled-600m` 不建议作为在线 query 翻译默认方案；我们在 `Tesla T4` 上测到 `batch_size=1` 时，`zh -> en` p50 约 `292.54 ms`、p95 约 `624.12 ms`，`en -> zh` p50 约 `481.61 ms`、p95 约 `1171.71 ms`。
  269 +- `nllb-200-distilled-600m` 不建议作为在线 query 翻译默认方案；我们在 `Tesla T4` 上测到 `batch_size=1` 时，根据query长短，耗时大概在70-150ms之间。
270 270  
271 271 **Batch Size / 调用方式建议**:
272 272 - 本接口支持 `text: string[]`；离线或批量索引翻译时，应尽量合并请求，让底层 backend 发挥批处理能力。
... ...
docs/相关性检索优化说明.md
  Show/Hide comments   View file @e874eb5
... ... @@ -17,9 +17,9 @@
17 17 查询链路（文本相关）：
18 18  
19 19 1. `QueryParser.parse()`
20   - 输出 `detected_language`、`query_text_by_lang`、`search_langs`、`index_languages`、`source_in_index_languages`。
  20 + 输出 `detected_language`、`query_text_by_lang`、`search_langs`、`index_languages`、`source_in_index_languages`；另输出 `contains_chinese` / `contains_english`（仅服务混写辅助召回，见 §4 末）。
21 21 2. `ESQueryBuilder._build_advanced_text_query()`
22   - 按 `search_langs` 动态拼接 `title/brief/description/vendor/category_*` 的 `.{lang}` 字段，叠加 shared 字段（`tags`、`option*_values`）。
  22 + 按 `search_langs` 动态拼接 `title/brief/description/vendor/category_*` 的 `.{lang}` 字段，叠加 shared 字段（`tags`、`option*_values`）；若命中混写辅助条件，在同一子句内并入另一语种列（§4 末）。
23 23 3. `build_query()`
24 24 统一走文本策略，不再有布尔 AST 枝路。
25 25  
... ... @@ -40,14 +40,20 @@
40 40 3. 若第 2 步翻译部分失败或全部失败：
41 41 对缺失翻译的 `index_languages` 字段，追加“原文低权重兜底”子句，避免完全丢失这些语种索引面的召回机会。
42 42  
43   -### 3.2 翻译等待策略
  43 +### 3.2 翻译与向量：并发提交与共享超时
44 44  
45   -`QueryParser.parse()` 中：
  45 +`QueryParser.parse()` 内（Stage 4–6）对**离线调用**采用线程池提交 + **一次** `concurrent.futures.wait`：
46 46  
47   -- 当源语种不在 `index_languages`：使用 `translate_multi_async(...)` 并等待 futures 收敛
48   -- 当源语种在 `index_languages`：使用 `translate_multi(..., async_mode=True)`，优先缓存命中，未命中可后台补齐
  47 +- **翻译**：对 `index_languages` 中除 `detected_language` 外的每个目标语种各提交一个 `translator.translate` 任务（多目标时并发执行）。
  48 +- **查询向量**（若开启 `enable_text_embedding` 且域为 default）：再提交一个 `text_encoder.encode` 任务。
  49 +- 上述任务进入**同一** future 集合；例如租户索引为 `[zh, en]` 且检测语种**不在**索引内时，常为 **2 路翻译 + 1 路向量，共 3 个任务并发**，共用超时。
49 50  
50   -这保证了“必须翻译才能检索”的场景不会直接空跑。
  51 +**等待预算（毫秒）**由 `detected_language` 是否属于租户 `index_languages` 决定（`query_config`）：
  52 +
  53 +- **在索引内**：`translation_embedding_wait_budget_ms_source_in_index`（默认较短，如 80ms）— 主召回已能打在源语种字段，翻译/向量稍慢可容忍。
  54 +- **不在索引内**：`translation_embedding_wait_budget_ms_source_not_in_index`（默认较长，如 200ms）— 翻译对可检索文本更关键，给足时间。
  55 +
  56 +超时未完成的任务会被丢弃并记 warning，解析继续（可能无部分译文或无数向量）。
51 57  
52 58 ## 4. 统一文本召回表达式
53 59  
... ... @@ -68,8 +74,16 @@
68 74  
69 75 最终按 `bool.should` 组合，`minimum_should_match: 1`。
70 76  
  77 +> **附 — 混写辅助召回**
  78 +> 当中英（或多脚本）混写时，为略抬召回：`QueryParser` 用 `contains_chinese`（文中有汉字）、`contains_english`（分词中有长度 ≥3 的纯英文 token）打标；`ESQueryBuilder` 在某一语言的 `multi_match` 上，按规则把**另一语种**的同类字段并入同一 `fields`（受 `index_languages` 限制），并入列的 boost 为配置值再乘 **`mixed_script_merged_field_boost_scale`（默认 0.8，`ESQueryBuilder` 构造参数）**。`fallback_original_query_*` 同样适用。字段在内部以 `(path, boost)` 列表合并后再格式化为 ES 字符串。
  79 +
71 80 ## 5. 关键配置项（文本策略）
72 81  
  82 +`query_config` 下与解析等待相关的项：
  83 +
  84 +- `translation_embedding_wait_budget_ms_source_in_index`
  85 +- `translation_embedding_wait_budget_ms_source_not_in_index`
  86 +
73 87 位于 `config/config.yaml -> query_config.text_query_strategy`：
74 88  
75 89 - `base_minimum_should_match`
... ... @@ -137,6 +151,7 @@
137 151 - `query_text_by_lang`
138 152 - `source_in_index_languages`
139 153 - `index_languages`
  154 + - `contains_chinese` / `contains_english`
140 155 - `ESQueryBuilder` 负责“表达式展开”：
141 156 - 动态字段组装
142 157 - 子句权重分配
... ...