為什麼 Microsoft Foundry 的 RAG 需要更好的索引，不需要…

Microsoft Foundry 的 RAG 成敗關鍵在索引與檢索品質，不在把提示詞越寫越長。

我站在這一邊：在 Microsoft Foundry 裡做 RAG，真正該投資的是索引設計與檢索品質，不是把 prompt 繼續加長。原因很直接，Foundry 的官方架構本身就把 Azure AI Search、hybrid search、agentic retrieval 和 grounding 放在核心位置，這表示系統的可信度先由資料找不找得到決定，再由模型怎麼回答決定。若檢索拿到的是錯的段落，再強的提示詞也只是把錯誤包裝得更像答案。

第一個論點：索引才是 RAG 的控制平面

Foundry 把 index 定義成讓檢索可靠的結構，這不是語義上的修辭，而是工程上的事實。當系統找不到正確片段時，模型會用看似合理的方式補完，結果就是幻覺。Microsoft 之所以同時提供 keyword、semantic、vector 與 hybrid search，就是因為「相關」不是單一標準，索引策略一變，答案是否被正確 grounding 也會跟著變。

更關鍵的是，Foundry 建議把 Azure AI Search 當作 RAG 的 index store。這代表索引不只是存資料，而是把 title、URL、file name 這類 citation metadata 一起帶進流程，讓答案可以被追溯、被審計。換句話說，索引不只是找得到內容，它決定了內容能不能被信任。對生產系統來說，這比 prompt 裡多塞幾句「請謹慎回答」重要得多。

第二個論點：真正有用的是 agentic retrieval，不是單次硬塞上下文

傳統 RAG 常見做法是丟一個 query、抓幾個 chunk、把它們塞進 prompt，然後希望模型自己想清楚。Foundry 的 agentic retrieval 之所以更強，是因為它把檢索變成規劃問題：模型可以把複雜問題拆成子查詢，平行執行，再回傳結構化 grounding 資料。這對多輪對話特別重要，因為使用者的意圖常常不是一次就能問完整。

官方功能列表也說明了這點：context-aware planning、parallel execution、semantic ranking、optional answer synthesis。這些不是包裝詞，而是直接影響延遲、覆蓋率與可追蹤性的機制。平行子查詢可以降低漏檢的機率，結構化輸出可以讓引用與 tracing 更清楚。對工程團隊來說，這比不停調整 prompt 模板更接近可維護的產品架構。

第三個論點：RAG 本質上是資料管線問題，不是文案問題

Microsoft 的實作順序其實已經把答案寫出來了：先準備資料、再切 chunk、再建 index、再接 Foundry、最後才是測試與評估。這個順序很重要，因為 chunking、embedding 品質與搜尋設定一旦出錯，模型根本沒有機會在正確證據上推理。官方也明講，資料準備不佳會直接傷害回覆品質。

所以把心力放在「更長的 prompt」是方向錯置。prompt 無法找回沒被檢索到的段落，也無法修補錯誤的切塊策略。Foundry 的 troubleshooting 其實已經點出常見故障：相關片段不對、明明有 grounding 仍然幻覺、延遲過高、token 膨脹。這些都是 pipeline defect，不是語言修飾問題。要修，得修資料路徑。

反方可能怎麼說

最強的反對意見是：RAG 本來就增加複雜度與成本。檢索會多一次往返與算力，embedding 與索引更新也有代價，檢索回來的內容還會吃掉 token。若需求只是固定風格、穩定行為，fine-tuning 可能更乾淨；若是 agent 系統，retrieval 也許只是眾多工具之一，不該被神化成唯一答案。

這個批評成立，但它打中的不是 index-centered RAG，而是濫用 RAG 的做法。Foundry 的邏輯很清楚：私有資料、快速變動資料、需要來源引用的答案，適合 RAG；要改的是行為模式，fine-tuning 更合適；retrieval 只是工具時，就別硬把它當整個架構。也就是說，限制要承認，但一旦你要的是 freshness、provenance 和 citations，索引仍然是核心資產。

真正該反駁的不是「RAG 有成本」，而是「既然有成本，就用更長 prompt 補上」。這條路通常只會讓 token 更貴、延遲更高、上下文更亂，卻不會讓證據更準。當檢索本身錯了，prompt 再漂亮也只是把錯誤回答得更完整。

你能做什麼

如果你是工程師，先設計 retrieval layer，再碰 prompt：選對 index 模式，從第一天就保存 citation metadata，把 access control 放在檢索層，並用真實使用者問題測試，不要只拿合成題目驗證。如果你是 PM 或創辦人，請把 indexing、evaluation 與 security 算進產品成本，而不是當作實作細節。對 Foundry 來說，RAG 的競爭力不在 prompt 長度，而在你是否把索引當成基礎設施，把 grounding 當成產品需求。