Hao程式筆記

NLP Day 45 系列總結與延伸路線 執行需求：CPU 可跑 。今天是「NLP 與大型語言模型應用」系列的第四十五篇，也是專案五篇的最後一篇。我們花一天回顧這 45 天的學習路徑：從 Day 1 的環境與工具鏈開始，經過文本前處理、詞向量、分類、LLM API、微調、檢索、RAG、Agent、LangGraph、成本武器、部署、到最後五天的「企業知識庫問答」專案。本篇不寫新技術，只整理學過的工具、指標、模型，給出延伸到 2025 年 5 月後可走的學習方向。我們會把七個階段的學習重點串成一張圖，並列出五個常見的職涯方向，最後給一份延伸閱讀清單（不引用 2025 年 5 月之後的新工具或新模型）。 引言 回頭看 45 天前，Day 1 我們說「這系列要把讀者從『會用 BERT 做分類』帶到『能獨立打造 LLM 應用』」。今天我們可以驗收這個承諾：Day 1–4 建立環境與基礎（Python、spaCy、jieba、sentence-transformers），Day 5–12 走完 NLP 經典任務（分類、NER、情緒分析、零樣本），Day 13–21 進入 LLM 與微調（API、提示工程、Ollama、結構化輸出、LoRA、評估），Day 22–30 走過檢索與 RAG（嵌入、向量資料庫、查詢改寫、rerank、GraphRAG），Day 31–37 從 RAG 走到 Agent（企業知識庫、ReAct、MCP、多 Agent、安全、文件處理自動化），Day 38–40 加上框架與部署武器（LangGraph、成本最佳化、FastAPI 串流），最後 Day 41–45 把所有工具組合成一個可部署的企業知識庫系統。四十四篇技術文之後的這篇，是把所有工具、指標、概念在腦中重新組合成一張可以帶走的地圖。 本篇的內容分四段：第一段回顧七個階段的學習路徑與代表工具；第二段整理「企業知識庫問答」專案的最終成果；第三段列出 2025 年 5 月前仍可走的延伸學習方向（multi-modal RAG、量化推論、Agent 部署等）；第四段是 45 天學習的「自我評估清單」，讀者可以對照檢查自己學到了什麼、還缺什麼。這篇沒有新的程式碼，但有大量引用 Day 1–44 的連結，方便你回頭補課。 七個階段的學習路徑 在把這張地圖列出來之前，我們先用一段小程...

NLP Day 44 部署與展示 執行需求：CPU 可跑 。今天是專案五篇的倒數第二篇，要把 Day 41–43 的所有成果——語料整備、檢索實驗、評估指標——整合成一個 production-ready 的最小可行產品。整段流程分四步：把 multilingual-e5-small 嵌入模型匯出成 ONNX（opset 17）、用 onnxruntime 1.19 寫 InferenceService、用 FastAPI 0.115 寫 HTTP 端點、用 Streamlit 1.41 寫展示頁。這套 stack 與前系列 Day 40（ONNX + FastAPI）與 CV 系列 Day 44（ONNX + FastAPI + Streamlit）的部署模式完全對齊，方便跨系列橫向比較。整個 stack 在本地 CPU 跑得動：ONNX 匯出約 30 秒、ONNX 推論單次約 80 ms、FastAPI + Streamlit 啟動約 5 秒、端到端問答約 2.5 秒。 引言 Day 41–43 我們累積了「企業知識庫問答」的完整原型：語料是法務部「個人資料保護法」（政府資料開放授權條款—第 1 版），嵌入是 multilingual-e5-small（CC BY-NC），向量索引是 Chroma 0.6.x，檢索是 hybrid_rerank（Day 42 最佳設定），評估是 Day 43 的引用正確率 0.94 + 忠實度 0.88 + 覆蓋率 0.90。今天要把這套原型「上線」：ONNX 加速 embedding 推論、FastAPI 包成 HTTP 服務、Streamlit 做前端展示，並把 Day 43 的錯誤案例寫進 fallback 邏輯。 為什麼選 ONNX + onnxruntime？sentence-transformers 內建 ONNX 匯出，匯出後可以省掉 PyTorch 的 500 MB 依賴，只剩 onnxruntime 的 30 MB；對小型部署或 Docker 容器友善。為什麼用 FastAPI 0.115？原生支援 async、Pydantic v2、OpenAPI 文件生成，是 Python 生態最主流的 HTTP 框架。為什麼用 Streamlit 1.41？ML 工程師最熟悉的快速 demo 工具，30 ...

NLP Day 43 評估與錯誤分析 執行需求：Colab T4 可跑 。昨天我們用三組實驗把檢索 recall@4 從 0.65 提升到 0.85，今天要把焦點從「檢索」轉到「生成」：用 Day 42 選出的 hybrid_rerank 設定（BM25 權重 0.3 + cross-encoder rerank）作為基準模型，在 Day 41 寫出的 10 題評估集上完整評估「生成品質」——引用正確性（citation precision）、忠實度（faithfulness）、覆蓋率，並把錯誤案例分成 FN（漏抓相關條文）、FP（誤判不相關）、Hallucination（生成與檢索不一致）三類做錯誤分析。整段評估在 Colab T4 約 18 分鐘；如果用 Ollama 本地推論可以省 API 成本，但會多 30–40 分鐘。本篇的所有評估指標、錯誤案例、報告都會被 Day 44 部署引用，因此共用設定要與 Day 41–42 完全一致，不會中途修改任何參數。 引言 Day 32 我們用過引用正確率與忠實度兩個指標，當時的 baseline 引用正確率 0.58、優化版 0.94。那個測試只用 10 題評估集、簡化版 prompt、沒有 rerank。今天要把 Day 41–42 累積的所有「專案地基」整合起來：用 hybrid_rerank 檢索、用 Day 32 的結構化 prompt、跑完整的 10 題評估、把指標量化並做錯誤分析。這個流程是工業界做 RAG 評估的標準三步：「跑指標、看指標、做錯誤分析」。 我們今天關注四個指標。**引用正確率（citation_precision）**：模型回答中引用的條號是否真的出現在提供的檢索段落裡，這是企業使用者最在意的「能不能溯源」。**忠實度（faithfulness）**：模型回答中的每個陳述是否能由檢索段落推導出來，避免幻覺。**覆蓋率（coverage）**：ground truth 的所有條號是否都被模型引用。**平均延遲**：每次推論的耗時，作為部署的參考。這四個指標在 RAGAS（0.2.x，2025 年仍在維護）框架裡都有標準實作，本篇手寫一份輕量版以保持程式碼可讀性。 評估的關鍵設計是把「指標量化」與「錯誤分析」分開：前者給出數字（這組 baseline 引用正確率 0.94）...