“ RAG技術成本最低的方式就是把非結構化文檔轉換成markdown格式進行處理 。”

在大模型應用領域中——RAG技術應該屬于一項基礎技術，不論做什么業務基本都離不開RAG的存在；但RAG技術屬于典型的入門五分鐘，想做好卻需要花費大量時間和精力，以及成本。

所以，今天我們就來討論一下RAG技術在企業應用中的解決方案，既要考慮技術問題，也要考慮成本問題。

怎么做好RAG

RAG技術從整體上來說主要分為兩塊，一塊是文檔預處理，也就是把文檔處理成向量格式，但需要盡量保證文檔的語義完整性；其次，就是檢索召回，具體要求是能快速并準確地召回需要的數據。

但從實踐的角度來看，目前對RAG影響最大的是第一步——文檔預處理，文檔處理的質量越高，召回的精準度就越高。其實這一點也很好理解，在一個有完善管理系統的圖書館里找書，肯定會比在一堆沒人管理的書堆里找書要快，要好。

那在文檔預處理這塊，主要存在的難點是什么？

在文檔處理領域，主要存在兩種數據形式，結構化數據和非結構化數據；結構化數據主要以excel這種二維表的形式存在，其處理起來相對比較簡單；而非結構化數據的格式就比較多，并且比較混亂，比如說txt，word，pdf，markdown，ppt等多種形式。

結構化數據今天我們就不討論了，因為其比較簡單；所以，我們今天主要討論的是非結構化數據，就以word文檔為例。

由于大模型有窗口上下文長度限制，并且從成本的角度考慮；文檔處理首先需要進行文檔切分，把文檔按照長度，段落或其它方式拆分成多個小段。

但非結構化文檔拆分的難點是其文檔的結構，以word文檔為例；文檔內容可以是文字，圖片，表格，結構圖，架構圖等多種形式。由于其文檔的復雜性，就導致其文檔處理起來相對比較復雜。

原因就在于，對人類來說，文檔中的文字，圖片和表格很好區分，但對大模型來說怎么區分那些是文字，那些是圖片，那些是表格就有相當大的挑戰性。雖然說現在有了多模態模型的存在，可以部門解決這個問題，但不論從成本，還是處理速度，亦或者是效果來看，都有點差強人意。

在文檔中文字和圖片需要分開進行處理，對長表格來說也需要保證表格的完整性；并且，要保證拆分之后的文檔存在一定的關聯性，否則很容易導致驢頭不對馬嘴。

舉例來說，一個技術文檔，一個運營文檔，可能都存在前言，介紹這種段落；而在文檔拆分之后，需要分清楚，那些段落是屬于技術文檔的，那些段落屬于運營文檔。

所以面對這種問題，目前比較好的解決方案是把這些文檔轉換成markdown格式；原因在于，雖然markdown文檔也是非結構化數據，但markdown又一套屬于自己的規范，比如說用一到多個#可以表示多個層級；也就是說markdown文檔屬于非結構化文檔中，相對比較結構化的文檔格式，這也是為什么目前各大模型廠商的前端展示格式主要以markdown為主。

在處理markdown文檔時，可以把拆分的每段文檔都帶上其上級標題；比如說，一個RAG的技術文檔，一級標題是RAG解決方案，二級標題可以是文檔拆分，文檔向量化，文檔召回等等；當然，也可以根據不同的需要，存在三級標題，四級標題等等。

這樣每個拆分的段落都攜帶上層一級或多級標題，這樣就可以盡量保證每段文檔的關聯性。

然后在具體處理時，就可以根據段落進行向量化，如果段落超長，則可以對段落進行再次拆分，但一定要帶上其上級標題。

而至于文檔中存在的圖片和表格，也需要進行特殊的處理，對表格來說主要是保證表格數據的完整性，在非長表格的情況下，盡量不要對表格數據進行拆分；而對于圖片格式，可以使用OCR技術，讀取圖片中的數據并轉換成文字，但這種處理方式會導致架構圖，流程圖等失去其本身的邏輯結構。

當然，也可以使用多模態模型或其它方式進行處理，但其整體上來看，效果不是特別好，但成本又特別高，并不是一個好的選擇。

所以，在RAG中最好盡量避免處理帶圖片的文檔，很多時候處理不好，反而會降低文檔本身的質量，污染正常的文本數據，導致召回效果變差。

最后，需要注意的是RAG增強檢索，并不限制文檔數據的來源，也不一定非要使用向量檢索；傳統的數據檢索技術同樣可以應用于RAG技術中；在某些大數據量處理的RAG系統中，傳統的檢索技術依然占據著主導地位，原因就在于基于向量檢索的速度問題，相對于傳統檢索方式會更慢。

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