Data Store Agent：FAQ 準不準，先看資料

課程概述

把公司文件丟進知識庫，再讓客服機器人回答問題，看起來很像「上傳完就收工」。真正上線後才會發現，答案準不準往往不是模型大小決定的，而是來源文件有沒有過期、段落切得好不好、權限有沒有跟著帶進索引，以及找不到答案時肯不肯停下來。

現行產品裡，網站、文件和資料庫內容會放進 Data Store，再由 Dialogflow CX（主控台名稱是 Conversational Agents）的 Data Store Tool 搜尋並整理回答。底層搜尋能力來自 Agent Search（原 Vertex AI Search）。它幫你省下不少 RAG 基礎建設，但不會自動替公司完成資料治理。

你將學到

• 釐清 Agent Search、Data Store 與 Data Store Tool 的分工
• 依網站、非結構化文件和結構化資料選擇匯入方式
• 在建立 Data Store 前決定解析、切片與資料來源 ACL
• 用查詢集檢查命中、引用、拒答和權限隔離
• 讓更新、刪除與權限變更真的反映到搜尋結果

它是一個受管 RAG 流程，不是「自動懂公司文件」

使用者提問後，大致會經過查詢改寫、搜尋、摘要、Grounding 和安全檢查。Data Store Tool 也能輸出執行追蹤與各階段延遲，方便分辨問題出在 FAQ 比對、搜尋、摘要還是安全檢查。

目前常見資料來源包括：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Data Stores 功能目前不在 Dialogflow CX SLA 內。若它是客服正式服務的唯一知識來源，要把失敗時的快取、固定 FAQ 或人工轉接一起設計進去。

引用是證據線索，不是正確保證

Data Store Tool 會提供支援連結，Agent Search 的摘要也能開啟 Citation。引用能回答「這句話從哪裡來」，但不能保證：

• 文件本身是最新或正確版本
• 模型沒有把例外條款漏掉
• 使用者真的有權限看到來源內容
• 引用段落足以佐證整句結論

因此測試時不能只檢查 Citation 欄位有沒有值。要讓人工逐題確認答案主張、引用段落、來源版本和權限都對得上。

Chunk 要能獨立回答，不是愈小愈好

Agent Search 可在建立 Data Store 時啟用文件切片，並搭配 Layout Parser 保留標題、段落、表格和清單結構。這個選擇要早點做：文件切片建立後不能直接開關，既有文件改 Parser 也不會自動重新解析。

對複雜 PDF，Layout Parser 通常比單純 OCR 更適合 RAG，因為它能辨識標題、表格和版面結構。掃描品質差、跨頁表格或資訊藏在圖片裡時，仍要抽樣檢查解析結果，不能只看匯入狀態顯示成功。

ACL 要在建 Data Store 時決定

企業內部文件常有部門、專案或個人權限差異。Agent Search 的資料來源存取控制需要先設定 IdP，並在建立 Data Store 時啟用；不能等資料都進來後，再把既有 Data Store 改成 ACL 模式。

目前官方文件仍將這項資料來源存取控制標示為 Preview。正式採用前要確認服務條款、支援來源和地區，也要準備產品限制改變時的應對方式。

特別容易踩雷的是 BigQuery：把資料匯入 Agent Search，不代表 BigQuery 原本的資料集與資料表權限會一起複製過去。若內容不是公開資料，就要使用支援的 ACL Schema、傳入終端使用者身分，並準備正反兩組帳號測試同一題。

FAQ 格式確實有優勢，逐字回覆要看怎麼匯入

成對的 Question／Answer 資料通常比把整份手冊丟進去更容易命中，因為每筆資料本身就有完整問法和答案。匯入成 FAQ Data Store 時，使用者問題若以高信心比對到某一題，Agent 會原樣回傳那一題的答案；同一份 CSV 若當成非結構化內容匯入，比對條件較寬鬆，Agent 就可能改寫答案而不是逐字回傳。涉及法規、價格或承諾時，最好把精確文字交給確定性回覆或要求使用者查看原文。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 20, "rankSpacing": 28, "wrappingWidth": 600}}}%%
flowchart TB
  subgraph GOVERN_STAGE["1. 先治理來源與權限"]
      direction TB
      SOURCE["盤點網站、文件、FAQ<br/>資料表與負責人"] --> CURRENT{"能確認版本、有效日期<br/>和唯一正本嗎？"}
      CURRENT -->|"不能"| CLEAN["先清除重複與過期內容<br/>補上 Owner 和更新規則"]
      CURRENT -->|"可以"| ACCESS{"不同使用者看到的內容<br/>是否需要不同？"}
      ACCESS -->|"需要"| ACL["先設定 IdP 與 ACL Schema<br/>建立時啟用 Access Control"]
      ACCESS -->|"不需要"| PARSE["依版面選 Parser<br/>保留標題、表格與清單"]
      ACL --> PARSE
  end
  PARSE --> CHUNK
  subgraph INDEX_STAGE["2. 解析、切片與同步"]
      direction TB
      CHUNK["決定 Chunk 與 Metadata<br/>抽查處理後的內容"] --> SYNC["匯入並同步更新、刪除<br/>與權限變更"]
      SYNC --> EVAL["用真實問法測命中、引用<br/>低信心、舊資料與越權"]
  end
  EVAL --> PASS
  subgraph RELEASE_STAGE["3. 驗證後才開放查詢"]
      direction TB
      PASS{"答案、來源、版本<br/>和使用者權限都正確嗎？"} -->|"否"| TUNE["修資料、Parser、Chunk<br/>Filter、Boost 或拒答策略"]
      PASS -->|"是"| LAUNCH["小流量上線<br/>監控無答案率與同步健康度"]
  end

實作重點

• 不要寫死「索引一定 5–30 分鐘完成」；資料量、來源與同步方式不同，應監控實際 Operation 和文件狀態
• 建立 Data Store 前先決定是否啟用文件切片與資料來源 ACL，這兩項都不是事後隨手切換的設定
• 使用 Metadata 表示文件類別、語系、地區、有效日期與版本，再搭配 Filter、Boost／Bury 控制結果
• 使用 Default、Optimized for voice 或 Customize 設定 Grounding、Rewriter 與 Summarization，不要沒有評估資料就亂調門檻
• 測試集要包含同義問法、例外條款、已刪除內容、無答案問題與「有權限／沒權限」帳號
• Conversation History、Cloud Logging 或 BigQuery tracing 可以協助定位搜尋、摘要和安全檢查的延遲與失敗

Lab 導讀

Lab 連結：到 Google Skills 搜尋「Virtual FAQ with data store agents」。截至 2026 年 10 月，目錄中找不到同名課程，可能已改版或下架。

Lab 會從 Cloud Storage 匯入文件，再把 Data Store Tool 接進對話。實作時請另外記下三件事：哪個文件版本被引用、查不到時 Agent 做了什麼，以及使用不同身分查詢時結果是否真的不同。這三題比「看起來有回答」更接近正式環境。

延伸學習

• Gemini Enterprise 入門 — 擴大到企業搜尋、連接器與身分同步
• Generative Playbooks — 把 Data Store Tool 接進可控的對話任務
• Agent Assist 與 GenAI — 將知識問答放進真人客服工作台
• Agent Search 文件切片 — 確認 Parser、Chunk 與既有限制
• 資料來源存取控制 — 設定 IdP、ACL 與終端使用者權限