给几百 G 的本地截图做一个能搜内容的引擎，我踩过的坑

最近做了个小工具：把我攒了几年、按字节算快 1T 的电脑截图（微信聊天截图、网页截图、报错截图、PPT 截图……）做成一个能直接搜内容的引擎。比如搜「上次那个 nginx 502 的报错」，直接把当时那张截图翻出来。

功能听起来不新鲜，但自己动手做一遍，坑比想象的多。这里把踩过的坑记录一下，给同样有这个需求的朋友参考。

坑一：OCR 不是「接个库」那么简单

一开始想当然：截图 → OCR → 存文本 → 搜，完事。实际：

• 中文截图里夹杂的英文报错、路径、代码，混排识别率惨不忍睹。纯中文 OCR 库对 Error: EACCES: permission denied '/var/log/...' 这种行基本全军覆没；


• 后来换成多模型互补：通用 OCR 打底，对识别置信度低的行再走一次视觉模型重读，准确率才到了能用的水平；


• 坐标信息别丢——OCR 返回的文字块位置留着，后面高亮定位全靠它。

坑二：索引体积失控

几个月的截图，全量向量化之后索引文件比截图本体还大。两件事必须做：

• 切分粒度：按文字块切，不要按整张图切。一张 1080p 截图 OCR 出来可能有 40 个块，大部分是时间戳、水印、无关 UI 文字——先过一遍规则过滤（正则 + 长度 + 位置），能砍掉六成索引量；


• 分层检索：先文本关键词粗筛（ SQLite FTS5 就够），命中候选再走向量精排。别一上来就全库 ANN 搜，慢且贵。

坑三：查询理解是最容易被忽略的一环

用户搜「那个 502 」，你拿什么去向量库里匹配？查询改写这层一定要做：

• 把口语查询改写成「可能出现在截图里的文字形态」（比如把「报错」扩写成 error / failed / 错误）；


• 时间限定词（「上个月」「上周」）单独解析出来，转成过滤条件，别混进向量里。

效果

现在 300+ 天的截图，一次搜索 1 秒内出结果，准确率主观评价八成以上。最大的收益是「再也不用翻聊天记录找那张图了」。

最后

这个项目的启发是：RAG 这套东西落到个人小工具上，工程量最大的不是向量检索本身，而是数据清洗和查询理解——七成时间花在了这两块。

代码还在整理，如果大家有兴趣，后续开源出来。也欢迎交流你们做本地内容检索的思路。