Medium 好讀版: https://bit.ly/4fpxwdn 大型語言模型 (LLM) 為自動化工作流程提供了很多幫助， 很多新的應用因為大型語言模型的出現，從不可能變為可能。 而為了使用模型的回答來串接不同的工作， 結構化輸出 (Structured Output) 幾乎不可或缺。 目前熱門的模型都有支援輸出特定的 JSON 格式，來方便程式處理模型的回答。 不過平常可能不太容易察覺，結構化輸出其實有它的缺點。 要求模型輸出特定的格式有機會降低模型的表現，甚至增加幻覺發生的機率。 大型語言模型如何產生結構化輸出? 想要讓模型照著我們的要求回答問題並不是一件簡單的事情， 資料科學家和工程師們為此提出了很多不同的解決方案。 而目前被廣泛應用到實際產品的方式， 是透過建立目標格式的語法樹來限制模型每一次輸出的 token。 知名的實作有開源的 lm-format-enforcer (LMFE) 或是 Google DeepMind 基於 OpenFST 的實作。 雖然在名詞的使用上各家並沒有統一，但概念上是相似的。 大方向就是強迫模型輸出符合當前語法狀態的 token，遍歷目標語法樹直到結束狀態。 這個方法的可靠性和效率非常高，幾乎可以確保輸出的格式符合規範。 但，最重要的永遠是這個但是， 強迫模型輸出特定的格式意味著每一次輸出的 token 不一定是能夠回答問題的的最佳解。 模型極有可能為了符合格式，讓下一個產生的 token 偏離了正確答案。 隨著任務的複雜度和輸出的增加，這樣的偏差最終就可能導致幻覺或錯誤的回答。 讓模型先好好說話！ 要解決這樣的問題，有一個容易且直覺的方法： 不要限制模型輸出的格式，讓它好好回答問題。 取得答案之後，我們再要求模型將答案轉換成我們要的格式。 這個方法適用在有較長前後文 (Context) 的複雜任務， 因為輸出的內容通常較精簡，模型便可以正確的轉換格式。 但這個方法具體倒底能改進多少輸出的品質呢？ 來作個實驗！ 為了量化結構化輸出對模型表現的影響， 筆者收集了一週份來自立法院的會議紀錄和質詢逐字稿， 總計約 400,000 個 tokens 的文字資料來設計實驗。 完整的資料可以在立院知更的每週新聞下載。 https://lyrobin.com/news 任務目標是請模型整理出當週立法院討論的議題，並做成新聞標題。 在選題上，我們要求模型盡可能的挑選不同領域的議題， 並希望可以避免標題間太過相似。 因此若是模型輸出的標題重覆性越高，則輸出的品質越低。 我們將輸出的標題透過 text embedding 輸出成 embedding vectors， 透過兩兩配對標題並計算彼此的相似度後取平均值， 就可以評估模型的表現。 以下的程式碼分別實作了兩個不同的方法： 1. 立即使用結構化輸出 2. 先不使用結構化輸出，後續多用一個提示來整理輸出格式。 以下我們稱前後者分別為一步和二步驟提示。 https://imgur.com/XJbjNh3 https://imgur.com/MrQswF1 程式的輸出和標題相似度的範例如下。 https://imgur.com/5ifasRa 最後我們用標題間的相似度畫出分布圖，可以得到以下的結果。 https://imgur.com/i2zAPBN https://imgur.com/KzBcQ8R 可以看到二步驟提示得到的標題彼此間相以度較低， 因此議題的差異較高，更符合我們設定的目標。 總結 從我們的實驗可以觀察出， 透過二步驟提示先讓模型好好針對問題回答， 再修改成特定格式有助於提升模型的表現。 因此若是輸入的前後文較長，且任務要求比較複雜， 可以透過這個方法來有效的改善輸出的品質。 希望這個小技巧能對你有一點幫助， 有任何的問題或指教都歡迎留言和我討論。 =========================== 最後小小的宣傳一下我開發的服務：立院知更。 https://lyrobin.com/ 這是一個使用大型語言模型實作的立法院搜尋引擎， 我們希望透過建立更加直覺且便利的立院搜尋引擎， 讓所有人能夠輕易地使用關鍵字搜尋到立院中各種相關文檔及影音資料， 進而提升公民參與。 有任何的想法或意見，都歡迎來信討論！ 參考資料 1. Automata-based constraints for language model decoding https://arxiv.org/abs/2407.08103v1 2. lm-format-enforcer https://github.com/noamgat/lm-format-enforcer -- ※ 發信站: 批踢踢實業坊(ptt-site.org.tw), 來自: 1.161.189.194 (臺灣) ※ 文章網址: https://ptt-site.org.tw/Soft_Job/M.1731591387.A.A6F

推 MoonCode: 11/14 21:58

推 melancholy07: 實作推，但是不是要考慮誤差範圍 11/14 22:19

推 jarvuschen: 請問提升的效益和兩倍cost如何取捨呢 11/15 00:24

推 holebro: 真不錯 11/15 00:29

推 umum29: 讚 請繼續收集之後的數據 畢竟實驗次數越多 結論才越準確 11/15 01:15

推 ATrain: 有人被洋鬼子包養過嗎 11/15 01:15

推 a731977: 11/15 01:33

推 attacksoil: 用html node比較不會出錯 11/15 06:41

推 DrTech: 第二個prompt也未必能選擇最佳解，也沒有控制LLM的輸出。 11/15 07:16

→ DrTech: 其實第二階任務改成選擇題，選擇候選答案，並結合formatte 11/15 07:16

→ DrTech: r控制輸出，其中一種範例：只選擇編號輸出1,2,3,4等選項， 11/15 07:16

推 grado0802: 到底要多有錢才會想包養 11/15 07:16

→ DrTech: 只要消耗one token就能選到答案，成本超低，回應速度超快 11/15 07:16

→ DrTech: 。這種速度與成本會幾乎等於one -prompt。 11/15 07:16

→ DrTech: 等待與消耗硬體資源成本，根本不用耗費2倍cost。 11/15 07:17

→ DrTech: 至於相似度評估，如果你是拿現有別人的embedding模型，要 11/15 07:22

→ DrTech: 先用立法院資料驗證模型品質。不然算出來的相似度會非常的 11/15 07:22

推 smilejin: 閨蜜上包養網還推薦我... 11/15 07:22

→ DrTech: 隨機難以參考。 11/15 07:22

→ DrTech: 範例圖中，八個句子相似度的例子，看起來同語意，但相似度 11/15 07:28

→ DrTech: 卻有0.85, 到0.78的落差。顯然，相似度選用的embedding的 11/15 07:28

→ DrTech: 模型，未必適合您的專案。 11/15 07:28

→ DrTech: 別誤會，架構與技巧本身是沒問題的。只是多提出了實務上更 11/15 07:36

推 qusekii: 包養? 11/15 07:36

→ DrTech: 能省成本，更能驗證效果的客觀做法。 11/15 07:36

推 fukku100: 推推 請問lyrobin有開源嗎 11/15 15:26

→ GoalBased: 所以是用人家的api嗎 可以分享用哪一個嗎 11/15 17:27

推 Hitmear: 你的問題是沒有用思維鏈產答案，而不是一階二階 11/15 18:35

→ yunf: 你想到的人家都做過了 同樣的問題就是別人在系統端改一下 11/18 02:24

推 Y949731: 現在包養網都這麼直接嗎 11/18 02:24

→ yunf: 你就變孤兒了 這樣的研究意義在哪裡？ 11/18 02:25

推 dongdong0405: 我也覺得用思維鏈做一次prompt 就足夠了，除非是逼 11/19 08:35

→ dongdong0405: 不得已我通常不會選擇下兩次 11/19 08:35