Commit e874eb508691b8515790db5a739a3c9cac650865

Authored by tangwang
1 parent 6823fe3e

docs

config/config.yaml
@@ -31,9 +31,9 @@ field_boosts: @@ -31,9 +31,9 @@ field_boosts:
31 category_path: 1.5 31 category_path: 1.5
32 category_name_text: 1.5 32 category_name_text: 1.5
33 tags: 1.0 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 # Query Configuration(查询配置) 38 # Query Configuration(查询配置)
39 query_config: 39 query_config:
@@ -245,6 +245,17 @@ config/environments/<env>.yaml @@ -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 nllb-200-distilled-600M性能优化 259 nllb-200-distilled-600M性能优化
249 已完成(2026-03) 260 已完成(2026-03)
250 - CTranslate2 迁移 + float16 转换 261 - CTranslate2 迁移 + float16 转换
docs/搜索API对接指南-07-微服务接口(Embedding-Reranker-Translation).md
@@ -264,9 +264,9 @@ curl "http://localhost:6007/health" @@ -264,9 +264,9 @@ curl "http://localhost:6007/health"
264 - 如果是en-zh互译、期待更高的速度,可以考虑`opus-mt-zh-en` / `opus-mt-en-zh`。(质量未详细评测,一些文章说比blib-200-600m更好,但是我看了些case感觉要差不少) 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 - 如果涉及其他语言,或对质量要求高于本地轻量模型,优先考虑 `deepl`。 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 **Batch Size / 调用方式建议**: 271 **Batch Size / 调用方式建议**:
272 - 本接口支持 `text: string[]`;离线或批量索引翻译时,应尽量合并请求,让底层 backend 发挥批处理能力。 272 - 本接口支持 `text: string[]`;离线或批量索引翻译时,应尽量合并请求,让底层 backend 发挥批处理能力。
docs/相关性检索优化说明.md
@@ -17,9 +17,9 @@ @@ -17,9 +17,9 @@
17 查询链路(文本相关): 17 查询链路(文本相关):
18 18
19 1. `QueryParser.parse()` 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 2. `ESQueryBuilder._build_advanced_text_query()` 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 3. `build_query()` 23 3. `build_query()`
24 统一走文本策略,不再有布尔 AST 枝路。 24 统一走文本策略,不再有布尔 AST 枝路。
25 25
@@ -40,14 +40,20 @@ @@ -40,14 +40,20 @@
40 3. 若第 2 步翻译部分失败或全部失败: 40 3. 若第 2 步翻译部分失败或全部失败:
41 对缺失翻译的 `index_languages` 字段,追加“原文低权重兜底”子句,避免完全丢失这些语种索引面的召回机会。 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 ## 4. 统一文本召回表达式 58 ## 4. 统一文本召回表达式
53 59
@@ -68,8 +74,16 @@ @@ -68,8 +74,16 @@
68 74
69 最终按 `bool.should` 组合,`minimum_should_match: 1`。 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 ## 5. 关键配置项(文本策略) 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 位于 `config/config.yaml -> query_config.text_query_strategy`: 87 位于 `config/config.yaml -> query_config.text_query_strategy`:
74 88
75 - `base_minimum_should_match` 89 - `base_minimum_should_match`
@@ -137,6 +151,7 @@ @@ -137,6 +151,7 @@
137 - `query_text_by_lang` 151 - `query_text_by_lang`
138 - `source_in_index_languages` 152 - `source_in_index_languages`
139 - `index_languages` 153 - `index_languages`
  154 + - `contains_chinese` / `contains_english`
140 - `ESQueryBuilder` 负责“表达式展开”: 155 - `ESQueryBuilder` 负责“表达式展开”:
141 - 动态字段组装 156 - 动态字段组装
142 - 子句权重分配 157 - 子句权重分配