首頁 / 技術文章 / RAG 內容怎麼寫：讓每個區塊被單獨檢索時仍說得清楚的寫作規則
技術文章
RAG 內容怎麼寫：讓每個區塊被單獨檢索時仍說得清楚的寫作規則
要讓文件被 RAG 切成區塊後，每一塊單獨被檢索到時仍說得清楚，作者能做的最有效動作是在寫作階段就補上上下文：每個小節開頭重述主題與適用範圍，把如上所述、此功能這類指代換成明確名詞。這正是 Anthropic 的 Contextual Retrieval 在索引階段替區塊補做的事。對內容作者來說，這比追求某個特定的區塊大小更值得投入；但要先說清楚，這些規則是從檢索機制推導出來的，還沒有經過實測。
為什麼 RAG 切出來的區塊會失去上下文
RAG 目前沒有統一的內容格式標準，但主流平台的處理流程大致相同：先把文件切成較小的區塊（chunk），再做嵌入、建索引、檢索，最後把取回的區塊放進提示。IBM Developer 的文章把這段流程拆成內容切分、向量化、向量資料庫索引、檢索與提示幾個步驟，並指出切分做得不好會讓結果變差。
切分不是可有可無的效能調整。Microsoft 的 Azure AI Search 文件說明，切分是為了讓輸入不超過嵌入模型與 chat completion 模型的 token 上限，避免內容被截斷而遺失。文件舉的例子是 Azure OpenAI 的 text-embedding-3-small，最大輸入長度為 8,191 tokens，以每個 token 約四個字元估算，大約是 6,000 個英文單字。同一份文件也提到，因為 chat completion 模型同樣有輸入限制，切分對 RAG 與 agentic retrieval 都有幫助。
問題出在切完之後。Anthropic 在說明 Contextual Retrieval 的文章中指出，傳統 RAG 在編碼資訊時會移除上下文，這常導致系統無法從知識庫檢索到相關資訊。一個區塊被切出來之後，它原本所屬的文件標題、前一節交代過的產品名稱、適用版本，都不一定還跟著它。Anthropic 的對策是在索引階段替每個區塊補上上下文說明，方法包含 Contextual Embeddings 與 Contextual BM25 兩個子技術；Anthropic 表示，這能讓檢索失敗次數減少 49%，搭配 reranking 時減少 67%。
作者端能先補上的上下文：六條寫作規則
Contextual Retrieval 是檢索端的解法，需要工程團隊改動索引流程。本站的判斷是，同一個缺口有一部分可以在寫作階段先補起來：如果每個段落本身就寫清楚主詞與適用範圍，索引時被剝掉的上下文就少了。下表列出每條規則對應的檢索端機制，並標明它屬於推導還是假設。
| 寫作規則 | 對應的檢索端機制 | 依據性質 |
|---|---|---|
| 小節第一句重述主詞、產品名與適用版本 | Anthropic 指出傳統 RAG 編碼時會移除上下文；區塊脫離原文後，只剩區塊內文字能說明它在講什麼 | 從機制推導 |
| 刪除依賴前文的指代，改成明確名詞 | 預設切分依長度而非語意切開，指代對象可能落在另一個區塊；重疊只能帶回相鄰的一小段文字 | 從機制推導 |
| 標題寫成完整的問句或陳述 | 標題若與內文落在同一區塊，是區塊內最直接的主題說明；各平台是否以 HTML 標題當切分邊界並不清楚 | 從機制推導 |
| 一個小節只處理一個問題 | Google Cloud 文件說明每個區塊的嵌入容量固定，區塊越大嵌入越籠統、可能遺漏細節 | 從機制推導 |
| 使用讀者實際會搜尋的專有名詞、型號與代碼 | Contextual BM25 的存在顯示關鍵字比對在 RAG 中仍有作用 | 假設 |
| 表格旁用一句文字寫出結論 | 表格如何被切分與嵌入在各平台並不透明，表頭可能與資料列分開 | 假設 |
規則一與二：首句重述主詞，刪除依賴前文的指代
這兩條是整套規則的核心，也最直接對應 Anthropic 描述的問題。技術文件習慣在第一節交代產品與版本，後面就用此功能、該設定、如上所述帶過；給從頭讀到尾的人看，這樣很省字，但對單獨被取出的區塊來說，這些詞沒有對象。
有人會認為區塊重疊能解決這個問題。Google Cloud RAG Engine 的預設 chunk_size 是 1,024 tokens、chunk_overlap 是 256 tokens，文件說明重疊是為了提升相關性與檢索品質。不過本站的判斷是，重疊只能讓相鄰區塊共享邊界附近的文字；如果產品名稱只在好幾段之前出現過一次，重疊也帶不回來。切分器不理解語意，作者無法保證一個段落會完整落在同一個區塊裡，比較穩妥的假設是：任何段落都可能被單獨取出。
規則三與四：標題要能單獨看懂，一節只回答一件事
像設定方式、注意事項這類標題，在目錄裡靠上下層級才有意義，被切進區塊後幾乎不提供資訊。改成如何啟用某產品企業版的離線同步，標題本身就能說明這個區塊的主題。至於一節只處理一個問題，依據是 Google Cloud 文件描述的取捨：區塊越小嵌入越精確，區塊越大越籠統。作者控制不了平台的區塊大小，但能控制一個小節裡混進多少個主題。
規則五與六：保留真實名詞，表格結論要寫成文字
這兩條的證據較弱，應視為假設。Anthropic 的方法同時處理嵌入與 BM25，顯示關鍵字比對沒有被向量檢索完全取代；據此推測，在內文直接寫出讀者會搜尋的型號、錯誤代碼與指令，而不是只用代稱，可能對兩種檢索都有利。表格則是目前最不透明的部分：研究來源沒有說明各系統是否保留表頭、是否逐列切開。如果表格真的被以固定長度切開，單一區塊可能只剩數字而沒有欄位意義，在表格前後用一句話寫出關鍵結論，可以降低這個風險。
改寫前後對照：同一段落被單獨取出時的差異
以下是一個虛構的產品說明段落。假設它被切分器單獨切成一個區塊，前面的章節都不在區塊內。
改寫前：
## 設定方式
如上所述，此功能預設為關閉。啟用後，該設定會套用到所有裝置，
但不適用於前一節提到的舊版用戶端。相關選項請參考上表。
改寫後：
## 如何啟用 Acme Sync 企業版的離線同步
Acme Sync 企業版的離線同步預設為關閉。管理員在管理後台啟用離線同步後，
這項設定會套用到組織內的所有裝置，但不適用於舊版桌面用戶端。
離線同步的可用選項只有兩個：僅同步已釘選的資料夾，或同步全部資料夾。改寫前的版本單獨閱讀時，檢索系統與模型都無從得知此功能是什麼、屬於哪個產品、舊版用戶端指哪一種，上表也很可能在另一個區塊。改寫後的版本多了二十幾個字，但產品、功能、適用對象與例外都在區塊內，使用者問到離線同步時，這段文字本身就有足夠的名詞可以被比對到。代價是全文讀起來會有些重複，這是刻意的取捨。
為什麼作者不該先追求特定的區塊大小
區塊該切多大，目前沒有一致答案。Google Cloud RAG Engine 給的是 1,024 tokens 加 256 tokens 重疊的預設值，同時說明小區塊精確、大區塊籠統的取捨；IBM 的 LangChain 教學則認為較小的區塊通常表現優於較大區塊，但這屬於教學觀點，不是規格。平台預設值是否夠好，使用者之間也有分歧：2024 年在 Microsoft Q&A 上有使用者質疑 Azure AI Search 的 Import and Vectorize 預設 skillset 會讓 RAG 表現不佳，並貼出 textSplitMode 為 pages、maximumPageLength 為 2000、pageOverlapLength 為 500 的設定。那是使用者提問，不是官方結論，產品預設也可能已經改變。
這些分歧對作者的意義很直接：區塊大小是平台與工程團隊的參數，會因嵌入模型、內容類型與實測結果而改，同一份文件可能同時被好幾套設定處理。為某個 token 數去調整段落長度，等於把寫作綁在一個隨時會變的參數上。讓每個小節自足則不依賴任何特定設定，不論區塊切在哪裡，被切出來的那一塊都比較有機會說清楚自己。Azure AI Search 提供內建的切分與向量化方案，許多團隊會直接沿用預設值，作者端的自足寫法對這類團隊尤其有用。
常見誤解
文件丟進 RAG，模型就懂每段的脈絡。Anthropic 指出傳統 RAG 在編碼時會移除上下文，這正是 Contextual Retrieval 要處理的問題。
切分只是為了效能。Microsoft 文件說明，切分是為了符合模型的輸入上限，並避免截斷造成資料遺失。
某個 token 數是標準區塊大小。各平台預設值與建議不同，沒有跨平台標準。
另一個陷阱是把這套規則直接搬到 AI 搜尋。AI 搜尋與 AEO／GEO 的引用在概念上同樣涉及先檢索片段、再生成答案，所以段落自足、主詞明確的原則可能同樣適用；但本文引用的資料只涵蓋企業自建 RAG 與雲端託管服務，沒有任何公開 AI 搜尋產品的切分或排序細節。關於 AI 搜尋如何取得與引用網頁，可參考本站對 AEO／GEO 建議官方依據的拆解，以及AI 搜尋取得網頁的四個關卡。
本文的依據與限制
本文的寫作規則全部是從檢索端機制推導出來的，研究來源沒有對任何一條做過實測，因此應視為建議，而不是已證實能提升檢索效果的結論。以下幾件事目前仍不確定：表格在各 RAG 系統中如何被切分與嵌入；作者、日期、結構化資料、meta description 等頁面層級 metadata 是否被用於檢索或排序；HTML 的 H1 到 H3 是否被內建切分器當作切分邊界；以及 Anthropic 的改善幅度在中文內容上能否複現。若團隊能取得自家 RAG 系統的檢索紀錄，最直接的驗證方式是挑一批常被問到卻檢索失敗的問題，比較段落改寫前後是否被取回。
結論：先把段落寫成能單獨成立，再談參數
Anthropic 用額外的索引步驟替區塊補上下文，代表工程端已經承認切分本身會造成資訊流失；這個步驟需要替每個區塊額外產生說明，會增加索引成本。本站的判斷是，內容團隊在寫作階段讓段落自足，成本較低，也不依賴任何平台的預設值，可以和檢索端的補強並行。接下來值得觀察的訊號有兩個：平台是否公開表格與標題階層的切分方式，以及是否有人在中文或特定領域的知識庫上，量測過自足寫法對檢索失敗率的實際影響。在這些資料出現之前，這套規則應該當作合理的預設寫法，而不是保證有效的優化手段。
常見問題
RAG 文件的區塊應該切多大？
沒有跨平台標準。Google Cloud RAG Engine 預設 1,024 tokens、重疊 256 tokens，並說明小區塊精確、大區塊籠統的取捨；IBM 教學則認為較小區塊通常表現較好。區塊大小應由工程團隊依嵌入模型、內容類型與實測結果調整，作者端更值得投入的是讓每個小節能單獨成立。
區塊有重疊，是不是就不用在每段重述主詞？
不建議這樣假設。重疊只能讓相鄰區塊共享邊界附近的文字，如果產品名稱或適用版本只在更前面出現過一次，重疊也帶不回來。在小節首句重述主詞，是不依賴任何切分設定的做法。
這些寫作規則對 AI 搜尋和 GEO 也有效嗎？
可能適用，但無法確認。AI 搜尋在概念上同樣涉及檢索片段再生成答案，不過目前沒有公開 AI 搜尋產品的切分或排序細節，不能把企業 RAG 平台的參數直接套用到 AI 搜尋上。
表格在 RAG 裡會被怎麼處理？
目前不透明，研究來源沒有說明各系統是否保留表頭或逐列切開。比較保守的做法是在表格前後用一句文字寫出關鍵結論，這樣即使表頭與資料列被切開，結論仍在文字區塊內。
資料來源
- Contextual Retrieval
- Chunk large documents for vector search
- Fine-tune RAG transformations
- why does the default chunking algorithm used by az
- Enhance RAG performance through intelligent chunking strategies
- Implement RAG chunking strategies with LangChain and watsonx.ai
- vector search how to chunk documents