Token Saver 能省 99%，也可能漏掉 10%

如果一个扩展告诉你，它能替 Claude 省掉 99% 的 token，先别急着装。

先找它拿计算公式。

这两天刚开源的 Token Saver 就打出了这个数字。它是一个 Claude Desktop 扩展，专门处理本地 PDF。文件不整本塞进对话，而是留在电脑里先检索，只把和问题有关的几段文字送给 Claude。

听起来像又一个「RAG 拯救世界」的故事。

RAG 是 retrieval-augmented generation，检索增强生成。大白话讲，就是别让模型从头啃完一本书，先派个检索器去找相关页，再把找到的证据交给模型作答。

这个思路不新。真正让我觉得有意思的，是 Token Saver 把自己的账算得相当诚实。

它的宣传数字可以到 99%，公开评测里的检索 recall@5 却只有 0.90。前一个数字在说省了多少上下文，后一个数字在说 30 道题里，有 3 道的答案页没进前五。

省下 99%，也可能漏掉 10%。

好家伙，同一个 README 里同时放着增长黑客和工程师。

这两个数字并不互相打脸。它们刚好把上下文工程里最容易被忽略的代价摆到了桌上。你可以少给模型很多材料，但从你决定「哪些材料不用给」的那一刻起，检索器就成了新的瓶颈。

先看 99% 是怎么来的。

一份 PDF 直接丢进 Claude，对话第一轮要读它，后面追问时，整段上下文通常还会跟着请求继续发送。200 页报告里，也许你只问第 47 页的一项退款条款，但模型仍得背着另外 199 页往前走。

Token Saver 把这件事拆成了两层。

本地层负责读文件、切块和检索。Claude 只负责看筛出来的证据、理解问题、组织答案。批量数据待在上下文窗口外，推理需要的少量片段才进来。

这其实很像程序里的虚拟内存。你不会为了改一个数组元素，把整块硬盘一次性搬进内存。需要哪一页，加载哪一页。模型上下文也该这么用。

项目给出的测量结果很直白。约 20 页的文档，相比只粘贴一次，只省 14%。约 80 页能省 78%。到了约 300 页，才会上升到 94%。

99% 出现在另一列。它比较的是多轮对话里每一轮都重复发送整份文档。约 300 页的 PDF 在这个基线下，能从反复背全文变成每轮只送约 2500 token 的片段，比例自然很漂亮。

所以 99% 不是假的，分母比较豪迈。

这块需要说清楚。很多人看到节省 token，会默认等价于省下同样比例的钱或额度。实际账单还包含系统提示词、对话历史、工具定义、模型输出和缓存策略。Token Saver 砍的是 PDF 这一块输入，不是整条请求凭空消失了 99%。

项目自己也承认，15 到 20 页左右才是盈亏平衡点。文档再短，切块、工具调用和返回元数据的开销可能比直接读全文还大。

一张两页发票，别折腾。

一本 300 页尽调报告，来活了。

文档越长、追问轮次越多，本地检索的优势越明显。数据来自项目公开 README。

数字之外，更值得抄的是它的检索流水线。

Token Saver 先把 PDF 切成约 180 个英文单词一块，并保留相邻重叠。重叠很重要。条款如果刚好跨在两个分块边界上，完全硬切会把一个完整意思劈成两半。留一点重叠，代价是索引稍微变大，换来句子不容易断头。

接下来它并行跑两种搜索。

一条是 BM25，可以把它理解成更讲究的关键词匹配。底层用 SQLite FTS5，也就是 SQLite 自带的全文检索能力。合同里问 termination clause，这一路擅长抓准确术语、编号和专有名词。

另一条是本地 embedding。Embedding 是把一段文字变成一串数字，让意思相近但用词不同的句子在向量空间里靠得更近。你问「近几年主营业务赚了多少」，原文可能写 operating earnings in recent years，没有逐词命中，语义检索仍有机会捞到。

两路结果按 0.4 和 0.6 混合，再走拒答门、去重、句子窗口裁剪、token 预算和 Top-K 选择。Top-K 就是只留得分最高的前几块。最终片段带着页码进入 Claude，整份 PDF 不进去。

这套结构有点子牛逼的地方，不是它用了多新的模型。BM25、SQLite、embedding 都是老熟人。它聪明在把概率模型放在需要理解的地方，把确定性代码放在能约束边界的地方。

文件夹白名单限制能读哪些文件，索引和 PDF 留在本机，30 分钟不用就从内存驱逐。Embedding 模型挂了，系统还能降级到纯关键词检索，并明确告诉用户。

工程系统好不好，经常不看顺风时能飞多高，看断一台发动机后会不会直接栽海里。

不过，检索器一接管「让模型看什么」，漏召回就不再是小毛病。

项目的公开评测用了两份真实长文档，一份 213 页的美国最高法院判决，一份 152 页的伯克希尔·哈撒韦 2023 年年报。作者写了 30 道带标准答案页的问题，混合检索有 27 道把答案页放进前五，recall@5 是 0.90。

翻成人话，十道题里大约有一道，正确页没有进入 Claude 能看到的候选片段。

更微妙的是，只跑关键词的版本也是 0.90。

语义检索并没有在总分上赢。两条路线只是漏掉了不同的题。Embedding 擅长抓改写表达，关键词更会盯住分红、判例名这类硬词。混合以后仍然有一道两边都没救回来。

这就是为什么「少给上下文」不能只看压缩率。

上下文压得越狠，模型读得越轻松，检索漏掉关键证据的后果也越重。全文模式至少让正确答案待在某个角落，虽然模型可能遇到 lost in the middle，也就是长上下文中间的信息被忽略。检索模式如果第一关就没捞到，后面的 Claude 再聪明也只能对着空气推理。

空指针。

Token Saver 的 README 在这件事上反而挺讨喜。它保留了旧成绩的更正。早期版本曾报告混合检索 0.97、关键词检索 0.93，后来加入查询停用词、轻量词干化和资格门后，旧数字无法复现。语料文件没有变化，成绩变化来自检索逻辑本身，项目便把当前 0.90 写了上去。

这种「改进了代码，跑分反而掉了」的记录，比一张永远向右上角的曲线可信。

它还公开列出了几个已知限制。

拒答门目前依赖关键词。问题和无关段落碰巧共享几个词，系统可能把无关内容当成证据，这叫 false accept，错误接受。16 份 PDF 放在同一个文件夹时，文件选择器 14 次只选对 12 次。两本接近 1000 页的教材并排放着，只问「那本教材里的巴甫洛夫」，它可能打开错书。把问题改成「我的心理学教材里的巴甫洛夫」，路由才更稳。

页码引用也不是万能保险。

一份判决书里可能同时有多数意见和反对意见。Token Saver 能告诉 Claude 这段话在第几页，却不一定告诉它属于哪位法官、哪一部分论证。页码是真的，归属仍可能错。

这提醒了我一件挺朴素的事。引用不是装饰，它应该成为用户验收结果的接口。

用 Token Saver 问长 PDF，最好把「请引用页码」写进问题。回答涉及合同义务、财务数字或政策条款时，点回原页核对。模型说找不到，别立刻相信文档里没有，先换一个更具体的关键词，或者直接说出文件名和章节。

这不是在照顾一个不够聪明的扩展。

这是在给概率系统补测试。

如果要判断自己该不该装，我会画一条很实际的线。

你的资料经常超过 50 页，而且会围绕同一份文件追问很多轮，Token Saver 值得试。财报、技术手册、合同合集、研究报告都合适。它把重复上下文变成一次本地索引，省 token 只是表面，真正舒服的是对话窗口不再被整本 PDF 塞满。

你的文件只有十来页，直接给 Claude 更省事。你需要全局比较整份文档的修辞、章节结构或多处隐含矛盾，也别过度依赖 Top-K 检索。那类任务需要广视野，把材料切成几个局部答案，可能把跨章节关系一起切没。

你的目录里放了几十份名字相似的 PDF，就把范围缩小。项目的安装指南也要求授权一个专用小文件夹，而不是整个 Documents。这个文件夹既是文件选择边界，也是安全边界。

授权目录既影响文件路由，也是扩展能读取哪些资料的安全边界。图源为项目安装指南。

第三方扩展会显示「未经 Anthropic 验证」，这不是可以顺手点掉的废话。先看仓库，确认授权目录，敏感文件单独放，安装包只从项目 Release 下载。隐私不是文件没上传就自动满分，还要看本地进程能读什么、最终哪些片段会发给云端模型。

说真的，Token Saver 现在还很年轻。仓库刚创建不久，GitHub 关注度很低，30 道评测题还是作者自己写的，尚未经过外部人工验证。把 0.90 当跨领域保证，肯定跑得比代码还快。

但我依然觉得它值得看。

不是因为又多了一个 Claude 扩展，而是它把 context engineering，也就是上下文工程，做成了一个普通人能安装的产品。过去大家喜欢炫上下文窗口有多大，100 万、200 万，恨不得把整个硬盘拖进去。现在工程开始往另一个方向拐。

模型能看多少，不再是唯一问题。

你该让它看多少，才是。

给 Claude 塞整本 PDF，是最省脑子的做法，也常常是最贵的偷懒。Token Saver 没有把这道题彻底解掉，它只是把成本从「模型反复读全文」搬到了「本地检索有没有找对」。

账单变小了，验收责任回到了人手里。

棒棒的。

至少这次，99% 后面那条细细的 10%，没有被藏起来。