答疑類產品是提升使用者體驗的重要手段，是平臺問題的“清道夫”。然而現有的智慧化答疑產品，只能解決少量的靜態文字匹配類問題，無法處理使用者真實遇到的平臺問題。因此才會有著名的“ Gartner：64% 受訪者不希望客服系統部署 AI ”事件發生。在 InfoQ 舉辦的 QCon 全球軟體開發大會（上海站）上，阿里巴巴技術專家黃建磊為我們帶來了精彩演講“Agent 驅動的智慧答疑產品構建：問答、診斷與修復實踐”，重點闡述在小喵智慧答疑產品的研發實踐中，如何透過主動問題定位、根因分析、問題修復構建的群體智慧體，動態化解決使用者問題，提升使用者滿意度。

我們團隊大概在去年 10 月 1 日的時候，開始啟動智慧答疑係統的研發，現在正好過去一年時間，借這次 QCon 的機會，我們把過去一年在實踐過程中遇到的問題以及我們如何解決這些問題分享給大家，希望對大家後續在應用層的落地有所幫助。

答疑產品在我們的生活和工作中無處不在。它是一種用於滿足使用者在使用特定平臺時遇到問題後尋求解決方案的工具。這個特定平臺可以被稱為“宿主平臺”。例如，常見的雲產品如阿里雲、騰訊雲和 AWS 等都具備答疑產品的形態。

答疑產品的重要性體現在以下幾個方面：如果設計得當，它可以顯著提升使用者體驗、服務質量，並增強使用者粘性。這些結論可以從一些公開資料和資料中得到佐證。然而，如果答疑產品設計不佳，反而可能產生負面影響。根據 Gartner 釋出的最新報告，一個令人擔憂的指標顯示，約 60% 到 70% 的使用者不希望他們使用的產品背後的答疑功能是由 AI 驅動的。甚至有超過 50% 的使用者表示，如果他們所使用的產品背後的智慧答疑是由 AI 驅動的，他們可能會轉向其他平臺。

答疑產品是依託於宿主平臺的，使用者在宿主平臺上遇到問題後才會轉向答疑平臺。接下來，我們介紹一下我們團隊所負責的宿主平臺。我們平臺是阿里巴巴研發運維的基礎設施，面向產品研發人員提供軟體交付全鏈路的自動化、平臺化和智慧化保障。簡單來說，這就是一個 DevOps 平臺，說得更專業一點，就是 SRE（Site Reliability Engineering，即網站可靠性工程）平臺。

我們先了解一個完整答疑的全鏈路過程。使用者在宿主平臺上進行操作時，可能會遇到紅色感嘆號提示，表明無法繼續操作，這意味著使用者遇到了問題。此時，使用者會轉向智慧答疑的 AI 機器人，描述自己遇到的問題，例如“我遇到了什麼樣的問題，該如何解決？”

在智慧答疑的背後，首先是一個 RAG（Retrieval-Augmented Generation）系統。RAG 系統包含底層的離線和線上知識庫。問題進入系統的第一個環節是問題改寫與泛化，這一環節也被稱為問題的前置處理。處理完成後，問題會經過文字與向量的兩路召回，從知識庫中找到與問題最相關的問題 – 答案對。然後，將這些相關的內容傳遞給模型，模型會總結出一個答案，並透過答疑機器人告知使用者，例如“你可以透過什麼操作來解決這個問題”。

我想特別強調的是，在接下來的分享中，我不會過多強調 RAG 體系，但這並不意味著它不重要。實際上，RAG 是整個答疑係統中非常關鍵的環節。目前，無論是學術界還是工業界，對 RAG 的研究已經相當豐富。例如，LangChain、Llama Index 以及許多公開的論文都對這一領域進行了深入探討。如果大家在 RAG 方面遇到問題，開源社群中已經有大量資源可以提供幫助。

對於答疑機器人給出的答案，使用者可能不滿意，或者不確定答案的正確性，這時他們會轉向人工答疑。人工答疑分為兩層：第一層是一線答疑人員，他們的主要職責是處理答疑工作。他們通常是非領域專家，主要解決相對簡單的問題。一線答疑人員在解決問題時，往往依賴自己的隱性知識——即他們頭腦中已有的知識。這種隱性知識與顯性知識相對，顯性知識是指明確記錄在文件或知識庫中的知識，而隱性知識則是個人在日常工作中積累的經驗和直覺。

如果一線答疑人員無法解決問題，他們會將問題轉給特定領域的專家。這些領域專家可能是功能的開發人員，他們對自己的功能模組和工作流程非常熟悉。他們會利用自己的隱性知識來解決問題。這就是一個完整的答疑係統。

在智慧答疑係統的開發與落地過程中，我們遇到了三個核心問題。

首先，使用者的問題描述往往不準確。 智慧答疑係統依賴於使用者的原始問題，但使用者在輸入問題時，往往只是希望快速繞過智慧答疑環節，轉而尋求人工幫助。因此，使用者輸入的問題通常非常簡略，甚至不準確。資料顯示，約 40% 的使用者問題長度小於 8 個字元。這種簡略且不準確的問題描述，即使後續有最先進的 RAG 體系或領先的模型支援，也很難為使用者提供精確的答案。

第二是缺乏領域知識。當問題從通用領域轉向特定私域時，基座模型往往不具備私域領域的專業知識。例如，企業內部的特定知識是基座模型所沒有的，這就導致 RAG 體系中的知識庫無法提供有效的解決方案。在答疑過程中，無論是人工一線答疑還是功能開發人員，他們解決問題時依賴的往往是自己腦海中的隱性知識，而這些知識並未被納入 RAG 知識庫中。因此，整體私域問題的解決率非常低。

第三是使用者對 AI 的不信任。在實際應用中，使用者對 AI 機器人給出的解決方案（例如分步驟的操作建議）往往持懷疑態度，甚至在轉向人工答疑時，使用者會要求一線答疑人員確認機器人給出的答案是否正確。本質上，當前的智慧體系給出的是一套面向過程的解決方案，使用者需要自行辨別這些解決方案的正確性，而這一過程需要使用者承擔一定的成本，這是使用者不願意接受的。相比之下，人工答疑給出的答案預設是被信任的，使用者會直接執行。

目前市場上許多所謂的“ AI 產品”其實只是在名稱上有 AI，本質上可能只有簡單的提示（Prompt），而缺乏真正的智慧化能力。在實際落地智慧化應用時，我們遇到的這些問題，正是由於智慧化本身的基座程式設計正規化改變所引發的連鎖反應。這些問題才是我們需要更多精力去解決的。相比之下，一些通用的、常見的元件在開源社群或工業界中都有相對成熟的參考案例。而我所提到的這些問題則更為具體、更具挑戰性，這也是我今天分享的核心內容。

接下來我們探討如何在現有的 AI 基座之上，利用 AI 的能力解決上述提到的三個核心問題。首先，我們著重解決第二個問題——缺乏領域知識。在答疑過程中，人工答疑人員通常依賴自己腦海中的隱性知識來解決問題。那麼，如何將員工腦海中的隱性知識轉化為顯性知識，並讓這些顯性知識能夠被上層智慧化系統（如 RAG 或模型對齊、SFT 過程中的語料）所利用呢？

在解決方案的迭代過程中，我們最初的想法是“人工智慧，先有人工，再有智慧”。因此，我們讓一線人員手動編寫知識，類似於編寫程式碼的過程。然而，這種方式對開發人員的壓力很大，因為它是一個旁路分支，不在他們的日常工作鏈路中。同時，顯性知識的稽核成本非常高，因此這條人工編寫的鏈路難以持續。

隨著對業界研究的深入，例如清華大學實驗室關於智慧體與環境對齊的工作，我們意識到可以利用專家知識來訓練智慧體。這啟發我們轉變思路：每個員工在日常工作中實際上已經在利用隱性知識解決問題，那麼我們是否可以基於這些日常行為來提取顯性知識呢？這就是隱性知識顯性化解決方案的核心思路。

隱性知識顯性化是一個相對泛化的命題，不同的場景對知識的需求和知識的表示形式都不相同，因此落地形式也各有差異。舉一個具體的案例：我們有一個智慧修復 Agent，其中的 Planning 過程至關重要。Agent 在解決問題時需要規劃如何解決，而這個規劃過程需要私域知識的增強。我們發現，一線員工在構建平臺上發起構建時，如果出現錯誤和錯誤日誌，他們會利用隱性知識透過程式碼編寫來解決問題。此時，錯誤日誌以及解決錯誤的程式碼 Diff 可以構成一個生產資料集。我們可以透過這個資料集提取顯性知識。

第一個階段是知識提取。 底層依然使用基礎語言模型，核心是利用其推理能力。我們向語言模型提供錯誤日誌和使用者程式碼的 Diff ，請求模型提取使用者解決問題時的思路。

然而，僅靠知識提取還不夠，因為模型底層可能存在幻覺，我們需要保證提取內容的準確性。業界常見的準確性解決方案有三種：第一種是找領域專家進行判斷，這是最準確的方法；第二種是使用更先進的模型作為“教師”進行判斷，但在我們的私域場景中顯然不適用，因為私域知識無法讓 GPT 或 O1 這樣的通用模型進行判斷；第三種是我們實踐中採用的方法——自我一致性。簡單來說，就是讓模型多次判斷同一問題。如果多次判斷結果一致，那麼在當前場景下就可以認為是正確的。我們將這些經過驗證的知識流轉到顯性知識庫中。

顯性知識的提取核心在於透過精心設計的 Prompt 引導模型完成知識提取。具體來說，Prompt 採用三段論的結構化方式：首先，明確模型的身份和角色；其次，說明模型需要完成的任務；最後，告知模型輸入的內容，例如錯誤日誌和使用者提交的程式碼 Diff。我們希望模型能夠從這些輸入中提取出顯性知識，包括識別問題的型別、定位問題的方法、針對此類問題的通用解決路徑，以及使用者實際採用的解決路徑。

第二個階段是正確性的判斷。 由於模型底層存在不穩定性，例如幻覺等問題，導致其輸出可能具有機率性。因此，在正確性判斷階段，我們採用基於自我一致性的方法，讓模型對同一問題進行多次判斷。這一階段的 Prompt 設計與第一階段類似：首先明確模型的角色和任務，然後解釋輸入內容的含義，最後告知模型需要返回的結果形式。在這一階段，模型需要從多個維度對提取的知識進行評估，包括：識別的問題是否正確、定位問題的理由是否合理、通用解決路徑是否正確，以及使用者的解決路徑是否正確。最終，模型需要給出一個綜合結論。這一階段的目標是確保提取的知識在準確性上達到可接受的標準。

在智慧答疑係統中，使用者對 AI 結果的信任度較低，尤其是在非編碼領域。使用者可能不會接受 AI 給出的解決方案，而是選擇轉人工處理。為了解決這一問題，我們提出了將面向過程的解決方案轉變為面向結果的解決方案。傳統的面向過程解決方案是指導使用者按步驟操作，例如在構建失敗的場景中，告訴使用者第一步、第二步、第三步應該怎麼做。而面向結果的解決方案則是直接為使用者提供一個已經驗證成功的程式碼 Diff 。這種思路的轉變能夠降低使用者接受結果的成本，從而提高智慧答疑係統的攔截率。

基於這一思路，我們引入了智慧修復 Agent 的概念。我們意識到 Agent 將成為未來智慧化應用的核心基座。如果將大語言模型（LLM）比作作業系統，那麼 Agent 就是執行在該作業系統上的應用程式。因此，我們構建了一套完整的框架，涵蓋 Agent 的定義、執行時管理、資料管理和知識提取。

在 Agent 的定義上，我們遵循了社群中廣泛認可的 LangGraph 架構。這種架構在底層設計和生態擴充套件性方面都表現出色。在智慧修復 Agent 的具體實現中，我們首先確認構建錯誤的發生，然後執行修復動作。修復節點中會進行規劃（Planning）和排序（Sorting）操作。我們發現，在程式碼修復場景中，檔案修改工具的成功率較低且受多種因素影響，因此我們將檔案修改單獨作為一個節點處理，並在修復過程中進行資料上報。這些資料對後續最佳化和效果評估具有重要意義。

Agent 執行時的設計至關重要。Agent 本質上是一個典型的“木桶應用”，由多個節點組成，任何一個節點的效果劣化都會對後續環節產生放大效應。為了避免這一問題，我們將 Agent 的執行時設計為一個連結串列，連結串列由多個步驟組成，每個步驟對應一個節點的執行時。每個步驟包含兩個設計要素：Action 和 Checkpoint。Action 是模型的結構化輸出，包括工具選擇、行為生成和推理過程；Checkpoint 用於回退，當執行中出現效果劣化時，可以基於某些節點進行回退。Checkpoint 中包含狀態（state）和環境（environment），例如當前的 Git 環境或工作區等。此外，我們還引入了 Reward 機制，類似於機器學習中的損失函式，使 Agent 能夠自適應地決定是前進還是回退。

在資料到知識的維度上，我們繼續推進隱性知識顯性化的工作。最終，我們直接向用戶提供經過驗證的程式碼 Diff，使用者可以直接接受而無需再手動執行復雜的步驟。

在智慧答疑產品的開發過程中，我們整個思路是透過遇到一個個問題並基於這些問題實現一個個 Agent 。我們預測智慧答疑未來將朝著群體智慧的方向演進。儘管過去群體智慧可能看起來較為虛幻，但在某些垂直領域和產品中，群體智慧的實現或許會更快到來。我們團隊將繼續面向更多問題，補充更多 Agent ，並探索 Agent 之間的自主協作和溝通。我們認為，無論是答疑還是其他智慧化應用，未來的底層架構一定是面向多 Agent 協作的方式演進。

在 AI 產品的開發和應用中，我們有以下幾點心得。

黃建磊，阿里巴巴技術專家。2017 年擔任釘釘桌面前端負責人，是可互動卡片（現酷應用的重要底層能力）的發起人。2021 年開始做 O2 Space 研發平臺，透過建設 O2 Pai 的開放能力，打造端到端的開放能力。2023 年至今，擔任阿里巴巴愛橙科技的技術專家。研發過程智慧化創新小組負責人，探索智慧答疑、智慧診斷、智慧修復等研發過程中的智慧化改造，提升研發效率和質量。

在 AI 大模型重塑軟體開發的時代，我們如何把握變革？如何突破技術邊界？4 月 10-12 日，QCon 全球軟體開發大會· 北京站 邀你共赴 3 天沉浸式學習之約，跳出「技術繭房」，探索前沿科技的無限可能。

本次大會將匯聚頂尖技術專家、創新實踐者，共同探討多行業 AI 落地應用，分享一手實踐經驗，深度參與 DeepSeek 主題圓桌，洞見未來趨勢。