RAG技術(shù)落地的兩個問題及應(yīng)對策略
什么是RAG？
RAG的全稱是檢索增強(qiáng)生成（Retrieval-Augmented Generation，簡稱RAG），它結(jié)合了檢索和和生成技術(shù)，通過整合檢索系統(tǒng)和生成模型的優(yōu)勢，來提升模型生成文本的質(zhì)量和上下文相關(guān)性。這種技術(shù)主要是為了解決生成式模型在面對需要具體、實時或領(lǐng)域?qū)I(yè)知識時可能產(chǎn)生的準(zhǔn)確性不足和上下文不敏感的問題。
即它先根據(jù)外部知識庫搜索到的信息來作為上下文，再來輔助模型回答問題，使得模型的回答更準(zhǔn)確。
比如你想做一個智能助手，當(dāng)用戶提出一個問題時，需要在你給的知識庫里面先搜索出文檔片段，然后再把文檔片段和用戶問題一起丟給大模型，讓模型去回答問題，這樣的話模型就可以回答的更有針對性和準(zhǔn)確性。這一定程度上可以解決大模型幻覺的問題。在之前的文章介紹過用RAG的技術(shù)來做智能問答 使用Dify 構(gòu)建國土空間規(guī)劃智能問答應(yīng)用
標(biāo)準(zhǔn)RAG流程主要由三部分組成：
索引（向量嵌入），通過嵌入模型實現(xiàn)文本塊的向量編碼，寫入向量數(shù)據(jù)庫。
檢索（相似查詢），通過嵌入模型服務(wù)實現(xiàn)問題查詢的向量編碼，使用相似性查詢檢索到相關(guān)片段。
生成，將檢索到的片段結(jié)果作為上下文和問題一起提交給大模型處理。
圖片
我這次碰到的兩個問題是在向量嵌入之前，一是對PDF掃描件的處理，二是文本分段。
01 PDF掃描件處理問題
還是先拿dify知識庫來測試給大家看看
這是原文件，是一個掃描件
圖片
上傳到dify，發(fā)現(xiàn)文本分段環(huán)節(jié)分不出來段落，失敗了，不支持PDF掃描件。
圖片
于是對比測試下別的平臺
打開阿里云百煉，發(fā)現(xiàn)是可以正常分段的。
圖片
試試 RAGFlow，也是可以的。
圖片
這兩家知識庫系統(tǒng)都預(yù)置了OCR的功能，先用OCR做了提取處理，再執(zhí)行分段、嵌入的過程。
上周階躍星辰開源了他們的OCR產(chǎn)品：GOT-OCR2_0，我們可以來試試，還是剛剛的文件，轉(zhuǎn)成圖片格式上傳。效果如下~
圖片
在政府或者企業(yè)內(nèi)部落地智能問答場景時，存在大量的PDF掃描件，當(dāng)然我們可以先對掃描件做轉(zhuǎn)換處理，再上傳到知識庫中。但如果知識庫預(yù)置OCR功能，在上傳掃描件時可以直接進(jìn)行處理，還是蠻實用的一個功能。
02 文本分段問題
事情的起因為某用戶在使用我們的智能問答產(chǎn)品時，問了一個問題
圖片
下面是我們助手的回答
圖片
下圖是正確的答案，可以看出明顯回答得不正確。
圖片
于是去dify知識庫排查，發(fā)現(xiàn)知識庫中是有這個文件的，但就是問不出來。根據(jù)前面RAG的流程，猜測可能是分段導(dǎo)致的問題，一看果然是因為之前上傳該文件到知識庫，是機(jī)械的按照字?jǐn)?shù)進(jìn)行的分段，從而導(dǎo)致沒有召回相關(guān)的片段。
當(dāng)然dify是提供了自定義選項的，但分段標(biāo)識符還挺難設(shè)置的，常見的可能設(shè)置成句號、問號、感嘆號啥的，但文檔的自然分段多種多樣，如使用數(shù)字標(biāo)識段落
- 段落一
- 段落二
使用章節(jié)標(biāo)識符
- 第1章：標(biāo)題
- 1.1 子標(biāo)題
- 1.1.1 段落
于是去扣子上搭建一個智能問答應(yīng)用來做對比測試。
先創(chuàng)建知識庫，上傳基本農(nóng)田政策文件《自然資源部關(guān)于做好占用永久基本農(nóng)田重大建設(shè)項目用地預(yù)審的通知》，可以看到扣子知識庫對上傳的文件做了比較好的分段，即按照段落進(jìn)行分段，更符合原文的意思，不會把一個段落內(nèi)容機(jī)械的按照字?jǐn)?shù)分割成不同的段落，從而造成檢索時檢索不全或者檢索不到的問題。
圖片
回答效果還可以。
圖片
阿里云百煉平臺對文檔切分提供智能切分和自定義切分兩種方式
圖片
智能切分對文本分段的效果是非常好的，基本上實現(xiàn)了按原文段落進(jìn)行分段。
圖片
圖片
百度千帆大模型平臺：
圖片
罷了罷了，操作還是這么復(fù)雜，體驗還是這么糟糕，還是熟悉的百度。
圖片
RAGFlow：
圖片
QAnything：
沒把分塊展示出來，上傳文件以后直接提問
圖片
回答的內(nèi)容重復(fù)了。
圖片
測試對比了dify、扣子、阿里云百煉、百度千帆、RAGFlow、QAnything等知識庫產(chǎn)品,有開源的、有商業(yè)，有大廠的，有小廠的，總的來說阿里云百煉對分段處理得最好。
dify知識庫一些功能還是做得不錯的，比如引入混合檢索和重排序，要是引入OCR和智能分段，那就更好了。
最近Anthropic分享RAG最佳實踐，提到了一種新的文檔分塊的方式，因為傳統(tǒng)的RAG系統(tǒng)有一個顯著的限制：它們經(jīng)常破壞上下文，就算是智能分段，有些信息還是需要結(jié)合上下文來理解才更準(zhǔn)確。
現(xiàn)在通過在嵌入之前將塊特定的解釋性上下文附加到每個塊之前（“上下文嵌入”）和創(chuàng)建BM25索引（“上下文BM25”）來解決這個問題，再結(jié)合重排序來降低檢索的失敗率。大家有興趣可以看看他們的實驗。
標(biāo)準(zhǔn)RAG流程
上下文嵌入+BM25索引+重排序
小結(jié)：在使用RAG技術(shù)落地智能問答助手過程中，不管是使用開源、商業(yè)平臺、還是自研，引入OCR的能力和智能分段都是重要和實用的功能。
參考資料
引入混合檢索（Hybrid Search）和重排序（Rerank）改進(jìn) RAG 系統(tǒng)召回效果
Anthropic分享RAG最佳實踐：Contextual Retrieval！
登頂Hugging Face總榜，創(chuàng)始人Clem點(diǎn)贊轉(zhuǎn)發(fā)，OCR-2.0火了！
本文轉(zhuǎn)載自微信公眾號「AI 思與行」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系A(chǔ)I 思與行公眾號。
