ReaderMX.
alitrack

16个AI函数装进DuckDB，在SQL里就能调大模型

aalitrack约 6 分钟

你正在 DuckDB 里查一批用户反馈。你想给每条反馈打个标签（投诉 / 建议 / 咨询），再提取关键信息，最后问问"最近用户在抱怨什么"。

正常的做法：导出 CSV → Python →调 LLM API → 写 prompt → 解析结果 → 导回数据库。三个工具、五次切换、一堆胶水代码。

duckdb-ai 的思路不一样：这些操作，全在 SQL 里完成。

LOAD ai;

-- 给反馈打标签
SELECT id, text, ai_classify(text, '投诉, 建议, 咨询')
FROM user_feedback;

-- 提取关键信息
SELECT id, ai_extract(text, 'product, issue, sentiment')
FROM user_feedback;

-- 直接问数据库问题，它生成 SQL 并执行
SELECT * FROM ai_query_data('最近一周投诉最多的产品是什么？');

没有 Python 脚本，没有 API 调用封装，没有中间格式转换。SQL 查询，LLM 计算，结果直接落表。

● ● ●

这是什么

duckdb-ai 是 DuckDB 的社区扩展，由 Leonardo Vida 开发，7 月 2 日刚刚合入 community-extensions。MIT 协议，C++ 编写。

一句话概括：把大模型的能力变成 DuckDB 的 SQL 函数。

它提供了 16 个 ai_* 函数，覆盖了四个维度：

类别函数做什么
文本任务`ai_complete`, `ai_summarize`, `ai_classify`, `ai_extract`, `ai_translate`, `ai_redact`, `ai_filter`补全、摘要、分类、提取、翻译、脱敏、过滤
结构化输出`ai_complete_json`, `ai_complete_record`, `ai_extract_record`JSON Schema 校验，直接投射到 DuckDB 列
嵌入 & 相似度`ai_embed`, `ai_similarity`, `ai_rerank`向量嵌入（自动分批）、余弦相似度、重排序
SQL 生成`ai_sql`, `ai_query_data`自然语言 → 只读 SELECT，解析器验证后才执行

外加 ai_usage() 查看用量和成本，ai_agg() 和 ai_summarize_agg() 做聚合级别的 AI 计算。

Image

● ● ●

怎么工作

核心思路很简单：扩展在 DuckDB 的查询执行引擎里注册了一批标量函数和聚合函数。每个函数调用时，扩展把输入发给配置好的 LLM provider，拿回结果，返回给查询。

Provider 的选择通过 DuckDB 的 Secret 机制管理，不是硬编码在 SQL 参数里：

-- 本地 Ollama（免费，数据不出机器）
SET duckdb_ai_provider = 'ollama';
SET duckdb_ai_model = 'gemma4:e4b';

-- 或者用 OpenAI，密钥存 Secret
CREATE SECRET openai_ai (
    TYPE duckdb_ai,
    AI_PROVIDER 'openai',
    API_KEY 'sk-...',
    MODEL 'gpt-4o-mini'
);

支持的 provider 有 10+ 个：Ollama、OpenAI、Azure OpenAI、Anthropic、Gemini、Mistral、DeepSeek、OpenRouter、Databricks、Snowflake Cortex、Z.ai，以及任何 OpenAI 兼容的本地服务器（vLLM、LiteLLM 等）。

扩展本身加载时不发任何网络请求 —— 只有执行 ai_* 函数时才会连接 provider。

Image

● ● ●

几个值得注意的设计

1. 结构化输出直接落表

ai_complete_record 和 ai_extract_record 会按你提供的 JSON Schema 校验模型输出，然后自动展开成 DuckDB 的 STRUCT 列。这意味着你可以写：

SELECT ai_extract_record(
    review_text,
    schema := '{"type":"object","properties":{"sentiment":{"type":"string"},"score":{"type":"integer"}}}'
) FROM reviews;

结果直接是 {sentiment: 'positive', score: 8}，不需要手动 JSON 解析。

2. 嵌入自动分批

ai_embed 不会逐行调 API —— 它会按 chunk 自动攒批，一次请求处理多条数据。这在处理大量文本嵌入时能省不少 API 开销。

3. SQL 生成有安全门

ai_sql 和 ai_query_data 生成的 SQL 必须通过 DuckDB 的解析器验证才会执行，而且只允许 SELECT 语句。你问"删掉所有订单"，它不会执行 DROP TABLE。

这不是 prompt 里说"请只生成 SELECT"—— 是代码层的硬约束。

● ● ●

性能与可控性

扩展内置了一套并发和节流机制：

  • 并发上限（duckdb_ai_max_concurrency）
  • 请求速率控制（duckdb_ai_requests_per_minute）
  • Token 速率预算（duckdb_ai_tokens_per_minute）
  • 失败重试 + 退避
  • 可选的响应缓存和 provider 端 prompt 缓存

还有网络出口白名单（duckdb_ai_allowed_domains），防止意外调用不该调的服务。

用量追踪也很直接：

SELECT * FROM ai_usage();
-- 返回每次调用的 provider、model、tokens、估计成本、缓存命中、重试次数

● ● ●

当前状态

刚合入 community-extensions，还不能 INSTALL ai。 我试了一下：

D INSTALL ai FROM community;
-- HTTP 404: extension not yet published

PR 是 7 月 2 日中午合的（#2169），社区的构建流水线还没把二进制推到 CDN。按 community-extensions 的正常节奏，应该 1-2 天内可安装。

在此之前可以从源码构建（需要 C++ toolchain + CMake + ninja）：

git clone https://github.com/leonardovida/duckdb-ai.git
cd duckdb-ai
GEN=ninja make release

目前版本 0.3.1，代码库非常新（7 月 1 日创建），但迭代速度很快 —— 两天发了三个版本。

● ● ●

跟 pgvector / PostgresML 比

DuckDB 的 AI 扩展不是第一个"在数据库里跑 AI"的尝试，但定位很不同：

维度duckdb-aipgvectorPostgresML
定位分析型，嵌入查询流OLTP + 向量搜索ML 训练+推理平台
AI 范围文本 + 嵌入 + SQL 生成仅向量存储/搜索完整 ML 流水线
Provider10+ LLM providerN/A（存向量）自托管模型
部署复杂度一个扩展文件一个扩展完整服务栈
适用场景批量文本处理、临时分析生产级向量检索模型训练+在线推理

duckdb-ai 的优势在于分析场景的零摩擦：你不需要把数据导出到 Python，不需要写 API 封装，不需要管理另一个服务。它适合"跑一次分析"或"做一批文本处理"的场景。

劣势也很明显：它不是为高并发在线服务设计的。DuckDB 本身是 OLAP 引擎，不适合嵌入到 API 服务的请求路径里。

● ● ●

局限

  1. 01还不可安装：INSTALL ai FROM community 目前 404，需要等构建流水线跑通。
  2. 02v0.3.1，早期阶段：两天前创建的 repo，API 可能会变。
  3. 03非官方扩展：一个维护者的社区项目，不是 DuckDB Labs 出品。稳定性取决于维护者的持续投入。
  4. 04LLM 延迟：每个 ai_* 调用都是一次网络请求。查询 1000 行 = 1000 次 API 调用。虽然做了并发控制，但延迟是跑不掉的。
  5. 05不支持 WASM：excluded_platforms: wasm_mvp;wasm_eh;wasm_threads —— browser 里的 DuckDB-WASM 用不了。
  6. 06依赖外部 LLM 成本：本地用 Ollama 免费，但云 provider 按 token 计费。ai_usage() 可以追踪，但成本是你自己的。

● ● ●

为什么值得关注

DuckDB 这两年的扩展策略很明确：让社区往这个"小分析引擎"里塞各种能力。从 Iceberg 到 Delta Lake，从 Spatial 到 Lance，现在是 AI。

这个方向的价值在于降低分析工作的上下文切换成本。一个分析师处理文本数据的典型流程是：SQL 查数据 → Python 调 LLM → 回写数据库 → 再查。每次切换都丢 context。

duckdb-ai 把这个流程压缩成一个 SQL 查询。不需要换工具，不需要写胶水代码。

当然，这不意味着"AI in SQL"是银弹。复杂 prompt 工程、多步推理、agent 循环 —— 这些还是 Python 更适合。但对于"给 5000 条评论分类""提取订单里的关键信息""批量生成摘要"这类操作，SQL 一站式确实比到处切工具舒服。

等社区构建流水线把二进制推上去，试试 INSTALL ai FROM community 能不能跑通。值得盯着。

链接：

  • 仓库: github.com/leonardovida/duckdb-ai
  • 社区扩展 PR: github.com/duckdb/community-extensions/pull/2169
  • 扩展描述: github.com/duckdb/community-extensions/blob/main/extensions/ai/description.yml

KEEP THE THREAD GOING

更多来源文章