在本篇文章中，我們將深入探討騰訊大語言模型在多個業務場景中的應用，特別是如何通過前沿技術提升模型的智能化與用戶體驗。首先介紹騰訊大模型的廣泛應用場景，如內容生成、智能客服和角色扮演等，并詳細解析 RAG（Retrieval-Augmented Generation）技術及其在實際業務中的創新應用，特別是在文檔生成和問答系統中的優勢。此外，文章還將探討 GraphRAG 在角色扮演場景中的應用，如何結合知識圖譜優化復雜的知識推理。最后，將深入分析 Agent 技術的原理與應用，展示其在目標驅動任務中的強大推理與執行能力。通過這些技術的結合與實踐，騰訊正在推動大語言模型在各類復雜場景中的智能化演變，提供更加精準且高效的解決方案。

一、騰訊大語言模型應用場景

1. 核心應用場景

騰訊大模型技術的應用覆蓋了多個業務場景，包括微信生態、社交內容、視頻新聞、辦公文檔、游戲等。通過大模型，騰訊推動了業務場景的智能化與高效化應用。

核心業務場景包括：

• 內容生成：如文案生成（如廣告文案）、評論輔助生成等。
• 內容理解：如文本審核、詐騙識別等。
• 智能客服：如知識問答、用戶引導等。
• 開發 Copilot：如代碼評審自動化、自動生成測試用例等。
• 角色扮演：如游戲場景中 NPC 的智能交互。

2. 大模型應用技術

騰訊在大模型應用中主要使用以下三種技術方式：

（1）SFT（Supervised Fine-Tuning）

• 基于基座模型（如大語言模型）進行微調，結合業務專屬數據，將特定領域的業務知識固化于模型中。
• 優勢：可直接實現針對性的任務回答與處理。

（2）RAG（Retrieval-Advanced Generation）

• 結合外部知識庫與檢索技術，在生成內容時加入檢索結果。
• 應用場景：智能客服、文檔助手等。
• 優勢：提供更高的可解釋性，并顯著減少幻覺現象（模型生成的虛假內容）。

（3）Agent（智能體）

• 通過調用外部工具，支持模型進行復雜任務的推理、規劃和執行。
• 優勢：適用于需要多步驟推理和執行的復雜任務場景。

3. 混元一站式大模型應用解決方案

騰訊通過混元大模型平臺提供一整套從基礎模型管理到復雜應用開發的支持體系，具體包括：

（1）基礎模型管理與開發支持

• 模型注冊與管理：支持多類型基礎模型（如 7B 模型、7B-MoE 模型等）。
• 數據處理鏈路打通：覆蓋數據抓取、清洗、模型訓練、評測、部署與服務等完整流程。

（2）Agent 平臺與擴展能力

功能支持：

• 集成 RAG 和 Agent 技術，支持索引與召回能力。
• 用戶可通過插件擴展與定義自有功能模塊。

應用能力：

• 提供智能問答、角色扮演、自定義編排等解決方案。
• 提供靈活交互界面，支持用戶完成復雜業務應用的流程化部署。

二、RAG 技術原理及優化實踐

在大模型技術快速發展的背景下，其直接應用于業務場景的過程中面臨一些難以忽視的問題，如：

• 幻覺問題：生成內容不準確或虛假，難以滿足高可靠性場景需求。
• 知識更新滯后：業務知識快速迭代，但模型更新周期較長，無法及時反映最新動態。
• 可解釋性與安全性：大模型的預測過程較為黑箱，難以提供足夠的安全保障。

為應對上述挑戰，RAG（Retrieval-Augmented Generation）技術通過結合檢索與生成機制，為模型注入動態更新的外部知識，顯著提高模型在復雜場景中的回答準確性與知識實時性。后文中將從技術原理、關鍵環節及實際應用出發，深入探討 RAG 技術的優化方案和應用實踐。

RAG 技術主要包含兩個核心部分：

數據準備：

• 構建高質量的知識庫。
• 針對知識庫構建召回索引及支持生成增強。

知識召回和生成增強：

• 用戶提出問題后，將其轉化為向量，結合知識庫中的向量匹配，召回對應文檔。
• 基于召回的文檔與問題生成準確且上下文相關的回答。

1. RAG技術原理

整體鏈路與原則如下：

• RAG 效果取決于全鏈路每一環節的優化，包括數據準備、索引構建、召回及生成環節。
• 遵循“Garbage in, garbage out” 原則，只有確保鏈路每一步的數據和處理結果高質量，最終效果才會滿足預期。

知識庫與生成增強：

• 知識庫通過存儲問題與相關文檔，實現向量匹配的高效檢索。
• 基礎模型以檢索的文檔為依據生成回答，確保生成結果具有高準確性和可靠性。

2. RAG 應用關鍵挑戰

RAG 在實際應用中會面臨諸多挑戰。首先，原始文檔格式多種多樣，內容提取面臨挑戰；第二，如何對不同格式的文檔進行切分，并保證語義完整性也是需要解決的一大問題；第三，需要考慮如何構建知識庫；第四，需要保證文檔召回率，召回的相關性，并在必要時融合多種召回技術；最后是如何讓模型更好地生成內容。

（1）文檔解析

技術手段：利用端到端模型對 PDF、Office 等文檔進行視覺化編碼和特征提取。

• 輸入：多種復雜文檔格式（PDF、海報、雜志等）。
• 輸出：高質量提取的段落、表格、公式等內容。

優化點：

• 支持異構文檔的解析。
• 保證文檔結構與語義的準確提取。

（2）文檔切分

提供多種切分方式適配不同業務場景：

• 固定長度切分：按照字數限制（如 1024 字）進行切分。
• 中文語義切分：通過模型判斷切分點，確保語義連貫。
• Markdown 標題細分：按 H1、H2、H3 等標題分層切分。
• 遞歸文本切分：根據語義和文檔層次靈活調整切分方式。

實際挑戰：

• 固定切分可能導致語義割裂。
• 復雜文檔需結合多種切分方式，確保內容完整性。

（3）離線知識擴充技術

• DocQAGenerator：直接基于原始文檔生成可能的 QA 對
• AugmentedQuestionGenerator：在用戶提供了<Question, Context>對的情況下，基于當前問題和上下文，為上下文生成更多可能的用戶問題
• AtomicUnitsQAGenerator：Atomic Units QA 的方法首先對原始文本進行分塊，然后將塊分解為原子陳述，再針對這些原子（以塊為上下文）生成一組合成問題

知識庫擴充方案：

• 針對用戶知識庫數據有限的情況，提出知識庫擴展方案：將文檔內容切分為 Chunk；提取原子成分并生成對應問題；生成問答對，擴充知識庫的覆蓋范圍。

成果：結合論文中提出的前沿方法，實現高效、精細化的知識庫構建。

（4）索引召回

向量化技術：支持兩種召回方式：

• 基于 Transformer/BERT 的語義召回。
• 基于 BM25（優化版 TF-IDF）的關鍵詞召回。

（5）多路召回

融合多種來源的召回結果，包括：Vector DB（向量數據庫）、ES（Elasticsearch），以及外部搜索引擎與 API。通過 Reranking 模型對召回結果進行重排和過濾，確保結果準確性和多樣性。

（6）知識生成

Prompt 工程：

• 明確角色設定：為模型提供專家或工程師等明確身份背景。
• 定義清晰的輸入輸出格式，避免歧義。
• 提供示例數據（Few-shot），增強模型理解能力。

SFT（微調優化）：

• 從業務場景中收集樣本數據。
• 結合監督學習方法進行模型微調，進一步提升生成效果。

三、GraphRAG 在角色扮演場景中的應用

1. RAG 局限

在角色扮演場景中，RAG 存在如下一些局限性：

• 缺乏全局信息：召回知識片段內容多為局部信息，缺乏全局關聯，難以支持復雜知識問答。例如，回答“孫悟空的金箍棒是怎么來的？”時，傳統 RAG 可能只提到“孫悟空從東海借金箍棒”，而無法完整呈現其背景故事。
• 缺乏上下文關聯：長文本中包含大量角色和關系，直接輸入給模型會受到長度限制，無法生成準確答案。
• 幻覺問題：傳統技術可能生成不真實或虛構的回答，降低用戶信任度。

為了解決這些問題，我們引入了 GraphRAG 技術。

2. GraphRAG：基于圖的檢索增強方法

GraphRAG（Graph-based Retrieval-Augmented Generation）技術通過結合知識圖譜構建與生成技術，為復雜知識場景中的問題解答提供了新的解決方案，特別是在長文本處理、關系推理和上下文理解等方面具有顯著優勢。

GraphRAG 技術通過知識圖譜的構建和使用，實現了從知識提取到推理生成的全鏈路優化。其核心流程包括三部分：

（1）索引構建（Indexing）

• 知識抽取：從小說或劇本中切分出語義片段，抽取實體、關系和社區信息。
• 圖譜構建：將這些內容組織為知識圖譜，存儲在圖數據庫中。

（2）檢索（Retrieval）

• 局部檢索（Local      Query）：針對具體實體或關系進行檢索，獲取細節信息。
• 全局檢索（Global      Query）：檢索整個圖譜的社區結構與總結內容，提取高層次信息。

（3）生成（Generation）

• 基于檢索結果生成回答，提供清晰的溯源和邏輯推理能力。

3. 基于混元LLM構建圖檢索增強框架

混元 LLM 構建 GraphRAG 主要包括離線和在線兩部分。

主要步驟：

• 語料切分
  對長文本如《西游記》或《長相思》進行內容切片（Chunking），以便模型處理。
• 知識抽取
  使用大模型的 Prompt 對 Chunk 內容進行解析，提取以下信息：
  實體（Entity）：如金箍棒、太上老君、孫悟空等。
  關系（Relation）：如“煉制”“使用”“借用”等。
  社區（Community）：如金箍棒在故事中的完整鏈條。
• 圖譜構建
  將抽取的實體、關系、社區等組織成圖譜，存儲在圖數據庫中。
  通過嵌入（Embedding）優化查詢效率。
  
• 在線檢索與生成
  問題解析
• 用戶問題觸發 Local 和 Global 兩種檢索方式。
• Local Query：針對單個實體的細節信息檢索。
• Global Query：獲取高層次社區總結，描述全局關系。
  內容整合與生成
• 模型結合 Local 和 Global 檢索內容，生成準確的回答。
• 在全局檢索中，通過 Reduce 機制對 Community Report 進行排序和整合，進一步提升回答連貫性。
  回答特點
• 準確性：基于圖譜的推理與生成，更接近真實。
• 透明性：提供回答溯源，減少幻覺現象。

4. 角色扮演場景介紹

在角色扮演中，GraphRAG 技術被用于以下場景：

• 角色特點還原
  支持長文本內容分析，細化角色背景。
  如通過《長相思》的劇本內容，生成符合角色設定的回答。
• 多角色互動
  準確理解角色間復雜關系，如感情糾葛、合作或沖突等。
• 任務指導
  在游戲中引導玩家完成復雜任務，提供清晰邏輯線索

四、Agent 技術原理和應用

1. Agent 應用場景

• 目標驅動：首先通過用戶的問題引導整個過程，比如用戶希望根據天氣情況安排一場預算不超過一萬元的三天深圳旅游。問題涉及多個因素如日期、天氣、預算等，系統需要理解這些信息并進行思考、推斷。
• 外部工具的使用：為了執行任務，模型會調用外部工具，如天氣查詢、預算計算器、旅游產品查詢和購買工具等。這些工具可以幫助系統更好地理解用戶需求，并提供更加精準的解決方案。
• 智能迭代：通過不斷的理解和推理，系統會執行相關的操作并通過迭代逐步完成任務，使得過程更加智能，并具備動態規劃的能力。

2. Agent 技術原理

核心功能：Agent 技術結合了推理（Reasoning）和行動（Action），模型在執行任務前進行推理，并根據推理結果執行相應的行動。

3. Agent 在混元中的實現

角色定義：

• 用戶（User）：與系統交互的外部角色。
• 計劃者（Planner）：負責推理任務的角色，首先判斷任務是否完整，若信息不全則會反問用戶獲取補充信息，并通過推理計劃下一步操作。
• 工具（Tool）：用于執行外部任務的工具，如天氣查詢或產品購買工具。
  Agent流程
• 反復推理與執行：任務通過多輪推理和執行外部工具得以推進。例如，任務可能包括天氣查詢或旅游產品購買，系統會通過外部工具獲取結果，并進行進一步推理，最終返回答案給用戶。
• 動態規劃：系統會根據執行過程的反饋動態調整計劃，逐步優化解決方案。

4. Agent 應用案例

業務背景：騰訊云通過代理技術支持多個合作伙伴，幫助其提升用戶體驗和工作效率。通過與外部工具結合，平臺能夠在復雜任務中靈活調度和執行，自動化處理各類任務。

技術優勢：

• 復雜問題處理：相比傳統的搜索技術，Agent 技術能處理更為復雜的需求，結合外部數據庫查詢或 API 調用獲取信息。
• 插件支持：平臺支持插件定義，能通過外部工具擴展系統功能，提高任務處理的靈活性和效率。

5. 總結

• 用戶體驗提升：過去用戶需要適應機器的輸入要求，現在系統能夠理解自然語言的復雜需求，提供更加直觀和舒適的交互方式。
• 智能化和人格化：隨著系統智能化的提高，用戶感知到的互動更具人性化，甚至能產生與真人交互的錯覺。
• 知識處理的多模態化：原本結構化的知識轉向半結構化、非結構化，甚至是多模態的知識處理，提升了系統的智能程度。
• 自主決策能力：隨著技術的發展，模型將具備更強的決策能力，未來在某些情況下，機器的決策可能優于人類。

五、問答環節

Q1：在生成 chunk 之后，基于 chunk 生成 QA 對，在 embedding 時是將 QA 對整個做 embedding 處理，還是做緩存機制？

A1：有兩種格式的 embedding：一種是將問題 (Question) 和回答(Answer) 分開處理，其中問題部分單獨 embedding，回答部分作為附帶信息在召回時使用；另一種是做全文索引，這時沒有問題部分，只有文檔索引。

Q2：能否介紹一下中文語義切分的具體方法？

A2：語義切分通過訓練類似于 BERT 的模型，判斷文章在不同 token 之間如何切分，保證切分后的文章語義的完整性，并且考慮上下文的連續性以保證語義流暢。

Q3：在問答系統中，如何評估回答的有效性？

A3：我們提供了評估框架和指標，如回答的正確性 (correctness)、召回文檔的相關性 (relevance) 等。整個過程具有透明性，業務方可以通過工具評估和調試，包括輸入和輸出的測試，確保模型回答符合預期。

Q4：什么情況下判斷模型需要進行 SFT（監督微調），而 RAG（檢索增強生成）是否能滿足需求？

A4：判斷標準不明確，但一般來說，如果業務需要基于特定領域知識（如代碼或云知識）構建模型，或者處理復雜的任務結構，可能需要進行 SFT。如果模型的指令遵循不夠好，也可能需要轉向 SFT。

Q5：SFT 是否能改善模型在特定文本風格上的表現，特別是聊天機器人的風格（如 WhatsApp 風格）？

A5：通過 SFT，模型可以很好地學習特定格式或風格的文本。只要提供足夠高質量的樣本，模型能夠生成符合期望的風格。例如，在 prompt 中提供風格示例可以幫助模型更好地理解并應用風格。

Q6：精調后的 SFT 模型是否仍然適用于通用的 Agent LLM？

A6：SFT 后的模型依然可以作為 Agent 的 LLM，但如果將其應用到新的業務場景中，可能效果會有所下降，尤其是如果領域知識差異較大時。

Q7：翻譯后的 SFT 模型是否會影響其 PR（推理能力）？

A7：經過 SFT 微調后，模型的通用性可能會下降，尤其是在訓練數據不平衡的情況下。例如，如果增加了過多不同類型的數據，可能會影響模型在某些任務上的表現，導致效果回退。