检索为什么比重新读一遍便宜
一、上周那家机构说了什么
投研工作里有一类问题出现得特别频繁：上周那家机构对某个行业的看法是什么，上个月那篇报告里那个判断的前提条件是怎么写的，三个月前自己写过的那段结论，为什么当时是那么想的。
这类问题的共同点是，答案确实存在，而且是自己亲手存下来的。不在网上，不用问别人，就在自己的资料里。难的是找。
过去找一份研报，路径大致是清楚的：打开文件夹，按机构名进去，按日期翻，找到文件名，打开，搜关键词。这个过程在文件只有几十份的时候不算什么，到了几千份，翻文件夹本身就变成一项工作。更麻烦的是，很多时候你并不记得是哪家机构、哪一天，只记得那句话长什么样。文件名帮不上忙。
于是很自然的想法是，把这些材料交给模型，直接问它。这个做法我试过，也很快就放弃了。原因不在于模型不够聪明，而在于每次提问都要把材料重新送进去一遍，而材料是几千万字的量级。这不是慢一点的问题，是这件事根本不成立。
后来想明白了一件事：研究员的长期记忆不该放在模型的权重里，也不该指望模型在对话里记住，它应该是一个能被秒级检索的本地文档库。问的是「上周那家机构怎么说的」，而不是「AI 你记得吗」。
二、三份语料，一个入口
现在这个库里有三份语料，都是平时真的会去查的东西。
AI 速递的正文，从第一期开始按期刊存，含精选与报告两部分，184 篇，六十余万字。
海外买方的官网洞察，整篇文字版，854 篇，一千三百多万字。
海外卖方研报的整册解析，303 篇，九百多万字。
合起来 1341 篇、约 2390 万字。这个体量放在任何一个搜索框里都够用，放在对话上下文里则完全不可能。
做法并不复杂。三份语料各自留在原来的目录里，一页不动，索引单独建在本机。检索时用一个统一的入口，前面加来源前缀区分：速递是 ai-digest，买方是 overseas-buy，卖方是 overseas-sell。想只在卖方里找，就限定前缀；不确定在哪一边，就不限定。
这件事真正的成本不在技术，在取舍。最省事的做法是把三份语料都搬进同一个目录，但那样就多出一份需要同步的真身，而同步迟早会出错。索引是派生物，扔了可以重建；原始语料是真身，动了就没法还原。让每个目录继续做它自己的真身，检索层只读不搬，这条边界定下来之后，后面的维护量小了一个量级。
三、索引为什么必须在本机
有一个决定看起来不合常理：内容放在共享盘上，索引却放在每台机器自己的目录里。
理由很具体。这些语料在共享盘上，Windows 那台机器和 Ubuntu 容器看到的是同一份内容，这一点必须保留——在 Windows 上整理文件是日常操作，总不能为了检索方便就放弃。但索引库不能跟着放上去。
起初我确实把索引放在了共享盘，结果是写不进去。共享盘走的是网络文件系统，多进程写同一个数据库文件时会被锁住，报的错是 database is locked。这个问题不是调参数能解决的，它来自网络文件系统本身的锁语义，而检索库恰恰是一个持续被写的东西。
反过来想，索引放在本机完全没有代价。索引是内容的派生物，同一份内容在任何一台机器上重建，结果都一样。既然如此，真身放在共享盘上供人使用，派生物各自留一份在本机，两边互不牵制。容器重建了，索引没了，重跑一遍就是；共享盘上的内容一个字节都不用动。
四、五分钟到一分钟
索引需要跟着新内容更新，否则查得到三个月前，查不到昨天。
最直接的做法是定时全量重建。三份语料加起来两千多万字，重建一次要几分钟。如果每隔几分钟重建一次，那台机器基本上一直在做索引。而新内容每天只增加几篇，两千多万字里发生变化的部分，一天可能只有几万字——全量重建是在反复处理 99% 没有变的东西。
现在的做法是增量。每隔一分钟扫一遍目录，比对上一次的记录，只处理新增和修改过的文件，然后把变更并进索引。守护进程的心跳和上一次的统计都落在本机的一个状态文件里，随时能看到「上一轮加了什么、改了什么、一共多少篇」。
判据也简单：全量重建是分钟级，增量是秒级甚至更快。能不能做到增量，决定了这个库是「每天更新一次」还是「随时可查」。后者才真正改变工作方式——刚看完一篇报告，几分钟后它就在库里了。
五、一次查询有多便宜
回到开头那个问题：检索为什么比重新读一遍便宜。
把整个库重读一遍，是 2390 万字。按中文大致的换算，这是一千六百万 token 量级的输入。这个数字的意义不在于贵，而在于它没法作为日常操作——每问一个问题就重读一遍，这件事在物理上就不成立。
一次检索返回的，是命中的那几篇的摘要和片段。实测下来，七条命中加起来不到三千字，占整个库的万分之一点二。
时间上的差别更直观。从敲下关键词到出结果，五十到八十毫秒，这个数字里还包含了启动一次进程的开销，也就是说人眼感觉不到等待。
但这里要克制一点。检索便宜，指的只是取回材料这一步便宜，不是说检索的结果可以直接当结论用。它解决的是「材料在哪」，不解决「材料说明什么」。这两件事不该混在一起——把前者做成机械的、快的、可重复的，恰恰是为了把时间留给后者。
六、便宜但会漏
这个方案有明显的不便宜的地方，得说清楚。
第一是它只认字面。搜「联邦基金」，能命中写了这四个字的地方；如果某篇报告通篇讲的是政策利率路径，一次都没提这个短语，它就找不到。字面匹配的优点是可控——你大概知道为什么命中，也知道为什么没命中；缺点是它不会替你想到换个说法。
第二是命中之后还要自己判断。同一个短语在这三份语料里的语境差别很大，买方讲的是配置，卖方讲的是定价，速递讲的是行业动态。检索把材料摆出来，判断仍然是人的事。
第三是它只覆盖已经入库的东西。没有喂进去的材料，检索里从来不存在，而且它不会提醒你「这里少了一块」。一个检索库最大的风险不是搜不到，是让人以为已经搜全了。所以每次拿检索结果下判断之前，得清楚这份语料覆盖到什么范围、覆盖到哪一天。
七、这套东西真正改变的事
用了一段时间之后，发生变化的地方和我最初预想的不太一样。
我原本以为价值在于省时间。省时间确实是真的，但真正被改变的是另一件事：因为查证变便宜了，人就更愿意去查。
以前写一段话，如果记不清某家机构原话怎么说的，很容易凭印象写个大概，因为翻文件夹的成本比模糊处理的成本高。现在这个成本低到可以忽略，模糊处理的理由就没了。检索降低的不只是查找成本，还有「不去核实」的借口。
另一个变化是，这些材料第一次变得可以累积。以前一份报告读完也就读完了，用不上第二次；现在它进了库，几个月后写另一篇东西时会被翻出来。存储的成本几乎为零，取用的成本也几乎为零，积累这件事才真正成立。
至于「AI 能不能记住我的资料」这个问题，我的答案是：不该让它记，该让它查。记忆是不可控的，你不知道它记住了什么、忘了什么、记错了什么；检索是可控的，查得到就是查得到，查不到就是查不到，而且随时可以复核。
把长期记忆从模型里搬出来，放进一个能被秒级检索的本地文档库，这件事做完之后，模型在对话里记不记得住，就不再重要了。
文中观点仅为个人实践观察，不构成任何投资建议。