一个暴论的结论

腾讯云开发者

发布于 2024-12-06 11:16:41

1060

在《说个暴论》一文中，我们揭露了当前关于大模型行业的一些乱象和痛点问题，其中重点提到了当前企业私有训练，不能调用外部 API 的情况下，可以利用开源 LLM+RAG 部署的方式，但这种方式的最大痛点是硬件成本和维护成本。而如果能调用 API，完全不用管有几台服务器，可以在任意时间，随意拉高并发量。

本文介绍了一种免去部署、维护、硬件成本的解决方案，利用腾讯乐享 AI 助手，企业可以实现基于企业内部知识库进行智能问答的业务场景，读者也可以从腾讯乐享 AI 助手的研发历程看到类似技术产品实现的方案逻辑。

关注腾讯云开发者，一手技术干货提前解锁👇

01、如火如荼的 RAG 社区

ChatGPT 的问世引爆了智能问答的市场，许多企业想要引入类似的产品，使之具备某个行业的专业知识，成为企业内部的“AI专家”，用以提升知识检索和生成的效率，加速企业各个业务流程的运转。RAG 的发展提供了技术上的可能性，于是二者一拍即合，企业 RAG 社区的建设就如火如荼地开始了。

但经过近两年的实践，企业发现：RAG 走通很容易，但从实际落地到应用于生产之间，还有很长的一段路要走，并且难度非常大。分享一个现实中遇到的例子：

一家中型公司认为“开源免费”能省很多钱，并且从技术上来看，自建 RAG 似乎并不难，不就是把一个向量数据库和 LLM 连起来吗？于是风风火火组建了项目团队，并很快上线了 RAG。结果不到三个月，整个团队已经乱作一团，一个工程师全职解决大模型幻觉和准确性问题，一个数据工程师拼命处理各种数据摄取和清洗问题，还有一个工程师天天被性能和基础设施折磨，更糟糕的是安全问题，每天不是在救火，就是在救火的路上。与此同时，预算早已翻了不止五倍......

为什么会出现这样的问题呢？

02、随需而变，回归理性

首先 RAG 系统本身，就需要解决知识库内容缺失、整合策略限制导致脱离上下文、答案不完整、格式错误等常见技术问题，此外，基础设施的搭建、数据库托管、数据安全、日常维护和运营等问题，也都是企业要源源不断投入人力和成本的地方。

因此，企业自建 RAG 虽然听起来激动人心，但具体实践还要回归理性。选择市面上已经非常成熟的产品也不失为一个高性价比选项。

乐享 AI 助手可基于全站知识进行智能总结问答，并提供参考链接

相比企业自建，腾讯乐享 AI 助手在以下方面独具优势：

2.1“知识管理”内核稳固

在 RAG 社区流行一句话是“Garbage in, garbage out（垃圾进，垃圾出）”，意思是说，如果我们给大模型的知识是不规范的、格式混乱的，那么大模型输出的答案也必然是不准确的、令人沮丧的。

腾讯乐享 AI 助手有两大核心模块，除了大语言模型，就是“知识管理”这个内核。在产品设计之初，就是以腾讯乐享在知识管理领域多年的项目经验为基础的，在知识的分类、权限管控、文档内容解析等方面有着深厚的技术积累，因此，才能在大模型时代快速构建起“Quality in, quality out”的 AI 助手。

2.2 丰富的行业经验积累

行业不同，业务流程和需求也是千差万别。腾讯乐享拥有30万+注册企业，1亿授权用户，行业覆盖率达到了100%。随着服务时间和经验的累积，以及与不同行业客户沟通的深入，腾讯乐享用真实客户诉求驱动大模型迭代升级，提升回答质量，持续提升产品性能。

这些扎根于真实业务场景而做的优化，也为乐享带来了更多的客户，进而得以收集更多行业的业务需求和反馈，最终反哺在产品能力上，形成良性循环。

2.3 高效的资源管理能力

大模型应用构建并不是一蹴而就的，无论是建设初期，还是后续维护，都需要大量资源的持续投入。除了大模型本身的高额成本，在现代企业环境下，流量峰值往往会有较大波动，弹性资源配置是保证高效运行的重要手段。腾讯乐享 AI 助手具备自动化监控、故障检测、智能化负载均衡等能力，并可基于腾讯云提供的弹性服务，灵活调整资源配置，优化成本效益。

2.4 大模型基座及训练架构的先进性

大型语言模型的开发和训练，需要大量计算资源和前沿技术知识。首先，乐享 AI 助手使用了腾讯自研的混元大模型基座，在高质量内容创作、逻辑推理、多轮对话上性能表现卓越，处于业界领先水平。

其次，按照常规流程，无论是大模型的精调，还是数据清洗，其中的工作都非常繁琐复杂。而腾讯自研的“混元一站式平台”可以将大模型从训练到部署整个流程自动化、可视化，正是有这样高效便捷的工具，乐享 AI 助手才能够快速地将最新技术应用到产品中去。

03、腾讯乐享 AI 助手的进阶之路

回到乐享最关心的用户体验上，我们认为在企业级知识问答技术上，仍然可以在以下三个维度继续精进。

3.1 维度一：模态多样化

AI 问答的基础是“知识”，对知识的组织和管理会直接影响大模型的回答效果。

//知识的重要性

我们服务某个软件企业时，客户期望使用乐享 AI 助手帮助售后客服人员快速找到相关答案，提高客户响应效率。但在产品使用初期，总是显示该问题无法回答。经过深入交流后才发现，原来售后客服人员认为有些知识“理所应当”地要存在于大模型中，所以并没有给到大模型相关的知识来源。

这个现象很常见，因为长期处于某个专业领域的工作人员，会在大脑中预设一些“缺省值”，而这些值并没有和大模型“对齐”，所以，哪些知识可以使用模型内部固有的知识（比如：天空为什么是蓝色的）？哪些必须参考用户输入的文档内容？这就需要不断调教大模型，才能把握好这个“度”。

听了我们的解释和建议，该企业的售后部门将现成文档和资料进行了导入，最终，问答准确率和采纳率都有了极大提升。

以上例子说明了企业有知识和没有知识的差别。但现实是，大部分企业是有现成的知识的，并且量很大。这就引发了下一个关键问题 —— 知识模态。、

//知识模态

我们所熟知的大模型准确来说是“大语言模型”，也就是专门处理文本的模型。文本模型的足够强大，才支撑了 RAG 系统中的“文本分割”、“文本编码（Embedding）”、“文本检索”、“大语言模型生成”等各个环节。

企业文档五花八门，尤其在 PPT、PDF 中存在大量图像，单一模态的文本模型，是无法处理这些信息的。那么，使用“多模态大模型”能否解决呢？

可能可以解决 RAG 链路中的部分问题，但非高枕无忧。在技术无法端到端解决的情况下，需要对“图像理解”有清晰的定位和定义（也就是需求分类），然后构建完善的工程架构，去处理不同客户对“图像理解”的诉求。

最简单的情况是，这些文档中的图片只是文字的拍照版本，或者企业的诉求只是需要提取图像中的文字，那么使用成熟的 OCR 技术即可。

更进一步，有些企业中的文档图片多为“线框图表”、“架构图”、“流程图”等相对规范的图表，那么可以在文档解析阶段，用一个小模型将这些图像转为 Markdown 格式的文本。

以上这两种分类，都是从图像到文字的转换，信息损耗极其微小，是可行的。但在具体的技术实现上，则需要进行模型训练，让模型尽可能多地学习从图表到文字的映射关系，这是一个长期迭代的过程。

对于其他更广泛的图像，比如产品示意图、零部件示意图、LOGO 等，就无法简单地进行文本转写来百分百实现，因为我们不知道将图像转写成什么文字，所以有两条路线，一条是优先提升 RAG 系统的上限，一条是优先提升 RAG 系统的下限：

提升上限就是彻底突破旧有文本模态 RAG 的限制，比如，搭建纯视觉 RAG 流程，实现“图文语义表征”、“图像搜索”、“图像问答”等功能，把文档当做一张张图片来理解和计算，有的称为 OCR-free（免 OCR）方法，也有叫 Visual RAG（视觉 RAG）系统。

提升下限就是在原有的文本 RAG 流程中补足图像信息，比如在文档解析阶段通过多模态大模型和产品交互的方式引入 Image Captioning（图像描述）能力。

无论哪一种方案，目的都是：1.让检索系统能从海量文档中定位到相关的图像；2.根据检索到的有限个图像，回答用户的问题。

乐享 AI助手可提供图文并茂的回答，并帮助用户快速定位相关图片

不同企业的图像风格也是迥然不同，如何在参数量可控（也就是不影响成本）的前提下提升模型的泛化性，是长期努力的方向。

3.2 维度二：知识跨度

以“长窗口”性能强大而著称的 Kimi 大模型创始人提出过一个形象的比喻，把大模型的窗口长度比作“内存”，把 RAG 所依赖的知识库比作“硬盘”，那么，在 RAG 问题上就产生了这样一个讨论：如果未来大模型窗口支持无限长，那么，是否就无需知识检索环节，直接将全量知识一口气丢给大模型就可以了？

目前在腾讯乐享 AI 助手中，RAG 中的知识检索环节还无法被去除，窗口的长度也需要尽可能的长。知识检索无法被去除比较好理解，因为目前大模型在超长文本中的问答表现差强人意，而且成本不可控，所以就需要“检索”这个环节来帮助大模型缩减冗余信息。

//长窗口的必要性

那么，窗口的长度为什么也需要尽量长呢？这就涉及到对用户 Query 的理解和分类了。

最简单的 Query 我们称之为局部知识获取，也就是知识跨度范围最小的情况，比如：某某在哪一年出生？恰好文档中有一段内容直接描述了该问题，那么只要检索到该片段就算检索成功。但在多文档知识问答场景中，经常出现跨文档的信息检索类问题，比如：帮我找出所有上线的版本号？某某都有发表过哪些演讲主题？这就需要足够长的上下文窗口。

下文”维度三：推理复杂度“将讨论用 Agent 思路解决，但在上下文长度支持方面，依然是多多益善。

//单文档场景问答能力

除了支持多文档知识问答，腾讯乐享 AI 助手还特别设计了单文档场景问答能力。表面上看文档数量缩小了，似乎难度更低了，但其实是完全不同 Query 需求空间。因为在单文档场景中，有一大部分需求是做“摘要”，而“摘要”又有不同的需求分类，我们参考了 SuperCLUE-Long 对“摘要”任务的划分：

全文摘要：例如，这篇文章讲了什么 / 对文章做个总结
局部摘要：例如，对“国内外研究现状”部分做个总结 / 总结一下某某发言内容
线索摘要：例如，总结一下某某机构的发展历程 / 总结某事件的发展过程

这些任务很难通过搜索引擎来缩减冗余信息，甚至会干扰有效信息，所以，最好的方式是将全文直接交给大模型来处理，因此，大模型窗口需要足够长。腾讯混元大模型支持 256k 长上下文窗口，也就是大约20万字的输入，为乐享 AI 助手提供了较大的操作空间。

腾讯乐享 AI助手支持长文档问答

回到实际问答上，窗口长度越长会带来问答效果的下降。在实践中，我们确实遇到过一些超过20万字的文档，这就需要使用文本压缩技术来对原始文本做加工处理，就像 PC 的文件压缩工具一样，大模型文本压缩工具也是在尽量保留有效信息的情况下，缩短上下文的整体长度，来保证问答效果和阅读体验。

3.3 维度三：推理复杂度

首先澄清一个概念，这里所说的“推理”不是狭义上的“大模型训练阶段和推理阶段”中的推理，而是站在用户角度，为了满足用户查询需求，所依赖的类似人的逻辑思考能力。比如前段时间 OpenAI 公布的 o1 大模型，能够解决复杂的数学题或猜字谜游戏，这就说明它的推理能力很强。

半年前 LlamaIndex（一家专注研发大模型应用程序框架的企业）的联合创始人兼CEO，Jerry Liu，发表了《Beyond RAG: Building Advanced Context-Augmented LLM Applications》主题报告，指出了以“内容解析、索引、检索、模型问答”为核心流程的“Naive RAG”具有较大的局限性，RAG 的最终归宿应该是 Agent，即通过“多轮对话、任务规划、工具/接口的调用、自我反思、个性化记忆”等能力的增强，来实现对用户更高阶需求的满足。

同样意识到 RAG 的局限性，并对用户查询需求做了深度剖析的是微软亚洲研究院，在两个月前发表论文《Retrieval Augmented Generation (RAG) and Beyond: A Comprehensive Survey on How to Make your LLMs use External Data More Wisely》，研究者们将用户的查询需求按推理的复杂程度分为4个级别：

（图片来自：《Retrieval Augmented Generation (RAG) and Beyond: A Comprehensive Survey on How to Make your LLMs use External Data More Wisely》）

第一个级别是 Explicit Facts（显性事实查询），指的是该查询在某一篇文档有且仅有一处现成的答案，这是最简单的情况。

第二个级别涉及到跨文档，但好在通过多篇文档的知识片段能够“汇总”出答案，只是答案比较分散，称为 Implicit Facts（隐性事实查询）。

这两个级别在上一小节“维度二：知识跨度”中已作详细说明，不再赘述。第三和第四个级别对 Naive RAG 系统才是真正的挑战。

第三个级别为 Interpretable Rationales（可解释的推理查询），即，源文档中没有现成的答案，需要根据若干事实/既定规则完成推理。

以客服场景为例将很好理解，客服人员在解决客户问题时，不仅需要依据“操作手册”中的条例，而且还要结合客户具体的问题，才能给出合理的解决方案。RAG 系统需要达到的就是类似这位客服人员的推理能力。

第四个级别是 Hidden Rationales（隐性推理查询），即，源文档中没有现成答案，同时也没有“手册”可参考，只有历史问题和答案，这就需要根据历史来挖掘“模式”，总结经验，然后回答问题。这种情形的推理在法律行业比较常见，比如律师遇到了一件新的案情，希望通过查询历史相关案件的背景和判定结果来辅助当前案件的决策。

由此可见，当前 RAG 系统在复杂推理场景中还有很大的提升空间，无论从整体技术架构的升级（Agent 方向）还是大模型内在推理能力（类似 o1 模型方向），都需要长时间的探索和积累。