关键要点
- 选择三种参考架构之一,而不是从零开始设计。 Obsidian 中心型 (笔记优先,~50K 条目)、AnythingLLM 中心型 (文档优先,~100K 条目) 或自建 Python + ChromaDB 技术栈 (工程师优先,1M+ 条目)。混合架构很少划算 — 集成成本占主导。
- 本地 AI PKB 有五层:捕获、存储、嵌入、检索、界面。 大多数初学者错误发生在捕获层,而不是 LLM 层。如果条目不能从移动端和邮件流入系统,再巧妙的检索也无法挽救项目。
- 硬件门槛:16 GB 内存。 低于此值,您只能在嵌入模型和聊天模型之间选一个 — 不能两者兼顾。在 16 GB 上可以并行运行 Llama 3.2 3B + nomic-embed-text。32 GB 可升级到 Qwen3 7B 或运行多个聊天会话。100,000 条目以上将嵌入迁移到家庭服务器。
- 2026 推荐模型: 聊天 — Llama 3.2 3B (默认)、Phi-4 Mini (8 GB 系统)、Qwen3 7B (32 GB+ 追求质量);嵌入 — nomic-embed-text (768 维,快速)、mxbai-embed-large (1024 维,更精准)、bge-m3 (多语言)。
- 捕获是扩展瓶颈,不是检索。 大多数知识条目在移动端到达 (网页剪藏、截图、语音笔记、转发邮件)。在调优 LLM 之前,先设计移动分享 → vault 路径。iOS Shortcuts → Obsidian / Working Copy / a-Shell 是三种可行的 iOS 路径。
- 同步方式决定移动端能跑什么。 Obsidian Sync 干净处理二进制嵌入索引;iCloud Drive 跨平台破坏它们;Git 需要 .gitignore 纪律和按设备重新索引。先选同步,再选插件。
- 备份不是可选项。 三层:vault 快照 (Time Machine、Backblaze、restic)、明文内容的 Git 历史,以及嵌入 + 元数据的季度导出作为干净的重建路径。嵌入可重新生成但成本高 — 10,000 条目以上也要备份它们。
快速事实
- 覆盖架构: Obsidian 中心型、AnythingLLM 中心型、自建 Python + ChromaDB 技术栈。
- LLM 后端: Ollama (推荐) — 在一个本地端点
http://localhost:11434后运行聊天和嵌入模型。 - 2026 推荐聊天模型: Llama 3.2 3B (16 GB 系统)、Phi-4 Mini (8 GB)、Qwen3 7B (32 GB+)。
- 2026 推荐嵌入模型: nomic-embed-text (768 维,快速)、mxbai-embed-large (1024 维,精准)、bge-m3 (多语言)。
- 条目数量目标: Obsidian ~50,000 条笔记,AnythingLLM ~100,000 条文档,自建 Python + ChromaDB 技术栈 1M+。
- 硬件门槛: 笔记本 16 GB 内存。10,000 条目以上:32 GB 推荐。100,000 条目以上:64 GB 家庭服务器。
- 移动捕获路径 (iOS): Shortcuts → Obsidian、Shortcuts → Working Copy (Git)、Shortcuts → a-Shell。Android:Tasker 或 HTTP Shortcuts。
应该构建哪种架构?
选择与您现有知识流入方式相符的架构 — 不是听起来最强大的那种。 如果您每天写笔记,选择 Obsidian 中心型。如果您的知识主要是文档 (PDF、导出、网页剪藏),选择 AnythingLLM 中心型。仅当您真的有 100,000+ 条目或多用户访问需求时,才构建自建 Python + ChromaDB 技术栈 — 维护成本是真实的,在该阈值以下很少能被证明合理。
📍 简单一句话
笔记优先的工作流选择 Obsidian + Smart Connections + Copilot + Ollama;文档密集型归档选择 AnythingLLM + Ollama;100K+ 条目的工程师选择自建 Python + ChromaDB 技术栈。
💬 简单来说
三条路,一个目的地。如果您已经在笔记应用中生活,Obsidian 在您现有的习惯外包裹 AI 功能。如果您主要囤积 PDF 和网页,AnythingLLM 是一个集成应用,可摄取、索引并聊天。如果您写代码并希望完全控制,Python + ChromaDB 让您构建您想要的 — 但您自己维护。选择符合您现有工作流的路径;不要为了适应架构而改变习惯。
决策:哪种 PKB 架构?
Use a local LLM if:
- •您已经使用 Obsidian 或希望 Markdown 文件的笔记优先工作流 → Obsidian 中心型
- •您的知识主要是 PDF、导出、网页剪藏和邮件归档 → AnythingLLM 中心型
- •您有 100,000+ 条目、自定义 schema 需求或多用户访问 → 自建 Python + ChromaDB 技术栈
- •您希望一个应用涵盖捕获、存储、RAG 和聊天 → AnythingLLM 中心型
- •您希望完全控制分块、检索和重排 → 自建 Python + ChromaDB 技术栈
Use a cloud model if:
- •您每次查询都需要 GPT-4o 级推理且归档很小 → Notion AI 或带自定义 GPT 的 ChatGPT (本地技术栈在合成上约有 70% 的能力)
- •您没有 16 GB+ 内存的机器或家庭服务器 → 云 SaaS PKB (Mem、Reflect)
- •您的团队需要并发多用户访问且不想托管服务 → 云等价方案
Quick decision:
- →笔记优先用户的默认选择:Obsidian + Smart Connections + Copilot + Ollama
- →文档密集型用户的默认选择:AnythingLLM + Ollama
- →100K+ 条目的工程师:自建 Python + ChromaDB + Llama 3.2 3B 技术栈
💡Tip: 不要因为听起来更强大就从自建 Python 技术栈开始。先构建 Obsidian 中心型或 AnythingLLM 中心型,运行两个月,识别不符合您工作流的层,然后只用自定义组件替换那一层。所有从「Python 从零开始」并运行超过六个月的 PKB 项目最终都收敛到 Obsidian 形或 AnythingLLM 形。
架构对比表
三种参考架构在五个对大多数构建者重要的轴上不同:设置复杂度、条目数量上限、移动同步、捕获灵活性和维护负担。 设置复杂度大致随控制度线性增长 — 维护成本也是如此。
📍 简单一句话
Obsidian 在 ~50K 条目时为中等复杂度,AnythingLLM 在 ~100K 条目时为低复杂度,自建 Python + ChromaDB 技术栈为高复杂度但可扩展至 100 万+ 条目。
💬 简单来说
AnythingLLM 设置最简单,在两种「开箱即用」选项中扩展最远 — 但它对文档组织有强烈意见。Obsidian 提供最具表达力的笔记层和活跃的插件生态,代价是设置稍多。自建 Python 无上限,但您维护一切:分块、重排、去重、同步、备份。按您对维护的耐心选择,而不是仅按条目数量。
| 架构 | 设置复杂度 | 最大条目 | 移动同步 | 最适合 |
|---|---|---|---|---|
| Obsidian 中心型 | 中 | ~50,000 | 是 (Obsidian Sync;iCloud / Git 有限制) | 具有日常写作习惯的笔记优先重度用户 |
| AnythingLLM 中心型 | 低 | ~100,000 | 有限 (通过 LAN / Tailscale 从手机访问 Web UI) | 文档密集型 PKB (PDF、导出、网页剪藏) |
| 自建 Python + ChromaDB | 高 | 1M+ | 手动 (需自建 API + 移动客户端) | 希望完全控制 + 多用户的工程师 |
💡Tip: 移动同步是最被低估的对比轴。AnythingLLM 在技术上比 Obsidian 更容易设置,但在移动端意味着「在 Safari 中打开 LAN Web UI」 — 不是原生体验。Obsidian Mobile 配合 Obsidian Sync,提供接近原生的 iOS / Android 应用,可离线阅读。如果移动捕获和阅读重要,请将 Obsidian 加权至高于表格暗示的水平。
本地 AI PKB 的五层
每个本地 AI PKB 无论架构如何都有相同的五层:捕获、存储、嵌入、检索、界面。 失败通常是因为某一层与其他层不匹配 — 最常见的是先进的检索层搭配无人使用的破损捕获管道。
- 1捕获
Why it matters: 条目进入系统的方式。Web Clipper、邮件转发、移动分享、语音笔记、手动粘贴。初学者构建中最容易跳过的层 — 也是决定系统能否经受日常使用的层。如果移动端捕获超过 5 秒,系统会被闲置。 - 2存储
Why it matters: 条目在磁盘上的位置。Markdown vault (Obsidian、Logseq)、文档文件夹 + 数据库 (AnythingLLM) 或文件系统 + 清单 (自建 Python)。选择能在工具更换中存活的存储格式 — 明文 Markdown 最可移植;二进制数据库最不可移植。 - 3嵌入
Why it matters: 用于语义搜索的条目向量表示。由本地模型生成 (通过 Ollama 的 nomic-embed-text 或 mxbai-embed-large)。嵌入模型可以稍后更换,但迁移成本是「全部重新嵌入」 — 选一次,坚持到底。 - 4检索
Why it matters: 查询时如何找到条目。Top-k 向量搜索、可选重排、可选元数据过滤 (标签、日期、来源)。朴素 top-5 与调优 top-20 加重排器之间的质量差异是「有用」与「神奇」之差。 - 5界面
Why it matters: 您查询和阅读的方式。侧边栏 (Smart Connections)、聊天 (Copilot、AnythingLLM)、CLI (自建 Python) 或 API。大多数用户默认选择聊天 — 但「相关笔记」侧边栏会浮现聊天找不到的被遗忘材料,因为您不知道该问什么。
⚠️Warning: 一种常见失败的构建模式:选择最强检索 (带重排的自定义混合搜索)、最聪明的聊天模型 (Qwen3 7B),却忽视捕获。三周后,vault 里有 47 个条目,因为移动端没有任何东西流入。修正方式始终一样:简化检索,简化聊天,修复捕获,接受 80% 的价值来自条目能进入系统这件事本身。
架构 A:Obsidian 中心型
Obsidian + Smart Connections + Copilot for Obsidian + Ollama 是 2026 年笔记优先工作流的默认架构。 在 16 GB Mac M3 Pro 或 PC 上可干净地扩展至约 50,000 条笔记,通过 Obsidian Mobile 支持移动阅读,并将所有内容保留为可带到任何未来工具的明文 Markdown。
- 存储: 文件夹 (「vault」) 中的 Markdown 文件。明文,简单文件夹,无数据库。可在工具迁移中存活。
- 捕获: Obsidian Web Clipper (浏览器扩展)、Obsidian Mobile 分享 (iOS / Android)、通过 Mailspike 或自定义 IFTTT 配方的邮件到 Obsidian、手动粘贴。
- 嵌入: Smart Connections 插件 → Ollama 在
http://localhost:11434/api/embeddings→ nomic-embed-text (默认) 或 mxbai-embed-large (更精准)。索引位于 vault 内的.smart-env/。 - 检索: Smart Connections 侧边栏 (相关笔记视图) + Copilot for Obsidian Vault QA 模式 (vault 上聊天查询的 RAG)。两者都使用嵌入索引。
- 界面: Smart Connections 侧边栏 (被动发现) + Copilot 聊天面板 (主动查询) + Text Generator 模板 (日常摘要等可重复工作流)。
- 设置时间: ~30 分钟 (安装 Ollama、拉取模型、安装三个插件、配置端点、让初始索引构建)。
- 硬件: 16 GB 内存最低 (Llama 3.2 3B + nomic-embed-text 并行)。10,000 条笔记以上推荐 32 GB。强烈推荐 SSD — 索引重建在 HDD 上受 I/O 限制。
- 条目上限: ~50,000 条笔记可行;测试至 20,000 时增量重新索引在亚秒级。50K+ 条笔记时初始索引运行 4–8 小时,应考虑子 vault。
- 最适合: 具有日常写作习惯、Markdown 优先偏好、希望「思考伙伴」侧边栏浮现被遗忘笔记的用户。
- 不适合: 知识主要为 PDF 和网页剪藏的用户 (选择 AnythingLLM 中心型);希望单一一体化应用的用户 (Obsidian 中心型是「Obsidian + 3 插件 + Ollama」)。
💡Tip: 关于此架构插件层的深入探讨 (哪 5 个插件、配置步骤、vault 规模数值),请参阅 Obsidian + 本地 LLM 插件指南。本页面涵盖架构;插件指南涵盖配置。
架构 B:AnythingLLM 中心型
AnythingLLM + Ollama 是一体化选项:捕获、存储、RAG 和聊天打包在单个桌面或自托管应用中。 可扩展至约 100,000 条文档 (PDF、网页剪藏、导出的混合),当您的知识主要以文档而非笔记的形式到达时,这是正确选择。
- 存储: AnythingLLM 内部数据库 (默认 SQLite;多用户自托管使用 Postgres)。文档通过 UI 摄取;原始文件可保留在您镜像的文件夹中。
- 捕获: 应用内上传 (将 PDF / 文件拖入工作区)、网页浏览器扩展、用于编程摄取的公共 API (
POST /api/v1/document/upload)、通过官方集成或自定义中继的邮件转发。 - 嵌入: AnythingLLM 使用您配置的嵌入提供商 — 选择「Ollama」 → 端点
http://localhost:11434→ 模型nomic-embed-text。嵌入存储在内置向量库中 (默认 LanceDB;ChromaDB / Pinecone 可选)。 - 检索: 工作区上的 RAG。可配置块大小、top-k 检索、可选重排。多个工作区允许按主题分区 (例如「工作」、「阅读」、「项目」)。
- 界面: AnythingLLM Web UI (在桌面和移动浏览器中工作)、自定义前端的公共 API、用于将其他工具接入您的 PKB 的 OpenAI 兼容端点。
- 设置时间: ~15 分钟 (安装 AnythingLLM Desktop 或 Docker、指向 Ollama、拖入文档)。
- 硬件: 16 GB 内存最低。10,000 条文档以上推荐 32 GB。在相同条目数下,AnythingLLM 比 Obsidian + 插件更省内存,因为只有一个进程而不是两个。
- 条目上限: 单个工作区中 ~100,000 条文档;50K 以上分区到多个工作区,以保持检索延迟低于 ~1 秒。
- 最适合: PDF 重度归档用户、网页剪藏重度捕获用户,以及偏好单个应用而非插件栈的用户。也是自托管共享 PKB 的小团队的正确选择。
- 不适合: 希望笔记优先写作面的用户 (Obsidian);希望以明文 Markdown 拥有存储的用户 (AnythingLLM 的向量库是内部的)。
💡Tip: 关于此处使用的 RAG 层的逐步设置 (Ollama + AnythingLLM、摄取、块调优),请参阅 30 分钟内为 PDF 构建本地 RAG 教程。要将 RAG 从玩具示例扩展到 1,000+ PDF,请参阅 本地与 1000+ PDF 聊天。
架构 C:自建 Python + ChromaDB
仅当您真的有 100,000+ 条目、多用户需求或现成工具无法建模的特定 schema 需求时,自建 Python + ChromaDB + Ollama 技术栈才是正确选择。 维护成本是真实的:分块、去重、重排、同步、备份 — 您拥有一切。
ChromaDB 摄取 (Python 草图)
“import chromadb, ollama, pathlib client = chromadb.PersistentClient(path="./chroma") coll = client.get_or_create_collection("kb") for p in pathlib.Path("vault").rglob("*.md"): text = p.read_text() emb = ollama.embeddings(model="nomic-embed-text", prompt=text)["embedding"] coll.upsert(ids=[str(p)], embeddings=[emb], documents=[text], metadatas=[{"source": str(p)}])”
带重排的查询 (草图)
“q = "What did I write about local RAG sync?" q_emb = ollama.embeddings(model="nomic-embed-text", prompt=q)["embedding"] hits = coll.query(query_embeddings=[q_emb], n_results=20) # pass hits["documents"] through a re-ranker, keep top 5 # send top 5 + question to Llama 3.2 3B via Ollama chat endpoint”
- 存储: 文件系统 (每个来源一个文件夹:
notes/、pdfs/、web/、email/) + 元数据清单 (SQLite 或 JSONL)。源文件保持开放格式,以便您可以更换检索层而无需重新摄取。 - 捕获: 由 webhook 触发的脚本 (Web Clipper → HTTP 端点 → 文件写入)、邮件转发 → IMAP poller → 文件写入、移动分享 → Tailscale 端点 → 文件写入。每个捕获路径都是一个小型 Python 服务。
- 嵌入: ChromaDB (本地模式,持久化到磁盘) + 通过 OpenAI 兼容端点的 Ollama 嵌入。通过 watchdog 进程在文件更改时重新嵌入。ChromaDB 通过 HNSW 索引在单台机器上扩展至数百万向量。
- 检索: ChromaDB top-k 相似度 + 重排器 (BGE Re-ranker 或本地 Cohere 等价物) + 元数据过滤 (日期范围、标签、来源)。可选与 BM25 在块上的混合搜索,用于精确词项匹配。
- 界面: 任意组合:小型 FastAPI 服务暴露 OpenAI 兼容
/v1/chat/completions端点、Streamlit / Gradio UI、CLI 或全部三者。在前面放 Open WebUI,无需编写 UI 代码即可获得精致的聊天体验。 - 设置时间: ~1 天可工作的 v1;~2 周迭代调优分块、检索质量和针对您数据的捕获管道。
- 硬件: 32 GB 内存笔记本用于开发;100,000 条目以上家庭服务器 64 GB 内存,这样嵌入服务不会与您的笔记本竞争。500K 以上为聊天吞吐量考虑专用 GPU (RTX 4060 或更好)。
- 条目上限: 通过 HNSW + 分片可行 1M+ 条目;瓶颈从检索转移到捕获管道可靠性和 schema 更改时的重新嵌入成本。
- 最适合: 希望拥有技术栈的工程师、有自定义 schema 的团队 (例如「每个条目都有置信度分数、来源和作者」),或在 Obsidian 或 AnythingLLM 中遇到硬限制 (分别为 50K 和 100K) 的用户。
- 不适合: 非工程师;低估维护成本的任何人;用例已被现成选项覆盖的用户。
⚠️Warning: 自建项目最常见的失败模式:由于 schema 不稳定,在每次代码更改时重新嵌入整个归档。在摄取超过 ~5,000 条目之前,锁定嵌入模型 + 块大小。在 100K 条目时从 nomic-embed-text 768 维迁移到 mxbai-embed-large 1024 维需要数小时计算并破坏 ChromaDB 集合 — 您不能混合维度。
捕获管道:网页、邮件、移动、语音
捕获层决定您的 PKB 能否经受日常使用。大多数知识在桌面之外到达 — 在移动端、邮件、语音笔记中 — 而要求先打开桌面应用的捕获管道是被绕过的管道。 为四个主要流入构建,接受 80% 的条目将在移动端到达。
- Web Clipper (桌面 + 移动): Obsidian Web Clipper、AnythingLLM 浏览器扩展,或将当前页面 POST 到您的捕获端点的自定义 bookmarklet。移动分享 → Web Clipper 扩展 → vault。
- 邮件转发: 专用地址 (例如
kb@yourdomain.com) + IMAP poller → 文件写入。转发您想保留的邮件;poller 处理摄取。在文件名中使用每个来源的前缀,以便检索可以按来源过滤。 - 移动分享: 最常用的捕获路径。iOS Share → Obsidian (写入 Markdown 文件)、iOS Share → Working Copy (提交到 Git)、iOS Share → 自定义 Shortcut (POST 到您的捕获 API)。Android:HTTP Shortcuts 或 Tasker。
- 语音笔记: 类似 AudioPen 的捕获在 2026 年越来越普遍。在手机上录音 → 用 Whisper.cpp 本地转录或通过自托管 Whisper 服务 → 将转录写为 Markdown 文件 → 嵌入。
- 手动粘贴: 备用方案。始终有效,从不扩展。用于长尾。
- 截图 OCR: 截图是有损的捕获格式。在 iOS 上使用 Apple Live Text 或本地 OCR 管道 (Tesseract、Apple Vision、EasyOCR) 提取文本 + 写入包含图像和 OCR 文本的 Markdown 文件。
💡Tip: 在设计管道之前审计您现有的捕获习惯。看看您已经保存的:浏览器书签、截图、转发邮件、语音备忘录。PKB 捕获层应反映这些现有流入 — 如果您已经在不断截图,构建 OCR 路径;如果您已经在向自己转发邮件,构建邮件转发。添加新习惯 (「从现在起我手动复制粘贴每篇文章到 KB」) 从来都不奏效。
移动捕获:iOS Shortcuts、Working Copy、a-Shell
iOS 在 2026 年有三条可行的本地 AI PKB 捕获路径:Shortcuts → Obsidian、Shortcuts → Working Copy (Git),或 Shortcuts → a-Shell (脚本驱动)。 每条路径自然地与三种参考架构之一配对。选择其同步模型符合您整体架构的路径。
- Shortcuts → Obsidian (Obsidian 中心型): Obsidian「附加到笔记」Shortcut 将捕获的内容直接写入 vault。通过 Obsidian Sync (付费,推荐) 或 iCloud Drive (免费,有限制) 同步。最适合笔记优先工作流。
- Shortcuts → Working Copy (Git): 捕获的内容写入 iPhone 上的 Working Copy 仓库,然后自动提交并推送。桌面拉取。免费、稳健,与任何 Markdown vault 配合工作。注意:Working Copy 是付费的 (一次性约 $20)。最适合 Git 同步的 vault。
- Shortcuts → a-Shell: a-Shell 是运行脚本的免费 iOS 终端。构建一个 Shortcut,将捕获的文本管道传递给 a-Shell 脚本,该脚本写入文件并通过
git提交,通过 Tailscale 上的rsync同步,或上传到您的自定义捕获端点。最适合工程师构建的自定义架构。 - Android 等价物: Tasker + Termux + Git 作为 iOS Working Copy 路径的对应。HTTP Shortcuts 用于自定义端点路径。Obsidian Mobile 分享用于 Obsidian 路径。
- 延迟预算: 移动捕获应在端到端 5 秒内完成 (分享 → 文件写入 / 提交 / 上传)。任何更慢用户都会打开应用一次再也不打开。
- 离线捕获: 三条 iOS 路径都离线排队 (Shortcuts 排队,Working Copy 排队提交,a-Shell 脚本可本地写入并稍后同步)。对飞行、交通和农村地区的捕获至关重要。
⚠️Warning: 不要构建需要桌面在线的移动捕获路径 (例如 POST 到仅在您的笔记本唤醒时可达的 Tailscale 保护端点)。您将在工作会议期间、笔记本睡眠模式期间和夜间丢失捕获。要么在始终在线的家庭服务器 / NAS 上运行捕获端点,要么写入离线缓冲的最终一致性存储 (Obsidian Sync、Git、iCloud)。
扩展:1K、10K、100K 条目
扩展本地 AI PKB 有三种状态:1,000 条目以下,任何现代笔记本上一切都很快;1,000–10,000 条目,嵌入索引成为需要管理的真实工件;10,000 条目以上,硬件成为瓶颈,捕获管道可靠性主导结果。 以下现实数字假设 Mac M3 Pro / RTX 4060 PC 配 nomic-embed-text 和 Llama 3.2 3B。
| 条目数 | 推荐架构 | 初始嵌入时间 | 硬件 | 备注 |
|---|---|---|---|---|
| 1,000 条目 | 三者任一 | ~2 分钟 | 16 GB 内存笔记本 | 一切感觉即时。架构选择纯粹按工作流契合度。 |
| 10,000 条目 | Obsidian 或 AnythingLLM | ~25 分钟 | 16 GB 内存笔记本 (推荐 32 GB) | 嵌入索引 ~150–250 MB。编辑时重新嵌入亚秒级。大多数知识工作者的甜蜜点。 |
| 50,000 条目 | AnythingLLM 或自建 Python | ~3 小时 | 32 GB 内存笔记本或家庭服务器 | 初始索引夜间运行。此后规划子 vault / 工作区。嵌入磁盘使用 ~1.5–2 GB。 |
| 100,000 条目 | AnythingLLM (多工作区) 或自建 Python | 6–8 小时 | 最低 32 GB 内存;首选家庭服务器 | 将嵌入迁移到专用家庭服务器。捕获管道可靠性现在是主要故障模式,而不是检索。 |
| 500,000+ 条目 | 自建 Python + ChromaDB | 24+ 小时 | 64 GB 内存家庭服务器 + 专用 GPU | 分片、去重和增量重新嵌入管道变得必要。现成工具不再适合。 |
💡Tip: 初始嵌入成本是一次性账单。第一次索引后,只有更改的条目重新嵌入 — 即使在 100K 条目下也通常每次保存不到一秒。第一次的缓慢体验是真实的,但不会重复。在通电的机器上夜间运行初始索引,然后忘记它。
备份、版本控制、多设备同步
本地 AI PKB 需要三层备份:vault 快照 (Time Machine、Backblaze、restic)、明文内容的 Git 历史,以及作为干净重建路径的嵌入和元数据的季度导出。 嵌入在技术上可重新生成,但在 100K+ 条目时重新生成成本是数小时 — 也要备份它们。
- vault 快照 (文件系统级): 每 24 小时的 Time Machine (macOS) 或 restic (Linux)。Backblaze 或 rsync.net 用于异地。捕获包括嵌入在内的一切。
- Git 历史 (仅内容): 提交到 Git 仓库 (本地 + GitHub / Gitea private) 的明文 Markdown 文件。将
.smart-env/、vector_store/和任何其他二进制索引文件夹添加到.gitignore。Git 提供每条笔记的版本历史;vault 快照提供整个系统回滚。 - 嵌入导出 (季度): 将向量库导出为可移植格式 (ChromaDB → parquet、Smart Connections → JSON dump、AnythingLLM → 内置导出)。最近两次导出保留在异地。如果 vault 快照失败或嵌入索引损坏,这是您的快速重建路径。
- 多设备同步 — Obsidian 中心型: Obsidian Sync 干净处理明文 + 二进制索引 (端到端加密)。iCloud Drive 适用于明文,但跨平台破坏二进制索引。Working Copy / Termux 上的 Git 仅适用于明文 — 按设备重新索引。
- 多设备同步 — AnythingLLM 中心型: 在家庭服务器上将 AnythingLLM 作为自托管 Docker 容器运行。所有设备通过 LAN 或 Tailscale 连接到同一实例。无需客户端同步。
- 多设备同步 — 自建 Python: 您构建的架构决定它。大多数构建使用中央 API 服务 (家庭服务器上的 FastAPI) + POST 捕获和 GET 查询的客户端。Tailscale 提供网络层。
- 迁移到新计算机: 恢复 vault 快照 → 恢复 Git 仓库 → 重启 Ollama → 重启嵌入索引器。如果您跳过了嵌入导出步骤,嵌入重新生成是自动的;如果您备份了它但格式与平台相关,则需要手动重新索引。
- 选择性共享: 要共享 vault 的部分 (例如与合著者的研究项目),使用子 vault 或带标签的导出脚本。不要共享整个 vault — 大多数本地 AI PKB 积累不应离开本地技术栈的敏感条目 (医疗、财务、个人)。
💡Tip: 每季度测试一次恢复。大多数「我有备份」的说法都是愿望 — 测试是「我能在不到 2 小时内将我的 vault 恢复到一台新笔记本上吗?」 运行该测试。第一次这样做时,您会发现三层 (快照、Git、嵌入导出) 中有一层在过去六个月被错误配置。
常见错误
- 在捕获层之前设计检索层。 在 47 条目的 vault 上,带重排的自定义混合搜索是浪费。先构建捕获,接受朴素 top-5 检索,只在 vault 拥有 1,000+ 条目并能在真实查询上测量检索质量后才优化检索。
- 混合架构。 「Obsidian 用于笔记 + AnythingLLM 用于 PDF + 自建 Python 用于邮件」听起来干净,但集成成本占主导。选择一种架构,接受其限制,只在绝对必要时添加单个连接器 (例如 AnythingLLM 只读摄取 Obsidian vault 文件夹)。
- 切换嵌入模型而不重新嵌入归档。 在同一存储中混合 nomic-embed-text 768 维和 mxbai-embed-large 1024 维向量会悄无声息地破坏检索。选择一个嵌入模型 + 维度,锁定它,只通过完整重新嵌入归档来切换。
- 忽略 10,000 条目以上嵌入索引的备份。 「我可以重新生成它」是真的,但重新生成需要数小时。10K 条目以上将嵌入存储添加到您的备份策略。
- 为桌面设计但 80% 的捕获在移动端发生。 没有移动捕获路径的 PKB 会被闲置。第一天就测试移动捕获流程 — 分享到 vault 应在 5 秒内完成。
- 依赖 iCloud Drive 处理二进制嵌入索引。 iCloud 干净处理明文;二进制索引 (Smart Connections
.smart-env/、AnythingLLM 向量库) 跨平台破坏。使用 Obsidian Sync、自托管实例,或接受按设备重新索引。 - 100K 条目时不分区。 100K+ 条目的单个工作区 / vault 检索延迟为秒级。按主题 (工作、阅读、项目) 分区到多个工作区或子 vault;分别查询每个或通过路由器查询。
- 低估合规风险。 个人知识库不可避免地积累敏感数据 (客户、患者、同事来信、财务和医疗笔记)。中国《数据安全法》(2021) 要求重要数据本地化存储和处理 — 本地推理满足数据本地化要求,因为没有跨境数据流动,无需签订第三方处理协议。对于金融、医疗、法律行业的企业部署,本地技术栈是合规的更简洁路径。
来源
- Obsidian — obsidian.md 和 help.obsidian.md (vault 结构、移动同步架构、插件文档)。
- AnythingLLM — github.com/Mintplex-Labs/anything-llm (开源自托管 RAG 应用)。
- Ollama — ollama.com 和 github.com/ollama/ollama (本地 LLM 运行时;聊天 + 嵌入端点)。
- ChromaDB — trychroma.com 和 github.com/chroma-core/chroma (开源本地向量数据库)。
- Working Copy — workingcopy.app (用于移动捕获管道的 iOS Git 客户端)。
- a-Shell — holzschu.github.io/a-Shell_iOS/ (用于脚本驱动移动捕获的免费 iOS 终端)。
常见问题
如何将网页捕获到我的知识库?
按摩擦排序的三个选项。(1) 浏览器扩展 Web Clipper — Obsidian Web Clipper 或 AnythingLLM 浏览器扩展将当前页面直接写入您的 vault / 工作区。(2) 移动分享 — 分享 Safari / Chrome → Obsidian (写入 Markdown 文件) 或 → Working Copy (提交到 Git) 或 → 自定义 Shortcut (POST 到您的捕获 API)。(3) Bookmarklet — 用于没有扩展的浏览器;将当前 URL + 选区 POST 到您的捕获端点。在实践中,移动分享是最常用的路径 — 先设计它。
我可以将邮件转发到系统吗?
可以。设置一个专用地址 (例如 Fastmail / Migadu 别名 kb@yourdomain.com) 并在您的家庭服务器或笔记本上运行 IMAP poller,该 poller 下载新邮件并将每封邮件作为一个 Markdown 文件写入您的 vault。在文件名中使用 from 地址前缀,以便检索可以按发件人过滤。AnythingLLM 有原生邮件集成;Obsidian 用户通常自己构建 IMAP poller 或使用 IFTTT / Zapier 替代品如 n8n。
如何在桌面和移动之间同步?
取决于架构。Obsidian 中心型:Obsidian Sync (付费,干净处理二进制索引)、iCloud Drive (免费,仅明文 — 按设备重新索引) 或 Working Copy 上的 Git (免费 + 一次性 Working Copy 费用,仅明文 — 按设备重新索引)。AnythingLLM 中心型:在家庭服务器上以 Docker 运行 AnythingLLM,所有设备通过 LAN 或 Tailscale 连接 — 无需客户端同步。自建 Python:在家庭服务器上构建中央 API 服务;客户端 POST 捕获并 GET 查询。
应该使用一个大 vault 还是按主题拆分?
~50,000 条目以下使用一个 vault。50K 以上按主题拆分 (工作、阅读、项目、个人),原因有二:检索延迟保持在 ~1 秒以下,以及上下文之间的意外交叉泄漏 (例如个人笔记出现在工作查询中) 在大规模时变得可能。早于 50K 拆分为时过早 — 您会失去 PKB 的主要价值之一:跨领域偶然连接。
为了准确度应该多久重新嵌入一次?
永远不要因「准确度漂移」而重新嵌入 — 嵌入不会退化。仅在更改嵌入模型时重新嵌入 (例如从 nomic-embed-text 升级到 mxbai-embed-large 以在技术内容上获得更好的检索)。三种架构都自动处理文件更改时的增量重新嵌入;您不安排它。例外是您控制索引器的自建 Python 技术栈 — 在那里,基于 watchdog 的保存时增量重新嵌入是标准做法。
我可以对知识库进行版本控制吗?
可以,对明文内容 (Markdown vault → Git 仓库,本地 + GitHub / Gitea private)。将二进制索引文件夹 (.smart-env/、vector_store/、ChromaDB 持久化目录) 添加到 .gitignore — 它们使历史膨胀并导致合并冲突。Git 提供每条笔记的版本历史;vault 快照 (Time Machine、restic) 提供整个系统回滚。两层都要,而不是二选一。
如何在此系统中处理 PDF?
Obsidian 中心型:将 PDF 与 Markdown 笔记一起存储;Smart Connections 不直接嵌入 PDF 内容 — 先提取文本 (例如通过 PDF++ 插件或在每个 PDF 旁边写入 Markdown 摘要的预处理脚本)。AnythingLLM 中心型:将 PDF 直接拖入工作区;AnythingLLM 自动处理 PDF 解析和分块。自建 Python:在摄取管道中使用 pypdf 或 pdfplumber 提取文本,然后嵌入提取的文本。AnythingLLM 是 PDF 重度归档摩擦最小的选项。
我可以选择性共享 KB 的部分吗?
可以,但从第一天就为此设计。使用子 vault (Obsidian) 或工作区 (AnythingLLM) 将「可共享」和「私有」内容保留在分离的存储中。一次性共享时,构建一个带标签导出脚本,按标签 (例如 #shareable) 提取条目到一个可移植 Markdown 包中。不要共享整个 vault — 大多数本地 AI PKB 积累不应离开本地技术栈的敏感条目 (医疗、财务、个人通信)。
最佳备份策略是什么?
三层:(1) 每 24 小时文件系统快照 (Time Machine / restic) 加异地副本 (Backblaze / rsync.net);(2) 明文内容的 Git 历史用于每条笔记版本恢复;(3) 嵌入 + 元数据的季度导出作为快速重建路径。每季度测试一次恢复 — 「我能在不到 2 小时内在新笔记本上重建我的 vault 吗?」 第一次恢复测试通常会揭示三层中有一层被错误配置。
如何迁移到新计算机?
恢复 vault 快照 → 安装 Ollama 并拉取相同模型 → 安装 Obsidian / AnythingLLM / 您的自建 Python 技术栈 → 重启嵌入索引器。使用 Obsidian Sync 或自托管 AnythingLLM,迁移就是「安装客户端并登录」 — 无需手动恢复。否则,10K 条目 vault 大约需要 ~30 分钟,50K 大约 ~2 小时,如果您跳过了嵌入导出步骤,100K 以上需要一夜。