整理自多方資料
如果只有 30 秒，這在說什麼？
你有沒有用 ChatGPT 問過一個很具體的問題，結果它一本正經地胡說八道？這就是 AI「幻覺」問題。RAG（Retrieval-Augmented Generation，檢索增強生成）就是解決這個問題的關鍵技術——讓 AI 先去查資料，再根據查到的內容回答你，而不是憑記憶瞎猜。
而且，你每天在用的 Cursor、GitHub Copilot、Claude Code，背後全都在用 RAG。
核心概念拆解
1. Retrieval（檢索）
一句話解釋： 在 AI 回答之前，先從資料庫裡找出跟問題最相關的文件。
生活中的比喻： 想像你在考開卷考試。老師允許你翻書，但考場有一整座圖書館的書，你不可能全部翻完。所以你需要一個超強的索引系統，幫你在幾秒內找到最相關的那幾頁——這就是 Retrieval 在做的事。
為什麼重要： 沒有好的檢索，AI 就只能靠訓練時學到的「記憶」回答，而這些記憶可能過時、不完整，甚至根本是錯的。
2. Embedding（向量嵌入）
一句話解釋： 把文字轉換成一串數字（向量），讓電腦能夠計算「兩段文字有多像」。
生活中的比喻： 就像把每本書的內容壓縮成一個 GPS 座標。內容越相似的書，座標越靠近。當你問一個問題時，系統把你的問題也變成座標，然後找出附近的書——這就是向量搜尋。
為什麼重要： 傳統關鍵字搜尋只能找到「字面上一樣」的結果。但 Embedding 能理解語意，比如搜尋「如何請假」也能找到標題寫著「休假申請流程」的文件。
3. Augmented Generation（增強生成）
一句話解釋： 把檢索到的資料塞進 AI 的提示詞裡，讓它「看著資料回答」。
生活中的比喻： 你問一個朋友：「我們公司的退款政策是什麼？」如果他憑印象回答，可能講錯。但如果你先把退款政策的文件遞給他，說「看完這個再回答我」，答案就靠譜多了。RAG 就是在做這件事。
為什麼重要： 這是 RAG 最核心的價值——AI 的回答有據可查，不再是黑箱。你甚至可以追溯每個答案來自哪份文件。
4. Vector Database（向量資料庫）
一句話解釋： 專門用來儲存和搜尋向量的資料庫，是 RAG 系統的「記憶中心」。
生活中的比喻： 傳統資料庫像一本按字母排列的電話簿，你必須知道確切的名字才能查到。向量資料庫則像一個會讀心術的圖書館員——你說「我想找跟情緒管理有關的書」，他就能馬上從幾萬本書中挑出最相關的幾本。
為什麼重要： 當企業有幾十萬份文件時，向量資料庫能在毫秒級別完成語意搜尋，這是 RAG 能實際上線的基礎。
前端工程師日常開發中的 RAG 應用
你可能以為 RAG 離你很遠，但其實你每天都在用。
你的 AI 程式助手，就是 RAG
Cursor 的核心賣點之一就是「理解你的整個專案」。當你在 Cursor 裡問「這個 useEffect 為什麼會無限迴圈？」，它不是只看你當前這個檔案，而是會對你整個 codebase 做索引（Embedding），然後檢索出相關的元件、Hook、型別定義，把這些上下文一起餵給 AI。這就是 RAG。
GitHub Copilot 也一樣。當它在 VS Code 裡建議程式碼時，會讀取你當前開啟的檔案、相關的 import、甚至鄰近的檔案作為上下文。新版 Copilot 更進一步支援 @workspace 指令，讓它檢索整個專案來回答問題——這也是 RAG。
Claude Code 在幫你改 bug 或寫新功能時，會先用 Grep、Glob 等工具搜尋你的 codebase，找到相關檔案讀取後再生成程式碼。本質上就是 Retrieval → Augmented Generation。
所以，當你覺得 AI 助手「懂你的專案」的時候，那就是 RAG 在發揮作用。當你覺得它「答非所問」的時候，通常是 RAG 的檢索那一步沒做好。
查文件：從翻官方文件到直接問 AI
以前遇到不熟的 API，你會去翻 MDN、React 官方文件、或某個 UI 元件庫的文件。現在很多文件網站本身就內建了 RAG 搜尋——你輸入一個自然語言問題，它不是做關鍵字比對，而是用向量搜尋找到最相關的文件段落，再用 AI 整理成一個直接的回答。
你也可以自己搭建：把團隊的元件庫文件、設計規範、coding convention 餵進一個 RAG 系統（例如用 LlamaIndex + Notion），新人入職直接問 AI 就能上手，不用再翻遍 Confluence。
Debug：給 AI 足夠的上下文
你有沒有這種經驗？把錯誤訊息丟給 ChatGPT，它給了一個看起來合理但完全不適用於你的專案的答案？
這就是「沒有 RAG」的狀態——AI 只看到你貼的那段錯誤訊息，不知道你用的是什麼框架版本、專案結構長什麼樣、相關的程式碼在哪。
而在 Cursor 或 Claude Code 裡 debug 時，AI 能自己去讀你的 package.json、tsconfig.json、相關的原始碼，基於你的實際專案環境給建議。這就是 RAG 在 debug 場景的價值——讓 AI 拿到正確的上下文，才能給出正確的答案。
學習新技術：AI 幫你讀完文件再教你
想學一個新框架？以前你要花半天讀完 Getting Started。現在你可以把官方文件丟進 RAG 系統，然後直接問：「Next.js 的 Server Component 跟 Client Component 差在哪？什麼時候用哪個？」AI 會從文件中找到相關段落，整理成白話回答。
這不是取代閱讀文件，而是讓你先快速抓到重點，再有目標地深入閱讀。
最容易搞錯的地方
很多人以為 AI 助手很聰明所以什麼都知道，但實際上 它的表現完全取決於「檢索到了什麼」。同一個問題，在 Cursor 裡問和在 ChatGPT 裡問，答案品質可能天差地遠——差別就在 Cursor 有你的 codebase 當作知識庫做 RAG，ChatGPT 沒有。
很多人以為 RAG 可以完全消除 AI 幻覺，但實際上 RAG 只是大幅降低幻覺的機率。如果檢索到的文件本身有錯，或者問題超出資料庫範圍，AI 還是可能瞎掰。所以看到 AI 給的答案，還是要自己判斷。
很多人以為「上下文越多越好」，但實際上 塞太多不相關的檔案給 AI，反而會讓它分心、搞混。這就是為什麼 Cursor 讓你手動 @file 指定檔案有時候反而比讓它自動搜尋更精準——你在手動做更好的 Retrieval。
用自己的話說一遍
RAG 的本質其實很直覺：與其讓 AI 靠「記憶」回答問題，不如讓它每次都先「查資料」再回答。
整個流程就三步：使用者問問題 → 系統從知識庫中找出最相關的文件 → 把這些文件跟問題一起交給 AI，讓它根據真實資料生成回答。
對前端工程師來說，這不是什麼需要另外學的新技術——你每天用的 Cursor、Copilot、Claude Code 已經在幫你做 RAG 了。理解它的原理，你會知道為什麼有時候 AI 超神（檢索到了正確的檔案），有時候超廢（檢索到了不相關的東西或根本沒檢索到）。
更實用的是，當你理解 RAG，你就知道怎麼「餵」AI 才能讓它表現更好：手動指定相關檔案、寫更精確的問題、甚至把團隊文件整理成 AI 容易檢索的格式。這不是在學 AI，這是在學怎麼更聰明地使用工具。
延伸思考
-
你在用 Cursor 或 Copilot 時，有沒有注意過它什麼時候特別準、什麼時候特別離譜？ 回想一下，那些「特別準」的時刻，是不是剛好它檢索到了正確的上下文？
-
如果你把團隊的 coding convention、PR review 常見回饋、元件庫文件全部做成 RAG 知識庫，會怎樣改變新人的 onboarding 體驗？
整理自：AWS - What is RAG?、GitHub - RAG for Software Development、Cursor vs Copilot 比較、RAG Code MCP for Copilot 等多方資料