|
|
6c2039f5c9
|
feat(vector): pluggable multimodal vector space
核心暴露 MultimodalEmbedder 接口，两条路径共享同一套 L0/L2/L3
向量缓存、media.Store 坐标、QueryMemoryMediaScored 检索：
- onnx：内嵌 ONNX 模型（CLIP 等），通过 build tag 编译
- http：外部向量 API 服务（Jina v5 / OpenAI / 自建）
跨模态融合权重改为 CrossModalFusionConfig 可配置结构体，
移除所有模型特定硬编码（CLIP/Jina），版本切换只需改配置。
模型切换自动迁移：
- StaleVecDigestsAll 支持全模态（image+audio+video）
- 启动时并发重算（ONNX 4 workers / API 8 workers）
- 修复 SQL 运算符优先级导致 kind 过滤失效的 bug
实测对比（492 篇生产文档 + 3 张真实图片）：
- TF-IDF：MRR 0.457（精确匹配快，语义差）
- fastText：MRR 0.530（语义中等，延迟 8ms）
- Jina v5-omni：MRR 0.900（全面领先，延迟 40ms）
- 中文文本→图片：Jina MRR 0.833 vs CLIP 0.611
See docs/embedding-comparison.md for full benchmark.
|
2026-09-09 17:38:34 +08:00 |
|
|
|
98365f3a55
|
feat(clip): 多模态向量器（CLIP ONNX）——文本/图像 512 维共享空间 + 媒体向量写入与重算
- internal/memory/clip：CLIP ONNX 向量器（onnxruntime 构建标签控制，默认构建不链接 ONNX）
- clip.New(modelDir) 加载 text.onnx/vision.onnx（输出 text_embed/image_embed [batch,512]）
- 实现 vector.Vectorizer + vector.MultimodalEmbedder（Vectorize/EmbedImage + Dense 变体）
- 词级 BPE tokenizer：merges 合并后词末片段带 </w> 查 vocab，与官方 encode 逐 id 对齐
- EmbedImage：解码→resize 224→NCHW→normalize→vision session
- Fingerprint（text+vision 文件 sha256）供模型切换检测
- stub 版（无 onnxruntime 标签）保持默认构建行为不变
- vector/store.go：新增 MultimodalEmbedder 接口
- media.Store：新增 StaleVecDigests(currentModel)——查 vec_model 不匹配/缺失的图片
- agent core：AgentConfig.ClipEmbedder + Agent.clipEmb 接线；
describePendingMedia 描述成功后 EmbedImageDense→SetVec；
新增 reembedStaleMedia 启动补算历史无向量图片
- config：core.memory.media.clip_model_dir（未配置退化为现有 fastText/TF-IDF 行为）
- cmd/homed：读 clip_model_dir 加载 CLIP，失败仅记日志不阻塞启动
测试：TestSmokeLoadAndEncode（文本语义 cat>dog 0.914>physics 0.740）、
TestCrossModalAlignment（red-image vs red-text 0.063>blue -0.009，与 Python 一致）、
TestTokEnd（与官方 encode 逐 id 对齐）、TestStaleVecDigests，含 -race 全绿
|
2026-09-09 10:23:31 +08:00 |
|
|
|
74a24f93d7
|
feat(memory): 媒体 GC 与描述生成两条后台循环
补齐媒体记忆的最后两块：容量上限真正生效，描述文本成为持久语义记忆。
## mediaGCLoop：让容量上限不再形同虚设
CAS 的 GC 只在被显式调用时执行，Put 路径不触发它。此前配置项
core.memory.media.max_mb 注册了却没有任何调用方——一次 see_video 抽 10 帧，
帧本身在工具结果被 Prune 后就没人引用了，若无人清理会一直堆在磁盘上。
现在按 gc_interval（默认 6h）周期调 GC(gc_min_age)。两个不变量：
- 有引用的内容永不删除，即使超容量（宁可超限也不断引用）
- gc_min_age（默认 1h）保护刚 Put 还没来得及 AddRef 的项——它们
refcount 也是 0
## mediaDescribeLoop：描述才是能活过 GC 的那部分
blob 会被容量 GC 淘汰，而描述留在 media 表里，并经 mediaSummaryForEvent
写进 L0 事件、随归档进 L2 文档、经蒸馏进 L3 图库。于是「那张紫蓝红三色
带图」在原始字节早已被清掉之后仍然可被检索到。
复用既有的视觉回退链（resolveModalFallback + chatModalFallbackBatch），
不新造一套模型调用。
三个刻意的决定：
- **走后台而非入库时同步**：视觉模型一次调用生产实测 9.6s。放在对话
路径上会让每张图都给回复加十几秒，而描述的价值是几个月后还能检索到，
不是这一轮——这一轮模型本来就直接看着图。
- **逐条而非批量**：批量拿回来是一整段文字，无法可靠切分回各自的
digest（模型未必按序号输出，也可能把两张图合并成一句）。宁可多几次
往返也要保证「描述 ↔ digest」的对应关系确定。
- **默认关闭**（describe_on_ingest=false）：它消耗视觉模型配额。开启后
每 30s 最多处理 4 条，不跟对话抢额度。
失败处理分三类：
- 网络抖动/配额 → 不标记，下轮重试
- 空回复 → 视作失败（上游剥离媒体时通常回空，与 modalfallback 同理）
- 不可描述（kind=other、blob 已丢失）→ 标记 described_by=unsupported/
content-missing，退出队列
## 顺带修掉 Pending 的一个真缺陷
测试写出来才发现：Pending 原先只看 `description = ''`，于是被标记为
described_by=unsupported 但 description 仍空的项**每轮都会被重新取出来
重试**，永久占着 LIMIT 的名额，真正需要描述的新项永远轮不到。
改为同时要求 described_by 也为空。
这是「先写断言再看它是否成立」抓到的——原本我以为标记一下就够了。
## 测试
medialoop_test.go 7 例：两条循环在禁用时立即返回（nil store / 零间隔 /
describe 关闭三种形态，不留空转 goroutine）、GC 清孤儿保留有引用项、
minAge 保护新项、无可用源时不误标记、不可描述大类被标记后退出队列。
media_test.go 补 1 例专测 Pending 的排除逻辑。
全仓 go build / go vet / go test 通过，SDK 冻结 diff = 0。
|
2026-09-04 22:00:03 +08:00 |
|
