一、前言

在第一週，我們為 AI 裝上了軀幹與大腦（Dify + Gemini）；而在過去這 7 天的第二階段（Day 7～Day 13）中，我們全力攻克了生成式 AI 最關鍵的技術——RAG（檢索增強生成）：

• 上傳了第一份課堂 FHIR 講義（Day 7）
• 克服碎成388塊的切片，調優為具備完整語意的文字塊（Day 8）
• 透過檢索測試（Hit Testing）驗證專有名詞與概念召回能力（Day 9）
• 在 Chatflow 畫布中將知識庫串接至 LLM 的 CONTEXT（Day 10）
• 開啟自動引用出處標籤，讓回答具備可追溯性（Day 11）
• 探討溫度值原理與新架構下模型嚴謹度的調校（Day 12）
• 實測專門縮寫（HL7 FHIR）在純向量檢索下的精準度（Day 13）

雖然結果看似順利，但在這段「餵教材給 AI」的過程中，身為醫資系學生，我們其實踩過了不少關於檔案格式、投影片排版與系統限制的坑。今天我們就來做個階段大驗收，盤點 4 個最常見的排版痛點與最佳解法，為知識庫篇畫下扎實的句點！

二、踩坑盤點一：簡報轉 PDF 時的「單詞成行」與碎片化陷阱

• 痛點現象：在 Day 7 上傳講義時，我們發現一份不長的簡報居然被切成了高達388塊切片，其中有些切片只有幾個字，平均段落長度只有44個字元！
• 原因剖析：PowerPoint 投影片為了視覺排版，文字方塊通常很零散，匯出成 PDF 時往往夾帶大量的單換行符號（\n）。Dify 預設若以單換行為切分依據，一遇到換行就會硬生生把完整句子截斷。
• 實務避坑解法：
  • 改用雙換行切分：在分段設定中，將識別符號設定為\n\n，優先保證段落完整性。
  • 適當給予長度彈性：設定 500～800 字元上限搭配 10% 的 Overlap（重疊字數），避免前後文名詞斷頭斷尾。實測證實能順利將碎片收斂到數十塊具備完整結構的段落！

三、踩坑盤點二：表格（Table）與多欄排版產生的文字雜訊

• 痛點現象：醫學資訊簡報中經常包含「標準對照表」（如 HL7 v2 vs. FHIR 的比較）或左右兩欄的排版。直接轉成 PDF 丟進 Dify 後，有時會發現系統讀取順序是「從左上橫著讀到右上」，導致表格欄位與內容錯置。
• 實務避坑解法：
  • 純文字或 Markdown 預處理：如果是極為重要的考點表格，上傳前不妨直接將該頁內容手動複製，整理成簡潔的 Markdown 表格語法（| 欄位 1 | 欄位 2 |）或條列式純文字再存檔餵入，AI 的辨識準確率會高達 100%！

四、踩坑盤點三：純圖片掃描檔的致命盲點

• 痛點現象：許多同學平時習慣用手機「翻拍」課本或投影幕，直接將相片轉成 PDF 餵給知識庫，結果檢索測試時完全搜不出任何內容！
• 原因剖析：純照片檔在底層本質上是像素（Pixels），缺乏文字編碼。Dify 免費版標準解析器只能抽取文字層，無法直接讀取圖片中的文字。
• 實務避坑解法：
  1. 盡量使用老師提供的原始 PPT / 數位 PDF 講義。
  2. 若只有紙本翻拍講義，務必先經過 Google Docs 或手機內建的 OCR 功能辨識為可複製的純文字後再匯入。

五、踩坑盤點四：雲端額度限制與檢索策略選擇

• 痛點現象：在想要開啟全文檢索或混合檢索（Hybrid Search）時，系統提示配額已用盡或 Rerank 模型無法調用。
• 實務避坑解法：不用慌張！實測證明，只要搭配 Google 免費的 gemini-embedding-001 進行純向量檢索，在檢索專有名詞縮寫（如 HL7 FHIR）時依然能達到 0.77 的高分召回！在免費用戶的架構下，這套方案兼顧了穩定度與零成本。

六、知識庫改版成果對照

經過這 7 天的逐步調校，我們的課堂知識庫完成了質的飛躍：