Day 19 整理了 Chunking 的基本概念。

我們知道文件不能直接整份丟進 RAG，而是要先切成多個 Chunk。

但接下來真正麻煩的問題是：

Chunk 到底要怎麼切？

因為切分方式不同，最後搜尋出來的結果也可能完全不同。

Chunk Size 要多大？

最基本的方法，就是設定固定的 Chunk Size。

例如每一段固定切成一定長度。

但 Chunk Size 並沒有一個所有文件都適用的標準答案。

如果內容本身比較簡單，可以切得短一點。

如果一個概念需要較完整的上下文，就可能需要比較大的 Chunk。

所以 Chunk Size 最重要的不是固定某個數字，而是：

盡量讓一個 Chunk 保留完整的意思。

Chunk Overlap 是什麼？

切割文件時，最常遇到的問題就是：

重要內容剛好被切在兩個 Chunk 中間。

所以可以使用 Chunk Overlap。

例如：

Chunk 1：A B C D

Chunk 2：C D E F

C、D 就是兩個 Chunk 重複的內容。

這樣即使重要資訊剛好落在切割邊界，也比較不容易失去上下文。

不一定要按照固定長度切

固定長度是最簡單的方法，但不一定適合所有資料。

有些文件本身就有很清楚的結構，例如：

• 標題
• 段落
• 章節
• FAQ
• 條列內容

這種情況就可以直接依照文件結構切分。

例如 FAQ：

Q：忘記密碼怎麼辦？
A：……

就很適合讓整組問答成為同一個 Chunk，而不是硬從中間切開。

這樣會比單純按照字數切分更自然。

Metadata 也很重要

每一個 Chunk 除了文字之外，也可以一起保存 Metadata。

例如：

• 文件名稱
• 章節
• 主題
• 資料來源
• Chunk ID

之後如果搜尋到某個 Chunk，系統就可以知道：

這段內容原本來自哪裡。

Metadata 也可以用來進一步篩選搜尋結果。

例如只搜尋「照護資料」，或只搜尋某一份指定文件。

不同資料可以使用不同切法

VoCare 未來可能會有不同形式的知識資料。

例如：

FAQ
適合一問一答作為一個 Chunk。

操作手冊
適合依照功能或章節切分。

長篇照護文章
可以依照段落或語意區塊切分。

所以 Chunking 不一定只能使用一套固定規則。

真正重要的是：

根據資料本身的結構選擇適合的切分方式。