ShotFind：用Python搭一个本地截图检索工具，自然语言找图

截图越攒越多，找起来却越来越难

多数人的电脑里都躺着一个叫“截图”或者“Screenshots”的文件夹。日子一长，它就堆成了数字垃圾场：会议白板、报错日志、聊天片段、灵感草图，成千上万张图片挤在一处，文件名清一色是Screenshot_2024-10-25_14-30-01.png一串毫无意义乱码。

想找回上周截的那张带特定代码报错的图，老办法是打开文件夹按时间排序，再一张张缩略图用肉眼扫。记得大概日期还算走运，连时间都忘了，就只能碰运气。

云盘相册倒有人脸识别和场景分类，可把私人工作截图往云端传，隐私上总让人不放心；而且它们一般做不到针对截图内容的细粒度语义搜索，比如“找那张有红色报错信息的图”。

所以我打算用 Python 写个本地跑的截图检索助手，暂定名 ShotFind。目标不复杂：数据不上传，全部本地化，能看懂图片内容，还支持自然语言搜索。

整体架构怎么搭

逻辑本身不复杂，分两步走：先是索引建立（Indexing），再是检索（Retrieval）。

索引这一步，程序遍历指定文件夹，逐张分析图片、提取关键信息，写进本地数据库；检索这一步，用户敲进查询词，系统就在数据库里挑出最相关的图片。

要让程序“看懂图片”，得靠 AI 模型。本地跑性能有限，我选了混合策略：

1. 轻量级 OCR：把图片里的文字抠出来，用于精确匹配。
2. 视觉-语言模型（VLM）：为图片生成自然语言描述，用于语义理解。
3. 向量嵌入（Embedding）：把文本和图片转成向量，再算相似度。

数据最后都落在 SQLite 里。它是单文件数据库，不用另装服务，个人工具用着正合适。

关键技术怎么落地

1. 数据结构化：从像素到字段

原始图片直接塞进数据库并不可取，查询效率会低得离谱。得先把非结构化的图片变成结构化的元数据。

每张截图会生成四个关键字段：

• 标题（Title）：简短概括图片内容，例如“Python 报错 traceback”。
• 摘要（Summary）：细说图片里的视觉元素和文字信息。
• 标签（Tags）：抽出关键实体，如“Python”、“Error”、“Linux”。
• 原文（OCR Text）：识别出图片中的全部文字。

这样结构化之后，检索就灵活多了。标题能搜，全文能搜，也可以让 AI 去理解你含糊的描述。

2. 去重机制：SHA-256 指纹

截图软件误触一下就会攒下一堆重复图，同一张图被存好几遍也不稀奇。为了省空间、也省索引时间，处理之前先算一遍图片文件的 SHA-256 哈希值。数据库里已经有同样的哈希，就直接跳过。做法不复杂，效果却实在，能挡掉大量多余的运算。

3. 模型怎么挑，输出怎么验

本地跑大模型，对机器是有门槛的。想让速度和效果都说得过去，我用的是量化过的多模态模型，比如 Qwen2-VL-7B-Instruct，或者更小的 Phi-3-Vision。这类模型在消费级显卡上能跑，塞给 CPU 也能转起来。

不过 LLM 的输出并不稳定。你让它按 JSON 格式写描述，它可能回你一段闲聊，也可能格式出错。所以输出校验这一步必须做严。

我用的办法是“重试加解析”：

1. 让模型严格按指定的 JSON Schema 输出。
2. 拿到返回的字符串先试着解析。
3. 解析失败或者字段缺了，就自动重试，最多 3 次。
4. 还是不行的话，记一条错误日志、跳过这张图，别让整个程序跟着崩。

后台任务要长时间跑，这种容错处理很关键。

4. 向量检索与混合搜索

只靠关键词匹配，语义上的问题解决不了。举个例子，你搜“代码报错”，图里的文字却是“Exception in thread main”，关键词就对不上了。

这时得靠向量检索。用嵌入模型（比如 bge-m3 或 all-MiniLM-L6-v2）把用户的查询词、图片的摘要和标签都转成向量，再算余弦相似度，找出语义上最接近的图片。

向量检索也有短板：精确匹配可能被忽略。你明明记得图里有“ERROR 500”这个词，向量搜索却可能返回一堆语义相关、但压根没这个词的图。

所以 ShotFind 走的是混合检索：

• 第一阶段，用 SQLite 的 FTS5（全文搜索模块）做关键词匹配，把含确切词汇的图片捞出来。
• 第二阶段，用向量相似度搜索，召回语义相关的图片。
• 融合排序：两路结果合并后按权重重新排。一般给向量匹配更高的权重，用来抓住用户意图，同时保留关键词匹配的精确性。

数据库设计

SQLite 是这个项目的底子。文件路径和哈希值要存，SQLite 的高级特性我们也用上了。

先给 OCR 文本和摘要字段建 FTS5 虚拟表，这比普通的LIKE %keyword%查询快好几个数量级，还支持分词搜索。

再说向量数据怎么放。SQLite 原生不支持向量类型，可以把向量序列化成 BLOB 或 JSON 字符串存进去。检索时把候选向量全读出来，在内存里算相似度。个人用的话，几千张图的规模，这种“暴力计算”毫秒级就能算完，完全可以接受。

要想做更专业的向量管理，也可以接上 sqlite-vss 插件，在 SQLite 内部实现高效的近似最近邻搜索（ANN）。

实际用起来是什么感受

部署好之后，ShotFind 就会在后台盯着你指定的那个截图文件夹。只要里面多了新图片，索引流程就会被自动触发。

搜索入口可以做得简单，命令行工具就行；也可以搭成 Web 界面，用 Streamlit 或 Gradio 都成。

不妨直接敲一句：“找一下昨天那个关于数据库连接超时的截图”。

这句话会被系统拆开解析：时间条件“昨天”被抽出来，语义特征“数据库连接超时”也被抽出来。随后它在向量空间里去找和“database connection timeout”接近的图片摘要，同时把创建时间落在昨天这个范围内的记录筛出来。

几秒过去，屏幕上就冒出最相关的三张图片。你要找的那张就在其中，画面上清清楚楚地显示着Connection refused的红色报错。

这么一通操作，跟在一层层文件夹里翻找相比，体验提升的不止一个维度。

局限和可以改进的地方

话说回来，这工具并不是没有短板。

先看速度。多模态模型推理偏慢，索引一张图可能要几秒到十几秒，具体看硬件。要是手里攒了几万张图片，第一次建索引恐怕得跑一整晚。改进的路子有两条：换成更小的蒸馏模型，或者走异步批量处理。

再看隐私。数据虽然存在本地，可一旦你用在线 API 做视觉理解（图的是更快速度或更好效果），截图内容就会被送到第三方服务器。碰上敏感的工作资料，建议老老实实用本地开源模型。

还有准确率。AI 可能凭空“幻觉”出图里根本没有的内容，也可能把关键细节漏掉。眼下的办法是多字段冗余存储：摘要即使写错了，OCR 提取的原文还在，关键词搜索仍能兜底。

结语

技术不一定非得是高大上的分布式系统或微服务架构。拿 Python 写个小工具，把自己日常生活里真实的痛点解决掉，这同样是编程的乐趣。

ShotFind 的代码逻辑谈不上复杂，可它把 OCR、多模态理解、向量搜索和数据库技术揉在了一起，拿来练手全栈 AI 应用挺合适。

你要是也受够了在几千张截图里大海捞针，不如自己动手试一把。哪怕只做一个简单的 OCR 关键词搜索，数字生活的效率也能提上一大截。

说到底，最好的工具不是最贵的那个，而是你最愿意用的那个。