自架推理服務的完整調校：從裝好到跑滿
裝起來能跑，跟跑到硬體極限之間差了三到五倍。這是逐項調校的順序。
提示自動優化：用資料而不是直覺改提示
手工調提示會遇到天花板。這套流程用評測集驅動搜尋，把改提示變成可重複的最佳化問題。
建立團隊的評測平台：從腳本到基礎設施
每個人各跑各的腳本，分數無法比較。這是評測平台的最小可行設計。
生產級 Agent 架構：狀態機、持久化與重放
Demo 用的 Agent 迴圈撐不起生產環境。這是一套可中斷、可恢復、可稽核的架構。
從零建一套可上線的 RAG：完整流程與關鍵決策點
把前面的零件組起來。這篇是一條端到端的實作路線，含每個決策點的判斷依據。
文件處理管線的完整實作：從掃描件到可查詢的知識庫
把版面解析、OCR、表格抽取與索引串成一條可維運的管線。
多區部署與故障轉移：模型服務的高可用設計
GPU 資源稀缺讓高可用比一般服務更難。這是務實的分級策略。
完整微調專案：從問題定義到上線的十二週流程
把微調當專案管理，而不是實驗。這是一條走得通的時程與里程碑。
對抗性提示測試：上線前先自己攻擊一輪
等攻擊者找出漏洞成本很高。這是一套可自動化的紅隊測試流程。
AI 功能的可觀測性平台：從日誌到可回答問題
記了一堆日誌卻查不出問題，是因為沒有圍繞「要回答什麼問題」來設計。
資料飛輪：讓產品使用產生訓練資料
最好的訓練資料來自產品本身。關鍵是把回收機制設計進使用流程。
Agent 的評測：任務完成率怎麼量
Agent 沒有標準答案可比對。這是一套可執行的任務級評測方法。
知識圖譜輔助檢索：關聯性問題的解法
「A 的主管的部門負責哪些產品」這種問題，向量檢索天生做不好。
視覺模型的評測：怎麼量「看對了沒有」
視覺任務的評測比純文字難，因為錯誤更隱蔽。這是可操作的方法。
推測解碼：在不換硬體的前提下加速生成
用小模型草擬、大模型驗證，生成速度常能提升一到兩倍。
多任務微調：一個介面卡處理多種任務
為每個任務訓一個介面卡，維運會爆炸。合併訓練有技巧。
多輪對話的狀態管理：什麼該留、什麼該丟
對話越長品質越差，是因為上下文管理沒有設計。這是可落地的策略。
把 AI 功能接進既有產品：漸進式導入的六個階段
一次性大改版風險太高。這是可控的導入路徑。
評測的統計嚴謹性：信賴區間與多重比較
200 題的評測集，91% 和 89% 的差距可能完全是雜訊。
工具集設計：從十個工具到五十個工具的擴展
工具變多之後選錯率會急速上升。這是分層與檢索式工具選擇的做法。
RAG 的權限模型：多租戶與文件級授權
企業場景中，檢索錯一份文件就是資安事故。這是可稽核的權限設計。
跨模態檢索的實作：以圖找文、以文找圖
把圖片與文字放進同一個向量空間，需要注意的細節比想像中多。
GPU 資源排程：讓訓練與推論共用叢集
訓練與推論搶卡是常見痛點。這是可運作的分時與優先權設計。
蒸餾：用大模型教出可上線的小模型
把大模型的能力壓縮進小模型，是降低推論成本最有效的手段之一。
團隊的 AI 工程規範：從程式碼審查到事故處理
把散落的最佳實務寫成團隊規範，新人才不用重踩一遍。
標註流程自動化：用模型做初標，人只做審核
人工從零標註太慢。模型初標加人工審核，速度通常快三到五倍。
讓 Agent 處理長任務：檢查點、分段與進度回報
需要跑三十分鐘的任務，不能用跑三十秒的架構。
提示的 A/B 測試框架：把改動風險降到最低
離線分數好不代表線上好。這是一套從灰度到全量的提示發布機制。
即時視訊分析：串流場景的架構取捨
把視覺模型接上攝影機串流，成本與延遲都需要重新設計。
邊緣與本地部署：離線環境的模型服務
不能連外網的環境有自己的一套限制。這是實務上的取捨。
介面卡的線上管理：熱切換與多租戶服務
同一個底座掛多個 LoRA 介面卡，是自架服務最划算的架構。
處理矛盾資訊：文件互相打架時該回答什麼
新舊版本並存、不同部門說法不一，這是真實文件庫的常態。
讓 Agent 安全地執行程式碼：沙箱的三層防護
允許模型執行程式碼是能力躍升，也是風險躍升。這是可實作的三層防護。
技術選型：自建、開源框架還是商業平台
三條路各有適用時機。這是一份可以照著填的決策表。
處理標註分歧：什麼時候該改指南、什麼時候該接受模糊
不是所有分歧都該消除。有些分歧反映的是任務本身的模糊性。
Agent 的權限與稽核：受監管環境的實作
讓 Agent 代替人操作系統，稽核要求會立刻浮現。這是可通過檢核的設計。
把領域知識編進提示：術語表與規則庫的組織方式
領域知識塞進提示會爆長，用檢索又太重。這是中間的做法。
延遲預算分配：從使用者體驗反推每一段的上限
先決定使用者能忍受多久，再把時間分配給各個環節。
持續微調：模型上線後怎麼跟著資料一起長
訓練一次就結束的模型會逐漸過時。這是可持續的迭代機制。
長期維運 RAG：索引膨脹、成本與品質衰退
RAG 上線一年後會遇到的問題，跟上線第一週完全不同。
AI 專案的第一個月：一份可執行的落地計畫
把前面所有內容收斂成四週的具體行動，適合剛啟動的團隊照著走。
合規視角的資料治理：保存期限、刪除權與跨境
AI 專案的資料治理不只是資安問題，還有法遵要求要滿足。
減少 Agent 的無效步數：常見的浪費模式與修法
Agent 平均步數從 9 降到 5，成本與延遲直接砍掉四成。
自我修正迴圈：讓模型檢查並修正自己的輸出
產生—檢查—修正的迴圈能顯著提升品質，但設計不當會變成無限打轉。
災難性遺忘：微調後模型變笨了怎麼辦
專項任務變好、其他能力全面退化，是微調最典型的副作用。有幾個明確的緩解手段。
給答案加上引用：可追溯的 RAG 怎麼實作
沒有引用的 RAG 等於沒有依據。這篇示範讓每一句答案都能對回原文的做法。
成本歸因到功能：知道每個功能花了多少錢
帳單只有一個總數，無法做決策。這是把成本拆到功能層級的做法。
微調的成本回收分析：什麼時候真的省到錢
把一次性成本與持續成本攤開，算出真正的損益平衡點。
表格與數值資料的檢索：為什麼 RAG 算不對數字
問「去年第三季營收多少」，RAG 常常答錯。這是結構化資料該走的路。
圖文混合檢索：讓 RAG 也能搜到圖表
技術文件的關鍵資訊常常在圖表裡。純文字 RAG 會整個漏掉。
Agent 與既有系統整合：把老舊 API 包成可用工具
真實企業的 API 不是為 Agent 設計的。這是包裝層的設計原則。
零結果與低信心的處理：RAG 的失敗體驗設計
查不到東西時的表現，決定使用者還會不會再用這個系統。
自架還是用 API：把成本算清楚再決定
自架的成本不只是顯示卡租金。這篇把常被忽略的項目列出來一起算。
把 Agent 接進客服流程：轉真人的時機與交接設計
Agent 不是要取代真人，而是要知道什麼時候該交出去，以及怎麼交。
A/B 測試模型改動：樣本數與統計顯著性
看到「新版好 2%」就全量上線，很可能只是雜訊。這篇給實用的判斷方法。
RAG 成本優化：從每次問答一塊錢降到一毛
把每個環節的成本攤開，逐項優化。多數系統有五到十倍的優化空間。
非同步批次處理：大量任務怎麼跑得又快又省
一萬份文件要處理，逐筆同步呼叫要跑一整天。批次架構能壓到幾小時。
把人放進迴圈：需要確認的動作該怎麼設計
刪除資料、寄信、付款這類動作不該由 Agent 自行決定。這篇是確認機制的實作模式。
建立你的第一組提示評測集：30 題就能開始
沒有評測集，改提示就只是憑感覺。這篇示範用 30 題建立可重跑的基準。
偏好對齊入門：什麼情況下需要 DPO
監督式微調教模型「怎麼做」，偏好對齊教它「兩個都對時選哪個」。多數任務不需要。
RAG 的評測方法：分開量檢索與生成
把 RAG 當黑箱評測，永遠不知道該修哪裡。這篇拆成兩層各自量測。
模型路由：用小模型接住八成流量
不是每個請求都需要最貴的模型。路由做得好，成本可以砍掉一半以上。
任務規劃：先出計畫再執行，值得嗎
讓 Agent 先寫出計畫再動手，在長任務上有效，在短任務上是浪費。這篇給判斷界線。
提示壓縮：在不掉分的前提下把 token 砍掉四成
長提示不只貴，還會讓中段指令被忽略。這篇是實測過的壓縮順序。
父子片段：檢索用小段落，生成給大段落
小片段檢索準，大片段回答完整。父子結構讓你兩者兼得。