# Data Machi

> 從 RAG 到 Agentic Workflow：30 天打造企業知識工作流學習系列

- [Data Machi 30 天學習系列：從聊天到企業 AI 產品](https://data-machi.com/docs/index.md): 30 天從企業 AI、檢索增強生成（RAG）、工具使用（Tool Use）、代理（Agent）、LangGraph 到部署，觀念與實作交錯，逐步完成一套 Data Machi 企業知識工作流。
- [Day 01｜企業 AI 不是聊天機器人，而是能完成工作的系統](https://data-machi.com/docs/30-days/day-01-enterprise-ai-is-not-chatbot.md): 從真實知識工作出發，理解企業 AI 與一般聊天機器人的差異，以及 Data Machi 30 天系列真正要解決的問題。
- [Day 02｜知識工作到底在做什麼？用 FUDAT 拆解五個關鍵步驟](https://data-machi.com/docs/30-days/day-02-what-is-knowledge-work.md): 把抽象的「知識工作」拆解成 Find、Understand、Decide、Act、Track 五個階段，理解 AI 應插入哪個環節才能提升效率。
- [Day 03｜為什麼 AI 知道很多，卻不知道你公司的事？](https://data-machi.com/docs/30-days/day-03-why-ai-does-not-know-your-company.md): 大型語言模型與企業私有資料之間存在三大知識落差，說明可信度為何比流暢度更重要，以及 RAG 如何填補缺口。
- [Day 04｜提示詞（Prompt）寫再長，也不會自動變成工作流程（Workflow）](https://data-machi.com/docs/30-days/day-04-prompt-is-not-workflow.md): 釐清提示詞（Prompt）、規則（Policy）、工具（Tool）與工作流程（Workflow）四個層次的差異，說明為何工作流程的可靠性必須由程式保證，而非只靠文字描述。
- [Day 05｜Data Machi 全貌：30 天我們到底要打造什麼？](https://data-machi.com/docs/30-days/day-05-data-machi-origin.md): 從產品地圖、開發環境與版本流程理解 Data Machi 的前端、後端、模型、RAG、工具與部署，建立後續實作的共同架構。
- [Day 06｜什麼是檢索增強生成（RAG）？讓 AI 從閉卷考試變成開卷考試](https://data-machi.com/docs/30-days/day-06-what-is-rag.md): 透過開卷考試的比喻，理解檢索增強生成（RAG）如何讓 AI 在回答前先檢索企業文件，解決私有資料不可見與答案可追溯的核心問題。
- [Day 07｜一份 PDF，怎麼變成 AI 可以搜尋的知識？](https://data-machi.com/docs/30-days/day-07-pdf-to-searchable-knowledge.md): 從解析、切割到向量化與索引，拆解 PDF 轉化為 AI 知識庫的完整流程，掌握每個步驟對 RAG 搜尋品質的關鍵影響。
- [Day 08｜關鍵字搜尋與語意搜尋：AI 到底怎麼找到對的內容？](https://data-machi.com/docs/30-days/day-08-semantic-vs-keyword-search.md): 比較關鍵字比對與語意向量搜尋的差異，透過企業案例理解各自的適用場景，學習如何結合兩者建立混合搜尋策略。
- [Day 09｜真實文件沒那麼簡單：掃描 PDF、表格與圖片怎麼處理？](https://data-machi.com/docs/30-days/day-09-scanned-pdf-and-visual-content.md): 理解掃描頁、圖表與截圖在企業 RAG 系統中的處理挑戰，從 OCR 到多模態視覺摘要，學習讓 AI 讀懂視覺內容的方法。
- [Day 10｜實作：建立第一個能引用來源的 PDF 檢索增強生成（RAG）](https://data-machi.com/docs/30-days/day-10-rag-is-not-enough.md): 把檢索增強生成（RAG）概念落地，準備 Gemini API、文件索引與查詢流程，完成能依文件回答並保留來源的最小版本。
- [Day 11｜檢索增強生成（RAG）找得到資料，為什麼還是無法完成工作？](https://data-machi.com/docs/30-days/day-11-rag-vs-tool-use.md): 檢索增強生成（RAG）負責從知識庫找回靜態相關內容，工具使用（Tool Use）則讓模型呼叫外部系統取得即時資料或執行操作。理解兩者差異，才能在企業 AI 工作流中選對方法。
- [Day 12｜什麼是工具使用（Tool Use）？讓 AI 從「回答」開始學會「使用工具」](https://data-machi.com/docs/30-days/day-12-what-langchain-solves.md): 理解工具使用（Tool Use）如何讓模型連接外部系統，以及 LangChain 如何整合模型、提示詞、工具呼叫與訊息格式。框架負責技術整合，但業務邏輯、資料品質與安全邊界仍需由系統設計者負責。
- [Day 13｜實作：讓 AI 查 Google Sheets，而不是自己猜數字](https://data-machi.com/docs/30-days/day-13-ai-reads-google-sheets.md): 從 Google 服務帳號（Service Account）、試算表權限、欄位對應到 Pandas 計算，建立 Data Machi 的第一個結構化資料工具。
- [Day 14｜企業知識散落各處：先畫出你的企業知識地圖（Knowledge Map）](https://data-machi.com/docs/30-days/day-14-confluence-and-trello.md): 用 Google Sheets、PDF、Confluence 與 Trello 理解不同資料來源的角色，並決定哪些系統值得接成工具。
- [Day 15｜實作：讓 AI 同時查數字與文件，完成第一次跨來源回答](https://data-machi.com/docs/30-days/day-15-cross-source-workflow.md): 把 Google Sheets 資料工具、PDF 檢索增強生成（RAG）與選配知識來源放進同一個任務，理解跨來源查詢時的拆題、順序與來源整合。
- [Day 16｜什麼時候工具使用（Tool Use）才真正變成代理（Agent）？](https://data-machi.com/docs/30-days/day-16-when-tools-become-agent.md): 探討工具（Tool）與代理（Agent）在架構設計上的本質差異。工具只負責執行被指定的單一能力；代理則會根據任務語意主動選擇工具、觀察結果，並在資料不足時調整策略。
- [Day 17｜推理與行動（ReAct）：代理如何看結果，再決定下一步？](https://data-machi.com/docs/30-days/day-17-react-loop.md): 透過思考（Thought）、行動（Action）、觀察（Observation）三個步驟，理解 ReAct 如何讓代理在每次取得工具結果後重新評估並調整下一步。
- [Day 18｜路由器（Router）與協調者（Coordinator）：會分流，不代表會完成任務](https://data-machi.com/docs/30-days/day-18-coordinator-as-project-manager.md): 理解路由器（Router）與協調者（Coordinator）在代理架構中的分工。前者負責分類與分流；後者還會整合前後文、觀察工具結果、判斷是否補查，並完成最終整合。
- [Day 19｜實作：建立 Data Machi 協調者（Coordinator），讓 AI 自己選工具](https://data-machi.com/docs/30-days/day-19-agent-memory.md): 把 Google Sheets 資料工具與 PDF 檢索增強生成（RAG）交給同一個協調者（Coordinator），讓系統依照問題選擇工具並整合結果。
- [Day 20｜一個問題要查三個來源，代理（Agent）應該怎麼安排？](https://data-machi.com/docs/30-days/day-20-clarification-and-verification.md): 從跨來源任務理解順序執行、平行執行、問題拆解與代理式搜尋（Agentic Search），讓協調者能依資料依賴安排查詢。
- [Day 21｜代理（Agent）為什麼需要記憶（Memory）？哪些資訊該記，哪些不該記？](https://data-machi.com/docs/30-days/day-21-why-agentexecutor-is-not-enough.md): 理解近期對話、摘要記憶與工具結果三種常見記憶，以及哪些資訊可以沿用、哪些應該重新查詢。
- [Day 22｜不知道答案時，代理（Agent）應該追問、重查，還是拒答？](https://data-machi.com/docs/30-days/day-22-what-is-langgraph.md): 理解問題釐清（Clarification）、答案驗證（Verification）與重新查詢的觸發時機，讓企業代理在資訊不足時不再用猜的。
- [Day 23｜代理（Agent）越自由越好嗎？為什麼最後會變得難以控制？](https://data-machi.com/docs/30-days/day-23-parallel-tool-execution.md): 理解黑箱式代理循環在流程順序、人工介入、重試與除錯上的限制，說明為什麼企業場景需要更明確的工作流程。
- [Day 24｜LangGraph 是什麼？用狀態（State）、節點（Node）、連線（Edge）把代理變成工作流程](https://data-machi.com/docs/30-days/day-24-tools-are-not-multi-agent.md): 理解 LangGraph 的狀態（State）、節點（Node）、連線（Edge）與條件連線（Conditional Edge），將多工具代理從黑箱循環轉成可觀察、可測試的工作流程。
- [Day 25｜實作：把協調者（Coordinator）改造成可控的 LangGraph 工作流程](https://data-machi.com/docs/30-days/day-25-human-in-the-loop.md): 把既有協調者（Coordinator）拆成路由、工具、驗證與回答節點，建立可觀察、可重試並可加入人工介入的 LangGraph 工作流程。
- [Day 26｜AI 一定會失敗：逾時（Timeout）、重試（Retry）、備援（Fallback）怎麼設計？](https://data-machi.com/docs/30-days/day-26-timeout-retry-fallback.md): 從模型逾時、限流與服務中斷出發，建立逾時（Timeout）、重試（Retry）、備援（Fallback）、答案驗證與可行動錯誤訊息。
- [Day 27｜代理（Agent）在工作時，使用者為什麼不能只看到轉圈圈？](https://data-machi.com/docs/30-days/day-27-agent-ux.md): 學習如何在 AI 代理執行長時間多步驟任務時提供清晰可信的使用者體驗：用人類可讀的進度提示、可行動錯誤訊息、完成狀態與可恢復任務設計，降低等待期間的不確定感。
- [Day 28｜API 金鑰（API Key）只是開始：企業 AI 的權限、安全與治理怎麼做？](https://data-machi.com/docs/30-days/day-28-meeting-to-action-items.md): 整理 API 金鑰（API Key）、服務帳號（Service Account）、最小權限、資產所有權與離職交接，讓 Data Machi 不綁在單一個人帳號上。
- [Day 29｜實作：把 Data Machi 部署到 Render 與 Vercel](https://data-machi.com/docs/30-days/day-29-security-testing-deployment.md): 從 GitHub 出發，完成 FastAPI 後端、React 前端、環境變數、後端網址與跨來源資源共享（CORS）設定，讓 Data Machi 真正上線。
- [Day 30｜從聊天到產品：30 天後，我們到底完成了什麼？](https://data-machi.com/docs/30-days/day-30-design-your-enterprise-agent.md): 用聊天（Chat）→ 檢索增強生成（RAG）→ 工具使用（Tool Use）→ 代理（Agent）→ 工作流程（Workflow）→ 產品（Product）回顧 30 天成果，完成驗收、交接與下一步規劃。