Agentic Workflow 是什麼？為什麼 RAG 知識檢索是 AI Agent 的底層蹲馬步
模型走向公共財，真正拉開 AI Agent 差距的是它讀不讀得到對的知識。本文拆解 Agentic Workflow 的運作、RAG 檢索增強生成的建置心法，以及零售電商與行銷廣告為什麼該把知識檢索當成最底層的蹲馬步功夫。
當每個品牌都接得到同一個大型語言模型，差距會出現在哪裡？
Gartner 在 2025 年 6 月預測，超過四成的 Agentic AI（代理型 AI，能自己拆解任務、查資料、執行、再修正的 AI）專案，會在 2027 年底前被取消，原因是成本失控、商業價值說不清、風險控管不足。Gartner 同一份資料還點出一個尷尬數字：市面上號稱做 AI agent 的廠商有數千家，真正具備代理能力的只有約 130 家，其餘多半是把舊的聊天機器人重新包裝。
問題很少出在模型不夠聰明。McKinsey 2025 年 11 月的《The State of AI》調查了 105 國、1,993 位受訪者，發現高達 88% 的組織已經在至少一個職能定期使用 AI，卻只有不到一成真正把 AI agent 規模化用在任何單一職能上。卡關的關鍵往往不在模型，而在地基：要讓 agent 規模化，靠的是乾淨、整合好、治理過的資料，不是散在各處的試算表和老舊資料庫。零售研究機構 IHL延伸 Gartner 的預測進一步指出，agentic AI 在門市端要做自主決策，仰賴的是持續、乾淨、結構化的資料流，一旦這份資料殘缺或破碎，agent 只會用機器的速度做出錯誤決定。
在這些知識密集的應用裡，AI agent 常見的問題不是不夠聰明，是讀不到對的知識。而讓 agent 讀得到對的知識的那套機制，名字叫 RAG。
我們團隊自己也在打這塊地基
這件事 91APP 團隊有切身體會。
為了讓內部的 AI 助手答得出零售與廣告科技的專業問題，我們把數百份簡報、操作 SOP、產業筆記和 Markdown 文件，餵成一套可以被 AI 即時檢索的知識庫。過程中最深的感受是：知識庫不是建一次就結束，它每週都在長大，新的產品功能、新的法規、新的市場數據不斷加進來。在這種狀態下，AI 答得準不準，幾乎完全取決於它檢索得準不準。
這就是為什麼我們會說，知識檢索是最底層的蹲馬步功夫。它不華麗，沒有 demo 上那種一問就答的戲劇性，但它決定了上面所有應用的天花板。後面我們會把這套建置經驗（包含踩過的坑）攤出來講，先從 Agentic Workflow 本身說起。
Agentic Workflow 與 RAG：先把三個構件拆乾淨
很多人把「用 AI」想成一件事：丟一句提示詞（prompt，給 AI 的指令）進去，等它吐一段答案出來。Agentic Workflow 不是這樣運作的。
Agentic Workflow（代理型工作流）指的是 AI 不再只回答一次，而是自己跑一個循環：先規劃要做哪些步驟，再去查需要的資料，然後執行動作，最後檢查結果、不滿意就重來。實作這種「邊想邊查邊做」的方法有好幾種，其中一個經典做法叫 ReAct（Reasoning + Acting，由 Yao 等人 2022 年提出，讓模型交錯產生推理步驟與實際動作），也有人用 plan-execute-reflect（規劃、執行、反思）來描述。不論哪一種，重點都一樣：agent 在這個循環裡會反覆需要「去外面查資料」，而查資料這個環節做得好不好，就是 RAG 要解決的事。
對需要讀文件知識的 agent 來說，要看懂它為什麼少了 RAG 就會瞎，把它拆成三個構件最清楚：
| 構件 | 它決定什麼 |
|---|---|
| 模型 | 語言理解與推理能力，是大家都買得到的公共財 |
| 工作流 | 把規劃、檢索、執行、反思串成一個會自我修正的循環 |
| 知識檢索 | 讓 agent 讀到品牌私有、結構化、不斷更新的資料，是真正的私有底座 |
模型這一塊，今天大家用的其實是同一批基礎模型，買得到、追得上，很難靠它拉開差距。工作流是把模型的能力編排起來，讓它會自己拆步驟。而知識檢索這塊地基，才是每個品牌獨一無二的東西：你十年累積的會員資料、你的商品結構、你的客服問答紀錄，這些是別人複製不走的。一個 agent 再會推理，如果讀到的資料是錯的、舊的、破碎的，它只會用更快的速度產出更像樣的錯誤答案。
這個判斷我們在 Agentic Commerce 的資料困局那篇談過：AI 代理購物時代，模型是公共財，資料深度才決定成效。想進一步釐清 agent 跟 skill、跟工具的分工，可以看AI Agent 與 Agent Skill 差異這篇。
RAG 是什麼：給模型外接一份它隨時查得到的記憶
RAG 的全名是 Retrieval-Augmented Generation，中文是「檢索增強生成」。
這個概念最早由 Patrick Lewis 等人在 2020 年的論文（發表於 NeurIPS）提出。論文把模型的知識分成兩種：一種是訓練時就燒進模型權重裡的「參數記憶」（parametric memory，模型背起來的東西），另一種是放在模型外面、可以隨時查的「非參數記憶」（non-parametric memory，例如一份外部文件索引）。RAG 做的事，就是讓模型在回答前先去非參數記憶裡撈出相關段落，再根據撈到的內容作答。
AWS 官方文件給的定義更白話：RAG 是一種用外部資料（例如公司內部文件）去補強大型語言模型的技術，讓模型在你的特定情境下，產出準確、可用的答案。
RAG 最關鍵的好處，論文裡寫得很直接：外部知識可以更新，而不需要重新訓練模型。這一點對零售品牌特別重要。商品天天上下架、活動週週換檔、會員狀態每天變，沒有人付得起「每次資料變動就重訓一次模型」的成本。RAG 讓你只要更新外部那份文件索引，agent 下一秒就讀得到新資料。
這裡要跟另一個常被混淆的做法分清楚：微調（fine-tuning，拿你的資料再訓練模型一次）。微調擅長教模型新的語氣、固定格式或特定領域的回答風格，也能內化一部分知識，但它不適合當「可追溯、可更新的事實資料庫」，因為改一次成本高、事實更新不易、而且模型還是可能記錯、也說不出答案出處。所以只要目標是可查證、會一直變動的事實，通常優先用 RAG，把知識留在外面隨查隨用。實務上兩者常常搭配，但對「資料一直在長大」的零售場景，RAG 是主力。
RAG 該怎麼建：一條流水線與四個實戰心法
把 RAG 拆開來看，它分成兩個階段。第一個是「新增索引/進資料庫階段」，文件第一次進來、或之後有新增與更新時才跑；第二個是「查詢階段」，使用者每問一次就跑一次。
新增索引階段做三件事：
- 切塊（chunking）：把文件切成一段一段適合檢索的片段
- 向量化（embedding）：用一個向量化模型，把每段文字轉成一串能代表語意的數字
- 建索引存進向量資料庫（vector database）：這些數字存起來，未來可以快速比對相似度
查詢階段則是：把使用者的問題也轉成數字，算它跟哪些片段最接近（常用餘弦相似度，cosine similarity，一種衡量兩串數字方向有多接近的算法），撈出最相關的幾段，必要時再重新排序，最後連同問題一起餵給模型作答。這也是為什麼「知識庫一直長大」不可怕：有新文件時只要重跑新增索引＋進資料庫階段把它補進索引，查詢階段下一秒就讀得到。
流程聽起來乾淨，真正動手會發現魔鬼都在細節。以下是我們團隊建內部知識庫時，用實際評測換來的四個心法（內含數字為 91APP 團隊 2026 年內部評測、資料未公開、未經第三方驗證，只證明在我們這份語料上成立，不是普世保證）。
訣竅1：乾淨的 Markdown 好做，PDF 和網頁才是真正的工程
如果你的文件本來就是乾淨的 Markdown（一種純文字標記格式，標題、段落結構清楚），機器就能精準地把每個段落切成一個獨立的知識點（這就是切塊），再轉成它好理解的數字座標（這就是向量化）。但簡報、PDF、爬下來的網頁不一樣：它們的段落會斷在奇怪的地方、表格會被打散、頁首頁尾會混進內文，機器不知道哪裡該切，一旦切錯，後面向量化、檢索全都跟著錯。我們的經驗是，整條流水線裡最花工的不是接模型，是把這些髒資料切成乾淨片段。預估工時時，這一段千萬別低估。
訣竅2：先建一把可信的「尺」，再談優化
要知道檢索準不準，得先有一套評測題。我們的做法是準備一份題庫，每題標好「正確答案應該出現在哪幾份文件」，然後量檢索的命中率。常用的衡量方式有兩個：一個是第 1 名命中率（看排第一的那段對不對），另一個是前 K 名召回率（如果一題的正解散在多份文件，要看前 K 段把該抓的相關片段抓回了多少比例；若一題只有單一正解，它就退化成「正解有沒有落在前 K 段」）。
這裡有個血淋淋的教訓：題庫太小會騙人。十題的結果幾乎沒有參考價值，我們建議至少五十到七十題才開始可信。更深的一課是，連這把尺本身都要先驗。我們曾經量到第 1 名命中率約 83%，逐題人工檢查才發現，有好幾題其實答對了，只是當初標答案時把「正解出現在哪份文件」標得太窄，跨多份文件的事實被誤判成沒答中。把標註修成允許多個來源之後，真實命中率校準到約九成。教訓很清楚：在一把歪的尺上做優化，會優化出假的進步。
訣竅3：混合檢索通常贏純語意檢索
只用向量化做語意比對，叫密集檢索（dense retrieval），它擅長理解意思相近但用字不同的問題。但它有個弱點：碰到專有名詞、產品型號、精確關鍵字時，反而不如老派的關鍵字檢索（稀疏檢索，sparse retrieval，例如 BM25 這個經典算法，原理是看關鍵字在文件裡出現的頻率與稀有度來打分，字越對得上、分數越高）。
實務上把兩者合起來用，效果最穩，這叫混合檢索（hybrid retrieval）。合併兩邊排名時，常用一個叫倒數排名融合（RRF，Reciprocal Rank Fusion）的簡單算法，概念是讓「在任一種檢索裡排得越前面」的片段拿到越高的綜合分數，再重新排序。在我們的語料上，純語意檢索的第 1 名命中率約 67%，換成混合檢索後拉到約 75%，這是單一招數裡 CP 值最高的一步。要提醒的是，哪一種檢索贏，會因語料而異，所以一定要用自己的題庫量過才算數，別直接套別人的結論。
訣竅4：別迷信加工具，先診斷再對症下藥
混合檢索之後，下一個常見招數是上重新排序模型（reranker，把撈回來的候選片段再精算一次相關度、重新排序的模型）。在我們語料上，加了 reranker 後命中率從約 75% 推到約 83%，看起來很划算。
但接下來的故事才是重點。我們後來想再升級 reranker，換一個更大更新的版本，在原本那把尺上看起來多對了兩題。等到我們把尺修準（修掉前面說的多來源誤判）之後重測，新舊版本同分，所謂的進步是測量假象。那個更大的模型還多吃了 2.3GB、跑得更慢，最後我們決定不換。
這帶出一個比任何工具都重要的紀律：先診斷，再動手。檢索不準有兩種病，一種是該撈的片段根本沒被撈回來（召回問題，要去修切塊或檢索方式），一種是撈回來了但排序排太後面（排序問題，才輪到 reranker）。先量出是哪種病，再決定動哪裡，不要憑感覺一直疊工具。我們在 選 CDP AI Agent 前要問的四個問題裡也提過類似的判斷：能不能說清楚資料從哪來、答案怎麼驗，比 demo 炫不炫重要得多。
還有一件零售場景一定會遇到的事：增量更新。知識庫會一直長大，所以索引不能每次都整份重建，要能只把新增和變動的文件補進去（增量索引，incremental indexing），並且設好更新節奏。這是把 RAG 從一次性專案，變成可以長期維運的關鍵。
從文件知識到會員數據：RAG 的邏輯也是 CDMP 的邏輯
走到這裡，把鏡頭從技術拉回行銷，會發現一件事：RAG 之於文件知識，跟 CDMP 之於會員數據，是同一套道理。
RAG 能不能讓 agent 答得準，取決於它檢索得到的文件夠不夠乾淨、結構化、更新得夠不夠即時。一個行銷用的 AI agent 能不能幫品牌做對決定，同樣取決於它讀得到的會員資料夠不夠完整：跨通路的消費有沒有歸戶到同一個會員、商品有沒有結構化的標籤、購買意圖的訊號是不是即時的。如果這份會員資料是破碎的，agent 給出的分群、推薦和行動也會跟著破碎。
這正是把資料底座準備好的價值所在。CDMP（Customer Data Management Platform，顧客數據管理平台）做的事，就是把散在官網、App、門市 POS、LINE 的會員行為，歸戶成單一身份、加上行為脈絡的標籤、整理成 agent 隨時讀得到的結構。RAG 解決的是「讓 agent 讀得到對的文件」，CDMP 解決的是「讓行銷 agent 讀得到對的會員資料」。要補一句技術上的分工：文件型知識（手冊、SOP、商品說明）適合走 RAG 這種語意檢索；而會員資料這類結構化資料，更多時候靠的是精確查詢、權限控管與資料治理，不是直接丟進向量檢索。但兩者要回答的是同一個問題：你的 AI，到底站在什麼樣的資料地基上。
關於這一點，AI Agent 行銷為什麼需要數據底座那篇有更完整的展開，可以接著看。
想讓 AI Agent 在你的品牌真的有用，先把這幾塊地基打穩
回到品牌可以立刻動手的事。要讓 agent 在自家環境裡真的可用，順序比工具更重要：
- 盤點知識資產：先把分散的簡報、SOP、商品說明、客服問答集中起來，標清楚哪些是乾淨文字、哪些是 PDF 圖檔（預期效果：知道工程量落在哪；建議起步：第一個月先盤點再決定要不要建 RAG）。
- 先建一把小而準的尺：準備五十到七十題真實會被問到的問題，標好正確來源，量檢索命中率（預期效果：優化有依據、不憑感覺；建議起步：建庫的同時就建題庫，別等做完才補）。
- 從混合檢索開始，別一上來就堆工具：先把語意檢索和關鍵字檢索合起來用，量出是召回問題還是排序問題，再決定要不要加 reranker（預期效果：把錢花在刀口上；建議起步：先跑混合檢索的基準數字）。
- 設好增量更新節奏：知識庫會長大，一開始就規劃怎麼只補新文件、多久更新一次（預期效果：RAG 能長期維運不腐化；建議起步：先定每週或每兩週的更新節拍）。
- 把第一方會員數據結構化：行銷 agent 的知識底座是會員資料，先做跨通路歸戶與標籤化，再談自動化（預期效果：agent 的分群與推薦才接得上真實顧客；建議起步：從 CDMP 的會員歸戶盤點開始）。
如果你還在評估該選哪個 AI agent 方案，AI Agent 平台怎麼比、怎麼挑這篇可以當對照。
結語
AI 這一輪真正的分水嶺，不在誰用的模型比較大，而在誰的 agent 讀得到別人讀不到的東西。模型是租來的能力，知識檢索的地基才是你自己的資產。
對台灣品牌來說，這其實是個公平的起點。基礎模型大家站在同一條線上，但你十年累積的會員資料、你的商品知識、你的客服經驗，是別人複製不走的。現在開始把這塊地基打穩，把蹲馬步的功夫練扎實，等 agent 真正能跑起來的那天，跑得最穩的會是資料準備得最好的那一個。
品牌最常問的 Agentic Workflow 與 RAG 問題
Q1：Agentic Workflow 到底跟一般用 AI 差在哪？ 一般用 AI 是問一句、答一句。Agentic Workflow 是讓 AI 自己跑一個循環：規劃步驟、去查資料、執行動作、檢查結果、不滿意就重做。差別在於它會自我修正，而且在循環裡會反覆需要檢索外部知識，這也是 RAG 重要的原因。
Q2：RAG 跟微調（fine-tuning）該怎麼選？ 微調是把知識再訓練進模型，適合教模型新的語氣或固定格式，但改一次成本高，不適合天天在變的事實。RAG 是把知識留在模型外面、隨查隨用，更新資料不用重訓模型，適合商品、活動、會員這類時效型資料。零售場景以 RAG 為主，必要時兩者搭配。
Q3：我們是小品牌、沒有工程團隊，也能做 RAG 嗎？ 可以，關鍵是從對的起點開始。如果文件本來就是乾淨的純文字，門檻不高；如果大多是 PDF、掃描檔、簡報，要先處理資料清理這段，這通常才是真正花工的地方。建議從一個範圍小、問題明確的場景先試，例如客服常見問答，先把一把小評測尺建起來，再決定要不要擴大。
Q4：建一套 RAG 多久看得到效果？ 如果資料乾淨，做出一個能回答特定範圍問題的版本，通常以週計算。但「準到能上線」需要反覆量測與調整，這部分取決於題庫品質和資料乾淨度，不是一次到位的事。先求一個可信的基準命中率，再逐步往上推。
Q5：我們的文件大多是 PDF 和簡報，會很難做嗎？ 會比純文字費工，但不是做不到。關鍵在切塊這一步要把 PDF、簡報的版面正確還原成乾淨片段，避免表格被打散、頁首頁尾混進內文。這段工程量請務必先評估，它往往決定整套 RAG 的品質上限。
Q6：RAG 跟知識圖譜（knowledge graph）有什麼不同？ 兩者都是給 AI 外掛知識，但組織方式不同。RAG 是把文件切塊後用語意相似度去撈相關片段，擅長處理大量非結構化文件；知識圖譜則是把實體與實體之間的關係明確連起來（例如「某商品屬於某品類、某品類常與某活動搭配」），擅長回答需要多步推理、關係明確的問題。實務上有人把兩者結合（業界稱 GraphRAG），先用圖譜釐清關係、再用檢索補上細節。要從哪個先做，取決於你的問題比較吃「找到對的段落」還是「理清楚關係」。