本文主要是介绍为什么自然语言转SQL(text to sql)在企业中较难落地，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
“BI 的未来是对话式的。” 这是多年来行业分析师的预测。 然而，尽管去年基于 LLM 的对话式应用程序（例如 ChatGPT + Bard）和新的强大模型（例如 GPT-4）取得了惊人的进步，但大多数公司仍然没有部署对话式 BI。 业务用户仍在寻找 BI 仪表板中的见解，数据分析师仍在打开连接到数据仓库的 SQL 引擎并手写 SQL 查询来回答临时业务问题。 为什么对话式 BI 还没有出现？
虽然结构化数据仅占全球数据的 20% 左右，但大多数企业数据仍然存储在结构化数据存储中，并且主要通过 SQL 查询进行访问。 因此，为了实现对话式 BI，需要设计一种解决方案，将自然语言业务问题转换为有效的 SQL 查询，然后针对企业数据仓库执行这些查询。 自 70 年代以来，工程师们一直尝试构建“自然语言到 SQL”(NL2SQL) 引擎（使用基于规则的技术），但很快就会变得过于复杂而无法使用。 但是随着像GitHub CoPilot和OpenAI Code Interpreter这样的转换器的进步，这似乎应该是一个微不足道的问题来解决。 但事实并非如此。
企业可以通过（至少）两种方式构建基于 LLM 的 NL2SQL 引擎来支持会话式 BI：
-
微调自己的 LLM — 这种方法需要采用现有的 LLM，然后使用与公司结构化数据相关的 NL与SQL 对进一步对LLM进行训练。这种方法面临的一些挑战是：a) 提供训练数据集既困难又昂贵，b) 最强大的 LLM 模型 (GPT-4) 无法进行微调（截至撰写本文时）。
-
利用上下文学习——最新的 LLM 模型（如 GPT-4-32K）可以很好地开箱即用地编写SQL，并且有足够的上下文窗口来进行一些小样本训练，并让代理尝试通过使用思维链技术执行后续操作来从错误中恢复过来。这里的想法是在GPT-4之上构建一个LLM代理，它可以通过很少的学习来实现NL2SQL。
那么部署解决方案#2 面临哪些挑战？ 以下是我们遇到的六种情况：
- 表和列描述——即使是最好的数据团队通常也没有关于表、列和元数据的清晰文档。 随着 ELT
的兴起，数据只是从各种来源转储到仓库中并根据查询进行转换，情况变得更糟。 因此，表和列的名称可能是唯一有用的信息。 - 缺少上下文和元数据——业务定义通常存在于数据分析师的头脑中，而不是在底层数据中。
- 信息不完整，缺乏“常识”——“2023 年 5 月洛杉矶的平均租金是多少？” 一个理性的人收到这个问题时会简单地假设该问题是关于加利福尼亚州洛杉矶的，或者会在后续中与提问者确认。然而，LLM通常会将其转换为从rent_prices中选择价格，其中城市=“洛杉矶” AND月份=“05” AND年份=“2023”，而这会提取加利福尼亚州洛杉矶和德克萨斯州洛杉矶的数据。
- 速度——为了使引擎能够“对话”，响应时间必须很快（不到 30 秒）。 这通常很难实现，特别是当代理尝试从错误中恢复或通过后续 LLM 调用评估生成的响应时。
- 复杂查询——虽然 GPT-4 可以很好地编写简单的 SQL 查询，但它经常会遇到需要聚合和连接的复杂查询。 如果列名包含可以在 SQL中完成的操作（例如 Average 或SUM）以及在数据仓库的联接操作中，其中外键没有像在关系型数据库中那样明确，则这种情况会加剧。
- 隐私和数据泄露——许多组织不希望将他们的数据库数据或模式发送给 OpenAI 这样的公司，因为它可能会泄露到他们的训练语料库中。
- 验证 – 没有简便的已知的方法来识别系统返回语法是有效但不正确的情况。 例如，如果用户询问“平均”值，但系统运行 AVG而不是选择名为“average_price”的列。
这篇关于为什么自然语言转SQL(text to sql)在企业中较难落地的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
