21 個域專用 LLM 讓通用 AI 變專家

我把 InfoWorld 的 21 個域專用 LLM 名單拆成可直接套用的選型、訓練與上線模板。

我用通用 LLM 一陣子了，越用越有一種很煩的熟悉感：它什麼都能講兩句，什麼都像懂，偏偏一碰到真正要命的領域就開始飄。法務文字會變軟，醫療語氣會變空，資安分析像在寫部落格評論。最氣的是，它不是不會回，它是回得太順，順到你一開始還會懷疑是不是自己太挑。

後來我看到 Peter Wayner 在 InfoWorld 的這篇 21 LLMs tuned for special domains，整個感覺就很對。這不是在吹某個更大的聊天機器人，而是在講反方向：不要再逼一個泛用模型扮演萬能專家，乾脆把它鎖進一個領域、一種資料、一種任務。這篇沒有給我漂亮口號，只有一個很實際的提醒：專精才是產品，不是附加功能。

別再幻想一個模型包辦所有事

“The best teams are building specialized models for niches—one for the doctors, one for the lawyers, one for the bankers, and so on.”

翻譯一下就是：真正聰明的團隊，早就不想拿一個模型去硬扛全部場景了。泛用模型可以在很多地方看起來像會，但只要錯誤成本一上來，這種「什麼都懂一點」就會變成負擔。醫療、法律、金融、資安這些領域，不是答得漂亮就算數，錯一點都可能出事。

我在產品開發裡看過太多這種設計：一個 AI 助手同時要回客服、讀內部文件、做合規摘要、還要幫分析報表。規格書看起來很省，實作後就開始地獄模式。prompt 越寫越長，guardrail 越加越醜，結果模型還是會在最重要的地方失手。把問題拆成領域任務之後，品質通常立刻上來，因為模型終於不用猜「好答案」到底長什麼樣。

Wayner 這篇把這件事講得很直白：不是拿一艘超級油輪去城市裡轉彎，而是該為不同道路做不同車子。

實操寫法很簡單：先列出你手上最貴的三種錯誤情境。如果你的 assistant 會碰法務審查、臨床支援或威脅情資，不要讓它跟一般內容工具共用同一條模型路徑。先把使用情境切開，再決定每條路要不要獨立 fine-tune，還是加 retrieval 就夠。

• 泛用模型拿來做 draft、分流、初步整理。
• 領域模型拿來做最終答案、抽取、分類。
• 專家路徑要夠窄，才有辦法真的評估。

模型變小，不代表變弱，常常只是比較不浪費

Wayner 提到專精不只為了準，還為了效率。這點我很認同，因為很多架構 review 都會假裝 inference cost 是別人的事，直到帳單來敲門。小而專的模型通常比較省，這不是小氣，是工程現實。

他也提到，有些大模型其實底層就是一群小專家在合作。這件事很值得記住，因為很多團隊太愛拜參數量了。大不等於好，有時候只是你花很多錢去喚醒一堆根本用不到的知識。

我自己看過最典型的狀況，是有人拿一個超大的模型去跑很窄的流程，像合約條款抽取或醫療摘要。Demo 當然能跑，但一上線使用量一多，延遲和成本就開始磨人。最後常常不是模型不行，而是你拿錯尺寸的工具去做固定工作。

實操寫法：把模型大小當成 scope control。任務邊界清楚，就把模型邊界也收緊。真的需要廣度，再考慮 routing 或 MoE，而不是一開始就丟一個巨無霸。若你要做量化或本地部署，先拿真實任務測品質，不要拿泛用 benchmark 自我安慰。

• 先用一條真實 workflow 量 latency 和 cost。
• 量化前先定可接受的準確率底線。
• 領域穩定時，優先選小型專用模型。

訓練資料集，才是你真正的產品

Wayner 講得很準：難的不是模型，是 training corpus。模型只是表面那層好看的東西，資料集才決定你吐出來的是實用答案，還是排版很整齊的胡說八道。文中提到不少案例都請 subject-matter experts 來建 ontology、驗答案，這不是額外工作，這就是主工作。

很多「我們就 fine-tune 一下」的計畫，最後都死在資料品質。資料髒，模型就學髒；標註亂，模型就學會亂得更有文法；參考來源不可信，最後就會得到一個很像專家、其實一直偏掉的系統。這種東西最危險，因為它講話太像真的。

我之前碰過一個法律助理專案，團隊想用內部合約歷史去訓練。第一輪 demo 超漂亮，因為挑的例子都很乾淨。結果一擴大資料範圍，整個地雷區就露出來了：條款版本衝突、舊模板沒清、紅線修到一半、不同部門用詞不一致。模型不是架構錯，而是知識底盤本來就爛。

實操寫法：把花在 corpus 設計上的時間拉高到比選模型還多。先定 source policy，定義什麼叫 ground truth，再找 domain expert 盯邊界案例。如果你說不出一份文件為什麼該進訓練集，那它大概率不該進。

• 先按來源品質篩資料，不要只看量。
• 每筆資料都要留 provenance。
• 有歧義的標註，先讓專家過一輪再訓練。

專用模型要的是驗證，不是感覺良好

Wayner 對 hallucination 的態度很直接：有嚴肅問題的使用者，不會容忍亂編。這也是專用模型存在的理由。做法務或醫療的系統，不能只做到「差不多」，它得可追溯、可檢查，而且要在該安靜的地方安靜。

所以文章裡很多例子都會搭人審或受限流程。像 EvenUp 這類工具會先產出草稿，再交給人 review。這不是弱，這是它知道風險在哪裡。反而是那種什麼都想全自動的設計，常常才最不負責任。

我覺得很多團隊還是想要 AI 魔術秀：按一下，直接出答案，然後就上線。領域系統不是這樣玩的。它需要 guardrail、citation check、escalation path，還要有一個明確的「我不知道」。沒有這些，就不是專家系統，只是帶自動補字的風險機器。

實操寫法：從第一天就把驗證塞進 workflow，不要等出事才補。事實性陳述要要求引用，會影響金錢、健康、法律地位的輸出要設 confidence threshold，風險高的結果一定要人審。若你在受監管領域，review path 應該是產品的一部分，不是例外。

我自己最常用的幾個模式很土，但很有效：

• RAG 用來 grounding。
• Structured extraction 用來做可重複輸出。
• Human approval 用在任何會改變錢、健康、法律狀態的動作。

先看資料和任務，再看品牌名

Wayner 列的例子很雜：有專有系統、有開源權重、有研究專案。這個混搭其實很重要，因為它提醒我，專精不是一種品牌風格，而是一種資料與任務的對齊。像 Hugging Face 上的模型、GitHub 上的 repo、還有文中提到的 Mistral、Microsoft、Google Cloud，名字都很大，但真正該問的是：它到底讀了什麼、誰驗過、要解什麼任務。

這也是我最想提醒台灣團隊的一件事：不要先問「哪個模型最紅」，先問「它的 corpus 是什麼、誰驗證過、失敗模式有沒有被量過」。一個用 PubMed abstract 訓練的模型，跟一個用臨床 guideline 訓練的模型，不是同一種東西。金融也是一樣，拿泛用聊天模型加個 finance prompt，不等於你有金融專家。

我看過不少團隊先買 demo 再補問題，結果發現模型其實是解鄰近問題，不是他們真正要的問題。這種落差通常不會在第一週爆，會在你要上線、要負責、要對結果簽名的時候才爆，而且修起來更貴。

實操寫法：做一份 procurement checklist，先問資料血統，再問評估方式。至少問三件事：訓練用什麼 corpus、誰驗過、測了哪些 failure mode。如果廠商答不清楚，我會直接往下一家走。

• 先問 corpus provenance。
• 再問 domain expert review。
• 最後問 task-specific eval，不要只看泛用 benchmark。

選對專精類型，比硬塞一個大模型重要

我喜歡 Wayner 這篇的另一個點：它沒有把所有 specialization 混成一鍋。分類、生成、推理、檢索、模擬，本來就是不同工作。很多團隊會把這些都想塞進同一個模型，最後做出一個什麼都能碰一下、什麼都不精的怪物。

像 ClimateBERT 主要是抓和分類 climate-related text，這跟寫政策 memo 完全是兩件事。GNoME 甚至不是傳統 LLM，而是圖神經網路，用在材料發現。Earth-2 則偏向氣候模擬與預測。這些都可以叫專用 AI，但根本不是同一類東西。

我一直覺得很多團隊會把界線弄糊：想要同一個模型同時做摘要、分類、推理、流程自動化。結果就是系統越堆越胖，卻沒有一個地方真的好用。比較乾脆的做法，是讓每個模型做它最擅長的思考型態。

實操寫法：先 map task，再 map model。抽取就用抽取導向的模型或 pipeline；推理就測推理模型；模擬就別再拿 chat interface 硬湊。介面不是能力，這句話我真的想刻在很多 PRD 上。

我通常這樣切：

• 分類與偵測：小型領域微調模型。
• 撰寫與解釋：有 grounding 的生成模型。
• 模擬與預測：專門的科學或統計模型。

可抄的模板

# Domain LLM selection template

## 1) Define the job
- Primary task:
- Secondary task:
- What counts as a wrong answer:
- What the model is allowed to do:
- What the model must never do:

## 2) Choose the specialization type
- [ ] Classification / extraction
- [ ] Drafting / generation
- [ ] Reasoning / planning
- [ ] Retrieval / search
- [ ] Simulation / forecasting

## 3) Build the corpus
- Source systems:
- Trusted references:
- Excluded sources:
- Expert reviewers:
- Labeling rules:
- Provenance tracking:

## 4) Pick the model path
- Base model:
- Fine-tune method:
- Retrieval layer:
- Quantization target:
- Hosting target:
- Human review step:

## 5) Evaluate on real cases
- Gold set size:
- Acceptance threshold:
- Hallucination checks:
- Citation checks:
- Latency target:
- Cost per request target:

## 6) Ship with guardrails
- Confidence threshold:
- Escalation rules:
- Audit logging:
- Fallback behavior:
- Human approval required for:

## 7) Prompt skeleton
You are a domain assistant for [domain].
Use only approved sources: [sources].
If evidence is missing, say so.
Cite the source for every factual claim.
Prefer concise answers.
Flag uncertain or risky outputs.

## 8) Review checklist
- Did the answer stay inside the domain?
- Did it cite approved sources?
- Did it avoid unsupported claims?
- Would a domain expert sign off on it?
- Would I ship this in production?

這段就是我會直接丟給團隊的版本。它先逼你回答最 boring 的問題，而這些問題通常才是專案翻車的地方。你如果連 job 都講不清楚，其實不是缺更好的模型，你是缺更好的 spec。

原始來源是 Peter Wayner 的 InfoWorld 文章 21 LLMs tuned for special domains。我這篇是從他的名單和觀點延伸成可直接套用的工作模板，實作建議與選型流程是我自己的整理。