阿里妹導讀
自2023年大模型技術進入大家視線後，業內出現了較多基於大模型技術和RAG對智慧問答機器人的探索，利用大模型對產品的相關文件學習，建立個人/平臺助手以減少客服的人工作業量。在我做RAG這大半年的時間裡，從開始很堅定認為RAG一定是非常有前景的技術方向之一，到中間一度迷茫RAG在知識問答上是否真正能比傳統文件檢索技術帶來更多的實用價值，再到逐漸嘗試並摸索到現在的一整套較適合我們應用演算法團隊訓練和部署資源均不富裕情況裡的最佳化方案並在逐步平穩落地中收穫了試點平臺owner的認可。無論是出於深化思考還是技術成長的角度，需要在這個節點去記錄下在這個過程中產生的對RAG技術的疑問及隨著一步步探索和思考所形成的自己的解決方案。由於RAG的相關工程全鏈路及生成微調等相關分享在網路上也較多，單從知識維度綜合去講探索的文章較少。因此本文的行文邏輯沒有按RAG整體技術架構去聊，而是單從知識增強的多角度去看RAG問答的難題與最佳化思路。領域本身較新，在nlp也是半路出家，思考大於經驗，有不合理的地方歡迎大家討論和指正。
RAG背景
檢索增強生成（Retrieval-augmented Generation），簡稱RAG，是一種利用預先檢索知識庫來增強大模型生成能力的方案；簡單來講，對於大模型在業務上的落地來說，我們用的大模型一般都是較好的開源通用大模型，但通用大模型只有通用的歸納總結能力，並沒有對領域問題回答的能力。因此，實際落地時如何讓大模型能領域化回答問題，有兩種方案，一種是用領域化資料再去訓練和微調，另一種則是外接領域化知識庫，對使用者提問先檢索知識庫再由大模型生成回答。
我們是做內部的平臺答疑助手，在我們的場景下，平臺的變動是頻繁的，對知識庫的更新編輯是非常多的，因此去訓練和即時更新大模型的成本很高，所以很自然地開始了基於RAG的這一套技術方案。
這個技術思路確實很直白也很簡單，三兩句即使沒有接觸過大模型演算法的同學也能對RAG這個技術的概念有一個認知（檢索文件+給大模型生成答案），且落地成本很低，無論是透過開源框架還是利用內部的RAG、AGENT平臺都能快速上手搭建一套屬於自己的知識庫問答能力，但這些能力在實際落地效果差異性很大。五月去北京參加AI Con大會，會上聽了很多RAG在領域裡的實踐，一位同行的師兄的感想裡寫了這麼一句話，也是我做RAG過程中逐漸對它的認知：“簡單做做很簡單，複雜做做很複雜”。在實踐中也發現，很多比較先進的技術研究的也是大模型生成的部分，落地上很多做法對於知識構建這一塊更是“簡單做做”居多。所以這篇文章也是想先從“簡單做做”分析目前的RAG中的知識難題，再從為解決這類知識難題我們所做的一些探索的思路。
“簡單做做很簡單”的RAG知識難題分析
RAG的“簡單做做”在於無論是用開源的框架還是一些中心化RAG平臺所提供的能力，我們其實可以很容易就搭建屬於自己的一套RAG問答能力，這套RAG能力往往是完整的，涵蓋【query改寫】、【向量嵌入】、【多路檢索】、【大模型總結】多個模組；這種能力從0-60分的搭建是快速高效的，大模型能從大量知識庫中找到一些相關知識，並做出一些像樣的回答（找不到相關知識時候也能作出看似合理的回答）。但隨著將該類模型不止用於簡單閒聊的場景，而是在實際需要解放人力的場景下落地的時候，這樣的能力給使用者的實感是空有智慧外殼，實際能力並不如傳統檢索。
上圖也是一篇比較全的RAG綜述[1]裡對RAG發展的框架概述，我們今天想聊的知識增強在這張RAG技術框架圖裡也只是不顯眼的【Documents-Indexing】，簡單做做的【文件分割-儲存】也是實現上最簡單的一個步驟。但簡單做做後的效果往往不如人意，以下兩個問題也是我們在實踐過程中的思考：
從知識角度分析，為什麼簡單做的RAG看上去會有人工智障感？
人工智障感主要是源於大模型並沒有理解灌入模型的知識，大模型去總結很多文件時缺乏一些領域內常識，又在雜亂的文件中進行生成，會有較多幻覺。（一個沒有常識的人，看了點看似相關可能無關的隻言片語，也很難不胡說八道）因此，核心問題在於【大模型悟性不高且知識質量低】，解決方案也是兩類並行，提高大模型的悟性【Prompt工程裡儘可能詳細引導/參考微軟RAFT方法(2)微調/許願開源大模型越來越牛..】，另一類即是從源頭上提高外接給大模型的知識質量，即是我們這篇文章聊的重點。接下來進入正題，灌入大模型的知識質量上存在哪些需要解決的難題？
從知識角度思考，灌入大模型的知識質量上存在哪些需要解決的難題？
這個問題最直接的回答是本身業務側提供的知識庫不夠/質量不行，實際上這個原因也確實有影響；但在實踐後也可以發現，一些演算法上的設計同樣影響大模型的知識質量。
1. 知識分塊矛盾
一般來說，RAG的第一步就是先對文件進行分塊，簡單做做的第一步就是先按預設的大小對文件進行分塊，overlap設個小點的值以防句子被截斷。但這裡在實踐中容易出問題的點在於RAG中檢索和生成所要求的粒度不同：
-
要想檢索器檢索的精準，需要小分塊； -
要想大模型生成時候參考得多，需要大分塊； -
同時，即使有overlap，但文件語義很可能恰恰在分塊處隔斷。如下圖所示，本身包含的一致性語義資訊更多的章節很可能會被分在不同chunk中。
因此，只通過預設大小一致的分塊策略及檢索生成用同樣的分塊策略都對RAG的效能損失極大。
2. 知識本身缺失
假設分塊問題能解決，另一個知識質量上更難的點在於，知識不存在於任何一個分塊裡：
-
其一，答案可能存在在文件中，但不存在確切的某一分塊中。從query到document本身的語義鴻溝來說，使用者的問題可大可小，和沉澱的文件的語義維度不可能始終一致；
-
其二，一些先驗的領域型知識並不在確切的分塊裡，但大模型沒有該類領域性常識時在回答具體問題時較為困難；
-
其三，一些過往問答裡出現過的知識僅能依靠業務側人工整理才能進入知識庫。
3. 知識相互衝突
假設知識全都call出來，但call出來的知識本身不清晰或者是不同的文件中對相似問題的詮釋不同，模稜兩可的知識容易讓大模型想不通以至於幻覺。
總結歸納到以上三點的時候，也慢慢清晰了：為什麼明明知識管理在RAG中重要性極高，但調研時較少演算法研究集中這塊。因為理想化情況下，知識本身是ok的我們才會讓大模型去外接知識；同時，對於人員投入較多的場景來說，由有經驗的同學去保證知識的正確是最優解。但在我們的場景下，往往是業務難以投入太多人力配合知識補充，內部知識庫更新也並不會有嚴謹性保證，因此，結構化較好的語雀文件對我們來說已經是最佳知識庫源。如何利用智慧化演算法來讓這些文件發揮它最大的作用也是我們在最佳化中最主要的方向。
“複雜做做很複雜”的RAG知識最佳化實踐
對應於前一章節所帶出的三類知識質量上的問題，【知識分塊矛盾】【知識本身缺失】和【知識相互衝突】，這一章節將會以思路為主介紹下對這三類難題的最佳化實踐。
一、從【知識分塊矛盾】出發的知識檢索最佳化
1. 知識分塊最佳化
一開始做知識分塊最佳化完全源於我們所用的資料基本上都是內部平臺的語雀文件資料，內部平臺的文件一般都是很規範，語雀文件的markdown屬性也是天然包含了很多資訊，能把這類結構化的markdown文件裡的標題資訊用上一定是能比純文字長度分割提升明顯很多。但即使是開源裡知名度最高的索引框架LlamaIndex，對於Markdown文字的分割都是十分詭異的思路（相對來說比較新的中心化的框架確實難以整合符合特定場景需求的演算法）。
到這裡，我們就放棄了直接用開源類的想法：
-
直接按結構分割可能會造成大的chunk過大、小的chunk過小； -
直接按長度分割則會造成結構資訊丟失。
因此，在該部分，我們結合了結構分割和長度分割兩種，實現了“先結構化分割-對大chunk再長度分割-對小chunk進行結構化合並”的三步分割邏輯，對每個文件進行結構-長度均衡的塊分割。
具體步驟如下：
-
step1: 遞迴分割文件，得到最小標題單元的Chunk（保留了各級標題資訊）。
-
step2: 對最小標題單元的chunk進行判斷，若chunk長度較長，按長度進行二次分割，獲取包含標題資訊的最小單元Segments。
-
step3: 對Segments進行判斷，從最低階標題到高階標題開始依次判斷並在長度範圍內合併獲取包含了segment周圍儘可能多語義資訊的Blocks【這一步在實際實現時使用的是歸併演算法的思想，按標題從低階到高階依次歸併】。
我們實現的演算法所構建的知識Blocks既包含各級標題資訊，對大chunk有分割；對小chunk合併又是基於結構的歸併，儘可能多地包含了附近的上下文資訊。因此給大模型的知識塊儘可能實現了語義和長度的平衡。
2. 檢索-生成的塊粒度解耦
由於檢索中文件塊越小、檢索越精準，而大模型生成階段則是文件塊越大、生成越全面，原有的檢索文件塊-大模型生成的思路會造成檢索和生成兩階段的效果削弱。
因此在對文件進行三步分割過程中，我們分割的不同粒度的知識在最終檢索過程中均是有用的。
-
Sentence：對chunk進行句子分割得到，會再拼接標題等結構化資訊；細粒度的知識適用於檢索階段。 -
Segment：見上一節，其包含了結構化段落資訊；完整的語義知識適用於重排階段。 -
Block：見上一節，其包含了Segment周圍儘可能多的語義資訊；更多的上下文資訊適用於大模型生成階段。
我們對檢索生成兩階段的文件的塊粒度進行了解耦，實現了“先句子粒度檢索-分割段粒度重排-結構化塊生成”的從小到大索引。
二、從【知識本身缺失】出發的知識增強擴充
知識本身缺失，很自然的思路就是對知識庫做增強擴充；擴充知識庫，在靠人力補齊外，我們探索了幾類藉助模型去從多個維度擴充的方法：擴充知識粒度解決Q-D不匹配的問題，擴充領域知識來補充大模型的先驗知識缺陷，擴充知識來源豐富本身知識庫。
1. 知識粒度擴充-通用性知識增強
針對由於語義粒度上Query-Document匹配困難的問題，現有的解決思路做的嘗試都是把讓Q-D進行對齊，要不把query也擴充到document粒度，要不把document精煉到query粒度。
將query擴充到document粒度
這類方案參考HyDE[2]，當query進來後，預先去生成可能的答案，再由可能的答案去檢索相關document。這類方案的動機也很明確，在很多RAG的落地實踐中看起來也可行，但由於對query的答案預先生成需要本身的大模型線上服務資源翻倍、等待時間上也大加長，在我們的場景中並沒有去嘗試。
將document精煉到query粒度
該類方案的思路基本上是藉助大模型做文件預先提取，文件摘要，做跨文件的預先關聯。方案很多很明確，結合場景裡的具體問題分析我們所需要的粒度擴充，再利用大模型輔助即可較快實現離線的一系列抽取。我們透過知識增強，下表中的檢索塊指檢索時用query所匹配的塊內容，生成塊指匹配到檢索塊後給大模型進行生成的塊內容。
|
問題型別
|
擴充粒度
|
檢索塊
|
生成塊
|
|
細粒度query
|
從文件中預先抽取使用者可能問的3-5個核心問題
|
使用者可能問的核心問題
|
對應文字塊
|
|
粗粒度query
|
對段落/文件粒度進行摘要後存入索引
|
段落/文件粒度的摘要
|
對應段落/文件（注意長度分割）
|
以上無論是細粒度query還是粗粒度query都還是停留在單文件的多粒度知識擴充上，跨文件場景下的query仍然無法得到解決。解決跨文件的query問題本質上還是解決文件間的關聯問題，提到關聯很自然的也就來到了Graph這項技術。因此，我們嘗試了微軟的GraphRAG[3]思路來解決跨文件的關聯問題。線下跑的程式碼確實是有效的，不過GraphRAG的檢索目前用在線上的成本很高【更新索引所需資源多，線上Graph儲存鏈路有待我們探索】，所以也不符合我們的低成本最佳化方案。但探索到了有用的技術哪能輕言放棄！雖然GraphRAG全鏈路尚未在我們的場景的線上鏈路裡落地，但思路用在了下一節先驗知識擴充裡。
2. 先驗知識擴充-領域型知識抽取
這一節想要解決的知識缺失問題也是領域化智慧問答裡一個老生常談的話題，許多模型預先並不知道一些領域內的先驗知識，單憑檢索出來的相關內容進行回答總會有效果不好的問題。因此，也有許多領域化的探索想方設法將領域化知識傳入大模型中。這類探索也大致可以歸納成以下兩類。
將領域型知識內化進大模型
將領域型知識內化進大模型也就是讓大模型在回答前就已經學習了相關的領域類知識，最常用的就是領域化資料微調方案。一開始都會去嘗試微調，但我們前期的微調效果不佳，後續沒有再走這條路的原因有幾個：
-
資料收集對我們來說難度高，需要有業務的同學幫忙去整理一些領域高質量資料，同時領域化資料也需要配比一些通用型資料進行微調，資料質量也很影響最終的；
-
不同研發平臺的領域化概念可能不同，為每個平臺都定製領域化微調模型並部署，這個資源上是完全不可行的；
-
RAG做到後面，其實生成部分用的開源大模型的更迭是很快的，我們不太可能及時去訓新開源的模型，換更新的大模型的收益又比用微調後的原有模型增益高。
這個問題也是我們後續一個可能的方向，如果後續能有一些知識編輯的策略，可以低成本地將我們內部的所有的研發文件輸入到模型的某個記憶單元，在模型層面也就相當於做了增量的預訓練。但短期內，在落地上更有效的方案還是將領域型知識顯示地灌入大模型。
將領域型知識顯式給大模型
實際落地上，我們暫時沒法讓模型長期記憶裡儲存領域型知識，於是選擇的方案是對query進行知識檢索的同時也去檢索一遍相關領域專有知識，類似於MemoRAG[4]的機制去建立我們的領域Memo Model。這套方案的核心也是在於領域的Memo Model如何構建。
如果有專心看到這裡的朋友可能會想起來，上一節有個實用但還沒用起來的技術是GraphRAG[5]。在這裡，我們構建了基於領域圖譜的MemoRAG。由於我們在構建領域圖譜的時候，大模型遍歷了整個知識庫，它能獲取的領域關聯在一次次遍歷和總結時候的可用率是非常高的。
構建領域圖譜的具體步驟如下：
-
step1: 模型會先多次讀取文件分塊，從中提取出領域實體（可結合不同場景規定實體型別）。 -
step2: 在遍歷完所有文件分塊後，模型會再多次遍歷提取出的領域實體，將其中的相似相關實體進行合併再總結。 -
step3: 對合並後的實體，模型再根據文字塊去提取實體之間的關聯。 -
step4: 對抽取的實體和關聯做社群發現，並對所聚集的社群做報告摘要
因此，在一整個鏈路後，模型能夠獲取跨文件完整的領域實體相關知識。對每個實體，模型也會做社群發現，生成社群報告。這類實體和社群報告，在這裡完全可以作為Memo Model的重要組成。query進來後，我們首先對query分詞去我們的領域Memo Model中檢索屬於該租戶的相關領域線索，並後續一併給模型，顯式地將領域知識灌入模型。
3. 知識來源擴充-經驗性知識沉澱
這一節比起前兩節，對知識擴充的思路會更直給。說白了就是，知識庫裡內容不夠的話，我們多從其他相關知識源來挖點內容。不過每個場景下可用知識源都不會太相同，為什麼還是把這一節放上來了，主要還是在於智慧答疑的場景下，一般都是先有人工答疑再有用智慧問答替代人工答疑這個過程。所以，人工答疑的資料往往是語雀知識庫外、甚至是超越語雀知識庫的最有用的知識源。
但歷史人工會話如何用在RAG也是一個比較難的命題，資訊挖掘存在幾個難點，其一為資料來源較雜亂，不同於標準化的書面文字，其中摻雜了較多口語化內容，且格式不一，其挖掘難度大；其二為關鍵資訊關聯性低，往往使用者的問題是透過多輪互動後才能得到解決方案，解決方案較為分散；其三為資訊準確度要求高，若挖掘出來的資訊準確率較低，在後續的檢索中會削弱模型效能，降低智慧問答效率。
在歷史會話的挖掘上，我們也在調研後考慮了兩個方案。
歷史會話總結與摘要
初期調研時，針對大部分歷史會話的探索基本上還是微調大模型對會話進行總結和摘要的能力。但在我們的場景下，一些研發平臺的人工答疑鏈路會很長，直接利用整個總結資料灌入知識庫又回到了Query-Document匹配難的問題。這裡要解決也可以再進行細粒度query抽取，從總結裡再生成問題和對應答案。但整體方案這樣看起來會有個誤差累積的風險，所以我們在構思，是不是也可以直接微調一版能夠從歷史會話中直接抽取有效問答對的模型。
歷史會話問答對挖掘
如上述思路，我們將方案轉變到歷史會話的問答對直接挖掘。下圖為利用會話問答對大模型對歷史工單進行問答對抽取的推理流程。第一個核心模組是會話問答對大模型，這裡我們利用了多尺度的問答對提取策略。針對會話問題中多輪迴答的複雜性，單步提示難以讓模型同時感知到全域性和區域性的知識。我們設計了一種分步提示（Multi-Step Prompting）策略，該生成策略用於訓練資料準備、訓練任務構造及大模型推理三個部分。本策略將針對歷史會話的問答對抽取分解為兩層子任務，分別構建不同的提示詞prompt，包括全域性層和區域性層。
-
全域性問答對抽取：由於往往一個歷史會話工單中使用者有最初進入提問的主要問題，而該類主要問題的解決方案往往橫跨了整個對話。因此在全域性層，首先要求大模型熟悉會話全文並理解全文判斷會話中客服是否解決了使用者所提出的主要問題，若解決了，則輸出全域性的問答對。
-
區域性問答對抽取：考慮到內部研發問題的複雜度往往較高，在多輪對話中往往存在多個衍生子問題，該類問題對於知識庫建設也起著較為關鍵的作用。因此在區域性層，要求大模型從區域性出發，判斷使用者可能提出的業務問題及客服是否有解決方案，若有解決方案，則輸出多個區域性問答對。
針對上下兩層子任務，我們分別設計了相應的提示詞，基於這個策略我們借用開源模型抽取+人工檢驗標註了基於2000+個會話的問答對資料，最終可用資料有1300條。我們用這批資料lora微調了Qwen-14b的模型。為了保證問答對抽取的完整性，並未限制抽取的問答對的數量，因此區域性抽取模組的問答對抽取自由度較高，導致可能會有髒資料產生。我們也利用大模型對抽取的問答對作質量評估，將質量較低的問答對篩選掉。由於前文所述的會話問答對大模型在經過對話資料微調後，對於對話有相應理解能力，此處我們僅用該大模型作簡單的評估即可對部分無關問題進行剔除。我們抽取問答對的可用率在試點租戶上可達70%。
三、從【知識相互衝突】出發的知識標籤策略
前面兩章講的還是知識本身搜不到的問題，這一章節關注的問題是在於，我們之前會有一些case，是在知識庫非常大的智慧體下面，會發現有這樣一種bad case：對同一個query，在不同的文件裡確實是都能找到回答，但這兩個文件的質量又確實有差異。一方面是在面對這類問題時往往大模型是無法直接判斷錯對優先，另一方面是本身模糊不清的知識更易讓大模型產生幻覺。
因此，我們在構建知識庫時，可以考慮運用一些天然的知識標籤和低成本構建的知識標籤來增強知識庫以化解知識衝突問題。
1. 從知識標籤到文件優先順序
為了前置去解決給大模型的知識文件衝突的問題，我們需要在給大模型前事先判斷出文件之間的重要性次序，可以利用文件的一些內容以外的資訊作為文件標籤來進行文件之間的相對優先順序比較。
從天然標籤上來說，文件的時間資訊及閱讀量資訊均可作為參考；從人工標籤上來說，配合的業務方能從專業的角度進行簡單的標記，將一些高保障知識庫優先順序打高、非常用知識庫優先順序打低。
標籤的用法上，一方面是可以前置做一些規則上的定製化過濾；另一方面，當我們需要的只是在大模型思考時候減少知識衝突帶來的混亂時，則是可以將其綜合對文件做相對的優先順序分數區分。
2. 文件優先順序運用思路
從文件標籤中獲取優先順序後，到底如何使用一開始也比較困擾。調研大部分的落地方法裡一般在這裡會帶過說結合場景設計策略。最開始和業務同學聊說希望能加入文件優先順序，能夠更明確地剔除一些無效文件，把高質量文件的權重調高。我們嘗試了在多個環節將文件優先順序化成權重，再將這個權重做一些策略加入到檢索/重排分數中，但一番嘗試後發現這個調權過程非常之沒有道理。權重調低了，這個優先順序基本沒用；調高了，一些高度相關但優先順序不高的文件在一些query裡又會完全失效。且即使對現有評測集裡的case利用權重我們能調出一版最優的結果，但這些權重對後續未知case就全是黑盒，並不是合理的應用方法。後續，我們在實踐中改變了做法。
篩除無關文件
文件優先順序一個最簡單有效的用法是，語雀知識庫中大量知識，但很多平臺的早期更新文件或者是個人記錄其實都是無關緊要的資訊。因此，文件優先順序可以用在過濾無關文件上。
結合CoT的Ref Selection
而對於都可能有用的文件來說，檢索召回階段的目標是召回相關文件，那這個階段優先順序加權怎麼都不合理，因為必然會影響本身文字的相關性。我們不在檢索中直接按優先順序排序，而是將原有的透過相關性檢索出來的文件和文件之間的相對優先順序均透過prompt的方式告訴大模型，啟發大模型先去選出要參考的文件再從中進行作答。
這類優先順序用法要解決的是具體兩類問題：1. 一類情況是我們已經知道了哪些是相關的，但這些相關文本里可能有些知識衝突或者是一些重複時候，優先讓模型參考優先順序高的答；2.還有一類情況是，對於重排後文檔整體相似度閾值，如果說檢索出來的文件相關性其實都低於某個水位的時候，讓模型優先參考優先順序高的（至少答的是比較高質量的內容）。
在實踐時的一個小trick在於，讓模型選出參考文件時讓模型給出簡單的思考過程會比讓模型直接給出參考文件的效果好很多。這個trick的有效性可能在於，作為生成式的模型，大模型確實是在生成過程中進行思考，而辨別文件相關性、知識衝突這些需要思考的指令又十分需要思考過程。
我們也發現，讓模型選出參考文件優先順序確實是只能給模型輔助，唯一風險是優先順序的使用有時候也比較黑盒（有的時候真的不懂模型的想法）。後續我們也會嘗試微調的方案，在參考文件的選擇時也可以結合RAFT的思想對模型進行微調，讓模型具有在一些衝突時候優先選擇優先順序高的文件作答的能力。
未來規劃
我們目前的研發助手業務會持續跟進，除了線上鏈路上的最佳化外，後續在知識增強上依然會持續最佳化。對很多線上case的分析上來說，目前我們對知識增強做了很多方案上的探索，整體思路已大致確立，但仍有一些落地中實用但難做的點需要繼續探索：
-
歷史會話的深度挖掘：不止一個業務方反饋非常需要對歷史會話內容的挖掘，這塊不止包括問答對抽取能力的最佳化，也包括如何配合進行歷史會話的智慧化分析、整理高頻問題。目前也是在探索中。
-
多模態知識的擴充：我們目前擴充的知識庫也都是基於文字資訊，對圖片資訊和文件連結的處理相同，將其作為url連結，前端上能對模型吐出的圖片url連結進行展示。所以，如果大模型從這段話裡認為這個圖片資訊需要展示會吐出，但這個做法也是損失了圖片本身的資訊。後續我們也需要嘗試利用圖片資訊再擴充知識庫。
參考連結：
[1]https://arxiv.org/pdf/2312.10997
[2]https://zilliz.com/learn/improve-rag-and-information-retrieval-with-hyde-hypothetical-document-embeddings
[3]https://arxiv.org/pdf/2404.16130
[4]https://arxiv.org/pdf/2409.05591
[5]https://arxiv.org/pdf/2404.16130
手把手教學構建 RAG 應用
本方案基於AnalyticDB for PostgreSQL的高效向量引擎與阿里雲自主研發的通義千問LLM模型，構建一個高效能的檢索增強生成（Retrieval-Augmented Generation, RAG）應用，實現企業的AI智慧客服，更高效地解決客戶問題。
點選閱讀原文檢視詳情。