“ RAG系統中，高質量的文檔處理才是RAG系統的核心。”

手上有一個基于自然語言對話的系統，其功能就是根據提供的文檔，能通過自然語言對話的方式去詢問需要的文檔和資料；其本質上來說就是一個RAG系統。

在之前一直強調說，RAG開發是一個入門五分鐘，但要做好可能要五個月，甚至更久的一項技術；在之前對這句話還沒有特別深刻的體會，但經過這個項目算是深有體會了。

RAG功能優化

剛開始做這個項目的時候，覺得技術比較簡單；就是把文檔切片，然后通過embedding模型向量化之后，保存到向量數據庫中；然后使用同樣的embedding模型對用戶問題進行向量化，然后使用向量計算的方式，匹配相似度，再通過rerank重排序的方式檢索相關的文檔。

這一套操作下來，雖然完整的實現了一個RAG功能；但這僅僅只是把這個RAG系統給做了出來，還遠遠算不上做好。

為什么這么說？

原因就在于經過實際測試之后發現，RAG系統的整體效果還不太滿意，有些問題文檔里明明有，但召回的時候卻召不回來。最后經過檢查發現，原因基本上都出在文檔處理上。

為什么會出現這種情況？

其實從實際的開發經驗來看，目前大模型應用，模型的能力已經可以說是很強了；甚至遠遠超過我們很多人的預料。但很多時候問題就出在我們的數據處理上，針對RAG系統來說就是文檔的前期處理上。

所以，只是把整個RAG流程跑通，這僅僅只是第一步；而比較難得是怎么把RAG做好，有更快更準確的召回效率。

以個人遇到的實際問題為例，針對一個word文檔，由于其處理起來比較復雜，因此我們一般采用兩種方式進行處理；一種是通過OCR技術，把word文檔轉換成純文本的markdown文檔，如果word文檔中存在大量的圖片或架構數據，那么文檔的處理質量相對會比較差。

還一種方式更粗暴，更簡單，直接找一個開源的文檔處理工具，把word文檔轉換成markdown文檔；其圖片或架構圖數據直接給丟掉。

之后，再整體針對markdown文檔進行處理；比如說根據markdown文檔標題進行分段，然后每段都帶上其上層標題的內容，以此來增加檢索召回的準確度。

雖然這種通用的處理方式能夠快速處理文檔，但由于文檔拆分的不夠詳細，就導致部分內容無法召回。

比如說，一個段落大概在三百到五百個中文字符，但用戶的問題可能只有幾個字；這樣對召回精度來說是遠遠不夠的；但如果拆分的太細，也會導致召回的數據條數太多，最后會被重排序或其它過濾方式給過濾掉。

而且，從實際的開發角度來說，設計向量庫表結構時，只會把需要相似度檢索的數據放到一兩個或兩三個字段中，然后根據這些字段進行檢索；但實際開發中，我們的文檔數據并不都是標準的word或markdown格式，也可能是excel，csv等結構化數據，亦或者是其它類型的數據。

這時怎么把這些數據使用合理的數據格式或結構進行存儲，也是一個需要考慮的問題；原因就在于你不可能把不同的數據格式單獨建一個字段進行保存，或者單獨建一個向量表保存，原因就在于太麻煩，數據太分散。

所以，我們目前的處理方式是不論是word文檔，還是excel文檔，都把它轉化成markdown格式進行存儲和向量化；然后再通過相似度檢索的方式進行匹配。

總之，在RAG系統中文檔處理是重中之重，而且需要根據不同的文檔格式和內容進行不同的處理；只有這樣才能不斷提升RAG的檢索準確性，否則RAG就失去了應有的意義。

本文轉載自??AI探索時代?? 作者：DFires