當我們興沖沖地將整份業務規範或法律條文塞給 AI 時，往往會迎來一記重錘：AI 雖然「讀」完了文件，卻經常給出張冠李戴的引用，甚至分不清楚新舊版本的規定，將早已失效的門檻當成現行標準。這類痛點的根源在於我們對待知識的方式——AI 的回答品質並不取決於它讀了多少字數，而在於我們如何幫它「切分」知識。如果切分邏輯錯誤，再強大的 LLM 也只是在垃圾堆中翻找答案。

1. 切塊的重點不是「切」，而是「你是誰？」

在設計知識切塊模型（Knowledge Schema）時，核心的架構哲學應是：「身分證欄位比內容欄位多」。

在一個專業的 KnowledgeChunk 設計中，13 個欄位裡與內容直接相關的（如編號、序、標題、內容文字）僅佔 4 個，而其餘的 9 個欄位——包含版本編號、生效區間、適用範圍與來源——才是這份知識的靈魂。這關乎到知識可追溯性（Knowledge Traceability）。

塊的價值一半在於內容本身，另一半則在於「它知道自己是誰」。如果缺乏這些元數據（Metadata），當檢索層命中資訊時，系統將無法判斷該資訊是否具備時效性或適用性。一旦忽視這一點，知識就會發生「身分證走散」的慘劇，導致 Day 17 提到的「200 萬教訓」在檢索層重演——讓系統在錯誤的時間點引用了正確的文字，造成不可挽回的業務風險。

2. 通用切塊器是法律條文的「絞肉機」

許多開發者傾向使用「固定字數」的通用切塊器（例如每 300 字切一塊），但這對於結構嚴謹的文件來說簡直是一場災難。

在我的實務測試中，一份包含 14 條條文的規範，若交給通用切塊器處理，最後會被強行裝進 3 個「混裝箱」裡。這導致了嚴重的後果：一塊之中混雜了 5 條功能迥異的條文。對於散文而言，300 字可能是合理的粒度，但對於法規條文，這種做法會讓模型無法精準定位引用來源。

> 「通用切塊器」在處理結構化文件時，就像是一台絞肉機，將原本清晰的邏輯層級攪碎。這導致模型在檢索時只能模糊地說「規範裡有寫」，卻無法提供任何精確的法律依據。

為了維持內容完整性（Contextual Integrity），正確的策略應採取「結構分流」：

• 條文類文件： 堅持「一條一塊」，並重用差異引擎中的 CLAUSE_PATTERN 正則表達式，確保系統內外對「條」的定義始終如一。此外，章標題不應獨立成塊，而應併入所屬條文的脈絡行中。
• FAQ 類文件： 採取「整份一塊」，因為問答對一旦拆開就會徹底失去原有的語意脈絡。
• 無結構文字： 僅在最後的保底方案中才使用段落聚合法。

這是一個血淋淋的教訓：正確的切塊粒度是由「文件結構」決定的，而非字數。

3. 當兩個「第 3 條」同時存在：生效日期的精準決斷

在法規頻繁更新的環境下，系統常需同時處理多個版本（例如 v1.2 與 v1.3）。當檢索命中兩個「第 3 條」時，內容可能分別寫著舊版的 500 萬與新版的 300 萬。

這種決斷不該交給 AI 去通靈，而應在檢索層（Retrieval Layer）就完成過濾。透過切塊引擎的「確定性計算」，確保同一份文件永遠產生同樣的塊，並讓每一塊都精確繼承母文件的「生效區間」。在檢索時，系統會根據身分證上的日期進行硬性過濾，確保端給 LLM 的條文是唯一的現行標準。這種架構上的穩定性，是 RAG 系統從實驗室走入生產環境的關鍵門檻。

4. 沒接電的紅線：樣式常數不等於規則

在技術實作中，最危險的往往是那些看起來已經完成、實則虛有其表的防禦機制。

以 chunk_id 的格式樣式（如 KB-000-C00）為例，開發者往往會將其定義為常數放在程式頂端。然而，如果沒有撰寫對應的校驗器（field_validator），這些格式就只是毫無約束力的「裝飾品」。當非法的編號進入系統時，由於缺乏攔截機制，錯誤會一路滲透到資料庫深處。

> 「所有紅線裡最容易被跨過的，是沒有接電的那條。」

這是一個重複發生的錯誤（如同 Day 12 的教訓）：沒有接上 validator 的樣式常數，就是一條沒接電的紅線。作為系統架構師，我們必須確保定義的規則與程式邏輯緊密接軌，不讓任何非法數據汙染知識地基。

結語：通往 RAG 的下一站

透過上述的結構化切塊策略，我們成功將 8 份虛擬知識文件精準轉化為 34 個具備完整「身分證」的知識塊，並通過了 10 項嚴苛的新功能測試（全系統累計 156 項測試通過）。

這不僅是數據的處理，更是為 AI 打下穩固的認知地基。當我們邁向下一階段的檢索與生成時，必須思考一個核心挑戰：當 AI 找不到相關依據時，它是否具備「敢說不知道」的勇氣？這種判斷力並非模型天生具備，而是取決於我們今日為它建立的知識結構是否足夠精確且具備可追溯性。

影片說明