ChatGPT的问世引爆了智能问答的市场，许多企业想要引入类似的产品，成为企业内部知识的“AI专家”，用来提升知识检索和生成的效率，加速企业内部的知识获取、流转和利用。RAG的发展提供了技术上的可能性，于是二者一拍即合，越来越多的企业开启了RAG构建之路。

RAG（Retrieval-Augmented Generation，检索增强生成）是一种人工智能框架，旨在利用大型语言模型（LLM）进行跨外部知识源的自然语言查询。RAG的核心思想是通过外挂知识库的方式给大模型提供更可靠的知识来抑制模型产生幻觉，通过定期迭代知识库的方式解决大模型知识更新慢和训练成本高的问题。说人话就是，RAG可以让大模型的回答得更准确。

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

以下从三大能力维度，八个子方向，来阐释腾讯乐享在服务企业客户的过程中，遇到的问题、思考过程及解决方法。

这三大能力维度相辅相成，缺一不可，分别是：知识管理能力、工程能力、算法能力； 八个子方向体现了各维度的纵深，形成一张纵横交错的RAG航海图。

目前在C端的AI助手类产品中，大多附带了“知识问答”功能，即，上传一篇或多篇文档，可以支持对这些文档进行提问。而在企业级知识问答场景中，为了沉淀“群集智慧”，一套能够支持多人多端协同的知识管理平台是必要的。

为了使得大语言模型能够利用沉淀好的知识，高质量完成问答流程，腾讯乐享从“知识有没有”、“知识质量高不高”、“知识管得好不好”三个方向来介绍可能存在的“坑”和解法。

1.1知识的边界（知识有没有）

大模型本身已经拥有了海量的“世界知识”，即使不用上传额外的文档，也能回答很多问题，那企业到底要将什么样的知识给到大模型？

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

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

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

1.2 知识解析（知识质量高不高）

当企业上传了大量文档后，就会面临下一个问题 —— “Garbage in, garbage out（垃圾进，垃圾出）”，意思是说，如果对这些文档（Word/PPT/PDF/Excel等）解析得不够好，那么给到大模型理解的内容就是不规范的、格式混乱的，从而导致大模型输出的答案很有可能是不准确的。

尤其在PPT、PDF中，很容易出现复杂格式的内容，这里会涉及的技术包括对于版面、段落等区域识别的技术，文字、表格识别技术等等。下面我们重点谈一谈客户较多提及的诉求——图像解析。

我们归纳多个客户对于图像解析的诉求主要是2个方面：

宏观角度

有些行业比如工业、制造业，存在大量的工程图纸、零部件示意图等。这类图像的特点是：线条复杂，图文混排程度高。经过和客户的深入沟通了解，他们其实并不需要将内部的细节完整解析出来，而是希望在询问相关问题时，能将图像带出即可。

这就需要在文档解析阶段，使用Image Captioning（图像描述）能力，为图像附上关键描述信息，让大模型能够知道这张图大概呈现了什么，是什么类型的，在大模型回答的内容中，大大提高带出相关图像的准确率，否则大模型只能靠图像周围的文字来“猜”。

微观角度

在很多场景中，仅在回答问题时带出完整的图像是不够的，还需要基于图像做更精准的回答，这就需要对图像做更深的理解。在腾讯乐享服务的客户中，其中有一部分比较共性的诉求是，提问和企业流程相关的问题，这里会涉及很多架构图、流程图、思维导图等，这些图像有两个特点：

• 图形的表达相对收敛，适合基于特定类型的图像范围收集数据和做小模型训练；

• 这些图像都可以转换为Markdown格式文本，信息损耗小。

因此，在微观图像理解场景中，腾讯乐享借助腾讯云大模型知识引擎团队构建的“图生文”解析模型完成从图像到文本的精准转换。

1.3 知识权限（知识管的好不好）

每个企业都有不同的职能部门，有不同的管理角色，以及对应的文档资源的权限。稍大规模的企业组织，还有涉及到分子公司和外部伙伴的管理，这使得部门、人以及资源的权限相互交织，处理起来异常复杂。

例如，隶属部门A的你，在部门B管理的文档库中，新建一个仅对部门C可见的文档D时，请问E部门的管理员能否访问文档D的内容？对应到知识问答场景也是一样的，当E部门的管理员发起Query请求时，系统能够检索到哪些文档，应该与整个权限体系保持同步，最终只能呈现E部门管理员拥有权限的文档。

腾讯乐享脱胎于腾讯内部知识分享和管理平台KM，因此在权限管控、知识分类等方面有多年的方法和技术沉淀，在多角色的管理员维度、文档维度、社区维度等维度上，都有清晰的权限管控逻辑。

腾讯内部的KM平台承担着连接腾讯庞大的员工网络、促进知识的高效流通和利用的重任。正是基于这一丰富的实战经验，腾讯乐享在设计之初便深深植入了多层细致的权限管理机制和科学的知识分类体系。

针对所有自学遇到困难的同学们，我帮大家系统梳理大模型学习脉络，将这份 分享出来：包括等, 😝有需要的小伙伴，可以 扫描下方二维码领取🆓↓↓↓

👉[CSDN大礼包🎁：全网最全《LLM大模型入门+进阶学习资源包》免费分享（安全链接，放心点击）]()👈

RAG技术是被大模型带火的，但只有大模型是远远不够的，除了上述提到的知识管理能力外，构建一套完善的工程架构很重要，因为，它决定了RAG系统的下限。

在将知识给到大模型之前，有一套很长的流程要走，包括Query预处理、文本切分、建索引等，每个环节都需要仔细打磨，是做RAG的基本功，系统回答不正确很可能在走到大模型环节之前已经出错了。另外一个体现工程架构完备性的地方在于，对于大模型自身的迭代，需要一套高效的训练、部署框架来承载，去保障模型的更新与服务的稳定性。下面分别对这两个方面来展开介绍。

2.1 检索

在很多企业自建的RAG系统中，刚开始大部分问题都出在这个环节。因为该环节流程长、涉及的技术栈丰富，需要较强的Debug能力，要分析实际的Badcase，来设计对应的解决方案。

由于检索技术在业界有比较丰富和成熟的方案，包括文本分割、文本向量化、关键词索引、相关性排序等等，每个环节都值得深入优化，不再赘述，这里主要从客户需求出发，分享我们观察到的“问答系统”和“检索系统”的一个典型区别。

“用户来到RAG系统中会提一个问题”，这是我们预设的标准场景，但事实上，用户可能并不是提问，而是和AI打了个招呼，或者希望AI帮忙写一篇文章。就算用户提了一个问题，也可能使用了不完整的表述，因此，该环节需要完成对Query的意图分类和改写。

“意图分类” 就是要判断用户的这句话是想做什么，意图是什么，每种意图要对应不同的应对策略，就像一个“路由器”，分发给不同的处理模块来处理。我们所说的狭义上的RAG，只是其中一类模块，除此之外，要需要结合不同的查询需求，设计合理的处理模块。

“改写” 就是要结合上文对话历史，将用户的提问转换为更加完整、精准的表述，使得后续的“检索”效果更好，比如，在一家多地办公的企业里，某员工和AI在聊关于“中国区员工福利政策”的话题，当问到“病假有几天？”，此时需要根据上文推理，将提问补充为“中国区员工的病假有几天？”这样一个完整的表述。

2.2 模型训练与部署

大型语言模型的开发和训练，需要大量计算资源和技术知识，这里以精调知识问答模型为例：

• 首先是选择一个合适的模型基座，确定模型的参数尺寸，是7B的还是70B的，是MoE架构的还是Dense架构的？

• 然后是准备数据集。任何有效的精调都依赖于高质量的训练数据集，高质量数据集依赖精细准确的标注，但手动标注通常既耗时又昂贵，需要一些自动化技术来加速流程和增强数据质量。

• 接下来就可以开始精调，但精调大模型需要较长的训练周期和大量计算资源，如果是多张GPU卡，还需要使用分布式训练方法，加速训练进程，但更麻烦的是，如何优化训练参数来保证最优的效果？

• 精调后的模型需要评估性能，如果基于知识问答场景指定有效、合理的评价指标，并自动化执行评估？

• 最后，当模型评估通过，需要通过版本管理工具，将模型部署上线，并持续监控其表现，根据线上流量情况，动态扩缩容。

以上简要描述了做模型精调的核心流程，可见十分繁琐，耗时耗力，这就不得不提腾讯内部的“混元一站式”平台：在模型方面，提供了各种尺寸的基座模型矩阵，可以按不同能力长项、使用场景、技术架构来选择和对比；在数据管理方面，提供方便的数据质检、比例调配、价值观对齐等自动化工具；模型精调、评测、部署上线也都做到了自动化执行，可以说，“混元一站式”平台将大模型精调的整个流程都做到了可视化、自动化，甚至只需鼠标点点就能快速完成。

正是有这样高效便捷的工具，乐享AI助手才能够快速地将最新技术应用到产品中去，在大模型能力上保持最先进的效果。

为了让问答能力真正实现“生产级”，我们认为在企业级知识问答场景中，需要以传统RAG技术为基础，在三个方向持续精进：模态多样化、知识跨度、推理复杂度。

3.1 模态多样化

在《2.1 知识解析》小节中，已经对“图像”模态的知识做了一部分预处理，主要是升级了传统的OCR技术，来支持更复杂图像的解析，将图像转为文字。

但对于其他更广泛的图像，比如产品示意图、地图标识、LOGO等，就无法简单地进行文本转写来百分百实现，因为我们不知道将图像转写成什么文字。此时，就需要在检索和生成阶段分别引入视觉模型，来把文档当做一张张图片来理解和计算，称为OCR-free（免OCR）方法。

在“检索”阶段引入视觉模型，主要是实现基于查询Query来找到对应的图像这一能力。技术的核心是训练一个能将“文本”和“图像”映射到同一语义空间的模型，比如，提问“空压机二级冷却器更换前后温度变化”，通过这句话来从海量图像中找到最相关的那个“仪表盘”图像。

而在“生成”阶段引入视觉模型，是为了实现基于上一步找到的有限个图像以及查询语句，生成最终的答案。这两个阶段需紧密配合，实现图像模态的知识问答能力。

在复杂多样的企业知识库中，除了图像模态，还有视频、音频模态等，多种模态的融合理解对于大模型来说，仍是不小的挑战。

3.2 知识跨度

以“长窗口”性能强大而著称的Kimi大模型创始人提出过一个形象的比喻，把大模型的窗口长度比作“内存”，把RAG所依赖的知识库比作“硬盘”，可见长窗口对于大模型的重要性。在此列举两个知识跨度大的场景，来说明长窗口的用途：

1.跨文档场景

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

2. 长篇单文档场景

单文档问答场景，表面上看文档数量缩小了，似乎难度更低了，但其实是完全不同Query需求空间。因为在单文档场景中，有一大部分需求是做“摘要”，而“摘要”又有不同的需求分类，我们参考了SuperCLUE-Long对“摘要”任务的划分：

• 全文摘要：例如，这篇文章讲了什么 / 对文章做个总结

• 局部摘要： 例如，对“国内外研究现状”部分做个总结 / 总结一下某某发言内容

• 线索摘要： 例如，总结一下某某机构的发展历程 / 总结某事件的发展过程

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

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

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模型方向），都需要长时间的探索和积累。

以上从“知识管理能力”、“工程能力”、“算法能力”三大能力方向，介绍了腾讯乐享对企业客户知识问答需求的认知和沉淀，也包含了乐享AI助手研发团队对未来技术方向的规划和思考。文章很长，腾讯乐享的探索之路也不止于此，希望让AI成为每个企业、每个用户的“外挂”生产力。

如何学习AI大模型？

大模型时代，火爆出圈的LLM大模型让程序员们开始重新评估自己的本领。 “？”“”等问题热议不断。

不如成为「」，毕竟AI时代，谁先尝试，谁就能占得先机！

想正式转到一些新兴的 AI 行业，不仅需要系统的学习AI大模型。同时也要跟已有的技能结合，辅助编程提效，或上手实操应用，增加自己的职场竞争力。

但是LLM相关的内容很多，现在网上的老课程老教材关于LLM又太少。所以现在小白入门就只能靠自学，学习成本和门槛很高

那么针对所有自学遇到困难的同学们，我帮大家系统梳理大模型学习脉络，将这份 分享出来：包括等, 😝有需要的小伙伴，可以 扫描下方二维码领取🆓↓↓↓

👉[CSDN大礼包🎁：全网最全《LLM大模型入门+进阶学习资源包》免费分享（安全链接，放心点击）]()👈

学习路线

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

👉学会后的收获：👈

• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓