阿里妹導讀
筆者結合實踐經驗以近期在負責的複雜表格智慧問答為切入點，結合大模型的哲學三問（“是誰、從哪裡來、到哪裡去”），穿插闡述自己對大模型的一些理解與判斷，以及面向公共雲LLM的建設模式思考，並分享軟體設計+模型演算法結合的一些研發實踐經驗。
一、前言
2022年11月，ChatGPT平地一聲雷，開啟了“大模型+”時代，為整個AI軟體市場帶來了無限商機，據ARK Invest的首席未來學家Brett Winton預測，到2030年左右，AI軟體市場的市場總值將達到13萬億美元（當前，全球IT支出為4+萬億美元），其中生成式AI的市場總值將達到1.3萬億美元左右，是2022年（400億美元）的32+倍，而近期Gartner釋出了2024中國基礎設施戰略技術成熟度曲線，清楚地表明，未來2-5年生成式AI依然處於期望膨脹期，可見，其潛力之巨大。
圖片來源網路
正因為如此，國內外的大模型創業公司，如雨後春筍般湧現，都在探索著大模型的PMF（Product Market Fit）新機會，主要有2大方向，一個是基礎模型的迭代（如GPT3.5 到 GPT4），不斷迭代通用的泛化能力，其理想態是AGI（Artificial General Intelligence），不過，Scaling Law所需的大資料、大算力，需要耗費巨大的資金投入，讓眾多初創公司望而卻步。
另一個方向就是大模型創新應用，以新技術驅動產品形態，基於新技術的階段性發展，快速迭代升級產品，並最大化技術在產品中的價值，當前還處於產業發展的早期，而從實現路徑上看，面向生產力的大模型場景應用更有可能找到PMF落地，比如知識問答場景。
在過去的一年多，筆者有幸與多個團隊深度合作共創，併成功落地了多個大模型的場景建設，比如，剛結束不久的國際奧運大模型、公文寫作大模型、安保數字孿生智慧體等，而目前主要專注於公共雲汽車能源領域的大模型場景，其中，讓筆者感觸最深的是，軟體設計與模型演算法的有機結合，是系統成功構建的關鍵因素之一。
本文，筆者結合實踐經驗，期望以近期在負責的複雜表格智慧問答為切入點，結合大模型的哲學三問（“是誰、從哪裡來、到哪裡去”），穿插闡述我對大模型的一些理解與判斷，以及面向公共雲LLM的建設模式思考，並分享軟體設計+模型演算法結合的一些研發實踐經驗。
二、背景
在汽車領域，汽車廠商旗下通常會有多個子品牌，不同品牌下通常會有多款車型。面對眾多車型，汽車廠商在服務於車主的過程中，長期以來產生了大量的碎片知識，如汽車延長保修、汽車保養等，散落在各種文件中，常見之一就是表格文件（xlsx）。
以汽車保養的表格場景為例，一般我們對錶格的認知是，諸如資料報表、統計表等這類結構化的表格，而此次的汽車保養表格則是複雜得多。一份汽車保養表格中，同時包含了結構化和非結構化的內容，涵蓋了汽車保養類別、保養條目、保養的價格、以及一些保養的政策等，內容多樣且雜糅。
這類場景的諮詢服務，效果不佳且效率非常低下。因此，如何整合這些碎片知識的複雜表格文件，構建智慧問答系統，從而為車主提供可用、精準、人性化的問答服務，顯得尤為重要。
三、場景分析
顯然，汽車保養場景屬於問答場景，而智慧問答系統的構建，目前最耳熟能詳的，當屬基於知識庫的檢索增強生成（RAG）方案，也是大模型被高頻使用的場景之一。其通用做法是，基於百鍊平臺構建知識庫，選擇大模型，搭建RAG智慧體，再加Prompt調優，從而一個智慧問答系統就建成了，非常高效。因為百鍊的RAG鏈路本身已經做了很多工程最佳化工作，加之大模型自身的推理能力，其問答效果會得到一個還可以的效能結果。
而這能滿足很多場景下的日常使用（不需要精準度很高的情形），以至於給人以錯覺，這就是大模型的最好表現了，這種能work就算ok了，屬於60分的邏輯，其往往忽略了背後的思考和作為建設者的最終目標。筆者認為，作為大模型場景建設落地者，最大化挖掘大模型能力，並最佳化大型語言模型的工作流程，最終為客戶帶來極致的技術體驗，是我們的技術服務核心目標，這裡體現的不僅是一種技術服務思維，更體現了一種研發思維，而研發思維是研發能力的抽象，其呈現的是匠工精神。
如背景說述，儘管汽車保養的表格複雜、資料多樣、雜糅，且格式不統一，但是，從技術實現路線上可以大致分為4類，如圖所示，其中阿里雲產品泛指未整合到百鍊平臺的其他阿里雲產品。技術路線1，基於百鍊平臺構建問答系統，其標準化程度高，試錯成本、人力投入較低。而越往後，標準化程度越低、人力和試錯成本越高。而專案過程中，我們需要快速搭建、快速驗證、不斷調優，快速試錯。由此可見，我們得出一個實施原則，面向公共雲業務，最大化標準（用好阿里雲百鍊）、最小化做定開。
基於這一實施原則，抽象出兩大核心：模型、平臺，而圍繞模型開展的工作，又一定繞不開Agent和Prompt，因此，筆者將其定義為“兩大核心、四大要素”，即，以模型、平臺為核心，以大模型、百鍊平臺、Agent、Prompt為四大要素，構建高效、可用的大模型系統實現場景落地。可見，對四大要素理解的深度和廣度，將直接影響到構建系統的最終效果，也就是前面提及的最大化模型效果。因此，接下來，筆者將優先闡述下對這四大要素的一些原理和思考。
四、要素1：大模型——技術驅動產品
1、大模型架構——Decoder-Only Transformer
AI領域有3個技術流派，分別是符號主義、連線主義以及行為主義，其中，連線主義強調的是模仿人腦的神經元結構，透過大量的神經元相互連線來處理資訊，從而實現人工智慧。大語言模型（LLM），通常指的是具有大量引數的深度神經網路模型，因此，追根溯源，大語言模型屬於3大流派中的連線主義流派。其神經網路架構，採用的是Transformer架構。
原生Transformer架構中， Encoder（編碼器）、Decoder（解碼器）是其重要組成部分。Encoder指的是將輸入序列編碼為特徵向量，Decoder指的是根據編碼器的輸出以及先前生成的序列生成下一個單詞（符號）。而基於Transformer架構的LLM，根據編/解碼器的組合方式不同，產生了三種不同模式，即Encoder-Only模式、Decoder-Only模式、以及Encoder-Decoder模式，且這三種模式都有不同程度的發展（如下圖所示）。
圖片來源網路
可以看出，Decoder-Only Transformer的LLM發展最為迅速、最為耀眼，已成業界主流。其主要原因在於，相比於其他兩種模式，Decoder-Only模式允許模型透過給定的前文，以自迴歸方式進行文字生成，即迭代式地將已預測的詞加入到先前輸入序列中，以繼續預測下一個詞，從而使得模型更簡單、更專注，且在預測下一個詞時計算效率更高。
Decoder-Only Transformer架構，如下圖所示，相比於原生Transformer，Decoder-only架構省略了Encoder部分，將使用者query直接傳遞給解碼器進行處理。其推理過程分為 2 個階段，Prefill階段、Decode階段。
圖片來源網路
Prefill階段為計算密集型，是使用者輸入完query到生成首個token的過程，LLM處理輸入token以計算中間狀態（Key-Value），這些狀態用於生成第一個新token，如下圖所示。由於輸入的內容已知，且不同token的Key-Value計算是獨立的，因此，從高緯度看，這是一種高度並行化的矩陣-矩陣操作（matrix-matrix operation），GPU利用率較高。
Decode階段為訪存密集型，LLM自迴歸地一次生成一個輸出token，直到滿足停止條件。過程中，每個順序輸出token需要頻繁地在 HBM 和 SDRAM 中訪問資料，獲取之前所有迭代的輸出狀態（Key-Value），所以無法有效利用GPU的平行計算特長，GPU利用率不足，進而導致了輸出階段成本高。這也是為何大模型的輸出價格一般高於輸入價格的原因。
2、大模型的“變”與“不變”思考
回顧歷年政府工作報告，從2015年提出的“網際網路+”到2019年提出的“智慧+”，它們在不同階段推動了產業的轉型升級。而今年政府工作報告更是首次提出了“人工智慧+”，AI被提升到了前所未有的高度，也意味著從“網際網路+”、“智慧+”到“人工智慧+”的轉變。而把“人工智慧+”具象化地看，筆者認為，我們正在經歷的是“大模型+”的時代。
大模型、大資料、大算力這三駕馬車的系統性已經成型，且在快速地產生化學反應，加速地驅動著各個產業升級，如大模型+汽車交通、大模型+教育、大模型+網際網路、大模型+能源等。然而，“大模型+”時代下，從服務於千行百業的場景落地角度看，筆者一直在思考的是什麼是“變”的、什麼又是“不變”的，來確保對客戶服務的技術判斷力和技術服務的領先力。有以下幾個觀點，與大家做下分享：
2.1 大模型的“變”
現在業界普遍都認為，AI技術的發展變化飛快，而且這種變化還在加速。其核心可以從兩個緯度來看。
縱深上看，大模型的推理能力不斷增強，正在從系統1思維（即快速、直覺、自動、易出錯的思維模式）朝著系統2思維（即刻意、緩慢、有意識且更可靠的推理）進化與演進。比如剛釋出不久的OpenAI o1，第一次證明了LLM具有慢思考能力，雖然o1並未公佈其實現原理，但是業界給出了諸多技術原理猜想，較為一致的觀點是，o1透過RL（強化學習）及MCTS（蒙特卡洛樹搜尋），將CoT（思維鏈）能力內化進LLM中，並運用強大的算力實現了Post-Training 階段的Scaling。筆者在【前言】中提到，大模型的發展方向之一是基模的迭代並朝著AGI演進（演進路線為模擬世界、探索世界、歸納世界），而歸納世界的前提就是大模型具備系統2的能力，可見，我們正在加速AGI方向探索。
橫向上看，基於Transformer的NLP領域Scaling Law有效性已經得到證明，而將該定律擴充套件到機器視覺、語言處理領域，並形成多模態融合，正在深度探索並取得了明顯進展，比如GPT-4o把視覺理解模型 GPT-4v、視覺生成模型 DALL-E、Sora以及有聲模型 Whisper、Voice Engine融合在了一起，從而更真實地感知與理解物理世界。而在場景建設方向，“大模型+”的連結能力也在不斷被突破，如大模型+終端裝置連線，大模型+智慧控制等，豐富了大模型的“行為”能力，進而給具生智慧裝上“大腦”，讓具生智慧更具想象空間和可落地性。
2.2 大模型的“不變”
貝索斯曾說過，“大家經常會問未來10年，會有什麼樣的變化？但很少有關心，未來十年什麼是不變的？我認為第二個問題比第一個問題更重要。”筆者的理解是，定義清楚了什麼是“不變”的，形成抓手並遷移，才可能不斷從“變”中，抽象出“不變”並形成內化。更具體地說，就是面向大模型場景建設，不斷挖掘其共性化建設，並形成標準化能力，從而應對千行百業中不斷湧現的新場景、新變化。
筆者認為，面向公共雲業務場景的建設模式已經顯現，即如下圖所示，類似於Linux系統架構，以大模型能力為核心，分層解耦形成對外服務能力，面向場景可組裝平臺化的大模型應用構建模式。透過三層軟體架構，快速構建輕量級應用，實現高內聚、低耦合、變化隔離；透過平臺化組裝，實現多應用的“積木”組合，從而輸出場景化解決方案。因此，無論大模型如何“變”，對外提供能量的介面層隔離了該變化，從而使得應用架構相對穩定。
我們知道，深度學習的思想是分層，透過多層疊加的方式，實現了對資料的分級表達，而大模型的核心正是透過這種縱向的層次堆疊，形成了Scaling Law。而對於業務，透過組裝方式橫向“堆疊”應用，是否也能形成“堆疊”效應，進而產生強大生命力呢？我想是一件非常值得期待的事情。
五、要素2：百鍊——可組裝式，所“建”即所得
百鍊，作為阿里雲大模型服務平臺，服務於千行百業的大模型場景建設，其平臺可用性、易用性至關重要。而作為資深使用者，筆者不僅見證了百鍊的快速成長並逐步走向優秀，更欣喜地看到了，今年5月份2.0版本的釋出。
該版本不僅深度踐行了“一切皆智慧體”的理念，更凸顯了模型中心、應用中心、以及資料中心這3大核心板塊的有機聯動，易用性取得了前所未有的提升，很大程度上滿足了常規功能的大模型應用搭建。如上圖所示，面向最高頻使用的應用構建，百鍊提供了3種構建模式，包括智慧體、工作流、多智慧體，其本質就是模組化、可組裝化。
可組裝化技術，強調的是系統架構層面，是對已有技術的再組合和用法創新，注重系統從構建到演化的過程，如何以可組裝的方式增強提升系統的韌性和快速適應性。
正如Gartner 研究副總裁David所說，可組裝方法，讓系統能力變得可沉澱、可組合複用、可靈活應對各種變化，在新功能的實現速度上將比競爭對手快80%。筆者給多家企業（累計培訓人數300+）做百鍊平臺培訓，很多學員不僅能快速上手百鍊，而且分鐘級搭建完成RAG應用系統並使用，所“建”即所得。
六、要素3：智慧體——大模型落地的關鍵載體
1、單智慧體
早在20世紀50、60年代，諾伯特·維納在《控制論》中就有對智慧體概念進行討論。而隨著深度神經網路的快速發展，尤其是大模型技術的爆發，基於LLM的智慧體被廣為人知，其定義也逐步清晰、具象化。
智慧體，是一種高效、智慧的代理，能感知環境、解釋資料、做出決策，並執行動作以實現預定的目標。其架構如下圖所示，包含規劃、記憶、工具、執行四大要素。透過將大模型嵌入到智慧體中，可以更好地將模型的能力應用於實際場景。它為智慧體提供了強大的推理能力，解釋指令和上下文，使其能夠更好地利用各種工具，諸如API、搜尋引擎等，實現（半）自主運作。
著名AI科學家吳恩達做過一項小型研究，結果表明，在編寫程式碼的標準編碼基準測試中，GPT-3.5 智慧體，效果上比 GPT-4 表現更好。筆者認為，智慧體已然成為大模型落地的關鍵載體，而大模型與智慧體的有機結合，有助於提升整個場景落地的效果。
2、多智慧體
在軟體領域，“分而治之”是一種常用的設計和開發理念，而在大模型場景中也同樣適用。面向複雜任務場景，多智慧體方法會將複雜任務分解為子任務，讓不同的智慧體完成不同的子任務，即專業“人”做專業“事”。AutoGen論文中的消融研究顯示，相比於單智慧體，透過對複雜任務分解而構建的多智慧體，其協作的表現更優。
因為，拆解任務有助於降低單個大模型的輸入複雜度以及理解難度，從而有利於大模型專注於“做”一件事情，其效能可能會更好。類比我們自身，在被洋洋灑灑地告知要處理10件事情，一次性要理解幾千字的資訊，與把這10件事情分開說、分開做，哪種做法更能做好做準確呢？其結果不言而喻。而筆者針對複雜表格所設計實現的方案正是基於這一思路。
七、要素4：Prompt——LLM與應用的“橋樑”
LLM的高速發展，為NLP帶來了新的正規化（如上圖所示），即預訓練+微調+Prompt正規化。其中，預訓練，是 LLM的基石，透過海量無標註語料，對大模型進行自監督學習，從而讓大模型具備了通用語言理解和生成能力，解決的是領域（Domain）能力問題；而微調，解決的是某一任務（Task）問題，利用標註的任務資料，對預訓練過的模型做進一步的最佳化，從而更好地適應某一Task，然而存在過擬合、災難性遺忘等風險。不過，這兩者有一個共性，就是都會改變模型的引數。
相反，提示詞工程（Prompt Engineer，PE）無需更改模型引數，而是透過構建合理的Prompt，激發大模型中蘊含的知識、引導其行為，從而生成高質量的結果。PE最大的優勢在於高效、靈活、成本低，而且避免了微調可能帶來的問題。正因為如此，傅盛在極客公園演講曾表示，如果創業者只學習大模型的一個技術點, 那就是Prompt。事實上，這也是我們場景落地過程中，使用最多的調優手段。
提示詞工程，是一種經驗科學，其效果在不同的模型之間可能會有較大差異，但方法層面具有通用性，下面介紹一些筆者在實踐中高頻使用的方法：
1、Few-Shot CoT，提供示例，在詢問問題的時候，給出示例能夠顯著提升模型輸出效果，尤其是針對格式上有要求的情況；
2、指定角色或人格，從而能夠回答得更加專業。比如，當我們直接問一個問題時，模型可能會很泛地回答，然而，當我們指定角色的時候，大模型能夠根據訓練時角色資料，給出更加具象化的回覆；
3、還有一些小技巧，如，先思考後回答、重要的資訊放提示詞後面、指定模型如何格式化響應等。
八、可行性方案設計——多方案探索
正如【場景分析】一節中指出的，複雜表格的智慧問答場景，屬於大模型RAG應用範疇。而大模型RAG的基本原理，正如ACA課程所介紹的，如下圖所示，主要分為2個階段，即：
建立索引：首先要清洗和提取原始資料，將PDF、Docx等不同格式的檔案解析為純文字資料；然後將文字資料分割成更小的片段（chunk）；最後將這些片段經過嵌入模型轉換成向量資料（此過程叫做embedding），並將原始語料塊和嵌入向量以鍵值對形式儲存到向量資料庫中，以便進行後續快速且頻繁的搜尋。
檢索生成：系統會獲取到使用者輸入，隨後計算出使用者的問題與向量資料庫中的文件塊之間的相似度，選擇相似度最高的K個文件塊作為回答當前問題的知識。知識與問題會合併到提示詞模板中提交給大模型，大模型給出回覆。
而在實際使用中，為了獲得更好的模型效能，會在原始的RAG基礎上，增加諸如混合檢索、Rerank等模組化能力，其中混合檢索有兩種形態，術語檢索（即稀疏檢索）以及語義檢索（即密集檢索）。
因此，根據【場景分析】中提出的實施原則，筆者優先選擇技術路線1、2，即優先基於百鍊、百鍊+阿里雲產品，標準化能力構建，並驗證其可行性。經過調研，探索出了3種可行性方案：
方案1：百鍊平臺標準RAG
按照百鍊平臺RAG的搭建，第一步需要匯入文件源，做文件解析，其中，匯入的複雜表格文件中，既有表格也有較長文段等，導致，提交上傳到百鍊平臺後進行解析出現報錯。
其原因為對於格式為xlsx的文件，資料型別要求是結構化型別，而我們上傳的複雜表格，既有結構化資料、也有非結構化資料，因此解析失敗。可見，方案1走不通，無法滿足該專案場景。
方案2：基於通義千問VL-Max的多模態RAG
由於複雜表格資料格式不統一、多樣化、且資料雜糅，傳統的文件解析經過嘗試均無法滿足，而基於多模態大模型的視覺感知，不僅能有效提取圖片文字資訊而且能做有效推理和生成，因此，考慮基於多模態大模型千問VL進行可行性測試。
方案的整體思路，將資料excel全部轉為圖片格式，然後呼叫基於QwenVL Max構建的多模態RAG。其中，基模的視覺識別能力對整個方案起著至關重要的作用，因此，優先基於QwenVL Max進行測試其效果。經過實際驗證，該模型能準確理解並給出正確回答，技術上看起來可行，但其存在明顯的弊端：
1）文件的預處理繁瑣，需要人工將所有文件，以一定方式截圖且不能存在文字遮擋情形（這點很難保證），其隨著文件數量增多，人工成本陡增；
2）多模態大模型其呼叫費用較高，隨著呼叫的次數增多，所需支付的費用持續加劇；
3）當截圖量級不斷增加時，一次性全部輸入給到通義千問VL- MAX顯然不現實。
方案3：文件解析（大模型版）+百鍊的組合RAG
回顧方案1，最大的卡點問題是文件為xlsx格式但資料型別為非結構化，導致無法解析。進一步考慮，是否可以尋求具備該能力的阿里雲產品，解決該excel文件解析問題，而一旦能打通，則後續便可以複用百鍊RAG標準化能力，從而最小化定製、最大化複用地支撐該專案的快速實現（即技術路線2）。因此，方案3應運而生。
方案的整體思路：
1）問答解析，基於阿里雲產品文件智慧的文件解析（大模型版）呼叫其文件解析介面實現文件抽取和理解，從文件中提取出文字markdown內容；
2）知識構建，將markdown內容匯入百鍊資料管理做解析，以及做資料向量化（embedding），構建知識庫；
3）基於百鍊應用模版構建RAG，並關聯該知識庫，生成智慧問答應用例項；
4）基於該智慧問答應用，做知識QA。
相比於其他2種方案，方案3標準化程度最高，實施上更輕量，且效果經過初步驗證更優。因此，可行性方案採用的是方案3。
可行性效果評測
基於方案3快速搭建的最小應用系統，根據實際測試樣例進行批次測試，準確率為51.2%。其結果表明，從可行性方案上，證明方案3的技術有效性，但從效果上，準確率較低，無法滿足實際使用落地。
九、可落地方案實現——多智慧體架構
1、難點分析
在可行性階段，探索並驗證了方案三（文件解析（大模型版）+百鍊的組合RAG）的技術可行性，效果上需要最佳化。在【Prompt】一節中提到了圍繞大模型效果最佳化的3大方向，預訓練、微調、PE，而PE是最高性價比的調優手段。因此，筆者的第一個直覺也是調Prompt，效果確實也有提升，但是並不顯著。事實上，經過深入分析，究其原因有3:
1）資料層面：（a）保養表格內容涵蓋多種類、資料雜糅；（b）價格費用計算複雜，需要4維條件才能鎖定一個價格；（c）資料中有髒資料，比如，如下圖所示，表頭里程（公里）一列顯示的卻是車型。
而方案3對資料的處理非常樸素，就是文件解析後構建一個知識庫，這其中存在2個問題，資料質量不高，資料相互耦合（形成資料噪聲）。
2）問題多樣化：使用者提問的保養問題較為多樣化，比如，詢問保養價格類、保養專案類、保養政策類等，而方案3透過單Agent+Prompt調優的方式構建問答能力，這導致的最大問題就是，Prompt指令的複雜度陡增。
而大模型產生幻覺的主要來源之一，就是過於複雜或寬泛的Prompt。從資訊學的角度來說，引入了更多的不確定性，增加了輸入的資訊熵。
3）精準類問題的推理難度大：保養價格類問題，屬於精準類問題，原則上不允許大模型回答出錯，而對於這類問題，如上表格所示，涉及到車型（含上市時間計算）、里程計算、地區推算、以及費用計算等才能得出最終的保養價格費用，屬於高維度的計算推理。
經過實測，大模型的表現並不理想，且帶有隨機性，這是因為LLM是基於已知輸入預測下一個Token的過程，本質上就是機率計算。
2、解決思路
1）RAG方案中，知識庫資料往往優於大模型自己具備的知識，即，知識庫資料質量在一定程度上決定了大模型的效果上限，因此，高質量知識至關重要。針對問題1，進行適度的資料清洗、資料分類非常有必要；
2）正如在【智慧體】一節中提到的“相比於單智慧體，透過對複雜任務分解而構建的多智慧體，其協作的表現更優”。因此， 針對問題2，我們需要對任務進行分類和拆解，從而構建業務垂直化的Agent，並形成多智慧體架構；其設計，符合軟體設計原則中的“職責單一化”原則，以及“高內聚、低耦合”原則；
3）針對問題3，儘管大模型的推理能力在不斷加強，但眼下還是需要透過一些工程化手段來改善。為此，筆者的思路是，針對精準類問題的解法是，構建Serverless價格查詢服務，並透過函式計算（FC）下沉到自定義外掛中，這樣既能充分發揮大模型的推理能力，又能透過外掛化呼叫提升精準度，且價格資料實現了線上化，可管控性更強。
3、方案架構
綜合上述3種解決思路，設計並最終形成了如下的方案架構，其設計的核心原則是分而治之，封裝垂類Agent，橫向組裝API。分層來看，首先基於大模型服務工具，進行資料處理、資料分類等工作，其次透過百鍊平臺進行垂類Agent構建，最後，透過百鍊API進行多智慧體編排組裝，且Router Agent做路由。
4、工程鏈路
整個方案的工程鏈路建設，主要分為離線階段和線上階段兩部分：
1）離線階段：資料處理&知識庫構建流程，如下所示：
2）線上階段：Query路由與檢索增強的工程鏈路，如下所示：
接下來，針對鏈路的關鍵模組進行簡要闡述：
4.1資料工程——Better Input Better Output
資料處理環節，主要是對錶格資料中有錯誤、有重複、格式錯誤等情況進行最佳化，並對錶格中的合併單元格進行分行處理等，隨後做資料分類，將保養內容進行抽取，並形成結構化資料，構建保養內容知識庫；將保養政策進行抽取，透過文件解析（大模型版）進行解析為MD資料，並透過百鍊構建保養政策知識庫。將保養價格資料進行抽取，並透過Coding實現RDS持久化，並對外提供資料查詢服務，以及透過函式計算（FC）實現Severless呼叫。最終，資料質量得到大幅度提升。
4.2車型改寫
車型改寫的目的在於，車主提問的方式是開放式的，比如“16年xx在北京，里程5000公里，保養需要多少錢？”xx車型有多款，且每一款的上市時間各有不同，這時候就需要透過車型改寫Agent，進行改寫，並輸出完整的車型。
其Prompt如下所示：
#角色你是一位問題改寫專家，善於根據歷史對話做問題改寫，並呼叫【車型匹配外掛】做二次改寫，以及問題分類。#技能，嚴格按照以下步驟執行**步驟1**：需要根據使用者問題和歷史對話，進行問題改寫；**步驟2**：根據步驟1改寫後的問題，如果提到車型，則提取到【車型】；如果提到時間，則提取到【時間】；否則，則不提取對應欄位。**步驟3**：如果【車型】，則務必呼叫【車型匹配外掛】，【車型】、【時間】（如果不為空）作為入參，獲取匹配後的【車型全稱】；**步驟4**：基於步驟3返回的結果，【車型全稱】資訊，對步驟1執行後的問題做二次改寫；（只改寫，不回答其他內容和思考過程）**步驟5**：根據改寫後的問題，判斷屬於哪類問題。問題類別列表：保養價格類、保養內容類、保養政策類、其他類。#約束**嚴格遵循**：務必根據技能步驟執行，如果技能中**步驟3**【車型匹配外掛】被執行，則務必按照**步驟4**進行改寫。#輸出格式，以json格式輸出，樣例："""{"使用者問題"："xx，5萬公里，北京保養需要多少錢？",“提取的車型”：“xx”,“外掛返回車型”：“xx2.0L”，"改寫後問題"："xx2.0L，5萬公里，北京保養需要多少錢","問題型別"："價格類"}"""4.3意圖識別
在完成多輪對話增強（帶歷史對話功能），做車型改寫的同時，系統會進一步對問題進行意圖識別，即理解使用者真正的需求。意圖識別是智慧問答系統的關鍵部分，它決定了系統是否能夠精確匹配使用者的需求，確保了後端鏈路的精準路由。如，使用者問“在成都保養單價需要多少錢？”，這時透過意圖識別，則會精準路由到保養價格Agent鏈路。
4.4文件解析
筆者主要利用的是文件智慧產品的文件解析（大模型版）能力，實現了基於文件解析的API介面，由xlsx文件轉化為markdown的線上功能，主流程如下所示：
#複雜表格解析主流程def process_file(file_path): #1、獲取client client = get_cred_client() print(f"file_path:{file_path}") #2、提交複雜表格檔案 id = submit_file(client,file_path)while True: #3、根據檔案id,查詢狀態 status = query(client,id)if(status == "success"):break time.sleep(1) #4、根據返回結果，獲取解析後的資料，並存入md檔案 get_parser_result(client,id)4.5函式計算
函式計算是一個事件驅動的全託管 Serverless 計算服務。而我們開發的價格計算外掛、車型外掛都屬於無狀態服務，非常適合採用這種函式計算方式。只需將程式碼編寫完成並上傳即可，無需管理伺服器等基礎設施，充分體現了Serverless的極簡運維，減少業務釋出和擴容運維時間，降低使用者業務構建門檻，降低使用者保有資源的成本。
5、效果
在測試評估階段，筆者根據實際樣例集進行測評，其部分結果如下所示：
保養內容類樣例，經過多智慧體問答系統，能正確輸出保養內容的相關資訊。
保養價格樣例，則準確給出對於車型的保養費用，且總費用、零件費用、工時價格，與表格資料完全一致。
經過批次測試，效果準確率達到93.8%，相比於可行性方案，效果顯著提升，如下圖所示：
十、總結
本文以汽車保養複雜表格的智慧問答為切入點，系統地闡述了：
1、從哲學三問（“是誰、從哪裡來、到哪裡去”）的視角，思考並分享了對LLM的理解，包括LLL所屬的連線主義流派、Decoder-Only Transformer架構、以及從縱深、橫向兩個緯度的“變”。從“變”中尋找到“不變”,即以大模型能力為核心，分層解耦形成對外服務能力，面向場景可組裝平臺化的大模型應用構建模式，從而以“不變”應萬“變”。
2、面向公共雲大模型建設，定義了“兩大核心、四大要素”，以及“最大化標準、最小化做定開” 的實施原則，有利於降低人力和試錯成本，從而實現快速搭建、快速驗證、不斷調優，快速試錯的大模型場景落地。
3、在深度剖析複雜表格的基礎上，從可行性到可落地性兩個階段，設計出了多種解決方案及其驗證，最終採用並實現了多智慧體+價格外掛（FC）的解決方案。經過實際樣例集測試評估，準確率達到93.8%，達到並超出了預期。
筆者認為，LLM哲學三問的思考，有利於幫助初探大模型的同學們，串聯知識碎片，系統性理解大模型；而“兩大核心、四大要素”，以及“最大化標準、最小化做定開”的實施原則，為大模型場景落地的同學們，提供了具有實踐價值的參考建議；最後，本文闡述的複雜表格多智慧體方案及其經驗，不侷限於汽車保養場景，具有一定通用性，對其他行業有類似場景訴求的同學們，同樣具有借鑑意義。
團隊：公共雲業務-技術服務部
參考：
使用 ChatGLM 搭建對話模型
透過ChatGLM和LangChain構建高效的對話模型。基於自然語言處理技術，並使用語言交換協議提升語義理解和互動體驗。可廣泛應用於聊天機器人、智慧客服、社交媒體等場景中，有效解決對話模型中的語義理解和互動問題，提高使用者互動的自然性和流暢度。
點選閱讀原文檢視詳情。