腾讯文档AI助手技术实践
作者：tensorchen
本文从技术应用架构以及AI大模型赋能角度介绍腾讯文档AI智能助手的探索和实践之路。作为一款集多功能为一体的AI产品，腾讯文档全品类与AI进行了深度融合，全面提升用户生活和办公中的效率。通过腾讯文档AI，你脑海中灵光一现的Idea可以快速转化为详细的内容，在各种类型的文档中同源流转。同时，面对纷繁复杂的信息，腾讯文档AI也可以加以分析处理，帮助你从海量的信息中提炼出有价值的内容，从而将他们转化为属于你的认知。
第一章：大模型给效率工具带来的挑战
随着ChatGPT的发布和火爆，全世界的目光仿佛都聚焦在了大语言模型上；其强大的语言理解能力和生成能力、上下文记忆、学习纠错、思维链推理等关键能力的涌现，都标志着”AIGC“的发展到达了技术拐点。全世界的开发者手握一个如此威力巨大的雷神之锤，恨不得把所有的钉子都锤一遍，所以大模型火热的开始阶段，有了这样的一个言论：”世界上所有的app都可以结合大模型重做一遍“。话语虽经不起推敲，但大模型在一些领域确实可以提高惊人的效率，尤其是效率工具领域，从以下几个宏观角度分析，确实给效率工具带来了极大的机会。
● 技术上：文本生成领域技术发展相对成熟
大模型落地最开始的应用，就是用于文本生成，同时在文本生成技术上发展也是最快最成熟的，承载用户创作的效率工具是天然落地的有利场景，可以极大提高用户创作环节的门槛和效率。
● 用户上：关注热度极高
用户关注度是大家极容易忽视的一个分析角度，当新技术、新概念问世后，无论新技术有多厉害，最终是要落地成为产品服务用户的。叫好不叫座的技术/产品，并不是真正的好技术/产品。
从百度关键词搜索指数，可以看出ChatGPT问世以来，所覆盖的用户面足够广、用户接受度和对其感兴趣程度极高，搜索指数峰值达85W，可算是今年的“互联网春晚”。过查询历史数据对比，可更加具象化的了解本次搜索热度：
上一个爆火的元宇宙概念， 搜索峰值指数不过10W，不及本次ChatGPT的1/8。
22年除夕当天，春晚关键词搜索指数150W，本次ChatGPT的关注度峰值已达春晚的一半。
● 发展规律：工具始终在率先变革
历史不会重复，但会押韵。从过往历代新技术变革到现在，每次工具都会率先的进行变革，一代人有一代人的生产力工具。
**
同样从全球/全国的竞品数据表现来看，完全也印证这件事：用户对文档类工具与AI的结合接受度高，需求旺盛，是本次大模型爆发后重点落地的优势领域。
全球访问量前100的AI产品中，共有12个文档类工具竞品上榜；全国访问量前100的AI产品中，共有26个文档类工具竞品上榜。
是新机遇但也确实是新挑战，对传统效率的革新并非一蹴而就，无论是用户认知教育、产品能力建设落地及差异化竞争、商业化模式都是新的挑战。本文会重点聚焦于 AI技术在产品落地环节及模型部分，其余部分不在此长篇幅展开，埋坑后续更新~
第二章：文档AI技术思维及架构
本章从技术角度介绍整个腾讯文档AI技术工程的具体实践架构，以及自身对AI应用落地的技术思考。
2.1 AI应用技术思维
在实际应用思维模式可以总结为：
1. 对人困难的，对AI也困难
2. 能让程序做的，就不要让AI做
举个可能不完全契合的例子：
人捕鱼这件事：人思考决策使用渔网（工具）进行捕鱼。普通人不会实际制作渔网，普通人制作渔网需要有人教授相关技能，过程费时费力，成效低，见效慢。
AI起到的是授人的作用；工具起到是渔的作用
在文档实际案例中，AI协助用户美化PPT这件事：AI理解用户需要美化PPT，AI决策使用PPT美化工具进行美化。AI不会实际美化PPT，AI美化PPT需要有人教授AI相关技能（海量的高质量的PPT美化相关数据进行模型训练），过程费时费力，成效低，见效慢。
"将整个PPT的字体调整为宋体" 任务
AI: 用于解决对话中理解用户调整字体的意图和具体的字体类别
工具：文档PPT调整字体工具进行实际的执行
"创建一个关于明朝历史的PPT" 任务
AI: 用于解决对话中理解用户创建PPT意图和主题 明朝历史
AI：基于明朝历史这个主题生成大纲和详细文本内容
工具（搜图工具）：基于大纲进行图片搜索，实施PPT配图
工具（PPT模版）：基于大纲，文本，图片 + 模版，生成完整PPT
腾讯文档自身业务包含诸多品类，例如Word，Excel，PPT，PDF，收集表（Form），思维导图，流程图，智能表格（SmartSheet），智能文档（SmartCanvas）以及正在进行中的白板品类。
不同品类是以产出为导向构建的产品形态，内容和形态叠加在一起，（Word需要调整格式，PPT大家需要学习美化）。其核心在于内容信息的表达。
因此，落地腾讯文档AI应用时， 从技术角度思考通常 应用AI解决内容相关问题，应用工程解决形态或者样式问题。
2.2 文档AI技术架构
● AICopilot：提供AI侧边栏对话入口服务，主要负责对话的意图识别工具分发，意图保持，柔性处理，缓存逻辑，会话存档等能力。
● AIServer：提供各品类独有浮层助手能力。
● AIAgent：定位于AI智能体，目前主要提供文档各品类的能力工具集合，被上层服务的意图识别后所实际的驱动的接口。
● AIEngine：文档的AI引擎服务，涉及对AI相关能力的抽象和封装，保持统一抽象定义（主要包含文生文，文生图，TTS，ASR，OCR，Embedding等AI能力的抽象），屏蔽不同AI能力间的差异，奠定文档可以在不同AI能力进行无缝切换的基础。
● AIOperation: 文档AI相关的灰度策略，隐私授权（柔性），运营操作。
● AIExtension：AI拓展服务，主要包含和规划为AI应用落地过程中的其他支撑能力，例如文本搜索，图片搜索，Python执行引擎。
2.3 文档AI中台架构
文档AI中台的概念初始于腾讯文档这款产品本身就存在10种品类，期望以中台解决方案的形式为不同品类进行赋能，同时也是这样实践和落地。此不仅仅在于腾讯文档产品本身，依据部门内整体产品矩阵，也更需要将文档xAI基础能力作为中台，交付和赋能不同的产品。
文档AI中台同具体模型和产品应用解除耦合，形成了可以为不同产品赋能的文档xAI解决方案，提供对文档AI领域的整体解决方案，赋能不同的AI应用产品。
2.4 中书阁AI应用框架
在文档AI应用和中台落地过程中，也将AI技术和周边能力生态抽象实现为AI应用框架，其定位：AI应用落地的应用框架建设 。愿景：AI For Everyone，降低AI应用技术门槛，提升AI应用研发效率 。
理念：
1.标准化：主要承接Oteam前两项内容 AI应用标准 和 AI应用规范，其将通过AI应用框架的标准化建设最终输出给业务研发者。
2.可视化：在大语言模型应用中往往遇到多次同大语言模型交互并调用外部工具，对其中的过程的可视化将有助于研发调试，问题定位以及运营分析等。
框架将提供UI平台，提供LLM应用过程的可视化界面（包含耗时分析，Token消耗等等内容）。
框架也将提供LLM的可观测性，提供基于OpenTelemetry标准的监控，分布式追踪和日志等数据的上报。
3.多语言框架：将提供多语言实现，以满足不用业务应用场景和业务技术栈。
对非AI专业友好，框架站在使用者角度进行模块和能力抽象，多语言提供AI应用开发聚焦在AI产品能力落地及效果优化。
第三章：文档AI应用侧技术实践
3.1 问答场景应用
文档产品最核心能力之一是信息传达，海量的信息中对信息进行AI问答是关键AI落地场景之一，在文档中涉及对Word，PPT，Sheet，思维导图，收集表，知识库等场景内容的问题。
文档的AI应用工程实现关键一点在于搭建文档问答的基础解决方案。解决此类的问题的关键在于如何让大模型理解领域知识（特定文档中的内容信息）。
通常有两种解决方案:
● 方案一：领域知识通过FT方式进入模型的权重文件中或通过LoRA动态叠加到模型权重文件中。
● 方案二：通过Context的方式即时的将领域知识传入模型。
用户的文档信息，是用户自身的信息的集合，它主要服务于用户自身。我们不可能为每位用户专门训练模型，基于时效性的考虑用户文档经常变更，也不可能每次变更重训模型，其次基于用户隐私的考虑，我们也不可能将用户数据拿来进行训练。显然方案一不可行。
那么在文档中实际进行落地的也是方案二：通过Context的方式即时的将领域知识传入模型。
这种技术被称为 RAG，RAG （Retrieval-Augmented Generation）搜索增强生成技术，也就是一套基于特定知识库的检索召回和大模型模型生成的技术方案，用于处理大模型中各种复杂的知识密集型任务，如知识问答。
整体解决方案由如下模块串联完成：
l 文档加载：定义统一的 Document 数据模型，将实现默认典型的数据源加载实现，业务方也可以根据接口自定义实现自身所需文档数据源。
文档分片：大语言模型上下文大小有一定限制，需要将大量数据进行分割操作。
文档Embedding：Embedding过程将对应文本向量化，以提供更好的语义表达。
文档向量存储：使用向量数据库存储文档向量信息。
文档召回：根据用户输入的问题召回跟问题最相关的文档信息。
问题解答：根据召回文档资料 + 用户输入问题提供给大语言模型进行知识问答。
为解决如下两种场景，在原有架构上规划进行进一步的升级。
1.解决元数据问答、总结、非总结类问题
2.解决涉及多模态文档的问答
3.2 意图识别应用
依在文档AI实际产生应用效益，需要将用户意图实际转化为具体的行为
挑战一：上百种指令场景
挑战二：意图和任务流程各不相拥，通过会涉及多种工具的串联
如下实际用户使用的示例:
结合用户不同输入应用场景，落地AI功能，关键在于 意图识别 和 任务编排
● 通过PromptID为唯一任务索引
● 将能力标准化工具化
● 通过As Code形式对任务进行编排（参考gitlab的，利用yml进行任务编排上百种任务场景）
用户意图更大的挑战是 多意图识别，用户可能同时进行字体调整和字号调整，对于上述的解决放哪，我们是不可能使用单个function call解决问题的，function call的参数有限，也无法预测所有的用户行为。
那么可行的大概两种：
方案一：多轮Function Call
方案二：生成代码
最终我们规划使用生成代码的方案，主要多轮function call实现上无法解决任务顺序问题，而通过生成的代码是可行的。
3.3 表格应用场景
表格场景最大的挑战是表格内容容量，根据目前大模型的context容量，大概只能支持有限个单元格。超大表格解决方案，核心策略在于：将原有AI返回结果升级为AI返回得出结果的方式方法（即代码）。
第四章：文档AI模型侧技术实践
4.1 创作场景模型
使用数据增强方法，强化薄弱能力
对于创作能力，使用self instruct、evol instruct等方法构造类似的种子指令、并通过复杂化进化和泛化，进行数据增强。可以有一套比较标准化的流程：
● 收集种子指令 ：收集新需求，人工编写简单种子指令；
● 指令多样化：参考self instruct、evol instruct 宽度变换的做法，对种子指令进行多样性变换，覆盖更多的领域、主题、形式等；
● 指令复杂化 ：参考evol instruct 深度变换操作（例如：增加约束、增加参考示例、增加具体化操作等），为种子指令添加约束，让指令变得复杂，为每个指令增加3-10个约束条件；
● 指令泛化：对进化后的指令同意改写，进一步丰富表达方式和形式，每个指令改写3-5种形式。
● 结果抓取：标注和抓取上述进化后的指令；
● 结果清洗：使用self-refine、人工检查等方式，抓取结果的准确率接近100%。
对比学习方式，提升理解稳定性
针对差别较小，难以区分的任务，例如：约束漏点、否定约束、数字要求等任务、专门构造对比样本，加入sft或者进行强化学习。这类样本可以加入sft阶段学习，可以构造pair数据，加入偏好学习阶段。
● 局部对比：在约束数量较多的情况下，模型难以兼顾到所有约束。容易出现漏点问题。通过从指令中逐个去掉约束、其他部分不变的方式，增加局部对比的样本，让每个约束在指令中出现和没有出现的情况对应什么response，模型都见到过。
● 否定对比：针对否定约束，通过去掉否定条件和对否定条件取反的方式，构造对比样本
写一篇邮件，关于提前预约我们的美容护肤师，享受专业的面部护理服务和个性化护肤方案推荐。邮件需包含邮件主题、收件人、发件人、正文等基本部分。在邮件中指出收件人需要在预约后的48小时内完成预约确认和安排护肤师的任务，并提醒收件人应通过电话或电子邮件回复预约信息。不要出现"顺祝商祺"
● 数字变换对比：对指令里的数字要求的数字进行变换，构造对比样本
编写一篇关于未来城市规划的短文，强调可持续发展和绿色出行的重要性。同时，探讨如何有效利用现有资源，以减少对环境的影响。请务必包括至少三个创新性的规划策略，并在文中提供相应的实例或案例。
编写一篇关于未来城市规划的短文，强调可持续发展和绿色出行的重要性。同时，探讨如何有效利用现有资源，以减少对环境的影响。请务必包括至少六个创新性的规划策略，并在文中提供相应的实例或案例。
4.2 表格场景模型
公式生成
公式生成除了可以识别基础公式需求外（“求A列的和”），还支持热门领域专业术语的理解，例如：用户问营运资金周转率最大的产品，基于混元知识蕴含能力，混元知道【营运资金周转率=销售额/平均营运资金】，进而计算出每个产品的营运资金周转率。
此外，在技术方案上使用了思维链（COT）+代码生成（POT）的方式，解决公式嵌套带来的效果不稳定的问题。
思维链（CoT）被认为最具开拓性和影响力的提示工程技术之一，它可以增强大型语言模型在决策过程中的表现。
CoT迫使模型将推理过程划分为中间步骤。这种方法类似于人类的认知过程，将复杂的挑战分解为更小、更易于管理的部分。
思维程序（PoT） 是一种独特的LLM推理方法。它不仅仅是生成自然语言答案，而是要求创建一个可执行程序，可以在Python等程序解释器上运行，从而产生实际的结果。
PoT提供了一个更清晰、更具表达力和基础的答案推导模型，提高了准确性和理解力。
图表生成
图表生成的核心部分包括6个模块，其中拒识、分步改写、代码生成三个模块是基于大模型的推理模块，背后模型均经过了模型精调。
具体地：
拒识模型能够识别用户问题和表格的相关性，对与表格无关的问题或非绘图问题进行拒绝回复
分步改写模型针对不同表格和不同问题，将绘图步骤拆解为多个可执行步骤
代码生成模型根据绘图步骤生成python表格可视化代码。
第五章：总结
结合腾讯文档AI落地过程，总结一下AI助手开发过程中的一些经验：
对人困难的，对AI也困难
能让程序做的，就不要让AI做
应用AI解决内容相关问题，应用工程解决形态或者样式问题