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