在银行数据仓库中部署AI代理：关键不在模型

披露：我们运营着几家AI企业，为企业提供AI工程服务。这是客户项目，名称已隐去。东南亚一家零售银行请我们帮助其分析师用英语提问，从仓库中获取答案。基本就是文本转SQL。十张表，858列，命名惯例混乱如常。第一版是最直接的方案。在提示中放入架构，模型编写SQL，运行并显示表格。在演示中运作良好，但第二周就开始摇晃。看似正确的连接实则错误。过滤条件用了错误的日期列。对数据无法回答的问题给出自信的答案。将其推向生产的关键因素，按影响排序：每个问题生成三个候选查询，并行处理，然后由一个独立的验证器读取问题、架构和所有候选，选择其一或全部拒绝。拒绝是一个功能。在用户测试中，'我无法从可用表中回答这个问题'每次都比错误的答案更受欢迎。任何模型变更前都有一个硬性关卡。他们的治理规则是，未经评估运行ID和指定审批者同意，任何人不得更换模型，即使是更便宜的。我们与分析师一起构建了一个包含60个问题的评估集，将标准设为85%的正确率，中位数时间低于9秒。当前模型通过了。两款更便宜的模型未通过，若没有这个关卡，我们可能会凭感觉发布其中一个。对架构前缀进行提示缓存。提示的静态部分有9到11k令牌。缓存它比我们对提示所做的任何改进都更有效降低了每个问题的成本。现在他们希望将整个系统部署在自家VPC内的自托管模型上，以确保数据驻留。我们报价：按他们的使用量，托管API每月约一千美元，匹配的GPU服务器每月3到9千美元，再加上几周工程师时间用于OpenAI兼容适配器。对银行来说这仍是合理选择。但'自托管更便宜'的说法在电子表格前站不住脚。诚实的总结：模型从来不是难点。验证器、评估集以及未经证明不得更改的规则才是。乐意在评论区深入探讨任何部分。