https://yennj12.js.org/yennj12_blog_V4/tags/pipeline/Recent content in Pipeline on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 04 Jul 2026 13: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.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part36-eval-pipeline-zh/Fri, 05 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part36-eval-pipeline-zh/Eval Pipeline 和 Eval 的差別： Eval 是你跑一次、拿到一個分數。 Eval Pipeline 是每次系統改變，自動跑、自動比較、自動擋住退化。 法律合約系統漏掉一個風險條款的損失可能是千萬。 靠人記得去跑評估，不夠。 面試情境 面試官：「客戶是一家法律事務所，剛上線了一個合約審查 AI 系統。他們問：每次你們更新 Prompt 或換模型版本，我怎麼知道品質沒有退化？法務長說，如果 AI 漏掉一個風險條款，損失可能是千萬。請設計一個讓客戶可以信任的 Eval Pipeline。」 一、核心問題：為什麼需要 Pipeline Eval（一次性）的問題： 現在的品質：Faithfulness = 0.87 ← 你知道 下週改了 Prompt 之後：? ← 你不知道 三個月後換了模型版本之後：? ← 你更不知道 沒有 Pipeline： 需要有人記得每次改動後去跑評估 → 沒人記得 → 品質退化不被發現 → 客戶先發現 有 Pipeline： 每次 Prompt / 模型 / 資料 變更 → 自動觸發評估 → 分數低於閾值 → 自動擋住部署 → 品質退化在影響用戶之前被系統發現 Eval Pipeline 是把「品質管控」從人工流程變成自動化系統。 這是 POC 到生產的核心差距之一。 二、Eval Pipeline 的四層架構 ┌───────────────────────────────────────────────────────────────────┐ │ Layer 1：黃金資料集（Ground Truth） │ │ 「正確答案是什麼」的標準，由領域專家建立 │ └──────────────────────────────┬────────────────────────────────────┘ │ 每次評估都用同一份資料集 ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 2：離線評估（Offline Eval） │ │ 每次部署前，對黃金資料集跑 RAGAS + Safety，產出指標報告 │ └──────────────────────────────┬────────────────────────────────────┘ │ 評估結果 vs 上一版 baseline ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 3：CI/CD 品質閘門（Quality Gate） │ │ 分數低於閾值 → 自動阻止部署；通過 → 繼續 Canary 部署 │ └──────────────────────────────┬────────────────────────────────────┘ │ 部署到生產後持續監控 ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 4：線上評估（Online Eval） │ │ 生產流量的持續品質監控，偵測 Data Drift 和 Performance Drift │ └───────────────────────────────────────────────────────────────────┘ 三、Layer 1：黃金資料集的設計原則 黃金資料集的每一筆記錄： { "id": "Q042", "query": "這份合約的違約金條款是否符合台灣民法第 250 條？", "context": ["第 3 頁段落.https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part5-frontend-pipeline-zh/Sat, 04 Jul 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part5-frontend-pipeline-zh/後端做得再精巧,使用者感受到的只有兩件事: 「我按下去之後,看得到它在動嗎?」以及「這些任務能不能串起來自動接力?」 前者是即時進度串流,後者是 pipeline 編排。 這一篇——系列最終回——談的就是這條「從按鈕到體驗」的最後一哩路。 四篇走下來:架構(Part 1)、可靠性引擎(Part 2)、實戰任務(Part 3)、生產化(Part 4)。這些都是使用者看不見的底層。最後這一篇,我們談使用者唯一真正碰得到的東西:前端體驗,以及把任務串起來的 Pipeline。 一、即時進度串流:AI 任務為什麼非有它不可 先講「為什麼」。一個 AI 任務可能跑 30 秒到好幾分鐘。如果使用者按下「執行」後盯著一個沒有任何反應的畫面…… 沒有即時進度 ───────────────────────────── [執行] → (轉圈圈…30 秒…) → 使用者以為當機 → 重新整理 → 更慘 有即時進度 ───────────────────────────── [執行] → 「登入中…」→「掃描案件…」→「撰寫第 3 篇提案…」 → 「送出中…」→「完成 ✅」 使用者全程知道它活著、在做什麼、還要多久 對 AI 任務來說,即時進度不是體驗加分,是信任的基礎。因為任務久、又是黑箱,不給回饋,使用者就會焦慮、就會亂按。 這個系統用 SSE(Server-Sent Events) 解決,Part 1 提過機制,這裡完整拆開。 二、SSE 串流的完整運作:四個零件 ┌───────────────────────────────────────────────────────────┐ │ ① 背景任務寫 log │ │ Flow 執行中,每完成一小步就 append 一條 log 到 DB │ │ progress.https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part1-pipeline-zh/Mon, 29 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part1-pipeline-zh/多數 AI 安全工具的做法：把程式碼丟給一個 LLM，問它「有沒有漏洞？」 Cloudflare 的做法：六個獨立 phase、多個平行 agent、adversarial validation、獨立事實查核。 差別不在「用了 AI」，而在「怎麼讓 AI 不說廢話」。 一、為什麼這個 repo 值得深讀 Cloudflare 在 2024 年開源了 security-audit-skill，把他們內部用 AI agent 做安全稽核的系統公開出來。 這不是一個「讓 ChatGPT 讀你的程式碼」的玩具。這是一個： 六階段 orchestrated pipeline，每個 phase 有明確的輸入/輸出 Multi-agent 架構，同一 phase 內多個 agent 平行執行 Adversarial validation：找漏洞的 agent 和驗證漏洞的 agent 是不同的 Structured output + schema validation：輸出有嚴格的 JSON schema Independent verification：最後一道全新 agent 逐一查核每一個事實宣稱 整個 Pipeline 的資料流： codebase │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Phase 1: Recon │ │ Agent 1a (Overview) Agent 1b (Trust) Agent 1c (Input) │ │ └─────────────────────────────┘ │ │ ▼ │ │ architecture.https://yennj12.js.org/yennj12_blog_V4/posts/nyc-taxi-big-data-pipeline-spark-kafka-streaming/Sat, 27 Sep 2025 10:00:00 +0000https://yennj12.js.org/yennj12_blog_V4/posts/nyc-taxi-big-data-pipeline-spark-kafka-streaming/Complete guide to building a production-ready data engineering pipeline for processing NYC taxi trip records using Apache Spark, Kafka streaming, Hadoop ecosystem, and AWS cloud infrastructure.