|
|
15e5e87fbf
|
perf(chineseclip): 分词器热路径分配优化 + 差分 oracle 验收（含一处真实语义修复）
嵌入式模型推理（ONNX）本身已是 C++，**可优化的 Go 侧是分词器与预处理**。
本轮先测出成本分布，再改，且**不假设 C 更快**。
## 实测（合成词表，无需 CHINESECLIP_MODEL_DIR）
| 场景 | ns/op | allocs |
|---|---:|---:|
| short_zh | 25681 | 60 |
| short_en | 19100 | 43 |
| mid_en | 117343 | 451 |
| mid_zh | 189260 | 1047 |
| punct_heavy | 283265 | 1388 |
| long_zh | 757746 | 4233 |
## pprof 指出的分配源（alloc_objects，mid_zh）
- splitOnPunctuation **33.5%**（每 token 都做 []rune + string(cur)）
- wordpiece **32.3%**（内层每轮候选都 string(runes[a:b])，多数未命中）
- stripAccents/NFD 33.6% cum
- basicTokenize 自身只 1.4%
## 改了三处
1. `basicTokenize`：`len([]rune(token))` → `utf8.RuneCountInString`
（原为「数个长度」就把整个 token 转 rune 切片）
2. `splitOnPunctuation`：去掉整串 []rune，改逐 rune 扫描 + 一次 flush
3. `wordpiece`：预建 rune 边界表，按字节区间取 substring，
消除「每轮候选都构造 string」
## ★★ 差分 oracle 抓到一处**真实语义缺陷**（非测量噪声）
本机无模型产物，权威的 TestTokenizerMatchesOfficialReference 会 **SKIP**
⇒ 仅靠现有测试，我的重写**没有被有效验证**。故把改动前的实现原样内联为
oracle 做差分（split/wordpiece/basicTokenize/Encode 四组 + 随机字节 2 万组
+ 随机 rune 5000 组）。
它立刻抓到：`"\xbc\xef=..."` 旧实现得 `["��" ...]`，新实现得 `["\xbc\xef" ...]`。
根因是 `[]rune(s)` 会把**非法字节归一成 U+FFFD**，而纯字节切片原样保留坏字节。
⇒ 真实差异（会进日志/去重/hash），已改为对非法序列写回 RuneError，与旧行为逐值一致。
## 诚实的收益结论：**基本没有**
改动后：mid_zh 189260（改前 186777）、long_zh 757746（改前 786416）、
mid_en 117343（改前 120422）。分配数 mid_en -40%、其余基本持平，
**时间无实质改善**（部分场景还略慢）。
复查原因（不掩盖）：重新做 CPU profile 后发现 **~25% 的样本是
runtime 锁/抢占**（unlock2 8.1% + lock2 6.8% + procyieldAsm 6.8% +
asyncPreempt 5.4%），而 utf8/unicode 相关不足 20%。
且 GOMAXPROCS 敏感：1→375365ns、4→209922ns、12→189543ns
⇒ **大量时间花在调度与 GC 而非分词算术**。
⇒ 结论：Go 侧微优化这条路**已到头**。真正的杠杆在别处：
① 提高 GOMAXPROCS/减少 GC 压力 ② 批量分词（降低每条输入的固定开销）
③ 减少送入模型的 token 量。三者都不是 C 能解决的。
改动本身保留（正确性等价、有 oracle 守护），但**不应据此宣称性能收益**。
与 C 化那几刀同一条纪律：没有数据支撑的优化不算优化。
验证：差分 oracle 6 组全过（含非法 UTF-8）；providers/... 全绿。
|
2026-09-26 11:44:49 +08:00 |
|
|
|
f5939979c2
|
docs: 更正三处无实测支撑的性能断言
用户指出现有文档里的性能数字可疑。逐个实测后发现三类问题，都不加改原文地
标注更正（历史条目保留原文，仓内已有此惯例）。
## ① 「崩溃到恢复 <1s」——从未成立
写于 v1.0.0 发版说明。但**当时的退避代码就已是 1s**（查 v1.0.0 tag 的
`procRestartBackoff = time.Second`），首次重启就要等 1s。
实测（新增临时测试测量 scheduleProcRestart 延迟）：
第 1 次崩溃 → 1s 第 2 次 → 2.001s 第 3 次 → 3.002s
顺带纠正我自己刚在站点写错的阈值：并非「崩 3 次停下」。实测第 **4** 次
才停（`procMaxRestarts=3`，判定为 `n > 3`），前 3 次都会重启。
## ② 「RPC 往返 p50 24.1µs」——量级对、数字不符
实测 `BenchmarkToolInvoke`：inline/small **30.4µs**、frame/small 51.5µs、
inline/large 767µs、frame/large 398µs。原文与实测同为几十微秒量级，
但具体值对不上，且未注明测的是哪种 payload。
## ③ 「CLIP 实测常驻 1.15GB」——采样点不对（6 处）
实测加载 chineseclip 两塔，RSS 会**自己降下来**：
加载前 0.00 GB
两塔加载后 1.59 GB ← 峰值
GC + 静置 0.89 GB ← 稳态（内核回收未用页）
1.15GB 落在两者之间，既不代表峰值也不代表稳态。线上稳态实测 0.39~0.58GB
（更长时间静置后更低）。同源问题：qwen3vl 的「常驻 9.4GB」实为**峰值**，
其视觉塔本就是按需加载（源码注释：每张图约 1.6GB，故按需）。
6 处全部改为「稳态 X（峰值 Y）」双值，消除口径歧义：README 中英、
docs/zh/multimodal-space.md、config/registry.go（2 处 + 1 处注释）、
providers/chineseclip/tokenizer.go。
## 验证
- `go build`（含 `-tags onnxruntime` 与不带）与 `go vet` 均通过
- 全仓 `grep 1.15GB` 已清零
- 测量用的临时测试文件已删除，无残留
|
2026-09-20 19:56:49 +08:00 |
|
|
|
929fb94e7a
|
feat(memory): 新增 chineseclip provider —— text+image 的小体积可商用向量空间
## 为什么
用户决定「本轮不覆盖 video，先支持 text+image」。这一刀正好解锁了此前
「小 + 可商用 + 覆盖视频」三者不可兼得的僵局：不要求视频后，唯一同时满足
**小、可商用、中文原生** 的选项是 Chinese-CLIP ViT-B/16。
实测对比（同机、真实跑出来的数字）：
| | Chinese-CLIP | jina-v5-omni-nano | Qwen3-VL-Emb-2B |
|---|---|---|---|
| 参数量 | 188M | 1.04B | 2B |
| 产物 / 常驻内存 | 754MB / **1.15GB** | ~2GB / 2.23GB | 8GB / 9.4GB |
| 维度 | 512 | 768 | 2048 |
| 许可 | **Apache-2.0** | CC BY-NC（不可商用） | Apache-2.0 |
| 视频 | 无 | 有 | 有 |
本机可用内存只有 5.3GB，Qwen 的 9.4GB 无法进程内使用；而 ORT format + mmap
那条路被证实当前不通（转换器对三段图段错误；走通还需同时升 ORT 运行时与
Go 绑定，v1.36 要求 API 29 而本机只有 28）。1.15GB 则可以直接进程内跑。
**代价已写进包注释与文档**：CLIP 是双塔对比学习，text↔image 是强项，但纯文本
语义明显弱于 MLLM 型嵌入器；文本检索仍由既有词向量/TF-IDF 路径兜底。
需要更强文本语义或视频时切回 qwen3vl。
## 内容
- `providers/chineseclip/`：按公共 SPI 实现的 provider（注册名 `chineseclip`），
含 BERT WordPiece 分词器、图像预处理、ONNX 双塔推理、无标签 stub。
- `scripts/export_chineseclip_onnx.py`：从官方权重导出规范产物 + 冻结参考，
自带逐用例 PyTorch 对比与覆盖度断言（计划集合≠执行集合即非零退出）。
- `cmd/homed/main.go`：空白导入两个 provider，由配置选其一。
- `go.mod`：`golang.org/x/text` 由间接依赖转为直接依赖（删音标需要 NFD）。
## 实现要点
- **分词器逐 token 对齐官方**。第一版探针自己拼 BertTokenizer（只给 vocab.txt、
没删音标、中文没逐字切），中文被整体切成 [UNK]，三个不同句子产出几乎相同的
向量（余弦 0.98）——差点把「模型坏了」当成结论。官方配置是 do_lower_case=true
+ 删音标生效 + 中文逐字切分；`TestTokenizerMatchesOfficialReference` 钉住
逐 token 一致。
- **图像缩放自写 bicubic**（复刻 PIL 的 precompute_coeffs + a=-0.5 核），不引
golang.org/x/image：它未进本机模块缓存，且最新版要求把整个工具链升到 Go 1.26，
为一个缩放函数动工具链不划算。
- **归一化在 provider 侧**（两个塔的图里都没归一化），检索按余弦。
- **指纹覆盖全部影响语义的产物**：两个 ONNX 图 + vocab.txt + embed_config.json，
读不到就写 MISSING（跳过等于对缺件不敏感）。
- 会话 Run 用 runMu 串行化（ORT 会话不保证并发安全），创建/销毁用 mu。
## 模态范围
只声明 `text` 与 `image`；`audio`/`video` 明确返回 `ErrUnsupportedModality`，
绝不用别的模型向量冒充（这是「音频明确 unsupported」纪律的落地）。
## 验证（实测）
导出侧：10 个用例（5 文本 + 5 图像）ONNX vs 官方 PyTorch 全部
`cos = 1.000000000`，覆盖度断言 10/10 通过。
Go 侧（`CHINESECLIP_MODEL_DIR=... go test -tags onnxruntime ./providers/chineseclip/ -v`）：
11/11 通过，其中
- 文本 5 用例 `cos = 1.000000000000`（逐位一致）
- 图像 4 纯色用例 `cos = 1.000000`（与官方预处理在 6 位小数内一致）
- 跨模态判别：红图对「红色」文本高于「蓝色」文本
- 模态拒绝 / 空输入 / 指纹稳定 / 产物缺失报错
顺带修掉测试自身的一个假通过：参考向量是**未归一化**的原始输出（模长 10~36），
原先「点积当余弦 + 单侧下界」会让 13.6 也判过，已改为真余弦 + 双侧容差。
构建矩阵：`go build/vet ./...` 与 `-tags onnxruntime` 两种都过；
`providers/... pkg/... internal/config/... internal/memory/vector/...` 回归通过
（qwen3vl 的 TestVideoModelInputMRope 需要 QWEN_ONNX_MODEL_DIR 指向含视频档的
v3 目录，缺该环境变量时用的是只有文本+图像的目录，与本改动无关）。
## 未做（明确记录）
- 发行版默认 provider 与构建标签变更：留下一提交（涉及打包与模型分发策略）。
- 模型产物（754MB）不进仓库，由导出脚本生成。
|
2026-09-11 23:58:53 +08:00 |
|
