許多從業(yè)者發(fā)現(xiàn)，盡管RAG能在短時間內(nèi)快速搭建出Demo，但在實際生產(chǎn)環(huán)境中落地卻困難重重。本文從AI大模型領(lǐng)域創(chuàng)業(yè)者的視角出發(fā)，深入剖析了RAG在產(chǎn)業(yè)落地中的核心問題——問題分級，并詳細探討四類問題的挑戰(zhàn)與解決方案，供大家參考。

很多熟悉RAG的產(chǎn)品經(jīng)理和工程師會吐槽，“做RAG一周就可以出Demo，但真正做到能上生產(chǎn)環(huán)境的水平，半年時間都不夠！”。

這是現(xiàn)階段RAG在產(chǎn)業(yè)落地的現(xiàn)實問題。RAG框架非常簡單易懂，也有很多優(yōu)化RAG全流程的方式和手段，風(fēng)叔在此前的文章中也做過詳細介紹，《Rag系統(tǒng)的發(fā)展歷程，從樸素、高級到模塊化》。

但無論是企業(yè)內(nèi)部使用，還是面向C端用戶，大家最直接的感受是，RAG只能檢索和回答相對淺顯直觀的問題。

企業(yè)知識庫領(lǐng)域的獨角獸Hebbia也曾經(jīng)做過實驗，RAG實際上只能解決企業(yè)內(nèi)部16%的問題，這到底是什么原因呢？

答案是問題分級。

任何用戶檢索問題都可以分成四類，顯性事實查詢、隱性事實查詢、可解釋性推理查詢和隱性推理查詢，這四類問題的復(fù)雜度和解題難度依次提升。

下圖列出了每類問題面對的挑戰(zhàn)和解決方法。可以看出，只有顯性事實查詢和部分隱性事實查詢，可以通過RAG、Iterative Rag或GraphRag來解決。而可解釋性推理查詢和隱性推理查詢問題，RAG就沒有用武之地了，需要依靠其他更復(fù)雜和針對性的解決方案。

在實際企業(yè)應(yīng)用場景中，絕大多數(shù)對業(yè)務(wù)部門有價值的問題都處于Level 3和Level 4，因此導(dǎo)致了“RAG一周出Demo，半年上不了線”的窘境。

接下來，風(fēng)叔將詳細闡述這四類問題的特點和解決方案。看到最后，相信你一定會有收獲！

一、顯性事實查詢

顯性事實是指外部數(shù)據(jù)中直接存在的事實信息或數(shù)據(jù)，不需要進行額外的推理。比如“2016年奧運會在哪里舉辦的？”、“某傳感器的品牌和工作溫度是多少？”、“門店A上個月的營業(yè)額是多少？”。

顯性事實查詢是最簡單的查詢形式，直接從提供的數(shù)據(jù)中檢索到明確的事實信息，不需要復(fù)雜的推理和思考，因此非常適合使用RAG。

當(dāng)然，要準確、高效地檢索和生成相關(guān)內(nèi)容，還需要對RAG系統(tǒng)進行優(yōu)化?？梢酝ㄟ^風(fēng)叔之前介紹的方法，這里再做個簡單的回顧。

索引構(gòu)建

• 塊優(yōu)化：通過滑動窗口、增加元數(shù)據(jù)、從小到大等方式，更加合理地對內(nèi)容塊的大小、結(jié)構(gòu)和相關(guān)性進行分塊。
• 多級索引：指創(chuàng)建兩個索引，一個由文檔摘要組成，另一個由文檔塊組成，并分兩步搜索，首先通過摘要過濾掉相關(guān)文檔，然后只在這個相關(guān)組內(nèi)進行搜索。
• 知識圖譜：提取實體以及實體之間的關(guān)系，構(gòu)建一種全局性的信息優(yōu)勢，從而提升RAG的精確度。

預(yù)檢索

• 多查詢：借助提示工程通過大型語言模型來擴展查詢，將原始Query擴展成多個相似的Query，然后并行執(zhí)行。
• 子查詢：通過分解和規(guī)劃復(fù)雜問題，將原始Query分解成為多個子問題，最后再進行匯總合并。
• 查詢轉(zhuǎn)換：將用戶的原始查詢轉(zhuǎn)換成一種新的查詢內(nèi)容后，再進行檢索生成。
• 查詢構(gòu)建：將自然語言的Query，轉(zhuǎn)化為某種特定機器或軟件能理解的語言，比如text2SQL、text2Cypher。

檢索

• 稀疏檢索器：用統(tǒng)計方法將查詢和文檔轉(zhuǎn)化為稀疏向量。其優(yōu)勢在于處理大型數(shù)據(jù)集時效率高，只關(guān)注非零元素。
• 密集檢索器：使用預(yù)訓(xùn)練的語言模型（PLMs）為查詢和文檔提供密集表示，盡管計算和存儲成本較高，卻能提供更復(fù)雜的語義表示
• 檢索器微調(diào)：基于有標記的領(lǐng)域數(shù)據(jù)微調(diào)檢索模型，通常借助對比學(xué)習(xí)來實現(xiàn)

檢索后

• 重排序：對于檢索到的內(nèi)容塊，使用專門的排序模型，重新計算上下文的相關(guān)性得分。
• 壓縮：對于檢索到的內(nèi)容塊，不要直接輸入大模型，而是先刪除無關(guān)內(nèi)容并突出重要上下文，從而減少整體提示長度，降低冗余信息對大模型的干擾。

二、隱性事實查詢

隱性事實并不會直接在原始數(shù)據(jù)中顯現(xiàn)，需要少量的推理和邏輯判斷。而且推導(dǎo)隱性事實的信息可能分散在多個段落或數(shù)據(jù)表中，因此需要跨文檔檢索或跨表查詢。

比如，“查詢過去一個月營收增長率最高的門店”，就是一個典型的隱性事實查詢。需要先獲取所有門店這個月和上個月的營收，然后計算每個門店的營收增長率，最后排序得出結(jié)果。

隱性事實查詢的主要挑戰(zhàn)是，不同問題依賴的數(shù)據(jù)源和推理邏輯都各不相同，如何保障大模型在推理過程中的泛化性。

隱性事實查詢的主要解題思路包括以下方法：

多跳檢索和推理

Iterative Rag：在檢索前先生成檢索計劃，然后在檢索過程中不斷根據(jù)檢索結(jié)果進行優(yōu)化。比如利用ReAct框架，沿著Thought – Action – Observation的分析思路，逐步逼近正確答案。

Self-Rag：構(gòu)建四個關(guān)鍵的評分器，即檢索需求評分器、檢索相關(guān)性評分器、生成相關(guān)性評分器和回答質(zhì)量評分器，從而讓大模型自主決定何時開始檢索、何時借助外部搜索工具、何時輸出最終答案。

利用圖和樹結(jié)構(gòu)

Raptor：RAPTOR 根據(jù)向量遞歸地對文本塊進行聚類，并生成這些聚類的文本摘要，從而自下而上構(gòu)建一棵樹。聚集在一起的節(jié)點是兄弟節(jié)點；父節(jié)點包含該集群的文本摘要。這種結(jié)構(gòu)使 RAPTOR 能夠?qū)⒋聿煌墑e文本的上下文塊加載到 LLM 的上下文中，以便能夠有效且高效地回答不同層面的問題。

GraphRag：一種將知識圖譜與Rag相結(jié)合的技術(shù)范式。傳統(tǒng)Rag是對向量數(shù)據(jù)庫進行檢索，而GraphRag則對存儲在圖數(shù)據(jù)庫中的知識圖譜進行檢索，獲得關(guān)聯(lián)知識并實現(xiàn)增強生成。

將自然語言轉(zhuǎn)換成SQL查詢

text2SQL：主要用于數(shù)據(jù)庫查詢，尤其是多表查詢場景，可參考《一文讀懂ChatBI的實現(xiàn)難點與解決方案，問答準確率超過99%》

三、可解釋性推理

可解釋性推理，是指無法從顯性事實和隱性事實中獲取，需要綜合多方數(shù)據(jù)進行較為復(fù)雜的推理、歸納和總結(jié)的問題，并且推理過程具備業(yè)務(wù)可解釋性。

ChatBI中的歸因分析，就是典型的可解釋性推理，比如”過去一個月，華南區(qū)域營收下滑5%的原因是什么？“。這個問題無法直接獲取，但可以通過一定方式進行推理，如下所示：

總營收 = 新客 * 轉(zhuǎn)化率 * 客單價 + 老客 * 復(fù)購率 * 客單價

經(jīng)過分析，新客數(shù)量、轉(zhuǎn)化率和客單價并未發(fā)生明顯變化，而老客復(fù)購率下滑約10%，因此可以推斷出可能是”服務(wù)質(zhì)量、競品競爭“等原因，引起了老客復(fù)購率的下滑，從而導(dǎo)致了總營收的下降。

可解釋性推理問題主要有兩個挑戰(zhàn)，多樣化的提示詞和有限的可解釋性。

• 多樣化的提示詞：不同的查詢問題，需要特定的業(yè)務(wù)知識和決策依據(jù)。比如推理營收下滑的原因可以用上述的業(yè)務(wù)規(guī)則，但如果是推理毛利率下滑的原因，就需要另一種業(yè)務(wù)規(guī)則。這種多樣化的規(guī)則沉淀，既需要行業(yè)專家進行梳理和沉淀，也需要將其轉(zhuǎn)換為合適的提示詞，讓大模型理解背后的邏輯。
• 有限的可解釋性：提示詞對于大模型的影響是不透明的，我們很難評估提示詞對模型的影響，因此會妨礙我們構(gòu)建一致的可解釋性

面對這樣的挑戰(zhàn)，風(fēng)叔主要有以下建議：

提示詞工程優(yōu)化

優(yōu)化提示詞：需要有效地將業(yè)務(wù)推理邏輯，整合到大語言模型中，比較考驗提示詞設(shè)計人員的行業(yè)know-how。

提示詞微調(diào)：手動設(shè)計提示詞會很耗時，可以通過提示詞微調(diào)技術(shù)解決這個問題。比如通過強化學(xué)習(xí)，將大模型生成正確回答的概率作為獎勵，指導(dǎo)模型在不同數(shù)據(jù)集上發(fā)現(xiàn)最佳提示詞配置。

構(gòu)建決策樹

決策樹：將決策流程轉(zhuǎn)換為狀態(tài)機、決策樹或偽代碼，讓大模型執(zhí)行。比如在設(shè)備運維領(lǐng)域，構(gòu)建故障樹就是一種非常有效的故障檢測方案。

利用智能體工作流

Agentic Workflow：通過workflow構(gòu)建大模型思考和行動的具體步驟，從而約束大模型的思考方向。這種方法的優(yōu)點是能夠提供相對穩(wěn)定的輸出，但缺點是靈活性不足，同樣需要針對每類問題設(shè)計工作流。

四、隱性推理查詢

隱性推理查詢，是指難以通過事先約定的業(yè)務(wù)規(guī)則或決策邏輯進行判斷，而必須從外部數(shù)據(jù)中進行觀察和分析，最終推理出結(jié)論。

比如IT智能運維，并不存在先驗的完整文檔，詳細記錄每種問題的處理方法和規(guī)則，只有運維團隊過去處理的各種故障事件和解決方案。大模型需要從這些數(shù)據(jù)中挖掘出針對不同故障的最佳處理方案，這就是隱性推理查詢。

同樣，在產(chǎn)線智能運維、智能量化交易等場景中，都涉及大量的隱性推理查詢問題。

隱性推理問題的主要挑戰(zhàn)是邏輯提煉困難、數(shù)據(jù)分散和不足，是最為復(fù)雜和困難的問題。

• 邏輯提煉困難：在海量數(shù)據(jù)中挖掘隱性邏輯，需要開發(fā)復(fù)雜且有效的算法，能夠解析和識別隱藏在數(shù)據(jù)背后的邏輯。因此，僅依靠表面的語義相似性是遠遠不夠的，需要構(gòu)建專門的小模型來應(yīng)對。
• 數(shù)據(jù)分散和不足：隱性邏輯往往隱藏在非常分散的知識中，因此要求模型具備強大的數(shù)據(jù)挖掘和綜合推理能力。同時，當(dāng)外部數(shù)據(jù)有限或者數(shù)據(jù)質(zhì)量不滿足要求時，也很難從中挖掘出有價值的信息。

對于隱性推理問題所面臨的挑戰(zhàn)，有以下解題思路：

• 機器學(xué)習(xí)：通過傳統(tǒng)的機器學(xué)習(xí)方法，從歷史數(shù)據(jù)和案例中總結(jié)出潛在的規(guī)則。
• 上下文學(xué)習(xí)：在提示中涵蓋相關(guān)的示例，給模型進行參考。但是這種方法的缺陷在于，如何讓大模型掌握其訓(xùn)練領(lǐng)域之外的推理能力。
• 模型微調(diào)：通過大量業(yè)務(wù)數(shù)據(jù)和案例數(shù)據(jù)，對模型進行微調(diào)，將領(lǐng)域知識進行內(nèi)化。但是這種方法的資源耗費比較大，中小企業(yè)謹慎使用。
• 強化學(xué)習(xí)：通過獎勵機制，鼓勵模型產(chǎn)生最符合業(yè)務(wù)實際的推理邏輯和答案。

五、總結(jié)

在本篇文章中，針對Rag上手容易上線難的問題，風(fēng)叔介紹了用戶檢索的四類問題，以及每類問題對應(yīng)的解題思路。

對于顯性事實查詢和隱性事實查詢類問題，可以通過多種Rag優(yōu)化方案來解決。但是，面對可解釋性推理和隱性推理問題時，只使用RAG就會力不從心了，需要引入提示詞工程、決策樹、Agentic Workflow、機器學(xué)習(xí)、模型微調(diào)和強化學(xué)習(xí)等多種方法。

其中每個方法要詳細展開闡述的話，都可以單獨寫一個系列。因此，本文只是先拋出這些解題方向，不做展開。后續(xù)有時間，風(fēng)叔再結(jié)合實際案例做詳細介紹。