Beyond Quacking: Deep Integration of Language Models and RAG into DuckDB
Anas Dorbani, Sunny Yasser, Jimmy Lin, Amine Mhedhbi
cs.DB, cs.AI, cs.IR
2025-04-02
FlockMTL 把 LLM 标量/聚合函数和可版本化的 PROMPT、MODEL 对象写进 DuckDB 的 SQL。Kaggle 银行评论上,批量推理让对话补全最高加速 7 倍、embedding 最高 48 倍。
知识密集型分析既要查表,也要读文档、做摘要、做重排。LLM 让这类流水线好搭原型,真要跑起来仍要拼 DBMS、搜索引擎和编排层:搬数据、管上下文、决定何时缓存、需求一变就重写。作者把这比成关系模型出现之前的数据管理:执行细节全压在工程师身上,跨系统还丢掉了联合优化。
FlockMTL 的回答是:把 LLM 能力和 RAG 嵌进 DuckDB 的 SQL,让语义操作用标量和聚合函数写,用代价优化去管批处理、缓存这些脏活。
它是 DuckDB 社区扩展,可 INSTALL / LOAD。新的 DDL 对象 PROMPT 和 MODEL 与 TABLE 平级,可 Local 或 Global。改资源会自动留版本,查询默认用最新,应用 SQL 不用跟着改。模型可走 OpenAI、Azure 或本地 Ollama。
标量函数把一行映射成一个值:llmcomplete / llmcompletejson 做生成,llmembedding 出向量,llmfilter 出布尔,fusion 用 rrf、combsum 等融合多路分数。聚合函数把多行收成一个值:llmreduce 做归约,llmrerank 做 listwise 重排,llmfirst / llmlast 取最相关或最不相关的一行。用 CTE 就能把过滤、摘要、抽 JSON、向量召回、BM25、融合、重排串成一条 SQL。另有 ASK,把自然语言问句翻成带这些函数的 SQL。
优化上,用户只写「对一行/对一组」的提示,系统用元提示拼出带格式约束、对 KV-cache 友好的完整提示,并按上下文窗口动态装箱。一次请求塞尽可能多的元组;输出撑破窗口就每次把 batch 缩小 10%,直到成功,单条仍超限则置 NULL。文中还提到预测缓存和按去重后的唯一值调用,篇幅不够,没展开实现。
这是 VLDB 2025 的四页演示论文,没有端到端准确率表,也没有跟 LangChain 编排或 Palimpzest、TAG 的系统对照数字。给出的硬指标是批处理加速:在 Kaggle Bank Review 上,对表扫描加一个标量 FlockMTL 函数,对话补全 map 最高约 7 倍,embedding 函数最高约 48 倍。
演示里用户对银行评论发「列出提到技术故障的评论并打严重度」,ASK 生成带 llmfilter 等函数的 SQL;计划检查页能看到自动选的 batch size,默认序列化是 XML,可改 JSON 或 Markdown,也能用 Jinja 换掉整段元提示。论文声称这是 SQL 里第一套完整混合检索实现,向量一路可走自带 embedding,词法一路接 DuckDB 全文扩展的 BM25,再用 fusion 和 llmrerank。
把 LLM 调用收进嵌入式分析库,分析师可以在 SQL 里写「过滤再摘要再抽字段」,而不必先把表倒进 Python。PROMPT / MODEL 版本化适合提示经常改、查询希望稳住的团队。7 倍和 48 倍说明,逐行打 API 在分析场景里有多浪费;光是装箱和去重就够吃一截。
它是渐进的系统工作,不是新的推理算法。对已经把 DuckDB 当分析引擎的人最有用;查询要联邦到 Postgres / MySQL 或扫 Parquet 时,扩展会跟着 DuckDB 的生态走。云上按 token 计费时,批处理同时砍延迟和账单。
四页演示几乎没有质量评测:没有报告 llmfilter 的误杀率、重排的 nDCG、ASK 的可执行率,也没有美元成本。7 倍 / 48 倍只来自一张表扫描加一个标量函数,复杂 CTE 链会怎样,文中没给。批处理把多行塞进一次解码,可能改变单行提示下的输出分布,论文没测这个偏差。
后端当时绑在 OpenAI、Azure、Ollama。元提示固定走 XML 默认,换 JSON 或 Markdown 对准确率的影响只在演示里让观众手调。缓存和去重被点名却没细节,复现优化效果要靠仓库。演示设定下用户还能手改 batch,等于优化并没有完全从人手里拿掉。