看了兩場關於 Agentic Search 的演講，分別來自 AWS OpenSearch 的 John Handler 和 AI-Powered Search 這本書的作者 Doug Turnbull (這有很多檢索知識文章，超讚)，兩位都在探討: AI Agent 是否正在取代幾十年累積的搜尋智慧?
第一場: John Handler – Agentic Search 技術
John 從搜尋的三個時代演進切入:
1. Lexical Search (詞彙搜尋) 用 BM25/TF-IDF 做關鍵字匹配，快速但難以理解語意。搜尋 “large screen televisions” 可能找不到描述中沒有 “large” 這個詞的大螢幕電視。
2. Semantic Search (語意搜尋) 用 embedding 向量捕捉語意，能理解 “shoes for the beach” 這種抽象需求，即使商品描述沒提到 “beach”。OpenSearch 的 Neural Plugin 可以在 ingest pipeline 自動調用 Bedrock 生成 embedding，查詢時也能自動轉換。
3. Agentic Search (代理搜尋) Agent 可以規劃、執行多個工具、推理結果，直到找到滿意的答案。
🔹 傳統搜尋的流程
John 強調，即使在 LLM 之前，搜尋工程就已經是一個複雜的生態系統:
- Data Preparation: 清洗、enrichment、entity recognition
- Query Rewrite: 加入用戶偏好、品牌傾向、同義詞擴展
- Re-ranking: 用歷史點擊/購買行為重新排序
- Feedback Loop: 捕捉用戶行為回饋到模型
這些「幾十年的智慧」不會消失，而是變成 Agent 可以調用的工具。
🔹 OpenSearch Agent 實作細節
John 用 OpenSearch 內建的 Conversational Agent 框架做了演示，幾個實作重點:
Tool 設計: 他為 Agent 準備了多個工具，semantic search、lexical search、Q&A search (搜尋用戶對產品的問答)、category lookup 等。每個 tool 都有明確的描述告訴 LLM 什麼時候該用。
System Prompt 設計: 關鍵是給 LLM 決策指引，例如「如果是廣泛的產品搜尋，用 category + lexical + semantic 工具；如果是關於產品特性的問題，用 Q&A search 去找用戶問過的問題」
對話脈絡: 搜尋 “everyday pants” 後，接著說 “I’m a man”，Agent 能理解這是對話中的補充條件，自動過濾出男性款式。傳統搜尋根本做不到。
🔹 用戶行為數據還是重要的
John 強調傳統的用戶行為分析在 Agentic Search 中依然重要，但用法不同:
- 在 Tool 層面: 傳統的 click model、user behavior 還是可以用來提升底層搜尋工具的品質
- 在 Prompt 層面: 可以把用戶偏好 (如「這個用戶喜歡 Nike」) 加到 Agent 的 context 中，讓推理更個人化
第二場: Doug Turnbull – Agentic Search 典範轉移
maven.com/p/e029a8/what-is-agentic-search-and-why-should-i-care
Doug 從「資訊需求」的角度切入，把搜尋場景分成兩端:
左端 – System 1 (直覺、被動) 瀏覽、打發時間、即時滿足。用戶可能自己都不清楚要什麼，更像 recommendation feed。
右端 – System 2 (理性、主動) 有明確目標、可以寫成一整段需求描述。法律案例檢索、求職、醫療文獻搜尋這類場景。
Doug 的核心論點: 對於 System 2 這端的搜尋，Agentic Search 就是典範轉移。
🔹 傳統搜尋的根本問題
「傳統搜尋像是把一整段需求壓縮成三個關鍵字塞進管道，然後祈禱另一端能解壓縮出正確結果。」
搜尋引擎只看到 “java developer downtown” 這幾個字，完全不知道用戶的完整需求是「我想找一份 Java 開發工作，要能走路到 Charlottesville 市中心，薪資範圍…」
然後我們用各種 query understanding、re-ranking 來補救這個資訊損失。
🔹 Agent 的三個關鍵能力
1. Reasoning (推理) Agent 會 “think step by step”，規劃解決問題的步驟。現代 reasoning model 已經把這個能力放進模型訓練裡，不需要特別 prompt。
2. Tool Usage (工具使用) Agent 可以調用搜尋工具、評估結果、決定下一步。訓練資料中已經有大量 web search 的使用範例，所以 LLM 對 tool calling 有不錯的理解。
3. Reflection (反思) Agent 可以看結果不好，調整 query 再試。Doug 舉了 ReAct 論文的例子: 搜尋 “Apple Remote”，發現結果不好，Agent 自己加上 “Front Row software” 來 refine query。
🔹 Tool Calling 實作眉角
Doug 分享了用 OpenAI API 來做 tool calling 的方式，關鍵是 schema 設計要好，讓 LLM 知道每個參數的意義。
🔹 如何加入 User Satisfaction 信號？
這是很重要的一點: Agent 自己判斷的 “relevance” 可能跟真實用戶滿意度不一致。
解法是把 satisfaction model (例如 Learning to Rank 模型) 包裝成另一個 tool，讓 Agent 可以查詢「這個結果用戶會滿意嗎？」就像 coding agent 需要跑 unit test 一樣，search agent 也需要 “relevance test”。
Prompt 技巧: Doug 提到一個有趣的發現，如果你用「這個結果是否 relevant」來描述，效果普通。但如果改成「這個結果會讓用戶 happy 還是 unhappy」，LLM 會更努力去優化，因為 LLM 天生就是 sycophant (討好者)，它們很想讓用戶開心 😂
🔹 能否把 Agentic 學習應用到傳統搜尋？
Doug 提出一個很有趣的想法: 用 Agent 離線跑 query，學習最佳策略，然後部署到即時系統:
- 直接 Cache: 把 query → tool usage 結果直接存起來，完全相同的 query 直接復用
- Semantic Cache: 存到向量資料庫，語意相似的 query (例如 “red shoes” vs “shoes that are red”) 也能命中 cache
- 訓練 ML 模型: 用 Agent 跑出來的 query → category/expansion mapping 當訓練資料，訓練一個輕量分類器部署到線上
- Code Generation: 最進階的玩法，讓 Agent 生成 re-ranking code，迭代改進直到 NDCG 提升。Doug 實驗顯示這招有效，NDCG 介於純 BM25 baseline 和 online agentic search 之間
🔹 現實挑戰
- 延遲: Agent 多輪推理目前還做不到毫秒級
- 成本: LLM 呼叫費用是大問題，frontier model 效果好但貴
- 開源模型: Tool calling 在 Llama 等開源模型上的支援度還在追趕中
總結
兩位講者都認為這是不可避免的典範轉移，尤其對於「用戶知道自己要什麼、需要深度搜尋」的場景。
特別是企業搜尋、專業領域搜尋這類應用，傳統搜尋工程的智慧不會消失，而是角色改變了。從「建造一個 monolithic 搜尋系統處理所有情況」變成「設計一組精準的檢索工具讓 Agent 使用」。