我要投稿

腾讯 | 混元大模型业务落地实践

发布日期：2024-12-16 12:06:18 浏览次数： 2760

作者：NewBeeNLP

微信搜一搜，关注“NewBeeNLP”

在本篇文章中，我们将深入探讨腾讯大语言模型在多个业务场景中的应用，特别是如何通过前沿技术提升模型的智能化与用户体验。首先介绍腾讯大模型的广泛应用场景，如内容生成、智能客服和角色扮演等，并详细解析 RAG（Retrieval-Augmented Generation）技术及其在实际业务中的创新应用，特别是在文档生成和问答系统中的优势。此外，文章还将探讨 GraphRAG 在角色扮演场景中的应用，如何结合知识图谱优化复杂的知识推理。最后，将深入分析 Agent 技术的原理与应用，展示其在目标驱动任务中的强大推理与执行能力。通过这些技术的结合与实践，腾讯正在推动大语言模型在各类复杂场景中的智能化演变，提供更加精准且高效的解决方案。

主要内容包括以下几大部分：

1. 腾讯大语言模型应用场景

2. RAG 技术原理及应用实践

3. GraphRAG 在角色扮演场景中的应用

4. Agent 技术原理和应用

5. 问答环节

分享嘉宾｜赵喜生腾讯高级工程师

出品社区｜DataFun

腾讯大语言模型应用场景

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 微调后，模型的通用性可能会下降，尤其是在训练数据不平衡的情况下。例如，如果增加了过多不同类型的数据，可能会影响模型在某些任务上的表现，导致效果回退。

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业