精读笔记

Problem Setting

《DeQL: A Decision Query Language for Prescriptive Analytics over Relational Data》（arXiv preprint / 2026）解决的不是某一类优化问题，而是关系型数据系统中缺失“决策查询”这一层抽象的问题。SQL 擅长描述事实，数据库内 ML 能回答预测，但“应该采取什么行动”通常需要跳出数据库，手工把关系数据转成优化模型。

真正困难点在于双重约束：一方面要保持 SQL 式的关系闭包、组合性、数据治理和查询可读性；另一方面又要保留优化问题的结构，让系统不是只得到一个扁平矩阵或黑盒 callback。以前方法卡在两端：建模语言表达力强但脱离数据系统；PaQL/SolveDB 把优化拉进 SQL，但要么偏 package selection，要么偏 solver embedding，缺少统一的 typed variables、constraint families、multi-granularity decisions 和 planner-visible structure。

关键矛盾是：用户希望像写 SQL 一样声明“我要优化什么”，系统却必须知道“变量在哪个粒度上、约束覆盖哪些实体、哪些结构可被专门算法利用”。DeQL 的核心目标就是把这个结构作为语言语义的一部分，而不是埋在用户手写建模代码里。

Motivation

作者的核心观察是，prescriptive analytics 的主要 friction 不只是 solver 难用，而是决策问题与关系数据之间缺少稳定接口。企业数据本来就在表里，policy/constraints 也天然是 grouping/filtering/join 条件，但现有 pipeline 往往先用 SQL 抽数，再在外部建模环境重新声明索引集合、参数、变量和约束。这一步既重复，又丢掉数据库里已经存在的 key、functional dependency、join structure 和 provenance。

已有 SQL 扩展不够的地方在于，它们没有把“优化实体身份”和“变量粒度”作为一等语义。Package query 可以表达选一批 tuple，但很难自然表达连续变量、跨层级变量共享、grouped constraints、scheduling global constraints 或 schema-level structural constraints。SolveDB 式集成把 solver 放进数据库，但如果语言层不保留结构，planner 仍然很难知道这个问题是不是 assignment、flow、LP、MILP 或 CP。

因此 DeQL 想补的缺口是：不是再发明一个 AMPL-in-SQL，而是让关系系统能直接承载 prescriptive workload，并让决策问题的结构在查询文本、IR 和执行计划中都可见。

Core Idea

DeQL 的核心思想是把优化模型拆成两个关系语义对象：候选集和决策查询。CREATE CANDIDATES 用 DECISION KEY 定义“一个决策实体是什么”；DECIDE 在这些实体上添加 decision columns，并用 SQL-like aggregates、BY、FILTER、JOIN、window/global constraints 声明约束和目标。结果仍然是 relation，可以继续被 SQL 查询或作为下一次 DECIDE 的输入。

这个改变的本质是把传统建模语言中的 index sets/variables/constraints 重新映射到关系语义：key 对应变量索引，grouping 对应 constraint family，join 对应跨粒度 coupling，selection 对应 package semantics。它引入的 inductive bias 是 planner-visible relational structure：系统知道变量属于哪个候选表、在哪个 grain 上实例化、约束按什么 group 生成、selection 如何影响聚合和输出形状。

相比 prior，DeQL 不是给 SQL 加一个 OPTIMIZE 函数，也不是固定一组模板；它试图定义一种通用的“决策关系代数”。如果成立，它比外部建模更 scalable 的原因不一定是 solver 更强，而是减少数据搬运、避免重复建模，并让引擎能利用 schema/key/group/join 结构做 formulation selection、decomposition 和 specialized solving。

Method

1. DECISION KEY：解决变量索引和结果形状不明确的问题。它要求候选查询在 key 上唯一且非 NULL，使每个候选实体对应明确的变量集合。核心变化是把数据库 key 语义提升为优化建模语义，避免 join 展开后 silently double-count。

2. Decision columns with grain：解决不同变量并不总是在同一粒度上决策的问题。默认一行一个变量，BY 可以声明 region-level、batch-level、global-level 变量。它的必要性在于真实优化常同时包含 item-level、group-level、facility-level 变量；核心变化是变量粒度不再隐含在手写索引集合中，而是显式进入查询。

3. SELECTION semantics：解决 package selection 与伴随变量联动的问题。auto-multiply 让 SUM(cost) 自动按选择变量计入，auto-link/auto-bound 让未选实体的连续/整数伴随变量归零。核心变化是把 PaQL 的 package semantics 泛化为 typed variables 上的选择算子，而不是要求用户手写 Big-M/linking constraints。

4. Grouped/filtered/window/global constraints：解决约束族的结构表达问题。BY 生成 per-group constraint，FILTER 限定单个聚合作用域，window constraints 表达时序依赖，DISJUNCTIVE/CUMULATIVE 引入 CP-style scheduling 语义。核心变化是约束不再只是矩阵行，而是保留产生方式和作用域。

5. Multi-granularity joins：解决多层级决策被迫笛卡尔展开的问题。不同 candidate set 保持各自 DECISION KEY，decision column 用 ON 标明归属，join 只连接数据实体，变量 coupling 放在 SUBJECT TO。核心变化是 facility-level binary 和 assignment-level continuous 这类变量可以在同一 DECIDE 中共享约束，但不必把 facility 数据重复到每个 customer pair 上。

6. Three-IR execution model：解决语言表达与 solver 输入之间的断层。Abstract IR 保留符号结构，Concrete IR 表示选定 formulation，Materialized IR 才变成系数矩阵/图/solver input。这个分层是 DeQL 能否成为系统而非语法糖的关键，因为 planner 的结构识别只能发生在 matrix materialization 之前。

Key Insight / Why It Works

这篇最重要的 insight 是：prescriptive analytics 的可优化性很大程度上来自“结构没有过早丢失”。如果用户在 Python/Pyomo 中手写 formulation，结构当然存在，但数据库系统看不到；如果系统只看到 materialized coefficient matrix，很多业务语义也已经丢了。DeQL 试图把 key、grain、group、filter、join、selection 这些关系结构保留到 IR 层，使 optimizer/planner 有机会做类似 SQL optimizer 的事情：识别模式、选择 formulation、推迟 materialization、利用 specialized algorithms。

最可能的核心贡献是 decision grain + relational closure + planner-visible constraint families 的组合。单独看，每个元素都不是全新：typed variables 来自优化建模语言，package selection 来自 PaQL，solver integration 来自 SolveDB，global constraints 来自 CP，PREDICT 来自 in-database ML。但它们被统一到关系闭包和 DECISION KEY 语义下，形成了一个比较 coherent 的语言设计。

哪些可能只是辅助：stochastic constraints、PREDICT、WITHIN/TIMEOUT、CREATE ABSTRACTION 目前更像 roadmap 或 extension hooks。尤其 stochastic 部分只说 sampling scenarios 和 chance constraints，文中未充分说明概率保证、sample complexity、correlation modeling 或 distributional robustness；PREDICT 也只是把模型打分作为 data column 注入 objective，增益来源不清，更多是 system integration 而非优化语言的核心创新。

方法为什么可能有效：因为大量企业优化问题并不是任意 nonlinear program，而是由关系数据生成的重复约束族和稀疏 coupling graph。把这些生成机制显式化，确实能帮助识别 network flow、assignment、totally unimodular structure、block decomposition、Benders-like 或 cluster abstraction 机会。这里的能力更接近 better inductive bias + structure preservation，而不是 scaling 本身。

但最强 claim 仍未被证明：planner 是否真的能从 DeQL 查询稳定推出更好 formulation。文中给了 assignment LP relaxation integral 的例子，但这只是经典结构识别；真实 workload 中结构常被业务约束、nonlinear scoring、chance constraints、dirty data 打破。若 planner 不能可靠处理这些混合情况，DeQL 的主要价值会退化为更方便的建模 DSL，而不是“SQL for decisions”。

Relation To Prior Work

DeQL 最接近三条谱系：optimization modeling languages、database-integrated optimization、package queries。与 AMPL/Pyomo/JuMP 的本质差异不是表达 typed variables/constraints，而是 DeQL 把变量索引和参数直接绑定到 relation、key、join 和 group 上，并要求输出仍是 relation。建模语言让用户选择 formulation；DeQL 试图让系统选择 formulation。

与 PaQL 的关系最直接。PaQL 的 PACKAGE/REPEAT/SUCH THAT 可以看作 SELECTION BINARY/INTEGER + auto-multiply 的特例。DeQL 的实质新增是连续/整数伴随变量、grouped constraints、变量 grain、多 granularity join、schema-level constraints 和 planner-facing structure。也就是说，它不是推翻 PaQL，而是把 package query 泛化成完整 prescriptive query。

与 SolveDB 的差异在语言层。SolveDB 更像把 solver 接入 SQL；DeQL 更强调 SQL 扩展的语义设计和 IR 分层。如果没有结构化语言，solver integration 只能解决“怎么调用 solver”，不能解决“系统如何理解决策问题”。

看似新的部分中，DISJUNCTIVE/CUMULATIVE 来自 constraint programming，PREDICT 来自 in-database ML，chance constraints 来自 SPaQL/stochastic optimization，WITHIN/TIMEOUT 来自 optimization solver 的 gap/time limit。实质创新不是这些 construct 本身，而是把它们放进一个关系闭包、key/grain-aware 的决策查询语言中。

Dataset / Evaluation

这篇没有传统意义上的 dataset/evaluation，更准确说是 language specification with examples。示例覆盖范围很宽：subset selection、continuous allocation、diet、production planning、assignment、batch scheduling、facility location、GPU scheduling、ML scoring、stochastic constraints。这能说明语言设计的表达覆盖面，但不能验证系统性能或 planner claim。

它没有展示真实企业 workload、真机部署、与 Pyomo/JuMP/SQL+solver pipeline 的开发成本对比，也没有展示不同 formulation selection 对 solve time/optimality gap 的影响。因此 evaluation 目前只支持“这些问题可以被写成 DeQL”，不支持“DeQL engine 能更快、更稳、更可扩展地求解”。

特别是 CREATE ABSTRACTION、structure detection、decomposition、bounded optimality loss 是最需要实验验证的部分，但正文只给概念描述。增益来源不清：未来如果有性能提升，可能来自减少数据搬运、solver 选择、problem decomposition、approximation abstraction，或只是特定 benchmark 的结构简单。当前文本无法区分。

Limitation

第一，DeQL 成立依赖一个强前提：业务决策问题可以干净地表达为关系候选集上的 typed variables、约束和单目标 objective。许多真实 prescriptive workflows 包含交互式偏好、非形式化 policy、人工 override、动态反馈和多阶段 recourse，这些不容易落入当前单次 DECIDE。

第二，scalability 上限不由语言决定，而由 candidate generation、join cardinality、constraint materialization 和 solver backend 决定。DeQL 可以保留 multi-granularity structure，但如果候选空间本身来自大规模 cross join，系统仍可能在 materialization 前后爆炸。CREATE ABSTRACTION 试图缓解，但 bounded optimality loss 文中未充分说明。

第三，表达力扩展可能把问题转移给 planner。语言允许 nonlinear/quadratic/chance constraints，并声称 engine 选择 solver，但这正是最难的系统问题。若 planner routing 不可靠，用户仍需要理解底层 formulation，否则 query 写得出来但解不出来、解得慢或得到不可解释近似。

第四，SQL-like 语义与优化语义存在张力。DeQL 的 aggregation over grain、SUM(1)=1、coarse variable broadcast、NULL-as-error、LAST_VALUE whole-group semantics 都有意偏离 SQL 直觉。这些设计有技术理由，但会增加心智负担，也可能导致 subtle modeling bugs。

第五，stochastic/PREDICT/LLM scoring 部分风险最大。PREDICT 进入 objective 后，优化会放大模型误差；chance constraints 若只靠采样，概率保证和相关性建模都不清楚。这里所谓智能决策很可能主要来自 data/model coverage，而不是 DeQL 本身的推理能力。

Takeaway

• 1. 最值得记住的是“DECISION KEY + grain + constraint family”这一组抽象：它把优化建模中最容易隐式出错的索引/粒度问题显式化，并与关系系统的 key/group/join 对齐。
• 2. DeQL 真正推动的方向不是更强 solver，而是 database optimizer 与 mathematical optimizer 的接口设计。
• 未来关键竞争点会在 IR、structure detection、formulation selection、debuggability，而不是语法本身。
• 3. 可迁移 insight：如果一个系统想把高级决策/规划能力嵌入数据平台，必须保留 problem-generating structure，而不是过早变成向量、矩阵或黑盒函数调用。

一句话总结

DeQL 是一次把 package query、优化建模语言和数据库查询优化合流的语言设计尝试，真正贡献在于用关系 key/grain/group/join 语义保留决策问题结构，而不是提出新的优化算法。