當你今天想要打造一個以GPT或是大型語言模型（Large Language Model，縮寫LLM）為核心的產品時，馬上就會出現一個困境：技術選擇太多了！
- 我要用GPT4還是GTP3.5？Llama聽說不錯？
- 我要用API來服務還是要自己訓練、部屬模型？
- 我需要Finetune嗎？
- 我要做prompt engineering嗎？怎麼做？
- 我要做retrival嗎？，RAG（Retrieval Augmented Generation）架構對我的任務有幫助嗎？
- ......
一系列的問題接踵而至，如果你有一個ML scientist在你的團隊，又會再把這個困境進一步擴大，主流模型就有十多個、Training有數十種的方法，到底該怎麼辦？
回想2015, 2016年做Deep Learning, Machine Learning，其實也是一樣的困境，傳統ML演算法有十多個，DL的魔法也有數十種不一樣的組合，BatchNorm、Dropout、Regularization、Adam optimizer都好像有用、要不要用？這個問題就跟我們現在面對LLM的各種可能性一樣，眼花撩亂而無法制定策略。
那在2023的今天，我們是怎麼要克服2015年的DL, ML的困境？
台大的李宏毅老師、Deep Learning.ai的Andrew Ng老師和UCBerkeley的Full Stack Deep Learning團隊代替我們解決了這個問題。
舉我最喜歡的FSDL的課程內容為例，2019年FSDL的課程內容就做出下面這頁簡報，並提供我們一個清晰的視角，要選擇各種ML DL的技巧之前，應該先分清楚我們現在遇到的問題，並想清楚哪些方法可以解決這個問題。
如果Training Error比Testing Error低一截，那我們遇到的就是Overfitting，各種類型的regularization或是縮小model都可以派上用場。但是如果我們遇到的是Training Error跟Human的水平有一截差距，那變成我們是Underfitting，反而是要加大model甚至是重新定義問題，找到一個更好fit的問題。
這張圖最少幫助了我3年以上的工作、學習經歷，讓我明確每一步應該做怎樣的決定。
而對於LLM開發，我們也需要一條清晰的思路。
一、從能找到的最強LLM（GPT4）開始你的產品。
我想提的第一點就是不論如何，請從你手邊能找到的最強LLM開始你的產品，以2023年上半年而言，就是GPT4，未來如果有其他更強模型就使用更強的模型。
對於任何一個AI產品而言，同時要面對兩個不確定性：1. 需求的不確定，2. 技術的不確定。技術的不確定指的是：我們沒辦法在訓練模型之前知道我們最後可以得到的Performance。因此很多AI產品投入了資源收集資料及訓練模型，最後卻發現模型遠沒有達到可接受的標準。
在LLM時期其實像是GPT4或是Bard這種模型，反倒提供給我們一個非常強的Baseline，所以請先使用你能找到的最強模型來開始你的產品。
如果GPT4達到你的標準，請最少做三件事
- 確認unit economics：確保每一次用戶使用你的服務時，你不會虧錢。Ex：用戶訂閱你服務一個月只要120，但是他平均每個月會使用超過120元的GPT-4額度，這就會出現問題（除非你有更完備的商業規劃）。
- 找尋護城河：因為你目前是使用第三方提供的LLM，所以你技術上不具備獨創性，請從其他方面尋找護城河。
- 在達成標準的前提下盡量降低cost：這裡最主要就是3招，1. 換小模型、2. GPT cache、3. 限縮LLM使用場景。
特別提一下「GPT cache」，在傳統chatbot中大多有一個功能是開發者提供QA pairs，然後每次用戶問問題，就從這些QA pairs中找尋最佳的回答，而GPT cache其實就是把每次GPT的回答記起來，當成一個QA pair，新問題進來時就可以先找有沒有相似的問題，減少訪問GPT API的次數。
二、如果GPT4（或你嘗試的LLM）沒有達成標準，請試圖分析LLM失敗的原因。
通常來說，LLM會失敗主流會有4種原因，我分為兩種大的類別：
- （Factual相關）LLM不具備這個知識：1. 嘗試RAG（Retrieval Augmented Generation），2. finetuning
- （Factual相關）LLM在胡言亂語（Hallucination）：1. prompt engineering (CoT, Self Critique)，2. finetuning
- （Reasoning相關）LLM不適應這種類型語料：1. finetuning: language modeling，2. 更換LLM
- （Reasoning相關）LLM無法正確推理這個問題：1. finetuning: supervised finetuning，2. In- Context Learning
這四個問題其實多多少少會有重疊，目前我的檢測方法也沒有辦法完全把他們區隔開，或是明確辨識LLM出現了哪個問題，所以很多是更依賴ML scientist的直覺跟各式各樣實驗的結果。
先來談Factual相關，如果你的LLM回答問題錯誤，有可能是LLM根本不具備相關知識，導致他只能隨便回答，也有可能試產生了Hallucination（胡言亂語）的現象。而最好區分這兩者的方法，就是做以下實驗。
實驗：選定k筆LLM答錯的資料，在prompt中加入能夠回答這題的相關資訊（也是你確定你未來可以取得的相關資訊），檢測是否有明顯變好，如果有的話那就可以走RAG（Retrieval Augmented Generation）這條路，如果RAG後還是有一定比例的資料無法達成，那則加入像是self critique之類的prompt engineering的方法。之後會再寫文章會再分別介紹RAG常用架構跟prompt engineering。
還有一個更直覺的思考方式：你想要LLM完成的這個任務，會不會在網路上常常出現？如果會常常出現，那高機率用Prompt engineering就可以，如果是冷門資訊，甚至是網路上不會出現的資訊（機構內部資訊），那就一定要走RAG。
Ex:
1. 開發玉山銀行的客服機器人，高機率用RAG比較好。
2. 開發一個每天誇獎你的對話機器人，高機率只要prompr engineering，因
為誇獎的用詞、知識、方法網路上出現很多次。接著來談Reasoning相關，如果LLM有相關知識，但是回答的時候錯誤率依舊很高，那就要考慮是不是LLM根本不具備需要的推理能力。而這又分為兩種：1. LLM對這種類型的文本不熟悉，2. LLM對這種類型的推理、分類問題不熟悉。兩者最直接的區分方法：讓LLM在你對應的文本算perplexity。
perplexity是用來衡量「LLM預測下一個詞的混亂程度」，如果perplexity高，代表LLM對這類型的文本領域（domain）根本不熟，可能是語言不熟悉，也有可能是內容領域不熟悉，這時候就一定要走language model finetuning，藉由unsupervised的finetuning，加強LLM對你的文本領域的熟悉度。而如果perplexity很低，但是問題還是解決不好，則更需要訓練LLM處理特定的問題，因此則要走supervised finetuning，這就類似傳統finetune CNN，蒐集Label data，讓模型學會執行對應任務。
如果是利用GPT4之類的API，我們沒辦法取得perplexity的數值，因此可以從你的文本中找出你認為基礎的知識語句，找個100句，每一句拋棄後半段請GPT4自行接龍，再基於結果判斷GPT4到底有沒有你這個領域的經驗。
順帶一提，perplexity是高是低，其實是一個非常需要經驗的事情，所以只能當作參考指標。如果一個model對文本的embedding你可以取得，那可以對embedding去train linear classifier，如果non seperable，則表示這個model無法足夠細緻的處理這類型的問題，則更需要supervised finetuning。
後續會提finetuning如何降低成本，不過只要finetuning對你而言是可以承擔的事情，建議對任何任務都先跑100~1,000筆資料、1個epoch的supervised finetuning，和10,000個token的language modeling。這會更像是以前DL我們直接用訓練來觀測模型是否會有顯著改善。
總結
- 先用GPT4來做MVP，如果可行則確認unit economics、尋找護城河跟盡量減低cost。
- 分析錯誤來源
- 如果錯誤跟factual比較有關，藉由跑「給定相關資訊來進行預測」的實驗測試LLM到底是不具備相關知識還是Hallucination。
- 如果錯誤跟reasoning比較有關，則藉由perplexity區分model需要language modeling finetuning還是supervised finetuning。
- 如果finetuning是可行的（有一定量資料、成本可接受），直接跑小範圍的finetune可以驗證很多事情。
後續會針對finetuning、prompt engineering、In-context learning跟RAG都會各自有一篇介紹。
