|
|
96c1d7baae
|
fix(memory): 千问文本塔补齐 tokenizer post_processor 与真实 ONNX 回归
验证 Go 端到端路径时发现：HuggingFace 的 tokenizer.json 带 TemplateProcessing
post_processor，规则是 `$A <|endoftext|>`——即每段输入末尾都会追加一个
`<|endoftext|>`(151643)。它正是图内 last-token 池化的锚点：
- 漏掉它：ONNX 仍能运行（不会报错），但池化取到的是模板末尾的 assistant
起始符，而非 post token，整条嵌入向量与上游不一致；
- 截断语义：HuggingFace 在 truncation=true 时先把正文截到 maxLen-1，
再保留末尾 post token（实测 600×"记忆"→ [511 正文][151643]）。
改动：
1. Tokenizer 新增 encodeModelInput(text, maxLen)：Encode 后追加 post token，
并在超长时先截到 maxLen-1；缺 <|endoftext|> 直接报错（防静默错误）。
2. Embedder.VectorizeDense 改用 encodeModelInput。
3. 测试：
- TestEncodeModelInputPostProcessor：短文本+post token；长文本按 512 截断
且尾 token 为 post token（用 600×"记忆"确保真的触发截断分支）。
- embedder_onnx_test.go（onnxruntime 标签）：用 Python onnxruntime 1.28
生成的冻结参考向量验证完整 Go 路径（模板渲染→BPE→ONNX→L2 normalize），
逐维 diff ≤ 2e-5；同时断言模型输入恰好 23 token 且末尾是 post token。
产物不在时跳过（与 tokenizer_test 相同约定）。
- 修正先前测试误用 400×"记忆"：BPE 把"记忆"合并为单 token，400 次只有
400 token 不触发截断；改用 600 次后确实走到 maxLen-1 分支。
其余（ORT 库路径、指纹纳入 .onnx.data）一并随本提交带上。
验证：go test ./internal/memory/qwen 与 -tags onnxruntime 全绿；
FP32 图与 PyTorch 在短/长/等长批次/真实 padding 批次上余弦均 ≥0.99999994。
|
2026-09-11 03:09:01 +08:00 |
|
|
|
8e88ae789f
|
feat(memory): 千问文本塔 ONNX 嵌入器（onnxruntime 标签，含 stub）
与 internal/memory/clip 同模式：`//go:build onnxruntime` 编真实实现，无标签时
走 stub，默认构建不链接 onnxruntime、行为不变。
加载契约（目录由 core.memory.multimodal_space.model_dir 指定）：
TextTower.onnx + 外部权重分片、tokenizer.json、embed_config.json。
图内已含 last-token 池化，输出即 [batch, dim]；L2 归一化在 Go 侧做。
两个刻意的设计选择：
1. **EmbedImageDense 明确报错，不返回零向量**
导出的是文本塔，视觉塔未导出。返回零向量会让「写入了但检索不到」，
把跨模态检索失效变成静默故障；明确报错则调用方（mediaref.go）log 后
跳过写向量，文本路径不受影响。
2. **Fingerprint 只哈希图文件 + 配置 + 外部权重的文件名与大小**
该目录有 6.5GB 权重分片，启动时全读一遍要几十秒、会阻塞 homeagent 启动。
换模型必然改变文件集合或大小，足以识别切换；代价是理论上存在
「大小相同但内容不同」的漏判，对本地单机部署可接受。已写入注释。
模板渲染（renderInstructionInput）放在无构建标签的 tokenizer.go，因此可被
测试覆盖：参考数据里有该模板串的用例，逐 token 对齐验证——模板差一个字符，
池化取到的「最后一个有效 token」位置就变，向量就不同，且不会报错。
验证：6 个测试全绿；go build ./...（stub）与 go build -tags onnxruntime
（真实实现）均通过。
|
2026-09-11 00:16:45 +08:00 |
|
|
|
e985151da9
|
feat(memory): 千问字节级 BPE 分词器 + 与上游逐条对齐的回归测试
为「千问嵌入模型导出 ONNX 并内嵌」的 Go 侧准备。CLIP 那套 tokenizer 不能复用：
CLIP 是「小写化 + 空白规整 + 词表 BPE」，千问是 **GPT-2 式字节级 BPE**
（先按字节映射到安全 unicode，再对映射结果做合并），中文与空白输入的切分
完全不同。
实现中撞到两个与上游对齐的坑，都由测试暴露：
1. **`\s+(?!\S)` 的语义依赖正则回溯**，不是「等价于 `\s+`」。
`\s+` 先贪婪吃完整段空白，发现后面是非空白导致 `(?!\S)` 失败，于是回退
一个字符，**正好留下末尾一个空白**给前面以 ` ?` / `[^…]?` 开头的分支合并。
这直接决定切分点：`" leading"` 会切成 `" "` + `" leading"`，
而不是 `" "` + `"leading"`。RE2 不支持 lookaround，近似改写必然对不上，
所以改成按分支顺序**显式实现**（含 `\s*[\r\n]+` 的回溯语义）。
实测：近似改写时 26 条里错 3 条，全部是空白串用例。
2. **Go 的 `\s` 只有 ASCII，且 regexp 不支持二进制属性 `\p{White_Space}`**
（只支持 script/category，直接写会报 invalid character class range）。
而上游 Rust regex 的 `\s` 正是 White_Space。改用 `unicode.IsSpace` 作为
唯一判据，避免全角空格/NBSP/行分隔符的切分点漂移。
另外特殊 token（`<|im_start|>` 等 24 个 AddedToken）必须**整体优先匹配**并
按长度降序，否则会被 BPE 拆成子 token，模型收到的输入就变了——且不会报任何错。
验证：`testdata/qwen_tokenizer_reference.json` 由 HuggingFace 真实 tokenizer
生成（26 条用例，覆盖中/英/中英混排/数字/各类空白形态/标点/emoji/特殊 token/
长文本/空串/单字符边界），Go 实现逐条精确对齐。字节↔unicode 映射另测双射性
（有碰撞会让不同字节编成同一 token，静默产生错误输入）。
|
2026-09-11 00:11:58 +08:00 |
|
