從MLOps到LLMOps，Line臺灣提示工程管理有一套

除了用機器學習（ML）來解決購物推薦問題，Line臺灣也開始擁抱大型語言模型（LLM），來提高工作生產力。

運用LLM的3大挑戰

在剖析自家LLM實戰經驗前，Line臺灣機器學習工程師李婕瑜先是點出，企業運用LLM提高工作生產力時，所面臨的3大挑戰。

首先，企業採用LLM，目的是要提高作業效率，尤其要能即時支援業務應用。這個需求，考驗了企業對LLM的維運管理能力，得要從原本熟悉的機器學習維運（MLOps），進入到大型語言模型維運（LLMOps）領域，學習新的流程整合與團隊協作。

再來，穩定性也是一大挑戰。因為，LLM由提示（Prompt）驅動，這些提示以自然語言表達，不像是程式語言有固定、嚴謹的格式。也因此，提示變動靈活，可能多個字、改個字，LLM就會給出截然不同的答案。於是，企業得要做好提示管理，記錄提示版本，才能維持服務穩定。

企業運用LLM，還會遇到安全性挑戰。因為這些LLM應用，不只要避免輸出歧視內容，也要符合AI相關法規，滿足透明性、可解釋等原則，像是要能解釋LLM為何給出特定答案等。李婕瑜指出，由於LLM應用場景廣泛，Line不只遵守安全法規，接下來還會多想一步、主動出擊，來尋找工具、確保LLM產出的答案更安全。

LLM客服案件分類的提示管理

不只上述痛點，李婕瑜也分享，Line實際應用LLM時遇到的2項難題，包括如何審查LLM生成內容，以及LLM調整到什麼程度，才算是夠好。

她以Line客服案件分類解釋器為例，Line臺灣本部每天會接收大量的客訴案件，但為釐清案件來優化整體Line服務方向，客服人員得先對案件貼標、分類，包括產品、政策、活動、系統問題、客服營運等類別。

在這個專案中，Line想藉助LLM來輔助案件分類，自動產出客訴標籤和整理過的事件原因，來加速客服人員統整需改善之處。

但在執行過程中，Line很快遇到了問題。因為LLM提示撰寫的技術門檻低，不只工程師，連業務、PM都能寫，造成提示內容多變，反而影響了LLM的產出和效能，Line甚至用R&R混亂來形容。

為解決這個問題，Line採用了名為CO-STAR的提示詞撰寫架構，來切分提示任務。這幾個字母分別代表不同要素，比如C是指情境（Context），也就是在提示中描述任務概況、賦予LLM角色；O則指目標（Objective），即在提示中告知LLM想實現的目標，像是「給出案件類別，並總結案件始末」。

再來是S，也就是回覆風格（Style），比如告訴LLM，要以客服身分回答問題。T則是語調（Tone），可以在提示中，要求LLM以溫柔的語調回覆。A則指受眾（Audience）目標，R是輸出的格式（Response），比如「將標籤和案件解釋區分開來」這類描述。

有了CO-STAR切分提示任務，接著還要依據專案特性，來對6個提示類型排序，才能發揮效果。這是因為，每項LLM專案有其重點，以客服案件分類為例，C、O、R類提示更為重要。因此，Line將客服案件分類的提示任務，改以CORAST的順序來重排。

下一步則是確認CORAST各階段的開發人員和驗收人員，比如在C階段，可由熟悉案件分類和定義的客服人員、業務人員來撰寫。又或是在S、T部分，客服人員有其偏好的風格和語調，因此可擔任驗收人員，開發人員只需專注格式處理及提示撰寫。

LLM要優化到什麼程度才夠好？

不只如此，這個LLM案件分類專案，還有第2項挑戰，也就是LLM要優化到什麼程度，才算夠好。

李婕瑜分析，當POC專案快速建立後，團隊會觀察LLM表現，來決定是否採用其他改善方法，來提高LLM效能。以Line客服案件分類解釋器為例，團隊將準確度作為模型表現評估的指標，要是LLM產出低於60%，意味著模型不清楚提示意思。

此時，Line除了考慮常見的檢索增強生成（RAG）、微調等補強手段，還會衡量加入規則式解法、思維鏈（CoT）或少樣本學習等方法，來提高LLM生成準確度。

再來，LLM如何才夠好，還與業務團隊的預期有關。意思是，開發團隊需與業務團隊討論，找出合理的初期LLM準確度共識，「最好是定在當前平均表現的正負10%，」李婕瑜建議。

接下來，只需控管LLM輸出的內容格式統一，整合至既有服務中，LLM專案就大功告成了。

可善用開源工具實作LLMOps

不只是提示管理，LLMOps也是應用LLM的一大課題。

一般來說，LLM應用流程包括了選擇基礎模型、提示工程、評估結果、改善和最終部署上線。但Line思考，能否將人工需介入的流程，縮短為2步驟，即上傳測試資料、進行提示工程，其他的評估、找出改善空間、決定部署上線等步驟，則由工具自動執行。

於是，Line自建一套內部LLM開發管理工具，不少專案都採用。但為了與社群分享這樣的架構，Line找到一款免費開源工具Pezzo，來說明如何建立LLM維運管理平臺。它的好處是，可集中管理不同專案的提示，簡化了提示編輯和版本管理，還能視覺化列出每個開發專案成本，讓使用者一眼掌握LLM專案概況。此外，李婕瑜也推薦開源的ML生命周期管理工具MLflow，因為MLflow也支援提示管理，可記錄不同提示版本表現和差異，兼顧ML和提示管理。

有了這些工具，LLM流程流暢許多，比如在Pezzo中編輯提示後，開發者就能建立頁面，來輸入提示樣板後設資料，再讓使用者決定是否要做RAG。若需要，只需上傳所需資料即可，之後透過MLflow自動完成實驗。這些實驗數據，像是提示版本、分數、模型和時間等，最後都會呈現在起初建立的頁面，Line的LLM客服案件分類器也是如此管理。

Line實作LLMOps，不單為了管理，還為因應法規（如國科會今年提出的AI基本法草案），來提早應對未來可能面臨的問責機制。因此，他們一方面建立問責制度，另一方面也開始評估，運用LLM檢測生成的廣告文案是否符合法規。李婕瑜舉例說明，廣告文案生成後，先經過禁用字詞掃描，通過後進行第二層審查，納入法規、可用詞與不可宣稱詞規範、Line內部法規，以及RAG連結的內部過往審核結果等資料，來讓LLM參考、判斷，廣告文案合規才會正式採用。這正是Line從LLMOps延伸思考的可行合規應用之一。

 相關報導