Orkas 记忆系统揭秘：SQLite 全文+向量混合检索、RRF 融合与 95MB 端侧嵌入模型工作原理-育师

Orkas 记忆系统揭秘：SQLite 全文+向量混合检索、RRF 融合与 95MB 端侧嵌入模型工作原理

【免费下载链接】OrkasOrkas is an open-source, local-first AI desktop app: a commander LLM directs specialist sub-agents, and runs your installed coding CLIs — Claude Code, Codex, OpenCode, OpenClaw, Hermes — as local sessions. Agents self-evolve via reflection and skill crystallization. BYO keys. macOS / Windows / Linux.项目地址: https://gitcode.com/gh_mirrors/or/Orkas

Orkas 是一款开源、本地优先（local-first）的 AI 桌面应用：指挥官 LLM 调度专业子智能体，并驱动 Claude Code、Codex 等本地编码 CLI 会话，智能体还能通过反思与技能结晶自我进化。这篇文章将完整拆解 Orkas 的记忆系统——它如何用 SQLite FTS5 全文索引 + 向量相似度做混合检索，用 RRF 倒数排名融合合并两路结果，并依靠一个约 95MB 的端侧 ONNX 嵌入模型让知识库索引全程不出本机。

为什么需要一个"本地记忆系统"

普通 AI 助手的对话刷新即失忆。Orkas 的思路是让每个智能体都拥有私有记忆与技能，并通过任务后的反思不断变强。这套能力在 README.md 中有一句概括：

每个 agent 拥有自己的私有 skills 和 memory，并在每次任务后通过反思改进。

实现上，Orkas 把记忆分成两层：轻量的跨会话 Markdown 记忆，和面向海量文档的混合检索索引。

第一层：跨会话 Markdown 记忆

源码位于 src/main/features/memory.ts，核心设计非常"轻量派"：

文件即记忆：MEMORY.md（跨项目共享事实）、USER.md（用户画像）、agents/<id>/MEMORY.md（每个智能体的领域笔记），条目之间用§分隔；
硬预算：memory.ts 中的常量规定共享记忆 2500 字符、用户画像 1500 字符、单智能体 2000 字符、每库最多 16 条，写满自动淘汰最旧条目，保证注入系统提示词时不撑爆上下文；
安全防护：写入前做提示注入、密钥外泄、隐形 Unicode 的模式扫描（src/main/features/memory.ts）。

会话开始时这些文件被"冻结"进系统提示词，对话中智能体再通过工具修改它们——记忆因此跨会话持久化。

第二层：SQLite 全文 + 向量混合检索

面向知识库和海量会话内容，Orkas 建的是一个本机 SQLite 混合索引：

通道	技术	擅长
全文通道	SQLiteFTS5倒排索引 + BM25 打分	精确关键词、专有名词
向量通道	sqlite-vec虚拟表 + 余弦相似度	语义相近、同义改写

关键设计都写在 src/main/features/vec_store.ts 的头部注释里：

分块：文档按 512 行一块、64 行重叠切块，兼顾上下文完整与检索粒度；
三表结构：kb_files（源文件+sha1+状态）、kb_chunks（分块文本）、kb_vec（512 维向量虚拟表）；
模型锁定：vec_store.ts#L46-L47 固定使用bge-small-zh-v1.5（512 维），换模型需要整个库重建，config.json在目录级别强制这一点；
并发模型：better-sqlite3 单写者 + 每库一把 Mutex 互斥锁，读走 SQLite 快照隔离，天然无锁读。

全局搜索的查询入口在 src/main/features/search/index.ts，BM25 打分器见 src/main/features/search/bm25.ts，还针对中日韩文本做了二字词（bigram）锚点增强——搜索"苏格拉底"时，能稳定命中真正包含该词的文档。

RRF 融合排序：0.7 向量 + 0.3 关键词

两路检索各自返回一份排序列表，但"BM25 分数 4.2"和"余弦相似度 0.81"根本不是同一个量纲，直接加权相加会互相污染。Orkas 采用教科书级的RRF（Reciprocal Rank Fusion，倒数排名融合）：

只取每条结果在两路列表中的名次rank，不取原始分；
按1/(k + rank)计算倒数排名分（k 取经验值 60，平滑头部名次）；
两路分别加权——向量 0.7、关键词 0.3——再加总排序。

这套机制的说明可以直接在 README.md#L200-L204 找到。0.7/0.3 的偏重体现了产品取向：语义相关优先，精确关键词作为强信号补充。此外 library_content_ranking.ts 还设了 0.45 / 0.65 双阈值：弱命中必须再叠加词法锚点才展示，防止向量检索"答非所问"。

最终，智能体通过memory_search与memory_read两个工具访问这套索引，检索范围覆盖存储文档和历史会话。

95MB 端侧嵌入模型：隐私如何得到保证

向量通道的核心是嵌入模型。Orkas 打包了一个 ONNX 版本的bge-small-zh-v1.5（约 95MB、512 维）：

安装时由 scripts/fetch-embedding-model.mjs 一次性拉取，落到resources/embedding-model/目录，带字节数校验和断点式超时控制；
推理走本地fastembed，建索引、算 query 向量全程在本机完成——索引一个知识库不会向任何地方发送数据；
如果你偏好云端，官方也提供 OpenAI、Gemini、Voyage、Mistral 等嵌入服务商作为可选项，默认仍是端侧。

这就是"95MB"的由来：小到随应用分发，大到足以胜任中英混合语义检索，是典型的端侧模型取舍。

小结：本地优先的完整闭环

环节	方案
轻量记忆	Markdown 文件 + 字符/条数硬预算
全文检索	SQLite FTS5 + BM25 + CJK bigram 锚点
语义检索	sqlite-vec，512 维本地向量
结果融合	RRF 倒数排名，0.7 向量 / 0.3 关键词
嵌入模型	bge-small-zh-v1.5，~95MB ONNX，端侧推理

对新手而言，最实用的三步：