AI团队把贷款模型做到84%准确，最后卡在未婚与已婚的批准率差

Karan Shingde用Google ADK和Gemini搭了一个自动ML团队。项目在Google Cloud上跑，有视频演示，也有公开的GitHub仓库。先看它怎么工作。

团队分四个角色。Analyst先看数据，找什么在驱动结果。Engineer做特征、训练模型。Skeptic找泄漏、不公平特征和弱模型。你是第四个角色，批准特征，决定什么上线。项目里还有一个Chat Analyst，回答关于数据、模型和线上流量的问题，答案带表格和图表。

关键设计在harness。agent不直接读CSV猜结论。它们写Python、跑代码，从输出里做判断。harness管四件事：给agent工具并限制权限，检查每一步交接，独立给模型打分，把agent代码放进隔离进程。一个规则贯穿整个系统：没有agent给自己的模型打分。模型由harness重新训练，在同一批未见测试申请上评分。

贷款审批例子。训练集614条历史申请，测试集367条模拟线上流量。错误批准的成本是错误拒绝的两倍。模型按每千次申请的损失排名。Logistic regression准确率84%，损失378。XGBoost 388，Random forest 447。全部批准所有人的损失是641。上线候选模型比全部批准省41%。

Skeptic在特征阶段标记Gender和Married，贷款方没有公平理由用它们。Karan保留两条修复建议，让工程师移除。模型阶段Skeptic说工作“Sound”，但指出未婚申请人批准率64%，已婚80%，低于0.8的公平性门槛。harness要求人决定。Karan知道这个缺口，仍把Logistic regression上线为v1。这是公开数据集的demo，不是真实放贷模型。真实贷款方应该先修缺口。

人类在环有两个默认关口：特征审核和上线决定。每个阶段Skeptic评审一次，不完整的工作退回一次。公平性警告的模型不会自行上线。所有决定记录是谁做的。

版本和部署。feature store、model registry和整条流水线都版本化。上线模型走/predict，回滚一键。下一次运行从上次的代码和反馈继续。GCP上，Agent Runtime托管后端，Cloud Run跑console，Cloud Storage存运行记录、模型和特征，Terraform和GitHub Actions做部署，Cloud Trace和BigQuery看追踪与提示响应。

成本控制。一次run用50次工具调用、328k Gemini 3.5 tokens，54%来自缓存。这次运行里每个agent都跑Gemini 3.5 Flash。agent工作时间15.7分钟，整次运行27.7分钟，中间在等人审核。三个做法压成本：把briefing前置，减少来回；长对话里的旧输出压成一行摘要；每个agent固定指令走prompt caching。成本大头是对话历史，不是提示词。

Karan的几条经验：pipeline演示更好看，因为把决策从agent手里拿走。不要让agent报告自己的分数。给Skeptic设上限和停止规则。凭证要早处理。Agent Runtime的请求限制影响console通信，共享存储迫使单服务器。这个模式不限于ML团队，换成SRE团队也能用：一个agent提议修复，另一个agent证明修复有问题，人批准生产变更。

项目代码：https://github.com/kmeanskaran/auto-ml-adk/

Agents CLI quickstart：https://google.github.io/agents-cli/guide/quickstart-tutorial/

ADK文档：https://adk.dev/get-started/python/

原推：https://x.com/kmeanskaran/status/2119817320810057827

原文是Karan与Google Cloud的官方合作内容。