AO2 FIELD GUIDE · N060 · AI 問答與 RAG 應用
FAQ 搜尋與 RAG 選擇不靠文件數量一刀切。用問題變化、來源條件、答案形式與維護能力比較三種路徑，附任務決策表與小範圍試行表，先驗證能完成工作，再決定是否增加生成式問答。
只有十份文件，要不要直接做 AI 問答？文件數量很容易數，卻不一定反映工作難度。十份資料可能有複雜版本與權限，一百份也可能只需找原文。先判斷使用者要拿到什麼，才能選合適的回答方式。
FAQ 搜尋與 RAG 選擇，先列出答案要長什麼樣
把近期問題分成固定答案、定位來源、跨段整理與條件不足。固定且經核准的說法適合直接呈現 FAQ；讀者需要完整原文時，搜尋可讓他定位文件與段落；跨多段整理且仍可追查依據時，再評估 RAG。它們可以共用入口，但每一種任務都應有清楚的完成標準，不把聊天視窗當成唯一出口。
少量文件不等於簡單任務，大量文件也不一定需要生成答案。RAG 一般先檢索資料，再將相關內容提供模型生成回覆。Microsoft 的設計指引將資料準備、檢索、上下文與生成分開考量；這說明新增回答能力也新增驗證工作，不代表所有小型知識庫都應採用同一架構。
白話例子：問櫃台、查書架，還是請人整理摘要
假想電子零件團隊只有一小組核准文件。問上班時間，櫃台的固定回答就足夠；要讀某個型號的完整規格，書架索引更直接；要比較兩份文件對某條件的差異，才可能需要整理摘要。這像 FAQ、搜尋與 RAG 的三種工作：給已知答案、帶到來源、依來源組合回覆。
櫃台對應核准短答，書架對應定位來源，摘要對應生成整理。比喻沒有表示模型具備人的專業判斷。當規格未明或來源衝突，任何方式都不能憑空確認；RAG 也可能漏找、漏帶條件或錯誤整理。此例為假想選型情境，重點是先區分工作，不按文件數套用固定門檻。
先檢查資料能否支持任務，再選入口
挑一組代表問題，人工找出支持答案的來源、版本、適用條件與不可回答部分。若人工都無法確認，先修資料或補問；若內容已有但找不到，再改善分類、術語與搜尋。掃描檔文字、表格條件、存取範圍及更新方式都可能影響結果，不能只用檔案總容量描述準備程度。
確認資料後，再看問題是否穩定、需不需要逐次組合、使用者是否要看原文，以及可容許的錯誤影響。對固定且高影響的回答，可優先採經核准文字及必要接手。需要引用原文的工作，即使新增 RAG，也應保留來源入口。權限與必要限制是共同前提，不能因改成聊天就省略。
| 主要任務 | 可先評估的路徑 | 必要驗證 |
|---|---|---|
| 固定且核准的短答 | FAQ | 條件完整、更新有責任人 |
| 要找原文與附件 | 搜尋 | 常見問法能定位正確版本 |
| 依多段來源整理 | RAG | 檢索、上下文及主張可追查 |
| 資料不足或有爭議 | 補問與人工接手 | 不把未知補成肯定答案 |
用同一組任務做小範圍比較
先建立最小可用路徑，讓 FAQ、搜尋或 RAG 在相同資料範圍處理同類問題。記錄正確性、條件保留、找到依據的方式、完成時間與維護投入。測試包含能回答、需補問、無資料和不允許取得的情況。不要只挑一題漂亮展示，再把整套方案的可用性當成已證明。
若搜尋已能穩定完成工作，新增生成能力要有明確補足的缺口。若 RAG 能整理但不能保留限制，就先修正再談擴大。比較也要包含資料變動後誰更新答案、如何回測，以及故障時是否可回到來源或人工。可用方案是工作完成與後續維護一起成立，不只是第一次回覆順暢。
選能維持的範圍，逐步增加能力
可以先將常見固定題做 FAQ，其他問題導向搜尋；對確實需要跨文件整理的任務，再加入有來源的問答。這是依證據逐步擴大，不表示每家公司都要依同樣階段前進。若需求本來就需要跨段生成，也可直接試驗，但仍把資料、檢索、答案與責任邊界列成可驗收工作。
選型理由要寫「補足哪個任務缺口」，不能只寫「功能比較新」。留下未採方案的原因及重新評估條件，例如問法變化、資料範圍或維護負擔改變。這樣下一次討論可回到實際需求，不用每次重新從產品展示或工具名稱開始，也不會把原本可用的固定回答全部重做。
| 檢查面向 | 留下什麼 | 決策用途 |
|---|---|---|
| 代表任務 | 題目、條件與預期產出 | 避免只選展示成功題 |
| 答案品質 | 依據、限制及錯誤類型 | 判斷能否真的使用 |
| 使用路徑 | 找法、步驟與求助 | 辨識入口與整理缺口 |
| 後續維護 | 資料變動、回測與接手 | 決定可持續範圍 |
常見問題
只有十份文件，是不是 FAQ 就夠了？
不能只看數量。若問題固定、答案可核准且易維護，FAQ 可能足夠；若需要定位完整原文，搜尋更合適；若常需跨段整理，才評估 RAG 的價值與驗證成本。十份文件也可能有複雜版本或權限，先用代表任務確認資料與產出要求，再決定方案，不設定通用的文件數門檻。
FAQ、搜尋和 RAG 一定要選一個嗎？
不必。它們可以支援不同任務，例如固定題直接給核准回答，查規格導向來源，需要整理時提供附依據的問答。共同入口要說清楚使用範圍與接手方式，並分別驗證品質。混合方案仍需有人維護，不因功能整合在一頁，就把答案更新、來源狀態和存取條件全部視為自動處理。
怎麼知道 RAG 值不值得增加？
先寫出既有方法無法完成的具體任務，再用同類題目試行。核對答案、條件、來源、完成時間與維護投入，也測無資料和需補問情境。若只是文字更順卻沒有改善任務，價值仍未確認。若改善成立，再估擴大範圍與持續成本，不能把一次成功展示直接換算成全面導入成果。
白話總結：需要的是櫃台、索引，還是來源摘要
先看使用者要完成什麼，用代表任務比較最小可行路徑，再決定是否增加生成能力。
- 分任務：固定短答、找原文、跨段整理與條件不足各自列清楚。
- 試路徑：用相同資料和同類問題核對品質、使用與維護。
- 定範圍：記錄選型理由、接手方式及重新評估條件。
完成條件：團隊能說清楚每種問題走哪條路，為何適合，以及資料變動後由誰確保仍然可用。
來源與方法範圍
資料查核：2026 年 10 月 24 日。來源支持文中對應的準則與平台說明；工作表、判斷步驟及已標示的假想情境由 AO2 整理，實際使用時依產品資料與現行設定核對。
