金山办公在知识库业务中的大模型思考和实践

好的，没问题。作为深耕AI领域多年的从业者，我来将这篇技术分享润色成更具个人风格和专业洞察的文章。 我们将彻底去掉原文中的“AI味”和无关推广信息，保留所有核心观点、技术细节和章节结构，使其读起来就像一位经验丰富的技术负责人在行业会议上的深度分享。 ---

对企业来说，把分散的知识管起来，这事儿有多重要？一句话总结：内部经验能传承了，重复造的轮子少了，知识本身的活力也就被激活了。而把大模型AI技术装进这个管理框架里，就像是给这套体系装上了“智慧大脑”，它不再只是个存储仓库，而是能实时整合、精准分析、甚至主动输出见解的智能系统。

这篇文章，整理自金山办公AI知识库技术总监陈亮在QCon 2024北京的一场深度分享。我们会聊聊金山办公在AI知识库实战中的一些思考，包括AI到底能在知识库里解决哪些实际问题、背后的技术架构怎么搭、RAG技术怎么落地才不“翻车”，以及我们在调教大模型时踩过的坑和找到的解法。文章完全基于现场实录重新组织。

金山的AI发展路径

先说说我们这边的情况。说实话，目前大模型还没真正催生出那种“人人都离不开”的现象级应用产品，金山办公也不例外。去年，我们下了决心全面押注AI，过去一年砸了不少资源，跟客户一起共创、一起落地了一些产品。

在4月份的发布会上，我们正式发布了整个AI 365平台，其中就包括WPS AI。这套方案是企业级的，目标很直接：用AI把生产力提上去，让工作流跑得更顺。从去年下半年开始，我们跟很多企业做了深入合作，把收集到的客户痛点，一步一步转化成标准化的产品方案。在这个过程里，我们确定了三条主要的技术演进路线。

第一个是

，你可以把它理解成是一个智能基座。核心要解决的是“大模型怎么被用好”的问题。企业对大模型的使用不能是无序的。第二个是，也就是智能文档库。我们希望用AI赋能文档处理，让WPS里沉淀的各类文档真正“活”起来，发挥出业务价值。最后一个是，它本质上是一个Agent产品。它能帮用户调用各种工具去完成特定任务，说白了就是让机器干那些重复性的活儿。

AI Hub 智能基座

AI Hub作为基座，首要任务是让大模型能被安全、可控地调用。打个比方，企业里可能有几百上千个员工都在用AI，谁该用哪个模型、用了多少token、信息安全怎么保障？AI Hub提供了一个平台，让企业能统一管理这些大模型的接入服务，无论是公网、私网还是混合部署，都能搞定。接入之后，还能看到可视化的使用报表，比如每天token消耗了多少，哪些提示词用得最多，管理层一目了然。目前我们已经接入了国内主流的几家大模型厂商，并且支持计费统计，这个对企业来说非常实用。

AI Docs 智能文档库

AI Docs是我们的智能文档库，可以说是站在WPS多年的文档处理“家底”上做出来的。金山办公在文档解析上有深厚的积累，无论是文本、表格还是复杂图表，我们都能准确识别和解析。今年整个行业特别强调AI知识库，我们的想法是，让企业各个环节上的文档，通过大模型的加持，真正释放它的价值。过去那些沉睡在硬盘里的文档，现在可以通过结构化的解析，成为AI输入的“养料”。

另外，智能文档库还包含“智能创作”功能。这个功能解决的是“内容生产”问题，尤其在金融、公文、论文这些对格式和风格要求严格的领域，落地的价值非常大。基于明确的来源，我们可以让大模型生成符合特定要求的内容。比如，我要写一篇QCon大会的演讲稿，那我往知识库里丢几份以前的QCon资料，然后通过一些机制，让大模型输出一份符合大会气质的稿子。这个功能的关键实现技术，我们在后面会详细讲。

Copilot

最后是Copilot。它基于API、Agent和大模型的架构，能帮企业调用各种工具，完成特定任务。Copilot的目标很明确：取代那些日常的、重复性的简单劳动，降低人力成本。举个内部的例子，如果我想创建明天10点的会议，传统流程我得打开日历、找会议室、创建日程、再一个个通知参会者。但在Copilot上，我只说一句“明天10点帮我创建个会议并发给相关人员”，它就能解析指令，调用365内部的API和组织的通讯录API，直接搞定一切。

这里我想提出一个概念，那就是未来企业级AI的形态：

。这个知识大脑要像人一样，能记忆、能思考、能行动，甚至能自我反馈和调节。大模型现在已经能够调用企业的私有数据、API以及金山办公的文档处理、365套件能力。再通过AI Hub调用大模型，企业就相当于拥有了强大的思考能力、洞察一切的感知能力、超大容量的记忆能力和自我规划的执行能力。所以，如果用一句话定义WPS AI，那就是：帮助企业构建自身的企业大脑，让生产经营活动得到AI的加持，实现降本增效。

不同场景下的技术实践

技术这块，我想从三个具体场景出发，谈谈我们的经验和思考。

首先是

。这是很多AI应用的标配，本质上是基于RAG的检索增强架构。但我今天更想强调的是“解析、切片和数据安全”这三个前处理环节。很多客户跑来跟我们合作，说他们业务数据很丰富，AI提效的需求也很强烈，但卡在RAG的第一步——数据预处理上。他们自己试过解析、切片，效果都不理想。所以我们在这方面做了很多工作。

第二个场景是

。创作背后的原理，其实涉及到召回和SFT（监督微调）。我们会用SFT对模型进行微调，确保它生成的内容更符合要求，风格更多样。最后一个是。简历场景在企业里非常普遍，但传统大模型在处理统计类或检索类问题时，比如“统计一下有多少985硕士”这种问题，表现很不稳定。所以我们采用了结构化提取的方式，来解决这个痛点。

智能问答

智能问答是AI知识库的核心应用。它的功能是，在海量知识库里，检索出跟用户问题最相关的内容，然后呈现给用户。甚至还有一个“词条”功能，用户在后台配置后，比如输入某个财务同事的名字，系统就能直接跳转到对应的聊天框。我们的系统还能检索出相关的图片，并引用文档来源。

这个场景有几个关键点。首先是

，这是RAG架构的“第一关”。文档进来后，需要提取出其中的内容。其次是，这跟传统搜索和推荐技术直接相关。第三是。在企业场景下，问答中的权限管控是个不小的挑战。具体来说，用户输入问题后，系统会对query进行改写，然后在召回时进行权限过滤。

在文档入库阶段，处理流程如下：

• 解析：
  支持海量异构数据源的精准识别。企业内部文档格式五花八门，我们有一整套机制，能把它们解析成统一的规范格式，比如Markdown、json等。这是基础能力。

• 切片：
  根据不同文档的布局，采取不同的切片策略。我们内部划分了七大分类，包括合同、公文、财报、论文等，每种文档的结构都不同。我们会根据文档结构（页码、章节、段落、block语义）来切片，而不是一刀切。这样做的好处是能显著提高召回率。

• 召回：
  采用多路召回策略。相比于单一召回方式，多路召回能获得更高的召回率，这意味着送给大模型的上下文更相关，最终答案的质量也更高。

• 权限：
  召回文档后，根据文档的ACL（访问控制列表）进行校验。简单说，就是员工只能看到他有权限看的文档内容，生成的答案里不会包含他不能看的信息。这是B端客户最在意的安全痛点。

智能创作

智能创作与智能问答在入口上很相似。用户输入一个主题，或者匹配到推荐的主题，系统就能帮生成符合特定风格和字数要求的文本。生成的内容可以直接填入云文档模板，支持公文、合同、财报等多种类型，并且会附上参考文档来源。这个场景有两个核心要求：

，不能胡编乱造；，适应不同角色和行业的需求。

具体实现路径是这样的：

• 主题匹配：
  用户输入主题后，系统会召回相关的文档片段，自动生成一个大纲。

• 大纲生成：
  大纲和主题之间有相似度关系。系统会根据这个大纲，进一步匹配库中的文件，最终生成文档。

• Prompt 调优：
  整个过程不是一次性的。系统会通过几轮确认（召回-生成-再召回-再生成），让用户逐步调整，直到得到满意的内容。

• SFT 微调：
  为了稳定地输出不同风格的内容（比如财报严谨、公文正式、合同精准），我们使用了开源的Lora模型，基于特定数据集进行微调。

目前，智能创作在财报和公文领域的效果已经比较理想了，但还没正式推向大众。因为在实际应用中，很多专业术语和行业“黑话”需要专门处理。比如金融领域的市盈率、P/E，医药行业特有的专业表述，如果不经过专门的训练，大模型很容易出错。特别是医药行业，对内容准确率的要求可以说是“零容忍”。药品说明书的一个字都不能错，因为它直接关系到用药安全。所以，在这些领域落地前，必须经过严格的多轮验证。

智能简历库

智能简历库是我们的一个特色场景。简历的格式相对固定，包含头像、姓名、联系方式、工作经历等结构化信息。但传统的大模型在处理统计类问题时（比如“有多少个硕士”），表现不稳定。所以我们换了一种思路：

。

我们结合大模型、NLP和NER（命名实体识别）等算法，把简历中的信息提取出来，以结构化的形式存入数据库。当用户提问时，比如“找一个具有AI经验的产品经理”，系统会把问题转化为SQL语句，或者通过向量搜索找到相关简历片段。在结构化抽取阶段，我们使用了Lora微调，目的是让大模型更准确地识别简历中的关键词。我们还生成了简历的总结，这有助于后续进行JD（职位描述）匹配。

JD匹配和字段匹配是两种不同的方式。我们通过语义检索，结合ES（Elasticsearch）技术，可以处理“需要多少年工作经验”这类自然语言描述。这样一来，用户可以精确地查询“有多少硕士以上学历的同学”，系统不仅能准确回答总数，还能列出具体人员。这在传统的大模型语义问答中是很难做到的。当然，我们也面临“问题转化为SQL语句”这个技术稳定性的问题，后续计划通过Lora微调来进一步优化。

经验分享

在大模型应用的过程中，我感觉这事儿特别有意思。大模型就像一个知识渊博但有点“老糊涂”的智者，几乎能回答所有问题，但准确性需要我们自己来兜底。为了确保它不出大篓子，我认为应该从四个维度来约束和规范：

。

1. 设计：
   必须有工程化思维。无论是问答还是创作，都必须有一个严格的pipeline流程。因为在大模型世界里，任何输入的小错误，都会被放大，随着流程的推进，误差会像滚雪球一样越滚越大。

2. 数据：
   经验表明，在数据量不够大的时候，数据的质量远比数量重要。高质量的输入是更好的选择，因为低质量数据会让大模型输出变得更加不可控。

3. 优化：
   我们内部有一套质量评测平台，用来评估问答或大模型输出的质量。核心方法是：给定query和context，让模型输出答案，然后结合人工审核和标注，双管齐下，来评估回答的好坏。

4. 踩坑：
   使用大模型时，最头疼的问题就是输出不稳定。因为它是生成式的，每次预测的结果都可能不同。为了应对这个，我们采取了Lora微调、结果缓存、或者用prompt进行约束等方式，来保证输出的稳定性。

展望未来

在大模型领域，我们经历了第一波以GPT为代表的技术涌现，大家充满了好奇和惊叹。紧接着，第二波应用层的创新开始到来。虽然目前国内上百个大模型里，还没出现真正的“杀手级应用”，但各行各业都已经开始积极尝试，比如金融、医药等。

我的判断是，第二波创新应该

，进行深度创新。大模型的发展正在从“玩一玩”转向“实用主义”，这是一个必然趋势。第二个观点是。我们面向B端，企业客户要的是能加速业务、带来价值的实际效果。所以，深入业务、提供实际价值，才是未来的关键。第三，我觉得。混合模式是未来的重要方向。大模型能做很多事，但某些方面可能还不够完美，需要进一步调教。这包括预训练、全参数或部分参数调整等方法。在我们业务里，大小模型的结合，是一个值得持续深挖的方向。