北京
去年我在做一个叫GridMind的项目时，踩到了一个坑——所有LangChain教程都假装它不存在。
GridMind是个完全离线的知识库助手，设计目标很极端：没网、没GPU、没云，纯CPU运行，内存不到4GB。灾难场景、偏远地区、僵尸末日……政府不会来的那种情况。但问题来了：知识库是会变的。
大多数RAG演示只给你看快乐路径：切分文档、生成嵌入、存向量、查询，完事。它们悄悄跳过了后半段——源文档被更新、修正、扩充之后怎么办？ naive的做法很痛苦：每次从头重新嵌入全部内容。对GridMind来说，这完全不可接受。
嵌入是昂贵的步骤。在CPU上用nomic-embed-text跑8个生存领域（水、庇护所、医疗、导航等）的完整知识库，需要几分钟。每次改个markdown文件就重跑一遍？门都没有。我需要一种便宜又可靠的方式，准确知道哪些文档自上次索引后变了——只重新嵌入那些。
解决方案是SHA-256作为变更指纹。核心想法很简单，但我没在任何地方看到写清楚，所以展开说说。
嵌入任何文档之前，先计算它的SHA-256哈希，和向量一起存在FAISS元数据里。下次索引时，在调用嵌入模型之前，先哈希当前文件，跟存好的哈希对比。匹配就跳过，没变，不调嵌入；不同就重新嵌入并更新哈希；新文件（没存过哈希）就全新嵌入并存储；文件删了就从索引里清掉向量。
代码很直接：用hashlib读8KB分块，保持内存平稳，大文件也不怕。为什么选SHA-256？我考虑过几个替代方案：文件修改时间戳（mtime）——快，但不可靠，复制文件、跑部署脚本、touch一下都会改mtime，内容没变也要重嵌入；文件大小——更快，更不可靠，10KB文件改一个字符，内容变了大小没变；MD5——其实够用，SHA-256稍慢但微秒级差别，我用它纯粹是习惯，抗碰撞性对这场景过剩，但也没成本。
索引存储结构很简单：FAISS索引旁边放一个JSON清单，记录每个文件路径、哈希、最后嵌入时间、对应的FAISS向量ID。更新流程变成：扫描所有源文件，对每个文件算哈希，查清单，匹配就跳过，不同或新增就重新嵌入并更新清单，最后清理清单里有但文件系统里没了的条目。
效果很实在。首次索引8个生存领域约需4分30秒（纯CPU，nomic-embed-text）。后续更新——比如修正医疗包清单里的一个剂量——只需0.3秒。不是4分钟，是0.3秒。因为只碰了那一个文件。
这方案在资源受限场景下是质变。Raspberry Pi 4上跑，嵌入模型占着CPU时系统本来就卡，能避免无谓调用就是胜利。更隐蔽的好处是幂等性：索引脚本可以随便重跑，不会重复嵌入、不会丢数据、不会搞乱向量库。这在边缘部署里很关键——你可能在野外用太阳能供电的节点上跑，只想确认"系统状态正确"然后断电。
为什么教程不写这个？我猜两个原因。一是大多数RAG demo用OpenAI API，嵌入便宜到没人优化；二是"变更检测"听着像枯燥的工程细节，不像语义搜索那么性感。但真做离线系统时，这就是生死线。
一个意外收获：哈希还成了调试利器。用户报告"这个回答不对"时，我能立刻检查清单，确认他们用的知识库版本，排查是不是旧文件导致的。在没法随时联网拉取最新版的场景里，这很重要。
最后关于FAISS的踩坑。我最初想直接把哈希存FAISS的metadata字段，但FAISS的索引结构对元数据查询不友好——它优化的是向量相似度，不是键值查找。所以清单单独放JSON，FAISS只负责向量。查询时先用清单找相关文件路径，再限制FAISS只搜那些向量的子集。这比全量搜索稍慢，但离线场景数据量可控，权衡值得。
完整代码我放在GridMind仓库里了。如果你也在做边缘RAG，希望省点电、省点时间，这几十行哈希逻辑可能比换个更大的模型更有价值。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
