10｜Embedding 存储与优化：向量从哪来？数据怎么存？查询怎么优化？

Henry

你好，我是 Henry，欢迎来到《OpenClaw 核心原理与实战》。
上节课我们深入剖析了混合搜索的加权融合、MMR 去重的贪心迭代以及时间衰减的指数模型——这三大算法共同回答了“搜索结果如何又准、又不重、又够新”的问题。但算法再精妙，也需要坚实的数据基础设施来支撑：向量从哪里来？数据存储在哪里？查询又如何优化？
这节课我们将聚焦 Memory 系统的数据层，从 Embedding 多提供者体系、SQLite 六张表设计，到分块策略与查询扩展，带你完整走通数据基础设施的每一个环节。
EmbeddingProvider 统一接口：屏蔽底层差异的契约在第 01 课时我们提到，Memory 系统的处理层负责将文本转化为向量。但现实中，嵌入引擎五花八门——OpenAI 用 REST API，Ollama 走本地 HTTP，node-llama-cpp 直接加载 GGUF 模型文件。如果让上层调用者（MemoryIndexManager）逐一适配，代码会迅速膨胀且难以维护。
OpenClaw 的解决方案是统一接口：所有嵌入引擎都必须实现 EmbeddingProvider 接口，上层只需调用接口方法，无需关心底层实现。
接口定义
// src/memory/embeddings.ts
export type EmbeddingProvider = {
  id: string;                                           // ★ 提供者唯一标识
  model: string;                                        // ★ 模型名称（用于缓存键）
  maxInputTokens?: number;                              // 最大输入 tokens（可选）
  embedQuery: (text: string) => Promise<number[]>;      // ★ 单条嵌入（搜索时使用）
  embedBatch: (texts: string[]) => Promise<number[][]>; // ★ 批量嵌入（索引时使用）
  embedBatchInputs?: (inputs: EmbeddingInput[]) => Promise<number[][]>;  // 多模态扩展
};

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
法语
德语
日语
韩语
俄语
西班牙语
解释
总结

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《OpenClaw 核心原理与实战》，新⼈⾸单¥59

立即购买

登录后留言

精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。

收起评论