再聊小語(yǔ)種翻譯問(wèn)題

今天因?yàn)橹苣┑木壒蕸](méi)怎么上班，于是今天一整天都在折騰如何將 AI 的翻譯能力引入到 WordPress 電商網(wǎng)站中。

其實(shí)這個(gè)話題在前面有篇文章中聊過(guò)，當(dāng)時(shí)使用的方案是仿照 DeepL 的開(kāi)發(fā)文檔開(kāi)發(fā)一款 API 服務(wù)，然后直接修改 TranslatePress 插件的遠(yuǎn)程請(qǐng)求地址。

可能是因?yàn)楫?dāng)時(shí)那個(gè)版本做得比較糙的緣故，效果一直都不怎么好，甚至有些語(yǔ)種的翻譯根本就不成功。

后面文章發(fā)布之后，在一位朋友的幫助下順利將 Worker 的緩存機(jī)制使用了起來(lái)，今天折騰了一上午算是將翻譯這個(gè)流程全部走通了，實(shí)現(xiàn)從零到一的突破。

原本以為后面可以一勞永逸的將這個(gè)方案遷移到另外幾個(gè)電商站點(diǎn)上，從此順利在 WP 網(wǎng)站上實(shí)現(xiàn)絲滑的內(nèi)容 AI 翻譯。

誰(shuí)承想等真正應(yīng)用到生產(chǎn)環(huán)境上之后，問(wèn)題立馬就出來(lái)了。

主要的點(diǎn)有兩個(gè)，其一是速度跟不上，其二是內(nèi)容量多起來(lái)后，AI 的能力跟不上。

比如上圖便是 API 的處理日志，會(huì)發(fā)現(xiàn)當(dāng)翻譯請(qǐng)求的內(nèi)容量上來(lái)之后，AI 根本處理不過(guò)來(lái)。

即便我將 Worker 服務(wù)升級(jí)到付費(fèi)版本，所有限制都去掉之后，還是處理不過(guò)來(lái)。

尤其是對(duì)于文章之類的場(chǎng)景，隨隨便便一篇文章可能有一兩千字，突然大量的翻譯請(qǐng)求進(jìn)來(lái)之后，AI 需要消耗很多資源去消化，過(guò)程中自然需要更多的時(shí)間。

而一旦超時(shí)，你會(huì)發(fā)現(xiàn)在網(wǎng)站前端根本就沒(méi)有相應(yīng)的翻譯效果，而相應(yīng)的 Token 卻實(shí)實(shí)在在被浪費(fèi)掉了，屬于是“人財(cái)兩失”。

過(guò)程中，我分別去調(diào)整了 Prompt 的要求，以及格式處理的要求。

但不管怎么調(diào)整，對(duì)于大內(nèi)容量（文章、長(zhǎng)頁(yè)面）的翻譯，其功能依舊不能實(shí)現(xiàn)。

所以后面這種直接翻譯方案，我可能需要謹(jǐn)慎使用了。

可能針對(duì)這種翻譯場(chǎng)景，我后面會(huì)更傾向于將網(wǎng)頁(yè)上的文本詞條全部下載下來(lái)，本地處理好之后再進(jìn)行上傳。

過(guò)程中的技術(shù)方案有兩種，一是使用 RPA 代替人工去手動(dòng)翻譯，二是直接在數(shù)據(jù)庫(kù)里更新數(shù)據(jù)。

RPA 這種方案我很早之前就做出來(lái)了，但是處理起來(lái)比較耗時(shí)，且因?yàn)轫?yè)面元素不規(guī)則的緣故，比較容易出錯(cuò)。

所以我現(xiàn)在更傾向于直接去更新數(shù)據(jù)表，但困難也比較大，就是需要后面專門抽一塊時(shí)間去學(xué)習(xí) TranslatePress 的代碼結(jié)構(gòu)。

后面碰到某個(gè)假期再去處理吧，現(xiàn)在先用 RPA 方案過(guò)渡一下。