跳至主要內容
ESC
Study Jam:AI Agent 與 MLOps — 第 7/9 篇

Data Store Agent:FAQ 準不準,先看資料

Data Store Agent:FAQ 準不準,先看資料

課程概述

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

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

Data Store Tool 有依據問答流程:網站、PDF、FAQ 與雲端資料經匯入、解析、切片與 ACL 索引;問題重寫後做關鍵字及語意搜尋、排序與權限時效過濾,高信心才生成附來源回答,低信心則澄清或轉接

一個可信的 FAQ 回答,要能一路追到來源、版本與權限。檢索結果太弱時就澄清或轉人工,不要為了「每題都有答案」把缺少的內容補成看似合理的句子。

你將學到

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

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

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

目前常見資料來源包括:

資料來源常見內容要先確認的事
網站 URL官網、Help Center、公開政策網域驗證、可爬範圍、排除頁面與更新延遲
Cloud StoragePDF、HTML、DOCX、JSONL文件品質、Parser、Metadata 與 ACL 欄位
BigQueryFAQ、產品目錄、結構化知識Schema、欄位用途;原本 BigQuery 權限不會自動跟著匯入
Google Cloud 資料庫AlloyDB、Bigtable、Firestore、Cloud SQL、Spanner支援方式、同步週期、資料範圍與服務帳號權限
第三方來源Drive、Confluence 等連接器IdP、群組同步、來源端 ACL 與連接器限制

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

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

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

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

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

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

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

Data Store 文件切片品質對照:機械切割把退貨政策、30 天條件與特價品例外拆散,查詢只命中部分規則而缺少脈絡;依標題與語意切成自足片段並保留適度重疊,可完整回答且附引用

一個 Chunk 最好能帶著標題和必要條件獨立回答問題。若「可以退貨」與「特價品除外」被切開,檢索只命中前半段時,就會產生一個有引用但仍然錯誤的答案。

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

ACL 要在建 Data Store 時決定

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

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

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

Data Store 內容與 ACL 更新生命週期:新增、更新、權限變更與刪除事件經同步,分別建立片段、切換版本、更新 ACL 或移除索引引用;查詢時再依使用者身分與目前時間過濾,只檢索有效版本

知識庫不是一次性匯入。新增、改版、權限變更和刪除都要能追蹤;監控最後成功同步時間、失敗文件與刪除延遲,才不會讓舊政策一直被找到。

FAQ 格式確實有優勢,但不是逐字回覆

成對的 Question/Answer 資料通常比把整份手冊丟進去更容易命中,因為每筆資料本身就有完整問法和答案。不過 Data Store Tool 仍可能改寫回答,並不保證逐字回傳 FAQ 原文。涉及法規、價格或承諾時,最好把精確文字交給確定性回覆或要求使用者查看原文。

上線關卡從資料治理開始,不是從模型選擇開始。能回答、引對來源、使用正確版本,而且沒有跨過使用者權限,四件事要一起通過。

實作重點

  • 不要寫死「索引一定 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 連結Virtual FAQ with data store agents — Google Cloud Skills Boost

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

延伸學習

Study Jam:AI Agent 與 MLOps — 7/9 完成 查看系列全覽 →

留言討論

徽章解鎖!