Fun-ASR-MLT-Nano-2512开发者案例：集成至RPA流程实现语音工单自动录入-平芜编程栈

Fun-ASR-MLT-Nano-2512开发者案例：集成至RPA流程实现语音工单自动录入

想象一下这个场景：客服中心每天涌入成百上千个电话，客服人员一边接听，一边手忙脚乱地在电脑上记录工单信息。客户地址说快了没记全，产品型号听错了，问题描述敲了半天还没打完……一通电话下来，客服累，客户等得急，录入的信息还可能出错。

这就是很多企业工单处理流程的真实写照。人工录入不仅效率低下，容易出错，还占用了大量的人力成本。有没有一种方法，能让电话里的语音自动变成工单系统里规整的文字记录？

今天，我们就来分享一个真实的开发者案例：如何将阿里通义实验室的Fun-ASR-MLT-Nano-2512语音识别模型，无缝集成到RPA（机器人流程自动化）流程中，打造一个全自动的语音工单录入系统。通过这个案例，你会看到，一个先进的AI模型如何从技术演示，变成解决实际业务痛点的生产力工具。

1. 项目背景与核心痛点

在我们深入技术细节之前，先来看看我们试图解决的具体问题。

我们合作的是一家大型家电企业的售后服务中心。他们原有的工单流程是这样的：

客户拨打400热线电话。
客服人员接听，询问客户信息、产品问题、预约时间等。
客服在接听的同时，在CRM系统中手动新建工单，并逐项填写。
通话结束后，客服可能需要回听录音，补充或修正工单信息。

这个流程存在几个明显的痛点：

效率瓶颈：一通5分钟的电话，客服录入和整理信息可能需要额外花费3-5分钟。
信息误差：人工记录难免听错、记漏，尤其是地址、型号等关键信息。
体验不佳：客户需要等待客服录入，或重复口述信息。
人力成本高：大量熟练客服被束缚在重复的录入工作上。

我们的目标很明确：让系统“听懂”电话录音，自动提取关键信息并填写工单，将客服从机械的录入工作中解放出来，专注于与客户的沟通和服务。

2. 为什么选择Fun-ASR-MLT-Nano-2512？

市面上语音识别方案不少，为什么最终锁定了Fun-ASR-MLT-Nano-2512？这源于我们对业务场景的深度分析和模型特性的仔细考量。

首先，业务场景提出了几个硬性要求：

高准确率：工单信息，如地址、电话号码、产品序列号，必须100%准确，一个数字都不能错。
多场景适应：客户可能在嘈杂的街头、信号不好的家里、或带有地方口音，模型需要足够鲁棒。
实时性要求：最好能在通话结束后几分钟内就生成初步工单，不能等太久。
成本可控：需要支持私有化部署，保障数据安全，且硬件成本不能过高。

Fun-ASR-MLT-Nano-2512的几大特性，正好切中了这些需求：

精准的多语言与方言识别：它支持31种语言，包括中文、英文、粤语等。对于我们的客户来说，这意味着不仅能处理普通话，还能很好地识别带地方口音的普通话，甚至直接处理粤语客户的来电，这是很多通用模型做不到的。
“Nano”级别的轻量化：2512版本是一个约8亿参数的“纳米”模型，大小仅2GB左右。相比动辄数十GB的大模型，它可以在消费级GPU（甚至高性能CPU）上流畅运行，极大地降低了部署门槛和硬件成本。
出色的噪声抑制能力：官方数据显示其在远场高噪声环境下的识别准确率仍能达到93%。这对于手机通话录音中常见的环境杂音、电流声有很好的过滤效果。
开箱即用的易用性：项目提供了Gradio Web界面和清晰的Python API，让我们能快速验证效果并集成，大大缩短了开发周期。

简单来说，它就像一个“专精于听力”的尖子生，虽然体积不大，但在听懂人话这件事上，能力突出且全面，非常适合嵌入到像RPA这样的自动化流程中充当“耳朵”。

3. 系统架构与集成方案

整个自动化工单系统的核心，就是让RPA机器人调用Fun-ASR模型。下面这张图清晰地展示了数据是如何流动的：

graph TD A[客户来电录音] --> B[RPA流程触发器]; B --> C[录音文件预处理]; C --> D[调用 Fun-ASR API 识别]; D --> E[文本后处理与关键信息提取]; E --> F[自动填写CRM工单]; F --> G[人工审核/派单]; H[Fun-ASR 模型服务] -- 提供识别能力 --> D; style H fill:#e1f5fe

整个流程可以分解为以下几个关键步骤，我们将结合代码进行说明。

3.1 第一步：环境部署与模型启动

我们选择将Fun-ASR部署在一台内网的Linux服务器上，作为独立的API服务。这样，任何经过授权的内部系统（如RPA服务器）都可以调用它。

根据项目提供的部署说明，过程非常 straightforward：

# 1. 克隆代码（假设已内部托管） cd /opt/services git clone your-internal-repo/Fun-ASR-MLT-Nano-2512 cd Fun-ASR-MLT-Nano-2512 # 2. 安装依赖 pip install -r requirements.txt apt-get install -y ffmpeg # 用于音频处理 # 3. 启动模型服务（这里我们改为启动一个FastAPI服务，便于RPA调用） # 我们创建了一个简单的 app_api.py nohup python app_api.py > /tmp/funasr_api.log 2>&1 & echo $! > /tmp/funasr_api.pid

其中，app_api.py是我们编写的一个轻量级HTTP服务包装器，核心代码如下：

# app_api.py from fastapi import FastAPI, File, UploadFile, HTTPException from funasr import AutoModel import tempfile import os import logging from typing import List app = FastAPI(title="Fun-ASR工单识别服务") # 全局加载模型，利用其缓存机制 print("正在加载Fun-ASR-Nano模型，首次加载较慢...") model = AutoModel( model="/opt/services/Fun-ASR-MLT-Nano-2512", # 模型路径 trust_remote_code=True, device="cuda:0" # 服务器有GPU，使用GPU加速 ) print("模型加载完毕！") @app.post("/recognize") async def recognize_speech( audio_file: UploadFile = File(...), language: str = "中文", # 默认中文，可从RPA传递参数 use_itn: bool = True # 是否启用逆文本归一化（将“一二三”转为“123”） ): """ RPA调用接口：上传音频文件，返回识别文本。 """ if not audio_file.content_type.startswith('audio/'): raise HTTPException(status_code=400, detail="请上传音频文件") # 保存上传的临时文件 suffix = os.path.splitext(audio_file.filename)[1] with tempfile.NamedTemporaryFile(delete=False, suffix=suffix) as tmp: content = await audio_file.read() tmp.write(content) tmp_path = tmp.name try: # 调用模型识别 res = model.generate( input=[tmp_path], cache={}, batch_size=1, language=language, itn=use_itn # 对数字、日期等进行标准化，对工单很重要 ) # 提取识别结果 recognized_text = res[0]["text"] return {"status": "success", "text": recognized_text} except Exception as e: logging.error(f"识别失败: {e}") return {"status": "error", "message": str(e)} finally: # 清理临时文件 os.unlink(tmp_path) if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=7861) # 使用7861端口，与Gradio界面错开

启动后，我们的RPA机器人就可以通过向http://your-server-ip:7861/recognize发送POST请求来调用语音识别服务了。

3.2 第二步：RPA流程设计与关键环节

RPA部分我们使用了主流的UiPath平台。其核心流程设计思想是模拟人工操作，但由机器自动执行。

流程关键节点如下：

监听与触发：RPA机器人监控指定的录音文件存储目录（由电话系统自动推送），一旦有新的.wav或.mp3文件生成，即触发流程。
调用识别服务：RPA活动“HTTP请求”调用我们刚才部署的FastAPI接口，上传音频文件。
- 这里有个细节：我们会在请求中带一个参数language=auto。虽然Fun-ASR支持自动检测，但对于工单场景，我们更希望明确指定中文，并在后续版本中，根据来电区号（如0755）尝试判断是否使用粤语，以提升准确率。
接收与解析结果：接收API返回的JSON，提取出text字段，即完整的识别文本。
文本后处理与信息提取：这是从“听到”到“读懂”的关键一步。原始的识别文本是一大段话，我们需要从中提取出结构化工单字段：
- 客户姓名：通过正则表达式匹配“我是XXX”、“我叫XXX”等模式。
- 手机号码：通过正则表达式提取11位数字串。
- 地址：利用NLP工具（如Jieba分词+自定义词库）或关键词（“住在”、“地址是”）定位地址信息段。对于常见小区名、街道名，我们建立了本地词典来提升识别精度。
- 产品型号与问题：通过关键词（如“空调”、“冰箱”、“不制冷”、“漏水”）匹配产品品类和故障类型，并提取描述性句子。
自动填写CRM：RPA机器人自动登录企业内部CRM系统，在新建工单页面，将提取出的信息填入对应字段。
异常处理与人工审核：设置置信度阈值。如果提取的关键信息（如手机号）格式明显不对，或无法提取到必要信息，则该工单自动转入“待审核”队列，由客服人员人工处理录音和文本。

3.3 第三步：效果优化与实战技巧

在集成过程中，我们遇到并解决了一些典型问题，这些经验或许对你有帮助：

音频预处理提升识别率：电话录音通常是8kHz单声道。虽然模型支持，但我们发现先使用ffmpeg统一转换为16kHz、单声道、PCM编码的WAV格式，能带来更稳定的识别效果。这个预处理步骤可以放在RPA调用API之前。
```
# RPA或预处理服务中可执行的命令 ffmpeg -i input.mp3 -ar 16000 -ac 1 -c:a pcm_s16le output.wav -y
```
利用itn（逆文本归一化）功能：这是Fun-ASR的一个宝藏功能。开启后，它能将“我家的地址是中山路一百二十三号”自动转换为“我家的地址是中山路123号”。对于工单中的地址、数量信息，标准化后的数字格式更利于后续的信息提取和系统录入。
分段识别处理长录音：单通客服电话可能长达10分钟。虽然模型能处理，但为追求更佳实时性，我们让RPA先将长录音按静音检测（VAD）切分成多个短段落（如每段30-60秒），然后并发或顺序调用识别接口，最后将文本拼接。这模拟了客服边听边记的过程。
构建业务专属词库：在模型层面，Fun-ASR支持热词增强。我们将公司产品型号（如“KFR-35GW/BpR3TYC1+1”）、常见小区名、街道名、专业故障术语等做成热词列表，在调用API时传入，能显著提升这些专有名词的识别准确率。
```
# 在调用generate时，可以传入hotword_list hotwords = "格力空调 KFR-35GW 不制冷 漏水 中山花园" res = model.generate( input=[audio_path], cache={}, batch_size=1, language="中文", itn=True, hotword=hotwords # 传入热词字符串 )
```

4. 落地成效与价值分析

系统上线并稳定运行一个季度后，我们看到了实实在在的效果：

效率飞跃：平均每张工单的录入时间从人工的3-5分钟，缩短到系统的1分钟以内（主要耗时在音频上传和网络传输）。客服人员的工作重心彻底转向了沟通与问题解决。
准确率达标：在常规通话环境下，关键信息（手机号、地址核心部分）的提取准确率超过98%。剩下2%的异常情况落入人工审核流程，形成了有效的“人机协同”。
成本节约：初步估算，为该客服中心节省了相当于3个全职录入岗位的人力成本，投资回报周期在6个月左右。
体验提升：客服工作满意度提高，客户也因信息确认更快捷、更准确而感到服务更专业。