
傳統 RAG 常見做法是「先搜一批資料,再全部塞進 prompt」。Agentic RAG 的想法比較像:把搜尋本身變成工具。

當 action 需要政策、文件或知識庫時,LLM 可以依推理需要決定要搜尋什麼關鍵字、要不要再查一次。這比固定前置檢索更彈性,也比較不會把不相關內容塞滿 context。
但搜尋仍然要有邊界:資料來源、可查範圍、回傳格式與稽核紀錄都要由工程系統管理。
傳統 RAG 常見流程是先檢索再生成:使用者問問題,系統先查向量庫,把片段塞進 prompt,再請模型回答。這對 FAQ 類型問題有效,但對多步流程不一定夠。
Agentic RAG 的想法是把檢索能力變成工具,讓 LLM 在 action 內根據推理需求決定何時搜、搜什麼、搜幾次。以旅遊政策為例,只有 proposeOffer 或 reviewOffer 需要政策依據時才查,不必每個流程都先塞一堆文件。
但越動態就越需要稽核。你要記錄查了哪些關鍵字、拿到哪些文件、引用到哪個段落、最後如何影響 action output。否則 RAG 只會從『查不到』變成『不知道怎麼查到的』。
要先把來源分清楚:RAG 這個大概念不是 Embabel 專屬;但 SearchOperations、ToolishRag、LlmReference、.withReference(...) 這套 agentic RAG 形狀,是 Embabel 自己的抽象。也就是說,這裡不是在講 Spring AI 的固定 Advisor/pipeline,而是在講 Embabel 如何把搜尋能力變成 LLM 可自主呼叫的工具。
這一段直接聚焦 agentic RAG 的接法與查詢邊界。
RAG 的關鍵在使用時機:搜尋文件本身可以是一種工具,但資料來源、查詢範圍與回傳格式仍要受系統限制。讓 LLM 決定何時搜尋,不代表讓它任意碰所有資料。
class PolicyActions {
private final ToolishRag toolishRag;
PolicyActions(SearchOperations searchOperations) {
this.toolishRag = new ToolishRag("docs", "Embabel 文件", searchOperations);
}
@Action
OfferDraft proposeOffer(ActivitySummary summary, OperationContext context) {
return context.ai().withDefaultLlm()
.withReference(toolishRag)
.createObject("Create an offer draft based on policy: " + summary, OfferDraft.class);
}
}
這段才是 Day 16 真正該看的引用點:
SearchOperations:底層搜尋能力ToolishRag:Embabel 把搜尋能力包成 LlmReference
context.ai().withDefaultLlm().withReference(toolishRag):把這份 RAG 能力交給這次 LLM 呼叫
所以如果只是看到:
McpToolExport.fromLlmReference(toolishRag)
那表示你看到的是「把 RAG 能力發布成 MCP 工具」;但如果你要回答「Embabel 在 action 裡怎麼調用 AI 工具」,真正該看的物件是 Ai / OperationContext.ai(),以及它後面的 .withReference(toolishRag) 或 .withToolObject(...)。
設計一個政策文件 RAG action:列出可搜尋欄位、工具輸入、工具輸出,以及 ActionAudit 要記錄的內容。
如果你也想進一步學習如何透過 AI 開發 Spring Framework 應用,讓 AI 協助理解框架、撰寫程式、除錯與驗>證,歡迎到 Hahow 看凱文大叔的最新課程【駕馭 AI 的全端實戰養成班:從零打造企業級智慧應用系統】。一起>學習如何駕馭 AI,提升 Spring 應用的開發效率與品質。
課程連結