AI 为数据民主化创造了新的机会。通过利用语言模型理解能力，在无需 SQL 的情况下生成见解，更多用户将能够*挖掘目前埋藏在海量数据中的宝贵见解*。
上个月，Snowflake 工程副总裁 Vivek Raghunathan 在 Fully Connected 大会上讨论了开创性的 Snowflake Copilot。该视频上周已在 YouTube 公开。Wren AI 团队已在 Text-to-SQL 领域工作数月，我们从 Vivek 在最近关于 SQL LLM 的演讲中分享的诸多想法和技术中学到了很多。今天，我想整理一下从该视频中获得的思考和心得。我希望这能帮助像我们一样的其他开发者更快地共同加速 Text-to-SQL 的创新！
Wren AI 的使命是通过将 Text-to-SQL 能力带到任何数据源和行业来民主化数据。我们坚信要让任何人都能轻松访问数据。
如果您对完整视频感兴趣，请查看下方链接！
现在，让我们开始吧！
Vivek 谈到了 AI 在数据分析领域的当前和未来。
但未来将演变为面向业务用户的全面对话式导航；这将使不了解 SQL 的个人能够简单地用自然语言提问并获得答案。
目标是创建一个支持交互式数据探索和可视化的界面，最终成为用户可以信赖并高效完成任务的 AI。
这也是我们在开发 Wren AI 中所经历的。我们认为当前的技术创新仍有局限性，难以达到面向所有业务用户的全面 AI 导航；这就像我们在自动驾驶汽车领域所经历的一样。多年来，汽车制造商一直在推出自动辅助驾驶功能来与驾驶员协作。在证明辅助驾驶在用例中能够达到高精度和安全性之前，我们仍需要数据分析师来协助 AI。
Vivek 提到 Text-to-SQL 就像冰山问题，表面看起来很简单，但*底层却极其复杂*。
演讲引用
“我在 Twitter 上看到过无数关于此的演示，最近又看到一个。为什么不使用模式识别等标准方法和流行语？为什么不在特定模式上进行微调？Spider 排行榜上经常有新的领导者，所以为什么要在这样一个微不足道的问题上浪费时间？” 我要告诉你，没那么简单
您将很快面临的一些显而易见的挑战，这些挑战在他的演讲中有所提及
确实，一点都不简单！
Wren AI 非常专注于解决数据与语义之间的挑战；我们认为，要使 Text-to-SQL 可靠，其核心在于如何构建一个可靠的语义引擎，以响应现有数据结构之上的语义架构，例如定义语义关系、计算、聚合等，LLM 应该学习如何处理不同场景下的不同上下文，这在很大程度上依赖于一个强大的语义层。
Snowflake 从 v0 到 v4 进行了多次实验；值得庆幸的是，Vivek 大方地分享了他们在后续版本中尝试、学习和迭代的内容，以改进 Text-to-SQL 的创新。
让我们深入了解！
在演讲中，Vivek 提到
为了解决这个问题，我们从一个名为 Spider 的耶鲁数据集开始，针对这个基准优化我们的模型。我们的初始模型表现良好，但在反映真实世界使用的内部数据集上进行测试时，其准确性急剧下降。
这突显了对强大的 **语义目录检索系统** *的需求*
在 V0 版本中，他们看到使用 Spider 数据集获得了最佳模型，准确率达 82%，零样本 GPT-4（未优化）准确率达 74%，但在真实世界数据中，他们使用最佳模型的准确率骤降至 9%，使用提示优化的 GPT-4 准确率达 14%。
正是在那时，他们开始意识到**“语义目录”**的重要性，语义在数据检索中起着巨大作用，因为预训练的 LLM 对您的业务上下文一无所知，唯一的方法就是通过 RAG 提供语义。
语义是解决 Text-to-SQL 挑战的关键，也是我们在开始实现 Wren AI 时的核心设计理念。
在随后的 V1 版本中，Snowflake 团队开始思考……* 如果我们可以将网络级搜索引入企业元数据搜索，并将输出馈送到 LLM，性能可能会显著提升。
换句话说，为了解决一个更简单的问题——我们应该在这个 LLM 的上下文中打包什么——我们将首先解决一个更难的问题
我们如何将消费级网络搜索引擎应用于对话式目录搜索问题？
结果如下，Snowflake 的最佳模型从 9% 提升到 24%，GPT-4 版本也从 14%跃升到 28%。**因此，语义目录检索至关重要的直觉是正确的**。
Vivek 提到了他们在 Snowflake 如何进行对话式目录检索
在 Snowflake，用户查询进来后会经过一个查询理解层，其中包括多轮消歧和查询重写。这里运用了信息检索（IR）和自然语言处理（NLP）文献中所有已知的技巧。
在中间，我们正在将消费级搜索引擎 Neeva 应用于对话式目录检索问题。这包括稀疏和密集检索及排序技术，例如关键词检索、用于检索的双编码器 LLM、IR 排序器（其性能优于 BM25）以及用于排序的交叉编码器 LLM。
当然，所有常规的秘诀都包含在内。我们在网络和模式数据上训练这些模型，并整合了流行度、权威度和新鲜度等因素。经过大量工作，我们最终得到了一个符合我们标准的系统。
Snowflake 团队还面临另一个挑战：**评估者**。他们手动重新标注了所有内容，添加了更复杂的示例来评估性能，并根据单表 vs. 多表、简单连接 vs. 复杂连接等数据语义进行了切分。
以下是 Vivek 在演讲中分享的内容
这更能反映真实世界的使用情况，但存在一些微妙的错误。那么，问题的症结在哪里呢？对于那些编写 SQL 的人来说，这并不容易。这不仅仅是学习语法；更是学习数据的底层语义并像分析师一样思考。
我们的标注者不是高薪分析师，即使是分析师也需要一个小时来理解数据库才能编写查询。他们有一套非常结构化的流程来学习数据的组织方式。还存在许多其他复杂问题，例如表之间的连接路径可能导致问题，以及诸如沟壑陷阱（chasm traps）和扇形陷阱（fan traps）之类的现象。
换句话说，我们触及了冰山，这意味着我们必须正确地策划数据。问题确定后，解决方案就简单了：我们手动策划了所有内容。我们进行了多轮验证和交叉检查。交叉检查过程实际上比看起来更难，因为它需要真正解决问题才能确保准确性。
这一见解对我们来说相当有趣；虽然我们在实现 Wren AI 时没有进行太多检索优化。目前，我们只从向量存储中进行 Top-N 选择；我们正在研究更详细的检索技术来改进这一领域。
我们的团队也在构建内部评估数据集，其中包含单表和多表、简单连接和复杂连接等更复杂的场景，以确保解决方案在现实世界中保持准确。
欢迎就此话题开启新的讨论！我们的团队愿意进一步改进！
接下来，Vivek 分享说，尽管取得了这些进展，模型在对话能力方面仍然面临挑战。针对 SQL 任务的优化削弱了它处理对话和遵循指令的能力。
以下是他们分享的一些见解
通过这次新的清晰评估，他们看到了显著的改进，他们的基础模型从 27% 提高到 39%，使用 GPT-4 的模型从 40%跃升到 46%。
他们在尝试构建时面临的下一个挑战是构建一个对话式副驾驶，而不是一个零样本的 Text-to-SQL 解决方案。它需要处理对话，并允许分析师在进行过程中完善他们的查询。
优化系统的一部分会无意中导致整个系统的性能下降。出现了两个大问题
演讲中提到 Text-to-SQL 挑战需要采用交互式方法而非零样本方法。我们 Wren AI 也在追求这种方法，我们仍在努力改进多种体验。
通过我们的实现，我们在“增强与生成”（Augmentation & Generation）RAG 管道中实现了复杂的流程，例如验证、纠正和澄清对话，以确保 LLM 完全理解用户的意图。当然，仍有很多领域需要改进。
Vivek 分享说，他们通过混合 Text-to-SQL 任务和更通用的指令遵循任务，重新训练了 LLM 以遵循指令。他们还在一个带有协调器 LLM 的多 LLM 设置中进行了分层。
协调器模型负责与客户进行对话；这就像一种代理方法。允许它在需要编写 SQL 时使用另一个同样大的 Text-to-SQL 模型。这种智能委派任务的方法解决了许多问题。
而且数字甚至更好了，他们曾经的最佳模型是 38%，现在由于增加了指令遵循能力达到了 41%，而使用 GPT-4 加优化后评估达到了 46%。
从 46.4% 到 99%，Text-to-SQL 的目标是——为不了解 SQL 的业务用户构建一个对话式副驾驶。*这是一个机会，他们需要 99% 的准确率。*
目标是为不了解 SQL 的业务用户构建一个对话式副驾驶。*这是一个机会，他们需要 99% 的准确率。*
在 Wren AI，我们也对 Text-to-SQL 的未来充满乐观。我们相信，随着 LLM 创新以惊人的速度发展，很快我们将能够将 LLM 与语义上下文相结合，使其接近人类理解能力，从而实现数据民主化的理想世界。
这在 Snowflake 正在进行中！利用客户提供的语义上下文来理解指标、连接路径等。
期待 Snowflake 的更多分享！非常令人兴奋！
最后，Vivek 分享了他经历所有挑战后获得的关键要点和心得，整理如下。
差不多就是这些了！感谢 Vivek 和 Snowflake 团队在这次演讲中分享了许多宝贵的经验，我们从中学到了很多！
继续前进！
立即用 AI 为您的数据赋能？！
