RAG技術演進的四大核心命題

阿里妹導讀
隨著技術的深入應用,如何高效利用大模型技術最佳化使用者體驗,同時應對其帶來的諸多挑戰?本文將從RAG的發展趨勢、技術挑戰、核心舉措以及未來展望四個維度總結我們應對挑戰的新的思路和方法。
一、背景
自2022年11月30日OpenAI釋出ChatGPT-3.5以來,預訓練大模型技術開啟了指數級發展程序。這一革新熱潮在2023年3月至4月達到階段性高峰:阿里通義千問和百度文心一言等國內頭部企業相繼釋出自主訓練的大模型,正式宣告人工智慧領域邁入大模型驅動的新紀元。尤其值得注意的是,2025年1-3月期間DeepSeek-R1和QwQ-32B推理大模型的開源舉措,進一步加速了技術的程序。回顧過去兩年間,大模型技術在金融、醫療、教育、客服等垂直領域實現深度滲透,尤其是在智慧問答服務領域的突破性進展,透過大模型理解與推理能力的融合,實現了使用者服務體驗的指數級躍遷。
大模型發展歷程[1]
然而,隨著技術的深入應用,如何高效利用大模型技術最佳化使用者體驗,同時應對其帶來的諸多挑戰,比如如何將領域資料高效垂直化,如何解決大模型的幻覺等問題,成為行業亟需解決的核心問題。RAG(Retrieval-Augmented Generation,檢索增強生成)作為一種前沿的技術方案,為應對上述挑戰提供了新的思路和方法。
在2024.05之前,我們完成了對客大模型智慧對話機器人Chatbot的RAG從0到1的建設,將檢索準確率提升至90%,生成準確率提升至85%。後期,我們的核心目標不僅是繼續升級對客RAG鏈路,將答案准確率提升至90%,還將重點構建小二智慧輔助Copilot RAG,將小二信任度(答案准確率)提升至85%。
對客Chatbot
小二智慧輔助Copilot
本文將從RAG的發展趨勢、技術挑戰、核心舉措以及未來展望四個維度進行總結,期望激發更多關於RAG技術在雲服務領域應用的思考與討論,推動智慧問答系統向更高效、精準和可靠的方向邁進。
二、發展趨勢
2.1 AI的發展趨勢
在介紹RAG之前,先看下AI的發展趨勢,紅杉資本(Sequoia Capital)對2025年的AI發展做了三個預測:
1. LLM提供商之間的差異化:競爭將更加激烈,出現獨特的超級力量(如OpenAI、Amazon/Anthropic、Google、Meta等)。這些公司已經發展出專門的優勢,以在競爭格局中實現差異化,塑造各自的戰略重心,並影響獲取市場的方式。有的公司賣雲,有的賣API,有的賣訂閱(token),還有的賣應用等。
2. AI搜尋作為殺手級應用的崛起AI搜尋的興起可能會分化當前由Google主導的搜尋市場。AI搜尋超越了簡單的網頁索引,轉向語義理解和知識綜合,使使用者能夠更高效地找到資訊並獲得更深入的見解。
3. AI投資的穩定化和ROI挑戰:鉅額資本投入需要透過切實的商業成果來證明其合理性,這仍是行業面臨的一個關鍵挑戰。
總結一句話總結,2025年的AI格局將明顯從最初的興奮和快速投資階段,轉向注重落地、差異化和展示實際價值的階段。對紅衫資本最近幾年的AI預測分析,可以參考下面熱帖[2],高年級洪林師兄的分享,總結非常深刻且全面。
2.2 RAG發展趨勢
Primary Architectural Approach 2023 vs 2024
接下來看下RAG的發展趨勢,從市場份額看,Menlo Partners(門羅的合作伙伴)在2024年11月20日釋出的市場調研報告[3]顯示,他們調查了600名美國企業IT決策者,這些企業員工人數均在50人以上,覆蓋了廣泛的行業和應用場景。資料顯示,今年企業AI設計模式(用於構建高效、可擴充套件AI系統的標準化架構)正在快速發展。2024年,RAG(檢索增強生成)目前佔據主導地位,採用率為51%,較去年的31%大幅上升。與此同時,經常被吹捧的微調(Fine-tuning)和RLHF(Reinforcement Learning from Human Feedback),尤其是在領先的應用提供商中,採用率仍然較低,分別只有9%和5%。
在2025年隨著推理大模型的爆發,比如DeepSeek-R1和QwQ-32B,在複雜任務的推理上,結合RAG能否碰出新的火花,是今年最值得期待的。
三、技術挑戰
3.1 業務挑戰
在服務領域,使用者體驗至關重要。然而,傳統的服務模式往往存在一些問題,如判別式回覆、缺乏生成性思考等,這些問題直接影響使用者體驗。接下來,我將從三個角度分析為什麼服務領域需要引入RAG:
1. 擬人化服務:傳統客服缺乏對使用者主動的個性化關懷,互動過程過於被動和機械,導致使用者感受不到溫度。
2. 專業性:技術支援人員對知識的維護成本較高,不同客服之間可能存在技術上的偏差。面對新問題時,缺乏有效的解決策略,導致問題解決效率低下。
3. 精準性:客服給出的答案往往泛泛而談,缺乏針對性。例如,使用者諮詢某一具體情況時,回覆卻涉及多個不同情況,造成客戶困擾和不滿。同時,客戶提出的問題大多模糊,需要上下文理解,但單靠小模型的能力難以勝任,導致使用者體驗不佳。
我們希望透過引入RAG,實現兩個核心目標:
1.為客戶提供專業、精準、擬人化的客服服務,打破傳統機械回覆的不良體驗。
2. 為客服人員提供專業、全面的智慧輔助,幫助他們快速響應客戶問題。
3.2 技術挑戰
儘管檢索增強生成(RAG)技術透過外部資訊注入顯著拓寬了大型語言模型( LLM )的認知維度,但該技術框架在關鍵決策場景下的缺陷也日益凸顯。實證資料顯示初期,小二智慧輔助Copilot面臨使用者信任度危機的核心根源,在於其LLM輸出結果存在顯著缺陷,雖然內容檢索準確率達到83%,但最終LLM生成答案的精準度僅為66%(兩者間形成17pt的可信度斷層)。這種資訊處理鏈路中的質量衰減效應,在售後服務問答場景,這種要求高度確定性的領域將直接引發嚴重後果。針對該技術瓶頸,我們透過系統性梳理RAG技術全鏈路,提煉出制約RAG效果的核心挑戰:
第一、資料價值的維度突破(檢索什麼)在知識庫構建層面,"垃圾進則垃圾出"(GIGO)定律持續制約RAG效能。面對海量異構資料(包括知識庫文件、語雀協作內容、小二備忘等結構化與非結構化混合資料),如何以識別核心資訊、釐清不同資料之間的關係網路,成為資料質量管控的關鍵前提。
第二、異構檢索的躍遷(怎麼檢索)在檢索機制維度,當前主流的同構空間檢索技術(如向量相似度比對)無法滿足小二問答場景的複雜需求。當面對服務領域常見的多源異構資料(不同資料之間、不同描述風格),如何進行異構檢索,實現精準的問題Q-答案A(-答案B)對映(一跳,多跳等鏈式檢索),成為提升資訊相關性的技術攻堅點。
第三、生成控制最佳化(怎麼用檢索內容)在生成控制層面,簡單的上下文注入策略導致模型持續暴露幻覺風險。亟需將檢索資訊轉化為可信賴的認知錨點,去除冗餘或者干擾資訊,實現"資訊指引生成"而非"啟用動態聯想"的良性互動。
第四、評估體系重構(怎麼評估)在質量控制維度,傳統評估指標(如BLEU、Rouge)無法精準捕捉RAG系統的特殊缺陷。需構建多維動態評估矩陣以實現技術改進的方向引導,這套評估矩陣不僅能量化RAG效果,更能為改進指明最佳化方向。
這些問題構成RAG技術進化的理論座標系。只有系統性解決資料質量管控、檢索正規化革新、生成控制最佳化和評估體系重構這四大命題,才能真正實現"知識增強"的價值閉環,重塑RAG智慧系統的可信度基石。
四、整體方案
本文從具體業務和技術挑戰出發,探討如何在知識邊界拓展與可信度困境的平衡中,提升RAG效能,幫助業務拿到結果。透過實際需求的碰撞與最佳實踐的探索,將這些經驗內化為RAG系統能力。
RAG 整體方案
4.1 資料價值的維度突破
作為RAG系統的核心基礎設施,知識庫的構建直接決定知識檢索與生成的質量邊界。前期,我們重點根據文件結構進行提供預分好段落的"chunk"語料(structure hierarchical),但這遠遠不足讓模型獲得更加深層次的資訊,也是造成模型生成幻覺的重要原因之一。後期,我們更加聚焦真實業務場景中的複雜挑戰:多模態資料格式的解析、跨chunk顯式和隱式關係建模(超連結/引用/章節關聯)以及業務專家隱性知識的結構化挖掘等。透過構建分層知識圖譜(Graph),我們開始實現從簡單文字/語義檢索,到複雜邏輯檢索的維度突破。
RAG 資料增強
下面重點介紹一下如何進行知識組織,構建一個健全的多層次知識庫。知識組織的核心是將解析後的資料構建成一個多層異構圖,捕捉不同資訊粒度和抽象水平之間的關係,支援下游任務的語義理解和推理檢索。第一步,抽象不同資料的特徵,挖掘它們之間的關係
第二步,進行多層次知識庫構建,核心流程可以概述為下述流程:Node(文件tree、工具、chunk等)->問題(原子粒度)->社群(問題聚類,該類的解決方案流程等)->主題(產品)->類目(產品線)
多層次知識庫構建
示例1:對一篇文件按照結構切分,提取文件、段落及細分Chunk,解析後挖掘核心問題、摘要、因素等特徵,並以文字和向量的方式儲存到索引中,同時構建Chunk之間的關係,維護一張Chunk圖譜。
文件Graph構建式示例
示例2:  根據工單之間和工單內部chunk之間的關係,構建工單的graph
工單Graph構建式示例
4.2 異構檢索的躍遷
前期,我們主要聚焦同構空間檢索技術,無法滿足小二問答場景的複雜需求。針對RAG系統在異構檢索場景下的核心挑戰(多源異構資料對映與Q-A的單跳和多跳匹配檢索問題),我們重點從以下幾個方面進行嘗試解決的:
  • 問題理解:透過對複雜問題進行拆解和多策略融合技術重構問題處理鏈路,解決使用者輸入與知識庫的語義鴻溝;
  • 檢索策略:增加文字異構檢索能力和構建"混合語義+向量+圖譜"三位一體的混合檢索架構,實現不同源資料的協同召回;並且引入迭代式檢索,提升複雜場景下的準確性。

4.2.1 問題理解

問題理解
我們針對複雜業務場景進行了三階最佳化:
1. 增加問題拆解能力
  • 拆解必要性判斷
  • 對於簡單問題(如“rds如何計費”),不進行拆解,直接輸出原始問句。
  • 對於複雜問題(如“郵箱子賬號如何設定郵箱的安全問題及安全手機”),嚴格按照獨立性原則拆解為多個子問題。
  • 避免無效拆解
  • 不將問題拆解為過於寬泛或無實際搜尋價值的形式。例如,“xxx的原因”或“xxx的排查流程”不作為獨立子問題。
2. 進行改寫策略最佳化
  • 報錯資訊保留:針對技術問題中的報錯碼(如“ERR bad lua script”),強制保留英文原文,並適當精簡上下文描述,確保改寫後的問句仍具備明確的搜尋價值。例如:
  • 原始問句:redis叢集代理模式不相容redisson分散式鎖,目前發現釋放時會提示如下:ERR bad lua script for redis cluster, first parameter of redis.call/redis.pcall must be a single literal string. 將redis引數改為script_check_enable就沒有問題了,有更好的解決方案嗎
  • 改寫後問句:Redis叢集代理模式下Redisson分散式鎖ERR bad lua script的解決方案
  • 多產品引用支援:對於涉及多個產品的問句,確保所有相關產品在改寫後均被正確引用。例如:
  • 原始問句:alibaba等保2.0映象和alibaba快速啟動有什麼區別
  • 不當的改寫後問句:['Alibaba等保2.0映象的特點', 'Alibaba快速啟動映象的特點', '兩者在安全合規性上的區別']
  • 正確的改寫後問句:['alibaba等保2.0映象的特點', 'alibaba快速啟動的特點', 'alibaba等保2.0映象和alibaba快速啟動的區別']
  • 上下文感知改寫:透過引入上下文資訊(包括產品資訊),我們增強了改寫模組對複雜場景的理解能力。模型會首先進行承接關係判斷,僅在必要時結合上下文進行改寫。例如:
  • 客戶的上文資訊:如果我的ECS伺服器被停機進行檢修等操作,我有什麼辦法能夠直接獲取到伺服器停機嗎?
  • 客戶當前問句:我想要你們那邊需要強制停機,我才接收報警,我應該選擇哪些
  • 改寫後問句:ECS伺服器如何設定僅在強制停機時才進行報警
3. 進行改寫效能最佳化
  • 合併改寫鏈路:將原有的兩輪大模型改寫壓縮為一輪,顯著降低了整體耗時(改寫模組處理耗時從4.5秒縮短至1.5秒,下降幅度超過60%
  • 旁路策略:對於命中高分知識的使用者問句,跳過改寫鏈路,直接進入搜尋環節,進一步降低耗時。
我們透過人工打標GSB(Good/Same/Bad)的方式驗證了改寫新方案相較於舊方案的有效性,得到結果如下:
  • Good : Same : Bad = 61.51% : 26.36% : 12.13%
另外針對拆解效果評估,我們使用大模型進行標註的方式,從以下幾個維度進行評估,評估結果見下表
1. 準確性:回答準確無誤,不存在答非所問,滿分3分
2. 完整性:針對使用者的問題回覆的內容比較全面,滿分3分
3. 語言表達:表達清晰且沒有語法錯誤,滿分3分
4. 引用資訊:準確且全,滿分3分
5. 推薦哪一個答案:1是推薦,0代表不推薦
可以從評估結果中看出,新方案在準確性和效率方面均表現出明顯優勢,特別是在複雜問題的改寫和拆解能力上有了顯著提升。

4.2.2 檢索策略

如果依託同構雙通道檢索(文字+向量),存在以下侷限性:檢索扁平化:單層級召回機制難以應對複雜問題拆解需求上下文缺失:多文件關聯檢索能力不足,導致大模型生成可信度降低;語義鴻溝:標準分詞器對領域異構同義詞的覆蓋度不足。
為了克服這些侷限,我們從同義詞庫構建&分詞器、增加混合語義檢索和邏輯召回和迭代式檢索進行了改進:
1. 同義詞庫構建&分詞器的選擇,特地收集來一些高頻異構同義詞,用來增加文字異構召回的能力,另外為了保證召回的準確率,我們在一些核心欄位上選用的查準率比較高的分詞器aliws->ik_smart。透過對比測試,我們發現兩者最佳化動作,在我們評測集上recall@10提升了4pt,不同同義詞之間的效能對比可見下表。
2. 增加混合語義檢索和邏輯召回,除了QQ檢索之外,增加QA檢索和圖譜召回,
  • 圖檢索:對關鍵節點進行向量和關鍵詞檢索,選擇topN 個節點的子圖資訊進行返回。
圖檢索
  • 混合檢索,總體策略是透過向量、文字和圖進行混合檢索,結合“小到大”策略獲得更豐富的上下文資訊,幫助大模型生成更精準的回答。
混合檢索
在工單檢索場景中的離線評估結果顯示,引入多語義召回和圖譜召回後,檢索系統的Top 5和Top 10準確率都有顯著提升,特別是在Top 5準確率上表現尤為突出。雖然多語義召回在Top 10準確率上有輕微下降,但結合圖譜召回後,整體效能得到了大幅提升。這表明新的檢索策略在提高檢索準確性方面效果顯著。
3. 迭代式檢索當首次搜尋未能獲取有效資訊時,需要調整搜尋策略需要分層次遞進式最佳化,逐步查詢直接解決 → 部分解決 → 關聯問題解決,避免“一次性檢索”的資訊汙染進而回復有誤。
Agentic RAG
4.3 生成控制最佳化
生成控制最佳化主要包含兩個核心方面:一是過濾掉無法解決問題的參考資訊,二是進一步完善參考資訊的質量和實用性。

4.3.1 過濾無效參考資訊

確保搜尋結果與使用者查詢的相關性是我們的基本要求,但更關鍵的挑戰在於如何保證檢索出的內容不僅相關,還能有效解決使用者的實際問題。使用者在進行搜尋時,期望得到的是能夠直接回答或解決其疑問的具體答案,而不僅僅是表面上看似相關的資訊。因此,如何有效地篩選出那些雖然相關但並不能真正解決問題的內容,對於提升檢索增強生成(RAG)的質量以及最佳化大型模型的表現至關重要。
前期,我們在生成內容的相關性方面做了一些初步探索,但尚未實現落地應用。進入2024.4月之後,我們認為進一步深化這方面的工作尤為重要。我們將重點放在透過資料增強來挖掘和理解問題和答案相關性的邏輯上,並引入檢索增強相關性(RAR, Retrieval-Augmented Relevance)技術,賦予大模型判斷“不相關”的能力。
Retrieval-Augmented Relevance(RAR)
以下是RAR這一過程中的幾個核心方法:
1. 相關性資料:利用小二/使用者反饋及高參數大模型分析,提煉出用於增強領域理解的相關性評估標準/邏輯。
2. 鏈式思維提示:設計一系列提示語句,引導模型逐步推理複雜問題,提高其邏輯分析能力和答案組織的條理性。
3. 動態少量示例學習:根據具體場景動態調整參考案例的數量,以最佳化模型對不同情況的適應性。
4. 相關性級別定義:明確界定查詢與文件間相關性的等級,確保模型僅基於最相關的資料生成答案,從而保證資訊的準確性和實用性。我們設定了四個相關性級別:
經過多次測試,包括採用不同的模型和不同指令提示策略,結果顯示Qwen 2.5 72B搭配Thoughts功能表現最佳,將錯誤召回率從15.97%可以降至5.03%,同時提高了68.5%的錯誤減少比例,F1分數達到了94.28%。這表明了在提高搜尋結果質量和使用者體驗方面的顯著進步。

4.3.2 完善參考資訊的質量

隨著大模型支援的context長度越來越長,我們從以下幾個方面對參考資訊進行最佳化和完善:
1. 支援更長上下文的響應:採用“small to big”的策略。為大模型提供更豐富的上下文資訊,使其能夠在生成過程中更好地理解和利用參考內容,從而生成更加全面和準確的回答。
2. 結構化ID過濾機制:為每一條參考資訊分配唯一的結構化ID,以便在搜尋過程中快速定位和篩選相關內容。這種機制不僅能提高資訊檢索的效率,還能減少冗餘資訊的干擾。
3. 多樣化圖片引用方式:為了最佳化生成內容的質量,我們對四種不同的圖片引用方式進行了評估,目的是提升圖片引用的比例,以豐富生成內容的形式和資訊維度。以下是每種方式的定義及評估結果的詳細分析:
  • 圖片引用方式說明
  • Option 1: 不解析圖片內容,僅保留原始圖片標記(![原始資訊])。
  • Option 2: 使用圖片的摘要資訊(![圖的summary])替換原始圖片標記。
  • Option 3: 在圖片摘要資訊的基礎上增加描述性內容(![圖的summary]+ 圖的description),並替換原始圖片標記。
  • Option 4: 將圖片的摘要資訊和描述性內容(![圖的summary] + 圖的description)附加到每條參考資訊的末尾。
  • 評估結果,對於兩種模型(Qwen 1.5 72B 和 Qwen Max),Option 4 的出圖比例均顯著優於其他方式,得分最高。這表明將圖片的摘要資訊和描述性內容附加到參考資訊末尾的方式能夠最大程度地提升生成內容的質量/出圖比例,另外Qwen Max 的整體得分顯著高於 Qwen 1.5 72B,表明更大規模的模型在處理多樣化圖片引用時具有更強的能力。
4.4 評估體系重構
RAG Diagnoser
隨著我們對RAG鏈路最佳化工作的不斷深入,傳統的評估方法逐漸顯現出侷限性。前期,我們主要依賴檢索準確率和生成準確率這兩個核心指標來衡量系統表現,但這種方法過於單一,難以全面反映複雜業務場景中的實際效果,也無法為後續最佳化提供明確的方向指引。因此,我們在本年度構建了一套全新的評估體系“RAG Diagnoser”。這套體系透過細粒度的診斷分析,可以幫助團隊從粗略判斷轉向精準定位,從而實現技術突破。
RAG Diagnoser的核心目標是成為RAG鏈路最佳化的“後盾”。它透過對模型輸出的每個環節進行深入剖析,幫助團隊快速識別問題根源,並制定針對性的改進策略。具體來說,這套體系具備三大功能:支援細粒度評估、識別效能瓶頸以及指導迭代最佳化。為了實現這些目標,第一步,我們先對使用者Query進行了細緻分類。在評估RAG時對問題進行分類這種模式在之前的工作中也不鮮見,例如阿里NLP團隊提出的CoFE-RAG從通用RAG的視角將Query拆分成了Factual, Analytical, Comparative, Tutorial四類[4]。在RAG Diagnoser中,Query的不同類別會影響後文提及的原子事實的定義和檢查方式。我們從對客RAG和智慧輔助的實際應用的角度出發,經過多輪迭代標註和分析,構建了一套符合自身業務特點的Query分類體系,涵蓋以下主要類別:
第二步,我們需要對不同型別Query抽取特定的Ground Truth作為評估Target,得益於我們業務特性,我們可以直接從歷史工單中提取相應Query的Ground Truth。
第三步,為了實現細粒度評估,我們引入了“原子事實”這一概念,作為評估的基礎單元。所謂原子事實,是指在RAG鏈路診斷過程中能夠被單獨分析、不可進一步拆分的具體且可驗證的事實或結論。這一概念的靈感借鑑了亞馬遜RAG-Checker[5]和經典RAG評測框架RAGAS[6]中的"claims"。例如對於以下句子:“尼羅河是一條向北流的大河,位於非洲東北部。它最終流入地中海。”可以提取出3條原子事實:尼羅河是一條北流的大河、尼羅河位於非洲東北部和尼羅河流入地中海。在我們的場景中,原子事實並不是固定的定義,而是根據業務特點進行了定製化設計。透過原子事實化,我們可以清晰地判斷模型是否遺漏了某個關鍵資訊,或者是否違背了某項事實。相比傳統端到端的評估方法,這種細粒度的方式更能揭示問題的本質。
第四步,我們會基於原子事實進行效能評估,比如根據RAG的回覆與Ground Truth在原子事實粒度上的一致性,計算整體的原子事實準確率、召回率、矛盾率等指標。這些指標可以幫助我們快速瞭解模型的整體表現。為了更深入地挖掘問題根源,我們還會對RAG鏈路的各個模組分別進行評估,以精準定位問題來源:
  • 搜尋診斷:檢查原子事實在檢索各階段的覆蓋率,判斷是否存在召回不足的問題。
  • 改寫診斷:分析改寫前後搜尋到的Chunk是否包含正確的原子事實,評估改寫的效果變化。
  • 回覆診斷:檢查生成模組是否存在遺漏或錯誤的原子事實,判斷生成質量。
以下是一個針對“Factual-Y/N”類Query的回覆診斷模組的具體案例。我們將詳細展示如何透過原子事實提取和對比,識別模型輸出中的問題,並指導後續最佳化。根據業務特點,我們在處理Factual-Y/N類Query時的兩點特殊設計也可以在下例中看到:對Ground Truth進行了格式化設計,第一句固定回答“Yes/No”;並確保至少有一條原子事實直接對應原問題的答案。
{"Query來源工單號":"xxx","使用者問句":"g8i伺服器支援二次虛擬化嗎","Query分類":"Factual-Y/N","從工單中提取的Ground Truth":"不是的。僅彈性裸金屬伺服器和超級計算叢集支援二次虛擬化,這些產品的規格都較大。g8i伺服器屬於通用型例項規格族,不支援二次虛擬化。","Ground Truth原子事實列表":["g8i伺服器不支援二次虛擬化。","彈性裸金屬伺服器支援二次虛擬化。","超級計算叢集支援二次虛擬化。","彈性裸金屬伺服器和超級計算叢集的規格都較大。","g8i伺服器屬於通用型例項規格族。"],"大模型回覆":"您好,g8i伺服器屬於彈性裸金屬伺服器,支援二次虛擬化。您可以利用這一特性在g8i伺服器上安裝虛擬化軟體,建立虛擬機器。更多詳情,可參考[彈性裸金屬伺服器概述](https://help.aliyun.com/document_detail/60576.html)文件。","大模型回覆原子事實列表":["g8i伺服器屬於彈性裸金屬伺服器。","g8i伺服器支援二次虛擬化。","您可以利用g8i伺服器的二次虛擬化特性在伺服器上安裝虛擬化軟體,建立虛擬機器。"],"大模型回覆中與Ground Truth矛盾的原子事實":["g8i伺服器不支援二次虛擬化。"],"Ground Truth中與大模型回覆矛盾的原子事實":["g8i伺服器屬於彈性裸金屬伺服器。","g8i伺服器支援二次虛擬化。","您可以利用g8i伺服器的二次虛擬化特性在伺服器上安裝虛擬化軟體,建立虛擬機器。"],"分析結論":{"矛盾的原子事實":"大模型回覆中的“g8i伺服器支援二次虛擬化”與Ground Truth中的“g8i伺服器不支援二次虛擬化”直接矛盾。此外,“g8i伺服器屬於彈性裸金屬伺服器”也與Ground Truth中的“g8i伺服器屬於通用型例項規格族”相沖突。","遺漏的原子事實":"大模型未提及“彈性裸金屬伺服器支援二次虛擬化”和“超級計算叢集支援二次虛擬化”這兩條重要資訊。同時,關於“彈性裸金屬伺服器和超級計算叢集的規格都較大”的補充說明也被完全忽略。","引入的錯誤資訊":"大模型引入了“您可以利用g8i伺服器的二次虛擬化特性在伺服器上安裝虛擬化軟體,建立虛擬機器”這一錯誤描述,進一步誤導使用者。"}}
最後,根據評估結果,明確各模組的效能短板,並提出針對性改進措施。例如,若發現檢索模組召回不足,則可考慮擴充同義詞庫或最佳化混合檢索策略;若生成模組頻繁出現幻覺,則推動相關性判斷機制的加強等。
五、未來展望
回顧過去一年,我們的工作重心主要聚焦於提升RAG系統在通用問題解決能力上的表現,成功完成了小二輔助Copilot RAG從0到1的建設,並顯著增強了大模型的信任度。同時,我們也開始在一些複雜場景中進行初步探索,為未來的發展奠定了基礎。展望未來,我們將邁向更深層次的技術突破與場景落地,在以下三個關鍵方向上深入探索:
1. 多模態檢索:進一步提升系統對文字、圖表、影像等多模態資料的理解與融合能力,以應對複雜的跨模態任務需求。
2. DeepSearch完善多層次異構圖的構建,最佳化跨文件推理與資訊連結能力;把長期的思考和推理過程融入到搜尋系統確保能夠高效處理需要深度邏輯推理的複雜任務。
3. 評估與最佳化:建立更加科學、全面的評估體系,推動RAG系統在實際應用中的持續迭代與效能提升。
我們相信,隨著推理大模型的飛速發展,結合在這些方向上的深耕細作,下一階段,我們服務領域的DeepRAG將迎來質的飛躍,為使用者帶來更智慧、更可靠的服務體驗,敬請期待!

參考文獻

[1] https://arxiv.org/pdf/2503.09567
[3] https://menlovc.com/2024-the-state-of-generative-ai-in-the-enterprise
[4] https://arxiv.org/abs/2410.12248
[5] https://github.com/amazon-science/RAGChecker
[6] https://github.com/explodinggradients/ragas
PAI部署多形態的Stable Diffusion WebUI服務
本方案提供了方便、高效的模型部署產品,並支援根據實際需求,配置不同的服務版本及服務引數。具有分鐘級部署上線,方便快捷、開箱即用,多版本部署方案,引數可定製化調整的優勢。
點選閱讀原文檢視詳情。

相關文章