“ 知識庫是RAG的靈魂，一個好的知識庫能解決絕大部分RAG問題?！?/strong>

在之前關于RAG的優化文章中，大部分都是在強調檢索端的優化，而關于文檔解析方面的內容卻非常的少，而這也是有原因的。

在之前介紹RAG的文章中，曾說過RAG是一種方法論，而不是一項具體的技術；其中有兩個比較重要的模塊：

• 其一是與大模型相關的上下文管理
• 其二是文檔召回模塊

其中文檔召回模塊又分為兩大塊，一塊是知識庫的構建，另一塊是檢索召回；而之前的文章主要就是針對檢索召回和上下文管理。

而今天所討論的文檔解析，就屬于知識庫的構建，而這也是RAG系統好與壞的基石；一個好的知識庫是RAG系統的基礎，否則所謂的增強生成只能是空中樓閣。

因為，任何RAG相關的應用場景，在檢索召回和上下文管理功能都可以進行復用；或者準確地說，RAG的檢索召回和上下文管理的手段就只有這么多。但文檔解析卻不同，其需要根據不同的業務場景，數據格式進行特殊的處理，而這也是最難搞定的一環。

文檔解析

為什么文檔解析會那么難？

主要原因就在于文檔格式和結構太復雜，特別是現在的富文本，同時包含圖片，文字，表格等多種格式的數據；而如果只是格式種類比較多還問題不大，主要是文檔內容多結構。

舉例來說，你的文檔是一個技術架構圖，或者流程圖等帶有結構的數據，這時候你不論選擇什么技術都很難進行處理。

以現在常見的OCR技術來說，雖然OCR能夠識別出文檔中內容，也就是信息；但是它識別不出來文檔內容中的結構信息。

從作者個人的體驗來看，除了純文字的文檔之外，任何帶有結構化信息的文檔，經過OCR處理之后，文檔中的結構化信息全部丟失，而這對構建知識庫來說會產生非常大的影響，甚至會直接導致有些文檔完全無效，還不如不要。

所以在RAG中，文檔處理的核心主要有以下三點：

• 提取關鍵信息
• 保留文檔結構
• 保證文本質量

提取關鍵信息

保證文檔中重要的數據內容都能被提取出來

保留文檔結構

要保證文檔的結構，如標題，段落，表格等；因此，作者在處理的過程中，會在每段拆分的文檔前面拼接上其上層標題。

保證文本質量

有些人在使用文檔格式轉換工具或OCR工具之后，就直接把轉換之后的文檔切分并入庫；但事實上這樣的文檔內容質量會非常差，原因就在于其中會存在很多噪音數據。

如圖片，結構圖，表格分隔符等，會占用大量的無效空間，導致文檔質量直線下降；而這些噪音數據又很難處理，特別是在文檔量比較大的情況下。一般情況下只能根據規則或正則表達式對內容進行適當的刪除和處理。

因此，在RAG中知識庫的構建，也就是文檔的處理需要花費大量的時間和精力；然后根據不同的業務場景，選擇合適的文檔格式和結構，并且選擇合適的存儲工具；如傳統數據庫，向量數據庫，知識圖譜等。

?

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