今日（10月5日），AWS 喺官方 Machine Learning Blog 發表技術文章，展示點樣喺 Amazon Bedrock Managed Knowledge Base 用 LangChain 建 RAG（檢索增強生成，即先檢索文件、再俾模型基於揾到嘅內容生成答案）應用，重點介紹喺呢個知識庫上可用嘅「代理式檢索」（agentic retrieval）。
文章開場嘅情境係：要支援助手比較兩款產品喺三個維度嘅分別，表面一個問題，實際同時問咗六個。傳統單次檢索會將呢個問題壓縮成一個查詢向量，檢索器根據向量揾到嘅，係「六個意圖嘅最佳平均」——搜尋冇錯誤、相關性分數看似正常，但揾返嚟嘅文件片段，只覆蓋咗問題嘅一啲部分。
由「搜一次」到「做計劃」
AWS 指，代理式檢索現已可用於 Amazon Bedrock Managed Knowledge Base：佢唔係搜一次就完，而係先將問題拆成若干子查詢（sub-queries），逐個執行，判斷證據夠唔夠，唔夠就再搜。每一步會以 trace events 串流返俾開發者，方便審視模型產生嘅計劃。
Managed Knowledge Base 係 Bedrock 嘅全託管 RAG 能力：開發者只須設定資料來源（示範用 Amazon S3），文件分塊、向量化（embedding）、儲存同檢索都由 AWS 處理，唔使自己管向量庫或重排模型。
知識庫提供兩個 API：Retrieve API 執行一次混合檢索（hybrid search），回傳有分數嘅文件片段；AgenticRetrieveStream API 執行多步規劃循環。langchain-aws 包兩者皆有暴露，前者係可放入 LangChain chain 嘅標準 retriever，後者係由知識庫直接做 function retrieval（函數式檢索），開發者喺同一個應用可以二揀一。
實作走查嘅條件：支援 Managed Knowledge Bases 同代理式檢索嘅 AWS Region（示範用 us-east-1，美國東部弗吉尼亞）；兩個 IAM 身份（一個俾知識庫假扮嘅服務角色，一個有權調用 API 嘅身份）；Python 3.12 或以上；以及放咗覆疊主題樣本文檔嘅 S3 bucket。文章話會交代兩條路徑嘅成本，以及「平嗰個幾時係正確選擇」。
如果你哋公司用 RAG 做客服或內部知識庫，呢個功能針對嘅正係一個常見痛點：用户嘅問題往往包含多個意圖，單次檢索將佢哋攤平成一個向量，多步檢索則逐個處理。揀邊條路徑，係檢索覆蓋度同成本之間嘅取捨。
阿調搞兩下
留意文章自己嘅措辭：「when the cheaper one is the right choice」——廠商用「平嗰個」形容其中一條路徑，已承認兩者成本有別；由上下文可見，單次檢索係成本較低嘅一方。做代理式檢索，你為額外嘅搜尋同模型調用買單，值唔值得，取決於你嘅知識庫有幾多「一問頂六問」嘅場景。決策前記得多問：文件放喺邊個 Region、規劃循環用嘅係邊個模型、trace events 可以審視幾多細節。廠商嘅技術文章，同佢哋其他產品一樣，值得你自己核。
阿調｜深度調教
