過去嘅 RAG（Retrieval Augmented Generation，檢索增強生成）流程好簡單：將問題做 embedding，去一個索引度搜近鄰，再畀模型唞答案。一次搜尋、一次生成。
AWS 開發者博客（2026-10-26）指出，呢個設計喺一大類問題上面係啱嘅，但會喺三個情況下失效：如果答案橫跨多個資料集，單一次檢索只攞到半個答案，而「通順但缺失」嘅答案往往比冇答案更危險；如果唔同問題需要查唔同來源，單個索引冇機制去揀；如果首次結果唔夠，冇地方可以「回頭再睇一次」。
呢篇文章講點樣用 CDK（AWS Cloud Development Kit）搭建一個「agentic retrieval」系統，令代理喺組成答案之前自己決定：要唔要檢索、去邊個知識庫查、查完第一次後要唔要再查。
三個關鍵組件
Managed Knowledge Base（Type: MANAGED）由 Amazon Bedrock 自己管理 ingestion、storage、indexing、retrieval，唔再需要自己建 OpenSearch Serverless 集合同索引，亦唔使為 OCU（OpenSearch Compute Unit）買單。
圖片：dronepicr／CC BY 2.0／Wikimedia Commons
Amazon Bedrock AgentCore 提供代理部分：Gateway 將每個知識庫以 MCP（Model Context Protocol）tool 形式暴露，Runtime 托管推理代理，AgenticRetrieveStream 喺內部做 reranking 後返還綜合帶引用嘅答案。呢個功能目前只適用於 Managed Knowledge Base。
可觀測性唔再係「有就最好」
文中指出，單次 pipeline 係個函數，讀得明。但代理喺迴圈入面推理同檢索，每個問題行唔同嘅路徑；預設情況下你睇唔到代理行咗邊條路，亦唔知答案啱唔啱。可觀測性因此由「有就最好」變成「唯一確認系統正常嘅方法」。方案隨附兩個 CloudWatch dashboard，覆蓋七層遙測，加上兩種評估：按需評估同持續評估，出自同一個 deployment。
阿調搞兩下：RAG 呢年最常見嘅坑就係「一個索引攞晒晒」，但公司嘅制度文件、技術文檔、客户資料往往分散喺唔同系統。代理可以揀邊個查，聽落好順理成章，但「代理決定」呢個詞背後，冇人話你邊個有權查、查完點審計。呢篇文章講嘅係技術層面，權限同合規層面係另一篇故事。
阿調｜深度調教
