Show HN：Natural-SQL-7B，一个强大的文本转 SQL 模型

原文 ↗ Hacker News 讨论 ↗

一个新的 70 亿参数文本转 SQL 模型 Natural-SQL-7B，旨在让非技术用户用自然语言查询数据库，同时可在本地运行，这让人们对比基于 GPT‑4 的方案更低成本、更私密的分析能力抱有期待。评论者质疑其自定义的“source available”许可、当前对 PostgreSQL 的侧重，以及约 75% 的准确率是否足以用于生产，尤其是在业务逻辑和 KPI 细节复杂或高度依赖领域知识的场景中。许多人认为，这类模型更适合作为起草工具，或与语义层、RAG 和强数据治理结合使用，而不是作为熟练分析师的完全替代品。

模型能力与范围

  • 一个 7B 的文本转 SQL 模型，在约 2 万对合成的 PostgreSQL 文本→SQL 配对上微调，覆盖了不同 SQL 类别和问题类型。
  • 在 SQL-Eval 上评测约为 76.5%，略低于 GPT‑4 和 sqlcoder‑15B。
  • 目前侧重于 Postgres；更广泛的方言支持（MySQL、DuckDB、MSSQL、BigQuery、Trino）是人们希望的方向，且部分已有计划。
  • 能处理多表连接、聚合和子查询这类对非技术用户而言“很难”的问题，但在非常复杂的模式或偏业务逻辑的查询上并不保证可靠。

许可与“开源”争议

  • 许可包含基于用途的限制（例如禁止军事用途），这些限制继承自基础模型。
  • 多位评论者认为这不算“开源”，而是“可获取源码/权重”。
  • 有人担心非标准许可会迫使人们做法律审查，而不是像熟悉的 MIT/Apache/GPL 那样直接使用。
  • 也有人指出，提供的只有模型权重，而没有训练代码/数据。

使用场景、准确率与可靠性

  • 被认为有用的场景包括：
    • 为开发者/分析师起草 SQL，之后由他们审阅并修正。
    • 支持本地/命令行工具，避免把模式发送给云端 LLM。
  • 怀疑者质疑，在大约 75% 的正确率下究竟能安全自动化什么，尤其是在业务关键分析和 KPI 场景中。
  • 也有人指出，人类同样会犯错；其价值在于加速“简单”步骤，并由人来验证结果。
  • 有人提出的思路包括：集成/共识、通过强数据库约束做验证，以及主要用于容易检查正确性的场景。

模式、上下文长度与语义

  • 4k 上下文对很多真实模式来说太小；人们讨论通过 DDL 做 RAG，或者希望有 32k+ 上下文。
  • 常见模式是：将 CREATE TABLE DDL（带注释）作为提示词；也有人对文档/wiki/dbt 做 RAG，以教授语义。
  • 几位评论者认为，真正的问题不是 SQL 语法，而是理解数据含义（“这个 ‘price’ 或 ‘active’ 字段到底是什么意思？”）。
  • 有人强烈支持语义层 / 知识图谱 / ORM，把业务逻辑编码进去，再从该层确定性地生成 SQL，而不是直接由 LLM 生成。

云端 vs 本地、隐私与信任

  • 一些人拒绝把模式或数据发送给 OpenAI，理由包括条款变化、监管担忧或潜在的政府访问。
  • Azure OpenAI 在一些人看来更安全，但在功能/模型上落后。
  • 对于有隐私或治理约束的人来说，这个模型“本地可用、权重可获取”的方式很有吸引力。

关于 SQL 与工具的更广泛思考

  • 有人争论应该学习 SQL，还是依赖 ORM 或 LLM；许多人强调 SQL 的长期价值和性能优势。
  • 也有人指出 SQL 的易用性问题，并更偏好抽象层。
  • 几位评论者提到，LLM 已经很适合用于解释复杂 SQL、调试错误，以及生成棘手的窗口函数/百分位数查询。