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

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

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

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

中文截图里夹杂的英文报错、路径、代码，混排识别率惨不忍睹。纯中文 OCR 库对 Error: EACCES: permission denied '/var/log/...' 这种行基本全军覆没；
后来换成多模型互补：通用 OCR 打底，对识别置信度低的行再走一次视觉模型重读，准确率才到了能用的水平；
坐标信息别丢——OCR 返回的文字块位置留着，后面高亮定位全靠它。

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

切分粒度：按文字块切，不要按整张图切。一张 1080p 截图 OCR 出来可能有 40 个块，大部分是时间戳、水印、无关 UI 文字——先过一遍规则过滤（正则 + 长度 + 位置），能砍掉六成索引量；
分层检索：先文本关键词粗筛（ SQLite FTS5 就够），命中候选再走向量精排。别一上来就全库 ANN 搜，慢且贵。

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

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

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

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