12 分鐘發表後的 8 分鐘答詢，是評審確認團隊是否真的理解、實作並有所學習的關鍵時段。本文整理 RAG 專題必備的答詢思路與練習題。
RAG 專題最後 8 分鐘：讓評審相信你真的懂、真的做過、真的有學到
12 分鐘的正式發表結束後，接下來的 8 分鐘答詢，是評審確認你們是否真的理解、真的做過、也真的學到東西的關鍵時段。
前面的簡報，是團隊主動決定要說什麼；到了答詢，問題由評審決定。這時候，評審通常不會只問系統有哪些功能，而會進一步確認：你們為什麼這樣設計？資料怎麼處理？怎麼知道答案是對的？哪些決策是團隊自己做的？這一年到底學到了什麼？
因此，答詢的準備重點，不是猜中評審會問哪一題，而是先把專題最核心的問題、技術邏輯、資料處理與驗證方式想清楚。
一、評審不是來抓 Bug，而是確認學習成果
很多同學會把答詢想成一場「防守戰」，覺得評審就是要來挑錯、找漏洞、抓 Bug。其實更重要的是，評審想確認這個專題是不是你們真的做過、想過，也理解自己做了什麼。
尤其現在生成式 AI、Vibe Coding 與各種低程式門檻工具愈來愈普及，一套系統能不能做出來，已經愈來愈難直接代表學生的能力。
評審很可能追問：為什麼這樣設計？技術如何選擇？資料為什麼放進知識庫？怎麼知道回答是對的？哪些事情由 AI 協助？哪些判斷由團隊完成？如果再做一次，會改什麼？
真正要讓評審看見的是：這一年來，你們完成了一套系統，也經歷了分析、選擇、實作、修正與驗證的完整過程。
二、回到 RAG 所要解決問題的核心
答詢前，不要急著猜評審會問哪一題。先回到專題最核心的問題：為什麼這個情境需要 RAG？
RAG 專題真正要處理的，通常不是「做一個可以聊天的系統」，而是當使用者面對大量、分散或專業的資訊時，如何更快找到相關資料，讓生成式 AI 的回答有所依據，也能進一步追溯來源。
團隊要先想清楚：使用者原本遇到什麼資訊問題？為什麼一般搜尋無法很好解決？為什麼直接詢問生成式 AI 還不夠？建立專業知識庫後改善了什麼？RAG 扮演什麼角色？如果拿掉 RAG，系統還剩下什麼？如何證明導入後的回答更可信、更有依據？
當這些問題想清楚後，即使評審換不同方式提問，也比較不容易被問倒。因為你們回答的是專題本身的核心邏輯，而不是背一組標準答案。
三、一定要準備回答：為什麼是 RAG？
這幾乎是必問題。評審可能會問：「為什麼不能直接用 ChatGPT？」「為什麼不用一般搜尋？」「和一般聊天機器人的差異在哪裡？」「為什麼一定要建知識庫？」
不能只回答「因為 RAG 比較準」。這樣的回答太薄弱。
你們需要說清楚：使用者面對的是哪一類專業資訊問題、一般搜尋的不足、一般生成式 AI 的風險、RAG 如何讓模型先檢索指定資料，以及為什麼來源可追溯對這個使用情境很重要。
要證明的是：RAG 是為了解決這個問題而選的，而不是因為目前很熱門所以拿來做。
四、必問題：你怎麼知道 AI 回答是對的？
系統會回答，只能證明系統能夠運作。評審接下來很可能問：你怎麼知道它答對？
團隊要事先想清楚：正確答案的依據、誰負責判斷、測試題目如何產生、包含哪些類型、如何確認引用來源真的支持答案、知識庫沒有答案時如何處理、正確率或來源支持率如何計算，以及是否與一般生成式 AI 或其他查詢方式比較。
如果只回答「我們測試過，大部分都蠻準的」，評審很可能馬上再問：「多準？怎麼算？」
只要在簡報或答詢中使用「準確、有效、方便、比較好」等說法，都要準備相對應的證據。尤其必須能回答：你怎麼證明或驗證 RAG 知識庫提供的回答是準確的？
這題不能只靠主觀感覺，要回到測試設計、標準答案、資料來源與驗證指標。
五、完整說清楚：資料進到 RAG 後發生了什麼
評審可能不只問用了哪一個模型，也可能一路追問資料處理流程：原始資料從哪裡來？有沒有清理？文件怎麼切分？為什麼這樣切？Embedding 怎麼做？資料存在哪裡？提問後如何檢索？取回幾筆內容？相關度不足怎麼辦？模型根據什麼產生回答？
學生至少要能完整說出一條流程：原始資料 → 清理與整理 → 文件切分 → 向量化 → 儲存進知識庫 → 使用者提問 → 問題向量化 → 相似度檢索 → 取回相關內容 → 提供給大型語言模型 → 生成回答 → 顯示來源。
答詢時最忌諱只說：「我們把資料放進知識庫，RAG 就會去找答案。」這會讓評審懷疑團隊只是把工具串起來，卻沒有理解中間的處理過程。
如果能進一步說明 Chunk size、Top-k、資料分類、不同來源的處理方式，以及這些設定如何影響檢索與回答品質，會更有說服力。
六、資料來源本身就是專題成果
RAG 的回答品質，很大程度取決於知識庫。評審很可能會問：為什麼選這些資料？哪些最可信？官方與社群資料如何區分？資料衝突怎麼辦？舊版本如何處理？誰負責更新？資料量有多少？足以支撐使用情境嗎？
團隊要能清楚說明資料來源怎麼找、哪些納入或排除、如何分類、哪些作為主要依據、哪些只能補充，以及版本與更新如何處理。
建立知識庫不是把 PDF 丟進去就完成了。資料的選擇、可信度、分類、版本與更新，本身就是資訊管理專題非常重要的一部分。
七、不要只給答案，要呈現思考過程
有些問題不一定有唯一正確答案，例如：為什麼選這個模型或向量資料庫？為什麼設定這個 Chunk size？資料量增加十倍怎麼辦？未來如何維護？隱私問題如何處理？
這時不需要裝成什麼都知道。比較好的回答方式是：我們當時怎麼考慮 → 為什麼這樣選 → 實作後發現什麼 → 如果再做一次會怎麼改善。
答詢可以記住一個簡單結構：結論 → 理由 → 證據或經驗 → 限制或下一步。
例如評審問「為什麼選這個模型？」可以先回答：「我們主要考量回答品質、使用成本與 API 整合便利性。」接著再補充測試或比較結果。原則很簡單：先回答，再解釋。
八、團隊分工不能只停在前端、後端
評審也很可能問：你負責什麼？哪一部分是你做的？這一年學到了什麼？程式是自己寫的嗎？AI 幫了多少？團隊怎麼分工？
如果回答只有「A 做前端、B 做後端、C 做簡報」，會顯得太薄弱。應進一步說明誰做需求分析、找資料來源、處理知識庫、負責 RAG 測試、規劃 UI／UX、進行驗證、負責技術選擇，以及哪些問題由團隊共同解決。
評審要確認每個人是否實際參與，也是否真的有所學習。換句話說，就是要把自己的「功勞」和「苦勞」說清楚。
九、8 分鐘很短，回答一定要先講結論
答詢最常見的問題之一，是學生講了很久，評審仍不知道答案是什麼。
例如評審問「你們怎麼知道回答是對的？」不要從「我們一開始先去找很多資料」講起。建議直接回答：「我們主要用標準答案與來源支持度來驗證。」再補充測試題分成哪些類型、如何逐題比較系統回答與原始資料。
先回答，再補充，評審才能快速抓到答案，也比較容易繼續追問重點。
十、團隊要先安排誰主答什麼
8 分鐘答詢不是搶答比賽，也不適合一個人包辦全部問題。事前可先分工：題目與使用者需求由 A 主答、RAG 架構與技術由 B、資料與知識庫由 C、UI／UX 由 D、測試與驗證由 E。
實際答詢可採「主責回答，其他人補充」，但每個人仍要理解整體專題。
如果評審點名某位成員，不應直接回答「這不是我負責的」。比較好的方式是：「這部分主要由另一位同學負責，不過整體作法是……，技術細節再請他補充。」這樣會成熟很多。
十一、聽不懂問題時，不要急著亂答
如果沒有聽懂，可以直接確認：「老師不好意思，我確認一下，您的問題是想問……嗎？」這完全沒有問題。
如果真的不知道，也不要硬掰。可以說：「這部分目前我們還沒有實際測試，所以現在不能很確定地下結論。不過如果後續要驗證，我們會從……進行。」
這比答非所問或現場猜答案好很多。做 AI 專題時，系統要避免幻覺；到了答詢，學生自己也不要產生幻覺。
十二、答詢真正要證明的三件事
我真的懂：我知道系統為什麼這樣設計，也理解 RAG 在做什麼。
我真的做過：我能說明資料、架構、測試、修正與實際處理過程。
我真的有學到：我知道自己做過哪些判斷、遇到哪些問題，也知道下一步可以怎麼改善。
12 分鐘簡報，是把專題成果說清楚。8 分鐘答詢，則是讓評審相信：這些成果、功勞與苦勞，真的都是你們一步一步做出來的。
附錄｜評審可能會問的 10 個問題
1. 為什麼選擇這個題目？你們怎麼證明這個問題真的存在？
2. 為什麼一定要使用 RAG？直接使用 ChatGPT 或一般搜尋不行嗎？
3. 請完整說明一筆資料從原始文件進入知識庫，到最後產生回答，中間經過哪些步驟？
4. 你們的資料來源有哪些？為什麼認為這些資料可信？
5. 官方資料、專業文章與社群內容如果出現不同說法，你們怎麼處理？
6. 你怎麼證明或驗證 RAG 知識庫提供的回答是準確的？
7. 你們怎麼確認最後的回答真的根據知識庫檢索到的內容，而不是大型語言模型自己推論出來的？
8. 當知識庫沒有答案，或檢索不到足夠相關內容時，系統會怎麼處理？
9. 團隊每個人實際負責什麼？有哪些重要判斷或技術決策是你們自己完成的？
10. 如果再給你們三個月，你們最想改善哪一件事？為什麼？
這 10 題不需要背標準答案。真正的準備方式，是每一題都能清楚說出自己的：論點、理由、做法與證據。