当前位置：首页 > news >正文

文本规整ITN功能开启后，口语变书面更智能

news 2026/8/27 22:31:42

文本规整ITN功能开启后，口语变书面更智能

在语音识别技术日益渗透到客服、会议记录、教育转写等日常场景的今天，一个看似微小却影响深远的问题逐渐浮现：我们能“听清”用户说了什么，但输出的文字却常常“不好用”。比如，“我去年花了三万五买了一辆车”这样的句子，虽然听得明白，但如果要导入报表系统或做数据分析，就必须手动转换成“35000元”——这个过程不仅耗时，还容易出错。

正是在这一背景下，文本规整（Inverse Text Normalization, ITN）技术悄然成为提升语音识别实用性的关键一环。它不再满足于“识别出来”，而是追求“识别得对、用得上”。以Fun-ASR WebUI为例，这款由 Fun-ASR 团队联合通义实验室推出的本地化语音识别平台，通过内置 ITN 功能，实现了从口语表达到标准书面语的智能转换，真正让 ASR 输出走向“即拿即用”。

什么是 ITN？不只是“说”和“写”的转换

简单来说，ITN 就是把语音识别结果中的口语化表达还原为标准书写格式的过程。例如：

“二零二五年三月十五号” → “2025年3月15日”
“下午四点二十” → “16:20”
“电话是幺三八零零一二三四五六” → “13800123456”

这听起来像是简单的替换，实则涉及语言理解、上下文判断与规则建模的综合能力。比如，“二零二五”可能是年份，也可能是编号；“三点”可能是时间，也可能是评分。如果缺乏语义感知，盲目转换反而会造成误解。

与之相对的是 TTS 中的TNN（Text Normalization for Synthesis），即将书面语转为适合朗读的口语形式。而 ITN 正好相反，它是 ASR 后处理中不可或缺的一环，专为“让机器输出更像人写的正式文本”服务。

ITN 是如何工作的？一场无声的语言重构

在 Fun-ASR 系统中，ITN 并非独立运行的黑盒模块，而是紧密嵌入在 ASR 解码之后的后处理流程中。它的运作可以分为四个阶段：

实体识别：扫描原始识别文本，定位需要规整的语言片段，如汉字数字、口语时间词、电话号码序列等。
语义解析：结合上下文判断其真实含义。例如，“下个月五号”中的“五号”应被理解为日期而非序数。
格式映射：调用预定义规则库进行结构化转换，将“三千四百”变为“3400”，“早上八点半”变为“08:30”。
上下文融合：确保转换后的文本语法通顺、语义完整，不会因替换导致句子断裂或歧义。

整个过程采用规则驱动 + 轻量级模型辅助的混合架构，在保证高准确率的同时控制计算开销，适用于实时和批量场景。更重要的是，这种设计避免了引入大型神经网络带来的延迟问题，特别适合部署在边缘设备或资源受限环境中。

支持哪些类型？覆盖高频使用场景

Fun-ASR 的 ITN 模块目前已支持多种常见实体类型的标准化处理：

类型	示例输入	规整输出
数字	三千四百	3400
年份	二零二五年	2025年
时间	下午三点二十	15:20
货币	五块钱	5元
电话号码	幺三八零零一二三四五六	13800123456
序号	第一百零一名	第101名

尤为关键的是，该系统具备一定的上下文感知能力。例如，“我在二零二五项目组”中的“二零二五”会被保留为编号形式，而非误判为年份。这种灵活性使得 ITN 不再是“一刀切”的替换工具，而是一个具备基础语义理解能力的智能组件。

此外，用户可通过 WebUI 界面一键开关 ITN 功能，无需修改代码或重启服务。对于需要保留原始口语表达的研究类任务（如语言学分析），关闭 ITN 即可；而对于生成报告、数据提取等应用，则推荐全程启用。

实际效果对比：从“看得懂”到“可以直接用”

维度	无 ITN 系统	启用 ITN 系统
输出可读性	口语化严重，需人工整理	接近人工编辑水平
数据结构化难度	需额外 NLP 处理提取信息	数值、时间已标准化，可直接解析
应用适配性	仅适用于听写回放	可对接 CRM、ERP、数据库等系统
用户体验	输出仍需大量后期编辑	几乎无需修改即可使用

相比第三方脚本或自研正则方案，Fun-ASR 内置 ITN 具有明显优势：

深度集成：与主干 ASR 模型协同优化，错误传播少
中文定制化强：针对汉语数字、时间表达习惯专门设计规则
零依赖部署：无需安装额外库或配置复杂环境，WebUI 勾选即生效

这意味着开发者无需投入额外开发成本，就能获得高质量的规整结果。

如何调用？API 控制简洁高效

尽管 ITN 功能为内置模块且未完全开源，但其行为可通过 API 参数灵活控制。以下是一个典型的 Python 调用示例：

import requests response = requests.post( "http://localhost:7860/api/transcribe", json={ "audio_file": "/path/to/audio.wav", "language": "zh", # 中文识别 "enable_itn": True, # ✅ 启用文本规整 "hotwords": ["营业时间", "客服电话"] # 可选热词增强 } ) result = response.json() print("原始文本:", result["text"]) print("规整后文本:", result["normalized_text"]) # ITN 处理后的结果

返回结果包含两个字段：
-text：原始识别输出，保留所有口语表达
-normalized_text：经 ITN 处理后的标准化文本

这种双输出设计非常实用——既可用于调试比对，也能根据不同下游任务选择使用哪种版本。例如，前端展示可用规整文本，而语音存档则保留原始内容。

流式识别怎么做？VAD 分段实现近实时体验

虽然 Fun-ASR 当前版本的底层模型不原生支持流式解码（如 RNN-T 或 Whisper Streaming），但它通过基于 VAD 的分段式模拟流式识别实现了良好的用户体验平衡。

其工作原理如下：

浏览器通过 Web Audio API 获取麦克风音频流
后端持续进行 Voice Activity Detection（VAD）检测
当检测到约 1.5 秒静音时，认为一句话结束
截取该语音片段送入 ASR 模型快速识别
结果立即追加显示，并继续监听下一语句

这种方式虽非真正的流式输出，但在普通对话节奏下，延迟通常控制在 1~3 秒内，已能满足大多数会议记录、课堂笔记等场景需求。

关键参数包括：
-最大单段时长：默认 30 秒，防止长时间无停顿导致无法触发识别
-最小语音长度：过滤短噪声，避免误触发
-静音阈值：由模型自动判定，无需手动调整

当然，也有局限需要注意：
- 说话过快、无明显停顿时，可能延迟上升
- 背景噪音大可能导致 VAD 误判
- 极长发言（>30秒）会被强制截断

因此建议：
- 发言时适当放缓语速，留出自然停顿
- 在安静环境下使用
- 对高精度长文本转写，优先选用“上传文件”模式全段识别

系统架构与工作流程：本地部署下的高效闭环

Fun-ASR WebUI 采用典型的前后端分离架构，整体流程清晰稳定：

[用户浏览器] ↓ (HTTP/WebSocket) [Flask/FastAPI 后端服务] ↓ [Fun-ASR 模型引擎] ← [GPU/CPU 计算资源] ↓ [ITN 后处理模块] ↓ [结果展示 & 历史存储]

其中，ITN 模块位于 ASR 解码器之后，作为通用后处理层存在，对所有识别路径（单文件、批量、实时录音）均生效。

典型工作流程如下：
1. 用户上传音频或启动录音
2. 加载选定模型（如 Fun-ASR-Nano-2512）
3. 执行语音识别，得到原始文本：“会议安排在二零二五年三月十号”
4. 若启用 ITN，则进行规整处理：
- “二零二五年” → “2025年”
- “三月十号” → “3月10日”
5. 输出最终结果：“会议安排在2025年3月10日”
6. 结果自动保存至本地数据库（history.db），支持后续查询导出

整个过程在 GPU 加速下可达接近实时的速度（1x RTF），即使在 CPU 模式下也能完成中小规模任务。