主題
一、概要
1. 優化 LLM 很難的原因是：
- 沒有解法懶人包
- 很難去除 noise
- 模型效能不好評估
- 不知道什麼時候要用哪種優化方式
從這裡會知道有哪些優化 LLM 性能的技術可以選擇，從 Prompt Engineering, RAG 到 Fine-tuning，了解何時要用哪種、為什麼不是另一種，會知道更實際的操作過程，以及如何應用這些技術來解決實際問題。
2. 優化 LLM 不是線性的過程，有兩個方向：
方向1 - Context Optimization (模型具備的知識)
方向2 - LLM Optimization (模型的行動方式)
優化過程有可能會是三種技術間的來回橫跳。
二、優化方法
1. Prompt Engineering
Best Practice：
- 提供清晰指令
- 將複雜任務拆解成簡單小任務
- 讓語言模型有思考的時間
- 給一些例子（Few-shot Learning）
- 系統性地測試變化
- 設評估體系
2. RAG (Retrieval-Augmented Generation)
類似短期記憶，使用外部工具（開書考的概念）來更新知識，並限制模型的回答來減少幻覺。
2.1 成功案例：針對客戶的問題決定用哪個資料庫來回答
[x] 假設性文檔嵌入（Hypothetical Document Embeddings, HyDE）：使用假設答案進行文件搜尋 → 沒什麼用
[x] fine-tune Embeddings: 從準確率來說有幫助，但貴、慢 → 捨棄
[o] chunk/embedding experiments（不同大小的資料塊嵌入不同內容）→ 65%準確率
[o] Cross-Encoder Reranking, classification steps → 85%準確率
[o] Prompt engineering, Tool use, Query expansion → 98%準確率
2.2 檢索的準確性評估框架—開源工具 ragas，有4個評估指標：
測試生成答案和問題的相關程度
- Faithfulness：事實準確性→和事實不符則認定為幻覺（hallucinations）
- Answer Relevancy：答案相關性→是否真的有回答到問題（太低可能要用Prompt Engineering）
測試檢索資訊和問題的相關程度
- Context Precision：noise 的成分多不多
- Context Recall：低的話表示要優化檢索功能
3. Fine-tuning
如果說RAG是短期記憶的話， fine-tune 就是長期記憶、知識內化。
3.1 優點：
- 提高模型性能，通常比 prompt engineering 更有效，prompt engineering 受限於 context size。
- 提高模型互動時的效率
- 減少所需的 talken : 減少複雜指令、範例、模式- 提取大模型的專業知識到小模型，直接和小模型互動
3.2 適合做：
- 取出大模型的知識並強化某個部分
- 修改或訂定模型輸出的結構或語調 ex. 強制輸出有效的JSON
- 教複雜指令
3.3 缺點：
- 不適合引入新知識
- 訓練過程緩慢，無法快速迭代
3.4 成功案例：Canva 把使用者想要設計的內容用 LLM 輸出結構性的指南
3.4.1 成功原因：
任務只需要現有知識、模型擁有非常高質量的訓練資料，因為強調了模型的特定知識，所以可以讓模型輸出特定結果。
3.4.2 實際做法：
- 收集訓練資料集（開源、買市場上的、花錢請人工標注員、從更大的模型中提煉資料）
- 訓練過程：理解可以調的 hyperparameters → 導致 overfitting, underfitting, Catastrophic Forgetting
- loss function 的重要性：預設下一個 token ( 不一定和 downstream task 性能有關)
- 評估模型：專業人士(或GPT-4)對輸出做排行、取不同模型並對生成輸出做比較
- 部署模型：形成反饋循環 — 從生產環境收集樣本→建立新的資料集→ fine-tune 資料集→形成飛輪效應
3.4.3 Best Practice：
- 先用 prompt engineering 和 few-shot learning，需要投入的資本少且迭代快速
- 建立成效的基準線：確切知道想要解決的目標是什麼
- 從小處著手：開發高質量資料集進行 fine-tune，看模型有沒有往正確的方向跑，看模型對哪個領域有困難就用新資料對這部分做改進
- 資料質量比資料量重要
4. 其他應用：Fine-tune + RAG
- 先 fine-tune 讓模型理解複雜指令
- 最小化 prompt engineering 的 token →留更多空間給 retrieved context
- 用 RAG 注入相關知識到 context
案例：Spider 1.0: Yale Semantic Parsing and Text-to-SQL Challenge
給出 NLP 問題和資料庫綱要 (schema) ，模型可以生出 SQL 指令來回答問題嗎？
- 從 prompt engineering 到最簡單的 RAG 開始嘗試 ex.cosine similarity
- 用 HyDE 生成假設的 SQL 語法，依據此做相似度檢索 → 提升5% (到達80%只跟 state of the art 差4%)
- 做 self-consistency 檢查，實際建構查詢並實際去跑，並嘗試用 chain of thought reasoning
總之從最簡單的方式看能擠出多少性能，用最簡單的 prompt engineering 和 fine-tuning 就已經接近 82% 準確率，結合 RAG 之後得到 83.5% 準確率，很逼近 state of the art。
來源：
