feat(search-index): 远端向量推理改用 OpenAI 兼容协议，支持 Ollama / WeMM 等服务

[taosiuman]

背景

本地语义检索原先只有三个 ONNX 编码器模型（BGE Small / BGE Base / Multilingual E5 Small）：权重必须下载到本机，向量也只能在本机算。想用更大的向量模型（例如 WeMM-Embedding-2B）就走不通：它是解码器结构的多模态模型，官方只提供 GGUF，套不进现有的 ONNX + tokenizer.json 通路。

最初的实现自定义了一套 POST /embed 协议。按 review 意见改为通用的 OpenAI 兼容接口：文本仍在本机切分，向量交给远端服务计算，服务方不需要为本工具另写适配层。

改动

文件	说明
local_search/catalog.py	remote_spec(id, endpoint, model, api_key, allow_self_signed, dimension)：地址/模型名/密钥由账号配置覆盖目录预设；新增 remote_identity() 索引身份指纹
local_search/inference.py	远端推理改为 POST {base}/v1/embeddings，按 data[].index 取向量、兼容 base64、请求 encoding_format: "float"；新增 remote_api_base() / parse_remote_vectors() / decode_remote_vector()；is_lan_endpoint() 扩展为覆盖网络直连
local_search/service.py	账号配置新增 remote_model / remote_api_key / remote_allow_self_signed / remote_dimension；保存时探测维度；generation 由身份指纹决定是否重建；ensure_tokenizer() 取不到时返回 None 而不是中断建索引；新增 remote_probe()
local_search/index.py	make_chunks(..., max_chars=None)：没有 tokenizer 时按字符上界切块
local_search/downloads.py	远端模型在列表里直接标记为已就绪，不产生下载任务
resources/local_search_models.json	目录新增 remote-openai（协议 openai、维度由探测决定、max_chars: 512）
routers/local_search.py	Settings 增加远端模型名/密钥/自签名开关；新增 POST /remote/test 供前端「测试连接」
ai/providers.py	新增 PROXY_BYPASS_NETWORKS / is_proxy_bypass_host()：100.64.0.0/10（Tailscale 等）与链路本地也要直连
frontend/components/LocalSearchSettings.vue	远端卡片：服务地址、模型名、可选 API Key、允许自签名证书、快速预设、「测试连接」；底部隐私说明按模型类型切换
frontend/components/AiSettings.vue	标签从「搜索在本机运行」改为「本机或你指定的服务」

远端服务约定

• POST {base}/v1/embeddings，请求 {"model": "...", "input": ["..."], "encoding_format": "float"}，响应 {"data": [{"index": 0, "embedding": [...]}]}
• 地址填到 /v1 即可，也接受完整的 /v1/embeddings；裸主机地址会自动补 /v1
• GET {base}/v1/models：可选，只用于「测试连接」列出服务上的模型
• GET {endpoint}/tokenizer.json：可选，没有就按字符上界切块
• API Key 可选（Authorization: Bearer）；HTTPS 使用自签名证书时需要显式勾选

Ollama、LM Studio、vLLM、TEI 等都自带这个入口，所以「支持 OpenAI 兼容」即「支持 Ollama」，不需要第二套协议。

四个容易被忽略的点

1. 索引一致性。 模型 id 不变但地址/模型名变了，旧向量与新查询会落在不同向量空间，余弦距离仍然算得出数，只是结果无意义。因此用「协议 + 地址 + 模型名 + 维度」的指纹决定是否重建 generation。
2. 维度必须探测。 远端模型维度不可预知，保存时探一次、每次响应再校验，不一致直接报错。
3. 模型名服务端通常不校验。 实测 vLLM 对不存在的模型名照样返回向量，所以「测试连接」用 /v1/models 交叉核对并提示。
4. 代理绕过要覆盖 Tailscale 段。 100.64.0.0/10 不在 RFC 1918 里；实测环境里存在不可达代理时请求会直接失败。该判定与明文 HTTP 的允许范围分开，后者保持原样。

验证

在隔离进程里对接一台真实部署的 vLLM（WeMM-Embedding-2B，HTTPS 自签名证书）：

• 向量维度 2048、L2 范数 1.000000、单条 0.51s
• 3 条消息 → 5 个字符切块 → 建索引 → 2 次查询均命中（sqlite-vec 余弦距离）
• 维度不一致、自签名未勾选、模型名写错三条错误路径都给出可照做的提示
• 保存时探测到维度 2048；改模型名/地址后 generation 重建，切回原配置复用原 generation；清空地址或模型名被拦下
• 本地三个模型的行为不变；tests/test_local_search*.py 83 passed

限制

• 吞吐约 2.9 条/秒（128 条 44.3s）：10 万条消息全量建索引约 9.6 小时。暂停在批次边界生效，单个请求不可中断。
• 服务端 usage.prompt_tokens 恒为 0，不依赖它做 token 计量。
• 本次不做：Azure 的 deployments URL 与 api-key 头、dimensions 截断参数、rerank、Ollama 原生 /api/embed 协议。

[xiaoshengbao]

感谢这个 PR！把向量推理交给独立服务，能让更多用户用上较大的模型，这个方向很有价值。
有个建议想和你讨论：是否可以把远端接口做得更通用一些，默认支持 OpenAI 兼容的 /v1/embeddings？用户填写服务地址、模型名和可选 API Key 就能接入，WeMM 则保留为一个预设。
也希望第一版就能兼容 Ollama，方便用户直接使用已有服务，不用额外实现 /embed。Ollama 已提供对应接口，可以参考：Ollama OpenAI 兼容文档。如果能用 Ollama 的向量模型跑通建索引和查询流程，应该能覆盖不少实际使用场景。
tokenizer 是否也可以改成可选？默认采用保守的文本切块方式，有对应 tokenizer 时再精确计数，避免要求每个服务都额外提供 /tokenizer.json。
另外，更换服务后的索引一致性、远端请求的暂停，以及页面“不上传聊天”的提示，也建议一起调整，避免用户遇到困惑。
不一定要一次支持所有服务，可以先以 OpenAI 兼容接口和 Ollama 为目标，其他协议后续再补。你觉得这样调整是否合适？

[2977094657]

@taosiuman 按照上述要求改了就行

[taosiuman]

其实想引入WeMM这个向量模型的初衷就是看到了这个模型通吃文本、音频、视频、图片的潜质，对于处理微信的数据库信息来说再合适不过，我继续再跟进这个PR

[taosiuman]

按 review 意见改完了（3c1c2ff、6cac45d），逐条回复：

1. OpenAI 兼容 /v1/embeddings — 采纳，而且只保留这一种协议。原先自定义的 /embed 已删除；WeMM 退化为预设，前端提供 WeMM 2B / Ollama / LM Studio 三个预设按钮直接把地址和模型名填好。
2. Ollama — 不需要额外实现：Ollama 自带 /v1/embeddings，所以「支持 OpenAI 兼容」本身就覆盖了它。预设把地址填成 http://127.0.0.1:11434/v1，并用 /v1/models 列出服务上的模型供参考；原生 /api/embed 不进 v1。
3. tokenizer 可选 — 采纳。取不到 tokenizer.json 时按字符上界切块（默认 512 字符；中文 1 字 ≈ 1 token，字符数是 token 数的上界，只会切多不会溢出上下文），max_chars 放在模型目录里可调。
4. 索引一致性 / 暂停 / 文案 — 都改了：索引身份指纹（协议 + 地址 + 模型名 + 维度）变化时重建 generation；维度在保存时探测、每次响应校验；远端请求按批检查取消标志并区分超时 / 4xx / 5xx；底部隐私说明与 AI 服务页标签按「当前模型是不是远端」切换措辞。
5. 范围 — v1 只做 OpenAI 兼容；Azure deployments URL 与 api-key 头、dimensions 截断、rerank、Ollama 原生协议留待后续。

另外三点是实测才发现的，建议一并考虑：

• 响应必须按 data[].index 排序，不能假设与请求同序；
• 部分服务默认返回 base64 向量，需要显式 encoding_format: "float" 并兼容 base64；
• vLLM 对不存在的模型名照样返回向量（不报错），模型名只能靠 /v1/models 交叉核对，所以「测试连接」会明确提示。

还有一个与 review 无关但影响可用性的点：100.64.0.0/10（Tailscale 等覆盖网络）不在 RFC 1918 内，原白名单不覆盖，环境里存在不可达代理时请求会直接失败，已加入直连列表。

验证方式见 PR 描述——这次是接一台真实部署的 vLLM + WeMM-Embedding-2B（HTTPS 自签名）跑通了建索引与检索，不再只是假服务。