很多做在線教育的朋友都跟我吐槽過一件事明明AI講解工具已經(jīng)能把一篇英文文章讀得聲情并茂可一到數(shù)學(xué)公式就原形畢露——根號(hào)變成二立方讀成乘以三更離譜的是把”sin x”念成sin 叉。這類問題不是個(gè)別廠商的疏漏而是幾乎所有語音合成方案在數(shù)學(xué)場(chǎng)景下的通病。我自己做過一年多的語音內(nèi)容自動(dòng)化踩過不少坑后來花了不少精力去拆解為什么讀不對(duì)這件事才發(fā)現(xiàn)問題的根源不在發(fā)音庫(kù)也不在聲學(xué)模型而在更底層的文本處理和語料設(shè)計(jì)邏輯上。這篇文章不打算停留在哪個(gè)工具好用的對(duì)比層面而是想聊聊公式朗讀翻車的底層原因、合成流水線里到底哪幾個(gè)環(huán)節(jié)在作梗以及我實(shí)際驗(yàn)證過、能在工程上落地的修正思路。如果你正在做數(shù)學(xué)類課程自動(dòng)化、給學(xué)習(xí)類App接入語音功能或者只是好奇為什么AI讀公式會(huì)這么傻這篇應(yīng)該能給你一些有用的線索。1. 日常抱怨背后公式朗讀錯(cuò)誤到底分成哪幾類先把問題歸類。我接觸過的公式朗讀錯(cuò)誤看著千奇百怪本質(zhì)上跑不出四類符號(hào)被當(dāng)成普通文本、數(shù)字處理邏輯錯(cuò)亂、運(yùn)算關(guān)系含糊、專業(yè)記號(hào)直接失語。分類清晰了排查起來才有方向。1.1 符號(hào)亂讀最荒誕但也最好理解最常見的一類是符號(hào)被當(dāng)成普通字母或單詞讀出來。比如x2經(jīng)常被讀成x二而不是x的平方π被讀成派還算好的有的引擎直接讀pai∑可能被跳過不讀也可能讀成sum。這類問題的根源在于語音合成引擎內(nèi)部有一個(gè)文本歸一化text normalization環(huán)節(jié)它負(fù)責(zé)把數(shù)字、符號(hào)、縮寫轉(zhuǎn)換成適合發(fā)音的常規(guī)文字。這套邏輯處理日期、時(shí)間、金額是精心設(shè)計(jì)過的但面對(duì)公式符號(hào)的時(shí)候它只會(huì)機(jī)械地查表。2這個(gè)字符如果出現(xiàn)在文檔里很多歸一化規(guī)則認(rèn)為它是上標(biāo)二但轉(zhuǎn)成語音的時(shí)候它不知道該不該把平方這個(gè)語義加進(jìn)去干脆就按字符讀。我印象很深的一個(gè)測(cè)試案例一段包含log?8的文本引擎讀出來是log二八而人類正常的讀法是以二為底八的對(duì)數(shù)。這種讀出來了但完全不對(duì)的錯(cuò)誤比直接跳過更讓人頭疼因?yàn)槁牭娜藭?huì)以為自己理解錯(cuò)了而不是懷疑機(jī)器讀錯(cuò)了。1.2 數(shù)字和單位的錯(cuò)亂歸一化規(guī)則在公式語境下的失靈第二類跟數(shù)字有關(guān)但表現(xiàn)形式非常本地化。中文語音引擎處理普通文本時(shí)會(huì)把1200轉(zhuǎn)成一千二百再合成。這個(gè)習(xí)慣在敘事文本里完全沒問題但放進(jìn)公式就壞事了。比如F(x)1200x引擎很可能讀成F x等于一千二百x而不是F x等于一千二百乘以x。這里丟掉的不是數(shù)字本身而是數(shù)字和變量之間的運(yùn)算關(guān)系。更麻煩的是單位類字符。3cm在文本歸一化里是三厘米5kg是五千克但公式里cm也可能是變量名6.02×1023需要讀成六點(diǎn)零二乘以十的二十三次方而很多引擎會(huì)把1023中的上標(biāo)丟失之后直接讀成一千零二十三或者十二十三。歸一化規(guī)則的面向普通文本取向在數(shù)學(xué)語境里幾乎是災(zāi)難性的。我在自建測(cè)試集的時(shí)候把這類錯(cuò)誤單獨(dú)歸為一檔因?yàn)樗鼈兊膹?fù)現(xiàn)條件最穩(wěn)定也最容易通過規(guī)則修補(bǔ)解決——只要在預(yù)處理階段把數(shù)字、變量、運(yùn)算符號(hào)的邊界識(shí)別出來問題就消掉大半。1.3 讀出來了但運(yùn)算關(guān)系沒表達(dá)出來第三類更加隱蔽就算符號(hào)、數(shù)字都讀對(duì)了引擎也可能在運(yùn)算關(guān)系的表達(dá)上缺斤少兩。比如(ab)/c讀出來是a加b除以c還是括號(hào)a加b除以c或者a加b的和除以c三種讀法信息量完全不同。人類讀公式時(shí)會(huì)通過語速、停頓和括號(hào)的和這些詞來維護(hù)運(yùn)算結(jié)構(gòu)的清晰度——聽的人甚至不用看公式就能腦補(bǔ)出層級(jí)。但語音引擎的韻律預(yù)測(cè)模塊通常是從普通朗讀語料里訓(xùn)練出來的它處理自然語言停頓還行處理括號(hào)層級(jí)這種結(jié)構(gòu)化信息就完全沒有章法。舉個(gè)例子2(xy)在數(shù)學(xué)上是一個(gè)整體應(yīng)該讀成二倍的括號(hào)x加y但很多引擎會(huì)讀成二乘以x加y。少了括號(hào)這個(gè)詞再加上沒有輔助停頓聽者會(huì)以為公式是2xy。這類錯(cuò)誤不怪發(fā)音也不怪聲學(xué)模型純粹是數(shù)學(xué)表達(dá)式在轉(zhuǎn)換成口語化朗讀文本的環(huán)節(jié)上缺失了一層結(jié)構(gòu)轉(zhuǎn)譯。1.4 專業(yè)記號(hào)直接失語連發(fā)聲都做不到最后一類是直接失語。比如∫積分、?nabla算子、∈屬于、?全稱量詞這些符號(hào)很多語音引擎的詞典里根本沒有對(duì)應(yīng)的讀音條目。更滑稽的是在公式中常見的希臘字母α、β、γ、θ經(jīng)常被英文TTS按照英文字母的發(fā)音規(guī)則讀出來聽起來像在讀一串亂碼。這類問題說明一個(gè)殘酷的現(xiàn)實(shí)絕大多數(shù)商用語音合成方案的語料庫(kù)以日?？谡Z-新聞-有聲書為主要覆蓋范圍數(shù)學(xué)符號(hào)、希臘字母這些低頻卻不是稀有需求的內(nèi)容在數(shù)據(jù)層面就存在覆蓋空白。錯(cuò)誤類型典型表現(xiàn)根本原因階段符號(hào)亂讀x2→ x二log?8→ log二八文本歸一化階段數(shù)字單位錯(cuò)亂1200x→ 一千二百x文本歸一化階段運(yùn)算關(guān)系含糊2(xy)→ 二乘以x加y韻律預(yù)測(cè)階段專業(yè)記號(hào)失語∫、∈、?無法發(fā)音詞典與音素覆蓋這個(gè)分類表是我后續(xù)所有調(diào)試工作的基礎(chǔ)。每次拿到一條讀錯(cuò)了的反饋先按這四類歸檔就能快速判斷問題出在哪個(gè)環(huán)節(jié)而不是一頭扎進(jìn)聲學(xué)參數(shù)里瞎調(diào)。2. 從文本到語音公式在合成流水線里經(jīng)歷了什么要理解公式為什么讀不對(duì)繞不開語音合成的基本流水線。我盡量用最通俗的方式講清楚因?yàn)檫@套流程決定了哪些錯(cuò)誤是可以修的哪些是必須換方案的。2.1 TTS的五個(gè)關(guān)鍵環(huán)節(jié)哪一個(gè)針對(duì)公式最薄弱一個(gè)標(biāo)準(zhǔn)的語音合成流水線大體經(jīng)過文本歸一化 → 分詞 → 詞性與淺層句法分析 → 韻律預(yù)測(cè) → 聲學(xué)參數(shù)生成與波形合成。文本歸一化負(fù)責(zé)把2024/5/1變成二零二四年五月一日把￥99變成九十九元分詞負(fù)責(zé)把中文句子切成詞詞性與句法分析判斷每個(gè)詞的角色韻律預(yù)測(cè)決定哪里停頓、哪里升調(diào)、哪個(gè)詞重讀最后聲學(xué)模型生成聲波。你發(fā)現(xiàn)沒有這套流水線從頭到尾是為自然語言設(shè)計(jì)的公式不是自然語言。公式里有符號(hào)、有變量、有上下標(biāo)、有二維排版這些信息在語文世界里根本沒有對(duì)應(yīng)物。最關(guān)鍵的矛盾在于文本歸一化階段做的是字符到字符的轉(zhuǎn)換它不負(fù)責(zé)理解根號(hào)底下的內(nèi)容是一個(gè)整體這個(gè)語義關(guān)系。所以我常說一句話公式朗讀出錯(cuò)不是最后一個(gè)開口說話的環(huán)節(jié)出了問題而是前面看文本的環(huán)節(jié)全都用錯(cuò)了坐標(biāo)系。你讓一個(gè)精通朗讀但不認(rèn)識(shí)公式的人讀題他大概率也會(huì)讀得支離破碎——現(xiàn)在的語音引擎就是那個(gè)精通朗讀但不認(rèn)識(shí)公式的人。2.2 文本歸一化為何專門對(duì)公式下黑手文本歸一化模塊是公式錯(cuò)誤的重災(zāi)區(qū)這一點(diǎn)值得單獨(dú)展開。歸一化的本質(zhì)是基于規(guī)則的有限狀態(tài)轉(zhuǎn)換比如正則表達(dá)式匹配到\d(\.\d)?%就替換成百分之××。這套規(guī)則在處理日期、電話、貨幣、網(wǎng)址時(shí)非常有效因?yàn)樗鼈兊母袷礁叨纫?guī)整。但數(shù)學(xué)表達(dá)式恰恰是格式極不規(guī)整的典型2/3是三分之二但(x2)/3是x加二的和除以三同樣的斜杠前者是分?jǐn)?shù)后者是除法運(yùn)算符語義完全不同。再比如103和10^3在文本里可能是同一個(gè)意思但歸一化規(guī)則很難對(duì)所有上標(biāo)形式做到統(tǒng)一處理。很多規(guī)則寫的是連續(xù)數(shù)字匹配到上標(biāo)字符則把上標(biāo)數(shù)拼在數(shù)字后面——于是103變成了103一百零三而它至少應(yīng)該讀成十的三次方。這個(gè)階段的另一個(gè)坑是語種判定。公式天生是多語種混排阿拉伯?dāng)?shù)字、拉丁變量、希臘字母、中文連接詞等于除以混在一起。引擎的語言識(shí)別模塊在短片段上很容易誤判尤其是log這種同時(shí)是英文單詞和數(shù)學(xué)函數(shù)名的字符串。我實(shí)測(cè)過一個(gè)引擎把log整體按英文單詞發(fā)音讀成洛克把ln讀成l n兩個(gè)字母完全沒意識(shí)到這是自然對(duì)數(shù)的縮寫。2.3 韻律層沒有公式語法可依賴就算你通過預(yù)處理把所有數(shù)字、符號(hào)都轉(zhuǎn)換對(duì)了離像人一樣讀公式還有一道硬關(guān)卡韻律預(yù)測(cè)。人的朗讀尤其是數(shù)學(xué)公式的朗讀非常依賴結(jié)構(gòu)驅(qū)動(dòng)的停頓。眼睛看到(ab)/(cd)腦子會(huì)規(guī)劃出括號(hào)內(nèi)短暫停頓-除號(hào)前后加重-分母括號(hào)內(nèi)短暫停頓的節(jié)奏。這種節(jié)奏不是情緒化的而是語義結(jié)構(gòu)在語音上的映射。形式化一點(diǎn)說公式的括號(hào)層級(jí)應(yīng)該線性映射為音頻上的停頓層級(jí)嵌套越深停頓越密最高層級(jí)的運(yùn)算符前后要給足呼吸時(shí)間。但TTS的韻律預(yù)測(cè)模型是從普通文本語料里學(xué)出來的它學(xué)習(xí)的是標(biāo)點(diǎn)符號(hào)和語氣詞帶來的韻律變化不是數(shù)學(xué)運(yùn)算符帶來的韻律變化。模型看到(和)大概率只是把它們當(dāng)標(biāo)點(diǎn)跳過根本不會(huì)據(jù)此生成括號(hào)層級(jí)對(duì)應(yīng)的停頓時(shí)長(zhǎng)。結(jié)果就是公式被讀成一串勻速的字符流結(jié)構(gòu)信息在聲音里蕩然無存。這也是為什么靠調(diào)音色調(diào)語速永遠(yuǎn)修不好公式朗讀——你調(diào)的只是音色和速度不是停頓結(jié)構(gòu)。真正要做的是在進(jìn)入TTS之前把公式文本轉(zhuǎn)換成自帶韻律標(biāo)記的朗讀文本讓引擎沒有機(jī)會(huì)自己亂斷句。3. 公式自帶反TTS基因二維結(jié)構(gòu)與歧義性的根源前面講的流水線缺陷其實(shí)都指向公式本身的特殊性。任何工具想讀好公式都得直面公式的兩種反TTS基因二維排版的信息壓縮和無處不在的上下文歧義。3.1 二維排版被壓成線性字串信息大量丟失紙質(zhì)公式和板書公式本質(zhì)上是二維排版信息分子在上分母在下根號(hào)覆蓋整個(gè)被開方數(shù)上標(biāo)是右上角的小字。這些信息在人類閱讀時(shí)是視覺并行處理的效率極高。但文本文件里只有線性字符流一旦把公式轉(zhuǎn)成純文本排版信息就丟了。以O(shè)CR識(shí)別出來的公式為例很多引擎會(huì)把分子/分母識(shí)別成分子分母斜杠丟失把x_i的上標(biāo)下標(biāo)丟失。還有一種常見情況是LaTeX源碼直接用\frac{a}表達(dá)分?jǐn)?shù)但做了簡(jiǎn)單文本提取后一類工具拿到的是LaTeX命令名另一類工具可能把命令名直接剝離了導(dǎo)致公式變成ab兩個(gè)字母的拼接。這種信息丟失是不可逆的任何語音引擎都沒辦法從一段丟失了排版信息的文本里腦補(bǔ)出分?jǐn)?shù)結(jié)構(gòu)。所以公式朗讀的修復(fù)一定不能只依賴TTS這一層必須在源頭保證輸入文本攜帶足夠的結(jié)構(gòu)信息。這也是為什么很多人最后選擇先轉(zhuǎn)成口語化文本再TTS的路線——結(jié)構(gòu)信息不能靠聲音去猜只能在文字里顯式寫出來。3.2 同一個(gè)符號(hào)語境不同讀法能差出十萬八千里公式的第二大反TTS基因是歧義性。同樣的字符在不同語境下讀法完全不同這種歧義甚至對(duì)規(guī)則引擎來說是不可判定級(jí)別的難題。舉幾個(gè)我實(shí)測(cè)過的高頻歧義2/3單獨(dú)出現(xiàn)是三分之二出現(xiàn)在2/3 x里是三分之二倍的x出現(xiàn)在x 2/3里又可能是x等于三分之二。但在2/3前后都是變量的情況下人類會(huì)默認(rèn)讀成二除以三。log作為數(shù)學(xué)函數(shù)要讀對(duì)數(shù)出現(xiàn)在log in里要讀登錄。語言模型需要跨越幾十個(gè)字符的上下文才能判斷文本歸一化規(guī)則的有限狀態(tài)機(jī)根本扛不住。sin數(shù)學(xué)里讀正弦英文語境里讀罪過中文學(xué)生口語里還經(jīng)常讀成賽因。x?1可以讀x的負(fù)一次方但在線性代數(shù)語境里也可能是x的逆。cos?1存在反余弦和余弦的負(fù)一次方兩種學(xué)派式讀法哪種都對(duì)看教材體系。這類歧義不是多加幾條正則能解決的。本質(zhì)上公式朗讀是一個(gè)需要上下文理解能力的任務(wù)而傳統(tǒng)TTS架構(gòu)里根本沒有上下文理解模塊。這也是我判斷純靠引擎優(yōu)化救不回來的依據(jù)之一。3.3 多語種混讀對(duì)語言判定模型的挑戰(zhàn)再補(bǔ)充一個(gè)很少被提及但現(xiàn)實(shí)存在的難題公式里的多語種混合。中文數(shù)學(xué)教材的朗讀習(xí)慣是中文句式英文變量希臘字母的混排。比如設(shè)α為銳角則sinαcos(90°-α)這句話TTS需要在一句話里完成中文、希臘字母、英文函數(shù)、角度符號(hào)的四種發(fā)音模式切換。而大多數(shù)TTS引擎按整句語言識(shí)別局部發(fā)音字典的方式工作句子級(jí)別判定為中文后α、sin、cos這些非中文片段就交給發(fā)音字典去碰運(yùn)氣。碰運(yùn)氣的結(jié)果就是α有時(shí)讀阿爾法有時(shí)按英文字母A讀β有時(shí)讀貝塔有時(shí)讀B°這個(gè)符號(hào)在部分引擎里直接靜音在另一部分里讀成度已經(jīng)算很給面子了。語言模型在短片段內(nèi)頻繁切換語種的場(chǎng)景下準(zhǔn)確率會(huì)急劇下降這幾乎是所有統(tǒng)一多語種模型的通病也不只是公式場(chǎng)景獨(dú)有的。4. 從根上想辦法三條可落地的修正路線問題掰開揉碎講完了接下來說解決。我實(shí)際驗(yàn)證過、覺得有普適性的方案有三條分別對(duì)應(yīng)不同資源投入和不同質(zhì)量要求。按推薦優(yōu)先級(jí)排復(fù)雜公式走結(jié)構(gòu)化轉(zhuǎn)譯簡(jiǎn)單公式走規(guī)則預(yù)處理預(yù)算充足且場(chǎng)景固定走微調(diào)專用模型。多數(shù)情況下前兩條已經(jīng)夠了。4.1 路線A規(guī)則預(yù)處理用腳本把公式變成口語文本思路很簡(jiǎn)單在喂給TTS之前先用腳本把公式轉(zhuǎn)換為帶口語化標(biāo)記的朗讀文本讓引擎讀的是已經(jīng)轉(zhuǎn)譯好的人話而不是原始公式字符串。以x^2 2x 1 0為例預(yù)處理腳本可以輸出x的平方加二x加一等于零。這里的關(guān)鍵不只是把^2替換成的平方還包括把2x識(shí)別成二x而不是二乘以x、把 0識(shí)別成等于零而不是等號(hào)零。具體做法上我的建議是先制定一張口語化朗讀規(guī)范表明確每個(gè)符號(hào)、每個(gè)結(jié)構(gòu)的朗讀標(biāo)準(zhǔn)數(shù)學(xué)結(jié)構(gòu)純文本表達(dá)推薦口語讀法x^2x^2x的平方\frac{a}a/ba除以b或b分之a(chǎn)按上下文\sqrt{x1}sqrt(x1)根號(hào)下x加一\log_2 8log_2(8)以二為底八的對(duì)數(shù)\int_a^b f(x)dx積分上下限從a到b的定積分f x d x這個(gè)規(guī)范表要跟教學(xué)內(nèi)容對(duì)齊比如分?jǐn)?shù)線到底讀幾分之幾還是除以需要看用戶習(xí)慣。我曾經(jīng)在某個(gè)項(xiàng)目里因?yàn)榻y(tǒng)一用了除以被一線老師反饋聽起來不夠自然后來改成語境感知規(guī)則純數(shù)值分?jǐn)?shù)讀幾分之幾含變量的分?jǐn)?shù)讀除以問題就解決了。用Python之類的腳本實(shí)現(xiàn)這套規(guī)則工作量約等于寫一堆串行正則和上下文規(guī)則普通人就能搞定。唯一要注意的是正則規(guī)則的優(yōu)先級(jí)要小心比如sqrt要優(yōu)先于sin處理因?yàn)閟in x里的in不能被sqrt之類的長(zhǎng)函數(shù)誤吞。4.2 路線B結(jié)構(gòu)化解構(gòu)把公式翻譯成帶停頓的講解詞規(guī)則預(yù)處理解決的是單個(gè)符號(hào)讀法但真正讀好公式靠的是整體結(jié)構(gòu)的解構(gòu)。這是我個(gè)人最推薦、也是實(shí)測(cè)效果最好的一條路線。思路是拿到公式文本后先解析它的結(jié)構(gòu)樹把、-、×、÷這些運(yùn)算符作為樹的節(jié)點(diǎn)操作數(shù)作為葉子然后按照樹的結(jié)構(gòu)生成一段分層的口語化講解文本。每個(gè)括號(hào)層級(jí)的切換自然對(duì)應(yīng)講解詞里的一組停頓詞或連接詞。舉個(gè)實(shí)操例子。公式(ab)/(c-d)結(jié)構(gòu)樹解析出來后生成的講解文本是括號(hào)a加b除以括號(hào)c減d。這里的括號(hào)和除以就是結(jié)構(gòu)信息的顯式標(biāo)記TTS只需要按普通文本朗讀停頓和重音自然就對(duì)了。更進(jìn)一步可以生成完全講解式文本a加b的和除以c減d的差。這種讀法對(duì)學(xué)習(xí)類場(chǎng)景最友好因?yàn)槿祟悢?shù)學(xué)老師的口語就是這么說的。代價(jià)是需要額外寫結(jié)構(gòu)連詞生成規(guī)則復(fù)雜度會(huì)高一些但對(duì)視頻課、有聲題集這類內(nèi)容質(zhì)量提升是肉眼可見的。我實(shí)際做過的方案是在LaTeX源碼層直接解析因?yàn)長(zhǎng)aTeX本來就攜帶著完整的結(jié)構(gòu)信息\frac{}{}、\sqrt{}、^、_用現(xiàn)成的LaTeX解析器把結(jié)構(gòu)樹提取出來再按結(jié)構(gòu)樹輸出口語文本效果非常穩(wěn)定。如果手里只有圖片公式那就先OCR再加一層LaTeX識(shí)別鏈路會(huì)長(zhǎng)一點(diǎn)但結(jié)果依然可控。4.3 路線C微調(diào)專用TTS代價(jià)高但上限也高如果你預(yù)算充足且公式朗讀是一個(gè)長(zhǎng)期核心功能可以考慮微調(diào)一個(gè)專用TTS模型。思路是收集大量數(shù)學(xué)公式-標(biāo)準(zhǔn)朗讀音頻配對(duì)數(shù)據(jù)在預(yù)訓(xùn)練模型基礎(chǔ)上做二次訓(xùn)練。這條路的效果上限最高因?yàn)槟Ｐ湍軐W(xué)到的不只是單個(gè)符號(hào)的讀法還包括公式朗讀的停頓習(xí)慣、語調(diào)變化、邏輯重音位置。但代價(jià)也很明顯需要成百上千小時(shí)的標(biāo)注語料、專業(yè)發(fā)音人、GPU訓(xùn)練集群以及持續(xù)的數(shù)據(jù)迭代。對(duì)個(gè)人開發(fā)者和小團(tuán)隊(duì)來說門檻確實(shí)高。我的建議是除非你本來就是做語音產(chǎn)品的否則不要從零訓(xùn)練而是基于可商用或開源的語音合成模型做少量數(shù)據(jù)微調(diào)比如用幾百條公式朗讀音頻做風(fēng)格適配。實(shí)測(cè)下來微調(diào)后的模型在停頓合理性上會(huì)有明顯提升但符號(hào)識(shí)別率的提升有限——因?yàn)槟Ｐ驮僭趺次⒄{(diào)輸入端的文本歸一化和分詞還是舊的符號(hào)層面的錯(cuò)亂在上游就注定了。所以即便是路線C也要配合路線A/B使用讓微調(diào)模型去讀已經(jīng)預(yù)處理好的文本效果最佳。5. SSML與發(fā)音字典不強(qiáng)求引擎變聰明的補(bǔ)救實(shí)操前面三條路屬于內(nèi)容側(cè)改造這一章講的是引擎?zhèn)妊a(bǔ)救。如果短期內(nèi)不想大改文本處理流水線又希望立刻改善一部分朗讀效果利用TTS引擎自帶的SSML標(biāo)記和自定義發(fā)音字典是最劃算的做法。5.1 用break標(biāo)記強(qiáng)制給公式斷句SSML語音合成標(biāo)記語言里最實(shí)用的標(biāo)簽之一就是break專門用來控制停頓。公式朗讀最缺的就是結(jié)構(gòu)停頓而break能在不改變文本內(nèi)容的前提下強(qiáng)制引擎在指定位置停頓。比如2(xy)可以生成speak break time100ms/二乘以break time200ms/括號(hào)x加ybreak time100ms/ /speak這樣引擎讀到乘以后面會(huì)停頓200毫秒相當(dāng)于把括號(hào)的存在用聲音暗示出來了。實(shí)測(cè)中100ms~300ms的短停頓在公式里效果最好太短聽不出來太長(zhǎng)會(huì)顯得機(jī)械。另一個(gè)實(shí)用組合是prosody的rate屬性。復(fù)雜的分式或帶多層括號(hào)的公式在朗讀時(shí)把速率降到0.9倍左右清晰度會(huì)有顯著提升。反過來簡(jiǎn)單的235保持1.0倍甚至1.1倍速率讀出來會(huì)更利落。5.2 用sub標(biāo)簽給頑固派符號(hào)指定別名SSML里的sub標(biāo)簽可以讓你指定一個(gè)實(shí)際朗讀的替換文本。這是對(duì)付那些死活讀不對(duì)的符號(hào)的最快手段。speak sub alias自然對(duì)數(shù)ln/sub2等于0.693 /speak另一個(gè)高頻場(chǎng)景是希臘字母直接按中文發(fā)音指定speak 設(shè)sub alias阿爾法α/sub為銳角則sub alias正弦sin/subsub alias阿爾法α/sub等于sub alias余弦cos/sub括號(hào)90度減sub alias阿爾法α/sub /speak用sub標(biāo)簽的好處是不用改原始文本只在合成層做替換不會(huì)破壞原文的公式排版。需要批量處理時(shí)可以用腳本自動(dòng)把公式文本里的符號(hào)替換為帶sub標(biāo)簽的SSML片段再交給引擎。5.3 自定義發(fā)音詞典一次配置全局生效比SSML更一勞永逸的路徑是給引擎配置自定義發(fā)音詞典。大多數(shù)商用TTS都支持用戶上傳一個(gè)詞典文件里面指定特定字詞的讀音。這是糾正sin讀賽因、log讀洛克這類問題的標(biāo)準(zhǔn)做法。以某些引擎為例詞典文件格式大致是這樣的sin 正弦 cos 余弦 tan 正切 log 對(duì)數(shù) ln 自然對(duì)數(shù) √ 根號(hào)配置之后引擎在整個(gè)項(xiàng)目里遇到sin都會(huì)按正弦發(fā)音不需要每個(gè)地方手動(dòng)加SSML。我自己的經(jīng)驗(yàn)是第一步先把數(shù)學(xué)高頻函數(shù)名希臘字母常見符號(hào)全部寫進(jìn)詞典大概50~100條就能消掉大部分低級(jí)錯(cuò)誤。但要注意詞典也有負(fù)面影響如果在線性代數(shù)內(nèi)容里出現(xiàn)sin作為人名或縮寫詞典會(huì)強(qiáng)行按正弦讀。所以詞典要按課程體系分域管理數(shù)學(xué)課里開數(shù)學(xué)詞典普通文本里關(guān)掉。5.4 這些補(bǔ)救的邊界在哪里說句實(shí)話SSML和發(fā)音字典的補(bǔ)救空間是有限的。它們能解決單點(diǎn)讀法錯(cuò)誤但沒有辦法解決整句結(jié)構(gòu)錯(cuò)亂和歧義判斷。比如lim_{x→∞} (11/x)^x e這句話里有極限號(hào)、箭頭、趨向于、括號(hào)層級(jí)、冪指數(shù)、自然常數(shù)光靠SSML和詞典是組織不出當(dāng)x趨向于無窮大時(shí)一加x分之一的x次方的極限等于自然常數(shù)e這種流暢讀法的。這種場(chǎng)景必須回到路線A/B走文本預(yù)處理或結(jié)構(gòu)化轉(zhuǎn)譯。所以我的常用策略是分層治療簡(jiǎn)單符號(hào)錯(cuò)誤交給詞典和SSML復(fù)雜結(jié)構(gòu)錯(cuò)誤交給預(yù)處理腳本兩套方案并行使用各管各的。6. 排查公式朗讀問題時(shí)的實(shí)戰(zhàn)思路最后聊聊排查方法。很多人遇到朗讀錯(cuò)誤第一反應(yīng)是換引擎、調(diào)參數(shù)但往往折騰半天也沒解決。我分享一下自己調(diào)試這類問題的完整思路按這個(gè)順序走效率會(huì)高很多。6.1 先錄音、再分類、后定位拿到一條朗讀不對(duì)的反饋別急著改代碼。先讓出錯(cuò)的音頻和原始公式文本放在一起逐字對(duì)照把實(shí)際讀出來的和應(yīng)該讀出來的差異點(diǎn)列出來然后按第一章的錯(cuò)誤分類表歸檔。這一步看著啰嗦但我吃了不少虧才明白它的價(jià)值。有一次我花了幾個(gè)小時(shí)調(diào)試停頓參數(shù)最后發(fā)現(xiàn)問題根本不是停頓而是log被詞典讀成了樂高——要是早做對(duì)照五分鐘就能定位。錯(cuò)誤分類是排查的錨點(diǎn)沒有分類的調(diào)試就是瞎試。6.2 用最簡(jiǎn)復(fù)現(xiàn)縮小范圍定位問題的標(biāo)準(zhǔn)方法是構(gòu)造最簡(jiǎn)復(fù)現(xiàn)。比如發(fā)現(xiàn)log?8讀錯(cuò)了就分別測(cè)試log2函數(shù)名數(shù)字log x函數(shù)名變量log_2 8帶底數(shù)log(8)帶括號(hào)通過比較這四條的朗讀結(jié)果你很快能判斷出問題出在函數(shù)名識(shí)別、上下標(biāo)處理、還是括號(hào)觸發(fā)哪一個(gè)環(huán)節(jié)。同理如果2(xy)讀錯(cuò)就拆開測(cè)2x、2(x)、(xy)一點(diǎn)點(diǎn)逼近。這個(gè)方法不僅適用于公式朗讀任何語音調(diào)試場(chǎng)景都能用。它能幫你把整體黑盒拆成一組可觀察的局部行為定位效率和準(zhǔn)確率都會(huì)高很多。6.3 結(jié)合文本預(yù)處理鏈路做整體調(diào)優(yōu)當(dāng)單點(diǎn)問題修得差不多之后我建議做一次端到端的音頻質(zhì)量審查找一個(gè)覆蓋各類型公式的測(cè)試題集涉及分?jǐn)?shù)、根號(hào)、上下標(biāo)、求和、極限、矩陣等常見結(jié)構(gòu)然后對(duì)每一類記錄朗讀結(jié)果和人工標(biāo)準(zhǔn)朗讀對(duì)比打分。這個(gè)測(cè)試集不需要很大50條左右就夠用。我自己的體會(huì)是每次改完預(yù)處理腳本或詞典之后跑一遍測(cè)試集看總分變化。如果某類錯(cuò)誤下降了但另一類上升了說明規(guī)則之間有沖突需要調(diào)整優(yōu)先級(jí)。堅(jiān)持迭代兩到三輪整體朗讀質(zhì)量會(huì)趨近穩(wěn)定。測(cè)試集最好貼近真實(shí)課程內(nèi)容我建議直接從目標(biāo)教材里挑例題不要自己憑空編公式。因?yàn)樽跃幑酵鶗?huì)無意中回避真實(shí)語料里的復(fù)雜情況比如帶條件的公式、多行對(duì)齊的行列式而真實(shí)教材里的公式才能暴露引擎的真實(shí)短板。6.4 給團(tuán)隊(duì)或項(xiàng)目的一個(gè)落地建議如果你是在團(tuán)隊(duì)里推進(jìn)這件事我特別建議輸出一份公式朗讀規(guī)范文檔哪怕只有兩三頁(yè)都行。規(guī)范文檔里寫明哪些符號(hào)用中文讀、哪些用英文讀、分?jǐn)?shù)線讀分之還是除以、括號(hào)在處理時(shí)是否顯式讀出來、遇到歧義時(shí)以哪種讀法為準(zhǔn)。這份文檔看起來是小事實(shí)際上是后續(xù)所有腳本和詞典配置的憲法。沒有它每個(gè)開發(fā)者憑感覺加規(guī)則最后維護(hù)成本會(huì)非常嚇人。我自己最后整理出的規(guī)范文檔幾乎是所有改動(dòng)方案的驗(yàn)收依據(jù)腳本規(guī)則要不要加、詞典要不要添詞以規(guī)范文檔為準(zhǔn)。這樣整個(gè)系統(tǒng)的行為才是可預(yù)期的而不是某天某個(gè)符號(hào)突然換了一種讀法大家一臉懵。結(jié)束語一個(gè)實(shí)測(cè)有效的最小改造組合拳最后分享一個(gè)我在不同項(xiàng)目里反復(fù)使用、效果比較穩(wěn)定的組合方案。如果你的目標(biāo)是盡快把公式朗讀質(zhì)量提升一檔我建議按這個(gè)順序操作先寫一份自己的朗讀規(guī)范把容易讀錯(cuò)的50個(gè)常用函數(shù)名和符號(hào)寫進(jìn)自定義發(fā)音詞典再寫一個(gè)簡(jiǎn)單的文本預(yù)處理腳本把上標(biāo)、下標(biāo)、分式、根號(hào)這些結(jié)構(gòu)化內(nèi)容轉(zhuǎn)換成語義清晰的口語文本復(fù)雜公式走LaTeX結(jié)構(gòu)解析輸出帶括號(hào)除以的差這類結(jié)構(gòu)連接詞的講解詞最后用SSML的break和rate做韻律層面的微調(diào)。這套組合不需要?jiǎng)幽Ｐ筒恍枰笠?guī)模訓(xùn)練純粹靠工程手段就能把公式朗讀從不能用拉到基本能用。我踩過最大的坑是迷信某個(gè)智能引擎能一步到位。事實(shí)證明公式朗讀是一個(gè)典型的領(lǐng)域知識(shí)工程細(xì)節(jié)問題領(lǐng)域知識(shí)解決讀什么工程細(xì)節(jié)解決怎么讀少一樣都不行。希望這篇梳理能幫你在做數(shù)學(xué)內(nèi)容有聲化的路上少繞幾個(gè)彎。