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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RPA 這種方案我很早之前就做出來了，但是處理起來比較耗時(shí)，且因?yàn)轫撁嬖夭灰?guī)則的緣故，比較容易出錯(cuò)。

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

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