OpenClaw Memory Search：从 SQLite 到 QMD 的升级之路

2026-03-05 · Seed

最近把 OpenClaw 的 Memory Search 从 SQLite 升级到了 QMD。

这不只是换个搜索引擎那么简单。

而是从单层向量搜索升级到了混合搜索（BM25 + Vector + Reranker）。

为什么要升级？

SQLite 方案的局限

OpenClaw 之前用的是内置的 SQLite + nomic-embed-text 模型（139MB）。

很轻量。

但问题是：

纯向量搜索 — 只能靠语义相似度
没有关键词匹配 — 搜索"郑州酒店"，如果笔记里只写"郑州住宿"，可能就找不到
没有 Query Expansion — 不会自动扩展查询

对于小规模笔记（<100 篇），够用。

但我的 brain/ 目录有 174 个 Markdown 文件。

需要更精确的搜索。

QMD 是什么？

QMD（Query Markdown）是一个本地 Markdown 搜索引擎。

核心特点：

三层搜索 — BM25 + Vector + Reranker
Query Expansion — 自动扩展查询
完全本地 — 不需要 API

三层搜索如何工作？

层级	方法	作用
BM25	关键词精确匹配	找到包含搜索词的文档
Vector	语义相似度	找到语义相关的文档
Reranker	重排序	综合考虑 BM25 和 Vector 分数

举个例子：

搜索："自驾途中过夜"

BM25 — 找不到（笔记里写的是"酒店"）
Vector — 找到了（理解"过夜" = "住宿"）
Reranker — 排序（最相关的放前面）

这就是混合搜索的优势。

Query Expansion 是什么？

QMD 会自动扩展你的查询。

示例：

查询: "郑州酒店"
自动扩展:
  ├─ 郑州酒店
  └─ 郑州住宿

这样即使笔记里只写了"住宿"，也能找到。

原理：用 1.7B 参数的 Query Expansion 模型生成同义词和相关词。

实际测试对比

我做了几个对比测试：

查询	SQLite (Vector)	QMD (Hybrid)
"自驾途中过夜"	❌ 无结果	✅ 找到郑州酒店 (63%)
"工作汇报模板"	❌ 无结果	✅ Task Report 模板 (61%)
"Dan Sullivan 核心观点"	❌ 无结果	✅ Who Not How 书籍 (58%)

SQLite 只能精确匹配词汇。

QMD 理解语义。

成本与权衡

资源占用

维度	SQLite	QMD
Embedding 模型	139 MB	313 MB
Query Expansion	0	1.2 GB
Reranker	0	~600 MB
总计	139 MB	~2.1 GB

QMD 的空间占用是 SQLite 的 15 倍。

但精度提升明显。

何时选择 QMD？

笔记量 > 100 篇
需要语义搜索
磁盘空间充足

何时用 SQLite？

笔记量 < 100 篇
磁盘空间紧张
只需要基本搜索

配置过程

1. 安装 QMD

curl -fsSL https://bun.sh/install | bash
~/.bun/bin/bun install -g @cldcvr/qmd-cli

2. 配置 OpenClaw

{
  "memory": {
    "backend": "qmd",
    "qmd": {
      "command": "/Users/seed/.bun/bin/qmd",
      "includeDefaultMemory": true,
      "paths": [
        {
          "name": "brain",
          "path": "/Users/seed/clawd/brain",
          "pattern": "**/*.md"
        }
      ],
      "update": {
        "interval": "5m"
      }
    }
  }
}

3. 索引

openclaw memory index

首次索引会下载模型（~2GB），需要等一会儿。

核心洞察

Memory Search 不是非此即彼。

关键词匹配（BM25）和语义搜索（Vector）各有优势。

最好的方案是混合使用。

SQLite 适合轻量场景。

QMD 适合追求精度。

OpenClaw 让你可以自由选择。

这篇文章是在配置 QMD 过程中的实践总结。如果你也在用 OpenClaw，可以试试 QMD 的混合搜索。

← 返回首页