本地知识库

"本地"是三个旋钮，而不是一个开关。

人们说"本地 RAG"时，指的架构可能天差地别。数据一共有三个可能离开你机器的地方，每一个都是一次独立的选择：

• 文档存放在哪里。在你的磁盘上、你的 NAS 上、你的 VPC 里——还是上传到某个厂商的摄取 API。合规要求真正关心的，通常就是这个旋钮。
• 嵌入在哪里计算。本地嵌入模型，还是托管的 embeddings 接口。请注意：调用托管嵌入服务，意味着建索引时每份文档的每一个分块都被发给了第三方——一个装满了别人 API 算出来的向量的"本地向量数据库"，语料其实早就泄露完了。
• 生成在哪里发生。本地小模型，还是前沿模型 API。多数生产环境中的"本地知识库"，前两个旋钮在本地、第三个在远端——因为被检索出来的那几段是语料中很小、且可以人工过目的一部分，而生成环节的质量差距却很大。

五个阶段，以及自己扛起来之后会变的东西。

每一个知识库——无论本地还是托管——都是同一条流水线。放到本地自己做，改变的是每个阶段的失败模式，而不是阶段本身：

• 摄取与解析。把 PDF、wiki、工单和代码变成文本。在本地，这是质量流失最多的地方：托管平台会附带一个调校过的版面解析器，而你用朴素 PDF 抽取器跑的第一版，会悄无声息地把表格搅成一锅词汤。
• 分块。切成可检索的单元。参见分块与向量搜索——规则不因本地而改变，只是没人替你调参了。
• 嵌入。用一个由你来锁版本、由你来托管、终究也要由你来升级的模型，把分块转成向量。
• 索引。把向量连同元数据存进可查询的东西里。在单机上，这往往是一个文件而不是一个服务——LanceDB、Chroma 这类嵌入式存储，或者一个 SQLite 扩展，而不是一个集群。
• 检索。给定一个问题，返回值得放进上下文的那几段。关键词加向量的混合检索再接一个重排序器，是生产环境的默认配置，而这恰恰是本地方案最常投入不足的一环。

有一条结论值得单独成句，因为它总在最不合时宜的时刻让人吃惊：更换嵌入模型会让整个索引作废。两个不同模型产出的向量之间不可比较，所以一次升级意味着把你存过的每一个分块重新嵌入一遍。请把它当成一项周期性成本来预算，而不是一次性迁移。

本地究竟买到了什么，又究竟付出了什么。

支持本地的理由比"隐私"这句口号所暗示的更有力，而它的代价也比"你得自己运维"更具体。

• 买到：可以证明的数据驻留。不是厂商关于其次级处理方的书面保证，而是一条网络边界。对受监管的语料和对源代码而言，这常常就是全部理由。
• 买到：没有按次计费的检索账单。检索成本坍缩成电费。这一点在智能体循环里比在只搜一次的聊天机器人里重要得多——一个任务可能触发十几次搜索。
• 买到：不必往返上传的新鲜度。为本地磁盘上一个变更过的文件重建索引，是毫秒级的事。它也是唯一能在离线或断续联网机器上运转的架构。
• 付出：召回归你负责。当智能体回答"我找不到"而那份文档明明存在时，没有别人会来替你诊断分块策略。你需要一个评测集——哪怕只有二十组"问题—应命中文档"配对——否则你就是在盲飞。
• 付出：索引维护是实打实的活儿。删除、重命名、失效条目、损坏文件，以及模型升级时的重新嵌入。一个没人维护的知识库，会退化成一个自信满满地提供去年答案的信源。
• 付出：硬件，以及一道规模天花板。笔记本上的嵌入式存储撑到数百万向量确实没问题，但撑不住一百个并发用户；而从"一个文件"迁移到"一个服务"，等于把检索层重写一遍。

先问问你到底需不需要索引。

关于 2026 年的本地知识库，最有用的一条认知是：领先的编程智能体基本上不再建它了。Claude Code、Cursor 与 Codex 是用 glob、grep 和 read 在源码树上检索的，而不是靠本地向量索引——精确匹配、无索引可建、不必与正被编辑的文件保持同步，也完全没有嵌入这一步。当语料就在磁盘上、是文本、而智能体又负担得起几次工具调用时，让模型直接搜索往往比上面那条流水线既更好又更简单。

一条粗略的分界线：

• 语料在本地、有结构、小到可以逐层浏览时——代码、配置、一个文档目录——并且精确标识符比同义改写更重要时，跳过索引。
• 语料庞大、以散文为主、按语义而非按字符串来查询时，建索引：支持工单历史、研究论文、政策文件、合同，以及任何用户的措辞永远不会与文档措辞重合的场景。
• 多数真实系统两者都要——关键词搜索与向量搜索会在不同的查询上失手，这正是混合检索成为默认选择的原因。

本地优先检索深入解析会把整条搭建路径走完，包括模型选择与硬件预算；选向量数据库覆盖存储选型；而智能体记忆处理的是相邻的另一个问题——智能体该记住关于它自己的什么，而不是关于你文档的什么。