DigUp 拆解：一个 SQLite 文件做完 Mac 本地语义搜索

结论先行

DigUp 是真的，流传的那份介绍基本准确。但有一条决定性限制：它只能在 Apple Silicon 的 Mac 上跑。

我手上只有 Windows，所以这篇不是实测，是核查。我逐项看了仓库元数据、release 列表、README 全文和技术路径，但一行代码没跑过。这个前提先说清楚，后面所有「它怎么样」都是指文档和代码里写了什么，不是我用出来的感受。

核对下来，值得记的有两件事：

它的四个设计选择，跟平台无关，可以直接搬到自己项目里。
顺手撞到的另一个项目 Omni，同类、同样 Mac 独占，但自带 MCP endpoint——这条线索比 DigUp 本身对我更重要。

核对过的事实

项	值
仓库	`ARahim3/DigUp`
星标 / fork	2,909 / 200
协议	MIT
语言	Swift
建库时间	2026-10-08
最新版本	v0.6.1（2026-10-12），安装包 DMG 8.3 MB
安装方式	Releases 下载拖入 Applications，或 `brew install --cask arahim3/tap/digup`
模型	EmbeddingGemma 2（Google DeepMind，2026 年 10 月发布，740M 参数，Apache 2.0，100+ 语言）
首次模型下载	865 MB（文本部分 310 MB + 图像与音频编码器 555 MB），应用本体约 20 MB
系统要求	Apple Silicon + macOS 14 以上
未决问题	56 个 open issues

流传版本里的几个数字都对得上：740M 参数、865 MB 模型、PDF 先处理前 30 页、单文件上限 5000 页、代码搜索默认关闭需手动开启。

一个需要留意的细节：README 的 FAQ 里写明，模型懂 100 多种语言，但精确词匹配对中文、日文、泰文这类不分词的语言不生效——因为不做分词。语义检索照常，但「按原样找到这个字符串」这一路会弱。对中文用户来说，这是这份工具最实际的短板。

为什么现在用不上

README 和 FAQ 各写了一次：Windows 和 Linux 都在路上。也就是还没来。

GitHub 上能搜到两个挂着「Windows 版」名号的仓库，都不是能用的东西：

仓库	状态
`sunboss/DigUp-Windows`	0 星，6 KB，一次提交，无协议
`boss477/digup-windows`	1 星，Rust，2026-10-12 建

一个是空壳，一个是刚起的头。现在在 Windows 上找 DigUp 的替代品，暂时属于白费功夫。

它做对的四件事

这部分是我觉得比工具本身更值钱的地方。

一、不用向量数据库

很多讲语义搜索的文章，第一句就是「你需要 Milvus / Qdrant」。DigUp 的做法相反——整个流水线是这样的：

你的文件夹 ─► 读取器（ImageIO、PDFKit、AVFoundation，截图文字走 Vision）
           ─► EmbeddingGemma 2 跑在 llama.cpp 上（Metal），独立辅助进程，跑完即退
           ─► 一个 SQLite 文件：每张图、每页、每段、每帧、每 30 秒音频一个向量，
              外加一个关键词索引（代码搜索单独一个）
你说的话   ─► 同一个模型的文本部分（约 250 MB，只在搜索时加载）─► 最近向量 + 精确词

所有向量进一个 SQLite 文件，检索时在进程内算相似度。768 维，所有模态共用同一个空间，所以一次查询能把视频帧和 PDF 页面放在一起排序。

对个人规模的知识库（几千到几万条），这完全够用，而且省掉整个运维层。我前两天排除 Milvus、Qdrant 是因为磁盘不够，DigUp 这个例子说明：就算磁盘够，也不一定需要它们。

二、混合检索，不是纯语义

DigUp 同时跑两条路：向量相似度，加关键词精确匹配。

README 里专门解释了为什么要留精确匹配，原话是「没有任何 embedding 能精确装下一个发票号」，所以精确命中的结果会被加权提升。

这一条对个人知识库特别关键。纯语义搜索会把「单笔不超过 100 英镑」这种带数字的规则，搜成一堆意思相近但数字不对的东西。规则、金额、型号、报错码，必须留一条精确匹配的通道。

（结合上面那条中文限制看，这一路在中文内容上本来就是打折的——所以中文知识库更要靠语义检索兜底，同时别指望精确匹配能救。）

三、分块策略按内容类型分别定

不是一刀切：

PDF：先处理前 30 页，其余等第一轮跑完再补，单文件上限 5000 页
音频：模型一次听 30 秒，所以用重叠的 30 秒滑窗，命中后能定位到具体时间点
视频：每隔几秒取一帧，每个镜头取一帧
长文档：同样分两轮，先能搜，再补全

「一次 30 秒、滑窗重叠」这种细节，是真正跑过音频检索才会踩出来的。

四、明确写了不读什么

README 里有一整段在说它不碰什么：

只读你选定的文件夹
永不读 ~/.ssh、密钥、证书、密码文件、隐藏目录、app bundle、缓存
看起来像数据集的文件夹跳过
不下载只存在于 iCloud 的占位文件
只读不改：不改、不移、不上传
代码搜索单独一个索引，永远不出现在其他搜索里，且跳过 git 忽略的内容、第三方代码、生成代码、数据文件、像密钥或密码的东西

一个索引工具愿意把「我保证不读这些」写进文档，这本身就是设计的一部分，不是免责声明。

顺手发现的：Omni 带 MCP

搜 DigUp 的过程中撞到另一个项目：hanxiao/omni-macos（Omni，作者 Han Xiao / Jina AI，320 星，Apache-2.0）。

项	DigUp	Omni
星标	2,909	320
协议	MIT	Apache-2.0
模型	EmbeddingGemma 2	`jina-embeddings-v5-omni`
推理实现	llama.cpp（Metal），辅助进程	MLX-Swift，进程内
平台	Apple Silicon Mac	Apple Silicon Mac
多机	无	Linked Macs：多台 Mac 联邦搜索，TLS 1.3 配对
本地接口	有命令行工具 `digup`	Settings 里可开 HTTP API（`127.0.0.1:51234`），带 MCP endpoint `/mcp`

最后一行是我在意的地方。

我前两天那份「让知识库适时出现」的方案里，最麻烦的一环是触发：怎么让 AI 在用户开口的时候自动想起某条笔记。当时的做法是自己写一个 hook 去 grep 知识库。

如果检索工具本身就暴露 MCP，这个 hook 就不用自己写了。 Omni 就是这个形态——它把自己挂成一个 MCP server，任何支持 MCP 的 agent 都能直接查它，本地 HTTP 接口还能给别的程序用。

代价是它同样只在 Mac 上跑。所以这条线索现在只能先记着。

对我自己的知识库意味着什么

三条可以马上用上、跟平台无关的：

检索层不用上向量数据库。 SQLite 加本地 embedding 够了，磁盘压力小得多——这对只剩 7 GB 的 C 盘是决定性的。
一定要留精确匹配。 知识库里现在就有「单笔不超过 100 英镑」这种带数字的规则，纯语义检索会毁掉它。
把「不读什么」写进约定。 知识库 README 里已经有一条「密码 / API Key / 口令不许放进来」，跟 DigUp 那段是同一个思路，可以再写细一点。

一句话

DigUp 我用不了，因为没有 Mac。但它的四个选择——SQLite 代替向量库、混合检索代替纯语义、分块按内容类型定、明确声明不读什么——都是可以直接搬的。至于 Omni 的 MCP endpoint，先挂在待办上。