NOW的侧写
我把CMU 15445#01看了一遍，我知道DBMS要把声明式语言（比如SQL）转换为具体的查询方案（通常使用关系代数来表示），但是我对LLM就没有那么熟悉。我不知道LLM可以在这个过程中扮演怎样的角色。以及LOTUS是如何实现这一点的，还有语义算子究竟发挥怎样的作用。怀着这样的疑问，我开始了阅读。
语义算子：https://sky.cs.berkeley.edu/project/lotus/
论文的轮廓
传统数据库：SQL (声明式语言) -> 查询优化器 -> 关系代数 (逻辑计划) -> 物理执行计划 (如使用哈希连接、索引扫描等)
LOTUS：语义算子 (声明式语言) -> LOTUS优化器 -> 黄金算法 (逻辑计划) -> 优化的执行计划 (使用代理模型+预言机模型)
我来给后者上色。
语义算子
在传统SQL中，操作（如WHERE gpa > 3.5）是基于严格的 逻辑和数学比较。计算机可以直接、无歧义地执行这些指令。
LOTUS中，操作是基于 自然语言和语义 的，例如： papers_df.sem_filter("论文的摘要部分提出了一个非常离谱的主张")
我们要在两者间建立桥梁，LLM 是最合适的工具。
把数据和自然语言指令打包成一个 prompt，发送给LLM，返回一个真值。
还是以这样的例子：
papers_df.sem_filter("论文的摘要部分提出了一个非常离谱的主张")
语义算子让我们用自然语言来声明一个基于语义的查询。"论文的摘要部分提出了一个非常离谱的主张"是一个自然语言表达式（文中称为 “langex”），它参数化了这个 sem_join 算子 。
LOTUS 优化器 (LOTUS Optimizer)
LOTUS优化器是接收语义算子查询，并 生成一个高效、低成本的执行计划 的核心组件 。它就是DBMS中的查询优化器 (Query Optimizer)。
在DBMS中，查询优化器会把用户的SQL语句转换成多种等价的关系代数表达式，然后基于成本估算选择一个最优的物理执行计划。
LOTUS 优化器负责将用户的声明式查询（逻辑计划）转换为一个经过优化的、可执行的计划（物理计划）。
黄金算法 (Gold Algorithm)
类比为DBMS优化器在开始优化前，脑子里有的那个 “标准但可能很慢”的查询计划。
还是举例子：
sem_filter 的黄金算法：对数据集中的每一行都独立调用一次高质量LLM来判断是否满足条件。
sem_join 的黄金算法：实现一个嵌套循环，对两个表的每一个元组对都调用一次LLM来判断是否满足连接条件 。这个算法非常准确，但也极其昂贵。
这是提供了一个清晰、可预测的行为规范。它是规范的正则的可预测的。
黄金算法是进一步优化的baseline.
优化的执行计划 (Optimized Execution Plan)
由LOTUS优化器生成的，最终实际在系统上运行的查询方案 。相当于于DBMS中的物理执行计划 (Physical Execution Plan)。
它是用一种叫“代理-预言机 (Proxy-Oracle)” 的模型来进行优化的。
- 预言机 (Oracle)：指黄金算法中使用的那个强大、昂贵但准确的LLM（比如Llama-3-70B） 。
- 代理 (Proxy)：指一个成本极低但准确性也较低的替代方案，比如一个非常小的LLM或者基于向量嵌入的相似度计算 。
计划的执行流程如下（以sem_filter为例）：
- 系统先通过少量采样，学习代理模型的输出与预言机模型输出之间的关系，并设定一个决策阈值 。
- 对于数据集中的每一行，首先使用 廉价的代理 进行判断 。
- 如果代理给出的分数非常高或非常低（即代理对自己的判断非常有信心），系统就直接采纳代理的结果，避免了调用昂贵的预言机 。
- 只有当代理给出的分数处于一个模棱两可的中间地带时，系统才会启动 昂贵的预言机 来做出最终裁决 。
通过这种方式，系统用廉价的代理处理了绝大多数“简单”的数据，只把一小部分“困难”的数据交给预言机。
论文说，这个优化计划能在执行上比黄金算法快1000倍，同时还能提供统计上的准确性保证。
今天到了12点，下一天我会细致阅读整篇文章。