用 Hook–Problem–Solution–Payoff 架構，說清楚 12 分鐘的專題故事：誰遇到問題、為什麼值得解決、如何運用 RAG、用什麼證據證明系統有效。
用 Hook–Problem–Solution–Payoff 架構，說清楚 12 分鐘的專題故事
今年我指導數組以 RAG 為核心的資訊管理畢業專題團隊，經過一整年的題目發想、需求分析、資料整理、知識庫建置、系統開發與測試驗證，目前已進入成果驗收與正式發表前的最後準備階段。
到了這個階段，學生面對的挑戰，已經從「系統還能做什麼」，轉向「如何把一整年的成果說清楚」。在有限的 12 分鐘裡，需要讓評審理解題目背景、問題與價值、RAG 的應用方式、團隊實際做了哪些工作，以及最後如何驗證系統成果。
因此，我將這段時間與同學討論的簡報準備重點整理成這份指引，並以 Hook–Problem–Solution–Payoff 作為主要架構，協助專題團隊在正式發表前重新檢視簡報主線。
整份簡報建議控制在 11～12 頁，另準備 3～5 頁備用資料。12 分鐘不可能把一年做過的事情全部講完，重點是讓評審沿著一條清楚的脈絡理解：
誰遇到問題？ 問題為什麼值得解決？團隊如何運用 RAG 處理？用什麼證據證明系統有效？
第一部分｜Hook：先讓評審願意繼續聽
Hook 原意是「鉤子」。在簡報裡，它指的是用一個具體情境、問題、故事或數字，先勾住評審的注意力。
這個階段不要急著介紹模型、向量資料庫或系統架構。評審必須先理解「為什麼需要這個專題」，後面的技術才有意義。
第 1 頁｜封面與核心主張
頁面應包含專題名稱、一句話說明專題價值、團隊成員、指導老師、系所，以及能代表使用情境的主視覺。
標題建議不要只寫「運用 RAG 建置智慧問答系統」，可以改成「協助特定使用者快速取得可信、可追溯的專業資訊」。
上台要在 20 秒內說清楚：誰會使用這套系統、他們面對什麼問題、團隊希望帶來什麼改變。
第 2 頁｜真實使用情境與痛點後果
呈現一個具體場景，例如：使用者急著尋找專業資訊、同一問題散落在多個網站與文件、使用者不知道哪一個答案正確、生成式 AI 回答得很完整卻沒有可靠來源，或因找不到正確資料，最後造成時間、權益或決策上的損失。
可用一段使用者對話、一個真實問題、一個錯誤查詢帶來後果的案例、一張簡單因果流程圖，或一組有感的數字。這一頁要回答：誰遇到了問題？在什麼情境下遇到？為什麼現有方式不理想？如果查不到、查錯了，可能造成什麼損失？
第二部分｜Problem：把問題說到具體
Problem 不只是列出幾個痛點，而是要讓評審看見：這個問題真實存在、影響明確，而且現有方法仍有不足。
第 3 頁｜使用者痛點與需求
選出 3 個最核心的問題，例如：資訊分散、資料版本不一、一般生成式 AI 可能產生沒有來源的回答、使用者需花大量時間比對判斷，或專業資訊更新快導致誤判。
避免只寫「搜尋不方便」「資訊很多」「AI 會出錯」。應改成具體敘述，例如：使用者必須在多個資料來源間搜尋、閱讀與比對，才能確認答案是否適用。這一頁要讓評審理解：問題不只是查詢麻煩，也會進一步造成時間成本、判斷風險與溝通負擔。
第 4 頁｜目標使用者、現有方法與專題目標
12 分鐘版本建議把原本「目標使用者與市場需要」、「現有方法為什麼不夠」、「專題目標」三頁濃縮成一頁，分成三小區塊。
目標使用者：說明主要與次要使用者，以及他們在什麼情境下會使用。
現有方式不足：一般搜尋可找到原始資料但需自行判斷；一般生成式 AI 回答快但可能沒有來源；現有專業網站資料可信，但分散且不好查。
專題目標：回應真實的市場與使用需求、應用 AI 與 RAG 技術、打造特定領域的 RAG 專業知識庫。
這一頁的任務是讓評審理解：這群人真的有問題、現有方法沒有完全解決、你們的專題目標是明確且合理的。
第三部分｜Solution：說清楚團隊怎麼做
Solution 是整份簡報的核心，占用時間最多。12 分鐘版本依然要講清楚，但必須更精煉，避免過度展開技術細節。
第 5 頁｜為什麼選擇 RAG
說明 RAG 能從指定知識庫檢索、將結果提供給大型語言模型、根據資料產生回答、顯示或追溯來源，並降低完全依賴模型記憶與自行推論的風險。
上台需回答：為什麼不能直接問 ChatGPT？為什麼一般搜尋不夠？為什麼需要自己建知識庫？RAG 和一般聊天機器人的差異在哪裡？這一頁是「技術選擇理由」，不是技術定義課，不要講太久。
第 6 頁｜RAG 完整運作流程
建議用流程圖呈現：資料蒐集 → 資料清理與分類 → 文件切分 → 向量化與儲存 → 使用者提問 → 檢索相關內容 → 生成回答 → 顯示來源。
評審真正想確認的是：你們真的做了 RAG，還是只串接生成式 AI API？因此要明確說明知識庫如何建立、問題如何轉換與檢索、檢索結果如何送進模型、回答如何連結來源，以及查不到答案時如何處理。這一頁是技術主線之一，要講清楚，但控制在約 1 分鐘。
第 7 頁｜資料來源與知識庫建置
說明資料來源類型、選擇標準、文件數量或資料規模、整理分類與更新方式，以及如何處理重複、衝突或過期資料。可區分官方、法規、專業機構、研究教育、社群與團隊自行整理內容。
必須回答：為什麼這些資料值得放入知識庫？如何確保來源可信？資料更新後，系統如何處理？12 分鐘版本不要逐項念資料來源清單，而要強調：你們如何判斷哪些資料能用、哪些資料只能作為輔助。
第 8 頁｜系統架構、技術選擇與使用者流程
12 分鐘版本建議把原本「系統架構與技術選擇」與「使用者流程與 UI／UX」濃縮成一頁。左側呈現前端、後端、向量資料庫、Embedding、大型語言模型與 API，並簡短說明選擇理由；右側呈現使用者流程：進入系統 → 提出問題 → 查看回答 → 確認來源 → 進一步追問或採取行動。
必須說明來源可見性、查無資料訊息，以及系統如何降低操作與判斷負擔。不要把這一頁做成工具 Logo 展示牆；評審要聽的是選擇理由與使用流程。
第 9 頁｜團隊分工與實際投入
分工不能只寫前端、後端、程式設計。尤其在 Vibe Coding 愈來愈普及的情況下，評審可能會懷疑系統是否主要依靠生成式 AI 快速產生程式。
因此分工應呈現完整的資訊管理工作：需求分析、資料蒐集與可信度評估、知識庫整理、系統流程規劃、UI／UX、Prompt 與檢索測試、錯誤分析、使用者測試，以及成果整理與簡報製作。
評審應該看見：每位成員做了哪些判斷、選擇、測試與修正；使用 AI 輔助開發沒有問題，但哪些決策是團隊自己完成的；團隊到底用了什麼、做了什麼、學到了什麼。這一頁不要講太細，但一定要讓評審知道：這不是只靠 AI 生成程式的專題，而是有完整分析與整合過程的資訊管理專題。
第 10 頁｜Demo：展示一條完整主線
Demo 建議流程：提出真實問題 → 檢索知識庫 → 產生回答 → 顯示來源 → 使用者完成下一步判斷。控制在 1.5～2 分鐘，只展示最能代表價值的案例，一定要顯示來源，最好準備知識庫沒有答案的案例，以及錄影或截圖備案。
Demo 要證明：系統不只會回答，也能說明答案根據什麼；當知識庫沒有答案時，不會隨意產生內容。Demo 是亮點，但不能吃掉太多時間；若超過 2 分鐘，很容易壓縮後面最重要的驗證與結論。
第四部分｜Payoff：用證據回答做完之後有什麼不同
Payoff 不是只展示成果畫面，而是要證明系統真的產生改善。評審最關心：你怎麼知道答案是對的？答案是否來自知識庫？系統是否比原本方法好？有哪些情況仍然做不到？
第 11 頁｜測試方法、成果、限制與結論
12 分鐘版本建議把原本「測試與驗證方法」與「成果、限制與結論」合併成一頁。
怎麼驗證：說明測試題目如何設計、題目類型、誰判斷正確、是否有比較組，以及是否邀請實際使用者測試。建議題目類型包含：知識庫中有明確答案、需整合多份資料、容易混淆、知識庫中沒有答案、不同問法但意思相同。可選指標如回答正確率、來源支持率、引用正確率、拒答適切性、查詢時間、任務完成時間、使用者滿意度；選擇最適合專題的 3～5 項即可。
成果：說明建立了哪些資料與功能、解決了哪些情境、測試結果，以及與一般搜尋或生成式 AI 相比的改善。
限制：誠實說明知識庫規模、部分題型表現、資料更新人工處理、速度與成本、尚未大規模測試、權限與隱私等問題。
核心結論只保留三件事：我們看見了什麼問題、如何運用 RAG 處理、用什麼證據證明成果。
建議收尾句：「我們完成的不只是一套問答系統，也走過從市場需求、資料整理、技術選擇、系統設計到成果驗證的完整過程。」或：「真正重要的是，能不能讓評審認同：三年資管沒有白學。面對一個真實問題，我們知道如何思考、如何選擇、如何實作，也能清楚說出自己用了什麼、做了什麼、學到了什麼。」
12 分鐘時間配置
Hook（第 1～2 頁）約 1.5 分鐘；Problem（第 3～4 頁）約 2 分鐘；Solution（第 5～10 頁）約 6 分鐘；Payoff（第 11 頁）約 2.5 分鐘。
補充原則：Hook 要快，不宜拖太久；Problem 要具體，但不要重複；Solution 是主體，占最多時間；Payoff 一定要保留足夠時間，不能被 Demo 吃掉。
建議準備的備用頁
備用頁一｜完整技術參數：Chunk size、overlap、Embedding、Top-k、相似度門檻、Prompt、模型參數。
備用頁二｜完整資料來源：來源清單、文件數量、更新時間、格式、可信度判斷方式。
備用頁三｜錯誤案例分析：問題、系統回答、正確答案、錯誤原因、改善方式。
備用頁四｜驗證數據：題目分類、正確率、來源支持率、拒答結果、使用者測試結果。
備用頁五｜系統成本與維運：API 成本、資料更新、維護責任、權限管理、未來擴充。
完成簡報後的檢查問題
Hook：評審能否在第一分鐘理解誰遇到了什麼問題？開場是否先談情境，而不是先講技術？
Problem：是否證明需求真實存在？是否說明一般搜尋與生成式 AI 的不足？三個專題目標是否涵蓋需求、技術與成果？
Solution：是否清楚說明完整 RAG 流程？是否證明系統真的有檢索知識庫？是否說明資料來源與技術選擇理由？分工是否呈現程式開發以外的工作？Demo 是否顯示回答來源與查無資料的處理方式？
Payoff：如何判斷回答正確？如何確認答案有知識庫內容支持？是否進行比較、測試或使用者驗證？是否誠實說明限制？評審聽完後，能否用一句話說出這個專題的價值？