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