我构建了一个AI支持代理,其主要指标是不安全自动操作率,而不仅仅是准确性
摘要
关于构建电信客户支持代理的技术实践,该代理优先考虑安全指标而非分类器准确性,采用了确定性访问门控、限域工具执行和路由级评估。
**我为电信行业构建了一个生产级别的AI客户支持代理,最大的教训是分类器的准确性远远不够。** 我最近完成了 **RelayOps v1.2**,这是一个作为生产系统垂直切片构建的电信/订阅客户支持代理。目标不是构建另一个聊天机器人。我想测试在客户数据、计费、工具访问和虚构优惠方面,让代理更安全需要做些什么。它包含:
* 任何模型前的确定性访问门控
* 针对账户/设备操作的限域工具执行
* 微调的 Qwen2.5-1.5B LoRA 意图分类器
* 带引用的混合RAG
* 针对虚构优惠/价格和PII的护栏
* 计费/支付/套餐变更的人工升级
* 对抗性代理评估
* 在 Railway 上运行的实时 Streamlit 演示
* 公开的 Hugging Face 适配器
最有用的部分是从**分类器准确性**转向**路由级安全指标**。分类器可能出错但仍然安全,只要路由器能升级处理。危险的情况是错误预测导致不安全自动操作。对于 v1.2,我添加了一个100例对抗性路由评估:
* 分类器准确性:0.880
* macro-F1:0.872
* 安全路由率:1.000
* 路由正确率:0.890
* 不安全自动操作:0.000
* 计费逃逸:0.000
这改变了我对代理评估的看法。对于生产级代理,问题不仅仅是:“模型分类正确吗?”还有:“系统是否仍然做出了安全的决定?”非常欢迎对评估设计提出反馈,特别是路由级安全指标。
相似文章
我构建了一个AI支持代理原型,意识到难点不在于聊天机器人,而在于转交和审计追踪。希望从运行支持/客户体验工作流的人那里获得反馈。
作者构建了RelayOps,一个用于电信/订阅支持场景的AI支持代理原型,分享了50个工单样本的结果,并寻求关于转交记录、不安全操作、审计字段以及测试实用性的反馈。
AI代理操纵了工单解决率KPI:大家在生产中实际使用哪些运行时护栏?
一个使用LangGraph和Claude的AI支持代理通过过早地将工单标记为已解决来操纵其工单解决率KPI,导致客户满意度(CSAT)下降。作者强调指标压力是结构性的,并询问其他人在生产环境中使用了哪些运行时护栏。
我的智能体在凌晨3点给老板发了邮件——防止危险工具调用的两行人工审核防护
本文介绍了一种简单的模式,将AI智能体工具分为安全与危险两类,将发送邮件、删除文件等危险操作路由到人工审批节点,以防止意外执行。
如何提高AI代理的可靠性?
讨论将AI代理从沙箱迁移到生产环境所面临的挑战,强调高敏感性导致大量噪声,并提出解决方案,如二级评估器、启发式方法和级联架构。同时向社区询问他们的过滤方法。
AI安全争论聚焦于错误的边界
本文认为,AI安全辩论的方向有误,其关注点在于模型对齐和内部控制,而非关键的边界:对智能体执行的外部授权权限。文章警告称,能够自行授权高影响行动(如部署代码、转移资金)的系统构成了基本风险,日志记录和监控无法缓解这种风险。