📖 機器閱讀理解 (MRC)
BiDAF → BERT → RAG · 博物館導覽機器人 · 120 天踩坑 · BERT vs LLM 選型
作者：TonTon Huang Ph.D.｜投入時間：2018/10/15–2019/02/10（~120 天）｜更新：2026-07-28
機器閱讀理解（MRC）要解決的問題是：「給機器一篇文章和一個問題，讓它找出答案」。比如展場導覽機器人，參觀者問「這件藏品是哪個朝代的？」，機器必須從展品說明書中定位並抽取出「明朝」這個答案。
MRC 是 NLP 領域中公認難度最高的任務之一，因為它同時需要語意理解、跨句推理、段落定位、答案抽取四種能力。2018 年 BERT 問世後才真正讓 MRC 達到實用水準。
MRC：最需要 LLM 的 NLP 任務，但傳統方法仍有一席之地
💡 核心論點：MRC 是五大 NLP 任務中傳統方法 vs LLM 界線最模糊的一個。固定知識庫（FAQ、產品說明）→ BERT+RAG；開放域問答（需要多步推理、跨文件融合）→ LLM（GPT/Gemini）。
| 比較維度 |
BERT 微調（封閉知識庫）固定域首選 |
LLM + RAG（開放域）複雜推理首選 |
| 知識庫大小 | 適合 <10 萬文件，索引後快速檢索 | 可接入任意規模知識庫，向量數據庫配合 |
| 答案必須在文本內 | 是，抽取式 MRC（Extractive）答案是原文片段 | 生成式 MRC，可融合多篇文章、生成摘要性答案 |
| 多步推理 | 困難：需要跨文件的推理依賴 | LLM 天然支援多步推理 |
| 幻覺風險 | 幾乎無：答案限定在原文內 | 有：LLM 可能生成文件中不存在的答案 |
| 延遲 | GPU ~50ms，CPU ~500ms | API round trip 1–5s + 生成時間 |
| 成本 | 一次微調，邊際成本接近零 | 每次問答消耗 Token（含文件 context） |
✅ 2026 黃金組合：Bi-encoder 召回 + BERT reranker + LLM 生成答案
BGE Embedding → FAISS 向量搜尋 → 召回 Top-5 文件 → BERT cross-encoder 精排 → GPT-4o 生成最終答案並附上引用來源。既保留效率，又有 LLM 的語言流暢性。
技術演進
BiDAF → QANet → Transformer-XL → BERT
BiDAF
雙向注意力流
→
Ruminating
多層注意力
→
Match-LSTM
序列匹配
→
QANet
純 CNN+Transformer
→
BERT
統一表示
→
RAG + LLM
2024+
🔷 BiDAF（Bidirectional Attention Flow, 2016）
同時計算「文章-問題」和「問題-文章」雙向注意力，讓模型能同時關注問題相關的文章段落。引入 Character Embedding 解決 OOV（未登錄詞）問題。是 2016–2018 年 MRC 的標準基線模型。
🧮 QANet（2018，Google Brain）
完全拋棄 RNN，改用純 CNN + Transformer。資料增強（Data Augmentation）是亮點：用機器翻譯把文章翻成其他語言再翻回來，生成語意相同的多元訓練數據。推論速度比 RNN-based 模型快 13 倍，是 BERT 問世前 SQuAD 最強模型。
⚡ Transformer-XL（2019，Google Brain）
引入「循環機制」讓 Transformer 可以記憶前一個片段的狀態，解決固定窗口的長文本問題。對於需要跨段落推理的長篇文章（如百科全書條目）尤為重要。但 BERT 問世後基本退出主流 MRC 競爭。
🏆 BERT for MRC（2018，Google）
BERT 在 SQuAD 2.0 上直接超越人類水準，徹底改變 MRC 格局。架構上極簡：把問題和文章拼接輸入（[CLS] 問題 [SEP] 文章 [SEP]），輸出兩個 Linear 層分別預測答案的起始和結束位置。只需微調幾個 epoch 即可。
數據集
中文 MRC 數據集：從 SQuAD 到 DRCD
⚠️ 核心痛點：2018 年做中文 MRC，幾乎沒有可用的繁體中文數據集。只能把英文 SQuAD 翻譯成中文使用，但翻譯品質影響模型效果，且簡繁轉換問題讓台灣場景更麻煩。
| 數據集 |
語言 |
規模 |
特點 |
台灣適用性 |
| SQuAD 1.0/2.0 |
英文 |
10 萬+ 問答對 |
維基百科文章，2.0 含 unanswerable 問題 |
⚠️ 機翻後可用，但品質有落差 |
| CMRC 2018 |
簡體中文 |
1.8 萬+ 問答對 |
中文維基百科，哈工大/科大訊飛 CodaLab 評測 |
⚠️ 簡體為主，繁體場景需轉換 |
| DRCD |
繁體中文 |
3 萬+ 問答對 |
台達電子研究院開發，維基百科為來源 |
✅ 台灣最佳選擇 |
| 自建 Wiki 標注 |
繁體中文 |
視場景而定 |
用 ChineseAnnotator 自行標注領域語料 |
✅ 最適合特定場景 |
實戰案例
博物館/展場導覽機器人 (2018–2019)
這是當時的核心應用場景：博物館展場內的導覽機器人，參觀者對著機器人說「這件青花瓷是哪個朝代的？」，機器人需要：
- ASR：語音轉文字，得到「這件青花瓷是哪個朝代的」
- 文本相似度：找到最相關的展品說明文件（80/20 法則）
- MRC：從說明文件中抽取「明朝（1368–1644）」作為答案
- TTS：合成語音播放給參觀者
⚠️ 多文件 MRC 的挑戰：一個問題可能需要參考多個展品說明才能完整回答（如「館內有哪些宋代文物？」），這是「多文件推理」問題，2019 年的 BERT 處理這種情況效果仍有限。這也是 2024 年 RAG 流行的原因之一。
⚠️ 繁體中文數據的永恆之痛：SQuAD 是英文，機翻成繁中後，翻譯品質良莠不齊；CMRC 是簡中，繁簡轉換後詞彙用語不自然。最終需要用 DRCD + 自建標注才能解決台灣場景問題。
✅ QANet 的數據增強技巧：把展品說明用 Google Translate 翻成英文，再翻回中文，得到語意相同但用詞不同的版本，與原版一起作為訓練數據。有效提升了小數據集的模型泛化能力。
2024+ 進展
RAG（檢索增強生成）：MRC 的現代解法
2023 年後，RAG（Retrieval-Augmented Generation）成為 MRC 問題的主流解決方案：把相關文件檢索出來，餵給 LLM 生成答案，既解決了 LLM 知識截止日期的問題，也減少了幻覺風險。
💡 RAG vs 傳統 MRC 的關鍵差異：
傳統 BERT MRC：答案必須是原文的片段（Extractive），答案範圍受限，但結果高度可信
RAG + LLM：答案可以是多文件融合後的摘要（Generative），更自然、更完整，但有幻覺風險，需要引用來源驗證
✅ 何時選傳統 BERT MRC：
• 知識庫已建立且更新頻率低（如展品說明、產品規格）
• 答案必須是原文的精確片段（法律條文引用、合約條款）
• 幻覺風險不可接受（醫療、法律場景）
• 部署環境無法連接外部 API
✅ 何時選 RAG + LLM：
• 需要跨文件融合信息（如「比較這兩個展品的差異」）
• 知識庫持續更新，不方便頻繁微調
• 答案需要自然語言解釋，而非原文片段
• 已有 GPT/Gemini API 預算且體驗優先