本地优先的 AI：当我决定把“第二大脑”留在自己电脑里

上半年我做了很多 LLM 应用的工程化：工具、评测、观测、SLO。

但越做越会遇到一个很人类的问题：

我到底愿不愿意把自己的笔记、工作文档、碎碎念，全部交给云端？

答案并不总是“愿意”。

所以 7 月我做了一个决定：把“第二大脑”尽量留在本地。不是反云端，而是反“默认上传”。

这篇文章写一个偏个人但很工程的实践：本地优先的知识检索与问答，怎么做才不鸡肋。

1. 为什么今年本地化突然又热了

如果你留意今年的 AI 讨论，会发现一个变化：

一边是更强的推理与更长的上下文
另一边是更强的隐私意识与更现实的成本

很多人开始接受一个朴素结论：

不是所有数据都需要上云，尤其是你的“私域知识”。

再加上本地推理与本地向量化的门槛持续降低，本地优先开始变得“不是极客玩具”。

2. 我给本地系统定的三个硬指标

离线可用：断网仍能检索与问答
可追溯：答案必须能指回原文片段
成本可控：CPU 也能跑，延迟可接受

如果做不到这三点，本地化就会沦为“情怀项目”。

3. 架构很简单：索引、检索、问答

flowchart LR
  A[Markdown 笔记] --> B[分段与清洗]
  B --> C[向量化]
  B --> D[BM25]
  C --> E[向量索引]
  D --> F[关键字索引]
  E --> G[混合召回/重排]
  F --> G
  G --> H[带引用的回答]

我把它拆成三个可替换模块：

向量化模型：能换（小模型优先）
索引引擎：能换（FAISS/SQLite/其他）
重排策略：能换（RRF/轻量 reranker）

这样做的好处是：当你未来想升级某个环节，不会推倒重来。

4. 最容易被忽略的部分：分段（Chunking）

本地化做不起来，很多时候不是模型不行，是分段太烂。

我踩过两个坑：

按固定字数硬切：上下文断裂，命中一段看不懂
切得太大：检索命中率下降，回答引用笼统

后来我用的策略是：

按标题层级切（H1/H2/H3）
段落太短就合并
段落太长就按自然段再切
目标把片段控制在“200~400 字左右”

它不优雅，但很实用。

5. 本地问答的“体验关键”：引用与链接

我不追求它像 ChatGPT 那样能聊。

我追求的是：它像一个靠谱的检索工具，答案只是引导你回到笔记。

所以输出我强制带两样东西：

命中文档路径
命中片段原文

当你能一键跳回原文，很多“幻觉焦虑”会自然消失。

6. 我对云端的态度：该用就用，但别默认

本地优先不代表拒绝云端。

我现在的策略是分层：

私密笔记：只本地
公开资料：可以云端检索
需要强推理的少量问题：手动选择云端模型

这更像一个“默认最小暴露”的原则。

结语

本地优先的 AI 没有那么酷，它解决的也不是“更聪明”，而是“更安心”。

当你的知识库不必离开电脑，你会更愿意记下真实想法、半成品灵感、甚至那些不体面的草稿。

而这些，才是第二大脑最有价值的部分。

（下一篇我会把这套思路落到 Obsidian 的本地向量检索上，把它变成可复用的工具链。）

琅琊苑