最近做了个小工具：把我攒了几年、按字节算快 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 秒内出结果，准确率主观评价八成以上。最

  • 情报分类：项目价值、技术价值
  • 命中依据：本地截图搜索引擎的实践经验与踩坑总结，有技术价值
  • 来源：服务器 / V2EX
  • 原作者：MaskerPRC
  • 发布时间：2026/9/11 21:02:56