为 AI SQL 助手实现更智能的查询路由：如何在不牺牲质量的情况下降低成本

想象一下，您的 SQL 助手就像一辆火箭，能够轻松处理复杂的查询。然而，当您意识到自己使用火箭燃料来获取一个简单的购物清单时，事情就变得不那么令人兴奋了。

这很令人兴奋，直到您收到燃料账单。突然，您意识到简单的任务不需要火箭。同样，当每个 SQL 请求，从基本查找到多模式分析，都被路由到同一个强大的 AI 模型时，会发生相同的事情。

获取 AI SQL 助手的过程通常是相同的。最初，生产力会提高：查询速度更快，样板代码消失，开发人员花在编写常规 SQL 查询上的时间减少。随着更多团队使用它，查询数量增加。当基础设施账单到来时，经济学就发生了变化。

问题在于建筑。运行可以思考执行计划、模式和复杂查询逻辑的 Frontier AI 模型的成本很高。这种价格对于具有挑战性的任务是合理的，因为每个查询的成本约为 0.03 美元。但是，当用于简单的 SELECT 语句和 CRUD 操作时，它就变得浪费了。

但是，答案不是降低模型。它是将查询发送到正确的位置。智能查询路由根据查询的复杂程度对其进行分类，并将其发送到正确的模型层次。这种方法可以在不降低输出质量的情况下将 SQL 工作负载的推理成本降低 40-70%。

本文解释了这种架构的工作原理：定义 SQL 复杂度层次、构建分类和路由管道以及测量系统运行时的实际成本质量权衡。这些模式反映了在开发 dbForge AI Assistant 中的模式感知 AI 能力时所学到的经验教训。

为什么一个模型不能适用于所有 SQL 任务

并非所有 SQL 查询在复杂性方面都相同。一个通过主键获取用户的查询和一个使用窗口函数在多个模式中重建会话漏斗的查询都是 SQL 查询，但生成它们所需的推理是非常不同的。

如果系统将它们视为相同，结果是可预测的：浪费计算。 在大多数企业工作负载中，查询大多是常规的。 简单的查找、单表读取、基本插入、语法修复。 没有什么复杂的。 将所有这些发送到前沿模型就像使用货运电梯运送一本笔记本一样。

一种思考问题的方法是将查询分为复杂度层次：

层次之间的成本差距很大。第 1 层查询的成本可能约为 0.001 美元，使用轻量级模型。同一个查询发送到前沿模型的成本约为 0.03 美元。在每天 10,000 个查询的情况下，这意味着每天 10 美元与 300 美元的差异。30 倍的差异，只是由于路由决策。

模式感知在这里也很重要。第 3 层查询不仅需要更多的计算资源，还需要上下文：表关系、外键、索引、数据库特定的语法。这种上下文必须在推理过程中注入。

将简单的第 1 层查询通过相同的重型路径运行会浪费令牌、增加延迟，并且不会提高结果。

模型选择的实用架构

路由系统通常具有四个阶段：分类、路由、执行和验证。每个阶段都有不同的作用，并且都可能以不同的方式失败。最好将它们分开考虑，然后再将整个管道组合起来。

分类是最重要的步骤。分类器接收原始 SQL 查询或将生成查询的自然语言提示，并将其分配到复杂度层次。有三种常见的方法来构建此分类器。

基于规则的分类依赖于正则表达式模式和抽象语法树解析来检测结构信号：例如表计数、嵌套深度、窗口函数、子查询或聚合运算符。这种方法快速、可预测，几乎没有开销。对于明显的案例（例如简单的 SELECT 语句和基本的 DML）通常可以在不涉及模型的情况下识别出来。

轻量级分类器模型使用一个小型语言模型来估计 SQL 复杂度。这种方法增加了一个额外的步骤，但这是整个管道中 ROI 最高的决策之一。分类器调用可能的成本约为 0.0001 美元，这很容易证明避免 0.03 美元的前沿模型调用是合理的。

在许多设置中，这些轻量级模型也可以在本地运行，有效地消除了简单用户查询的成本。它们还可以在查询生成之前对自然语言提示进行分类，这在查询尚不存在的助手工作流中很有用。

混合分类结合这两种方法。基于规则的逻辑处理明确的案例，而分类器处理模糊的中间案例：看起来中等复杂但可能需要模式感知推理来正确生成的查询。

路由发生在分类之后。但层次本身并不是唯一的因素。几个其他因素会影响查询应该发送到哪里。这些包括：

1. 模式上下文要求。一些查询需要模型了解外键关系、索引或其他结构细节。这些查询携带更多上下文，通常需要路由到更高能力的模型。
2. 延迟容忍度。面向用户的功能（如自动补全或内联建议）具有严格的延迟预算。后台任务通常没有。对于这些情况，可能可以接受更慢但更强大的模型。
3. 置信度阈值。有时分类器对层次不确定。在这些情况下，路由到更高层通常是更安全的选择。向下路由错误可能会产生错误的查询并触发重试，这通常比首先使用更强大的模型更昂贵。

验证层在代码运行后执行。验证层的任务是捕获路由错误，然后再将它们呈现给用户。在执行后，会进行检查以确保语法正确、结果合理（查询返回正确的行形状？）以及模式一致。如果结果未通过验证，系统会将其升级并再次运行查询。

在 Devart，我们在 dbForge AI Assistant 中实现路由准确性的最重要因素是将模式感知上下文构建到分类决策中。没有模式上下文，使用不明确的表名或依赖于隐式关系的查询通常会被误分类并发送到无法处理它们的更便宜的模型。解决方案是提供不仅仅是查询结构，还有一些模式元数据给分类器。

实践中的成本质量权衡：什么才是重要的

路由的商业案例仅在质量保持的情况下才成立。降低成本但损害输出质量、增加重试或降低开发人员信任的成本降低并不是节省，而是将基础设施账单的成本转移到工程时间上。三个指标决定路由系统是否真正有效。

每层查询成本建立了基线。跟踪每个层的实际支出，而不是作为混合平均值。混合平均值会掩盖路由是否有效的信息，系统将 50% 的查询路由到错误的层仍会显示较低的平均成本，而实际上会产生更差的结果。

质量评分检查正确性、完整性以及遵循 SQL 最佳实践。升级率是最直接的信号。它比任何其他指标都能更快地发现错误分类，并且显示分类器需要改进的确切位置。一个调优良好的系统应该将升级率保持在 5% 以下。分类器需要在该水平以上重新训练。它可能正在误读结构信号，或者可能没有它需要的模式上下文来区分中等复杂和复杂查询。

延迟影响检查从一个层到下一个层的响应时间，包括任何额外的分类时间。用户应该只注意到通过路由层的交互延迟 50-100 毫秒。如果分类本身成为一个问题，混合方法（规则用于明确的案例，分类器仅用于不明确的案例）可以在不失去准确性的情况下解决它。

在现实生活中，一个调优良好的路由系统可以将推理成本降低 40-60%，将升级率保持在 5% 以下，并且对于复杂查询保持高质量的输出。要节省 70% 或更多，通常需要使用较小的模型自己执行第 1 层任务。这可能有效，但也会使事情更加复杂，这并不是每个团队都愿意处理的。

“升级税”是另一个需要考虑的因素。如果路由对更便宜的模型过于苛刻，系统可能需要执行更多工作：分类器调用、初始模型调用、失败的验证、重路由和第二个模型调用。在某些情况下，这比首先使用前沿模型更昂贵。

仅查看每次调用成本会忽略这种影响。升级率必须与其一起跟踪。

工程团队的战略收获

智能路由不仅是成熟的 AI SQL 部署的好处，也是长期部署的必备条件。跳过它的团队将无法解决的预算问题与可以解决的架构问题进行交换。模式已经存在；剩下的就是决定先遵循哪些模式。

从分类器开始，而不是模型。路由层决定一切是否有效。一个调优良好的混合分类器将为您提供大部分成本节约，而不会使事情过于复杂。

使用模式上下文来帮助分类决策。对于涉及多个表之间的关系或特定于模式的推理的 SQL 工作负载，查询结构本身是不够的。分类时提供部分模式元数据可以大大提高层次准确性。

使用升级率作为主要质量信号。它比任何其他指标都能更快地发现错误分类，并且显示分类器需要改进的确切位置。

在构建分类器之前，规划验证层。了解失败的外观以及升级的原因可以使路由逻辑更干净，并使系统更好地处理边缘情况。

路由层的价值会随着开源模型的改进和本地推理成本的降低而增加。更便宜的第 1 层模型会使层之间的成本差异更大，从而使正确的分类更加有价值。今天构建的路由架构将在很长一段时间内都很有用，不仅仅是一个快速解决方案。