我尝试让自然语言成为 SQL 谓词。数字说不行。

📌 One-Sentence Summary

作者构建了一个名为「SemPred」的系统，将自然语言谓词直接融入 SQL WHERE 子句，并得出结论：最初的冻结编码器架构无法满足准确率与覆盖率所需的平衡。

📝 Summary

本文记录了一个实验：创建一个 SQL 谓词（SEM_PREDICT），让用户用普通英语过滤数据。作者使用 DuckDB 和一个冻结的 MiniLM 编码器，为每个谓词配备逻辑回归头，开发了原型系统。尽管通过嵌入缓存和批量推理实现了高吞吐量（4.2 万+ 对/秒），但该模型未能通过预设的质量门槛，即准确率需达到 ≥90%，覆盖率需达到 ≥50%。作者详细分析了弃权（使用 UNKNOWN/NULL）与覆盖率之间的权衡关系，并认为这更像是一个数据系统挑战，而非纯粹的 NLP 问题。文中提出了一个成对评分架构的假设，并总结了为 AI 实验设定严格停止条件的教训。

💡 Main Points

将语义谓词集成到 SQL 逻辑中

目标是让自然语言条件像原生 SQL 谓词一样表现（TRUE、FALSE、UNKNOWN），避免逐行 API 调用并保持 SQL 结构。

准确率与覆盖率之间的关键权衡

通过使用弃权边界返回「UNKNOWN」，准确率可以被夸大，但覆盖率会下降；由于无法在保持高准确率的同时回答至少 50% 的查询，该原型失败了。

系统性能 vs. 模型质量

数据系统实现（DuckDB 集成和嵌入缓存）取得了成功，实现了高吞吐量，但冻结编码器的模型架构对于这项任务来说不够。

从分类到成对关系的转变

作者推测，将谓词视为分类头是错误的；相反，模型应评估文本与谓词字符串之间的成对关系。

💬 Key Quotes

通过让模型回答更少的问题，你几乎可以让任何模型看起来都很准确，因此每个弃权数字旁边都需要有其对应的覆盖率。

在大型表上运行不确定的谓词可能更难的是要安全地执行。

我不想要一个 LLM 为我写 SQL，也不想要一个聊天机器人。我也不想把每一行都发到 API。

质量门槛没通过，因此结论是这种架构还不具备生产就绪条件。

📊 Article Meta

AI Screening： 86

Source： DEV Community: machinelearning

Author： Yudeeswaran V

Category： 人工智能

Language： 英文

Read Time： 7 min

Word Count： 1749

Tags：

AI 与智能应用 , AI 工程 , 机器学习 , 数据库 , LLM 推理优化