https://yennj12.js.org/yennj12_blog_V4/tags/llamaindex/Recent content in LlamaIndex on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 21 Jun 2026 22:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase13-part2-orchestration-zh/Sun, 21 Jun 2026 22:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase13-part2-orchestration-zh/大多數人第一次接觸 LLM 應用，寫的是一個 openai.chat() 呼叫。 但到了生產環境，你需要的是：步驟間傳遞上下文、錯誤自動重試、中間結果快取、非同步平行執行。 單次呼叫處理不了這些；你需要的是一條管線，而不是一個函式。 本文從框架比較到生產監控，完整解析 AI 工作流程編排的每一個決策點。 面試情境：你的團隊要上線一個 RAG 客服機器人，需要：查詢改寫 → 向量檢索 → 文件重排序 → 生成答案 → 品質過濾。QA 反映目前有 15% 的查詢因為某一步失敗而整條管線崩潰。架構師問你：如何設計這個管線的錯誤處理策略，以及你會選哪個編排框架？請解釋你的技術決策。 一、核心問題：單次 LLM 呼叫為什麼不夠 1.1 真實 AI 應用的複雜度 想像你在構建一個智慧文件問答系統。用戶問：「上個季度我們在亞太區的收入是多少？」 一個 openai.chat() 能回答嗎？不行。你需要： 查詢理解：識別出「上個季度」和「亞太區」是關鍵限定詞 查詢改寫：展開成「Q3 2025 Asia Pacific revenue」等多個搜尋變體 向量檢索：從數千份財報文件中找出相關段落 重排序：用 Cross-Encoder 重新對候選段落評分 上下文組裝：把最相關的段落和對話歷史組成 Prompt 生成：呼叫 LLM 生成答案 品質驗證：確認答案有引用來源，沒有幻覺 這是 7 個步驟、至少 4 個外部服務呼叫、數個狀態轉換。這就是工作流程編排要解決的問題。 1.2 沒有編排框架時的痛點 痛點 具體表現 影響 錯誤傳播 步驟 3 失敗 → 整條管線崩潰 15–30% 請求失敗率 重複程式碼 每個專案重寫 retry / logging 開發速度 -40% 測試困難 無法對單一步驟做單元測試 Bug 定位時間 3× 無可觀測性 不知道哪個步驟慢 P95 延遲難以優化 狀態管理 中間結果存在記憶體，重啟即失 長任務無法恢復 1.