背景痛点传统智能客服的困境与AI带来的曙光在接触智能客服项目之前我对传统IVR交互式语音应答系统的印象还停留在“按1转人工按2查询余额”的机械式交互上。这类系统最大的痛点在于对话逻辑完全基于预设的树状结构一旦用户的问题稍微偏离预定路径系统就会陷入“抱歉我没听懂”的循环最终只能依赖人工坐席。更具体的问题包括意图识别僵化传统系统依赖关键词匹配或简单的NLU自然语言理解模型只能处理有限、固定的句式。当用户说“我想查一下上个月的话费”和“帮我看看七月花了多少钱”时系统可能无法识别这是同一个意图。多轮对话状态维护困难实现一个需要多次信息确认的业务如修改套餐需要开发者手动设计复杂的对话状态机DSM代码臃肿且难以维护。上下文感知缺失用户中途切换话题或进行指代如“这个服务”指代前文提到的某项业务传统系统无法关联历史对话体验割裂。开发与运维成本高语音识别ASR、语音合成TTS、对话逻辑需要分别对接不同服务集成复杂问题排查链路长。而大语言模型LLM的出现让我们看到了解决这些问题的全新路径。它强大的上下文理解和生成能力恰好可以弥补传统规则系统的不足。我的目标就是构建一个以FreeSWITCH为通信核心以LLM为“大脑”的新一代智能客服系统。为什么选择FreeSWITCH架构选型深度对比在开源通信领域Asterisk和Kamailio是另外两个常见选择。经过详细的技术调研我们最终选择了FreeSWITCH主要基于以下几点核心优势原生的高性能WebRTC支持mod_verto这是决定性因素。我们的系统需要支持网页一键呼叫免插件接入。FreeSWITCH的mod_verto模块提供了高效的WebRTC信令和媒体处理能力与SIP协议栈深度集成性能损耗远低于通过网关转接的方案。统一、清晰的内部架构FreeSWITCH内部使用sofia作为SIP协议栈媒体处理通过核心的switch_core统一调度模块化设计清晰。相比之下Asterisk的模块间耦合度更高在处理复杂媒体流时调试更困难。强大的脚本与控制接口通过Event SocketESL或mod_lua我们可以用Python、Lua等语言从外部精细控制每一通呼叫的流程这为我们集成AI逻辑提供了极大的灵活性。活跃的社区与商业支持FreeSWITCH拥有非常活跃的社区和成熟的商业公司支持遇到生产环境下的棘手问题时更容易找到解决方案或支持。下图展示了我们基于FreeSWITCH构建的系统核心通信链路核心模块设计与实现1. WebRTC网关与SIP协议栈的深度集成我们的客户端通过WebRTC直接连接FreeSWITCH的mod_verto。关键在于配置verto.conf.xml和sofia的profile确保媒体流能正确路由。关键配置点在verto.conf.xml中需要正确配置bind-local的地址和端口并开启secure-media和secure-signaling以支持WSS和SRTP。对应的SIP profile例如internal需要配置相同的RTP端口范围并开启rtp-autoflush和rtp-timeout-sec以优化媒体流释放。外部控制逻辑Python ESL示例 我们启动一个Python守护进程通过ESL监听CHANNEL_ANSWER、CHANNEL_HANGUP等事件并在通话建立后启动AI处理协程。import ESL def esl_event_handler(event): event_name event.getHeader(Event-Name) uuid event.getHeader(Unique-ID) if event_name CHANNEL_ANSWER: # 通话应答启动AI处理协程 asyncio.create_task(handle_ai_call(uuid)) elif event_name CHANNEL_HANGUP: # 通话挂断清理资源 cleanup_call_resources(uuid) # 连接FreeSWITCH ESL con ESL.ESLconnection(localhost, 8021, ClueCon) if con.connected(): con.events(plain, ALL) while True: e con.recvEvent() if e: esl_event_handler(e) else: print(无法连接到FreeSWITCH ESL) # 在实际生产中这里应加入重试和告警逻辑2. 语音流实时分块与ASR接口设计为了降低LLM处理的延迟我们采用“流式ASR 增量处理”的策略。FreeSWITCH可以通过mod_av或mod_media_bug将双向音频流实时转发给我们的处理服务。实现步骤挂载Media Bug在通话应答后通过ESL命令uuid_audio给频道挂载一个media bug将音频流发送到指定的TCP/WebSocket服务端。# 通过ESL发送命令 cmd fuuid_audio {channel_uuid} start start tcp://127.0.0.1:8084 con.api(cmd)音频分块与缓冲服务端接收原始的PCM或G.711音频流。我们设置一个约200ms的缓冲区具体时长需根据ASR模型调整当缓冲区满或检测到静音VAD时将音频块发送给流式ASR服务如阿里云、腾讯云或开源的Vosk。import asyncio import websockets from collections import deque class AudioBuffer: def __init__(self, chunk_duration_ms200, sample_rate8000): self.buffer deque() self.chunk_size int(sample_rate * chunk_duration_ms / 1000) * 2 # 16bit PCM self.sample_rate sample_rate def add_packet(self, audio_data: bytes): self.buffer.append(audio_data) # 简单累加判断实际生产环境应用更精确的计时 if sum(len(d) for d in self.buffer) self.chunk_size: chunk b.join(self.buffer) self.buffer.clear() return chunk return None async def handle_audio_stream(websocket, path): buffer AudioBuffer() async for message in websocket: # message 为从FreeSWITCH接收的音频包 chunk buffer.add_packet(message) if chunk: # 将chunk发送给ASR服务获取实时文本 asr_text await call_asr_service(chunk) if asr_text and asr_text.strip(): # 将文本放入LLM处理队列 await llm_input_queue.put((channel_uuid, asr_text))异常处理网络抖动可能导致音频包乱序或丢失。我们在ASR客户端实现了简单的重试和超时机制并在连续多次失败后向用户播放“网络不稳定”的提示音并尝试重建媒体流。3. 大模型对话状态机实现这是系统的“大脑”。我们不希望每次都将完整的对话历史发送给LLM成本高且可能超长而是实现了一个带压缩功能的对话状态机。核心数据结构class DialogueState: def __init__(self, call_id: str): self.call_id call_id self.history [] # 存储原始对话轮次 [(‘user‘, ‘text‘), (‘ai‘, ‘text‘)] self.compressed_summary ““ # 压缩后的历史摘要 self.context { # 业务上下文如订单号、用户身份等 ‘intent‘: None, ‘slots‘: {}, ‘step‘: ‘greeting‘ } def add_interaction(self, speaker: str, text: str): 添加一次交互并触发压缩判断 self.history.append((speaker, text)) if len(self.history) 6: # 历史超过3轮一问一答为一轮则触发压缩 self._compress_history() def _compress_history(self): 调用LLM对早期历史进行摘要压缩 # 构建压缩提示词 prompt f“““请将以下对话压缩成一段简洁的摘要保留关键事实和用户意图 {‘\n‘.join([f‘{s}: {t}‘ for s, t in self.history[:-4]])} 摘要”“” # 调用LLM的摘要接口使用较小、较快的模型 summary call_llm_summarize(prompt) self.compressed_summary summary # 保留最近两轮原始对话 self.history self.history[-4:] def get_prompt_for_llm(self, current_user_input: str) - str: 生成发送给主LLM的完整提示词 full_context f“““ 你是智能客服助理。以下是本次对话的摘要背景{self.compressed_summary} 最近的对话历史 {‘\n‘.join([f‘{s}: {t}‘ for s, t in self.history])} 当前用户说{current_user_input} 请根据以上信息进行友好、专业的回复。如果需要询问更多信息来澄清请直接提问。 回复时不要提及‘摘要背景‘等词。 ”“” return full_context工作流程收到ASR转换后的用户文本。根据call_id找到对应的DialogueState对象调用add_interaction(‘user‘, text)。调用state.get_prompt_for_llm(text)生成提示词发送给主LLM如GPT-4, Claude, 或微调后的开源模型。收到LLM回复后调用add_interaction(‘ai‘, response)。将回复文本通过TTS转换后经由FreeSWITCH播放给用户。性能优化实战1. 网络抖动与语音延迟JitterBuffer的魔法在IP语音通信中网络抖动Jitter是影响音质的主要元凶。FreeSWITCH的JitterBuffer可以缓存一定量的语音包平滑播放但配置不当会增加延迟。关键配置在SIP profile或全局vars.xml中!-- 设置自适应抖动缓冲区最小延迟20ms最大120ms -- param namejitterbuffer-len value20-120/ !-- 启用丢包隐藏(PLC)在网络丢包时尝试修复音质 -- param namejitterbuffer-plc valuetrue/我们的调优经验内网环境可以将最大值设小如60ms降低延迟。公网环境建议使用20-120或40-200在延迟和抗抖动之间取得平衡。通过fs_cli运行show calls命令观察jitter和delay值作为调优依据。2. 成本控制基于Token计费的模型调用策略直接使用GPT-4等商用API成本是必须考虑的问题。我们设计了分级调用策略意图路由层首先用一个轻量级、低成本的文本分类模型或基于Embedding的相似度匹配判断用户意图。如果是“查询天气”、“讲个笑话”等通用意图路由到成本较低的通用对话模型如较小的开源模型。业务处理层如果识别为“办理业务”、“投诉建议”等关键意图则路由到高能力的付费模型如GPT-4。缓存与复用对于常见问题如“营业时间”将LLM的回复结果缓存起来下次直接命中缓存避免重复调用。Token预算监控为每个会话设置Token预算当消耗接近阈值时主动引导用户转向人工服务或简化回复。避坑指南那些我们踩过的“坑”1. DTMF信号与语音流的冲突在用户输入银行卡号、密码时DTMF电话按键音是重要输入方式。但FreeSWITCH中DTMF可以通过RFC2833带内或SIP INFO带外多种方式传递容易与语音流混淆导致ASR误识别为数字读音。解决方案在Dialplan中明确设置DTMF模式为info或rfc2833并统一选择一种。在ASR处理前增加一个DTMF检测过滤器。如果检测到有效的DTMF事件则将该时间段内的音频流丢弃不发送给ASR并直接记录按键值到对话上下文中。在播放“请输入密码”等提示音后临时调高DTMF检测的灵敏度并短暂关闭ASR。2. 模型服务冷启动预热我们的LLM服务部署在Kubernetes上支持自动扩缩容。当突发流量到来新Pod启动时加载大型模型如7B参数模型可能需要30秒以上导致呼叫排队超时。预热方案水平预热部署一个独立的“预热服务”。该服务监控HPA水平Pod自动扩缩器的决策在新Pod创建前即通过Service Account请求一个虚拟预测触发模型加载。垂直预热在Pod的readinessProbe中不仅检查端口是否就绪还添加一个检查端点该端点执行一次极小的模型推理如对“你好”生成回复成功后才标记Pod就绪接入流量。缓存预热将通用的系统提示词System Prompt在服务启动时即完成Token化并缓存减少第一次请求的处理时间。安全考量通信与数据的双重防护1. SRTP加密实现为防止语音流被窃听我们强制启用SRTP安全实时传输协议。FreeSWITCH配置!-- 在SIP profile中 -- param nametls valuetrue/ param nametls-bind-params valuetransporttls/ param nametls-cert-dir value/path/to/certs/ param namesrtp-crypto-suite valueAES_CM_128_HMAC_SHA1_80/ !-- 加密套件 -- param namesrtp-global-crypto-suite valueAES_CM_128_HMAC_SHA1_80/ param namesrtp-secure-media valuetrue/ !-- 强制SRTP --WebRTCVerto客户端在连接时必须使用wss://协议并在SDP协商中支持SRTP。2. PCI DSS合规要点如果客服系统涉及支付需要关注PCI DSS支付卡行业数据安全标准。我们的做法是隔离将处理支付信息的DTMF输入流程独立到一个专用的、逻辑隔离的FreeSWITCH context中该context的录音、日志单独存储。不存储绝对不在日志、录音或数据库中完整记录卡号、CVV等敏感信息。DTMF按键音在内存中组合成完整信息后立即通过加密通道提交给支付网关随后在内存中清除。审计所有对支付相关Dialplan和ESL接口的访问都有完整的、不可篡改的审计日志。总结与开放性问题经过几个月的开发和迭代这套基于FreeSWITCH与大模型的智能客服系统已经稳定服务了我们的线上业务。它显著提升了应对复杂问题的能力用户满意度调查中“问题一次性解决率”有了大幅提高。然而一个核心的矛盾始终存在如何平衡大模型推理延迟与对话流畅性LLM生成文本需要时间尤其是长回复。虽然流式TTS可以边生成边播放但用户说完到AI开始回复之间的“思考时间”First Word Latency如果超过1.5秒就会产生明显的对话卡顿感。我们目前的策略是快速确认在LLM开始生成时先播放一个简短的“嗯”、“好的”等语气词让用户知道系统已接收。分句流式TTS与LLM的流式输出结合不是等整段话生成完再TTS而是每生成一个完整句子就立即送入TTS引擎缩短首句延迟。本地化小模型对于非常常见的问答对训练一个极小的、能在100ms内响应的本地模型作为“快速响应通道”。但这还不够。未来我们正在探索“预测性生成”和“延迟补偿”等更前沿的方向。例如能否在用户说话接近尾声时模型就开始预测可能的回复开头或者在网络延迟不可避免时通过调整播放语速来微妙地“追赶”时间这些都是非常有趣且具有挑战性的工程问题。技术的道路没有尽头每一次对延迟的优化都是对更好用户体验的追求。希望我们在这条路上的实践和思考能给你带来一些启发。