DuckDB 正式将 AI 向量检索纳入一等公民

Lance 扩展让 DuckDB 的 SQL 工作流从“分析表”自然延伸到“检索表”，向量、全文、图片字节和标量元数据可以在同一套数据操作里协同工作。

SQL 入口开始覆盖检索路径

视频解读如上,欢迎订阅. AI 应用的数据表已经不再只是指标、维度和事实行。一个检索型数据集通常同时包含文本、embedding、图片或音频、业务标签、过滤字段、索引和版本状态。开发者需要先做条件筛选，再做向量召回或全文召回，还要把结果接回分析、评估、审计和回填流程。

DuckDB 的 Lance 扩展把这条路径放进 SQL。官方文档显示，扩展支持 INSTALL lance; LOAD lance;，可以读写 Lance 表，并提供 lance_vector_search、lance_fts、lance_hybrid_search 三类检索函数。Lance 文档中的 DuckDB 集成也给出了混合搜索：向量距离、全文分数和 _hybrid_score 可以在一个查询结果里出现，并由 SQL 排序。

Lance 提供 AI 数据的表形态

向量检索进入 SQL 只是表层变化，更关键的是底层表格式。Lance 的表格式把数据组织为带版本的 fragments、data files、deletion files 和 indices；其设计目标覆盖 ACID transactions、schema evolution、time travel，以及基于 MVCC 的增量更新。对 AI 数据来说，这些能力非常实际：新增 embedding 列、回填特征、重建索引、删除样本、保留历史快照，都会发生在同一份数据资产上。

Lance 的 data evolution 机制尤其贴近特征工程。添加新列时，可以给已有 fragments 追加新的 data files，不必为了一个新特征重写整张表。Lance 的 transaction 规范也说明，每次提交都会创建新的不可变表版本，并通过乐观并发和冲突处理支持多写入场景。

这让 DuckDB 和 Lance 的分工更清楚：DuckDB 负责嵌入式 SQL 计算与数据探索，Lance 负责面向 AI workload 的开放表存储、索引生命周期和随机访问。

随机访问成为湖仓格式的新指标

AI 数据集对存储格式提出了一个更硬的问题：同一份列式数据既要能全表扫描，也要能快速随机访问。RAG、视觉搜索、推荐召回、模型评估样本回放，都在频繁读取少量命中的行、向量、文本和 blob。

2025 年 Lance 论文把这个问题推到存储编码层面：AI workload 同时需要 sequential access 和 random access；传统列式库在利用 NVMe 随机读能力时存在不足；结构编码会影响磁盘性能。论文进一步指出，Lance 的 structural encoding 方案旨在提高随机访问性能，同时避免牺牲扫描性能和内存利用率。

因此，Lance 接入 DuckDB 的信号已经超出格式兼容本身。它代表湖仓系统开始把检索型访问、索引维护和多模态对象读取纳入基础能力，减少开发者在 Parquet、向量库、全文引擎和对象存储之间反复同步数据的成本。

生产边界要看数据生命周期

这套组合最适合检索是主路径的数据资产：RAG 语料库、多模态素材库、embedding 特征库、视觉搜索库、推荐候选集、模型评测样本池。它们的共同点是数据会增长、schema 会变、索引要维护、样本要追溯，查询还经常混合标量过滤、全文检索和向量召回。

结构化报表、宽表扫描、低频离线聚合仍然可以继续使用成熟湖仓格式。引入 Lance 的理由，应当来自数据生命周期和访问模式，单次跑分只能作为辅助证据。真正需要评估的是：少复制一份数据、少维护一个外部检索系统、少处理一套一致性问题，能否抵消新格式带来的学习和治理成本。

接下来该看什么

• DuckDB Lance 扩展的 SQL 覆盖度、平台支持和稳定性承诺。
• 向量、全文、标量索引在高频更新场景中的维护成本。
• REST namespace 与远端 catalog 在权限、并发、治理上的成熟度。
• 对 S3、GCS、Azure Blob、OSS、Hugging Face Hub 等远端存储的实际体验。
• 与 Parquet、Iceberg、Delta 等生态之间的数据迁移和互操作成本。

结论

DuckDB 与 Lance 的结合，给 AI 数据湖仓提供了一个更实用的方向：用 SQL 保持分析工作流，用 Lance 承载检索、版本、索引和多模态随机访问。向量检索正在从外挂组件进入数据表内部，成为和扫描、过滤、聚合一样需要被正式建模的基础能力。