2026.10.19
RAG資料切分實戰指南：提升檢索品質的關鍵方法
AI資訊
RAG資料切分不是把文件隨意截成幾段，而是決定知識庫能否找對證據的核心設計。當使用者詢問「某產品保固是否含耗材」時，若保固條款、例外情況與產品型號被切散，模型即使語言能力再好，也可能檢索到不完整片段，最後給出看似合理卻不符合規範的答案。
RAG 系統會先把企業文件轉為向量，再依問題找出相關內容交給模型生成答案；因此，切分品質同時影響召回率、回答完整度、索引容量與查詢延遲。尤其中文文件常混有表格、條款、型號、英文縮寫與掃描 PDF，若只以字元數硬切，容易破壞語意與文件結構。
本文將從切分必要性、常見策略、不同資料來源處理、檢索管線整合、評估實驗與企業治理依序說明，並提供可直接用於 PoC 的測試做法。讀完後，你可以建立可量測的切分假設，而不是只憑直覺挑選 chunk size 與 overlap。
RAG資料切分為何決定回答是否可信
切分的直接目的，是讓每個片段保留可回答問題的最小證據
直接來說，好的切分單位必須讓單一片段在脫離原文件後，仍保有足夠的主詞、條件、例外與結論。若只留下「可申請退貨」這一句，卻把「限收到商品後七日內」切到另一塊，檢索結果就可能造成錯誤承諾。切分的目標不是製造愈多向量愈好，而是建立可被獨立理解、可被精準召回的知識證據。
嵌入模型會把一段文字壓縮成向量表示；段落太長時，保固、付款、交期等多個主題被混在同一向量中，查詢相似度容易被稀釋。段落太短則缺少必要限定條件，使模型只能根據零碎語句推論。實務上應先定義「一塊能回答哪一類問題」，再決定文字長度，而非反過來只選一個漂亮的數字。
生成階段也會受到內容排列影響。當大量候選內容塞入提示詞，中間位置的證據可能較不容易被模型有效運用，這是常被稱為 Lost in the Middle 的現象。因此，切分、召回與重排要一起設計：切出完整證據，先廣泛找回，再把最相關的內容放在模型容易引用的位置。
- 切分單位應包含主詞、條件、例外與結論
- 過長片段會稀釋向量主題，過短片段會遺失限定語
- 檢索品質不能只看是否命中關鍵字，也要看證據是否完整
上下文限制不是唯一問題，嵌入輸入與生成成本同樣需要控制
直接答案是，chunk size 必須同時低於嵌入模型可接受的輸入範圍，也要符合最終提示詞的預算。某些教材以「上下文窗口為512個token」示範限制，而現代模型雖可支援更長內容，並不表示每次都該傳入大量文字。內容愈長，檢索排序愈難辨別細微差異，推論延遲與成本也會隨之增加。
Token 不等於中文字數，中文、英文、數字、程式碼和標點會產生不同切分結果。團隊不應只用「500 字」作為唯一規則，而要以實際嵌入器的 tokenizer 量測。若產品手冊中含大量型號與料號，字面不長卻可能消耗較多 token；若忽略此差異，入庫時就可能發生截斷或資料不一致。
最可靠的做法是在資料管線記錄每個 chunk 的 token 數、來源頁碼、標題路徑與版本。當答案錯誤時，工程與業務人員便能回溯：問題是文件未收錄、切分遺失條件、向量未召回，還是模型沒有忠實使用證據。這種可追溯性比單次展示漂亮答案更能支持正式導入。
- 以 tokenizer 實測取代單純用中文字數估算
- 記錄 token、頁碼、標題、版本與來源連結
- 把提示詞預算保留給多個高品質證據，而非單一長文
Overlap 的作用是保護跨邊界語意，而不是無限制複製文字
直接來說，overlap 應只用來保留跨段落邊界的必要脈絡。例如一段先定義「甲方」，下一段才說明甲方義務，少量重疊可避免後段失去指涉對象；但把一半內容重複到下一塊，會造成近似向量大量堆疊，使檢索結果被同一篇文件壟斷。
常見起點可使用 chunk_size = 500 與 chunk_overlap = 50，再依資料特性調整。對短篇 FAQ，重疊可能幾乎不重要；對法規條款、技術規格與逐步操作說明，則需要讓標題、前提或步驟銜接保留在相鄰片段。起點不是標準答案，必須交由測試問題驗證。
重疊比例提高，向量數量、嵌入成本與重複召回機率也會提高。建議在索引建立後檢查相鄰 chunk 的相似度與文字重複率；若多數片段幾乎一樣，代表 overlap 過大。相反地，若問題常需要前後兩段才能還原條件，則應優先檢視段落邊界與結構切分，而非盲目加大重疊。
- Overlap 用於維持跨邊界語意，不是提高資料量
- 以相鄰 chunk 相似度檢查重複是否過高
- 優先修正切分邊界，再考慮擴大重疊
四種主流切分策略與選型原則
固定大小切分適合快速建立基準，但不應直接視為最終方案
RAG資料切分若處於第一輪原型階段，固定大小切分是最容易建立基準的方法。它依字元、單詞或 token 數切開文件，實作簡單、吞吐量穩定，也容易預估索引大小。對格式混亂、無法可靠解析標題的純文字資料，這是一個合理起點，但它不理解句子或主題邊界。
例如可先設定 chunk_size = 200 與 chunk_overlap = 10，用於檢查資料能否順利解析、嵌入與檢索。若內容含較長的段落，可改以 CHUNK_SIZE = 500、CHUNK_OVERLAP = 50 建立另一組實驗，並以同一批標準問題比較答案引用的完整性，而不是只比較系統是否能輸出文字。
固定大小最常見的失敗模式，是把表格列、程式函式、條款例外或段落標題切成兩半。若問題涉及「適用對象、金額、期限、例外」等成組資訊，系統可能只找回其中一半。發現這類問題時，應改用遞迴或結構化策略，而不是持續微調單一字數。
- 優點是實作快速、成本可預測、適合建立對照組
- 缺點是可能切斷句子、表格列與條款條件
- 第一輪測試必須保留固定大小策略作為品質基線
遞迴切分以自然分隔符優先，通常是企業文字的穩健預設
直接答案是，遞迴切分會優先依文件中最有意義的邊界拆分，例如標題、雙換行、單換行、句號與空白；只有在片段仍超長時，才逐層使用更細的分隔符。因此，它比固定字數更容易保住段落和句子的完整性，特別適合內規、說明書、客服知識與一般 Markdown 文件。
中文文件應自訂分隔符順序，納入「。」「！」「？」「；」「\n\n」與章節符號，同時留意中英混雜的句點與縮寫。若資料常出現「3.2.1」或「v2.0」，把句點一律當斷點會切壞編號與版本資訊。遞迴策略的價值，在於可以把這些組織知識明確寫入規則，而非交給字元長度碰運氣。
遞迴切分不保證每個片段只有一個主題。當一個段落同時講授權、資安與費用，仍可能產生混合向量。因此它應被視為可靠的文字骨架，而不是取代測試的萬靈丹。團隊應從標準題庫抽查：每個正確答案所依賴的證據，是否落在同一塊或相鄰可共同召回的區域。
- 先保留章節與段落，再逐步細切到句子
- 中文標點與版本編號需要客製分隔規則
- 適合作為非結構化企業文字的主要預設策略
語義與結構化切分，適合主題明確或版面規則完整的內容
直接來說，語義切分會根據相鄰句子的嵌入相似度偵測主題轉折；結構化切分則直接使用標題、章節、清單、表格和文件元素。前者適合連續敘事、研究報告與長篇說明，後者適合規格書、政策文件、Markdown 與具有穩定標題層級的知識庫。兩者都比固定切分更能保存讀者理解的脈絡。
語義方法常會以相鄰句子形成緩衝區再計算差異，部分實作提供 buffer_size`参数（默认为1），並可用 breakpoint_threshold_amount` (默认为 `95`) 作為斷點閾值起點。這些數字不是品質保證；不同領域的句子密度、術語重複程度與文件語氣，都會改變相似度分布。
結構化方法的關鍵是把父層資訊帶到子塊，例如每個段落附上「產品手冊＞安裝＞網路設定」的標題路徑。如此一來，即使片段本身只寫「請重新啟動」，檢索與生成端仍知道它屬於哪個產品、哪個步驟。對企業文件而言，這種 metadata 往往比再增加幾十個 token 更有價值。
| 策略 | 適用內容 | 主要優勢 | 主要限制 |
|---|---|---|---|
| 固定大小 | 格式混亂純文字 | 快速建立基線 | 易切斷語意 |
| 遞迴切分 | 內規與說明文件 | 保留自然段落 | 仍可能混合主題 |
| 語義切分 | 報告與長篇文章 | 辨識主題轉折 | 計算成本較高 |
| 結構化切分 | 規格書與 Markdown | 保留章節脈絡 | 仰賴解析品質 |
- 語義切分以主題轉折決定邊界
- 結構化切分以標題、段落、表格與節點保存脈絡
- 子塊應攜帶標題路徑等父層 metadata
依資料類型處理 PDF、表格、程式碼與多模態內容
PDF 先做版面與 OCR 品質檢查，再決定文字邊界
直接答案是，PDF 不應一律當成純文字處理。原生電子 PDF 的文字順序通常較可用，但雙欄排版、頁首頁尾、註腳與浮動圖表仍可能讓抽取順序錯亂；掃描檔則先面臨 OCR 誤辨問題。若原始文字已錯，後續再精密的向量檢索與重排也無法可靠補救。
處理流程應保留頁碼、區塊座標、標題階層與文件名稱，並在抽取後抽樣比對原始畫面。使用 PyMuPDF、pdfplumber 或 Unstructured 等工具時，不只要確認「有沒有文字」，更要確認條款編號是否連續、表格欄位是否對齊、頁首是否被誤混進內文。這些都是影響切分邊界的前置品質。
跨頁段落和跨頁表格是常見陷阱。若表格下一頁只剩數值，沒有欄名，該頁單獨嵌入幾乎沒有可檢索意義。較佳做法是把欄名、表格標題與跨頁標記一起放進 chunk，必要時將同一邏輯表格合併成結構化文字，讓問題中的欄位名稱能對應到正確數值。
- 先驗證 OCR 與閱讀順序，再談向量化
- 頁碼、版面區塊與標題層級應成為 metadata
- 跨頁表格必須補回欄名與表格標題
表格應以列與欄位語意切分，避免只存成破碎文字
直接來說，表格的最小單位通常不是一整頁文字，而是一筆可被問題定位的資料列，加上欄位名稱與表格語境。若使用者問「Laptop 的價格是多少」，只儲存 `ProductID: 101, ProductName: “Laptop”, Price: 1200` 還不夠；若缺少幣別、價格類型、有效期間與資料來源，系統仍可能回答得不完整。
對小型表格，可將表格標題、欄名與每一列轉成自然語句或 JSON，再以一列或一組相關列建立 chunk。對大型財務、庫存或品項表，則應搭配資料庫查詢或文字轉 SQL，而非把所有數值塞進向量庫。向量搜尋擅長找概念相關內容，並不天然擅長精確聚合、排序與計算。
表格與正文有關聯時，要建立雙向連結。例如「費率表」的每個片段應指向解釋計價條件的章節；解釋章節也應保留表格識別碼。這能避免模型只找到價格卻不知道適用門檻，或只找到政策敘述卻無法回覆具體金額。
- 每列應攜帶表格名稱、欄名、單位與有效條件
- 需要聚合計算的資料應交由結構化查詢處理
- 正文與表格之間應以識別碼建立可追溯關聯
程式碼、簡報與圖片需要以元素節點保存原始關係
直接答案是，程式碼不宜依一般句號與段落切分，應優先以函式、類別、模組、註解區塊與 import 關係作為邊界。tree-sitter 等語法剖析工具可協助取得抽象語法結構，讓每個 chunk 保有函式名稱、檔案路徑與語言資訊，避免把函式宣告與實作內容拆散。
簡報與圖片型文件則應保留投影片編號、標題、圖說、OCR 文字與相鄰元素關係。只抽取投影片上的幾個詞，通常無法傳達圖表趨勢與結論。若圖表本身是重要證據，可額外產生文字描述，並連結到原圖或投影片位置，讓回答能提供可查核的引用來源。
採用 LlamaIndex 或 Unstructured 這類元素導向工具時，重點不是套件名稱，而是確認節點模型能否表達父子關係。例如章節是父節點、段落和表格列是子節點；檢索到子節點後，再按需要補入父節點摘要。這樣可兼顧精準召回與完整背景，降低單一長 chunk 的負擔。
- 程式碼以函式、類別與模組等語法節點切分
- 多模態資料需保存投影片、圖片與圖說的關係
- 父子節點有助於兼顧精準檢索與完整背景
把切分放回完整檢索管線，避免只優化單一環節
混合檢索能補足向量搜尋對精確詞彙的不足
直接答案是，企業知識庫應優先評估向量檢索加上關鍵字檢索的混合模式。向量搜尋善於理解「出差報銷」與「差旅費請款」的語意接近，但面對產品型號、合約編號、錯誤碼或罕見縮寫時，關鍵字往往更可靠。切分後保留原文與欄位化 metadata，才能讓兩種檢索各自發揮作用。
一個常見流程是「問題向量化 ──▶ 在向量库做相似度检索 + 关键词检索 → 召回 ~20 个候选块」。這一層的目的不是立刻選出唯一答案，而是盡量不要漏掉關鍵證據。若切分過碎，二十個候選可能被同一段內容的重複片段塞滿；若切分過大，真正答案又可能被不相關主題稀釋。
metadata 過濾應在召回前使用，而非讓模型事後猜測。常見篩選條件包括部門、產品線、語言、文件狀態、生效日期、租戶與使用者權限。這些欄位也能讓同一份文件的不同版本共存；查詢時只取已核准且目前有效的內容，避免舊政策被高相似度向量誤召回。
- 向量檢索適合語意相近，關鍵字適合型號與精確詞彙
- 候選集合的任務是提高召回，不是直接生成答案
- 權限、版本與文件狀態應在檢索前過濾
重排器把廣泛候選縮成可供模型引用的證據集合
直接答案是，重排器應放在初步召回之後，用更精細的查詢與文件配對模型選出最相關證據。實務流程可設定「重排(rerank)→ 精选最相关的 top-3~5 块」，讓生成模型看到少量但關聯度高的內容。這也呼應「向量召回是「广而粗」,重排是「精而准」」的分工。
有些實作會先重新評估前 25 名，並傳回絕對最佳的 3 個結果。這樣的設定特別適合政策問答：初步檢索可能把多個相似條款找回，重排器再根據完整問題判斷哪一段真正回答使用者。若沒有重排，模型只關注前 5 個結果時，確實可能錯過第 7 個位置的重要答案。
重排不是切分問題的遮羞布。若答案需要兩個相鄰 chunk 才完整，重排器選中其中一塊後仍可能造成資訊缺漏。可採取相鄰擴展策略：命中某 chunk 時，依 token 預算補入前後片段或父節點摘要；但必須標示其來源，避免把不相關鄰居一併帶入。
- 初召回追求不漏找，重排追求排序精準
- top-3~5 應以題庫表現與提示詞預算決定
- 可加入相鄰片段或父節點，但要控制無關內容
上下文補充與答案引用，能降低片段脫離原文的風險
直接答案是，每個 chunk 在嵌入前可補上一句簡潔的文件上下文，例如文件名稱、章節路徑、適用產品與段落主旨。這不等於把整篇文件複製進每個片段，而是補足代名詞與隱含背景。像「它涨了 20%」這類句子，若沒有前文就無法知道「它」指的是售價、流量或成本。
Anthropic 的 Contextual Retrieval 說明指出，為每塊補充上下文可把檢索失敗率降低 49%，搭配重排可達 67%。這是值得驗證的方向，但不應直接當成自家資料的保證值；中文條款、表格與內部術語是否同樣受益，仍必須由企業自己的題庫、權限規則與資料品質驗證。
最終答案應附上文件名稱、章節、頁碼或可存取連結，並要求模型在證據不足時明確說明無法確認。引用設計不只提升使用者信任，也有助於除錯：當回答錯誤，團隊可立刻判斷是檢索到錯誤來源、正確來源被漏召回，或模型誤讀了正確內容。
- 以短上下文補足代名詞、主體與適用範圍
- 外部研究數據應視為假設，仍需在自家資料驗證
- 答案引用是使用體驗與除錯機制的一部分
以 PoC 建立可量測的切分實驗與企業治理機制
先用標準題庫做消融實驗，才能知道改善來自哪個環節
直接答案是，切分策略不能只靠少數示範問題判斷，應建立涵蓋真實工作情境的標準題庫。題目至少要包含直接查詢、跨段整合、否定條件、表格數值、專有名詞與無答案問題，並為每題標記正確文件、正確段落與可接受答案。這樣才能區分「回答看似流暢」和「證據確實正確」。
實驗應採消融方式：先固定嵌入模型、向量庫、提示詞與重排器，只比較固定、遞迴、語義和結構化切分；接著固定最佳切分，再比較 overlap、上下文補充與重排。評估可包含 Recall@K、MRR、nDCG、答案正確率、引用正確率與無證據時的拒答表現，避免單一分數掩蓋風險。
切分方案也應量測成本與速度，例如 chunk 總數、嵌入處理時間、索引容量、P95 查詢延遲與每題推論 token。品質最高的方案未必能承受每日更新量；成本最低的方案也可能在關鍵條款上漏答。決策者需要的是品質—成本曲線，以及何種錯誤風險可被業務接受。
| 步驟 | 要做什麼 | 觀察重點 |
|---|---|---|
| 建立題庫 | 標記問題與證據 | 涵蓋高風險情境 |
| 建立基線 | 固定大小切分 | Recall@K 與引用完整性 |
| 比較策略 | 遞迴、語義、結構化 | 品質增益與成本 |
| 加入重排 | 固定候選數測試 | 排序與延遲 |
| 現場驗證 | 真實使用者試用 | 可用性與例外題 |
- 題庫需涵蓋直接題、跨段題、表格題與無答案題
- 以消融實驗分辨切分、重排與嵌入模型的貢獻
- 同時評估檢索品質、回答品質、延遲與索引成本
增量更新、版本與權限，是正式環境不可忽略的切分設計
直接答案是，正式知識庫必須為每個 chunk 建立穩定識別碼，識別碼應可追溯至文件 ID、版本、標題路徑與內容雜湊。文件更新時，不應把所有內容無差別重新嵌入；應先辨識改動區塊、重新產生受影響 chunk、刪除舊向量，再更新關聯 metadata，避免同一條規範的新舊版本同時被召回。
權限控制必須跟著 chunk 走，而不是只保護原始檔案。若一份文件同時含公開操作流程與僅限主管閱讀的成本資料，切分後每個片段都要繼承正確的存取標籤。檢索階段依使用者身分與租戶過濾，生成階段也不得引用未授權片段，才能避免向量庫成為資料外洩的旁路。
敏感資訊遮罩要在入庫前設計，例如個資、帳號、客戶名稱與內部機密代碼，可依資料分類決定去識別、加密、排除或採取受控索引。切分時也要避免把姓名和聯絡方式分散到不同片段而漏遮罩。治理不是最後補一層權限畫面，而是從解析、chunk ID 到檢索過濾都一致。
- 以文件 ID、版本、路徑與內容雜湊管理增量更新
- 每個 chunk 都應帶有租戶、角色與敏感度標籤
- 遮罩與權限必須在入庫及檢索兩端落實
小規模 PoC 可用真實資料驗證 Go 或 No-Go，而非急著全面開發
直接答案是，企業應先選擇一個高頻、可驗證且風險可控的問答情境做 PoC，例如客服條款查詢、產品手冊協助或內部規範檢索。以實際文件、實際角色權限與實際問題測試，才能知道切分策略是否適合現場；僅用公開範例資料，很難發現內部縮寫、舊版文件與流程例外造成的問題。
ALION 的 AI PoC 開發支援強調先以最小配置驗證可行性與效益，並透過現場調查釐清真正課題。其 AI 上游工程訂閱方案為月費 20 萬日圓起，包含需求梳理、設計文件與示範製作；若後續進入正式開發，相關上游工程成果可延續使用，降低重新交接與重做的風險。
PoC 的交付物不應只有一個聊天介面，還應包含資料盤點、切分規格、題庫、評估報告、權限設計與下一步建議。若測試結果顯示資料品質不足、權限規則尚未完備，提出暫緩或縮小範圍同樣有價值。這能讓團隊以證據決定投資，而不是在大型開發後才發現基礎假設不成立。
- 選擇高頻、可驗證且可控風險的真實場景
- PoC 應交付資料規格、題庫與評估報告
- No-Go 或縮小範圍是降低投資風險的有效結論
實作工具、參考來源與導入檢查清單
工具選擇應以可觀測性與資料相容性為先
直接答案是，LangChain、LlamaIndex、Unstructured、PyMuPDF、pgvector 與各家雲端嵌入服務都可組成 RAG 管線，但工具不會自動解決資料品質。選型時應確認是否能自訂分隔符、保留 metadata、輸出穩定 chunk ID、處理非同步批次、刪除舊向量，以及記錄每次解析與嵌入的錯誤。這些能力比是否能在幾分鐘內展示聊天畫面更重要。
若以 Python 建立可重現環境，可明確鎖定相依版本，例如 langchain – community ==0.3.31、pgvector ==0.4.2、tiktoken ==0.12.0 與 sqlalchemy ==2.0.45。版本鎖定有助於避免切分器行為、token 計算或資料庫驅動變更後，讓同一批文件產生不同索引結果。
資料庫層可使用 PostgreSQL 搭配 pgvector，並為向量、全文索引與 metadata 過濾設計適當索引。無論選擇自建或雲端服務，都要將原始檔、解析後文字、chunk、嵌入向量與評估紀錄分層保存。當模型或嵌入器更換時，這能讓團隊只重建必要層，而不失去稽核與回溯能力。
- 優先確認 metadata、版本、刪除與錯誤追蹤能力
- 鎖定相依版本以維持實驗可重現性
- 原始檔、文字、chunk、向量與評估結果應分層管理
導入前應以問題清單確認切分規格是否完整
直接答案是，在正式入庫前，團隊應把切分規則寫成可審查的規格，而不是散落在程式參數中。規格需說明資料來源、解析器、標題層級、分隔符順序、最大 token、overlap、表格處理、父子節點關係、metadata 欄位、權限繼承與版本更新規則，讓業務、資安與工程人員能對同一套定義討論。
驗收時不只測「問得到答案嗎」，還要問：答案能否連回正確文件？不同權限的帳號是否只看到允許內容？文件更新後舊答案是否消失？表格數字是否含單位與有效條件？模型不確定時是否會拒答？這些問題能把抽象的可靠性要求轉成可測試案例。
若文件種類持續增加，不要為每一種來源硬塞進同一套規則。較成熟的做法是建立資料分類：一般文章採遞迴切分，政策採標題與條款切分，表格採列級結構化表示，程式碼採語法節點，掃描 PDF 則增加 OCR 品質門檻。分類清楚後，維護與迭代成本會明顯降低。
- 把切分規則文件化，供業務、資安與工程共同審查
- 驗收需涵蓋引用、權限、更新、表格與拒答行為
- 依資料類型制定規則，避免一套參數套用所有來源
可信參考來源可協助團隊持續驗證方法與實作細節
直接答案是，切分策略應持續對照原始技術文件與可重現的官方教學，而非只依社群貼文複製參數。LangChain 的文字切分文件說明遞迴與長度導向的實作概念；LlamaIndex 文件則提供節點與文件索引的設計方式。閱讀文件時，應把範例參數視為實驗起點，再用自家題庫驗證。
可參考 Anthropic 的 Contextual Retrieval 說明，了解為片段補充上下文與重排的設計思路：https://www.anthropic.com/news/contextual-retrieval 。其重點不是追逐單一百分比，而是理解為何獨立 chunk 常缺少指涉對象、文件背景與適用範圍，並將這項洞察轉換為可量測的內部實驗。
其他可靠的延伸資料包括 LangChain 文件：https://python.langchain.com/docs/concepts/text_splitters/ 、LlamaIndex 文件：https://docs.llamaindex.ai/en/stable/module_guides/loading/node_parsers/ 、Google Cloud RAG 教學：https://codelabs.developers.google.com/ 。導入時仍應檢查授權、資料傳輸位置、模型服務條款與企業資安要求。
- 以官方文件與可重現教學作為技術依據
- 將外部案例轉為內部題庫可驗證的假設
- 評估工具時同步確認授權、資料位置與資安責任
總結
做好RAG資料切分的關鍵，不是追求單一最佳 chunk size，而是依資料結構、問題型態、檢索管線與治理需求建立可驗證的設計。從固定大小建立基線，再以遞迴、語義或結構化策略改善證據完整性，配合混合檢索、重排、引用與增量更新，才能讓知識庫在真實業務情境下保持可靠。
重點整理
- 先以真實題庫衡量 Recall@K、引用正確率與答案完整性，再調整參數。
- 固定、遞迴、語義與結構化切分各有適用資料，不應以單一規則處理所有文件。
- PDF、表格、程式碼與圖片需要保留版面、欄位或節點關係。
- 權限、版本、敏感資料遮罩與刪除機制必須納入 chunk 設計。
- 以小規模 PoC 驗證品質與效益，可降低全面開發的投資風險。
若你的團隊已經有文件卻不確定該如何切分、如何驗證檢索品質，建議先挑選一個高頻場景，建立小型題庫與可比較的基線。透過實際資料測試切分、重排與權限規則，便能更有把握地判斷下一步該優化資料、調整架構，或進入正式系統開發。
常見問題 FAQ
Q1. chunk size 要設多少才適合企業 RAG？
沒有通用唯一答案。可先以 200 或 500 左右的切分設定建立基線，再以真實題庫測試召回、引用完整性、延遲與成本。若條款條件常被切開，應先改善結構邊界，再調整大小或 overlap。
Q2. RAG 一定需要語義切分嗎？
不一定。格式穩定的規範、手冊與 Markdown 文件，遞迴或結構化切分往往更容易維護；語義切分適合主題轉折較多的長篇內容。應以資料型態與題庫評估結果決定，而非預設採用最複雜的方法。
Q3. 文件更新後，需要把所有向量重新建立嗎？
不一定。若保有文件版本、內容雜湊與穩定 chunk ID，可只找出受影響片段，刪除舊向量並重新嵌入更新內容。完整重建適合嵌入模型、解析規則或切分策略大幅變更時使用。
Q4. 如何避免 RAG 回答未授權的內部資訊？
每個 chunk 都應繼承租戶、角色、文件狀態與敏感度 metadata，並在檢索前依登入身分過濾。原始文件的權限控管不足以保護已入庫的片段，生成階段也應僅使用已通過授權篩選的證據。
Q5. PoC 階段最該驗證什麼？
除了答案正確率，還要驗證正確證據是否被召回、引用是否可追溯、權限是否正確、文件更新是否同步，以及現場人員是否能理解並採用。PoC 的價值在於以真實資料為 Go、調整範圍或 No-Go 提供依據。