0e66a315
 tangwang
docs
|
1
2
|
|
|
af827ce9
tangwang
rerank
|
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
翻译的health很慢
translator的设计 ：
QueryParser 里面 并不是调用的6006，目前是把6006做了一个provider，然后translate的总体配置又有6006的baseurl，很混乱！！！
config.yaml 里面的 翻译的配置 不是“6006 专用配置”，而是搜索服务的
6006本来之前是做一个provider。
结果后面改造成了综合体，但是还没改完，改到一半发现之前的实现跟我的设计或者想法有偏差。
需要继续改完！！！！！！！！
- `config.yaml` **不是“6006 专用配置”**，而是整个系统的 **统一 services 配置**，由 `config/services_config.py` 读取，**搜索 API 进程和翻译服务进程都会用到它**。
- 关键决定行为的是这一行：
```yaml
translation:
provider: "llm"
```
在当前配置下：
- 搜索 API 进程里，`QueryParser` 初始化翻译器时走的是：
```python
create_translation_provider(...) # provider == "llm"
```
进而返回的是 `LLMTranslatorProvider`（本进程内调用），**不会走 `base_url`，也不会走 6006 端口**。
- `base_url: "http://127.0.0.1:6006"` 只在 `provider: "http"` / `"service"` 时被 `HttpTranslationProvider` 使用；在 `provider: "llm"` 时，这个字段对 `QueryParser` 是完全被忽略的。
所以现在的实际情况是：
- **QueryParser 中的翻译是“本进程直连 LLM API”**，所以日志在搜索后端自己的日志文件里。
- 如果你希望「QueryParser 永远通过 6006 端口的翻译服务」，需要把 provider 改成 HTTP：
```yaml
translation:
provider: "http" # ← 改成 http 或 service
cache: ...
providers:
http:
base_url: "http://127.0.0.1:6006"
model: "llm" # 或 "qwen-mt-flush"，看你想用哪个
timeout_sec: 10.0
llm:
model: "qwen-flash" # 留给翻译服务自身内部使用
qwen-mt: ...
deepl: ...
```
查看翻译的缓存情况
向量的缓存
|
|
0e66a315
tangwang
docs
|
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
AI - 生产 - MySQL
HOST：10.200.16.14 / localhost
端口：3316
用户名：root
密码：qY8tgodLoA&KT#yQ
AI - 生产 - Redis
HOST：10.200.16.14 / localhost
端口：6479
密码：dxEkegEZ@C5SXWKv
远程登录方式：
# redis
redis-cli -h 43.166.252.75 -p 6479
# mysql 3个用户，都可以远程登录
mysql -uroot -p'qY8tgodLoA&KT#yQ'
CREATE USER 'saas'@'%' IDENTIFIED BY '6dlpco6dVGuqzt^l';
CREATE USER 'sa'@'%' IDENTIFIED BY 'C#HU!GPps7ck8tsM';
ES：
HOST：10.200.16.14 / localhost
端口：9200
访问示例：
用户名密码：saas:4hOaLaf41y2VuI8y
你安装过nvidia-container-toolkit吗
现在有一些开源的推理引擎对向量化模型和重排模型支持的比较好，我们这块也正好要单独拎出来，因此想改造下。
|
|
950a640e
tangwang
embeddings
|
119
120
121
|
已决策：embedding 先统一为 Qwen3-Embedding-0.6B（Sentence Transformers，本地 6005），后续若要独立高并发服务优先评估 TEI。
最好以 docker 方式部署，让 gpu 对 docker 可见需要 nvidia-container-toolkit，
我试了多种方法安装 nvidia-container-toolkit 都失败了
|
|
0e66a315
tangwang
docs
|
122
123
124
125
|
https://mirrors.aliyun.com/github/releases/NVIDIA/nvidia-container-toolkit/
https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/index.html
|
|
0e66a315
tangwang
docs
|
126
127
128
|
qwen3-embedding
qwen3-reranker
|
|
950a640e
tangwang
embeddings
|
129
130
|
选一个推理引擎，相比于我自己直接调 sentence-transformers，主要是多进程和负载均衡、连续批处理，比较有用
当前结论：embedding 场景优先 TEI；vLLM 更偏向生成式与 rerank 场景。
|
|
0e66a315
tangwang
docs
|
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
混用 大模型 使用：hunyuan-turbos-latest
混元 OpenAI 兼容接口相关调用示例：https://cloud.tencent.com/document/product/1729/111007
腾讯云 混元大模型 API_KEY：sk-mN2PiW2gp57B3ykxGs4QhvYxhPzXRZ2bcR5kPqadjboGYwiz
hunyuan翻译：使用模型 hunyuan-translation
https://cloud.tencent.com/document/product/1729/113395#4.-.E7.A4.BA.E4.BE.8B
谷歌翻译 基础版：https://docs.cloud.google.com/translate/docs/reference/rest/v2/translate
阿里云 百炼模型 现在使用的apikey是国内的。
各地域的 Base URL 和对应的 API Key 是绑定的。
现在使用了美国的服务器，使用了美国的地址，需要在 美国地域控制台页面（https://modelstudio.console.aliyun.com/us-east-1 ）中创建或获取API_KEY：
登录 百炼美国地域控制台:https://modelstudio.console.aliyun.com/us-east-1?spm=5176.2020520104.0.0.6b383a98WjpXff
在 API Key 管理 中创建或复制一个适用于美国地域的 Key
|