我一直聽過 RAG 與 ReAct，但懂得模模糊糊

我一直聽過 RAG 與 ReAct，但懂得模模糊糊。
直到準備考試，才真的發狠拷問 AI 們它們到底在幹嘛。

現在回頭看，它們確實能解掉很多原本卡住的地方，
也算是讓我離「大神領域的邊界」靠近了一點。

---

RAG 跟 ReAct 解的其實是兩種不同的缺陷

RAG 對我來說，本質是在處理「記憶不可靠」這件事。

模型記得的東西有限，而且有訓練期限，
所以在回答之前，先去文件或資料來源裡找，再整理成回答。

ReAct 則是在補「不會真的做事」。

它不是一次給你結論，
而是比較像人：先想、再用工具、看結果、再修正下一步。

簡單說：
RAG 處理的是知識來源，
ReAct 處理的是行動流程。

---

為什麼企業場景特別需要這對「雙 R 好夥伴」

過去能靠規則與 SOP，是因為世界變得慢，
我們來得及把 SOP 寫完，還有時間校驗。

現在很多場景，變化快到來不及寫成完整 SOP，
只能先訂原則，再邊跑邊調。

供應鏈、維運、客服，其實都符合這個狀況。

---

供應鏈的關鍵，不在預測，在反應速度

傳統做法通常是這樣：

事情發生 → 人看到 → 人整理 → 人開會 → 才開始調度

如果引入 ReAct，流程會變成：

先感知外部事件 →
對照內部數據推估影響 →
直接產出可行選項

差別在於，把「慢慢反應」變成「及早處理」。

---

RAG 在客服的效果其實最直觀

以前的客服訓練，很容易變成兩件事的組合：
文件搜尋器 + 情緒管理員。

問題一抽象，就只能丟一堆標準答案，
然後再補一句「我能理解你的感受」。

RAG 的差別在於：

先理解問題，
再從文件裡抓出真正相關的段落，
整理成回答，必要時附上來源。

關鍵價值在於：
先用模型做理解，再開始搜尋。

---

個人應用時，我現在會特別注意的幾件事

第一個是對 Context 長度的敏感度。
現在我會直接把「什麼時候該重開對話」當成設計的一部分。

第二個轉換也很實際：
不再把 AI 當對話對象，而是當流程裡的一個元件。

它負責哪一段？
出錯我能不能發現？
需不需要人工確認？

---

概念理解檢查題（我用來確認自己是不是真的懂）

如果要做一個能回答「今天早上最新財經新聞」的聊天機器人，最合理的做法是什麼？

每天重訓模型？
叫模型自己發揮？
還是用 RAG 接即時新聞來源？

答案其實很清楚是用 RAG。
即時資訊本來就不適合拿來做微調。

---

文件對話拉得很長，模型開始忘記前面的條件，卻對最近幾句記得很清楚，這是什麼狀況？

這多半不是模型壞掉，
而是對話太長，注意力被擠掉。

最有效的解法，反而是重開對話。

---

ReAct 一定要重新訓練模型才能用嗎？

這題我一開始也答錯。
後來才確認，多數情況下不一定。

只要提示設計清楚，
就能進入「思考＋行動」的循環。

---

不用再背 Prompt 魔法句了，重點是用的時候怎麼想

這些技巧不是完全沒用，
而是現在的重點已經不在這裡了。

真正影響結果的，反而是這些問題：

我有沒有把任務邊界講清楚？
資料是不是對的？
什麼時候該重來？