又一个被小米套路到的😓，不是一千亿 token ，是一千亿 credits 。每个 token 现在消耗几百个 credits 了。

@sillydaddy #4 上面的例子算错了😓，10 轮命中率=550000/650000=85%。

一般用 claude code 这类 agent ，缓存会占比很大，一般都会在 90%以上。因为它要经历 thinking..action..thinking..action 这样很多轮，轮次越多，缓存占比越大，因为每一轮都会把之前轮的那些输入喂给大模型，这些就是缓存。

假如每轮新输入 10000 个 token ，那么 10 轮后，未缓存的就是 100000 个 token ，缓存的呢？ 10000+20000+30000+...+100000=5550000 ，缓存命中率=5550000/5650000=98%

实际要考虑上下文超出会压缩，导致原来的缓存失效。但缓存命中率只跟 Agent 工具的用法有关系，Agent 模式一般都能到 90%以上，除非你特意优化 Agent 的流程，减少缓存的占用，比如使用定制的流程去处理，例如那些 AI 视频生成管线，把流程前一环节的输出经过筛选，作为下一环节 API 调用的输入，而不是堆积信息，这样会减少缓存。

这是我用 claude code 调用小米 token plan 处理文本提取信息，这个场景下的消耗（缓存占比非常大，命中率 97%，这种情况下，可用量确实提高了 10 倍左右）：
https://v2ex.com/t/1215750#r_17686925

不过，小米套路多倒是真的。

@LittleTree 可能是国内国外的不匹配？我的 token plan 是走的新加坡。

谢谢 OP ，麻烦填我的吧，早知道调价这么低，就不那么早用完了。邀请码：A2ZFD2 。注册： https://platform.xiaomimimo.com?ref=A2ZFD2 （注册后点控制台左下方入口填入，体验金 40 天有效）

小米套路真多：先 0 元赠送，再趁剩 3~4 天时，重置额度，让人感激。再趁热乎把价格调到和 DeepSeek 一样。还有 7 亿->380 亿 credits 的营销噱头，你直接把缓存 token 的价格调降到 0.02credit 不就行了吗。

确实是 5~8 倍的提升！看图：
https://i.v2ex.co/yOG9s3dCl.jpeg

token plan 的话，使用 mimo-v2.5 ，把现在的 380 亿，除以 100Credits/token ，想当于原来的 3.8 亿 Credits 。

未缓存输入 = 640 万
+ 缓存输入折合 = 200 万（ 22436 万/120 倍）
+ 输出折合 = 140 万（ 73 万*2 倍）
-----
总消耗 = 1000 万，占 3.8 亿 token 的 1/38 。

而按旧方式，上图的 2.3 亿 credits ，占了赠送的 7 亿 token 的 1/3 。
等于用量提升了 12 倍（当然，我的缓存命中率比较高，占 97% 。但一般 Agent 使用场景，缓存输入都是占大头。）

@icew23 #26 而且，即使是建立了结构化信息，仍然要使用 ReACT 模式。比如我提到的标签网络，搜索一个句子，可以转化成搜索多个标签，通过搜索多个标签，找到这些标签关联节点集合，然后对它们取交并差，问题在于，每个标签所关联到的节点集合，都是非常多的，就像向量搜索时匹配到的句段一样。这就让最后的筛选结果，仍然面临 topK 类似的困境。需要由 AI 来 ReACT ，决定是否继续筛选，是否要调整筛选条件。

@icew23 #26 感觉有达成共识了，对于知识库这种，用向量数据库+结构化信息。结构化信息需要 AI 跑一遍来提取。我在那篇笔记标签网络的主题里面，就是在手动建标签网络，现在有了 AI ，跑一遍就可以把标签网络建立起来了。你觉得那篇的想法怎么样？对于这个主题里搜集信息这种一次性的，AI 驱动的 ReACT 模式，应该比较省成本，不用考虑无关的内容。

@PiersSoCool #17 我算了一下，DeepSeek V4 Flash ，百万输入 token 是 1 块钱，我单单 govmap 这个项目就要花费三千块左右。

@Morriaty 太感谢了！看样子最优解就是这个了。我把它作为附言吧，标记为已解决。

这样 token 数量应该是比较少的，配合 DeepSeek 的低缓存价格，完全足够了，token 数量基本取决于未缓存的输入 token ，而这些 token 基本就是那些包含有效信息的文字量，最多增加一个常数倍。

而且这种方式，应该就是向量数据库的最优解了：因为向量数据库只是给出一种渐进的匹配度。不存在机械式的程序可以客观判定的分割线，所以，最终的截止需要由人类来决定，或者由类似于人类理解力的 LLM 来决定。你说的 ReACT 模式，渐进式，恰恰符合这个模式。

@nomagick @sillydaddy #13 当然也不止这一个项目。而且我感觉所有需要从互联网收集、整理信息的，都会遇到类似的需求：不能漏掉关键信息，不能消耗太多 token 。

@nomagick 对了，补充一下这件事的背景，其实我在做一个 govmap 项目，需要搜集国省市县乡的各机构的职责、构成、编制等等：
https://v2ex.com/t/907899#r_12559610

涉及到的文档处理比较多，需要不少的搜索工作量和整理工作量。还是希望能尽量减少一些 token 的消耗。所以，需要一个比较流程化的处理过程，比如搜索、下载、抽取关联片段、提取信息、整理为格式化数据。

@Morriaty 你的意思是不是，让大模型自己根据搜索匹配的过程，来适应性的查找？比如搜索到某些关键字，然后再扩展它的范围？也很道理。因为我的目的就是节省 token ，如果不用读全文，那就满足我的需求了。

@maolon #6 这个把关键词改写成长句的，还是第一次见到，应该是叫 HyDE 吧，还挺神奇的！我感觉挺适合我的需求的，感谢！

@IsaacYoung 感谢分享，里面提到的「父子文档」，其实跟楼上提到的依赖预制的语义结构是一样的。这个依赖条件，其实本身也需要 LLM 的介入，否则只凭借解析文本的结构、网页的结构来确定，并不稳定。

所以，感觉还是需要 LLM 的理解能力来介入，提取多层的抽象信息。但这里有个悖论，如果是整理出的知识，需要多次检索，那 LLM 介入一次，后续多次使用，效率比较高。但如果是我这种，只需要提取一次，那直接让 LLM 提取所需的信息就可以，就没必要再让向量数据库转一次手了。

前者抽取多层抽象信息，感觉跟我之前提到的笔记的网状 tag 系统，不谋而合了： https://v2ex.com/t/825142

@IsaacYoung
@cryptovae
这些方法应该能缓解，但是没有从根儿上解决。比如，如果恰好关键信息不在重叠的 token 里面呢？

关键在于，向量搜索它会漏掉。

如果是人来交互式的查看结果，可以把最匹配的 topK 个，优先展示出来，如果不满意，再动态增加 topK 。
可如果是程序来处理呢？怎么保证不会漏掉呢？

还要不要遵循用户的隐私设置？😂
https://i.v2ex.co/fZDBN5zkl.png

目前已有的理解能力，再加上缺失的持续学习，就是 AGI 了。持续学习是 AGI 缺失的一块拼图。
持续学习的关键是什么呢？ LLM 的上下文已经够大了，但是把上下文当做记忆，总感觉不太对劲。

LLM 的一整个权重，可以看作是一个具大的无状态的函数，类似于函数式编程中的纯函数，里面完全没有任何状态，我们知道，纯函数编程的一个别扭之处是，它的效率很低——最近我用 Cavalry 这个动效制作软件就深有体会，它是纯函数，没有状态，相比之下，Origami Studio 就可以保有状态，后者要比前者方便不少——LLM 把所有的状态，都存放在上下文里面。这种函数与状态分离的模式，会不会就是它效率很低的原因呢？不知道，只是瞎猜的。