在 SQL 里直接写"帮我过滤掉负面评论"——一个让 AI 过滤器省 3-19 倍 token 的新招
- 关联论文：2606.07923（Larch · flyP · 2026-07-17）
数据库工程师 2026 年最头疼的"新算子"——
你可以在 SQL 里直接写
AI_FILTER('负面情绪', 评论列)，让 LLM 帮你筛掉负面评论。一行 SQL，零代码，业务方开心了——但你的 token 账单疯了。
为什么？
因为每次 AI_FILTER 都是一次 LLM 推理：延迟百毫秒到秒级，token 费用随数据量线性增长。而且这个算子对数据库优化器来说是个黑盒——它看不到内部逻辑，传统的 cost model（代价模型，估算"这条 SQL 大概要花多少资源"）和 cardinality estimation（基数估计，估算"过滤后还剩多少行"）全失效。结果：语义谓词在大表上几乎不可用。
arXiv 2606.07923 提出的 Larch，把这个痛点直接打成可学习问题——核心结论：比 Palimpzest、Quest 等基线降低 3×–19× 的 token 总开销。
为什么这件事重要？ 因为它意味着"在 SQL 里写自然语言过滤"这件事，从"演示惊艳、上生产破产"开始变成"可以放进生产管线"。
它到底解决什么真问题
行业里通常有两个绕路做法：
- 推到末尾：把语义谓词放到执行链最后，避免重复调用——但错失并行机会；
- 粗暴采样（sample-then-filter）：先抽 1% 让 LLM 跑，再决定要不要全量——要么漏检要么重算。
Larch 的切入点是两个观察：
- 语义算子慢，意味着有充分时间在运行时跑重优化——传统 OLTP（Online Transaction Processing，在线事务处理，即"快速跑大量简单查询"的场景）优化器不能干的事，这里能干；
- 非结构化数据几乎都会伴随 embedding（向量化表示，把文字/图片转成一串数字）一起存（用于下游检索），于是 prompt 与数据值之间可以做廉价的语义近似——不必每次都真调用大模型。
它怎么 work：两个互补变体
Larch 不是单一算法，而是两个互补变体共享同一个"AI SQL + 优化框架"形态。
变体 1：Larch-A2C（GNN + MDP 排序）
把任意布尔语义过滤表达式看成一棵 AND/OR/NOT 树，叶子节点是一个 AI_FILTER(prompt_i, col_i)。
- 编码器：Embedding-augmented Gated Graph Neural Network（GGNN，门控图神经网络）。每个节点既拿到对应的 prompt embedding，又拿到子树结构信息，门控机制决定不同层级的消息传递；
- 决策形式化：把"选哪个子节点先求值"建模成 MDP（Markov Decision Process，马尔可夫决策过程，即"在每个状态决定下一步做什么"的数学框架），状态是当前表达式树的剩余子树，行动是选择下一个求值节点，奖励是"少调一次大模型"；
- 训练信号：用结构化的 q-error（量化误差，即"预测值偏离实际值多少倍"）等反馈作为强化学习奖励。
适合过滤器多、表达式嵌套深、需要结构感知的情况。
变体 2：Larch-Sel（选择率预测 + 动态规划）
另一条更直接的路线：
- 选择率预测：用一个监督学习模型直接预测每个语义过滤器的 selectivity（保留比例），输入是 prompt embedding、列 embedding、列的样本统计等；
- 执行序搜索：在预测到的 selectivity 基础上，用经典动态规划（类似 Selinger 算法，数据库领域"找最优 JOIN 顺序"的经典方案）枚举不同的过滤器求值顺序，挑总期望 token 开销最低的那个。
适合过滤器相对独立、可以独立打分的情况。
两条路殊途同归：A2C 走结构学习路线，Sel 走经典 Selinger 路线，互为 fallback。论文报告两者在大多数负载上互为补集——一个差的数据集另一个往往能救回来。
关键实验与数据
- 核心指标：总 token 开销（包含 prompt + completion），不是单次延迟；
- 主要结果：两种 Larch 变体在所有测试集上always outperform现有方法，token 成本降低 3×–19×；
- 基线：Palimpzest（MIT）和 Quest（CMU）——AI SQL / semantic query optimization 方向被引用最多的系统。
⚠️ 诚实标注： - "always outperform" 措辞过强，摘要级断言未具同行评审定论； - 3×–19× 是相对基线的倍数，未说明基线是默认配置还是最优配置； - 论文摘要未给出端到端延迟降低多少——这是个常见盲点； - 缺乏与"sample-then-filter"的强对比，这恰恰是工程上最常见的简化做法。
数字 vs. 实际落地
工程上你可能踩到的坑：
| 坑 | 描述 | 解法 |
|---|---|---|
| 数据漂移导致 selectivity 模型失效 | 数据分布变化后历史训练数据不再代表真实 workload | 加监控：预测 vs. 实际 selectivity 的 q-error；超阈值自动重训练 |
| embedding 可用性是隐性依赖 | 没有预存 embedding 的列无法做短路优化，节省效果打折扣 | schema 注册阶段强制要求 embedding 列存在；缺失则走降级路径 |
| 小查询优化成本不划算 | 查询只过滤 10 行，优化器开销反而比直接执行还贵 | 设最低行数阈值：行数 < 阈值时跳过 Larch |
| A2C 的 RL 奖励函数设计困难 | q-error 奖励稀疏，训练不稳定 | 先用行为克隆（让模型模仿已有正确决策）做 warm-up，再加 RL 微调 |
| 与传统索引的交互 | AI_FILTER 和 B-tree / HNSW 索引并行存在时，优化器需要全局视野 | 把索引可用性作为 Larch 执行计划的额外输入 |
为什么这件事对从业者重要
- 不要把语义谓词当 last-mile 步骤：很多团队下意识把
AI_FILTER放到 SQL 末尾，结果丢了并行与短路机会。Larch 提示应该让它进入优化器视野； - 选择率可以被学习：传统数据库靠直方图，AI SQL 可以直接训练一个监督模型预测过滤后保留多少行；
- 慢算子反而是优化机会：当某个算子本身就贵时，为它专门做运行时的重优化是值得的——这条经验可以从 Larch 推广到其他重算子（重型 ML 推理、外部 API 调用）；
- embedding 是一等公民：在 RAG / 多模态数据库里，embedding 列应当像普通索引列一样纳入优化器统计。
必须警惕的边界
- 优化本身需要额外 ML 推理开销，对小查询可能反而更慢；
- 选择率预测模型的可解释性、可调试性较弱，线上出问题时难定位；
- 依赖 embedding 的可用性；如果数据库里没有预先算好的 embedding，节省的成本会被 embedding 计算抵消；
- 缺乏与传统 sample-then-filter 的强对比；
- 论文未公开具体的 workload 行数、模型规格、token 单价等明细。
谁该读这篇
- 数据库内核 / 优化器方向的工程师：想了解 AI4DB（AI for Database，用 AI 优化数据库本身）的新边界；
- 正在做 RAG / 多模态检索 / AI 数据分析平台的工程团队：关注如何控制 token 成本；
- 数据平台架构师：需要判断"要不要在自家查询引擎里引入语义谓词优化层"。
一句话总结
AI SQL 不是"塞个 LLM 进数据库"那么简单——需要把语义算子当作可学习对象，让优化器真正理解它的代价与选择性。
Larch 用 GNN + MDP（A2C）和选择率预测 + DP（Sel）两条路线，证明"语义谓词优化"这件事既可学习又可工程化。代价是要为每条 SQL 多花几毫秒优化时间，收益是 3×–19× 的 token 节省——对真在生产里用 AI SQL 的团队，这是救命级优化。
📎 论文 ID：2606.07923
三个标题变体
- 在 SQL 里直接写"帮我过滤掉负面评论"——一个让 AI 过滤器省 3-19 倍 token 的新招
- AI SQL 的 token 账单太吓人？Larch 教优化器自己学习"先调哪个 AI 谓词"省 19 倍钱
- 把 LLM 过滤器塞进 SQL 的代价太高了——这篇论文用 GNN+DP 把 token 开销打掉 19 倍
小红书风格卡片文案（可直接发布）
🤖 AI SQL 不是塞个 LLM 进数据库那么简单！
姐妹们有没有试过在 SQL 里直接写
AI_FILTER('负面情绪', 评论列) 🪄
一行搞定自然语言过滤，演示超惊艳——
但生产环境一上线 💸 token 账单直接爆掉！
为什么？每次 AI_FILTER 调一次 LLM 延迟百毫秒到秒级 💀 而且数据库优化器把它当黑盒 传统的 cost model + 基数估计全失效
arXiv 2606.07923 的 Larch 直接解决这个痛点 💥 核心结论：比 Palimpzest、Quest 等基线降低 3×–19× 的 token 总开销
Larch 怎么 work？两条互补路线 🔀：
📌 Larch-A2C（GNN + MDP 排序） - 把布尔过滤表达式看成一棵 AND/OR/NOT 树 - GGNN（门控图神经网络）编码 prompt + 树结构 - MDP 决定"先求值哪个子节点" - 强化学习奖励 = 少调一次大模型
📌 Larch-Sel（选择率预测 + 动态规划） - 监督学习模型预测每个 AI_FILTER 的 selectivity（保留比例） - 经典 DP（类似 Selinger 算法）枚举最优求值顺序 - 挑总期望 token 开销最低的那个
两条路殊途同归 🤝 A2C 适合嵌套深的复杂表达式 Sel 适合独立可打分的过滤器 两者在大多数负载上互为补集——一个差的数据集另一个往往能救回来 ✨
关键实验 📊：
- 核心指标：总 token 开销，不是单次延迟
- 主要结果：所有测试集上 always outperform 现有方法
- 降低幅度：3×–19× 的 token 成本
- 基线：Palimpzest（MIT）+ Quest（CMU）
⚠️ 诚实标注：
- "always outperform" 措辞过强，摘要级断言未具同行评审定论
- 3×–19× 是相对倍数，未说明基线是默认还是最优配置
- 论文未给出端到端延迟降低多少
- 缺乏与"sample-then-filter"的强对比
工程落地点 🛠️：
1️⃣ 别把语义谓词当 last-mile——让它进入优化器视野 2️⃣ 选择率可以被学习——监督模型预测过滤后保留多少行 3️⃣ 慢算子反而是优化机会——为重算子做运行时重优化值得 4️⃣ embedding 是一等公民——像普通索引列一样纳入优化器统计
工程坑（提前避雷）🚧：
| 坑 | 解法 |
|---|---|
| 数据漂移 → selectivity 模型失效 | 监控预测 vs. 实际 q-error，超阈值重训 |
| embedding 不可用 → 优化失效 | schema 阶段强制要求 embedding 列 |
| 小查询优化成本反贵 | 设最低行数阈值跳过 Larch |
| A2C 奖励稀疏训练不稳 | 先行为克隆 warm-up 再 RL 微调 |
| 与 B-tree / HNSW 索引并行 | 把索引可用性纳入执行计划 |
⚠️ 必须警惕的边界：
- 优化本身需要 ML 推理开销，小查询可能反贵
- 选择率预测可解释性弱，线上出问题难定位
- 依赖 embedding 可用性，节省的成本会被 embedding 计算抵消
📎 论文 ID：2606.07923
💬 评论区聊聊：你团队用 AI SQL 踩过哪些 token 账单的坑？