最近在公司完成了一個內(nèi)部知識問答應(yīng)用，實現(xiàn)流程很簡單，實際上就是Langchain那一套：

對文檔進行切片

將切片后的文本塊轉(zhuǎn)變?yōu)橄蛄啃问酱鎯χ料蛄繋熘?/p>

用戶問題轉(zhuǎn)換為向量

匹配用戶問題向量和向量庫中各文本塊向量的相關(guān)度

將最相關(guān)的Top 5文本塊和問題拼接起來，形成Prompt輸入給大模型

將大模型的答案返回給用戶

具體可以參考下圖，

這個流程的打通其實特別容易，基本上1天就能把架子搭起來，然后開發(fā)好了API對外服務(wù)。并且在嘗試了幾個通用的文檔后，覺得效果也不錯。

但是，當(dāng)公司內(nèi)部真實文檔導(dǎo)入之后，效果急轉(zhuǎn)直下。

當(dāng)時初步分析，有以下幾個原因：

1. 文檔種類多

有doc、ppt、excel、pdf，pdf也有掃描版和文字版。

doc類的文檔相對來說還比較容易處理，畢竟大部分內(nèi)容是文字，信息密度較高。但是也有少量圖文混排的情況。

Excel也還好處理，本身就是結(jié)構(gòu)化的數(shù)據(jù)，合并單元格的情況使用程序填充了之后，每一行的信息也是完整的。

真正難處理的是ppt和pdf，ppt中包含大量架構(gòu)圖、流程圖等圖示，以及展示圖片。pdf基本上也是這種情況。

這就導(dǎo)致了大部分文檔，單純抽取出來的文字信息，呈現(xiàn)碎片化、不完整的特點。

2. 切分方式

如果沒有定制切分方式，則是按照一個固定的長度對文本進行切分，同時連續(xù)的文本設(shè)置一定的重疊。

這種方式導(dǎo)致了每一段文本包含的語義信息實際上也是不夠完整的。同時沒有考慮到文本中已包含的標題等關(guān)鍵信息。

這就導(dǎo)致了需要被向量化的文本段，其主題語義并不是那么明顯，和自然形成的段落顯示出顯著的差距，從而給檢索過程造成巨大的困難。

3. 內(nèi)部知識的特殊性

大模型或者句向量在訓(xùn)練時，使用的語料都是較為通用的語料。這導(dǎo)致了這些模型，對于垂直領(lǐng)域的知識識別是有缺陷的。它們沒有辦法理解企業(yè)內(nèi)部的一些專用術(shù)語，縮寫所表示的具體含義。這樣極大地影響了生成向量的精準度，以及大模型輸出的效果。

4. 用戶提問的隨意性

實際上大部分用戶在提問時，寫下的query是較為模糊籠統(tǒng)的，其實際的意圖埋藏在了心里，而沒有完整體現(xiàn)在query中。使得檢索出來的文本段落并不能完全命中用戶想要的內(nèi)容，大模型根據(jù)這些文本段落也不能輸出合適的答案。

例如，用戶如果直接問一句“請給我推薦一個酒店”，那么模型不知道用戶想住什么位置，什么價位，什么風(fēng)格的酒店，給出的答案肯定是無法滿足用戶的需求的。

問題解決方法

對于以上問題，我采取了多種方式進行解決，最終應(yīng)用還是能夠較好的滿足用戶的需求。

1. 對文檔內(nèi)容進行重新處理

針對各種類型的文檔，分別進行了很多定制化的措施，用于完整的提取文檔內(nèi)容。這部分基本上臟活累活，

Doc類文檔還是比較好處理的，直接解析其實就能得到文本到底是什么元素，比如標題、表格、段落等等。這部分直接將文本段及其對應(yīng)的屬性存儲下來，用于后續(xù)切分的依據(jù)。

PDF類文檔的難點在于，如何完整恢復(fù)圖片、表格、標題、段落等內(nèi)容，形成一個文字版的文檔。這里使用了多個開源模型進行協(xié)同分析，例如版面分析使用了百度的PP-StructureV2，能夠?qū)?a href="http://www.www27dydycom.cn/tags/te/" target="_blank">Text、Title、Figure、Figure caption、Table、Table caption、Header、Footer、Reference、Equation10類區(qū)域進行檢測，統(tǒng)一了OCR和文本屬性分類兩個任務(wù)。

PPT的難點在于，如何對PPT中大量的流程圖，架構(gòu)圖進行提取。因為這些圖多以形狀元素在PPT中呈現(xiàn)，如果光提取文字，大量潛藏的信息就完全丟失了。于是這里只能先將PPT轉(zhuǎn)換成PDF形式，然后用上述處理PDF的方式來進行解析。

當(dāng)然，這里還沒有解決出圖片信息如何還原的問題。大量的文檔使用了圖文混排的形式，例如上述的PPT文件，轉(zhuǎn)換成PDF后，僅僅是能夠識別出這一塊是一幅圖片，對于圖片，直接轉(zhuǎn)換成向量，不利于后續(xù)的檢索。所以我們只能通過一個較為昂貴的方案，即部署了一個多模態(tài)模型，通過prompt來對文檔中的圖片進行關(guān)鍵信息提取，形成一段摘要描述，作為文檔圖片的索引。效果類似下圖。

2. 語義切分

對文檔內(nèi)容進行重新處理后，語義切分工作其實就比較好做了。我們現(xiàn)在能夠拿到的有每一段文本，每一張圖片，每一張表格，文本對應(yīng)的屬性，圖片對應(yīng)的描述。

對于每個文檔，實際上元素的組織形式是樹狀形式。例如一個文檔包含多個標題，每個標題又包括多個小標題，每個小標題包括一段文本等等。我們只需要根據(jù)元素之間的關(guān)系，通過遍歷這顆文檔樹，就能取到各個較為完整的語義段落，以及其對應(yīng)的標題。

有些完整語義段落可能較長，于是我們對每一個語義段落，再通過大模型進行摘要。這樣文檔就形成了一個結(jié)構(gòu)化的表達形式：

3. RAG Fusion

檢索增強這一塊主要借鑒了RAG Fusion技術(shù)，這個技術(shù)原理比較簡單，概括起來就是，當(dāng)接收用戶query時，讓大模型生成5-10個相似的query，然后每個query去匹配5-10個文本塊，接著對所有返回的文本塊再做個倒序融合排序，如果有需求就再加個精排，最后取Top K個文本塊拼接至prompt。

實際使用時候，這個方法的主要好處，是增加了相關(guān)文本塊的召回率，同時對用戶的query自動進行了文本糾錯、分解長句等功能。但是還是無法從根本上解決理解用戶意圖的問題。

4. 增加追問機制

這里是通過Prompt就可以實現(xiàn)的功能，只要在Prompt中加入“如果無法從背景知識回答用戶的問題，則根據(jù)背景知識內(nèi)容，對用戶進行追問，問題限制在3個以內(nèi)”。這個機制并沒有什么技術(shù)含量，主要依靠大模型的能力。不過大大改善了用戶體驗，用戶在多輪引導(dǎo)中逐步明確了自己的問題，從而能夠得到合適的答案。

5. 微調(diào)Embedding句向量模型

這部分主要是為了解決垂直領(lǐng)域特殊詞匯，在通用句向量中會權(quán)重過大的問題。比如有個通用句向量模型，它在訓(xùn)練中很少見到“SAAS”這個詞，無論是文本段和用戶query，只要提到了這個詞，整個句向量都會被帶偏。舉個例子：

假如一個用戶問的是：我是一個SAAS用戶，我希望訂購一個云存儲服務(wù)。由于SAAS的權(quán)重很高，使得檢索匹配時候，模型完全忽略了后面的那句話，才是真實的用戶需求。返回的內(nèi)容可能是SAAS的介紹、SAAS的使用手冊等等。

這里的微調(diào)方法使用的數(shù)據(jù)，是讓大模型對語義分割的每一段，形成問答對。用這些問答對構(gòu)建了數(shù)據(jù)集進行句向量的訓(xùn)練，使得句向量能夠盡量理解垂直領(lǐng)域的場景。

總結(jié)

經(jīng)過這么一套組合拳，系統(tǒng)的回答效果從一開始的完全給不了幫助以及胡說八道，到了現(xiàn)在可以參考的程度。但是與用戶實際期望還是相差甚遠。

這里不由得讓我思考了下整個過程，RAG的本意是想讓模型降低幻想，同時能夠?qū)崟r獲取內(nèi)容，使得大模型給出合適的回答。

在嚴謹場景中，precision比recall更重要。

如果大模型胡亂輸出，類比傳統(tǒng)指標，就好比recall高但是precision低，但是限制了大模型的輸出后，提升了precision，recall降低了。所以給用戶造成的觀感就是，大模型變笨了，是不是哪里出問題了。

總之，這個balance很難取，我對比了下市面主流的一些基于單篇文檔的知識庫問答，比如WPS AI，或者海外的ChatDoc。我發(fā)現(xiàn)即使基于單篇文檔回答，它們在我們垂直領(lǐng)域的文檔的幻想問題還是很嚴重。但是輸出的答案不認真看的話，確實挺驚艷。例如問個操作步驟問題，文檔壓根沒這個內(nèi)容，但是它一步步輸出的極其自信。

反正最后就想感慨一下，RAG確實沒有想的那么容易。