最近在公司完成了一個內部知識問答應用，實現流程很簡單，實際上就是Langchain那一套：

對文檔進行切片

將切片后的文本塊轉變為向量形式存儲至向量庫中

用戶問題轉換為向量

匹配用戶問題向量和向量庫中各文本塊向量的相關度

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

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

具體可以參考下圖，

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

但是，當公司內部真實文檔導入之后，效果急轉直下。

當時初步分析，有以下幾個原因：

1. 文檔種類多

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

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

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

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

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

2. 切分方式

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

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

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

3. 內部知識的特殊性

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

4. 用戶提問的隨意性

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

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

問題解決方法

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

1. 對文檔內容進行重新處理

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

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

PDF類文檔的難點在于，如何完整恢復圖片、表格、標題、段落等內容，形成一個文字版的文檔。這里使用了多個開源模型進行協同分析，例如版面分析使用了百度的PP-StructureV2，能夠對Text、Title、Figure、Figure caption、Table、Table caption、Header、Footer、Reference、Equation10類區域進行檢測，統一了OCR和文本屬性分類兩個任務。

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

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

2. 語義切分

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

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

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

3. RAG Fusion

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

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

4. 增加追問機制

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

5. 微調Embedding句向量模型

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

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

這里的微調方法使用的數據，是讓大模型對語義分割的每一段，形成問答對。用這些問答對構建了數據集進行句向量的訓練，使得句向量能夠盡量理解垂直領域的場景。

總結

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

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

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

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

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

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