“ 想做一個(gè)RAG項(xiàng)目很容易，但要想做好一個(gè)RAG系統(tǒng)卻很難。”

最近手上的一個(gè)RAG聊天類項(xiàng)目也算接近了尾聲，雖然從功能上來說項(xiàng)目已經(jīng)完成了；但從質(zhì)量上來看，其實(shí)離真正的完成還差了老大一截，原因就是做出來了，但沒做好。

因此，今天我們就來基于這個(gè)項(xiàng)目做一個(gè)基本的項(xiàng)目總結(jié)，看看在一個(gè)企業(yè)級(jí)RAG系統(tǒng)中，到底存在哪些問題，以及應(yīng)該怎么做。

企業(yè)級(jí)RAG

還是那句話，RAG從技術(shù)的角度來看主要是三個(gè)部分：

1. 文檔預(yù)處理

2. 文檔召回

3. 生成增強(qiáng)

所以，我們就從這三個(gè)角度來看一下在真正的企業(yè)級(jí)項(xiàng)目中應(yīng)該怎么做。

文檔預(yù)處理

文檔預(yù)處理一直都是RAG系統(tǒng)中的一個(gè)技術(shù)難點(diǎn)，原因就在于無格式的復(fù)雜文檔處理；典型的就是word，pdf這種圖文表混合的文檔，目前為止還沒有一個(gè)很好的解決方案。

但技術(shù)的發(fā)展是一個(gè)線性的過程，并不能因?yàn)榇嬖趩栴}就不管了；因此，面對(duì)這種問題我們需要在貼合業(yè)務(wù)場(chǎng)景的前提下，盡量的把這些存在問題的影響降到最低。

在這里我們需要強(qiáng)調(diào)，也是需要注意的一件事；文檔預(yù)處理之前一定要搞明白你的業(yè)務(wù)場(chǎng)景，不同的業(yè)務(wù)場(chǎng)景對(duì)文檔處理的要求也不盡相同；比如說你是業(yè)務(wù)咨詢類場(chǎng)景，這時(shí)你可能主要需要的是一些文字描述類文檔；而如果你是技術(shù)咨詢類場(chǎng)景，可能還需要大量的架構(gòu)圖，方案設(shè)計(jì)等。

前者我們可能只需要使用ocr技術(shù)或者直接把文檔中的圖片給丟掉即可；而后者可能需要使用多模態(tài)技術(shù)，把文檔中的圖 文 表給摳出來，然后進(jìn)行混合檢索和回答。

再說文檔格式的問題，在真實(shí)的業(yè)務(wù)場(chǎng)景中，文檔的來源很復(fù)雜包括線下文檔word，pdf，excel，txt等常見文檔，以及線上文檔數(shù)據(jù)庫(kù)，API等；數(shù)據(jù)格式也多種多樣，因此需要有一個(gè)統(tǒng)一的文檔格式來承載這些不同的文檔數(shù)據(jù)，只有這樣才能方便我們統(tǒng)一進(jìn)行管理和預(yù)處理。

畢竟對(duì)于檢索召回端來說，文檔預(yù)處理屬于前置流程，其對(duì)檢索召回是無感的；所以，在文檔預(yù)處理時(shí)只需要按照要求的文檔格式進(jìn)行處理，那么就可以完全做到文檔處理和召回的分離，減少系統(tǒng)的耦合性。

比如作者在項(xiàng)目中就是把所有格式的文檔都處理成markdown格式，這樣就可以進(jìn)行統(tǒng)一的管理和向量化。

當(dāng)然這里文檔轉(zhuǎn)換成markdown格式，并不是直接把原文檔簡(jiǎn)單轉(zhuǎn)換成markdown即可；而是需要對(duì)原文檔進(jìn)行清洗，梳理，刪除一些無用和不規(guī)范的內(nèi)容，盡量讓markdown文檔變得緊湊，舍棄部門全而不精的內(nèi)容。

并且，可以對(duì)處理之后的markdown文檔進(jìn)行總結(jié)提煉——summary，以及提取標(biāo)簽；這樣在檢索端就可以使用標(biāo)量召回和相似度召回，提升召回率。

文檔召回

在第一步文檔處理過程中，我們?cè)诒M可能保證文檔質(zhì)量的前提下，第二步要關(guān)注的就是文檔召回的方式問題了。

在文檔召回過程中，我們首先需要對(duì)用戶的問題進(jìn)行處理；這里的處理包括問題的完善和優(yōu)化，提出相似子問題，以及最后的兜底問題等。

原因主要在于，用戶在提出問題時(shí)除非特別專業(yè)或了解相關(guān)內(nèi)容；否則很多情況下，用戶自己可能都不知道到底應(yīng)該怎么提問題，以及問題中會(huì)存在語義不通順，錯(cuò)別字等情況。所以，對(duì)問題進(jìn)行改寫優(yōu)化，并從多個(gè)維度提出幾個(gè)相似性問題，有助于提高召回率。

其次，可以根據(jù)用戶的問題提取標(biāo)簽，這樣就可以根據(jù)這些標(biāo)簽進(jìn)行標(biāo)量檢索，這樣能夠大大提升準(zhǔn)確率以及查詢效率；畢竟簡(jiǎn)單的字符匹配相對(duì)應(yīng)向量計(jì)算要快得多。

之后，通過多種方式召回?cái)?shù)據(jù)之后，最后需要對(duì)召回的數(shù)據(jù)進(jìn)行去重，排序等操作；把相似度最高的數(shù)據(jù)丟給大模型，而不是把召回的所有數(shù)據(jù)都丟給大模型。

生成增強(qiáng)

在完成數(shù)據(jù)召回之后，并不是說這些數(shù)據(jù)就直接丟給大模型，我們還需要對(duì)這些數(shù)據(jù)進(jìn)行處理；否則會(huì)存在很多問題。

比如說，你最終召回的數(shù)據(jù)是一個(gè)文檔列表，我們是否能夠先把這個(gè)文檔列表轉(zhuǎn)換成一段完整的文檔；而不是一段一段好像無關(guān)的文檔列表。

其次，由于模型上下文窗口有限，特別是在多輪對(duì)話中，我們可能還需要對(duì)召回的文檔進(jìn)行提煉總結(jié)之后再丟給模型；以及對(duì)歷史記錄進(jìn)行壓縮；一是為了防止上下文超長(zhǎng)導(dǎo)致內(nèi)容丟失，二是上下文過長(zhǎng)會(huì)導(dǎo)致模型處理質(zhì)量下降。

最后，在一些業(yè)務(wù)場(chǎng)景中，可能還需要給用戶展示參考文檔，以及源文檔；這時(shí)我們還需要處理好文檔的格式，否則給用戶看到一堆沒有格式的亂七八糟的內(nèi)容，也會(huì)影響用戶體驗(yàn)。

本文轉(zhuǎn)載自???AI探索時(shí)代??? 作者：DFires