Ringg 的 AI 智能体每月处理 700 万通电话，最高自主解决 65% 的客户请求

平台以多模型分工的方式运行：GPT‑4.1 承担大部分实时语音与聊天流量，GPT‑5.6 Luna 在性能、延迟或性价比更合适时使用，GPT‑5.6 Terra 负责通话后摘要与情感分类，GPT‑5.6 Sol 支持评估、提示改进与模型即裁判工作流。 与单一模型承担全部任务的做法不同，这里把实时交互、事后分析与评估改进拆给不同模型，并按任务需求路由。 文中给出了各模型的具体分工描述与路由逻辑，属于平台架构层面的说明，未提供逐模型的对比实验数据。

在通话后分析工作流的评估中，GPT‑5.6 Terra 与 Gemini 2.5 Flash 等替代方案对比后胜出，Ringg 因此把摘要与情感分类迁移到 Terra，在保持高准确率的同时显著改善单位经济性。 这是文中唯一给出明确对比对象的模型评估结果，把模型选择与成本结构直接挂钩。 文中说明评估使用历史对话与模拟客户流程，并提到 Terra 在常见区域语言上达到最高 97% 的准确率，但未披露样本规模与统计细节。

在客户侧，智能体最高可自主解决 65% 的常规咨询；Policybazaar 连接超过 57,000 个客户请求、67% 通话无需人工介入，平均响应时间从 8–12 分钟降至 60 秒以内；Practo 实现 85% 首次呼叫解决率、响应低于三秒、运营成本下降 70%，每天完成超过 1,000 次预约；Groww 对 IPO、期货与期权相关咨询的自助解决率为 72%，平均处理时间两分钟。 这些是具体客户部署后的运营指标，把平台能力落到可衡量的业务结果上。 均为文中引述的客户侧运营数据，属于部署方报告的结果，未提供独立审计或对照实验说明。

工程上，系统在上下文接近约 80,000 tokens 时生成结构化摘要以延续长对话；模型先经历史对话与模拟流程离线测试，再进入小比例生产流量；生产路由器跨区域监控延迟与端点健康并在端点不可用或超过延迟阈值时切换流量。 把上下文管理、灰度发布与流量切换作为平台可靠性的组成部分一并描述。 属于系统设计与运维流程说明，文中未给出这些机制对应的故障率或延迟分布数据。

该材料面向正在评估企业级语音与聊天智能体落地的团队，尤其是印度等需要多语言与跨渠道服务的高并发消费业务场景。它说明的是在具备编排层、知识检索、灰度发布与延迟路由等配套工程的前提下，把实时交互、事后分析与评估改进分配给不同模型可以同时兼顾质量、延迟与成本。文中提到的浏览器智能体与跨渠道上下文层仍处于开发阶段，其适用范围有待后续披露。

文中未披露模型评估的样本规模、统计方法与对照设置，也未说明 65% 解决率与 4.8 CSAT 的统计口径与时间窗口；客户侧指标由部署方报告，缺少独立验证说明。此外，浏览器智能体与跨渠道上下文层尚在开发中，其实际表现与适用条件有待后续信息补充。