机器人外呼

一、立项背景与目标
背景：传统人工外呼效率低（有效通话占比不足40%）、成本高、情绪影响大；合规监管趋严（需全程录音、拒绝后禁呼）；AI与大数据技术成熟，驱动行业向智能化转型。
目标：实现批量自动拨号，接通率提升40%以上，人力成本降低50%~70%；全程录音可追溯，自动标记客户意向，支持黑名单与全量质检，形成数据闭环优化营销策略。

二、核心功能模块
客户管理：批量导入、去重清洗、黑名单过滤、360°画像打标。
智能呼叫：预测式/预览式/预约型拨号，并发控制与智能重拨。
语音交互：ASR+NLP+TTS引擎，多轮对话、意图识别、情绪分析。
任务调度：按地域/等级分配，实时监控坐席状态，话术模板管理。
录音质检：全程自动录音、存档，全量合规复查与风险告警。
数据报表：实时监控接通率、转化率等200+指标，自动生成工单并反馈优化。

三、业务流程与路径
数据准备：导入客户信息 → 号码清洗 → 构建画像 → 创建外呼任务（配置话术、时间、策略）。
智能拨号：调度引擎分配号码 → 自动过滤无效号码 → 按策略发起呼叫（支持重拨）。
交互识别：ASR转写 → NLP理解意图 → 多轮对话 → 标记意向等级（高/中/低），高意向可转人工。
录音质检：全程录音存档 → 质检引擎合规审查 → 拒绝号码加入黑名单。
数据归集：通话记录与分析报表自动生成 → 高意向创建CRM工单 → 结果反哺筛选规则和话术，形成闭环迭代。

一、整体架构与设计思路
架构分层：接入层（SIP协议栈）→ AI能力层（ASR/NLP/TTS）→ 业务逻辑层（任务调度/状态机）→ 数据层（MySQL+Redis+clickhouse）。前后端分离，异步通信（Kafka），容器化部署（docker）。
技术栈：
前端：Vue3 + TypeScript + Vite +element plus + Pinia + ECharts + WebSocket/janus
后端：golang+ gorm+ FreeSWITCH + Redis + MySQL + Elasticsearch + Kafka + Docker+clickhouse
设计核心：分层解耦、实时双向通信、高并发调度。

二、我负责的模块与量化成果
前端全包（坐席工作台、任务管理后台、实时监控仪表盘、录音质检界面），后端负责任务调度、客户管理、报表等25+ API接口。
量化结果：
前端代码量约2.8万行（Vue3+TS），交付12个核心页面
坐席操作响应＜300ms，状态同步准确率99.5%
10万级号码导入渲染＜2s，实时仪表盘延迟＜5s
上线后坐席日均有效外呼量从200通提升至350通+

三、遇到的难点与解决方案
1. WebSocket假连接导致状态不同步
问题：网络切换时连接断开但前端未感知，座席状态异常。
解决：增加15秒心跳+连续3次超时重连，每次操作前主动确认状态。
结果：问题彻底解决，稳定运行。
2. 并发通话页面卡顿与内存溢出
问题：多路通话DOM节点堆积，帧率降至15fps，内存持续攀升。
解决：共享WebSocket连接（sessionId区分）、虚拟滚动、通话结束即销毁DOM并释放音频流。
结果：帧率提升至55fps+，内存稳定＜200MB，连续运行8小时无泄漏。
3. 振铃与接通状态判断混乱
问题：不同运营商触发事件不一致，振铃状态卡死。
解决：前端状态机兜底（超时自动判定失败），同时监听多种事件，埋点追溯。
结果：状态准确率从85%提升至99%+，投诉下降60%。
4. 高并发任务调度性能瓶颈
问题：高峰期数据库行锁导致任务获取延迟严重。
解决：迁移至Redis ZSET无锁队列，批量获取；Kafka异步解耦通话事件。
结果：调度延迟从800ms降至50ms，吞吐量提升6倍。