obsidian:~/vault$ search --hybrid obsidian

Example vault location

#

words: 2328 read_time: 41m updated: 2026-03-02 07:54
$ retriever search --hybrid obsidian

核心要点

上下文工程,而非笔记记录。 Obsidian 库对 AI 的价值不在于笔记本身,而在于使笔记可查询的检索层。一个拥有 16,000 个文件但缺乏检索能力的库只是一个只写数据库。一个拥有 200 个文件但配备混合搜索和 MCP 集成的库就是一个 AI 知识库。检索基础设施才是产品,笔记只是原材料。

混合检索优于纯关键词搜索或纯语义搜索。 BM25 能捕获精确的标识符和函数名。向量搜索能捕获不同术语间的同义词和概念匹配。Reciprocal Rank Fusion(RRF)无需分数校准即可合并两者的结果。任何单一方法都无法覆盖两种失败模式。基于 MS MARCO 段落排序的研究证实了这一规律:混合检索始终优于单独使用任一方法。1 混合检索器深度解析涵盖了 RRF 数学原理、基于真实数据的示例、失败模式分析以及交互式融合计算器。

MCP 使 AI 工具直接访问库。 Model Context Protocol(MCP)服务器将检索器作为工具暴露出来,Claude Code、Codex CLI、Cursor 及其他 AI 工具可以直接调用。智能体查询库后接收带有来源归属的排序结果,并在无需加载整个文件的情况下使用上下文。MCP 服务器是检索引擎的一个轻量封装。

本地优先意味着零 API 成本和完全隐私。 整个技术栈运行在单台机器上:SQLite 用于存储,Model2Vec 用于嵌入(embeddings),FTS5 用于关键词搜索,sqlite-vec 用于向量 KNN 搜索。无需云服务,无需 API 调用,无需网络依赖。个人笔记永远不会离开您的设备。完整重新嵌入 49,746 个分块按 OpenAI API 价格大约花费 $0.30,但真正的成本在于延迟、隐私暴露,以及一个本应离线工作的系统对网络的依赖。2

增量索引使系统在 10 秒内保持最新。 通过文件修改时间比较检测变更,仅对修改过的文件重新分块和重新嵌入。在 Apple M 系列硬件上,完整重建索引大约需要四分钟。对一天中典型编辑量的增量更新在十秒内完成。系统无需人工干预即可保持最新状态。

该架构可从 200 篇笔记扩展至 20,000+ 篇。 相同的三层设计(摄入层、检索层、集成层)适用于任意库规模。从对小型库进行纯 BM25 搜索开始。当关键词冲突成为问题时添加向量搜索。当您需要精确匹配和语义匹配时添加 RRF 融合。每一层都独立可用,也可独立移除。


如何使用本指南

本指南涵盖完整系统。您的起点取决于当前阶段:

您的情况… 从这里开始 然后探索
Obsidian + AI 新手 为什么选择 Obsidian 作为 AI 基础设施快速入门 库架构MCP 服务器架构
已有库,希望接入 AI MCP 服务器架构Claude Code 集成 嵌入模型全文搜索
正在构建检索系统 完整检索管道Reciprocal Rank Fusion 性能调优故障排除
团队或企业场景 决策框架知识图谱模式 开发者工作流方案迁移指南

标记为合约的章节包含实现细节、配置代码块和失败模式。标记为叙述的章节侧重于概念、架构决策及设计选择背后的推理。标记为方案的章节提供逐步操作流程。


为什么选择 Obsidian 作为 AI 基础设施

本指南的核心论点:Obsidian 库是个人 AI 知识库的最佳基底,因为它们本地优先、纯文本、图结构化,并且用户掌控技术栈的每一层。

Obsidian 提供了其他方案所不具备的 AI 能力

纯文本 Markdown 文件。 每条笔记都是文件系统上的一个 .md 文件。没有专有格式,无需数据库导出,无需 API 即可读取内容。任何能读取文件的工具都能读取您的库。grepripgrep、Python 的 pathlib、SQLite FTS5——它们都能直接处理源文件。当您构建检索系统时,您索引的是文件,而非 API 响应。由于源即文件系统,索引始终与源保持一致。

本地优先架构。 库存储在您的设备上。没有服务器,不依赖云同步,没有 API 速率限制,没有限制您处理自有内容方式的服务条款。您无需任何外部服务即可对笔记进行嵌入、索引、分块和搜索。这对 AI 基础设施至关重要,因为检索管道的运行速度取决于您的磁盘速度,而非 API 端点的响应速度。这对隐私同样重要:包含凭证、健康数据、财务信息和私人反思的个人笔记永远不会离开您的设备。

通过 wiki-link 实现图结构。 Obsidian 的 [[wiki-link]] 语法在笔记之间创建有向图。一条关于 OAuth 实现的笔记链接到关于令牌轮换、会话管理和 API 安全的笔记。图结构编码了人工策划的概念间关系。向量嵌入捕获语义相似性,而 wiki-link 捕获的是作者在思考主题时建立的有意关联。图是嵌入无法复制的信号。

插件生态系统。 Obsidian 拥有 1,800+ 个社区插件。Dataview 让您像查询数据库一样查询库。Templater 使用 JavaScript 逻辑从模板生成笔记。Git 集成将库同步到代码仓库。Linter 强制执行格式一致性。这些插件在不改变底层纯文本格式的情况下为库添加结构。检索系统索引的是这些插件的输出,而非插件本身。

500 万以上用户。 Obsidian 拥有庞大的活跃社区,产出模板、工作流、插件和文档。当您遇到库组织或插件配置问题时,很可能已有人记录了解决方案。社区还产出 Obsidian 周边工具:MCP 服务器、索引脚本、发布管道和 API 封装器。

纯文件系统无法提供的能力

一个 Markdown 文件目录具有纯文本优势,但缺少 Obsidian 添加的三项能力:

  1. 双向链接。 Obsidian 自动追踪反向链接。当您从笔记 A 链接到笔记 B 时,笔记 B 会显示笔记 A 引用了它。图面板可视化展示连接集群。这种双向感知是原始文件系统无法提供的元数据。

  2. 带插件渲染的实时预览。 Dataview 查询、Mermaid 图表和标注块实时渲染。写作体验比纯文本编辑器更丰富,而存储格式仍然是纯文本。您在富编辑环境中写作和组织;检索系统索引的是原始 Markdown。

  3. 社区基础设施。 插件发现、主题市场、同步服务(可选)、发布服务(可选)以及文档生态系统。您可以用独立工具复制任何单独功能,但 Obsidian 将它们打包成一个连贯的工作流。

Obsidian 不做的事(以及您需要构建的部分)

Obsidian 不包含检索基础设施。它具有基础搜索功能(全文、文件名、标签),但没有嵌入管道、向量搜索、融合排序、MCP 服务器、凭证过滤、分块策略,也没有外部 AI 工具的集成钩子。本指南涵盖您在 Obsidian 之上构建的基础设施。 库是基底。检索管道、MCP 服务器和集成钩子是基础设施。

此处描述的架构是Markdown 优先,而非 Obsidian 专属。 如果您使用 Logseq、Foam、Dendron 或纯 Markdown 文件目录,检索管道的工作方式完全相同。分块器读取 .md 文件。嵌入器处理文本字符串。索引器写入 SQLite。这些组件都不依赖 Obsidian 特有功能。Obsidian 的贡献在于提供了写作和组织环境,产出检索器所索引的 Markdown 文件。

快速开始:首个AI连接的Vault

本节将在五分钟内将一个vault连接到AI工具。您将安装Obsidian、创建一个vault、安装一个MCP服务器,并运行您的第一个查询。本快速开始使用社区MCP服务器以获得即时结果。后续章节将介绍如何构建用于生产环境的自定义检索管道。

前提条件

  • macOS、Linux或Windows
  • Node.js 18+(用于MCP服务器)
  • 已安装Claude Code、Codex CLI或Cursor

第1步:创建vault

obsidian.md下载Obsidian并创建一个新的vault。选择一个您能记住的位置——MCP服务器需要绝对路径。

# Example vault location
~/Documents/knowledge-base/

添加一些笔记,为检索器提供可供搜索的内容。即使只有10-20篇笔记也足以看到结果。每篇笔记应为一个.md文件,具有有意义的标题和至少一段内容。

第2步:安装MCP服务器

obsidian-mcp社区服务器提供即时的vault访问。安装方法:

npm install -g obsidian-mcp-server

第3步:配置您的AI工具

Claude Code — 添加到~/.claude/settings.json

{
  "mcpServers": {
    "obsidian": {
      "command": "obsidian-mcp-server",
      "args": ["--vault", "/absolute/path/to/your/vault"]
    }
  }
}

Codex CLI — 添加到.codex/config.toml

[mcp_servers.obsidian]
command = "obsidian-mcp-server"
args = ["--vault", "/absolute/path/to/your/vault"]

Cursor — 添加到.cursor/mcp.json

{
  "mcpServers": {
    "obsidian": {
      "command": "obsidian-mcp-server",
      "args": ["--vault", "/absolute/path/to/your/vault"]
    }
  }
}

第4步:运行您的第一个查询

打开您的AI工具,提出一个您的vault笔记能够回答的问题:

Search my Obsidian vault for notes about [topic you wrote about]

AI工具会调用MCP服务器,服务器搜索您的vault并返回匹配的内容。您应该能看到包含文件路径和相关摘录的结果。

您刚刚构建了什么

您通过一个标准协议将本地知识库连接到了AI工具。MCP服务器读取您的vault文件,执行基础搜索,并返回结果。这是最小可行版本。

本快速开始未提供的功能: - 混合检索(BM25 + 向量搜索 + RRF fusion) - 基于embedding的语义搜索 - 凭证过滤 - 增量索引 - 基于Hook的自动上下文注入

本指南的其余部分将逐一介绍如何构建这些功能。快速开始验证了概念。完整管道提供生产级别的检索质量。


决策框架:Obsidian与替代方案对比

并非每个使用场景都需要Obsidian。本节将说明何时Obsidian是正确的基础设施选择,何时它显得过度,以及何时其他方案更合适。

决策树

START: What is your primary content type?

├─ Structured data (tables, records, schemas)
   Use a database. SQLite, PostgreSQL, or a spreadsheet.
   Obsidian is for prose, not tabular data.

├─ Ephemeral context (current project, temporary notes)
   Use CLAUDE.md / AGENTS.md in the project repo.
   These travel with the code and reset per project.

├─ Team wiki (shared documentation, onboarding)
   Evaluate Notion, Confluence, or a shared git repo.
   Obsidian vaults are personal-first. Team sync is possible
    but not native.

└─ Growing personal knowledge corpus
   
   ├─ < 50 notes
      A folder of markdown files + grep is sufficient.
      Obsidian adds value mainly through the link graph,
       which needs density to be useful.
   
   ├─ 50 - 500 notes
      Obsidian adds value. Wiki-links create a navigable graph.
      BM25-only search (FTS5) is sufficient at this scale.
      Skip vector search and RRF until keyword collisions appear.
   
   ├─ 500 - 5,000 notes
      Full hybrid retrieval becomes valuable. Keyword collisions
       increase. Semantic search catches queries that BM25 misses.
      Add vector search + RRF fusion at this scale.
   
   └─ 5,000+ notes
       Full pipeline is essential. BM25-only returns too much noise.
       Credential filtering becomes critical (more notes = more
        accidentally pasted secrets).
       Incremental indexing matters (full reindex takes minutes).
       MCP integration pays dividends on every AI interaction.

对比矩阵

评估标准 Obsidian Notion Apple Notes 纯文件系统 CLAUDE.md
本地优先 否(云端) 部分(iCloud)
纯文本 是(markdown) 否(块结构) 否(专有格式)
图谱结构 是(wiki-links) 部分(提及)
AI可索引 直接文件访问 需要API 需要导出 直接文件访问 已在上下文中
插件生态 1,800+插件 集成方案 不适用 不适用
离线可用 完全支持 仅缓存只读 部分 完全支持 完全支持
支持10K+笔记 是(需API) 性能下降 否(单文件)
费用 免费(核心功能) $10/月起 免费 免费 免费

何时Obsidian显得过度

  • 单项目上下文。 如果AI只需要当前代码库的上下文,请将其放在CLAUDE.mdAGENTS.md或项目级文档中。这些文件随代码库一起分发,并会被自动加载。
  • 结构化数据。 如果内容是表格、记录或模式定义,请使用数据库。Obsidian笔记以散文为主。Dataview可以查询frontmatter字段,但真正的数据库能更好地处理结构化查询。
  • 临时性研究。 如果笔记在项目结束后将被丢弃,使用包含markdown文件的临时目录更为简单。不要为临时性内容构建检索基础设施。

何时Obsidian是正确的选择

  • 数月或数年持续积累知识。 价值随着语料库的增长而复合增长。一个200篇笔记的vault被每日查询六个月,比一个5,000篇笔记的vault被查询一次提供更多价值。
  • 单一语料库涵盖多个领域。 一个包含编程、架构、安全、设计和个人项目笔记的vault受益于跨领域检索,而这是项目级CLAUDE.md无法提供的。
  • 隐私敏感内容。 本地优先意味着检索管道永远不会将内容发送到外部服务。vault包含您放入的任何内容,包括您不会上传到云服务的内容。

心智模型:三层架构

该系统包含三个独立运作但组合后产生复合效果的层。每一层关注不同的问题,也有不同的故障模式。

┌─────────────────────────────────────────────────────┐
                 INTEGRATION LAYER                     
  MCP servers, hooks, skills, context injection        
  Concern: delivering context to AI tools              
  Failure: wrong context, too much context, stale      
└──────────────────────┬──────────────────────────────┘
                        query + ranked results
┌──────────────────────┴──────────────────────────────┐
                  RETRIEVAL LAYER                      
  BM25, vector KNN, RRF fusion, token budget           
  Concern: finding the right content for any query     
  Failure: wrong ranking, missed results, slow queries 
└──────────────────────┬──────────────────────────────┘
                        chunked, embedded, indexed
┌──────────────────────┴──────────────────────────────┐
                   INTAKE LAYER                        
  Note creation, signal triage, vault organization     
  Concern: what enters the vault and how it's stored   │
  Failure: noise, duplicates, missing structure        
└─────────────────────────────────────────────────────┘

摄入层(Intake)决定什么内容进入vault。如果不加筛选,vault会积累噪音:推文截图、未加注释的复制粘贴文章、缺乏上下文的半成品想法。摄入层负责在内容进入时进行质量控制。评分管道、标签规范或人工审核流程——任何能确保vault包含值得检索的内容的机制。

检索层(Retrieval)使vault可查询。这是引擎:将笔记分块为搜索单元,将分块嵌入向量空间,建立关键词和语义搜索索引,通过RRF融合结果。检索层将一个文件目录转化为可查询的知识库。没有这一层,vault只能通过手动浏览和基础搜索进行导航,AI工具无法以编程方式访问。

集成层(Integration)将检索层连接到AI工具。MCP服务器将检索功能暴露为可调用的工具。Hook自动注入上下文。Skill将新知识捕获回vault。集成层是知识库与使用它的AI代理之间的接口。

这些层在设计上是解耦的。摄入评分管道不了解embedding。检索器不了解信号路由规则。MCP服务器不了解笔记是如何创建的。这种解耦意味着您可以独立改进任何一层。更换embedding模型无需改变摄入管道。添加新的MCP功能无需修改检索器。更改信号评分启发式规则无需触及索引。


面向AI消费的Vault架构

为AI检索优化的vault与为个人浏览优化的vault遵循不同的规范。本节涵盖文件夹结构、笔记模式、frontmatter规范,以及能够提升检索质量的特定模式。

文件夹结构

使用数字前缀为顶层文件夹创建可预测的组织层级。数字并不表示优先级——它们将相关领域归类,使结构便于浏览。

vault/
├── 00-inbox/              # Unsorted captures, pending triage
├── 01-projects/           # Active project notes
├── 02-areas/              # Ongoing areas of responsibility
├── 03-resources/          # Reference material by topic
   ├── programming/
   ├── security/
   ├── ai-engineering/
   ├── design/
   └── devops/
├── 04-archive/            # Completed projects, old references
├── 05-signals/            # Scored signal intake
   ├── ai-tooling/
   ├── security/
   ├── systems/
   └── ...12 domain folders
├── 06-daily/              # Daily notes (if used)
├── 07-templates/          # Note templates (excluded from index)
├── 08-attachments/        # Images, PDFs (excluded from index)
├── .obsidian/             # Obsidian config (excluded from index)
└── .indexignore            # Paths to exclude from retrieval index

应建立索引的文件夹:所有包含Markdown文本内容的文件夹——项目、领域、资源、信号、每日笔记。

应排除在索引之外的文件夹:模板(包含占位符变量而非实际内容)、附件(二进制文件)、Obsidian配置,以及任何包含您不希望出现在检索索引中的敏感内容的文件夹。

.indexignore文件

在vault根目录创建一个.indexignore文件,以明确排除检索索引中的路径。其语法与.gitignore相同:

# Obsidian internal
.obsidian/

# Templates contain placeholders, not content
07-templates/

# Binary attachments
08-attachments/

# Personal health/medical notes
02-areas/health/

# Financial records
02-areas/finance/personal/

# Career documents (resumes, salary data)
02-areas/career/private/

索引器在扫描前读取此文件,并完全跳过匹配的路径。被排除路径中的文件永远不会被分块、不会被嵌入,也不会出现在搜索结果中。

笔记模式

每条笔记都应包含YAML frontmatter。检索器使用frontmatter字段进行过滤和上下文增强:

---
title: "OAuth Token Rotation Patterns"
type: note           # note | signal | project | moc | daily
domain: security     # primary domain for routing
tags:
  - authentication
  - oauth
  - token-management
created: 2026-01-15
updated: 2026-02-28
source: ""           # URL if captured from external source
status: active       # active | archived | draft
---

检索所需的必填字段:

  • title — 用于搜索结果显示以及BM25的标题上下文
  • type — 支持按类型过滤的查询(”只显示MOC”或”只显示信号”)
  • tags — 以0.3的权重索引到FTS5标题上下文中,即使正文使用不同的术语也能提供关键词匹配

可选但有价值的字段:

  • domain — 支持按领域限定的查询(”仅搜索安全相关笔记”)
  • source — 外部采集内容的来源归属;检索器可在结果中包含来源URL
  • status — 允许在活跃搜索中排除已归档或草稿状态的笔记

分块规范

检索器在H2(##)标题边界处进行分块。这意味着您的笔记结构直接影响检索粒度:

有利于检索的结构:

## Token Rotation Strategy

The rotation interval depends on the threat model...

## Implementation with refresh_token

The OAuth 2.0 refresh token flow requires...

## Error Handling: Expired Tokens

When a token expires mid-request...

三个H2章节产生三个可独立搜索的块。每个块都有足够的上下文,使embedding能够捕获其语义。关于”过期令牌处理”的查询会精确匹配到第三个块。

不利于检索的结构:

# OAuth Notes

Token rotation depends on threat model. The OAuth 2.0 refresh
token flow requires storing the refresh token securely. When a
token expires mid-request, the client should retry after refresh.
The rotation interval is typically 15-30 minutes for access tokens
and 7-30 days for refresh tokens...

一个没有H2标题的长段落只会产生一个大块。embedding会在该段落的所有主题上取平均值。对任何子主题的查询都会同等程度地匹配整条笔记。

经验法则:如果一个章节涵盖了多个概念,请将其拆分为H2子章节。分块器会处理剩余的工作。

笔记中不应包含的内容

会降低检索质量的内容:

  • 未加注释的整篇文章原文复制粘贴。检索器会索引原始文章的关键词,用非您本人撰写的内容稀释vault的质量。请改为添加摘要、提取要点,或链接到来源URL。
  • 没有文字描述的截图。检索器索引的是Markdown文本。没有alt文本或周围描述的图片对BM25和向量搜索都是不可见的。
  • 凭据字符串。API密钥、令牌、密码、连接字符串。即使有凭据过滤机制,最安全的做法是永远不要将密钥粘贴到笔记中。请改为通过名称引用(”在~/.env中的Cloudflare API令牌”)。
  • 未经整理的自动生成内容。如果某个工具生成了笔记(会议转录、Readwise高亮、RSS导入),请在其进入永久vault之前进行审阅和注释。未经整理的自动导入只增加数量而不增加可检索的价值。

AI工作流的插件生态系统

能够提升vault在AI检索方面质量的Obsidian插件分为三类:结构性插件(强制一致性)、查询性插件(暴露元数据)和同步性插件(保持vault更新)。

核心插件

Dataview。使用frontmatter字段像数据库一样查询您的vault。创建动态索引:”所有标记为security且在过去30天内更新的笔记”或”所有状态为active的项目笔记”。Dataview不会直接帮助检索,但它能帮助您识别vault覆盖范围中的空白,并找到需要更新的笔记。

TABLE type, domain, updated
FROM "03-resources"
WHERE status = "active"
SORT updated DESC
LIMIT 20

Templater。使用带有动态字段的模板创建笔记。通过使用预填createdtypedomain字段的模板,确保每条新笔记都以正确的frontmatter开头。一致的frontmatter能提升检索过滤效果。

<%* /* New Resource Note Template */ %>
---
title: "<% tp.file.cursor() %>"
type: note
domain: <% tp.system.suggester(["programming", "security", "ai-engineering", "design", "devops"], ["programming", "security", "ai-engineering", "design", "devops"]) %>
tags: []
created: <% tp.date.now("YYYY-MM-DD") %>
updated: <% tp.date.now("YYYY-MM-DD") %>
source: ""
status: active
---

## Key Points

## Details

## 参考资料

Linter。在整个仓库中强制执行格式化规则。一致的标题层级(H1用于标题,H2用于章节,H3用于子章节)可确保分块器产生可预测的结果。对检索有影响的Linter规则:

  • 标题递增:强制使用连续的标题层级(不允许从H1直接跳到H3)
  • YAML title:与文件名保持一致
  • 尾部空格:移除(避免FTS5分词产生的异常)
  • 连续空行:限制为1行(生成更干净的分块)

Git集成。为您的仓库提供版本控制。跟踪历史变更、在多台设备间同步,并从误删中恢复。Git还提供mtime数据,索引器利用该数据进行增量变更检测。

有助于索引的插件

Smart Connections。一款Obsidian插件,在Obsidian内部提供AI驱动的语义搜索功能。它会创建自己的embedding索引。虽然本指南中的检索系统是Obsidian外部的(作为Python管道运行),但Smart Connections在写作过程中探索语义关联时非常有用。两个系统索引相同的内容,但服务于不同的用例:Smart Connections用于编辑器内的发现,外部检索器用于AI工具集成。

Metadata Menu。提供结构化的frontmatter编辑功能,支持字段值自动补全。减少typedomaintags字段中的拼写错误。一致的元数据可提高检索过滤的准确性。

不利于索引的插件

Excalidraw。将绘图以JSON形式嵌入markdown文件中存储。该JSON在语法上是有效的markdown,但在分块和生成embedding时会产生无意义的内容。请通过.indexignore或按文件扩展名过滤,将Excalidraw文件排除在索引之外。

Kanban。将看板状态存储为特殊格式的markdown。该格式是为Kanban渲染设计的,而非用于文本检索。分块器会产生卡片标题和元数据的碎片,这些碎片无法生成有效的embedding。请将Kanban看板排除在索引之外。

Calendar。创建内容极少的每日笔记(通常只有一个日期标题)。空白或接近空白的笔记会产生低质量的分块。如果您使用每日笔记,请在其中写入实质性内容,或将每日笔记文件夹排除在索引之外。

重要的插件配置

文件恢复 → 启用。防止笔记被意外删除。虽然与检索没有直接关系,但对于您所依赖的知识库来说至关重要。

严格换行 → 禁用。标准markdown换行方式(双换行符表示段落)比Obsidian的严格模式(单换行符生成<br>)产生更干净的分块。

新文件默认存放位置 → 指定文件夹。将新文件路由到00-inbox/,使未分类的笔记不会污染领域文件夹。收件箱是一个暂存区;文件在整理后移入相应的领域文件夹。

Wiki-link格式 → 尽可能使用最短路径。较短的链接目标在检索器索引链接结构时更容易解析。


Embedding 模型:选择与配置

Embedding 模型将文本块转换为数值向量,用于语义搜索。模型的选择决定了检索质量、索引大小、embedding 速度和运行时依赖。本节解释为什么 Model2Vec 的 potion-base-8M 是默认选择,以及何时应选择替代方案。

为什么选择 Model2Vec potion-base-8M

模型: minishlab/potion-base-8M 参数量: 760万 维度: 256 大小: 约30 MB 依赖: model2vec(仅需 numpy,无需 PyTorch) 推理: 仅 CPU,静态词嵌入(无注意力层)

Model2Vec 将句子转换器的知识蒸馏为静态 token embeddings。与 BERT、MiniLM 及其他 transformer 模型通过注意力层处理输入不同,Model2Vec 通过预计算的 token embeddings 加权平均来生成向量。3 实际效果是:embedding 速度比基于 transformer 的模型快50至500倍,因为不存在顺序计算。

在 MTEB 基准测试套件上,potion-base-8M 达到了 all-MiniLM-L6-v2 性能的89%(平均分50.03 vs 56.09)。4 11%的质量差距是速度和简洁性优势的代价。对于较短的 markdown 文本块(典型知识库中平均200至400词),质量差异不如长文档那样明显,因为两种模型在短小、聚焦的文本上会趋向于相似的表示。

配置

# embedder.py
DEFAULT_MODEL = "minishlab/potion-base-8M"
EMBEDDING_DIM = 256

class Model2VecEmbedder:
    def __init__(self, model_name=DEFAULT_MODEL):
        self._model_name = model_name
        self._model = None

    def _ensure_model(self):
        if self._model is not None:
            return
        _activate_venv()  # Add isolated venv to sys.path
        from model2vec import StaticModel
        self._model = StaticModel.from_pretrained(self._model_name)

    def embed_batch(self, texts):
        self._ensure_model()
        vecs = self._model.encode(texts)
        return [v.tolist() for v in vecs]

延迟加载。 模型在首次使用时加载,而非在导入时加载。当检索器运行在仅 BM25 回退模式下时(例如未安装 embedding 虚拟环境),导入 embedder 模块的开销为零。

隔离虚拟环境。 模型运行在专用虚拟环境中(例如 ~/.claude/venvs/memory/),以避免与工具链其他部分产生依赖冲突。_activate_venv() 函数在运行时将虚拟环境的 site-packages 添加到 sys.path

# Create isolated venv
python3 -m venv ~/.claude/venvs/memory
~/.claude/venvs/memory/bin/pip install model2vec

批量处理。 embedder 以64为一批处理文本,以分摊 Model2Vec 的开销。索引器将文本块提供给 embed_batch() 而非逐个 embedding。

何时选择替代方案

模型 维度 大小 速度 质量(MTEB) 适用场景
potion-base-8M 256 30 MB 500x 50.03 默认:本地、快速、无需 GPU
potion-base-32M 256 120 MB 400x 52.46 更高质量,仍为静态模型
potion-retrieval-32M 256 120 MB 400x 36.35(检索) 针对检索优化的静态模型
all-MiniLM-L6-v2 384 80 MB 1x 56.09 更高质量,仍为本地部署
nomic-embed-text-v1.5 768 270 MB 0.5x 62.28 最佳本地质量
text-embedding-3-small 1536 API N/A 62.30 基于 API,最高质量

选择 potion-base-32M 适用于希望获得比 potion-base-8M 更高质量但不离开静态 embedding 系列的场景。该模型于2025年1月发布,使用从 baai/bge-base-en-v1.5 蒸馏的更大词汇表,MTEB 平均分达到52.46(比 potion-base-8M 提升5%),同时保持相同的256维输出和仅 numpy 依赖。18 模型文件增大4倍会增加内存使用,但 embedding 速度仍比 transformer 模型快数个数量级。

选择 potion-retrieval-32M 适用于主要用途为检索的场景(知识库搜索正是如此)。此变体基于 potion-base-32M 针对检索任务进行了微调,在 MTEB 检索基准测试中得分36.35,而基础模型为33.52。18 总体 MTEB 平均分降至49.73,因为微调以通用性能换取了检索专项增益。

选择 all-MiniLM-L6-v2 适用于检索质量比速度更重要且已安装 PyTorch 的场景。384维向量与256维相比,SQLite 数据库大小增加约50%。在 M 系列硬件上,对15,000个文件进行完整重新索引的 embedding 速度从不到1分钟降至约10分钟。

选择 nomic-embed-text-v1.5 适用于需要最佳本地检索质量且接受较慢索引速度的场景。768维向量使数据库大小大约增加两倍。需要 PyTorch 以及现代 CPU 或 GPU。

选择 text-embedding-3-small 适用于网络延迟和隐私为可接受代价的场景。API 能生成最高质量的 embeddings,但引入了云端依赖、按 token 计费(每百万 token $0.02),并将您的内容发送至 OpenAI 的服务器。

在其他所有情况下保持使用 potion-base-8M。 速度优势对于迭代索引至关重要(开发期间重新索引),仅 numpy 依赖避免了 PyTorch 安装的复杂性,256维向量使数据库保持紧凑。

量化与降维

Model2Vec v0.5.0+ 支持以降低精度和维度加载模型。18 这对于在受限硬件上部署或在不更换模型的情况下减小数据库大小非常有用:

from model2vec import StaticModel

# Load with int8 quantization (25% of original size)
model = StaticModel.from_pretrained("minishlab/potion-base-8M", quantize=True)

# Load with reduced dimensions (e.g., 128 instead of 256)
model = StaticModel.from_pretrained("minishlab/potion-base-8M", dimensionality=128)

量化模型以极小的内存占用保持了近乎相同的检索质量。降维遵循 Matryoshka 风格的截断方式——前 N 个维度承载最多信息。将256维降至128维可将向量存储减半,而对短文本检索的质量损失极小。

模型哈希追踪

索引器存储由模型名称和词汇表大小生成的哈希值。如果您更换了 embedding 模型,索引器会在下次增量运行时检测到不匹配,并自动触发完整的重新索引。

def _compute_model_hash(self):
    """Hash model name + vocab size for compatibility tracking."""
    key = f"{self._model_name}:{self._model.vocab_size}"
    return hashlib.sha256(key.encode()).hexdigest()[:16]

这可以防止不同模型的向量混入同一数据库,否则会产生无意义的 cosine similarity 分数。

故障模式

模型下载失败。 首次运行时会从 Hugging Face 下载模型。如果下载失败(网络问题、企业防火墙),检索器将回退到仅 BM25 模式。模型在首次下载后会缓存在本地。

维度不匹配。 如果您在未清除数据库的情况下更换模型,存储的向量维度将与新 embeddings 不同。索引器通过模型哈希检测此情况并触发完整的重新索引。如果哈希检查失败(自定义模型未正确设置哈希),sqlite-vec 将在维度不匹配的 KNN 查询中报错。

大型知识库的内存压力。 在单批次中 embedding 50,000+个文本块可能消耗大量内存。索引器以64为一批进行处理以限制峰值内存使用。如果内存仍然不足,请减小批次大小。


使用FTS5进行全文搜索

SQLite的FTS5扩展提供了基于BM25排名的全文搜索功能。FTS5是混合检索(hybrid retrieval)管道中的关键词搜索组件。本节介绍FTS5的配置、BM25的优势场景及其特定的失败模式。

FTS5虚拟表

CREATE VIRTUAL TABLE chunks_fts USING fts5(
    chunk_text,
    section,
    heading_context,
    content=chunks,
    content_rowid=id
);

内容同步模式。 content=chunks参数告诉FTS5直接引用chunks表,而不是存储文本的副本。这将存储需求减半,但意味着在插入、更新或删除chunks时,必须手动同步FTS5。

索引列。 共有三列被索引: - chunk_text — 每个chunk的主要内容(BM25权重:1.0) - section — H2标题文本(BM25权重:0.5) - heading_context — 笔记标题、标签和元数据(BM25权重:0.3)

BM25排名

BM25通过词频、逆文档频率和文档长度归一化来对文档进行排名。FTS5中的bm25()辅助函数接受按列设置的权重:

SELECT
    c.id, c.file_path, c.section, c.chunk_text,
    bm25(chunks_fts, 1.0, 0.5, 0.3) AS score
FROM chunks_fts
JOIN chunks c ON chunks_fts.rowid = c.id
WHERE chunks_fts MATCH ?
ORDER BY score
LIMIT 30;

列权重(1.0、0.5、0.3)的含义: - chunk_text中的关键词匹配对得分贡献最大 - section(标题)中的匹配贡献为前者的一半 - heading_context(标题、标签)中的匹配贡献为30%

这些权重可以调整。如果您的vault中的标题具有较强的内容预测性,可以增加section权重。如果您的标签全面且准确,可以增加heading_context权重。

BM25的优势场景

BM25在包含精确标识符的查询中表现出色:

  • 函数名: _rrf_fuseembed_batchget_stale_files
  • CLI标志: --incremental--vault--model
  • 配置键: bm25_weightmax_tokensbatch_size
  • 错误消息: SQLITE_LOCKEDConnectionRefusedError
  • 特定专业术语: PostToolUsePreToolUseAGENTS.md

对于这类查询,BM25能够立即找到精确匹配。向量搜索会返回语义相关的内容,但可能将精确匹配排在概念性讨论之后。

BM25的失败场景

当查询使用的术语与存储内容不同时,BM25会失败:

  • 查询:”how to handle authentication failures” → vault中包含关于”login error recovery”和”session expiration handling”的笔记。BM25无法匹配,因为关键词不同。
  • 查询:”what is the best way to manage state” → vault中包含关于”Redux store patterns”和”context providers”的笔记。BM25无法匹配,因为”状态管理”是通过特定技术名称来表达的。

BM25在大规模vault中还会遇到关键词冲突问题。在一个包含15,000个文件的vault中,搜索”configuration”会匹配数百条笔记,因为几乎每个项目笔记都会提到配置。结果在技术上是正确的,但实际上毫无用处——排名无法判断哪条”configuration”笔记与当前查询相关。

FTS5分词器

FTS5默认使用unicode61分词器,可处理ASCII和Unicode文本。对于包含大量CJK(中文、日文、韩文)内容的vault,建议使用trigram分词器:

-- For CJK-heavy vaults
CREATE VIRTUAL TABLE chunks_fts USING fts5(
    chunk_text, section, heading_context,
    content=chunks, content_rowid=id,
    tokenize='trigram'
);

默认的unicode61分词器按词边界进行分割,对于词与词之间没有空格的语言效果不佳。trigram分词器每三个字符进行分割,能够实现子串匹配,但代价是索引大小增加(约为3倍)。

维护

当底层chunks表发生变化时,FTS5需要显式同步:

# After inserting chunks
cursor.execute("""
    INSERT INTO chunks_fts(chunks_fts)
    VALUES('rebuild')
""")

rebuild命令从内容表重建FTS5索引。在批量插入(完整重建索引)后执行此命令,但不要在单条增量更新后执行——对于增量更新,请使用INSERT INTO chunks_fts(rowid, chunk_text, section, heading_context)来同步单独的行。


使用sqlite-vec进行向量搜索

sqlite-vec扩展将向量KNN(K-最近邻)搜索引入SQLite。本节介绍sqlite-vec的配置、从笔记到可搜索向量的嵌入(embeddings)管道,以及特定的查询模式。

sqlite-vec虚拟表

CREATE VIRTUAL TABLE chunk_vecs USING vec0(
    id INTEGER PRIMARY KEY,
    embedding float[256]
);

vec0模块将256维浮点向量存储为紧凑的二进制数据。id列与chunks表一一对应,支持在向量结果和chunk元数据之间进行联合查询。

嵌入管道

从笔记到可搜索向量的管道流程如下:

Note (.md file)
   Chunker: split at H2 boundaries
     Chunks (30-2000 chars each)
       Credential filter: scrub secrets
         Embedder: Model2Vec encode
           Vectors (256-dim float arrays)
             sqlite-vec: store as packed binary
               Ready for KNN queries

向量序列化

Python的struct模块将浮点向量序列化为sqlite-vec存储格式:

import struct

def _serialize_vector(vec):
    """Pack float list into binary for sqlite-vec."""
    return struct.pack(f"{len(vec)}f", *vec)

def _deserialize_vector(blob, dim=256):
    """Unpack binary blob to float list."""
    return list(struct.unpack(f"{dim}f", blob))

KNN查询

向量搜索查询首先对输入进行嵌入编码,然后通过余弦距离(cosine distance)找到K个最近的chunk:

def _vector_search(self, query_text, limit=30):
    query_vec = self.embedder.embed_batch([query_text])[0]
    packed = _serialize_vector(query_vec)

    results = self.db.execute("""
        SELECT
            cv.id,
            cv.distance,
            c.file_path,
            c.section,
            c.chunk_text
        FROM chunk_vecs cv
        JOIN chunks c ON cv.id = c.id
        WHERE embedding MATCH ?
            AND k = ?
        ORDER BY distance
    """, [packed, limit]).fetchall()

    return results

sqlite-vec中的MATCH操作符执行近似最近邻搜索。k参数控制返回结果的数量。distance列包含余弦距离(0 = 完全相同,2 = 完全相反)。

向量搜索的优势场景

当概念比具体词汇更重要时,向量搜索表现出色:

  • 查询:”how to handle authentication failures” → 找到关于”login error recovery”的笔记(相同语义空间,不同关键词)
  • 查询:”what patterns exist for caching” → 找到关于”memoization”、”Redis TTL strategies”和”HTTP cache headers”的笔记(相关概念,多样化术语)
  • 查询:”approaches to testing asynchronous code” → 找到关于”pytest-asyncio fixtures”、”mock event loops”和”async test patterns”的笔记(相同概念通过实现细节表达)

向量搜索的失败场景

向量搜索在处理精确标识符时表现不佳:

  • 查询:_rrf_fuse → 返回关于”fusion algorithms”和”rank merging”的笔记,但可能将实际的函数定义排在概念性讨论之后
  • 查询:PostToolUse → 返回关于”tool lifecycle hooks”和”post-execution handlers”的笔记,而非特定的hook名称

向量搜索在处理结构化数据时也存在困难。JSON配置文件、YAML块和代码片段生成的嵌入向量捕获的是结构模式而非语义含义。一个包含"review": true的JSON文件与一段关于代码审查的散文讨论,其嵌入结果完全不同。

优雅降级

如果sqlite-vec加载失败(扩展缺失、平台不兼容、库文件损坏),检索器将回退到仅使用BM25的搜索模式:

class VectorIndex:
    def __init__(self, db_path):
        self.db = sqlite3.connect(db_path)
        self._vec_available = False
        try:
            self.db.enable_load_extension(True)
            self.db.load_extension("vec0")
            self._vec_available = True
        except Exception:
            pass  # BM25-only mode

    @property
    def vec_available(self):
        return self._vec_available

检索器在尝试向量查询前会检查vec_available属性。当向量搜索不可用时,所有搜索仅使用BM25,RRF融合步骤将被跳过。


Reciprocal Rank Fusion(RRF)

RRF将两个排名列表合并,无需进行分数校准。本节涵盖算法原理、一个完整的查询追踪示例、k参数的调优,以及选择RRF而非其他替代方案的原因。如需使用可编辑排名的交互式计算器、场景预设和可视化架构探索器,请参阅hybrid retriever深度解析

算法原理

RRF仅根据文档在每个列表中的排名位置为其分配分数:

score(d) = Σ (weight_i / (k + rank_i))

其中: - k是平滑常数(取值60,遵循Cormack等人的研究1) - rank_i是文档在结果列表i中从1开始的排名 - weight_i是可选的每列表权重乘数(默认值1.0)

在多个列表中排名靠前的文档将获得更高的融合分数。仅出现在一个列表中的文档只从该单一来源获得分数。

为什么选择RRF而非其他方案

加权线性组合需要将BM25分数与cosine similarity距离进行校准。BM25分数是无界的,且随语料库大小而变化。余弦距离的范围是[0, 2]。将两者组合需要归一化处理,而归一化参数依赖于具体数据集。RRF仅使用排名位置,而排名位置始终是从1开始的整数,与评分方法无关。

学习型融合模型需要标注的训练数据——查询-文档相关性对。对于个人知识库而言,这样的训练数据并不存在。您需要手动判断数百个查询-文档对才能训练出有用的模型。RRF无需任何训练数据即可工作。

Condorcet投票方法(Borda计数、Schulze方法)在理论上很优雅,但实现和调优更为复杂。RRF原始论文证明,在TREC评估数据上,RRF优于Condorcet方法。1

融合实践

查询:”how does the review aggregator handle disagreements”

BM25将review-aggregator.py排在第3位(精确关键词匹配”review”、”aggregator”、”disagreements”),但将两个配置文件排在更前面(它们更突出地匹配了”review”)。向量搜索将同一文本块排在第1位(语义匹配冲突解决)。经过RRF融合后:

文本块 BM25 Vec 融合分数
review-aggregator.py “Disagreement Resolution” #3 #1 0.0323
code-review-patterns.md “Multi-Reviewer” #4 #2 0.0317
deliberation-config.json “Review Weights” #1 0.0164

两个列表中排名靠前的文本块会浮到顶部。仅出现在一个列表中的文本块只获得单一来源的分数,会排在双重排名结果的下方。实际的分歧解决逻辑最终胜出,因为两种方法都找到了它——BM25通过关键词匹配,向量搜索通过语义匹配。

如需查看包含逐排名RRF数学计算的完整步骤追踪,请在交互式RRF计算器中尝试不同的k值。

实现

RRF_K = 60

def _rrf_fuse(self, bm25_results, vec_results,
              bm25_weight=1.0, vec_weight=1.0):
    """Fuse BM25 and vector results using Reciprocal Rank Fusion."""
    scores = {}

    for rank, r in enumerate(bm25_results, start=1):
        cid = r["id"]
        if cid not in scores:
            scores[cid] = {
                "rrf_score": 0.0,
                "file_path": r["file_path"],
                "section": r["section"],
                "chunk_text": r["chunk_text"],
                "bm25_rank": None,
                "vec_rank": None,
            }
        scores[cid]["rrf_score"] += bm25_weight / (self._rrf_k + rank)
        scores[cid]["bm25_rank"] = rank

    for rank, r in enumerate(vec_results, start=1):
        cid = r["id"]
        if cid not in scores:
            scores[cid] = {
                "rrf_score": 0.0,
                "file_path": r["file_path"],
                "section": r["section"],
                "chunk_text": r["chunk_text"],
                "bm25_rank": None,
                "vec_rank": None,
            }
        scores[cid]["rrf_score"] += vec_weight / (self._rrf_k + rank)
        scores[cid]["vec_rank"] = rank

    fused = sorted(
        scores.values(),
        key=lambda x: x["rrf_score"],
        reverse=True,
    )
    return fused

调优k值

k常数控制着顶部排名结果相对于较低排名结果的权重分配:

  • 较低的k值(例如10):顶部排名结果占主导地位。排名1的分数为1/11 = 0.091,排名10的分数为1/20 = 0.050(相差1.8倍)。当您信任各个排序器能正确获取顶部结果时适用。
  • 默认k值(60):平衡模式。排名1的分数为1/61 = 0.0164,排名10的分数为1/70 = 0.0143(相差1.15倍)。排名差异被压缩,使得出现在多个列表中的权重更大。
  • 较高的k值(例如200):同时出现在两个列表中比排名位置重要得多。排名1的分数为1/201,排名10的分数为1/210——几乎相同。当各个排序器产生噪声较大的排名,但跨列表一致性可靠时适用。

建议从k=60开始。RRF原始论文发现该值在多种TREC数据集上表现稳健。只有在针对您自己的查询分布测量到失败案例后,再进行调优。

平局处理

当两个文本块具有相同的RRF分数时(这种情况罕见,但在一个列表中排名相同且未出现在另一个列表中时可能发生),按以下规则打破平局:

  1. 优先选择同时出现在两个列表中的文本块,而非仅出现在一个列表中的
  2. 在同时出现在两个列表中的文本块之间,优先选择合并排名较低的
  3. 在仅出现在一个列表中的文本块之间,优先选择在该列表中排名较低的

完整的检索流水线

本节追踪一个查询从输入到输出经过整个流水线的过程:BM25搜索、向量搜索、RRF融合、token预算截断和上下文组装。

端到端流程

User query: "PostToolUse hook for context compression"
  │
  ├─ BM25 Search (FTS5)
  │    → MATCH "PostToolUse hook context compression"
  │    → Top 30 results ranked by BM25 score
  │    → 12ms
  │
  ├─ Vector Search (sqlite-vec)
  │    → Embed query with Model2Vec
  │    → KNN k=30 on chunk_vecs
  │    → Top 30 results ranked by cosine distance
  │    → 8ms
  │
  └─ RRF Fusion
       → Merge 60 candidates (may overlap)
       → Score by rank position
       → Top 10 results
       → 3ms
       │
       └─ Token Budget
            → Truncate to max_tokens (default 4000)
            → Estimate at 4 chars per token
            → Return results with metadata
            → <1ms

总延迟:约23毫秒,测试环境为Apple M3 Pro硬件上包含49,746个分块的数据库。

搜索API

class HybridRetriever:
    def search(self, query, limit=10, max_tokens=4000,
               bm25_weight=1.0, vec_weight=1.0):
        """
        Search the vault using hybrid BM25 + vector retrieval.

        Args:
            query: Search query text
            limit: Maximum results to return
            max_tokens: Token budget for total result text
            bm25_weight: Weight for BM25 results in RRF
            vec_weight: Weight for vector results in RRF

        Returns:
            List of SearchResult with file_path, section,
            chunk_text, rrf_score, bm25_rank, vec_rank
        """
        # BM25 search
        bm25_results = self._bm25_search(query, limit=30)

        # Vector search (if available)
        if self.index.vec_available:
            vec_results = self._vector_search(query, limit=30)
            fused = self._rrf_fuse(
                bm25_results, vec_results,
                bm25_weight, vec_weight,
            )
        else:
            fused = bm25_results  # BM25-only fallback

        # Token budget truncation
        results = []
        token_count = 0
        for r in fused[:limit]:
            chunk_tokens = len(r["chunk_text"]) // 4
            if token_count + chunk_tokens > max_tokens:
                break
            results.append(r)
            token_count += chunk_tokens

        return results

Token预算截断

max_tokens参数防止检索器返回超出AI工具可用范围的上下文。估算采用每个token 4个字符的比例(对英文散文而言是合理的近似值)。结果按贪心策略截断:按排名顺序依次添加结果,直到预算耗尽。

这是一种保守策略。更精细的方法会考虑每个结果的质量分数,优先选择更短但质量更高的结果,而非更长但质量较低的结果。贪心方法更简单,且在实践中效果良好,因为RRF排名已经按相关性对结果进行了排序。

数据库Schema(完整版)

-- Chunk content and metadata
CREATE TABLE chunks (
    id INTEGER PRIMARY KEY,
    file_path TEXT NOT NULL,
    section TEXT NOT NULL,
    chunk_text TEXT NOT NULL,
    heading_context TEXT DEFAULT '',
    mtime_ns INTEGER NOT NULL,
    embedded_at REAL NOT NULL
);

CREATE INDEX idx_chunks_file ON chunks(file_path);
CREATE INDEX idx_chunks_mtime ON chunks(mtime_ns);

-- FTS5 for BM25 search (content-synced to chunks table)
CREATE VIRTUAL TABLE chunks_fts USING fts5(
    chunk_text, section, heading_context,
    content=chunks, content_rowid=id
);

-- sqlite-vec for vector KNN search
CREATE VIRTUAL TABLE chunk_vecs USING vec0(
    id INTEGER PRIMARY KEY,
    embedding float[256]
);

-- Model metadata for compatibility tracking
CREATE TABLE model_meta (
    key TEXT PRIMARY KEY,
    value TEXT
);

优雅降级路径

Full pipeline:     BM25 + Vector + RRF    Best results
No sqlite-vec:     BM25 only              Good results (no semantic)
No model download:  BM25 only              Good results (no semantic)
No FTS5:           Vector only             Decent results (no keyword)
No database:       Error                   Prompt user to run indexer

检索器在初始化时检查各组件的可用性,并相应调整查询策略。缺少某个组件会降低结果质量,但不会导致报错。唯一的硬性失败条件是数据库文件缺失。

生产环境统计数据

测试环境:16,894个文件的知识库,49,746个分块,83 MB SQLite数据库,Apple M3 Pro:

指标 数值
总文件数 16,894
总分块数 49,746
数据库大小 83 MB
BM25查询延迟(p50) 12ms
向量查询延迟(p50) 8ms
RRF融合延迟 3ms
端到端搜索延迟(p50) 23ms
全量重建索引时间 约4分钟
增量重建索引时间 <10秒
Embedding模型 potion-base-8M(256维)
BM25候选池 30
向量候选池 30
默认结果数限制 10
默认token预算 4,000 tokens

内容哈希与变更检测

索引器需要知道自上次索引运行以来哪些文件发生了变化。本节介绍变更检测机制和哈希策略。

文件修改时间比对

索引器在chunks表中为每个分块存储mtime_ns(以纳秒为单位的文件修改时间)。在增量运行时,索引器执行以下步骤:

  1. 扫描知识库中所有允许文件夹内的.md文件
  2. 从文件系统读取每个文件的mtime_ns
  3. 与数据库中存储的mtime_ns进行比对
  4. 识别三种类别:
  5. 新文件:路径存在于文件系统中但不在数据库中
  6. 已修改文件:路径同时存在于两者中但mtime_ns不同
  7. 已删除文件:路径存在于数据库中但不在文件系统中
def get_stale_files(self, vault_mtimes):
    """Find files whose mtime changed or are new."""
    stored = dict(self.db.execute(
        "SELECT DISTINCT file_path, mtime_ns FROM chunks"
    ).fetchall())

    stale = []
    for path, mtime in vault_mtimes.items():
        if path not in stored or stored[path] != mtime:
            stale.append(path)
    return stale

def get_deleted_files(self, vault_paths):
    """Find files in database that no longer exist in vault."""
    stored_paths = set(r[0] for r in self.db.execute(
        "SELECT DISTINCT file_path FROM chunks"
    ).fetchall())
    return stored_paths - set(vault_paths)

为什么选择mtime而非内容哈希

内容哈希(对文件内容计算SHA-256)比mtime比对更可靠——它能检测到文件被触碰但内容未变的情况(例如git checkout恢复了原始mtime)。然而,哈希需要在每次增量运行时读取每个文件的内容。对于16,894个文件,读取文件内容需要2-3秒,而从文件系统读取mtime只需不到100毫秒。

权衡如下:mtime比对偶尔会触发对未更改文件的不必要重新索引(误报),但绝不会遗漏实际的变更。误报的代价仅是每次运行多几次embedding调用。速度差异(100毫秒 vs 3秒)使得mtime成为在每次AI交互时运行的系统的务实选择。

处理删除操作

当文件从知识库中删除时,索引器会从数据库中移除该文件的所有分块:

def remove_file(self, file_path):
    """Remove all chunks and vectors for a file."""
    chunk_ids = [r[0] for r in self.db.execute(
        "SELECT id FROM chunks WHERE file_path = ?",
        [file_path],
    ).fetchall()]

    for cid in chunk_ids:
        self.db.execute(
            "DELETE FROM chunk_vecs WHERE id = ?", [cid]
        )
    self.db.execute(
        "DELETE FROM chunks WHERE file_path = ?",
        [file_path],
    )

FTS5内容同步表需要通过INSERT INTO chunks_fts(chunks_fts, rowid, ...) VALUES('delete', ?, ...)对每个被删除的行进行显式删除操作。索引器在文件移除流程中处理这一步骤。


增量索引与全量重建索引

索引器支持两种模式:增量索引(快速,日常使用)和全量重建(较慢,偶尔使用)。本节介绍每种模式的适用场景、幂等性保证以及损坏恢复方案。

增量索引

适用场景: 编辑笔记后的日常索引,这是默认模式。

执行流程: 1. 扫描知识库中的文件变更(通过 mtime 比较) 2. 删除已删除文件对应的文本块 3. 对已修改的文件重新分块和重新生成 embeddings 4. 为新文件插入新的文本块 5. 同步 FTS5 索引

典型耗时: 对于包含 16,000 个文件的知识库,处理一天的编辑量不到 10 秒。

python index_vault.py --incremental

全量重建索引

适用场景: - 更换 embedding 模型后(检测到模型哈希值不匹配) - 数据库架构迁移后(新增列、修改索引) - 数据库损坏后(完整性检查失败) - 增量索引产生异常结果时

执行流程: 1. 删除所有现有数据(文本块、向量、FTS5 条目) 2. 扫描整个知识库 3. 对所有文件进行分块 4. 对所有文本块生成 embeddings 5. 从头构建 FTS5 索引

典型耗时: 在 Apple M3 Pro 上处理 16,894 个文件约需 4 分钟。

python index_vault.py --full

幂等性

两种模式都具有幂等性:对同一命令执行两次会产生相同的结果。索引器在插入新文本块之前会先删除该文件已有的文本块,因此对已经是最新状态的数据库重复执行增量索引不会产生任何变更。重复执行全量重建索引则会生成一个完全相同的数据库。

损坏恢复

如果 SQLite 数据库发生损坏(写入期间断电、磁盘错误、事务执行中途进程被终止):

# Check integrity
sqlite3 vectors.db "PRAGMA integrity_check;"

# If corruption detected, full reindex rebuilds from source files
python index_vault.py --full

真正的数据源始终是知识库中的文件,而非数据库。数据库只是一个派生产物,可以随时重建。这是一个关键的设计特性:您永远不需要备份数据库。

--incremental 标志

当索引器以 --incremental 模式运行时:

  1. 模型哈希校验。 将存储的模型哈希值与当前模型进行比较。如果不一致,自动切换为全量重建索引模式并向用户发出警告。
  2. 文件扫描。 遍历允许的文件夹,收集文件路径和修改时间。
  3. 变更检测。 与已存储的数据进行比对。
  4. 批量处理。 以每批 64 个文件的方式对变更文件重新分块和生成 embeddings。
  5. 进度报告。 输出已处理文件数量和耗时。
  6. 优雅关闭。 处理 SIGINT 信号时,先完成当前文件的处理再停止。

凭据过滤与数据边界

个人笔记中包含敏感信息:API 密钥、Bearer 令牌、数据库连接字符串、调试过程中粘贴的私钥。凭据过滤器可以防止这些内容进入检索索引。

问题所在

一篇关于调试 OAuth 集成的笔记可能包含:

The token was: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
I used this curl command:
  curl -H "Authorization: Bearer sk-ant-api03-abc123..."

如果不进行过滤,JWT 和 API 密钥都会被分块、生成 embeddings 并存储到数据库中。搜索”authentication”时会返回包含真实密钥的文本块。更糟糕的是,如果检索器通过 MCP 将结果传递给 AI 工具,这些密钥就会出现在 AI 的上下文窗口中,甚至可能出现在工具的日志里。

基于模式的过滤

凭据过滤器在每个文本块存储之前运行,匹配 25 种特定厂商模式以及通用模式:

特定厂商模式:

模式 示例 正则表达式
OpenAI API 密钥 sk-... sk-[a-zA-Z0-9_-]{20,}
Anthropic API 密钥 sk-ant-api03-... sk-ant-api\d{2}-[a-zA-Z0-9_-]{20,}
GitHub PAT ghp_... gh[ps]_[a-zA-Z0-9]{36,}
AWS 访问密钥 AKIA... AKIA[0-9A-Z]{16}
Stripe 密钥 sk_live_... [sr]k_(live\|test)_[a-zA-Z0-9]{24,}
Cloudflare 令牌 ... 多种模式

通用模式:

模式 检测方式
JWT 令牌 eyJ[a-zA-Z0-9_-]+\.eyJ[a-zA-Z0-9_-]+
Bearer 令牌 Bearer\s+[a-zA-Z0-9_\-\.]+
私钥 -----BEGIN (RSA\|EC\|OPENSSH) PRIVATE KEY-----
高熵 base64 字符串 每字符熵值 >4.5 比特、长度 40+ 字符的字符串
密码赋值 password\s*[:=]\s*["'][^"']+["']

过滤器实现

def clean_content(text):
    """Scrub credentials from text before indexing."""
    result = ScanResult(is_clean=True, match_count=0, patterns=[])

    for pattern in CREDENTIAL_PATTERNS:
        matches = pattern.regex.findall(text)
        if matches:
            text = pattern.regex.sub(
                f"[REDACTED:{pattern.name}]", text
            )
            result.is_clean = False
            result.match_count += len(matches)
            result.patterns.append(pattern.name)

    return text, result

关键设计决策:

  1. 先过滤再生成 embeddings。 清洗后的文本才是实际被 embedding 的内容。向量表示永远不会编码凭据模式。查询”API key”时返回的是讨论 API 密钥管理的笔记,而非包含实际密钥的笔记。

  2. 替换而非删除。 [REDACTED:pattern-name] 标记保留了周围文本的语义上下文。embedding 能够捕捉到”此处原本有类似凭据的内容”这一语义信息,但不会编码凭据本身。

  3. 记录模式而非值。 过滤器会记录匹配到的模式(例如”从 oauth-debug.md 中清除了 2 个凭据 [jwt, bearer-token]”),但绝不会记录凭据的实际值。

基于路径的排除

.indexignore 文件提供基于路径的粗粒度排除功能。凭据过滤器则在已索引的文件内提供细粒度的内容清洗。两者缺一不可:

  • .indexignore 用于排除您明确知道包含敏感内容的整个文件夹(健康笔记、财务记录、职业文档)
  • 凭据过滤器用于清洗意外嵌入在可索引内容中的密钥

数据分级

对于包含多样化内容的知识库,建议按敏感程度对笔记进行分级:

级别 示例 是否索引? 是否过滤?
公开 博客草稿、技术笔记
内部 项目计划、架构决策
敏感 薪资数据、健康记录 否(.indexignore 不适用
受限 凭据、私钥 否(.indexignore 不适用

MCP 服务器架构

Model Context Protocol(MCP)服务器将检索器作为工具暴露给 AI 代理调用。本节涵盖服务器设计、功能范围和权限边界。

协议选择:STDIO 与 HTTP

MCP 支持两种传输模式:

STDIO — AI 工具将 MCP 服务器作为子进程启动,通过 stdin/stdout 进行通信。这是本地工具的标准模式。Claude Code、Codex CLI 和 Cursor 均支持 STDIO MCP 服务器。

{
  "mcpServers": {
    "obsidian": {
      "command": "python",
      "args": ["/path/to/obsidian_mcp.py"],
      "env": {
        "VAULT_PATH": "/path/to/vault",
        "DB_PATH": "/path/to/vectors.db"
      }
    }
  }
}

HTTP — MCP 服务器作为独立的 HTTP 服务运行。适用于远程访问、多客户端配置,或知识库位于共享服务器的团队配置。

{
  "mcpServers": {
    "obsidian": {
      "url": "http://localhost:3333/mcp"
    }
  }
}

建议:个人知识库使用 STDIO。它更简单、更安全(无网络暴露),且服务器生命周期由 AI 工具管理。仅当多个工具或多台设备需要同时访问同一知识库时,才使用 HTTP。

MCP 规范演进。2025年6月的 MCP 规范新增了基于 OAuth 的授权、结构化工具输出(类型化返回模式)和引导(服务器发起的用户提示)。16 下一版规范(暂定2026年6月)提议支持长时间任务的异步操作、将无状态请求处理作为默认传输模式,以及通过 .well-known URL 进行服务器发现。16 对于个人知识库服务器,STDIO 仍然是最简单的路径。规范变更主要影响具有多租户路由和负载均衡的企业级 HTTP 部署。请关注 MCP 路线图 以了解影响您传输选择的更新。

功能设计

MCP 服务器应暴露最少的工具集:

search — 主要工具。运行混合检索(hybrid retrieval)并返回排序结果。

{
  "name": "obsidian_search",
  "description": "Search the Obsidian vault using hybrid BM25 + vector retrieval",
  "parameters": {
    "query": { "type": "string", "description": "Search query" },
    "limit": { "type": "integer", "default": 5 },
    "max_tokens": { "type": "integer", "default": 2000 }
  }
}

read_note — 通过路径读取特定笔记的完整内容。当代理需要查看搜索结果的完整上下文时非常有用。

{
  "name": "obsidian_read_note",
  "description": "Read the full content of a note by file path",
  "parameters": {
    "file_path": { "type": "string", "description": "Relative path within vault" }
  }
}

list_notes — 列出匹配过滤条件(按文件夹、标签、类型或日期范围)的笔记。当代理没有具体查询时,适用于探索性浏览。

{
  "name": "obsidian_list_notes",
  "description": "List notes matching filters",
  "parameters": {
    "folder": { "type": "string", "description": "Folder path within vault" },
    "tag": { "type": "string", "description": "Tag to filter by" },
    "limit": { "type": "integer", "default": 20 }
  }
}

get_context — 便捷工具,运行搜索并将结果格式化为适合注入对话的上下文块。

{
  "name": "obsidian_get_context",
  "description": "Get formatted context from vault for a topic",
  "parameters": {
    "topic": { "type": "string", "description": "Topic to get context for" },
    "max_tokens": { "type": "integer", "default": 2000 }
  }
}

权限边界

MCP 服务器应执行严格的边界控制:

  1. 只读。服务器读取知识库和索引数据库,不创建、修改或删除笔记。写入操作(捕获新笔记)由单独的钩子或技能处理,而非 MCP 服务器。

  2. 知识库范围限定。服务器仅读取配置的知识库路径内的文件。路径遍历尝试(../../etc/passwd)必须被拒绝。

  3. 凭证过滤输出。即使数据库包含预过滤内容,仍应在输出时应用凭证过滤,作为纵深防御措施。

  4. 令牌限制响应。对所有工具响应执行 max_tokens 限制,防止 AI 工具接收过大的上下文块。

错误处理

MCP 工具应返回结构化的错误消息,帮助 AI 工具进行恢复:

def search(self, query, limit=5, max_tokens=2000):
    if not self.db_path.exists():
        return {
            "error": "Index database not found. Run the indexer first.",
            "suggestion": "python index_vault.py --full"
        }

    results = self.retriever.search(query, limit, max_tokens)

    if not results:
        return {
            "results": [],
            "message": f"No results found for '{query}'. Try broader terms."
        }

    return {
        "results": [
            {
                "file_path": r["file_path"],
                "section": r["section"],
                "text": r["chunk_text"],
                "score": round(r["rrf_score"], 4),
            }
            for r in results
        ],
        "count": len(results),
        "query": query,
    }

Claude Code 集成

Claude Code 是 Obsidian 检索系统的主要使用者。本节涵盖 MCP 配置、钩子集成和 obsidian_bridge.py 模式。

MCP 配置

将 Obsidian MCP 服务器添加到 ~/.claude/settings.json

{
  "mcpServers": {
    "obsidian": {
      "command": "python",
      "args": ["/path/to/obsidian_mcp.py"],
      "env": {
        "VAULT_PATH": "/absolute/path/to/vault",
        "DB_PATH": "/absolute/path/to/vectors.db"
      }
    }
  }
}

添加配置后,重新启动 Claude Code。MCP 服务器将作为子进程启动。验证其是否运行:

> What tools do you have from the obsidian MCP server?

Claude Code 应列出可用的工具(obsidian_searchobsidian_read_note 等)。

钩子集成

钩子在定义的生命周期节点扩展 Claude Code 的行为。两个钩子与 Obsidian 集成相关:

PreToolUse 钩子 — 在代理处理工具调用之前查询知识库,自动注入相关上下文。

#!/bin/bash
# ~/.claude/hooks/pre-tool-use/obsidian-context.sh
# Automatically inject vault context before tool execution

TOOL_NAME="$1"
PROMPT="$2"

# Only inject context for code-related tools
case "$TOOL_NAME" in
    Edit|Write|Bash)
        # Query the vault
        CONTEXT=$(python /path/to/retriever.py search "$PROMPT" --limit 3 --max-tokens 1500)
        if [ -n "$CONTEXT" ]; then
            echo "---"
            echo "Relevant vault context:"
            echo "$CONTEXT"
            echo "---"
        fi
        ;;
esac

PostToolUse 钩子 — 将重要的工具输出捕获回知识库,供未来检索使用。

#!/bin/bash
# ~/.claude/hooks/post-tool-use/capture-insight.sh
# Capture significant outputs to vault (selective)

TOOL_NAME="$1"
OUTPUT="$2"

# Only capture substantial outputs
if [ ${#OUTPUT} -gt 500 ]; then
    python /path/to/capture.py --text "$OUTPUT" --source "claude-code-$TOOL_NAME"
fi

obsidian_bridge.py 模式

桥接模块提供一个 Python API,供钩子和技能调用:

# obsidian_bridge.py
from retriever import HybridRetriever

_retriever = None

def get_retriever():
    global _retriever
    if _retriever is None:
        _retriever = HybridRetriever(
            db_path="/path/to/vectors.db",
            vault_path="/path/to/vault",
        )
    return _retriever

def search_vault(query, limit=5, max_tokens=2000):
    """Search vault and return formatted context."""
    retriever = get_retriever()
    results = retriever.search(query, limit, max_tokens)

    if not results:
        return ""

    lines = ["## Vault Context\n"]
    for r in results:
        lines.append(f"**{r['file_path']}** — {r['section']}")
        lines.append(f"> {r['chunk_text'][:500]}")
        lines.append("")

    return "\n".join(lines)

/capture 技能

一个用于将洞察捕获回知识库的 Claude Code 技能:

/capture "OAuth token rotation requires both access and refresh token invalidation"
  --domain security
  --tags oauth,tokens

该技能在 00-inbox/ 中创建一条带有正确 frontmatter 的新笔记,并触发增量重新索引,使新笔记可立即被搜索到。

上下文窗口管理

集成时应注意 Claude Code 的上下文窗口:

  • 将每次查询注入的上下文限制在1,500-2,000个令牌。超过此限制会与代理的工作记忆竞争。
  • 包含来源归属。始终包含文件路径和章节标题,以便代理可以引用来源。
  • 截断分块文本。长分块应使用 ... 截断而非完全省略。前300-500个字符通常包含关键信息。
  • 不要在每次工具调用时都注入。PreToolUse 钩子应根据调用的工具选择性地注入上下文。读取操作不需要知识库上下文,写入和编辑操作则受益于此。

Codex CLI 集成

Codex CLI 通过 config.toml 连接 MCP 服务器。其集成模式在配置语法和指令传递方面与 Claude Code 不同。

MCP 配置

添加到 .codex/config.toml~/.codex/config.toml

[mcp_servers.obsidian]
command = "python"
args = ["/path/to/obsidian_mcp.py"]

[mcp_servers.obsidian.env]
VAULT_PATH = "/absolute/path/to/vault"
DB_PATH = "/absolute/path/to/vectors.db"

AGENTS.md 模式

Codex CLI 读取 AGENTS.md 获取项目级指令。包含知识库搜索指引:

## 可用工具

### Obsidian 知识库(MCP:obsidian)
使用 `obsidian_search` 工具从知识库中查找相关上下文。
在以下情况下搜索知识库:
- 了解某个概念或模式的背景信息
- 查阅先前的决策或理由
- 获取实现所需的参考资料

查询示例:
- "authentication patterns in FastAPI"
- "how does the review aggregator work"
- "sqlite-vec configuration"

与 Claude Code 的差异

功能 Claude Code Codex CLI
MCP 配置 settings.json config.toml
Hooks ~/.claude/hooks/ 不支持
Skills ~/.claude/skills/ 不支持
指令文件 CLAUDE.md AGENTS.md
审批模式 --dangerously-skip-permissions suggest / auto-edit / full-auto

关键区别:Codex CLI 不支持 hooks。自动上下文注入模式(PreToolUse hook)不可用。作为替代,请在 AGENTS.md 中明确指示代理在开始工作前搜索知识库。


Cursor 及其他工具

Cursor 和其他支持 MCP 的 AI 工具可以连接到同一个 Obsidian MCP 服务器。本节介绍常用工具的配置方法。

Cursor

在项目根目录的 .cursor/mcp.json 中添加以下配置:

{
  "mcpServers": {
    "obsidian": {
      "command": "python",
      "args": ["/path/to/obsidian_mcp.py"],
      "env": {
        "VAULT_PATH": "/absolute/path/to/vault",
        "DB_PATH": "/absolute/path/to/vectors.db"
      }
    }
  }
}

Cursor 的 .cursorrules 文件可以包含使用知识库的指令:

When working on implementation tasks, search the Obsidian vault
for relevant context before writing code. Use the obsidian_search
tool with descriptive queries about the concept you're implementing.

兼容性矩阵

工具 MCP 支持 传输方式 配置位置
Claude Code 完整支持 STDIO ~/.claude/settings.json
Codex CLI 完整支持 STDIO .codex/config.toml
Cursor 完整支持 STDIO .cursor/mcp.json
Windsurf 完整支持 STDIO .windsurf/mcp.json
Continue.dev 部分支持 HTTP ~/.continue/config.json
Zed 开发中 STDIO 设置界面

不支持 MCP 的工具的替代方案

对于不支持 MCP 的工具,可以将检索器封装为 CLI:

# Search from command line
python retriever_cli.py search "query text" --limit 5

# Output formatted for copy-paste into any tool
python retriever_cli.py context "query text" --format markdown

该 CLI 输出结构化文本,可以手动粘贴到任何 AI 工具的输入中。虽然不如 MCP 集成优雅,但具有通用性。


利用结构化笔记实现提示词缓存

知识库中的结构化笔记可以作为可复用的上下文块,减少 AI 交互中的 token 消耗。本节介绍缓存键设计和 token 预算管理。

模式概述

与其在每次交互时搜索上下文,不如从结构良好的知识库笔记中预构建上下文块并缓存:

# cache_keys.py
CONTEXT_BLOCKS = {
    "auth-patterns": {
        "vault_query": "authentication patterns implementation",
        "max_tokens": 1500,
        "ttl_hours": 24,  # Rebuild daily
    },
    "api-conventions": {
        "vault_query": "API design conventions REST patterns",
        "max_tokens": 1000,
        "ttl_hours": 168,  # Rebuild weekly
    },
    "project-architecture": {
        "vault_query": "current project architecture decisions",
        "max_tokens": 2000,
        "ttl_hours": 12,  # Rebuild twice daily
    },
}

缓存失效

缓存失效基于两个信号:

  1. TTL 过期。每个上下文块都有生存时间(TTL)。当 TTL 过期时,系统会重新查询知识库来重建该块。
  2. 知识库变更检测。当索引器检测到对缓存上下文块所引用的文件进行了更改时,该块会立即失效。

Token 预算管理

一个会话从总上下文预算开始。缓存块消耗该预算的一部分:

Total context budget:    8,000 tokens
├─ System prompt:        1,500 tokens
├─ Cached blocks:        3,000 tokens (pre-loaded)
├─ Dynamic search:       2,000 tokens (on-demand)
└─ Conversation:         1,500 tokens (remaining)

缓存块在会话开始时加载。动态搜索结果按每次查询填充剩余预算。这种混合方式为代理提供了常用上下文的基准,同时为特定查询保留了预算空间。

缓存前后的 Token 用量对比

不使用缓存:每次相关查询都会触发知识库搜索,返回1,500-2,000个 token 的上下文。在一个会话中经过10次查询后,代理会消耗15,000-20,000个 token 的知识库上下文。

使用缓存:三个预构建的上下文块总共消耗4,500个 token。额外的搜索每次独立查询增加1,500-2,000个 token。在10次查询中,如果有6次被缓存块覆盖,代理消耗4,500 +(4 × 1,500)= 10,500个 token——大约是未缓存用量的一半。


PostToolUse Hooks 实现上下文压缩

工具输出可能非常冗长:堆栈跟踪、文件列表、测试结果等。PostToolUse hook 可以在这些输出消耗上下文窗口空间之前对其进行压缩。

问题描述

一个运行测试的 Bash 工具调用可能返回:

PASSED tests/test_auth.py::test_login_success
PASSED tests/test_auth.py::test_login_failure
PASSED tests/test_auth.py::test_token_refresh
PASSED tests/test_auth.py::test_session_expiry
... (200 more lines)
FAILED tests/test_api.py::test_rate_limit_exceeded

完整输出为5,000个 token,但关键信息仅在2行中:200个通过,1个失败。

Hook 实现

#!/bin/bash
# ~/.claude/hooks/post-tool-use/compress-output.sh
# Compress verbose tool outputs to preserve context window

TOOL_NAME="$1"
OUTPUT="$2"
OUTPUT_LEN=${#OUTPUT}

# Only compress large outputs
if [ "$OUTPUT_LEN" -lt 2000 ]; then
    exit 0  # Pass through unchanged
fi

case "$TOOL_NAME" in
    Bash)
        # Compress test output
        if echo "$OUTPUT" | grep -q "PASSED\|FAILED"; then
            PASSED=$(echo "$OUTPUT" | grep -c "PASSED")
            FAILED=$(echo "$OUTPUT" | grep -c "FAILED")
            FAILURES=$(echo "$OUTPUT" | grep "FAILED")
            echo "Tests: $PASSED passed, $FAILED failed"
            if [ "$FAILED" -gt 0 ]; then
                echo "Failures:"
                echo "$FAILURES"
            fi
        fi
        ;;
esac

防止递归触发

如果压缩 hook 产生的输出不加防护,可能会触发自身:

# Guard against recursive invocation
if [ -n "$COMPRESS_HOOK_ACTIVE" ]; then
    exit 0
fi
export COMPRESS_HOOK_ACTIVE=1

压缩策略

输出类型 检测方式 压缩策略
测试结果 PASSED / FAILED 关键字 统计通过/失败数量,仅显示失败项
文件列表 命令中包含 lsfind 截断为前20条并显示总数
堆栈跟踪 Traceback 关键字 保留首尾栈帧及错误信息
Git 状态 modified: / new file: 按状态汇总数量
构建输出 warning: / error: 过滤信息行,仅保留警告和错误

信号摄取与分类管道

摄取层决定了哪些内容进入知识库。如果缺乏筛选,知识库将积累大量噪音。本节介绍将信号路由到领域文件夹的评分管道。

来源

信号来自多个渠道:

  • RSS 订阅源:技术博客、安全公告、发布说明
  • 书签:通过 Obsidian Web Clipper 或书签工具保存的浏览器书签
  • 新闻通讯:电子邮件新闻通讯中的关键摘录
  • 手动捕获:在阅读、对话或研究过程中编写的笔记
  • 工具输出:通过钩子捕获的重要 AI 工具输出

评分维度

每个信号按四个维度评分(每个维度 0.0 到 1.0):

维度 问题 低分(0.0-0.3) 高分(0.7-1.0)
相关性 这是否与我的活跃领域相关? 边缘内容,超出范围 与当前工作直接相关
可操作性 我能否使用这些信息? 纯理论,无实际应用 可以应用的具体技术或模式
深度 内容有多充实? 标题党,浅层摘要 附带示例的详细分析
权威性 来源的可信度如何? 匿名博客,未经验证 一手来源、同行评审、公认专家

综合评分与路由

composite = (relevance * 0.35) + (actionability * 0.25) +
            (depth * 0.25) + (authority * 0.15)
分数范围 操作
0.55+ 自动路由到领域文件夹
0.40 - 0.55 加入队列等待人工审核
< 0.40 丢弃(不存储)

领域路由

评分超过 0.55 的信号根据关键词匹配和主题分类路由到 12 个领域文件夹之一:

05-signals/
├── ai-tooling/        # Claude, LLMs, AI development tools
├── security/          # Vulnerabilities, auth, cryptography
├── systems/           # Architecture, distributed systems
├── programming/       # Languages, patterns, algorithms
├── web/               # Frontend, backends, APIs
├── data/              # Databases, data engineering
├── devops/            # CI/CD, containers, infrastructure
├── design/            # UI/UX, product design
├── mobile/            # iOS, Android, cross-platform
├── career/            # Industry trends, hiring, growth
├── research/          # Academic papers, whitepapers
└── other/             # Signals that don't fit a domain

生产统计数据

运行 14 个月以来的数据:

指标 数值
处理的信号总数 7,771
自动路由(>0.55) 4,832(62%)
排队等待审核(0.40-0.55) 1,543(20%)
丢弃(<0.40) 1,396(18%)
活跃领域文件夹 12
日均信号数 ~18

知识图谱模式

Obsidian 的 wiki-link 图谱编码了笔记之间的关系。本节介绍链接语义、用于上下文扩展的图谱遍历,以及降低图谱质量的反模式。

每个 wiki-link 都会在图谱中创建一条有向边。Obsidian 同时追踪正向链接和 backlink:

  • 正向链接:笔记 A 包含 [[笔记 B]] → A 链接到 B
  • Backlink:笔记 B 显示笔记 A 引用了它

图谱根据上下文编码不同类型的关系:

链接模式 语义 示例
行内链接 “与……相关” “See [[OAuth Token Rotation]] for details”
标题链接 “包含子主题” ”## Related\n- [[Token Rotation]]\n- [[Session Management]]”
标签式链接 “被归类为” ”[[type/reference]]”
MOC 链接 “属于” 一个 Maps of Content 笔记,列出相关笔记

Maps of Content(MOC)

MOC 是将相关笔记组织成可导航结构的索引笔记:

---
title: "Authentication & Security MOC"
type: moc
domain: security
---

## Core Concepts
- [[OAuth 2.0 Overview]]
- [[JWT Token Anatomy]]
- [[Session Management Patterns]]

## Implementation Patterns
- [[OAuth Token Rotation]]
- [[Refresh Token Security]]
- [[PKCE Flow Implementation]]

## Failure Modes
- [[Token Expiry Handling]]
- [[Session Fixation Prevention]]
- [[CSRF Defense Strategies]]

MOC 通过两种方式提升检索效果:

  1. 直接匹配。搜索”authentication overview”时会匹配到 MOC 本身,为代理提供一份精心整理的相关笔记列表。
  2. 上下文扩展。在找到特定笔记后,检索器可以检查该笔记是否出现在任何 MOC 中,并将 MOC 的结构包含在结果中,为代理提供更广泛主题的全景图。

用于上下文扩展的图谱遍历

检索器的一个未来增强方向:在找到排名靠前的结果后,通过跟踪链接来扩展上下文:

def expand_context(results, depth=1):
    """Follow wiki-links from top results to find related context."""
    expanded = set()
    for result in results:
        # Parse wiki-links from chunk text
        links = extract_wiki_links(result["chunk_text"])
        for link_target in links:
            # Resolve link to file path
            target_path = resolve_wiki_link(link_target)
            if target_path and target_path not in expanded:
                expanded.add(target_path)
                # Include target's most relevant chunk
                target_chunks = get_chunks_for_file(target_path)
                # ... rank and include best chunk
    return results + list(expanded_results)

当前检索器尚未实现此功能,但它是图谱结构的自然延伸。

反模式

孤立集群。一组笔记彼此之间相互链接,但与知识库的其余部分没有连接。Obsidian 的图谱面板会将这些显示为断开的孤岛。孤立集群表明缺少 MOC 或缺少跨领域链接。

标签蔓延。不一致地使用标签或创建过多细粒度标签。一个拥有 5,000 篇笔记和 500 个唯一标签的知识库,平均每 10 个标签才对应 1 篇笔记——这些标签对过滤毫无用处。应整合为 20-50 个与领域文件夹对应的高级标签。

链接多、内容少的笔记。完全由 wiki-link 组成而没有任何正文的笔记。这类笔记的索引效果很差,因为分块器没有文本可供生成 embeddings。至少添加一段上下文文字,解释相关笔记之间的关联。

对所有内容都使用双向链接。并非每个引用都需要成为 wiki-link。在行文中顺带提到”OAuth”并不需要写成 [[OAuth 2.0 Overview]]。请将 wiki-link 保留给有意义的、可导航的关系——即点击链接后能提供有用上下文的情况。


开发者工作流方案

将知识库检索与日常开发任务相结合的实用工作流。

晨间上下文加载

通过加载相关上下文开始新的一天:

Search my vault for notes about [current project] updated in the last week

检索器会返回与您活跃项目相关的近期笔记,帮助您快速回忆上次的工作进展。比重新阅读昨天的提交记录更加高效。

编码过程中的研究捕获

在实现功能的过程中,无需离开编辑器即可捕获洞见:

/capture "FastAPI dependency injection with async generators requires yield,
not return. The generator is the dependency lifecycle."
  --domain programming
  --tags fastapi,dependency-injection

捕获的洞见会立即被索引,并可供将来检索。经过数月积累,这些微捕获将构建起一个针对具体实现的知识语料库。

项目启动

在启动新项目或新功能时:

  1. 搜索知识库:”关于[技术/模式]我了解什么?”
  2. 查看前 5 条结果,了解之前的决策和踩过的坑
  3. 检查该领域是否已有 MOC;如果没有,创建一个
  4. 搜索失败模式:”[技术]的常见问题”

借助知识库搜索进行调试

当遇到错误或意外行为时:

Search my vault for [error message or symptom]

之前的调试笔记往往包含根本原因和修复方案。这在跨项目的重复问题上尤其有价值——知识库记住了您遗忘的东西。

代码审查准备

在审查 PR 之前:

Search my vault for patterns and conventions about [module being changed]

知识库会返回与被审查代码相关的先前决策、架构约束和编码规范。审查将基于组织知识,而不仅仅是差异对比。

性能调优

本节涵盖针对不同仓库规模和使用模式的优化策略。

索引大小管理

仓库规模 分块数 数据库大小 全量重建索引 增量更新
500 篇笔记 ~1,500 3 MB 15 秒 <1 秒
2,000 篇笔记 ~6,000 12 MB 45 秒 2 秒
5,000 篇笔记 ~15,000 30 MB 2 分钟 4 秒
15,000 篇笔记 ~50,000 83 MB 4 分钟 <10 秒
50,000 篇笔记 ~150,000 250 MB 15 分钟 30 秒

当笔记数量达到 50,000 篇以上时,请考虑: - 将批处理大小从 64 增加到 128 以加快 embedding 生成速度 - 使用 WAL 模式(默认)以支持并发访问 - 在非高峰时段运行全量重建索引

查询优化

WAL 模式。 SQLite 的预写日志(Write-Ahead Logging)模式允许在索引器写入时进行并发读取:

db.execute("PRAGMA journal_mode=WAL")

当 MCP 服务器在索引器执行增量更新时处理查询请求,这一点至关重要。

连接池。 MCP 服务器应复用数据库连接,而不是为每次查询打开新连接。在 WAL 模式下,单个长期存活的连接即可支持并发读取。

# MCP server initialization
db = sqlite3.connect(DB_PATH, check_same_thread=False)
db.execute("PRAGMA journal_mode=WAL")
db.execute("PRAGMA mmap_size=268435456")  # 256 MB mmap

内存映射 I/O。 mmap_size pragma 指示 SQLite 对数据库文件使用内存映射 I/O。对于 83 MB 的数据库,将整个文件映射到内存中可以消除大部分磁盘读取。

FTS5 优化。 在全量重建索引后,运行:

INSERT INTO chunks_fts(chunks_fts) VALUES('optimize');

此操作会合并 FTS5 内部的 b-tree 段,从而降低后续搜索的查询延迟。

扩展性基准测试

测试环境为 Apple M3 Pro,36 GB RAM,NVMe SSD:

操作 500 篇笔记 5K 篇笔记 15K 篇笔记 50K 篇笔记
BM25 查询 2ms 5ms 12ms 25ms
向量查询 1ms 3ms 8ms 20ms
RRF 融合 <1ms <1ms 3ms 5ms
完整搜索 3ms 8ms 23ms 50ms

所有基准测试均包含数据库访问、查询执行和结果格式化。MCP STDIO 通信的网络延迟额外增加 1-2ms。


故障排除

索引偏移

症状: 搜索返回过时的结果,或遗漏最近添加的笔记。

原因: 添加笔记后增量索引器未运行,或文件的修改时间(mtime)未更新(例如,从另一台机器同步时保留了原始时间戳)。

解决方法: 运行全量重建索引:python index_vault.py --full

Embedding 模型切换

症状: 更换 embedding 模型后,向量搜索返回无意义的结果。

原因: 旧向量(来自先前模型)正在与新的查询向量进行比较。维度或向量空间语义不兼容。

解决方法: 索引器应检测到模型哈希不匹配并自动触发全量重建索引。如果未自动触发,请手动清除数据库并重新索引:

rm vectors.db
python index_vault.py --full

FTS5 维护

症状: 经过多次增量更新后,FTS5 查询返回不正确或不完整的结果。

原因: 经过多次小规模更新后,FTS5 内部段可能变得碎片化。

解决方法: 重建并优化:

INSERT INTO chunks_fts(chunks_fts) VALUES('rebuild');
INSERT INTO chunks_fts(chunks_fts) VALUES('optimize');

MCP 超时

症状: AI 工具报告 MCP 服务器超时。

原因: 首次查询会触发模型加载(延迟初始化),耗时 2-5 秒。AI 工具的默认 MCP 超时时间可能更短。

解决方法: 在服务器启动时预热模型:

# In MCP server initialization
retriever = HybridRetriever(db_path, vault_path)
retriever.search("warmup", limit=1)  # Trigger model load

SQLite 文件锁

症状: 出现 SQLITE_BUSYSQLITE_LOCKED 错误。

原因: 多个进程同时写入数据库。WAL 模式允许并发读取,但只允许一个写入者。

解决方法: 确保只有一个进程(索引器)写入数据库。MCP 服务器和钩子应仅执行读取操作。如果需要并发写入,请使用 WAL 模式并设置忙等待超时:

db.execute("PRAGMA busy_timeout=5000")  # Wait up to 5 seconds

sqlite-vec 无法加载

症状: 向量搜索被禁用;检索器以仅 BM25 模式运行。

原因: sqlite-vec 扩展未安装、在库路径中未找到,或与 SQLite 版本不兼容。

解决方法:

# Install via pip
pip install sqlite-vec

# Or compile from source
git clone https://github.com/asg017/sqlite-vec
cd sqlite-vec && make

验证扩展是否加载成功:

import sqlite3
db = sqlite3.connect(":memory:")
db.enable_load_extension(True)
db.load_extension("vec0")
print("sqlite-vec loaded successfully")

大型仓库内存问题

症状: 对大型仓库(50,000 篇以上笔记)进行全量重建索引时出现内存不足错误。

原因: embedding 批处理大小过大,或所有文件内容被同时加载到内存中。

解决方法: 减小批处理大小并增量处理文件:

BATCH_SIZE = 32  # Reduce from 64

同时确保索引器逐个处理文件(依次读取、分块和 embedding 每个文件后再处理下一个),而不是将所有文件一次性加载到内存中。


迁移指南

从 Apple Notes 迁移

  1. 通过 macOS 的”导出全部”选项导出 Apple Notes,或使用迁移工具如 apple-notes-liberator
  2. 使用 markdownifypandoc 将 HTML 导出文件转换为 markdown
  3. 将转换后的文件移动到仓库的 00-inbox/ 文件夹
  4. 检查每篇笔记并添加 frontmatter
  5. 将笔记移动到相应的领域文件夹

从 Notion 迁移

  1. 从 Notion 导出:Settings → Export → Markdown & CSV
  2. 将导出的压缩包解压到仓库的 00-inbox/ 文件夹
  3. 修复 Notion 特有的 markdown 格式问题:
  4. Notion 使用 - [ ] 表示清单——这是标准 markdown 格式
  5. Notion 将属性表以 HTML 形式包含——转换为 YAML frontmatter
  6. Notion 以相对路径嵌入图片——将图片复制到您的附件文件夹
  7. 添加标准 frontmatter(typedomaintags
  8. 将 Notion 页面链接替换为 Obsidian wiki-link

从 Google Docs 迁移

  1. 使用 Google Takeout 导出所有文档
  2. .docx 文件转换为 markdown:pandoc -f docx -t markdown input.docx -o output.md
  3. 批量转换:for f in *.docx; do pandoc -f docx -t markdown "$f" -o "${f%.docx}.md"; done
  4. 移入仓库,添加 frontmatter,整理到相应文件夹

从纯 Markdown(非 Obsidian)迁移

如果您已有一个 markdown 文件目录:

  1. 将该目录作为 Obsidian 仓库打开(Obsidian → Open Vault → Open folder)
  2. 如果该目录受版本控制,将 .obsidian/ 添加到 .gitignore
  3. 创建 frontmatter 模板并应用到现有文件
  4. 在阅读和整理过程中开始使用 [[wiki-links]] 链接笔记
  5. 立即运行索引器——检索系统从第一天起即可使用

从其他检索系统迁移

如果您正在从其他 embedding/搜索系统迁移:

  1. 不要尝试迁移向量数据。 不同模型产生的向量空间不兼容。请使用新模型运行全量重建索引。
  2. 迁移内容,而非索引。 仓库文件才是真实数据源。索引只是派生产物。
  3. 迁移后进行验证。 运行 10-20 个您已知答案的查询,验证结果是否符合预期。

更新日志

日期 变更
2026-03-02 在模型对比中添加 potion-base-32M 和 potion-retrieval-32M。添加量化/降维部分。添加 MCP 规范演进说明。
2026-03-01 首次发布

参考文献


  1. Cormack, G.V., Clarke, C.L.A., and Buettcher, S. Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods。SIGIR,2009。提出了以k=60作为无参数方法来组合排序列表的RRF算法。 

  2. OpenAI Embeddings Pricing。text-embedding-3-small:每百万token $0.02。预估知识库全量重建索引费用:约$0.30。 

  3. van Dongen, T. et al. Model2Vec: Turn any Sentence Transformer into a Small Fast Model。arXiv,2025。描述了从句子转换器生成静态embeddings的蒸馏方法。 

  4. MTEB: Massive Text Embedding Benchmark。potion-base-8M平均得分50.03,而all-MiniLM-L6-v2为56.09(保留率89%)。 

  5. SQLite FTS5 Extension。FTS5提供具有BM25排序和可配置列权重的全文搜索功能。 

  6. sqlite-vec: A vector search SQLite extension。在SQLite中提供用于KNN向量搜索的vec0虚拟表。 

  7. Robertson, S. and Zaragoza, H. The Probabilistic Relevance Framework: BM25 and Beyond。Foundations and Trends in Information Retrieval,2009。 

  8. Karpukhin, V. et al. Dense Passage Retrieval for Open-Domain Question Answering。EMNLP,2020。密集表示在开放域问答任务上比BM25高出9-19%。 

  9. Reimers, N. and Gurevych, I. Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks。EMNLP,2019。密集语义相似度的奠基性工作。 

  10. Luan, Y. et al. Sparse, Dense, and Attentional Representations for Text Retrieval。TACL,2021。混合检索(hybrid retrieval)在MS MARCO上始终优于单模态方法。 

  11. SQLite Write-Ahead Logging。WAL模式支持并发读取与单写入者。 

  12. Gao, Y. et al. Retrieval-Augmented Generation for Large Language Models: A Survey。arXiv,2024。RAG架构和分块策略的综述。 

  13. Thakur, N. et al. BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models。NeurIPS,2021。 

  14. Model2Vec: Distill a Small Fast Model from any Sentence Transformer。Minish Lab,2024。 

  15. Obsidian Documentation。Obsidian官方文档。 

  16. Model Context Protocol Specification。用于连接AI工具与数据源的MCP标准。 

  17. 作者生产环境数据。16,894个文件,49,746个分块,83.56 MB SQLite数据库,14个月内处理7,771个信号。查询延迟通过time.perf_counter()测量。 

  18. Model2Vec Potion Models。Minish Lab,2025。Potion-base-32M(MTEB 52.46)、potion-retrieval-32M(MTEB检索36.35)以及v0.5.0+版本的量化/降维特性。 

VAULT obsidian.md INDEXED