出品 | 51CTO技術棧（微信號：blog51cto）

日前，在51CTO主辦的WOT全球技術創新大會上，瀾舟科技合伙人、算法和應用VP馬永亮帶來了主題演講《企業級智能知識庫搜索問答技術與應用》，圍繞知識庫搜索問答場景，詳細闡述了在AI2.0時代，我們應該如何結合大模型能力進行有效的實踐與創新。

本文將摘選其中精彩內容，統一整理，希望為諸君帶來啟發。

以2022年年底ChatGPT推出為分界點，我們可以把過去的AI技術稱為AI1.0，之后的技術稱為AI2.0。那么，跟AI1.0相比，AI2.0的技術有哪些不同呢？

圖片

首先，大家熟知的“能力涌現”，以前很多通過規則的方式，或者一個很復雜的Pipeline構建起來的能力，今天在大模型中就可以涌現出來。其次，多模態的能力以及對話的能力等等，這些都是AI2.0時代大模型能力突出的地方。然而，結合我們這幾年在B端行業中應用大模型技術的經驗，對于大模型/AI技術的產業落地，我認為這幾點非常關鍵。

第一，AI能力的獲取門檻顯著降低了。今天想讓大模型完成一件任務，最簡單的方式就是通過自然語言與大模型進行交互，通過做Prompt Engineering就可以做到。這在這以前是不敢想象的。

大模型的第二個特點，就是它的通用性。以前很多AI能力的構建可能都和具體的任務相關。比如之前做搜索引擎，整個團隊會被分成很多不同的Team，Query理解、排序、文檔的理解等等，這里面用到的技術大不一樣。然而，今天不一樣了，現在所有這些任務，像搜索引擎這么復雜的系統，其實都可以構建在大模型技術之上。

第三點，則是生成能力。因為以前做機器學習算法或者模型時，數據標注非常耗時耗力，卡點就在于用于標注的訓練數據的稀少。今天因為生成能力的存在，就意味著你可以來生成這些數據，然后再去標注。這對于看重企業私密數據安全的to B場景而言，非常有意義。

因此，當具備了上述三點之后，大模型、AI技術開始在不同的行業中落地。同時需要注意的是，不同行業其實對大模型技術的需求并不一樣，因此發展成熟度也不盡相同。

在發展比較快的行業，比如在圖片生成的領域，已經有很多流水非常高、用戶黏性非常好的一些產品和公司出現了；相對發展困難一些的行業，比如在基礎研究、自動駕駛等領域，落地則較慢；中間則是金融、教育等領域，現在正處于啟動期；同時，在金融、制造業等賽道不斷地有一些標桿企業的應用開始落地了，但數量尚有限。

以上便是我們從去年6月份到現在為止，觀察到的大模型落地的行業趨勢。

圖片

1.AI產業化象限

那么接下來，結合大模型能力以及對to B、to C行業的理解，AI產業化最后會形成怎樣一個象限？

在很多維度中，我們抽取了三個最重要的維度：門檻、效果、人力。從這三個維度看，重點去思考象限中的四個點如何在效果面上達到最好。

圖片

首先看A點，我稱之為“成本之殤”，為什么呢？因為達到A點的效果，同時需要極多的人力和極高的門檻，成本非常高昂。

這也是在AI1.0時代，尤其在to B行業化去落地時面臨的最大挑戰，它不僅體現在人才的數量上，而且這些人才需要具備一定的模型構建的能力，成本顯然很高。因為B端行業不同，需求不一樣。同樣的行業，不同的公司，需求差別其實也不小。

再來看點B，這里稱之為“互聯網模式”。它是一個邊際效應遞減的模式，特點就是人力相對要少，但是門檻比較高。因為互聯網模式下有規模效應，比如我們之前一個團隊可能有十幾個人、二十個人，這些人就干一件事情：把query的意圖分析得準一點，哪怕漲一個百分點，上線之后帶來的效果也會非?？捎^——因為這樣一個搜索引擎它每天的Query都是數十億的。因此幾個人、十幾個人的改進就可以非常容易得到規模化，成本邊際效應就會遞減。

接下來，C點則是“終極AGI”，特點是效果又好，也不需要非常專業的人，而且需要的人也不多。即我們所設想的這樣：不需要人來干活，交給模型、交給AI、交給AGI就可以了。這顯然是很難做到的，尤其在行業落地的場景下。

最后D點，我認為是“AI產業化的起點”。像瀾舟科技這樣的toB公司就是致力于推向這個點。依賴于大模型技術，D點的門檻其實會很大程度上降低，也會取得明顯的效果，但是它仍然需要很多人，為什么呢？因為要駕馭今天的模型去解決一些定制化的問題，確實需要一些人的知識和能力，但是它的門檻會降低。通過這種方式，去解決千行百業AI大模型落地的問題。

2.產模一體，為什么要自己做模型？

瀾舟科技在企業戰略布局的定位是產模一體，既做大模型底座，同時也會側重產品和應用的研發和落地。很多人會問，“可以用很多開源的模型，為什么還要自己做模型呢？”我認為自己做模型有以下幾點優勢。

圖片

第一，你會很清楚地理解整個技術棧以及存在的問題。這對在應用中去做比如微調、對齊，甚至利用RAG、Agent都是非常有幫助的。即使今天大家在應用中使用GPT4或者其他SOTA模型，實際上也會面臨很多問題，只靠Prompt Engineering很多時候是不能解決的，RAG、Agent也很重要。

第二，在使用大模型這些能力的時候，還意味著你需要了解模型的能力邊界在哪，能力不夠的地方就需要去優化。同時也確實有一些公司和客戶有意愿、有需求去針對模型底座做一些定制的優化，做一些continue train。

瀾舟科技在這些方面其實都有一些布局，最底層的模型，基于底層的基礎模型之上我們會有一些行業的，還有一些功能性的，比如金融行業大模型、編程大模型，我們剛才講的幾個技術能力。上面就是我們今天講得可能會比較多的，就是知識庫相關的，搜索、問答，以及和寫作有關的一些能力。

3.行業落地中的挑戰

在企業側落地方面，有以下幾個突出的問題。

首先是模型效果。大模型直接拿來用，今天的很多問題其實都解決不了。大家使用RAG的一個很重要的原因，就是它能接入可快速更新的知識庫，而這些知識庫每次通過訓練把這個知識infuse到模型里，時效性顯然不夠。此外，還存在數據庫、圖譜等結構化知識難以利用以及幻覺問題等。

圖片

第二，落地成本的問題，這里既有研發的成本，同時也有模型本身的成本。大參數量的模型，需要用很多機器去部署它，而且窗口越長，推理越慢，就需要更多的機器；此外，大模型的定制需要投入很多人力，如果門檻不夠低的話，人力成本也會非常高。

最后，可持續的問題。大模型發展速度非常快，很多企業在采購大模型時會擔心，現在花錢買了一個底座，可能沒過兩三個月，可能就會開源出一個比你買的還要好的模型，這對于去布局自己公司或集團的大模型技術是有一定的風險的。

瀾舟科技已經開源了很多模型，在常見的這些開源社區和網站上其實大家也都能夠下載。然而，我們不會去做參數量非常大的模型，因為企業客戶本身實際上也并不去用太大的參數去解決真正業務中的實際問題。

圖片

金融作為重要的行業領域，瀾舟科技投入了更多的資源打造出金融行業大模型。

孟子GPT金融行業大模型通過構建眾多金融任務的多樣化學習數據、Few-shot學習以及強化學習等訓練方法，在金融任務上的性能評測上整體取得了優異性能。結果顯示，它不僅在金融任務上明顯比通用模型好，而且其通用能力也沒有出現明顯下降。

圖片

4.RAG和Agent

在搜索、問答、知識庫領域，通常會依賴兩個重要的技術，一個是RAG(檢索增強生成)，一個是Agent。

搜索引擎跟大模型能力結合起來是一個很自然的想法，因為搜索引擎的搜索實際上是用戶去驅動的，用戶說我要搜什么，系統看了一些文檔之后，再決定下一步要搜什么，以此來解決自己的這個問題。

大模型可以將這個流程自動化，比如，之前用戶需要搜十個Query，用了大模型之后，你只需要搜解決那個問題的那個Query就行。當時的效果就已經不錯了。

在與搜索結合過程中，我們看到RAG（檢索增強生成）技術。今天這個框架已經非常標準化，其中的很多模塊，比如Query上應該做些什么，文檔上應該做些什么等，也都是搜索引擎中非常重要的模塊。

文檔方面，在toB的領域，很多文檔都是非結構化的，比如PDF文件格式，所以文檔解析在知識庫這個領域就非常重要，在這個領域要解決海量信息、幻覺等問題，就可以自然接入到大模型的應用中來。

其實，這里的窗口長度也沒有那么大，根據我們自己的實驗，一個13B左右的模型，每個文檔片段1K左右，大模型的輸入窗口6K，即TOP6的文檔片段，在答案的recall上就能做到99%以上。只要底層檢索和排序的能力做到一定水平之后，就很容易達到這點。所以大家經?？吹揭话肽Ｐ偷拇翱谥挥?、7K，長一點的有20~30K。

圖片

但如果你真的要解讀一篇金融領域的文檔，比如年報、研報，年報一般二、三百頁，研報多的三、四十頁，那么窗口即便是幾百K都不夠。

不用提推理速度，就是對效果的影響也會很明顯，因為它太長了，長了之后整個窗口內的和你的問題相關的信息密度會顯著下降，下降了之后就會自然影響模型的效果。

因此，并不是說這模型支持這么長窗口，就給它這么長，效果跟短文本窗口是不一樣的：短不只是推理的成本低，推理的效果也會更好。

檢索是一個非常通用的接口，可以通過讓大模型和檢索結合起來，做非常多的事。現在大家做RAG，更多是非結構化的文檔搜索，但其實將非結構化文檔變成半結構化或者結構化進而做結構化文檔的搜索，也是一個趨勢。所以就是結合了檢索的通用的接口之后，同時大模型的能力也得到了非常強的擴展。

接下來講一下Agent方面。第一，結合Agent可以設計非常復雜的工作流。企業側存在很多復雜的工作流，它需要很多步，而且這些步驟有時還不只是一次大模型的推理，還要依賴于現在的一些能力，比如檢索增強、代碼的執行、計算等等，這些工具的調用其實都是通過Agent串聯起來的流程。

人們可以自己設計workflow，現在編排這種流程的工具很多。此外，大模型本身也具備一定的planning能力，甚至針對一些比較局限的場景，大模型也可以自己設計workflow，而且會非常動態，會根據不同的輸入，會設計不同的workflow。

圖片

整體上看，包括瀾舟科技在內的很多大模型的公司，整個技術棧有這幾個層次，L1-通用的底座、L2-行業大模型，L3-場景任務模型，L4-AI Agent。

5.具體案例：文檔理解和搜問

現在說到文檔問答或者知識庫一些具體的問題和我們的一些工作。

首先，為什么要做文檔的解析和理解，因為在一些文檔中，它的問題有時和文檔的結構是緊密相關的，有了文章的結構，其實對于RAG做更復雜的問題是有很好的幫助的。

圖片

下面就是我們在文檔理解上面的一個整體的文檔解析能力的架構。

圖片

首先，PDF文檔、圖片等非結構化的內容，通過OCR，利用大模型進行一些處理之后，得到文章的內容。

下面則是針對文檔的結構部分，同樣也需要OCR，通過大模型和規則的結合，就可以把非常常見的、模式非常清楚的東西定義出來，而且大模型非常適合去擴展一些偏tail的內容。

最后文檔的內容和文檔的結構合并之后，我們就可以得到一個非結構化文檔的解析的結果，像表格、章節、標題、段落等等。

接下來就可以針對它做一個分塊，這里也會有很多的策略。比如多粒度分層chunking，一篇文章可以有多種分塊方法。然后在每種類型的分塊方法上都進行召回，最后再做一些合并的策略，其實就會有更好的結果。

圖片

在搜問方面，我認為有三個比較重要的環節。第一，文檔的解析非常重要。第二，檢索的準確度，別只用一個向量去解決檢索的環節，后面可能還要做關鍵詞和排序模型，可以采用    learning to rank作為大模型最后在排序的召回層，這樣可以非常有效地提升整個RAG stack推理的速度。

最后就是答案的答復和幻覺的檢測,這個環節非常重要。在B端領域，一個可以落地的指標是90%以上，否則的話其實很難被使用起來，即便真的有人去用，體驗也會非常差。

6.知識庫搜索和問答的未來方向

最后我想分享一下在知識庫搜索和問答領域，下一個階段我們會重點關注的幾個技術方向。

首先第一個就是從單一的結構數據向多結構數據融合來做搜索問答或者RAG、Agent。單一的數據結構可以理解為一種非結構化的文檔，比如圖片或PDF。而多結構化則是指即使是非結構化的文檔，我們也希望把它變成半結構化的。

例如，輸入一本講解世界范圍名勝古跡的書，我們現在問一個優點條件搜索的問題：中國的名勝古跡有哪些？如果用傳統的RAG的話，很可能搜回來的古跡不只是中國的。這時候就希望針對這樣的文檔做一些半結構化處理。這里有一種很簡單的方法：針對這些非結構化的文檔構建一個簡單的知識結構就可以了。

最簡單的知識結構其實就是Key-value，我們抽出這個文章內容的property，然后它的value是什么。對應剛才的例子，其實就把文章中的古跡的地址、所在的國家抽取成property，只要它是“中國”就行了。這樣的非結構化數據就變成了一個半結構化/結構化的數據，將其放到數據庫中之后，就可以利用現代數據庫搜索的技術，比如NL2SQL或者Semantic的NL2SQL，進行一些值的語義匹配的，當然現在也有很多數據庫是把這種匹配向量化了。

今天這種非結構化文檔的問答，通過“抽取，聚合，總結”的這種模式，指標基本上都能到90%以上了。接下來大家需要解決更難的問題，這就需要了解文章的結構，文章的知識點，知識的維度。

第二個趨勢，就是從剛才說到的抽取、匯總、摘要，將轉向數理的計算和推理。這種類型的問題更多出現在表格上，今天做得好一點的可能就直接在非結構化的表里面抽出一兩個值，但如果讓它去做一些計算、推理，比如：哪一年某個公司的營業額是最高的，成功率就會低很多，可能只有50%-60%左右。今天我們考慮在大模型中引入代碼、工具等能力，利用Agent的一些技術來解決類似的問題。

最后一個趨勢就是單跳檢索增強轉向多跳?！皢翁本褪怯脩舭l一個問題，我們就把這個問題需要的東西搜回來，你可能會對這個Query做很多改寫去搜。而“多跳是什么”？比如這樣的問題：A、B、C三個公司的年營業額或者2023年的業績表現對比是如何的？這幾個公司的業績表現可能是在三個文檔中，你直接搜這個問題，即使多文檔的搜索效果也不會很好。這個時候就需要“多跳”。

所謂“多跳”，就是這個問題就會拆成一個并列的搜索。回到這個例子中，就會把它拆成三個Query，分別搜A公司、B公司和C公司單獨的內容。除了這種并行的多跳，還有很多其他類型的，比如遞進、交并關系等等，甚至有一些是計算的。瀾舟智庫，作為瀾舟科技精心打造大模型時代的智能知識庫平臺，專為現代企業量身定制，該平臺集智能AI搜索、知識庫問答、AI輔助寫作等功能于一體，能夠幫助企業迅速構建起既安全又可靠的專屬知識中臺。我們也會在未來的瀾舟智庫這款知識庫產品的迭代中不斷地引入這些新的能力進來。

本文轉載自??51CTO技術棧??，作者：言征