搜尋意圖： 如果你在找「擷取、轉換、載入 是什麼」或「擷取、轉換、載入 和相近概念差在哪」，先看這頁的短定義、完整說明與延伸比較。
TL;DR： 資料工程核心流程，將原始資料從來源系統擷取（Extract）、清洗轉換（Transform）後，載入（Load）至目標資料倉儲或 AI 訓練管線的三段式架構。
實用情境： 適合用在閱讀 AI 文章、產品文件或和同事討論時，先用一頁快速對齊概念。
下一步： 先讀完定義，再往下看延伸比較與對應工具，把概念轉成實際應用。
資料工程核心流程，將原始資料從來源系統擷取（Extract）、清洗轉換（Transform）後，載入（Load）至目標資料倉儲或 AI 訓練管線的三段式架構。
ETL（Extract, Transform, Load）是資料工程領域歷史最悠久也最核心的架構模式，在 AI 時代的重要性不減反增。隨著大型語言模型（LLM）與機器學習系統對資料品質的依賴程度提升，ETL 管線的設計成為決定 AI 系統上限的關鍵因素之一。
Extract（擷取）階段
Extract 是 ETL 的第一個步驟，負責從多個異質資料來源收集原始資料。資料來源可能包括：關聯式資料庫（MySQL、PostgreSQL）、NoSQL 資料庫（MongoDB、Cassandra）、REST API 與 GraphQL 端點、CSV 或 Excel 等平面檔案、雲端物件儲存（S3、GCS）、即時資料流（Kafka、Kinesis）、網頁爬蟲資料、感測器與 IoT 裝置日誌，以及企業 ERP、CRM 等業務系統。Extraction 的挑戰在於處理各來源的異質性：不同的認證方式、資料格式、更新頻率與資料量。全量擷取（Full Extraction）每次拉取全部資料，適合小型或不常變動的資料集；增量擷取（Incremental Extraction）只抓取自上次執行以來新增或修改的資料，透過時間戳記或變更資料捕獲（CDC，Change Data Capture）實現，適合大型持續更新的資料集。
Transform（轉換）階段
Transform 是 ETL 管線中最複雜也最關鍵的階段，決定了進入 AI 系統的資料品質。常見的轉換操作包括以下幾類。資料清洗（Data Cleaning）：處理缺失值（填充均值/中位數/眾數，或用預測模型填補）、移除重複記錄、修正格式錯誤（如日期格式不一致、大小寫混用）、過濾異常值（Outlier Detection）。格式標準化（Normalization）：統一編碼格式（UTF-8）、統一單位（如將溫度統一為攝氏）、統一類別值的表述（如「台灣」「Taiwan」「TW」統一為同一值）。特徵工程（Feature Engineering）：從原始欄位衍生新特徵（如從訂單時間衍生「星期幾」「是否週末」「距上次購買天數」）、文字欄位向量化（TF-IDF 或 BERT Embedding）、類別變數編碼（One-Hot Encoding 或 Target Encoding）。資料驗證（Data Validation）：確認資料範圍合法（如年齡不超過 150）、必填欄位不為空、外鍵關聯一致性，並記錄資料品質指標（完整率、準確率、一致性）。
Load（載入）階段
Load 階段將轉換後的資料寫入目標系統。目標系統通常是資料倉儲（Data Warehouse，如 BigQuery、Snowflake、Redshift）、資料湖（Data Lake，如 S3 + Delta Lake 或 Apache Iceberg）、特徵儲存（Feature Store，如 Feast、Vertex AI Feature Store），或向量資料庫（Vector Database，如 Pinecone、Weaviate、pgvector）。載入策略分為完全替換（Full Replace，每次全量覆寫目標）、增量附加（Append Only，只新增不刪改，適合事件日誌）、Upsert（根據主鍵更新已存在的記錄或新增不存在的記錄），以及 Slowly Changing Dimension（SCD，追蹤歷史變更，常用於維度表）。
ETL 與 ELT 的區別
傳統 ETL 先在中間層（ETL 伺服器）轉換後再載入目標系統，適合轉換計算量大且目標系統儲存成本高的時代。現代雲端資料倉儲（如 BigQuery、Snowflake）儲存廉價、計算彈性強，催生了 ELT（Extract, Load, Transform）模式：先將原始資料直接載入資料倉儲，再在倉儲內以 SQL 或 dbt（Data Build Tool）進行轉換。ELT 的優勢是保留原始資料便於回溯，轉換邏輯以 SQL 版本控制，擴充性更強。
在 AI 管線中的角色
ETL 是 MLOps 管線的上游基礎。在模型訓練階段，ETL 管線負責將散佈在各系統的訓練資料彙整、清洗並格式化為模型訓練所需的格式（如 Parquet、TFRecord）。在 RAG（Retrieval-Augmented Generation）架構中，ETL 負責將知識庫文件擷取、分段、向量化後載入向量資料庫，供 LLM 即時檢索。在模型監控階段，ETL 持續從生產系統收集預測日誌、用戶反饋與資料飄移指標，觸發模型再訓練。ETL 管線的健壯性直接決定了整個 AI 系統的資料鮮度與可靠性。
在 iPAS 考試中的考點
ETL 在 iPAS AI 應用規劃師初級與中級考試中均有出現，考點集中在理解 ETL 三個階段的職責分工、識別常見資料品質問題（缺失值、重複值、格式錯誤）及其對應的 Transform 處理策略，以及了解 ETL 在 AI 資料管線中的位置（位於資料收集與模型訓練之間）。考生還需理解 ETL 失敗對下游模型品質的影響，即「Garbage in, Garbage out」的具體含義。
常用工具
在實務工具選型上，批次 ETL 常用 Apache Airflow（工作流排程）+ dbt（轉換）+ Fivetran/Airbyte（連接器）。串流 ETL 常用 Apache Kafka + Apache Flink 或 Spark Streaming。雲端原生方案有 AWS Glue、Google Dataflow、Azure Data Factory。在 AI 管線中，Hugging Face Datasets、LangChain Document Loaders 與 LlamaIndex 的 Data Connectors 扮演了輕量 ETL 的角色，專門處理 LLM 所需的文字資料載入與分段。
常見問題
ETL 和 ELT 有什麼差異，現代 AI 專案更常用哪一個？
ETL 是「先轉換再載入」，轉換在中介層完成後才寫入目標倉儲，適合轉換邏輯複雜且原始資料不宜保留的場景。ELT 是「先載入再轉換」，將原始資料直接寫入資料倉儲，再利用倉儲的計算能力做 SQL 或 dbt 轉換。現代 AI 專案更傾向 ELT，因為雲端資料倉儲儲存便宜、可以保留原始資料以供未來回溯分析，且轉換邏輯用 dbt 版本控制更易於維護。但對於需要即時轉換的串流資料管線（如即時詐騙偵測），仍會採用 ETL 架構。
RAG 架構中的 ETL 管線需要做哪些特殊的轉換步驟？
RAG（Retrieval-Augmented Generation）的 ETL 管線相比傳統結構化資料 ETL 有幾個特殊步驟。在 Extract 階段，需要處理 PDF、Word、HTML 等非結構化格式的文件解析。在 Transform 階段，需要將長文件切分為語意完整的段落（Chunking），常見策略有固定大小切分（如 512 tokens）、遞迴切分（依段落、句子層級）及語意切分；接著對每個段落用 Embedding 模型（如 text-embedding-3-large）轉換為向量。在 Load 階段，將（段落文字、向量、來源 metadata）組合寫入向量資料庫（如 Pinecone、Weaviate）。Chunk 大小與 Embedding 模型的選擇直接影響 RAG 的檢索精度。
ETL 管線出錯時對 AI 模型有什麼影響，如何監控？
ETL 管線出錯對 AI 模型的影響深遠，常見表現有：資料遺漏導致訓練樣本不足、資料格式錯誤導致模型解析失敗、類別標籤污染導致模型學到錯誤的對應關係，以及資料飄移（Data Drift）未被偵測導致模型使用過期的分佈假設。監控 ETL 管線需要建立資料品質指標追蹤：記錄每次執行的資料量、缺失率、異常值比例與執行時長，設定閾值並在超過時觸發警報。工具上可使用 Great Expectations 或 dbt Tests 在管線中插入資料品質斷言（Assertion），確保資料在進入模型訓練前通過品質門檻。