LLM 就那幾個，生成式 AI 產品怎越來越多？
2023 年後半開始，生成式 AI 的開發與競爭如火如荼地開展。雖然 AI 生成內容包羅萬象，但都離不開一件事：使用人類文字向 AI 提出需求。
其中最令人耳熟能詳、也最基礎的，即是暱稱魔法咒語的「prompt」(提示詞)，以及幾乎什麼都能生成的大語言模型 (LLM)。
然而，LLM 的開發極其昂貴、專業且資源消耗巨大。絕大多數企業都沒本錢及意願，從零開發一個新的 LLM。那有趣的來了：AI 競爭開跑至今，成千上萬提供特定領域：介面設計、工作管理、樂曲創作、文章撰寫、客戶服務、程式設計等諸多生成式 AI 產品，是從何而來的呢？
絕大多數，依然離不開「prompt」及大家熟知的幾家寡頭 LLM (Gemini、ChatGPT、Claude、Grok、DeepSeek 等)。
眾多生成式 AI 產品的開發團隊，會預先為 LLM 設定其角色，並開發一套規則及流程，讓使用者不必花太多心思去調整流程、制定規則、撰寫 prompt，而僅需直覺地寫下要求，或者使用開發團隊製作好的直覺化工具來微調，即能產出想要 (堪用) 的結果。當中最直觀的生成式 AI 產品，即是 AI 線上客服。
嗯？聽起來，似乎只需要程式工程師，就能利用現成的 LLM 來開發各種生成式 AI 產品了嘛？
是這樣，但也不是這樣。
語言工作者於製作 AI 產品中的定位
毫無疑問，工程師在這領域扮演最關鍵的角色，況且也不是所有使用 LLM 開發的生成式 AI 產品皆須語言工作者的參與。然而。如果其產品的生成內容著重於面向人類的文字時 (例如 AI 客服)，語言工作者就是產品開發不可或缺的成員。
語言工作者在 AI 產品開發中的職能，我參與過的有兩大類：
- 撰寫 prompt 範本：這通常是直接參與 LLM 本身的開發。語言工作者會按照開發團隊的要求，撰寫各式各樣的 prompt 及 response (回覆)，用以訓練 LLM。例如：撰寫一組 prompt 及 response，讓 LLM 知道可以用什麼樣的 response 回覆什麼樣的 prompt，或是撰寫違反規則的 prompt (例如要求 LLM 提供公司機密、製作違禁品的方法等)，訓練 LLM 回絕這類 prompt 的要求。
- 制定規則：雖然工程師是制定規則及流程的核心，當產品的生成結果直接與人類語言相關時，必然需要專精這方面的語言工作者參與，舉凡術語庫及翻譯記憶庫 (translation memory，下稱 TM) 的建立、風格指南 (style guide) 的撰寫、LLM 生成內容的品質考核 (language quality assurance，下稱 LQA) 等，在在皆不是工程師擅於處理的。
無論是上述的 1 或 2，雖然語言工作者是輔助性的角色，卻同樣是開發團隊不可或缺的成員。本文這次分享的，是我參與 2「制定規則」的經驗。
生成式 AI 翻譯產品開發，語言工作者的體驗
過去一年間，我全職參與了一項 AI 翻譯產品的開發。這項產品的最終目的，是以 LLM 取代絕大多數人工翻譯的職責，處理各種語言的翻譯。
坦白說，雖然我參與的時間相當長，職責絕大部分仍與一般翻譯員/校稿員相似：維護術語庫/語料庫/風格指南，以及進行 LQA。差別在於：我負責 LQA 的對象是 LLM。
程序 1：前置作業
這項 AI 產品，是某網路銷售平台公司，為了簡化及節省本地化作業而開發。因此，我的首要之務是整理出適合 LLM 使用的語料庫、術語庫及風格指南。
- 語料庫：從 TM 中擷取最近期的內容並分類語料：高品質、可用、不可用。
- 術語庫 ABC：類似語料庫的作業，並將術語分類為 A、B、C：
- A：LLM 必須使用的術語
- B：LLM 在特定情境必須使用的術語 (例如：「review」在特定情況必須翻為「審核」)
- C：參考用的術語，LLM 自主判斷是否採納 - 風格指南：將原本以中文撰寫且格式為 .doc/.pdf 的指南翻譯為英文，並以符合開發團隊要求的格式上傳至公司內部語言工作平台上，以利 LLM 使用。
程序 2：LQA
這是我的工作最主要的部份：LQA (語言品質考核) LLM 所翻譯的內容。此流程隨開發階段有所變化，但其核心作業離不開三大步驟：標錯、修復、提報。
- 標錯：將標記的錯誤分類 (例如：文法、語言、風格、標點符號等) 及分級 (極重、重大、次要、偏好性)。
- 修復：透過編輯術語庫、語料庫及風格指南，嘗試讓 LLM 能正確翻譯和遵守規則，是參與開發的語言工作者最重要的職責之一。
- 提報：修復失敗、缺乏有效修復手段，或是判定原文或參考資料 (情境圖片、任務註記等) 有錯或不夠清楚時，提報與開發團隊接手處理。
程序 2 - 2b/3b：判讀 CoT
專案進行了約 6 個月左右時，開發團隊提供新的內部工具，供語言工作者閱讀 LLM 的「Chain of Thought」(思維鏈，簡稱 CoT)，透過閱讀 LLM 的思考過程，推斷錯誤的根源：是風格指南的規則不夠嚴謹？B 術語的情境定義不夠明確？任務註記的內容誤導了 LLM？prompt 的編排有疑慮？還是 LLM 又在胡思亂想？
判讀 CoT 讓我感到最有趣、最有程式開發參與的原因，在於它是非常明確的 debug 環節，也就是從語言中找出錯誤的步驟，只不過程式設計師看的是程式語言，我看的是 LLM 寫的「自然語言」(人類語言)。此外，開發團隊也提供了複製 prompt 到測試介面下修改及重跑的工具，所以我也可以嘗試調整 prompt 來驗證自己的推斷是否正確。這個部分和使用 Stable Diffusion 不斷調整 prompt 內容以生成想要的圖片，頗有異曲同工之妙。
程序 3：RCA 分析報告
這是 2 - 3 「提報」的延伸，每週將 LLM LQA 標記出的錯誤整理及分類，寫成一份 Excel 分析表，作為開發團隊隔週的開發重點依據。因為這部分和 2 - 2/3 有密切關聯，所以我在處理 2、3 的工作時，也會提前粗略記錄這週的報告將有哪些內容。
需要額外寫這份頗花時間的分析報告，理由在於 LQA 流程著重的是「分類錯誤」，是語言工作者面向的分類法，但開發團隊更需要的是「錯誤發生原因」。舉例而言，假如 LLM 引用的語料庫條目有誤，這種情況可能產生正確性或語言性的錯譯、漏譯、超譯、一致性、道地性、文法性等各種子類型錯誤，然而這些分類對開發團隊的意義不大，所以需要這份 Root-cause analysis (根本原因分析，簡稱 RCA) 報告，以利開發團隊快速清楚地了解 LLM 翻譯錯誤的原因。
程序 番外篇：審核 LLM TQE
該公司不只在翻譯方面想使用 LLM，在校對方面也想使用 LLM，且也有同步在進行開發，所以我的另一項工作是審核 LLM 交出的「translation quality evaluation」(翻譯品質評估，簡稱 TQE)，也就是「我審核 LLM 針對平台已實際上線內容所做的 LQA」，判別 LLM 是否有誤標錯誤。如果我判定標錯正確，就在內部專屬平台修正該錯誤或提交相關部門處理；如果我判定是誤標，就根據 LLM 提供的標錯理由 (有點像很短的 CoT)，判斷是否需要調整術語或風格指南，以避免同類錯誤持續發生。
而因為各種因素，這個「番外篇」是最累人的工作……讓我不禁想聊聊，參與這次 AI 翻譯產品開發時所遇到的種種問題。
參與過程中，遭遇的各種難題
溝通不良/資訊不一致，是貫串專案的核心問題。
從我上任的頭 2 項任務：篩選術語庫及語料庫、翻譯風格指南，這個問題就見端睨。
這家公司其實有內部全職語言工作者，但這項 AI 翻譯產品開發除了極少數語種外，最初均是雇用短期外包語言工作者參與開發 (包括我負責的台灣繁體)。此外，有些產線部門還有自己的語言工作者——上述種種我上任時完全不知曉。在尚不能取用內部資料庫、也還無法和內部語言工作者溝通之前，我就必須透過收到的寥寥幾份不完整又不透明的 Excel 檔案，以及內容過時且不足的風格指南，硬著頭皮篩選術語庫、語料庫及翻譯指南。
可想而知，問題很多。直到卸任前，我都在持續調整這時期篩選及翻譯的內容。
這種不一致問題，即便後續提供了更多資料庫權限，也能與內部語言工作者直接線上傳訊後，依然持續存在。直到我把原本參與 LLM 開發的職責交接給內部語言工作者前，我的主要聯絡窗口只有負責 AI 翻譯產品開發的 2 位 PM，而他們代為詢問獲得的資訊往往非常有限且不夠及時。我對各產線部門的內容有足夠了解的時候，已是將 LLM 職責完全交接出去，在卸任前暫代內部人員處理一般翻譯工作的時期了……
無法修改的術語庫
我是遇到了才知道，LLM 會使用的術語庫，包含「我看不到」的術語庫，由其他產線部門自行管理。這些部門不只缺乏對術語 ABC 分類的理解與遵守，還缺乏台繁用語知識，而且其術語庫也是為了自己部門產線所制定，常常偏離一般的譯法 (超譯/定義過度狹義/翻譯過於累贅)，導致只要涉及到該類型術語庫，LLM 必然出錯，且常是大錯。
另外，還有部門會大批上傳「同樣缺乏對 ABC 分類理解的」自訂術語，也是永遠處理不完的問題根源。
外包內容直入語料庫
受限於全職內部語言工作者人數及產能不足，該公司大部分語種都把翻譯需求大量外包出去——且再度因為全職內部語言工作者人數及產能不足之故，外包翻完的內容會在未受內部人員校對的情況下，直接加到語料庫裡面，其條目數量遠遠超出我最初篩選的語料庫 + 內部人員處理的條目。
另外，內部流程也是沒有校稿程序的，因此所有譯文都是初稿 ＝ 最終稿。
而開發團隊制定的 LLM 翻譯流程，使 LLM 不會根據譯者、時間來篩選語料庫內容，導致 LLM 時不時會因為「混合參考不同譯者及時間」的語料庫，進而生成「混亂風格」的翻譯。
LLM 愛幻想又叛逆
可能是受限於 LLM 現階段的能力，以及開發團隊制定的 LLM 翻譯流程之故，LLM 在「一致性」及「標點符號/空格指南遵守度」兩方面，一直都處於不及格的狀態。
何謂一致性問題？
Product price may increase during the ordering process.
訂購期間，產品價格可能會上升。
Product price may decrease during the ordering process.
產品價格在訂購期間有可能下降。
原文可能只有一字之差且應用情境類似，但 LLM 對於這種情況的句法/用詞一致性，從來都不會妥善處理。
何謂標點符號/空格指南遵守度？
如同帳面字義，LLM 常常會在已經理解了風格指南規則的前提下 (透過 CoT 確認)，刻意違背規則。該問題似乎和 LLM 對台灣繁體這語種的理解有所關聯，導致 LLM 有時會自行判定「我認為不遵守指南，才會更合乎台灣繁體的用法」而違背了指南。
然而，無論是 prompt 還是指南中，都有明定指南必須要遵守……
上述這 2 個問題在我負責期間，開發團隊一直解決不了，導致後來團隊要求我以較低的 LQA 標準來評分 LLM 的一致性，並把部分空格規則交由 LLM 翻譯後的邏輯規則編碼來處理。
當然，叛逆只是形容，實際上 LLM 在這方面頻頻出錯的原因，我個人認為在於 LLM 非常、非常會「鑽規則邏輯的空子」。
這張圖可充分展示 LLM 的「叛逆」
而在審核 LLM TQE 方面，LLM 的「叛逆」更是一展無疑。
翻譯時：LLM 會想盡戰法違背風格指南，證明它的版本才是更好更棒的。
TQE時：LLM 會想盡辦法用風格指南吹毛求疵，判定內容違反風格指南。
幸好，開發團隊後來有提供為 LLM TQE 關閉部分風格指南規則的功能，然而頻繁打槍 LLM 吹毛求疵的工作，著實是非常令人疲倦的精神轟炸。
而且風格指南也不能全關，全關了 LLM TQE 就別做了，所以還得衡量關閉的利弊，不適合關閉的可能需要修改規則，然而要改出降低 LLM 吹毛求疵的規則，非常的燒腦。
可能的優化建議
說實話：下方的優化建議不一定有效，即便有效，可能開發團隊也早已想到，只是受限於現實因素 (LLM 翻譯成本、開發時間、各產線的協調等)，直到我卸任前都未見實現，但我認為仍值得一提：
- 更像人工流程的 LLM 翻譯流程：
- 我能查看 CoT 後才得知，原來開發團隊設計的流程是「分步驟且不迴圈的」：LLM 查找好術語及語料 → 翻譯。換言之，即使翻譯時有所疑慮，LLM 也沒辦法回頭查找更多的術語及語料。此外，設計上語料只會查找並參考 3~4 條，非常有限。這與人工翻譯邊翻邊查資料，而且不會有語料量上限，有絕對性的差別。 - 根據譯者及時間，分配語料條目的優先級別及權重：
- 外包內容、各部門各做各的問題，其實也不是這家公司才有的罕見現象，但如果能根據譯者 (內部 > 約聘全職 > 外包接案) 及時間先後 (最新 > 最舊) 分類，我認為必能解決相當程度的翻譯品質問題。 - 各部門達成同調：
- 這項 AI 翻譯產品如果開發成功，全部有翻譯需求的部門都會受惠，理因致力協助，但實際情況卻是「協助寥寥、添亂叢生」。這種頻被扯後腿的開發環境，效率很難高起來。 - 縮減 prompt 長度：
- 制定的翻譯流程，prompt 包含整份風格指南，這佔了整個 prompt 近乎九成的內容。prompt 過長會衍生 LLM 不適應問題 (可能是指南遵守度不夠的原因之一)，但 LLM 又很會鑽空子，導致風格指南難以有效縮減。那麼，或許可以和篩選術語及語料一樣，在每次翻譯前 (每條原文 key 跑一次流程)，先篩選出適用的指南規則並刪除其他不相關部分，以大幅縮減 prompt 長度。
- 「風格指南」內建於 LLM 中 (意即以局部訓練生成「LLM 子版本」)，prompt 就不需要包含厚重的風格指南。
*這是 Stable Diffusion 常態做法，但我不清楚 LLM 在這方面的可行性，畢竟多數 LLM 不像 Stable Diffusion 開源，不過既然有 Gemini Nano 這類 LLM 子版本，技術上應可行。 - 語言工作者更深度參與：
- 雖然後期語言工作者能看到 CoT 和 prompt 了，但卻沒有實際調整 prompt 的權限，只能局部測試後向開發團隊提出建言。這就衍生出 1 項邏輯矛盾：prompt 是用自然語言寫成的，但卻不讓專長是自然語言的語言工作者參與。事實上，prompt 中也一直有未能修正的英文錯字。
- 開發團隊也未開放語言工作者查看「LLM 篩選術語和語料的 prompt」。 - 等 LLM 迭代：
- 這是使用現成 LLM 開發產品最大的瓶頸。我在參與開發期間，有遇過一次 LLM 版本迭代，其結果是 LLM 風格指南中原本為舊版 LLM 撰寫的「防呆」規則，新版 LLM 已不再需要。
- 當然，也不排除迭代後，有些規則會有 LLM 從遵守轉為不遵守的情況，但我認為每次迭代，LLM 必定會變得更「懂事」。
結語
從 2023 年末至今，其實也才過了 2 年多，而 LLM 處理翻譯的問題，已從不堪用轉為「太有個性」。我想要不了多久，不需要人工後續 MTPE (校對機器翻譯) 且看不出問題的 AI 翻譯產品，就會大量問世了吧？亦或許，已經有了呢？
＊本文所有圖片 (含文章縮圖) 皆以 Gemini 透過 Nano Banana 生成。
