本系列旨在分享LLM帶進程式使用的過程、概念。前20天分享從API 串接基礎出發,一路談 Prompt Engineering、Context engineering、harness engineering,建立起「怎麼讓 LLM 好好工作」的完整知識骨架;後10天則動手實作,打造一套個人版的 LLM 流量控管系統,完成多廠商API集中管理的gateway、用量監控等。
目標是走到系列結束時,不只學會怎麼「用」LLM,而且有能力把它當作一個可維運的系統元件來設計與實作。
Day 11|Write:把資訊寫到 context window 之外 目前我們已經知道context window是有上限的,丟太多內容給模型不一定有用,因...
Day 12|Select:挑對的東西拉回 context window 昨天講了 Write——把不急著用的資訊先存到 context window 之外。但...
Day 13|Compress:把已經在 context 裡的內容變小 前兩天談了 Write(先存到外面)跟 Select(挑對的拉回來)。今天要處理的是第三...
Day 14|Isolate:把 context 拆到不同地方,不要塞在同一個窗口裡 前幾天分享的Write、Select、Compress,都屬於「一個con...
Day 15|Prompt Caching:降低成本與延遲 之前有說過,few-shot 範例每次呼叫都要重複送一次,成本會跟著累加。這幾天談的 Write、S...
Day 16|Tool Use 迴圈:讓模型自己決定下一步該做什麼 Day4的時候有提過,tool use的原本的設計目的,是由模型自己決定要呼叫哪個工具、拿到...
Day 17|為什麼需要 Harness Engineering 昨天已經分享完工具迴圈,現在該來檢視一個問題,如果 agent 在某一步犯了錯,呼叫錯工具、用...
Day 18|Harness 的組成元件:把「環境」拆開來看 昨天講了 Harness Engineering 要解決的問題,是讓某一類錯誤從此結構上不可能再發...
Day 19|一個案例,拆解到底:怎麼判斷是不是真的在做 Harness 前兩天分享了「為什麼需要 harness」跟「harness 是甚麼」,道理都懂,但實...
Day 20|動手蓋一個最小可行的 Harness 這幾天分享了為什麼需要 Harness Engineering、有哪些元件,以及怎麼判斷算不算Harness...