本地跑模型的最小環境：三個選擇與各自適合的人
不必先買顯示卡。依照你的目的，選對工具就能在筆電上開始。
該微調還是該寫提示：先跑完這四個檢查
微調是最後手段，不是第一步。這四個檢查能替你省下大量算力與標註成本。
推理延遲的組成：先知道時間花在哪裡
優化之前先拆解。多數團隊優化錯地方，是因為沒量過各段耗時。
工具呼叫的第一課：把函式描述寫得讓模型看得懂
Agent 不聽話，八成問題出在工具描述。這篇講清楚描述該寫什麼、不該寫什麼。
API 金鑰管理：別讓金鑰進 git，也別只靠 .env
金鑰外洩的成本很高，而且多數是同一種犯錯方式造成的。
離線評測與線上評測：兩者各自能回答什麼問題
離線分數漂亮但線上出事，是因為兩種評測在測不同的東西。
提示詞的四段式結構：角色、任務、限制、輸出格式
大部分「模型不聽話」其實是提示沒有結構。用固定四段式改寫，同一個需求的輸出穩定度通常立刻提升一個檔次。
圖片進模型前該做什麼：解析度、格式與 token 成本
同一張圖，處理方式不同，成本可以差三倍。這篇講清楚前處理的取捨。
LoRA 是什麼：用三個參數理解它在做的事
不用讀論文也能正確使用 LoRA。理解 rank、alpha 與目標模組這三件事就夠了。
RAG 的最小可用架構：五個元件與它們的失敗模式
先把架構圖看懂，再談優化。這篇拆解 RAG 的五個元件，以及每個元件壞掉時使用者會看到什麼症狀。
把 AI 功能寫成可測試的程式：假模型與快照測試
每次跑測試都真的呼叫模型，既慢又貴又不穩定。有更好的做法。
連續批次處理：吞吐量提升最大的一個開關
同樣的硬體，開啟連續批次後吞吐量常常翻好幾倍。理解它為什麼有效。
ReAct 迴圈的實作：思考、行動、觀察的最小骨架
不用框架也能寫出可用的 Agent 迴圈。八十行程式碼就能跑，而且每一步都看得懂。
讓模型只回 JSON：從提示約束到結構化輸出參數
要模型輸出 JSON，光在提示裡拜託是不夠的。這篇整理三個層次的做法，以及各自會在什麼情況下失效。
用模型當裁判：可靠的 LLM-as-judge 怎麼設計
讓模型評分很方便，但預設做法的偏誤很大。這幾個修正能大幅提升一致性。
微調資料集怎麼準備：格式、數量與品質的實際標準
微調成敗八成取決於資料。這篇是可以直接照做的準備流程。
切塊策略比較：固定長度、語意邊界與結構感知
切塊是 RAG 影響最大也最便宜的調整點。三種策略的適用文件類型完全不同。
token 計算與成本估算：上線前先算清楚
幾個簡單的估算就能避免「上線第一週就燒掉整月預算」。
文件理解流程：OCR、版面解析與模型各自負責什麼
把整份 PDF 丟給視覺模型不是最好的做法。分工的流程更準也更便宜。
前綴快取：把重複的系統提示只算一次
如果你的每個請求都帶著兩千字的系統提示，前綴快取幾乎是免費的加速。
Agent 的停止條件：怎麼判斷任務真的完成了
跑不停與提早收工都是常見故障。停止條件需要明確設計，不能只靠模型自己決定。
少樣本示範怎麼挑：三個會讓效果變差的常見錯誤
加了範例反而更糟，通常不是因為範例太少，而是挑錯了。這篇講清楚範例的挑選原則與排列順序的影響。
訓練資料去重：近似重複比完全重複更麻煩
完全相同的樣本好抓，改了兩個字的近似重複才是讓評測分數虛高的元凶。
QLoRA：在單張消費級顯示卡上微調的實際配置
4-bit 量化加 LoRA，讓 24GB 顯示記憶體就能微調中型模型。這是可跑通的設定。
混合檢索：向量搜尋補不上的那一塊
產品型號、錯誤代碼、人名這類字串，向量搜尋常常查不到。關鍵字檢索仍然不可取代。
串接多家模型服務：抽象層該做到什麼程度
過度抽象會綁死自己，完全不抽象又難以換供應商。這是實用的中間路線。
從圖片抽取結構化資料：發票與表單的實作模式
單據辨識不要用自由問答，用 schema 約束加上欄位驗證。
量化怎麼選：INT8、FP8 與 4-bit 的實際差異
量化能省記憶體也能加速，但不同精度的取捨很不一樣。這篇給選擇順序。
讓 Agent 安全地執行程式碼：沙箱的三層防護
允許模型執行程式碼是能力躍升，也是風險躍升。這是可實作的三層防護。
思維鏈的正確用法：什麼時候該讓模型想，什麼時候不該
思維鏈不是萬靈丹。用在不需要推理的任務上，只會增加延遲、成本與出錯機會。
標註指南怎麼寫：一致率低通常不是標註者的問題
兩個人標同一批資料只有六成一致，多半是指南沒寫清楚邊界。
學習率與訓練輪數：從損失曲線讀出該停在哪
微調過擬合的速度比想像中快。看懂曲線比背誦超參數表有用得多。
重排模型該不該加：延遲與命中率的實際取捨
重排幾乎一定能提升品質，問題是值不值得那 200 毫秒。這篇給判斷依據。
重試與降級：模型服務不穩時怎麼撐住
上游會限流、會逾時、會過載。這是一套可直接用的韌性策略。
語音轉文字之後：標點、分段與講者辨識
原始逐字稿幾乎不能直接用。後處理決定了它的實用價值。
串流回應的正確實作：SSE 與中途中斷
串流不只是把字吐出來，還要處理中斷、錯誤與部分結果的保存。
Agent 的記憶設計：短期、長期與什麼都不記
記憶不是越多越好。多數 Agent 需要的其實是好的摘要，而不是完整歷史。
系統提示與使用者提示：邊界該畫在哪裡
把該放系統提示的東西寫進使用者訊息，是最常見也最容易修的架構錯誤。
評測集會腐化：三個月後你的分數還有意義嗎
固定的評測集用久了會失去區分度。這篇講怎麼維護它的有效性。
災難性遺忘：微調後模型變笨了怎麼辦
專項任務變好、其他能力全面退化，是微調最典型的副作用。有幾個明確的緩解手段。
給答案加上引用：可追溯的 RAG 怎麼實作
沒有引用的 RAG 等於沒有依據。這篇示範讓每一句答案都能對回原文的做法。
給團隊的 AI 使用規範：五條就夠的起手版本
落落長的規範沒人讀。這五條涵蓋了大部分實際風險。
圖文混合檢索：讓 RAG 也能搜到圖表
技術文件的關鍵資訊常常在圖表裡。純文字 RAG 會整個漏掉。
模型服務的健康檢查：光看行程還活著不夠
模型服務可以「行程還在但已經不能用」。健康檢查必須做真實推論。
多 Agent 協作前，先問自己是不是真的需要
多 Agent 架構很吸引人，但九成情況下單 Agent 加好工具就夠了，而且更好維護。
提示注入的基本防線：分隔、標記與輸出檢查
只要你的提示裡有使用者輸入或外部文件，就存在提示注入風險。這篇是可以今天就加上的三道防線。
從線上日誌挖評測題：最便宜的高品質資料來源
最貼近真實的題目就在你的日誌裡，關鍵是知道要撈哪些。
合成資料怎麼用才不會反效果
用大模型生成訓練資料很方便，但直接拿來訓練通常會把錯誤一起學進去。
查詢改寫：使用者問得很爛時怎麼救
真實的問題常是「那個怎麼用」。在檢索之前先把問題補完整，命中率會有明顯改善。
把提示與程式碼一起做程式碼審查：該看哪幾件事
提示改動也會造成線上事故，審查標準卻常常缺席。這是一份可用的檢查清單。
視覺問答的提示技巧：讓模型看它該看的地方
同一張圖，問法不同結果差很多。這幾個技巧能明顯提升準確率。
自架還是用 API：把成本算清楚再決定
自架的成本不只是顯示卡租金。這篇把常被忽略的項目列出來一起算。
給工具寫好回傳值：模型讀得懂的錯誤訊息
工具回傳 500 Internal Server Error，模型只能亂猜。錯誤訊息也是提示的一部分。
用提示模板管理版本：把提示當程式碼看待
提示散落在各個檔案的字串裡，就沒辦法回答「上週效果比較好的是哪一版」。
A/B 測試模型改動：樣本數與統計顯著性
看到「新版好 2%」就全量上線，很可能只是雜訊。這篇給實用的判斷方法。
微調模型的版本管理：介面卡、底座與提示要對齊
微調上線後最容易出的事故是版本錯配。三個東西必須綁在一起管理。
嵌入模型怎麼選：維度、語言與成本的三角
嵌入模型換一次就要重建整個索引，所以第一次要選對。這篇整理實際的挑選順序。
非同步批次處理：大量任務怎麼跑得又快又省
一萬份文件要處理，逐筆同步呼叫要跑一整天。批次架構能壓到幾小時。
影片理解的取樣策略：不要每一幀都送
影片內容分析的成本主要來自幀數。取樣策略決定了成本與品質。
限流與排隊：流量尖峰時怎麼不整個垮掉
模型服務的資源無法瞬間擴充，所以入口的排隊策略比擴容更重要。
把人放進迴圈：需要確認的動作該怎麼設計
刪除資料、寄信、付款這類動作不該由 Agent 自行決定。這篇是確認機制的實作模式。
建立你的第一組提示評測集：30 題就能開始
沒有評測集，改提示就只是憑感覺。這篇示範用 30 題建立可重跑的基準。
文本清洗的常見陷阱：全形、零寬字元與 Unicode 正規化
看起來一樣的兩個字串，在程式眼中可能完全不同。中文資料尤其容易中招。
偏好對齊入門：什麼情況下需要 DPO
監督式微調教模型「怎麼做」，偏好對齊教它「兩個都對時選哪個」。多數任務不需要。
metadata 過濾：讓檢索先縮小範圍再比相似度
很多檢索問題不是相似度算錯，而是根本不該搜到那批文件。
用小專案練習：五個能在一天內完成的 AI 實作題
學 AI 開發最快的方式是做完一個能跑的東西。這五個題目難度遞增。
圖片生成接進產品：提示、種子與版權的三個現實問題
生成圖不難，難的是穩定、可重現與可商用。
把模型服務包成 Docker：一份可用的基礎設定
GPU 容器化有幾個固定要處理的點，這是可以直接改用的骨架。
Agent 的成本控管：把費用當成一級指標
Agent 的成本不是線性的，一個沒設限的迴圈就能燒掉整月預算。
溫度、top-p 與重複懲罰：三個參數的實際影響
調參數之前，先知道每個參數實際在改什麼。多數任務其實只需要動一個。
資料集切分：隨機切分什麼時候會騙你
隨機切分很方便，但在有時間性或群組性的資料上會造成嚴重高估。
微調模型的評測：不要只看訓練指標
訓練損失是給訓練用的，上線決策要看另一組數字。
RAG 的評測方法：分開量檢索與生成
把 RAG 當黑箱評測，永遠不知道該修哪裡。這篇拆成兩層各自量測。
AI 功能的錯誤處理：使用者該看到什麼
模型會失敗，這是設計前提。失敗時的體驗決定了產品的可信度。
多模態應用的成本結構：圖片比文字貴在哪
一張圖等於多少 token？搞清楚計費邏輯，成本才控制得住。
灰度發布模型版本：怎麼安全地換模型
換模型跟改程式不一樣，行為變化沒辦法用單元測試涵蓋。要靠流量分配。
Agent 的可觀測性：一次任務該記錄哪些欄位
Agent 出錯時無法重現，通常是因為當時什麼都沒記。這是一份可直接照抄的日誌欄位清單。
長文摘要的兩種策略：分段彙整與滑動精煉
文件超過上下文長度時，怎麼摘才不會漏掉關鍵段落。兩種策略各有適用情境。
指標選擇：準確率什麼時候會誤導你
類別不平衡時，準確率 95% 可能代表模型什麼都沒學到。
微調前的資料脫敏：不要把個資訓進權重裡
資料進了權重就拿不出來。脫敏必須在訓練前完成，這是不可逆的一步。
PDF 進 RAG 前的清洗：頁首頁尾、表格與換行
RAG 效果差，有很高比例的原因出在 PDF 抽取階段就已經爛了。
AI 專案的上線檢查清單：發布前的十六個確認項
把散落在各篇教程的重點收成一張清單，發布前逐項打勾。
多模態輸出的驗證：怎麼確認模型真的看懂了
視覺任務的錯誤特別隱蔽，因為輸出看起來永遠很合理。
語意快取：相似問題直接回舊答案，可以嗎
語意快取能省下大量成本，但誤命中的代價很高。要有明確的適用邊界。
從 Chatbot 到 Agent：三個要補上的東西
已經有一個能對話的機器人，要升級成能做事的 Agent，需要補的其實不多。
讓模型承認自己不知道：降低幻覺的提示設計
模型預設會傾向給出答案。要它回「不知道」，必須明確給出這條路，而且讓這條路夠好走。
資料版本控制：讓每個分數都能追回當時的資料
程式碼有 git，資料常常只有一個資料夾叫 final_v3_new。這是最小可行的做法。
上下文塞多少片段最好：k 值的實測方法
塞越多不一定越準。片段數對準確率的曲線通常在中段就見頂，之後反而下滑。
模型路由：用小模型接住八成流量
不是每個請求都需要最貴的模型。路由做得好，成本可以砍掉一半以上。
任務規劃：先出計畫再執行，值得嗎
讓 Agent 先寫出計畫再動手，在長任務上有效，在短任務上是浪費。這篇給判斷界線。
把需求寫成規格：用驗收條件取代形容詞
「寫得專業一點」對模型沒有意義。把形容詞換成可檢查的條件，輸出品質才會穩定。
監控模型輸出漂移：使用者沒抱怨不代表沒問題
模型行為可能悄悄改變。這幾個不需要標註的指標可以當早期警訊。
文件更新怎麼同步：增量索引的基本設計
文件會改，索引不能每次都全量重建。這篇是最小可行的增量更新設計。
串接外部 API 當工具：認證、重試與冪等
把既有 API 包成工具看似簡單，但認證、逾時與重複執行三個問題一定會遇到。
提示壓縮：在不掉分的前提下把 token 砍掉四成
長提示不只貴，還會讓中段指令被忽略。這篇是實測過的壓縮順序。
父子片段：檢索用小段落，生成給大段落
小片段檢索準，大片段回答完整。父子結構讓你兩者兼得。
多語言提示：中文任務要用中文提示嗎
提示語言、輸入語言與輸出語言可以是三種不同的選擇。這篇整理各種組合的實際差異。
RAG 的快取設計：哪些能快取，哪些不能
RAG 有三個可快取的層次，用對了能省下大半成本，用錯了會回傳過期答案。
把一個大提示拆成多次呼叫：什麼時候值得
一次做完所有事的提示很難調。拆成多步後好維護，但延遲與成本會上升，要拆得有道理。
提示工程的除錯清單：輸出不對時依序檢查這七項
輸出怪怪的時候不要急著改提示。照順序檢查，通常前三項就能找到原因。