Loading...
正在加载...
请稍候

WeTextProcessing 开源库深度研究报告

✨步子哥 (steper) 2026年04月20日 03:45
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>WeTextProcessing 开源库深度研究报告</title> <link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <link href="https://fonts.googleapis.com/css2?family=Noto+Sans+SC:wght@400;700&family=Noto+Serif+SC:wght@400;700&family=Source+Code+Pro:wght@400;700&display=swap" rel="stylesheet"> <script src="https://cdn.jsdelivr.net/npm/chart.js"></script> <style> /* 1. 总体布局与氛围 */ html, body { margin: 0; padding: 0; width: 100%; background-color: #FFFFFF; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; } body { font-family: "Noto Serif SC", serif; font-size: 16px; color: #212529; line-height: 1.8; } .container { max-width: 800px; margin: 40px auto; padding: 40px 60px; background-color: #FFFFFF; box-shadow: 0 6px 20px rgba(0, 0, 0, 0.07); border-radius: 8px; } /* 2. 字体与排版 */ h1, h2, h3, h4, h5, h6 { font-family: "Noto Sans SC", "Noto Serif SC", sans-serif; font-weight: 700; } h1 { font-size: 28px; margin-top: 24px; margin-bottom: 20px; text-align: center; color: #212529; } h2 { font-size: 22px; padding-bottom: 0.4em; margin-top: 2.5em; margin-bottom: 1.5em; border-bottom: 1px solid #dee2e6; display: flex; align-items: center; } h2::before { content: ''; display: inline-block; width: 14px; height: 14px; background-color: #0D6EFD; border-radius: 50%; margin-right: 12px; flex-shrink: 0; } h3 { font-size: 20px; margin-top: 2em; margin-bottom: 1em; } h4 { font-size: 18px; margin-top: 1.5em; margin-bottom: 0.8em; } p { margin-bottom: 1.2em; } strong, b { color: #212529; font-weight: 700; } a { color: #0D6EFD; text-decoration: none; transition: color 0.2s ease-in-out; } a:hover { text-decoration: underline; } /* 3. 其他元素 */ code { font-family: "Source Code Pro", monospace; background-color: #e9ecef; padding: 0.2em 0.4em; border-radius: 4px; font-size: 0.9em; } pre { background-color: #f8f9fa; padding: 1em; border-radius: 6px; overflow-x: auto; border: 1px solid #e9ecef; } pre code { background-color: transparent; padding: 0; border-radius: 0; font-size: 0.9em; } blockquote { border-left: 4px solid #0D6EFD; padding-left: 1em; margin-left: 0; color: #495057; background-color: #f8f9fa; padding: 0.8em 1em; border-radius: 0 4px 4px 0; } hr { border: 0; height: 2px; background-color: #0D6EFD; margin: 3em 0; } table { width: 100%; border-collapse: collapse; margin: 1.5em 0; font-size: 0.95em; } th, td { padding: 0.8em 1em; text-align: left; border-bottom: 1px solid #e9ecef; } thead { border-bottom: 2px solid #0D6EFD; } thead th { font-family: "Noto Sans SC", sans-serif; font-weight: 700; } tbody tr:hover { background-color: rgba(13, 110, 253, 0.05); } ul, ol { padding-left: 2em; } li { margin-bottom: 0.5em; } .component-group { border: 1px solid #e9ecef; border-radius: 6px; padding: 1.5em; margin: 1.5em 0; background-color: #fdfdff; box-shadow: 0 2px 4px rgba(0,0,0,0.03); } .component-group > :first-child { margin-top: 0; } .component-group > :last-child { margin-bottom: 0; } /* 目录样式 */ .toc { background-color: #f8f9fa; border: 1px solid #e9ecef; padding: 1.5em 2em; margin-bottom: 2em; border-radius: 6px; } .toc-title { font-family: "Noto Sans SC", sans-serif; font-size: 20px; font-weight: 700; margin-top: 0; margin-bottom: 1em; color: #212529; } .toc ul { list-style: none; padding-left: 0; } .toc-level-2 > li { margin-bottom: 0.8em; font-size: 16px; } .toc-level-3 { padding-left: 2em; margin-top: 0.5em; } .toc-level-3 > li { font-size: 15px; margin-bottom: 0.5em; } .toc a { color: #0D6EFD; text-decoration: none; } .toc a:hover { text-decoration: underline; } .toc-h2-prefix { margin-right: 0.5em; font-weight: 700; } /* 图表样式 */ .generated-chart { margin: 2.5em auto; padding: 1em; border: 1px solid #e9ecef; border-radius: 8px; box-shadow: 0 4px 12px rgba(0,0,0,0.05); } .chart-container { position: relative; height: 400px; width: 100%; } figcaption { text-align: center; margin-top: 1em; font-size: 14px; color: #6c757d; font-family: "Noto Serif SC", serif; } </style> </head> <body> <div class="container"> <h1>WeTextProcessing 开源库深度研究报告</h1> <nav class="toc"> <h3 class="toc-title">目录</h3> <ul class="toc-level-2"> <li><a href="#h2-1"><span class="toc-h2-prefix">一、</span>概述与背景</a></li> <li><a href="#h2-2"><span class="toc-h2-prefix">二、</span>核心功能与技术原理</a> <ul class="toc-level-3"> <li><a href="#h3-2-1">文本规范化(TN)</a></li> <li><a href="#h3-2-2">逆文本规范化(ITN)</a></li> </ul> </li> <li><a href="#h2-3"><span class="toc-h2-prefix">三、</span>多语言支持与扩展性</a></li> <li><a href="#h2-4"><span class="toc-h2-prefix">四、</span>部署与生态</a></li> <li><a href="#h2-5"><span class="toc-h2-prefix">五、</span>应用场景与价值</a></li> <li><a href="#h2-6"><span class="toc-h2-prefix">六、</span>性能与局限</a></li> <li><a href="#h2-7"><span class="toc-h2-prefix">七、</span>总结与展望</a></li> </ul> </nav> <h2 id="h2-1">概述与背景</h2> <p><strong>WeTextProcessing</strong> 是一个由 WeNet 团队开源的文本处理工具库,专注于文本规范化(Text Normalization, TN)和逆文本规范化(Inverse Text Normalization, ITN)【1†source】。它提供从非结构化文本到标准格式,以及从标准格式回到自然语言文本的双向转换能力,是构建语音交互系统不可或缺的关键组件【8†source】。在语音合成(TTS)前端,TN 将原始文本转换为规范形式;在语音识别(ASR)后端,ITN 将识别出的规范文本还原为用户易读的形式,两者共同确保人机交互的流畅与准确【8†source】。</p> <p>WeTextProcessing 的设计秉承“生产优先、生产就绪”(Production First & Production Ready)的原则,旨在提供一个<strong>开箱即用</strong>且<strong>高效可靠</strong>的文本处理解决方案【3†source】。它内置了对中文、英文和日文三种语言的支持,并采用基于有限状态转换器(FST)的规则引擎来实现高效处理【3†source】。与传统依赖复杂第三方库的方案不同,WeTextProcessing 在 Python 运行时中不依赖 Pynini 等重量级库,而是通过预先构建 FST 模型来实现轻量级部署【9†source】。这使得开发者可以<strong>即插即用</strong>地集成文本标准化功能,无需从零编写繁琐的正则表达式规则,大大降低了开发门槛【11†source】。</p> <h2 id="h2-2">核心功能与技术原理</h2> <p>WeTextProcessing 的核心功能分为两大模块:<strong>文本规范化(TN)</strong>和<strong>逆文本规范化(ITN)</strong>,两者共同构成了完整的双向文本处理流水线。</p> <h3 id="h3-2-1">文本规范化(TN)</h3> <p>文本规范化是指将原始文本中的非标准词汇(Non-Standard Words, NSW)转换为标准口语形式的过程【5†source】。例如,将数字、日期、时间、货币、度量衡等按照语言习惯读出来。WeTextProcessing 的 TN 模块将此过程分为三个阶段【5†source】:</p> <ol> <li><strong>预处理器(Pre-Processing)</strong>:对输入文本进行清洗和基础转换,例如将全角字符转换为半角、统一标点符号、移除黑名单词汇(如语气词“呃”、“啊”等)【5†source】。这一步骤确保后续处理在统一的字符集和格式上进行。</li> <li><strong>非标准词规范化(NSW Normalization)</strong>:这是 TN 的核心阶段,通过一系列规则将各类 NSW 转换为标准文本【5†source】。WeTextProcessing 针对不同类别的 NSW 设计了专门的处理器,包括: <ul> <li><strong>数字(Numbers)</strong>:将阿拉伯数字转换为中文数字或英文读法,例如“465”→“四百六十五”,“6.42”→“六点四二”【5†source】。中文数字转换支持从个、十、百、千到万、亿的完整映射,并可配置是否将 0-9 的单个数字也进行转换【10†source】。</li> <li><strong>分数(Fraction)</strong>:将分数形式转换为口语读法,例如“1/5”→“五分之一”【5†source】。</li> <li><strong>百分比(Percentage)</strong>:将百分号读出,例如“6.3%”→“百分之六点三”【5†source】。</li> <li><strong>日期(Date)</strong>:将日期格式转换为口语表达,例如“2002/01/28”→“二零零二年一月二十八日”【5†source】。支持多种日期格式(如“2002-01-28”、“2002.01.28”)的识别和转换。</li> <li><strong>时间(Time)</strong>:将时间格式转换为口语,例如“8:00 a.m.”→“早上八点”,“5:02”→“五点零二分”【5†source】。</li> <li><strong>数学表达式(Math)</strong>:处理数学符号和算式,例如“78:96”→“七十八比九十六”,“-2”→“负二”【5†source】。</li> <li><strong>货币(Money)</strong>:将货币符号和数字转换为口语读法,例如“¥13.5”→“十三点五元”,“$13.5”→“十三点五美元”【5†source】。</li> <li><strong>度量衡(Measure)</strong>:将度量单位读出,例如“25kg”→“二十五千克”,“38°C”→“三十八摄氏度”【5†source】。</li> <li><strong>数字序列(Number Series)</strong>:处理连续数字,如电话号码等,例如“12306”→“幺二三零六”【5†source】。</li> <li><strong>儿化音(Erhua)</strong>:针对中文的儿化音进行处理,可选择去除或保留,例如“地儿”→“地”【5†source】。</li> <li><strong>白名单(Whitelist)</strong>:对特定词汇进行替换,例如将“CEO”保留为英文字母读法【5†source】。</li> </ul> </li> <li><strong>后处理器(Post-Processing)</strong>:对规范化后的文本进行进一步优化,例如移除不必要的标点、标记未登录词(OOV)等【5†source】。这一步确保输出文本符合自然语言表达习惯,例如避免出现不合理的空格或标点。</li> </ol> <p>通过上述三阶段流水线,WeTextProcessing 能够将诸如“2.5平方电线”这样的原始文本转换为“二点五平方电线”,将“2023年12月5日14:30,预算5000元”转换为“二零二三年十二月五日下午两点三十分,预算五千元”等,实现全面且可控的文本规范化【12†source】。</p> <h3 id="h3-2-2">逆文本规范化(ITN)</h3> <p>逆文本规范化是 TN 的逆过程,即将已规范化的文本恢复为原始书写形式【5†source】。这在语音识别场景尤为重要,因为识别结果需要以用户可读的形式显示。WeTextProcessing 的 ITN 模块同样采用三阶段流水线,但与 TN 的处理逻辑相反【5†source】:</p> <ol> <li><strong>预处理器</strong>:对输入文本进行清洗,与 TN 预处理类似,包括移除黑名单词汇等【5†source】。</li> <li><strong>非标准词逆规范化(NSW Denormalization)</strong>:将标准文本中的各类 NSW 还原为原始格式。ITN 提供了与 TN 对应的逆转换规则,例如: <ul> <li><strong>数字</strong>:将中文数字或英文读法转换回数字,例如“四百六十五”→“465”,“六点四二”→“6.42”【5†source】。ITN 同样支持对单个数字的处理配置,例如“幸运一百”在启用 0-9 转换时可还原为“幸运100”,否则保留为“幸运一百”【5†source】。</li> <li><strong>分数</strong>:将分数读法还原为数字分数,例如“五分之一”→“1/5”【5†source】。</li> <li><strong>百分比</strong>:将“百分之六点三”还原为“6.3%”【5†source】。</li> <li><strong>日期</strong>:将“二零零二年一月二十八日”还原为“2002/01/28”【5†source】。</li> <li><strong>时间</strong>:将“八月十六号十二点之前”还原为“08/16 12点之前”【5†source】。</li> <li><strong>数学表达式</strong>:将“七十八比九十六”还原为“78:96”等【5†source】。</li> <li><strong>货币</strong>:将“十三点五元”还原为“¥13.5”【5†source】。</li> <li><strong>度量衡</strong>:将“二十五千克”还原为“25kg”等【5†source】。</li> <li><strong>数字序列</strong>:将“幺二三零六”还原为“12306”【5†source】。</li> <li><strong>白名单</strong>:对特定词汇进行逆向替换,例如将“C E O”还原为“CEO”【5†source】。</li> </ul> </li> <li><strong>后处理器</strong>:与 TN 后处理类似,对还原后的文本进行格式优化,确保输出符合书写规范。</li> </ol> <p>通过 ITN,WeTextProcessing 能够将“二点五平方电线”还原为“2.5平方电线”,将“下午三点四十五分”还原为“15:45”,实现从机器处理格式到用户友好格式的转换【12†source】。这种双向能力使得工具能够满足对话系统等需要交互场景的需求,确保用户输入和系统输出的一致性。</p> <h2 id="h2-3">多语言支持与扩展性</h2> <p>WeTextProcessing 提供了对中文、英文和日文三种语言的原生支持【3†source】。每种语言都有独立的规则库和数据资源,能够处理各自语言的特有表达。例如,中文模块支持农历日期转换和儿化音处理,英文模块能解析罗马数字,日文模块包含平假名/片假名转换功能【12†source】。这种多语言并行支持使跨国企业无需为不同语言开发独立处理系统,显著降低了开发成本【12†source】。</p> <p>同时,WeTextProcessing 的架构具有高度的模块化和可扩展性。规则引擎采用插件式设计,每个处理场景(如日期、货币、度量单位等)作为独立模块存在【12†source】。开发者可以按需加载规则,既保证处理精度又减少资源消耗【12†source】。更重要的是,用户可以方便地<strong>自定义规则</strong>来扩展或修改系统行为【1†source】。通过编辑对应的规则脚本(如 TN 的 <code>tn/chinese/rules/</code> 目录下的 Python 文件或 ITN 的 <code>itn/chinese/rules/</code> 目录下的文件),然后运行带 <code>--overwrite_cache</code> 参数的命令,即可重新构建 FST 规则库,生成新的 <code>.far</code> 文件供部署使用【1†source】。这种规则可扩展性架构允许开发者根据特定领域需求,通过添加自定义规则文件扩展系统能力,极大降低了二次开发门槛【12†source】。</p> <h2 id="h2-4">部署与生态</h2> <p>WeTextProcessing 提供了多种部署方式,以适应不同场景需求:</p> <ul> <li><strong>Python 包</strong>:用户可以通过 <code>pip install WeTextProcessing</code> 一键安装,然后在 Python 代码中直接调用 TN/ITN 接口,非常方便集成到现有项目中【1†source】。安装后,WeTextProcessing 会自动下载并缓存预构建的 FST 模型,首次使用时可能需要联网获取模型,但之后即可离线运行。</li> <li><strong>命令行工具</strong>:WeTextProcessing 提供了命令行接口 <code>wetn</code> 和 <code>weitn</code>,可以直接对输入文本进行规范化或逆规范化【1†source】。这便于快速测试或在脚本中批量处理文本。</li> <li><strong>C++ 运行时</strong>:为了满足生产环境对性能和依赖精简的要求,WeTextProcessing 提供了基于 C++ 的运行时【1†source】。开发者可以使用 CMake 构建 C++ 可执行文件 <code>processor_main</code>,并通过指定 FST 规则文件(<code>.far</code>)来执行文本处理【1†source】。C++ 运行时仅依赖 OpenFst,无需 Pynini 等大型依赖,部署更轻量【1†source】。这使得 WeTextProcessing 可以方便地集成到 C++ 项目或嵌入式系统中。</li> <li><strong>Rust 实现</strong>:社区还出现了一个 Rust 语言实现的 WeTextProcessing 版本——<code>wetext-rs</code>【9†source】。该实现使用纯 Rust 编写,不依赖 Pynini,而是采用 Rust 版的 OpenFst(<code>rustfst</code>)来实现 FST 功能【9†source】。Rust 实现的动机是与 Candle 等 Rust 生态框架集成,消除对 Python 的依赖,并利用 Rust 的内存安全和零成本抽象来提高文本处理性能【9†source】。目前 <code>wetext-rs</code> 已支持中英日三语的 TN 和 ITN 功能,并提供与 Python 版本类似的 API 调用方式【9†source】。</li> </ul> <p>WeTextProcessing 的生态还包括一些相关项目和工具。例如,有开发者基于 WeTextProcessing 构建了中文 ITN 模型并部署到 ModelScope 平台,方便其他用户直接使用【2†source】。此外,WeTextProcessing 也被集成到更大的语音技术栈中,如 FunASR 等开源语音识别框架就支持使用 WeTextProcessing 提供的 C++ 运行时来处理识别结果【11†source】。这些生态拓展进一步提升了 WeTextProcessing 的实用性和影响力。</p> <h2 id="h2-5">应用场景与价值</h2> <p>WeTextProcessing 的双向文本处理能力在多个领域展现出显著价值:</p> <ul> <li><strong>智能客服与对话系统</strong>:在客服场景中,用户输入往往包含大量非标准化表达(如“1百20块”、“明天下午3点”等),直接用于意图识别会导致错误率上升【12†source】。WeTextProcessing 可以将这些表达统一转换为标准格式(如“一百二十元”、“明天下午三点”),显著提升系统理解准确率。据统计,未经处理的用户输入会使意图识别错误率提升 35% 以上,而使用 WeTextProcessing 后,某智能客服系统的理解准确率提升了 40%,人工干预率降低了 65%【12†source】。同时,ITN 能将系统回复中的数字、时间等转换为自然语言形式,提高对话的自然度。</li> </ul> <figure class="generated-chart"> <div class="chart-container"> <canvas id="performanceChart"></canvas> </div> <figcaption>图1:WeTextProcessing 在智能客服场景中的性能提升对比</figcaption> </figure> <ul> <li><strong>语音助手与 TTS/ASR</strong>:在语音交互中,TN 是 TTS 前端的关键步骤,将文本转换为语音合成引擎可读的格式;ITN 是 ASR 后端的关键步骤,将识别结果转换为用户可读的文本【8†source】。WeTextProcessing 能确保语音合成时读出“下午3点”而非“15:00”,在语音识别字幕上显示“下午3点”而非“下午三点”,提升用户体验【8†source】。某智能音箱厂商集成该工具后,数字类语音播报的用户满意度提升了 37%【12†source】。</li> <li><strong>金融数据处理</strong>:在金融报表、交易记录等场景,需要将不同格式的数字和货币统一处理。WeTextProcessing 的货币和数字规则可以自动将“$1,000”、“1000美元”统一为“一千美元”,将“6.42万人”转换为“64200人”等,大幅提高数据清洗和整合的效率【12†source】。某银行使用 WeTextProcessing 后,报表处理时间从 2 小时缩短至 15 分钟,数据准确率提升至 99.8%【12†source】。</li> <li><strong>多语言内容平台</strong>:对于跨境电商、新闻聚合等多语言平台,WeTextProcessing 的多语言支持可以统一不同语言的数字、日期、度量单位格式,方便内容索引和检索【12†source】。例如,将中英文日期、数字统一标准化后,检索效率可提升 40%【12†source】。</li> <li><strong>医疗与专业领域</strong>:在医疗文本处理中,WeTextProcessing 可以标准化病历中的时间、剂量等关键信息,提高后续数据分析的准确性【12†source】。某医院信息系统集成后,病历数据分析效率提升了 25%【12†source】。此外,通过扩展领域词典,WeTextProcessing 也能适配法律、化学等专业领域的特殊术语处理需求。</li> </ul> <p>综上,WeTextProcessing 作为一款<strong>文本处理黑箱的开箱</strong>,为各行业提供了高效、可靠的文本标准化解决方案,让原本耗时耗力的文本预处理变得简单易行,显著提升了系统的智能化水平和数据处理质量【12†source】。</p> <h2 id="h2-6">性能与局限</h2> <p>WeTextProcessing 在设计上兼顾了准确性和效率。其基于 FST 的规则引擎在处理文本时具有<strong>线性时间复杂度</strong>,能够快速匹配和转换文本模式【9†source】。在实际应用中,WeTextProcessing 的处理速度可达每秒数百字符,满足大多数实时处理场景的需求【12†source】。与基于深度学习的端到端模型相比,规则方法在准确率上可能略逊一筹,但胜在<strong>可控可解释</strong>,且对计算资源要求更低【12†source】。WeTextProcessing 通过权重机制和优先级排序,确保在多条规则匹配时选取最优路径,从而在保证转换正确性的同时,兼顾了一定的鲁棒性【1†source】。</p> <p>然而,WeTextProcessing 也存在一些局限和挑战:</p> <ul> <li><strong>规则覆盖与维护</strong>:规则方法的优势是可控,但劣势是需要<strong>穷举</strong>各种文本模式。对于某些歧义或特殊场景,可能需要不断添加和调整规则。WeTextProcessing 内置了丰富的规则库,但不可能覆盖 100% 的长尾场景【12†source】。开发者在使用过程中,如果遇到未被正确处理的 badcase,需要定位问题类型并修改相应规则或数据文件来修复【1†source】。这要求使用者对规则语法有一定了解,增加了维护成本。</li> <li><strong>上下文歧义</strong>:纯规则方法对上下文的依赖较弱,容易出现歧义。例如,“三点五分”既可理解为时间“3:05”,也可理解为量词“3.5 分”【1†source】。WeTextProcessing 通过在规则中加入上下文线索(如检测“得到”一词来判断“三点五分”为得分)来缓解部分歧义,但无法完全避免【1†source】。对于高度依赖上下文的复杂文本,规则方法可能不如深度学习模型鲁棒。</li> <li><strong>依赖与部署</strong>:WeTextProcessing 的 Python 版本在运行时仍需依赖 OpenFst 等库,初次安装可能涉及编译环境。尽管提供了不依赖 Pynini 的轻量运行时,但在 Windows 等平台上的安装和部署仍存在挑战,社区中也有相关反馈【6†source】。C++ 运行时虽然轻量,但需要用户自行编译和集成,对非 C++ 开发者有一定门槛。</li> <li><strong>模型更新</strong>:WeTextProcessing 的规则和模型需要随语言演变而更新,例如新的货币符号、度量单位等。如果用户未及时更新数据资源,可能影响转换效果【12†source】。项目组建议每季度更新一次规则库,以确保涵盖最新的语言现象【12†source】。</li> </ul> <p>尽管存在上述局限,WeTextProcessing 通过<strong>规则+数据</strong>的架构,在大多数场景下提供了足够高的准确率和效率,并且其开源特性允许社区共同完善规则库,不断提升系统表现【12†source】。在实际应用中,建议根据具体业务场景调整规则配置,平衡处理准确性与性能需求【12†source】。对于极端复杂或专业领域的文本,也可以考虑将 WeTextProcessing 与深度学习模型结合,形成混合系统,以兼顾规则的可控性和神经网络的鲁棒性。</p> <h2 id="h2-7">总结与展望</h2> <p>WeTextProcessing 作为一款专注于文本标准化与逆标准化的开源工具,凭借其<strong>双向处理</strong>、<strong>多语言支持</strong>和<strong>规则可扩展</strong>等核心优势,为解决非结构化文本处理难题提供了系统化的解决方案【12†source】。它不仅包含一套完整的中文/英文/日文 TN/ITN 规则语法,还提供了从 Python 包到 C++ 运行时的全栈部署支持,真正实现了“开箱即用”的生产级文本处理能力【1†source】。</p> <p>展望未来,WeTextProcessing 的发展将聚焦于<strong>持续完善规则库</strong>和<strong>提升易用性</strong>。一方面,项目组计划将更多真实线上环境中的 corner case 纳入测试和修复范围,不断提高规则覆盖率和准确率【1†source】。另一方面,社区也在探索更丰富的语言支持(如韩语等)和更简便的部署方式(如提供预编译的二进制包、优化 Windows 平台体验等)。随着自然语言处理技术的深入应用,文本标准化作为基础环节的重要性将愈发凸显,WeTextProcessing 有望在更多领域发挥关键作用,成为多语言文本预处理领域的首选工具【12†source】。通过开源社区的力量,WeTextProcessing 将不断演进,让文本处理不再复杂,为构建更智能的语言应用奠定坚实基础。【12†source】</p> </div> <script> document.addEventListener('DOMContentLoaded', function () { const ctx = document.getElementById('performanceChart'); if (ctx) { const performanceChart = new Chart(ctx, { type: 'bar', data: { labels: ['意图识别错误率降低', '理解准确率提升', '人工干预率降低'], datasets: [{ label: '性能变化 (%)', data: [35, 40, 65], backgroundColor: [ 'rgba(13, 110, 253, 0.5)', 'rgba(25, 135, 84, 0.5)', 'rgba(255, 193, 7, 0.5)' ], borderColor: [ 'rgba(13, 110, 253, 1)', 'rgba(25, 135, 84, 1)', 'rgba(255, 193, 7, 1)' ], borderWidth: 1 }] }, options: { responsive: true, maintainAspectRatio: false, scales: { y: { beginAtZero: true, max: 80, title: { display: true, text: '百分比 (%)', color: '#212529', font: { family: "'Noto Sans SC', sans-serif", size: 14 } }, grid: { color: '#E9ECEF', borderDash: [5, 5] }, ticks: { color: '#212529', font: { family: "'Noto Sans SC', sans-serif" } } }, x: { grid: { display: false }, ticks: { color: '#212529', font: { family: "'Noto Sans SC', sans-serif", size: 14 } } } }, plugins: { legend: { display: false }, tooltip: { mode: 'index', intersect: false, titleFont: { family: "'Noto Sans SC', sans-serif" }, bodyFont: { family: "'Noto Sans SC', sans-serif" } }, title: { display: false } } } }); } }); </script> </body> </html>

讨论回复

0 条回复

还没有人回复,快来发表你的看法吧!