DigUp vs Milvus vs 传统搜索引擎：检索赛道来了个4天1146星的新人

【免费下载链接】DigUpSearch your computer by what's in your files: photos, PDFs, documents, recordings, videos and code. On-device on Mac, Windows and Linux, built on Google DeepMind's EmbeddingGemma 2.项目地址: https://gitcode.com/gh_mirrors/di/DigUp

过去几年，凡是聊到"检索"，几乎绕不开两个固定答案：要么是 Elasticsearch 这类建立在倒排索引上的传统搜索引擎，要么是 Milvus 这类专门为向量而生的数据库。前者的核心是关键词与 BM25 相关性打分，后者的核心是海量向量上的近似最近邻。它们都解决了一个共同的问题——"给我一个能扛住规模的服务"。

但 2026 年 10 月，一个叫 DigUp 的开源项目用 4 天时间拿下了 1146 颗星，把"检索"重新拉回到了一个被大厂方案长期忽略的坐标上：不建集群、不接 GPU 卡、不写一行运维配置，而是在你自己的 Mac 上，按文件"里面有什么"来搜索。它不是又一个向量数据库，也不是又一个搜索引擎，而是一个把多模态语义模型塞进单机索引管线的端到端产品。

这篇文章不打算给你"谁比谁强"的结论，而是把 DigUp、Milvus、传统搜索引擎放在同一条轴线上，分别拆开它们的定位、成本、场景边界，最后给出什么时候该关注 DigUp 的判断。所有技术细节均来自仓库源码，可以对照验证。

先对齐坐标：三种"检索"根本不是一回事

很多选型争论之所以无效，是因为把三个不同层面的东西放在同一个词"搜索"下比较。

• DigUp是一个运行在 Apple Silicon Mac 上的桌面应用：你选好文件夹，它把图片、PDF、录音、视频、代码全部读取并向量化，存在本地 SQLite 里；之后按下热键⇧⌘Space，用自然语言描述你要找的东西。它解决的是"我电脑里的这个文件，内容到底是什么"。
• Milvus是一个分布式向量数据库：它不生产向量，也不理解文件内容，而是提供一个可以横向扩展、支持 GPU 加速、能扛住亿级向量检索的服务层。它解决的是"海量向量怎么被高速查询"。
• 传统搜索引擎（这里指 Elasticsearch 一类的通用引擎，也包括 macOS 自带的 Spotlight）以倒排索引 + 词项匹配为核心。它们解决的是"文本里有没有这些词"。

这三者的技术栈几乎不重叠：DigUp 的索引核心是"一个 SQLite 文件 + 内存暴力扫描"，Milvus 的核心是分布式分片与 ANN 索引，Elasticsearch 的核心是 Lucene 的倒排表与 BM25。把它们放在一起比较，比的不是"谁检索得更快"，而是"你的检索问题到底长什么样"。

定位差异：通用检索底座 vs 垂直场景挖掘

Milvus 和 Elasticsearch 都是通用底座——你自己负责把数据喂进去、把 embedding 管线搭起来、把查询服务化。DigUp 恰恰相反，它把检索的每一个环节都做成了固定的垂直闭环：爬取、抽取、向量化、索引、查询、定位、打开，全部内置。

看 README.md 的开头就能感受到这种差异：DigUp 的卖点是一组"能定位到具体位置"的检索——"zebra in a video" 直接打开视频里斑马出现的那一帧，"where they talk about sleep" 跳到播客的那一分钟，"the clause about pets in the lease" 定位到 PDF 的某一页并标出关键词。

这种细粒度定位能力，是传统搜索引擎和向量数据库都不提供的，也是 DigUp 工程上最花心思的地方。在 Sources/DigUpKit/Model.swift 中可以看到，一个文件被切成多种SegmentKind：image、ocr、page、page_image、chunk、audio、frame、lines、cells。音频按 30 秒窗口、步长 25 秒切片（audioWindow = 30.0、audioHop = 25.0），视频每隔几秒抽一帧，PDF 按页抽取，代码按"行段"抽取。每个片段都带loc/locEnd，这就是"跳到那一分钟、那一页、那一行"的实现基础：

• Sources/DigUpKit/MediaExtractors.swift 用 AVFoundation 把音轨解码成 16kHz 单声道，按窗口切 WAV 分片，并跳过静音段（RMS 低于 −50dBFS 的不值得占用一个向量）；
• Sources/DigUpKit/Extractors.swift 用 PDFKit 逐页读 PDF，文字不足的页渲染成图片走视觉编码器，扫描件交给 Apple Vision OCR；
• Sources/DigUpKit/Crawler.swift 只读取元数据，跳过node_modules、数据集文件夹、密钥文件、仅存于 iCloud 的占位文件，连"代码项目里只索引截图"这种细节都考虑到了。

检索本身也是混合的。核心在 Sources/DigUpKit/Searcher.swift：语义（向量）+ 关键词（FTS5）双通道。语义侧用 EmbeddingGemma 2 把每条查询嵌入 768 维空间，和所有片段向量做余弦相似度，并只保留在统计分布上显著突出的结果（zGate = 2.0）；关键词侧用 SQLite FTS5 做词项匹配，为精确串（发票号、错误码、人名）兜底——因为"任何向量都装不下一个精确的发票号"（README 原文）。两个通道的得分在 Searcher.swift 中融合，代码索引里还专门降低了词权重（codeWordWeight = 1.0vswordWeight = 2.0），因为"app、running、location"这类词在代码里到处都是。

EmbeddingGemma 2 是多模态模型，把文本、图片、音频、视频放进同一个向量空间，这意味着一次查询可以同时给视频帧、PDF 页、录音片段排序——README 称之为"one query can rank a video frame against a PDF page"。这正好命中垂直场景的痛点：你的文件本来就是异构的，你要的答案可能藏在任意一种文件里。Milvus 和 Elasticsearch 都需要你先决定"这一路数据存什么、怎么搜"，而 DigUp 把"异构文件 + 一个自然语言问题"做成了默认形态。

上手成本与部署形态：三种完全不同的账本

这部分差异最直观，也最容易被忽视。

Milvus 的账本是服务化：需要规划集群、GPU 资源、embedding 生产管线、索引构建任务和查询网关。它解决的是"我自己做一个检索服务"的工程问题，意味着你要先有数据工程师、有部署环境、有持续运维。这是分布式系统该有的复杂度，但如果你只有"一台 Mac 上的两万个文件"，这个复杂度就是纯浪费。

传统搜索引擎的账本同样在服务侧：Elasticsearch 要管分片、副本、分词器、mapping，还要处理"搜不到、搜不准、搜太慢"三件套。Spotlight 倒是零成本，但它只按文件名、元数据和全文文本匹配，看不懂图片内容、听不见录音说了什么、不能按"含义"搜索——这正是 DigUp 的 FAQ 里明确回答过的差异（README.md）。

DigUp 的账本是一台 Mac：从 Release 下载 DMG 或brew install --cask arahim3/tap/digup，首次启动下载一次模型（865 MB），选好文件夹，之后就是热键即搜。索引结构是单个 SQLite 文件（index.sqlite），向量以 float16 存进同一个库。这一点在 Sources/DigUpKit/IndexStore.swift 里被写成了明确的工程判断：

Vectors live in the same database as everything else... At this scale (~20k vectors, ~30 MB) brute-force search over an in-memory copy is a few milliseconds;no vector database needed.

这是全文最值得品的一句：在个人文件的量级上，暴力扫描比任何向量索引都快，而且省掉了分布式系统的一切。向量矩阵用mmap匿名映射（Sources/DigUpKit/Vectors.swift），float16 存储把 7 万条向量的内存占用从 215 MB 压到 108 MB，释放时munmap立刻归还内存，不会像 malloc 那样把大块留在进程足迹里。索引的占用也被量化过：整个 llama.cpp 源码库的代码索引约 130 MB、耗时约 20 分钟（README 实测数据）。

工程上还有一处值得学习：DigUp 对"向量版本一致性"做了自动化保障。Tests/LlamaRuntimeTests/ReferenceVectorTests.swift 保存了一份固定输入的参考向量（vectors.json），要求当前 llama.cpp 构建产出的向量与参考余弦相似度 ≥ 0.999；每次升级 llama.cpp 都必须先过这关，否则就保留旧版本或提升vectorVersion并让所有索引重建。索引指纹（IndexOptions.fingerprint）记录模型与参数，任何影响向量的改动都会触发--reindex。这种"发布前用回归向量锁住运行时"的做法，比大多数服务化检索团队都要严谨。

各自的场景边界：别拿错工具

把三者摆到具体场景里，边界就非常清晰。

DigUp 的适用场景：个人或小团队的本机文件检索，特征是"文件多模态（截图、录音、PDF 扫描件、视频、代码）、隐私敏感、要求离线、要求跨语言"。README 里给出的例子已经点透了它的能力边界——英文查询能找到孟加拉语、阿拉伯语写的笔记（模型支持 100+ 语言），精确串按原文匹配（截图文字走 Apple Vision OCR，支持约 25 种语言）。evals 目录下的评测也印证了这一点：evals/synthetic.json 里有 "a penguin" 这种语义查询（预期命中视频中 0-6 秒的片段），evals/multilingual.json 里有孟加拉语与阿拉伯语的跨语言查询。它的边界同样明确：macOS-only、Apple Silicon-only（macOS 14+）、单机、单用户，不做服务化 API，不横向扩展，量级天花板在几十万向量这个区间。

Milvus 的适用场景：面向产品的规模化检索服务——推荐召回、RAG 的知识库底座、人脸/商品图库去重、上亿向量下的相似性搜索。团队要建检索服务、要水平扩展、要 GPU 加速、要和在线业务集成时，Milvus 这类向量数据库是合理选择。但它不解决"数据从哪来、怎么理解内容"，embedding 管线、数据接入、语义质量都是你自己的事。

传统搜索引擎的适用场景：以文本为主的企业内部检索、日志分析、Web 搜索、需要精确词项匹配和复杂过滤条件的查询。Elasticsearch 生态成熟、周边丰富，但在"图片内容、语音内容、跨模态语义"上是结构性缺失——不是不好用，是问题模型根本不同。

一句话总结边界：DigUp 管"这台电脑里有什么"，Milvus 管"这个服务怎么扛住亿级查询"，Elasticsearch 管"这批文本里的词怎么被快速命中"。前者的价值在语义理解与端到端体验，后两者的价值在规模与服务化。

给选型者的结论：什么时候该关注 DigUp

如果你正在搭建一个检索服务，Milvus 和 Elasticsearch 仍然是正确方向，DigUp 不是它们的替代品。但如果你是下面任何一种人，DigUp 值得立刻关注：

• 你的检索需求发生在单台机器上：大量截图、PDF 扫描件、录音、视频散落在硬盘里，"文件名叫什么"根本帮不上忙，你需要按内容找人——DigUp 是这个问题的当下最优解之一；
• 你极度在意隐私：DigUp 只在下载模型和每日更新检查时联网，无账号、无遥测（README 明确声明），全部索引和查询都在本机完成；
• 你需要跨语言检索：100+ 语言的语义模型 + 跨语言查询，是传统全文索引做不到的；
• 你想做代码语义搜索：code:前缀 + 独立代码索引（code.sqlite），按"这段代码是干什么的"找函数，并直接定位到编辑器行号，这是 ripgrep 和 IDE 内搜索之外的第三种能力；
• 你关心小模型能干什么：740M 参数、Apache 2.0 的 EmbeddingGemma 2 在笔记本 GPU 上跑多模态检索，本身就是"端侧 AI"的一个高完成度样本——读完 Sources/DigUpKit 的实现（SQLite 单文件索引、fp16 暴力扫描、混合检索融合、参考向量回归测试），你会明白 1146 颗星不是营销出来的。

反过来，如果你需要多用户、需要水平扩展、需要把检索封装成在线 API，请继续用向量数据库和搜索引擎——DigUp 的设计目标里根本没有这些词。

检索赛道的这次"新人入场"，真正的启示不是"个人文件检索居然能这么做"，而是：当模型足够小、足够开放、足够多模态时，"检索"这件事的最小可行单位不再是一个集群，而是一台笔记本加一个 SQLite 文件。DigUp 用 4 天 1146 星证明了这条路成立，剩下的，是看这个生态能走多远。

【免费下载链接】DigUpSearch your computer by what's in your files: photos, PDFs, documents, recordings, videos and code. On-device on Mac, Windows and Linux, built on Google DeepMind's EmbeddingGemma 2.项目地址: https://gitcode.com/gh_mirrors/di/DigUp