LLM API 練習： 台幣三元能做多少事? 幫四千多則噗浪貼文下標籤

最近幾個月藉一個專案來學習呼叫 LLM API： 把過去幾年我寫的或者轉發的每一則噗浪貼文打上一些標籤。 成果展示： 標籤列表； "sum of products" 查詢範例： 認知戰*矛盾+政治*矛盾。 也許不是很精確， 不過總比幾千則完全沒有整理的噗文要好。 程式碼與範例資料檔放在 github/tagging-plurk； 這篇筆記一下一路的學習心得。

動手之前已經想好原則： 能夠用傳統程式碼處理的， 就盡量不要叫 LLM 做， 以便減輕它的 "認知負荷"， 讓它可以專心把注意力放在傳統程式無法處理的地方。 這是 整理紫微斗數程式 時想到的心得。

一開始就沒打算用比較貴的商業專屬模型 (例如 Gemini 或 ChatGPT) 而是從 AWS Bedrock 挑選 性價比最佳的開放權重 LLM 。 但是我會花很多時間詢問 Gemini 與 ChatGPT 的意見， 請它們幫我改良下標籤的提示詞之後， 才真的呼叫 API。

最早我的指令大約長這樣： 「對每一則貼文進行摘要， 然後下標籤」。 摘要的目的是方便我目視檢查 LLM 上的標籤是否恰當。 結果效果不太好， 我懷疑是太頻繁的 context switch 消耗 LLM 太多的腦力， 就跟 二手捐贈平台地圖 的例子一樣。 Gemini 也建議改採 stage isolation / loop fission 的方式， 就是把工作拆成兩個迴圈， 先對所有的噗文摘要， 再對所有的摘要下標籤。 果然有改善。

為了避免 LLM 隨意挑的標籤太發散， 我建了一個標籤階層檔案 tag-hierarchy.yaml 只放入我有興趣的標籤。 這更能反映我的個人偏好， 例如對某些特定議題特別深入的關注， 像是 「資訊科技」 和 「中國」 底下都各自可以分出更細的子標籤、孫標籤。 每個標籤加上註解， 更能讓 LLM 照我的意思去解讀。 這是必須而且耗時的人工作業， 也讓我聯想到職場上好的主管必須把指令下清楚。

ChatGPT 甚至還建議我應該把它改成 json 格式以便容納更詳細的定義， 像是為每一個標籤定義/舉例/舉反例等等。 不過我懶惰， 就省略了。

再來， 寫好提示詞 llm-tag.md ( github 上的這個 已經是改良過的目前最新第 N 版)， 把它跟 tag-hierarchy.yaml 以及隨意挑選的 30 則噗文手動貼給 Gemini 貼標籤。 完成之後， 問它： 「根據你剛才執行任務的經驗， 有沒有發現我的指令有哪些地方可以改進，例如矛盾或不夠明確之處?」 也用同樣的方式詢問 ChatGPT。 我在這裡磨了幾週， 不斷改進提示詞。 也是在這個過程當中， 決定改變做法， 完全省略 「摘要」 這個步驟， 讓AI直接從原文下標籤比較單純而且完整， 反正人類可以透過其他界面 (Q.php， 上面的查詢範例) 來檢查結果。

關於提示詞， 值得一提的幾點：

1. 我在兩處提到 「請採寬鬆原則解釋關鍵詞」， 目的是寧濫勿缺 (對! 請再唸一遍) 以利後續在小範圍的噗文內進一步 (例如採更嚴格的標準) 處理， 而不要有遺珠之憾。
2. ...

本來其實打算拿這個專案來練習使用 Hermes agent。 但是 Gemini 還是 ChatGPT 說： 像這種每一批次彼此獨立的作業， 其實直接寫程式呼叫 API 效率高多了。 尤其因為每一批次都共用相同的提示詞跟標籤階層檔案， 如果我所採用的 neocloud (新型雲端公司， 主要提供 GPU 算力、 LLM 模型) 及模型有支援 提示詞快取 (prompt caching) 的話， 效率更高。

再來， 叫 ChatGPT 推薦一些 neoclouds， 最後選定 deepinfra。 (註： 註冊帳號時要輸入 "報稅帳號"， 但格子的數目不足輸入身分證字號? 總之隨便輸入也可以通過。) 取得 API key 之後就可以建一個提示詞文字檔 prompt.txt (例如寫 python 程式算 pi 之類的) 這樣測試：

export OPENAI_BASE_URL=https://api.deepinfra.com/v1/openai
export OPENAI_API_KEY=$(< 金鑰檔路徑)
./llm-query.py --list-models > ml-deepinfra.txt # 產生可用模型列表
./llm-query.py -m openai/gpt-oss-120b -u prompt.txt > ans.txt

然後把 llm-tag.md 跟 tag-hierarchy.yaml 合併成 cached-prompt.txt 作為 system prompt， 再加上隨意挑選的 30 則噗文 plurks.txt 作為 user prompt， 挑一些模型來做實驗： ./llm-query.py -m $MODEL --prompt-cache-key 'tagging-plurk' -d '###' -s cached-prompt.txt -u plurks.txt > result.txt 這裡的 --prompt-cache-key 後面指定一個任選但固定不變的字串， 主要是要幫助 deepinfra 識別哪些不同時間點的呼叫有可能可以共用 cache (跟同時段別的用戶的呼叫作區隔)。

根據類似 在 AWS 上面挑選最佳性價比模型 的篩選方式， 以及詢問 Gemini 或 ChatGPT 的結果， 我挑了以下模型作為 $MODEL 來測試：

deepseek-ai/DeepSeek-V4-Flash
google/gemma-4-26B-A4B-it
meta-llama/Llama-3.3-70B-Instruct-Turbo
openai/gpt-oss-120b
Qwen/Qwen3-235B-A22B-Instruct-2507
zai-org/GLM-4.7-Flash

除了 GLM 會當掉之外， 其他模型跑完的結果連同測試提示詞丟給 Gemini 以及 ChatGPT 評分， 結果兩者一致挑選 deepseek 跟 Qwen! 也許是因為這兩個模型處理中文最順暢? (候選模型經匿名處理， 改用代號， 不讓兩個裁判有先入為主的成見。)

我在科學月刊/科技報導的文章： 「多快好省」的大型語言模型？ DeepSeek的優勢、 爭議與國安隱憂 裡面有提到： 如果在自己的電腦上離線執行 deepseek， 就不會有隱私外洩的問題； 但是被一般人忽略、更嚴重的問題是： 使用者的價值觀可能受到模型潛移默化的影響。 直白地說， 就是有可能被 "黨的價值" 所洗腦。

以我目前的應用情境來說， 機器在雲端， deepinfra 是美國公司， 也許不會被中共監控。 餵給它的資料都是公開資訊， 所以沒有隱私的問題。 「幫噗浪下標籤」 不涉及 "LLM 餵資訊給我吃"， 所以也沒有被洗腦的顧慮。 甚至， 或許因為它更了解中共， 會不會比我更能看出隱藏在看似正常行為之下的認知戰與超限戰動機? 總之， 這次實驗就採用 deepseek 了。

實驗結果： 在 deepinfra 上用 deepseek 幫 4364 則噗浪短文下標籤， 因為有 cache 的幫助， 做了 148 次 API 呼叫， 花了40分鐘 0.09 美元， 不到台幣3元。

總結心得： 採用好的策略， 可以大幅度降低成本又提高效率。 這樣， 像我這種沒有經費的退休族才會有動力真的拿AI來做事 :-)

1. 想清楚你的問題需要用多複雜的工具。 比方說， 如果需要前後連續性 (需要很長的上下文/目前狀態受歷史影響) 才用 agent； 至於 stateless 的問題， 改直接呼叫 LLM 的 API 就好。
2. 先跟強大的模型討論出最佳策略、 費心調整提示詞， 甚至叫它們幫好幾個開放權重的模型的測試結果評分， 最後才挑最佳模型大量 "施作"。

另外， 為了簡化問題， 目前我的處理流程裡直接忽略圖片。 也就是說， 把所有文字都藏在截圖裡的貼文， 一律不會出現在任何標籤底下。 所以也要再次 呼籲網友： 轉貼來自其他社群媒體平台的文章時， 最好可以留下 (1) 原出處網址 (2) 用 文字 摘要， 最好放進一些有助於搜尋此事件的關鍵詞 (人名、地名、...)， 而不是只有文章截圖， 這樣你的貼文會有比較多的機會被 LLM 直接處理、 發揮它的功效。

希望這篇對於跟我一樣慢飛的玩家有幫助。