🏠 地端 AI 文件助手進階：RAG 切片策略、Top-K 調校與引用來源格式最佳實務
很多人在搭建地端 AI（例如 Ollama + 各類文件助手）後，明明資料都放進去了，回答卻常出現兩種狀況： 抓不到重點 或 抓到不相干的段落，最後就變成「看起來很像有回答，但其實不可靠」。
這通常不是模型不夠強，而是 RAG（檢索增強生成）流程裡最關鍵的三個地方沒調好： 切片（Chunking）、檢索參數（Top-K / 閾值）、以及 引用來源（Citations）。 本篇以「能維運、可驗證、可上線」的角度，整理一套你可以直接套用的最佳實務。
📌 目錄
- 1) 目標與適用場景
- 2) RAG 的核心流程：你到底在優化哪一段？
- 3) 切片策略：為什麼它決定了『檢索準不準』
- 4) 切片實戰配方：依文件型態選 Chunk Size
- 5) Overlap 怎麼設才不會斷上下文？
- 6) Top-K 與 Similarity Threshold 的調校方法
- 7) Context Window 預算：別讓雜訊塞爆模型
- 8) 引用來源（Citations）：可追溯不是加個註腳而已
- 9) 地端 RAG 常見坑與對策
- 10) 上線前的 RAG 優化檢查清單
- FAQ
- 🔗 延伸閱讀
1) 📌 目標與適用場景
- 讓檢索抓得準：切片策略正確，向量相似度才會「對焦」。
- 讓回覆穩且可驗證：Top-K/閾值調好，雜訊不會把答案帶歪。
- 讓結果可追溯：引用來源要能回到「哪份文件、哪個章節、哪一頁或哪個段落」。
- 適合：企業內部知識庫、個人技術筆記地端 AI、法務/醫療/稽核等需要可追溯回答的場景。
2) 🧩 RAG 的核心流程：你到底在優化哪一段？
先把流程講清楚，才知道要改哪裡。RAG 可以拆成四段，每段出問題症狀不一樣：
[文件] → (抽取/清洗) → (切片 Chunking + Metadata)
→ (Embedding 寫入向量庫)
[提問] → (Embedding 查詢) → (Retrieval: Top-K / Threshold / 排序)
→ (組合 Context) → (LLM 生成 + 引用輸出)- 抽取/清洗出問題：PDF 表格破碎、段落順序亂，後面再怎麼調都救不回來。
- 切片出問題：檢索命中看似相關，但內容不完整，容易「抓到半句」或「漏掉定義」。
- Retrieval出問題：Top-K 太大塞雜訊、太小漏資料；Threshold 太高撈不到、太低撈錯。
- 引用出問題：答案看似正確，但沒辦法驗證，使用者信任度會一路掉。
3) 🧠 切片策略：為什麼它決定了『檢索準不準』
向量檢索抓的是「語意相似度」，而不是「你以為的關鍵字」。如果一段太長，向量會變得模糊；如果太短，又會失去上下文。 所以切片的目標不是「切得多」，而是讓每個 chunk 成為可獨立被理解的最小知識單位。
✅ 建議優先採用：結構優先切分（標題/段落/清單）
- 先按結構切：標題 → 小節 → 段落 → 清單項（比固定字數硬切穩定很多）。
- 再用大小補齊：超長段落才用字數/字元補切。
- Metadata 跟著切：章節標題、頁碼、段落索引、chunk_id 直接帶上，後面引用才做得起來。
4) 🧪 切片實戰配方：依文件型態選 Chunk Size
沒有一個 Chunk Size 可以通吃。最務實的做法是：先按文件型態分群，給「起始值」，再用題庫去驗證與微調。
| 文件型態 | 建議 Chunk Size（起始值） | Overlap（起始值） | 原因 |
|---|---|---|---|
| 技術教學／操作手冊（段落清楚） | 600 ~ 900 | 80 ~ 160 | 需要保留「步驟前後」與注意事項 |
| 規格書／名詞定義密集 | 400 ~ 700 | 120 ~ 200 | 定義 + 條件常黏在一起，Overlap 要更保守 |
| FAQ／短段落問答 | 250 ~ 450 | 40 ~ 80 | 一問一答本身就短，切太大反而混雜 |
| 程式碼／設定檔 | 200 ~ 400（以行為單位更佳） | 20 ~ 60 | 以函式/區塊切比字數切可靠 |
| PDF 表格為主 | 先轉 Markdown/結構化後再切 | 視欄位而定 | 抽取若破碎，切片再完美也救不回來 |
如果你只想要一個「先能用」的起手式：Chunk Size 700、Overlap 140，再用 Top-K/Threshold 做微調，通常能先把「胡說八道」壓下來。
5) 🛠 Overlap 怎麼設才不會斷上下文？
Overlap 的目的不是灌水，而是避免「定義剛好在上一段、解釋剛好在下一段」時，檢索只拿到半套資訊。 最常見的建議是 Overlap = Chunk Size 的 10%~20%，但你可以用一個更直覺的判斷：
- 如果你的 chunk 常含「術語 + 定義 + 條件」：Overlap 偏大（15%~25%）。
- 如果你的 chunk 多為「短問答/小段落」：Overlap 偏小（5%~15%）。
CHUNK_SIZE = 700
CHUNK_OVERLAP = 140 # 約 20%6) 🔍 Top-K 與 Similarity Threshold 的調校方法
這兩個參數決定「模型會看到哪些資料」。策略是：先把切片固定，再用一組固定題庫做 A/B 測試。
6.1 Top-K（撈回來幾段）
- K=3~5：一般問答最常用，雜訊少，結論更聚焦。
- K=6~10：整理/比較/彙整型問題，背景更完整，但更容易塞入不相干段落。
6.2 Similarity Threshold（相似度閾值）
用來把「看似相關但其實是雜訊」擋掉。常見起手式：
- 先從 0.70 開始
- 撈不到資料就降到 0.65
- 雜訊太多就升到 0.75
6.3 建議的調校順序（最省時間）
- 先調 Top-K：3 → 5 → 8（看漏抓 vs 雜訊）
- 再調 Threshold：0.75 → 0.70 → 0.65（看撈不到 vs 亂抓）
7) 🧾 Context Window 預算：別讓雜訊塞爆模型
很多人 Top-K 開很大，結果不是更準，而是更亂。原因很簡單：Context Window 有上限，你塞進去的每一段都在跟正確資訊搶位置。
7.1 一個好用的預算分配
- 20%：系統指令/回答格式/引用規則（不可省）
- 70%：檢索回來的 chunks（主菜）
- 10%：使用者問題、額外限制條件
7.2 實務技巧：先「排序」再「截斷」
- 先依相似度排序（或加上 rerank）
- 再依 token 預算逐段加入，超過就停止
- 必要時把「第二梯隊」資料放到下一輪（多輪檢索）
8) 📄 引用來源（Citations）：可追溯不是加個註腳而已
「引用」真正的價值是：讓使用者能回頭核對，並讓你自己能排錯。要做到這件事，metadata 需要規格化。
8.1 建議的 metadata（至少要有）
doc_id：文件唯一 ID（不要只靠檔名）file_name：檔名或顯示名section_title：章節標題（非常關鍵）page_number：PDF 可用（沒有就用段落索引）chunk_id：切片後的唯一 ID（例：doc_id + 序號）offset：字元偏移或段落索引（方便精準定位）source_url：可點開的來源（內網也行）
8.2 推薦的提示詞模板（可直接套用）
你是嚴謹的技術文件助手，只能依據【參考資料】回答。
若【參考資料】未包含答案，請回覆「資料不足」，並列出需要補充的資料或文件。
輸出格式（必須遵守）：
1) 結論（條列）
2) 依據（每點後面附 [來源]）
3) 若有操作：步驟（必要時附 [來源]）
4) 引用清單（列出每個 [來源] 的文件/章節/頁碼/ID）
【問題】
{question}
【參考資料】
[來源1] 文件：{file_name}｜章節：{section_title}｜頁碼：{page_number}｜ID：{chunk_id}
內容：{chunk_text}
[來源2] ...8.3 引用輸出格式（讀者最好核對）
- 句尾引用：
...（參考：[來源1][來源3]） - 段尾引用：段落最後統一列：
引用：[來源2][來源4]
9) ⚠️ 地端 RAG 常見坑與對策
9.1 PDF 表格抽不乾淨，答案永遠怪怪的
表格被拆成碎片文字時，向量檢索容易抓到「半列資料」。
對策： 先把表格轉成 Markdown（保留欄位名/單位），或轉成結構化 JSON，再進行切片與寫入。
9.2 你以為是 Top-K 問題，其實是「切片太粗」
當 chunk 太長，檢索命中會變得「看起來相關但抓不到答案」。
對策： 先把 chunk size 降一級（例如 900 → 700 → 500），再重新建索引。
9.3 向量庫變大後變慢
chunks 到十萬級以上，延遲通常會開始飄。
對策： 做資料分層（hot/warm）、做 namespace/collection 分割、或考慮更適合的向量庫與索引策略。
9.4 Embedding 不一致（最容易忽略）
寫入用 A 模型、查詢用 B 模型，就算是同家族也可能讓相似度失真。
對策： 寫入與查詢強制同一套 embedding，並把版本寫入 metadata。
10) ✅ 上線前的 RAG 優化檢查清單
- [ ] 抽取後的文字順序正確（PDF 不亂跳段、不破碎）
- [ ] 切片採「結構優先」：標題/段落/清單優先切分
- [ ] Overlap 介於 Chunk Size 的 10%~20%，且已用題庫驗證
- [ ] Top-K 與 Threshold 依固定題庫做過 A/B 調校
- [ ] Context 預算控管：排序後再塞入，避免雜訊塞爆
- [ ] 每個 chunk 有完整 metadata（章節/頁碼/chunk_id/來源）
- [ ] 回覆強制引用；撈不到就輸出「資料不足」
你現在的 RAG 主要卡在哪一段？是抽取（PDF/表格）、切片（Chunk Size/Overlap）、還是檢索（Top-K/Threshold）？
也歡迎分享你的參數（Chunk Size / Overlap / Top-K / Threshold）與一兩個「最常問的問題」，很容易就能收斂到更穩的調校方向。
FAQ
Q1：Overlap 設越大越安全嗎？
不一定。Overlap 會增加索引量與相似段落重複命中，太大會讓 Top-K 更容易撈到「同一段的不同版本」，反而浪費 Context 預算。 一般從 10%~20% 起跳，再用題庫驗證最穩。
Q2：我想要答案更『保守』，寧可回答不知道
把 Threshold 拉高（例如 0.75），Top-K 降低（例如 3~4），並在提示詞要求「資料不足就直接說不足」。 同時強制引用來源，這會大幅壓低幻覺機率。
Q3：我想要答案更『完整』，可以做彙整與比較
把 Top-K 拉到 6~10，搭配 Context 預算控管（排序後逐段加入），必要時採「兩階段檢索」：先檢索後摘要，再依摘要做第二輪精準檢索。
沒有留言: