THE NOTEBOOK / ARTICLES
文章。
把思考寫下來，讓好奇心接著走。
顯示 23 / 23 篇文章
AI Engineering 研究前線：30 天系列導讀
依序閱讀本地 AI 助理的 30 天實作紀錄，從模型與對話流程走到知識檢索、工具驗證及真實語料評估。
Day 1：LLM本質上就是一個接龍遊戲
從下一個 token 的預測方式認識 LLM，並比較網頁 AI 與本地推論的資料流、硬體需求和 context 預算。
Day 2：與本地模型第一次對話
用 uv 建立隔離環境、啟動 MLX-LM server，再從 Python 程式送出第一個本地模型請求。
Day 3：讓模型可以連續處理多個問題
把一次性 prompt 改為互動式 Chat Runner，讓程式能連續接收問題並有明確離開方式。
Day 4：Prompt 到底改變了什麼？先從 system message 開始
為每次請求加入固定 system message，觀察 system prompt 如何改變本地模型的回答。
Day 5：讓模型回答固定 JSON 格式
加入 `--json-answer`，要求模型回傳固定 JSON，並驗證 `answer`、`limitations` 欄位。
Day 6：模型真的記得上一題嗎？把對話歷史放回每次 request
將已完成的 user／assistant 回合帶進下一次 request，讓互動模式能根據前文回答追問。
Day 7：第一週交付前，先讓本地聊天程式跑完一次驗收
以兩輪真實本地 runtime checkpoint，驗收 JSON 格式回答與 session history。
Day 8：為本地知識庫打地基
建立 inbox 到 raw 的來源轉換流程，將 Markdown、文字、PDF 和靜態 HTML 轉成帶來源欄位的 Markdown。
Day 9：將知識文件送入本地模型前要思考的事
將 raw 文件切成可回查位置的 chunks，並量測 token 數與 evidence budget 對延遲的影響。
Day 10：資料分段後的查詢手法
以 SQLite FTS5 建立關鍵字檢索，使用 BM25 排序 chunks，保留來源檔名和行號。
Day 11：知識庫不能只是關鍵字搜尋
從 raw 文件自動建立來源索引與 source pages，補上可瀏覽的知識庫目錄。
Day 12：同一個問題，三種資料搜尋路徑的差異在哪裡？
比較 raw、wiki 與 hierarchical 三條檢索路徑，釐清導覽頁與回答證據的分工。
Day 13：Context 預算控管
建立 context builder，在預算內排序與去重候選片段，並記錄淘汰原因。
Day 14：將知識庫與模型結合，做出有來源的 RAG
將檢索、context 組裝與本地 Qwen 串起來，產生可回查引用的 RAG 回答。
Day 15：告訴模型能用哪些工具，程式再決定怎麼執行
加入唯讀 `list_sources` 工具，讓模型提出操作，再由 Python 驗證並執行。
Day 16：依文件 ID 讀取受限的內容片段
用 document ID 取回限定數量的文件 chunks；工具不接受檔案路徑，只讀 manifest 指定內容。
Day 17：知識庫找不到答案時，讓使用者挑來源再匯入
將網路搜尋和匯入拆成兩步，只有使用者選定候選來源後才更新知識庫。
Day 18：驗證模型使用工具的準確率
用 10 題固定案例評估工具路由，檢查模型選擇而不執行工具操作。
Day 19：調用工具有固定格式，如果參數錯誤怎麼辦？
檢查工具名稱與 arguments 的欄位、型別和長度，拒絕多餘或格式錯誤的參數。
Day 20：MCP 解決了什麼問題？
比較直接工具呼叫與 MCP client/server 架構，說明目前專案已完成的部分與未實作範圍。
Day 21：第三週回顧：模型提議工具，Python 決定能不能執行
用 checkpoint 回顧第三週工具流程，檢查工具選擇、參數驗證、執行和結果回傳。
Day 22：五份範例文件夠測知識庫嗎？我把語料換成 Kubernetes 文件
改用 Kubernetes 官方 Markdown 文件作為語料，記錄版本、規模、授權與十題起始 benchmark。
還沒有符合的內容。
換個關鍵字，或清除篩選條件再看看。