今天重点聊聊在云盘文档场景里，如何把知识图谱用起来，让知识问答和管理这件事变得更靠谱一些。
分享的核心内容，大致可以分成这几个部分：第一，360文档云的知识管理和问答到底是怎么玩的；第二，知识图谱怎么融入到RAG问答流程里去；第三，知识图谱如何帮文档变得更标准化、层次化、结构化；最后，聊聊现实中的挑战和下一步的展望。
360 文档云知识管理/问答应用场景
先来看，这个场景的切入点到底是什么。
业务痛点
先说第一个麻烦：非结构化数据涨得太快了。
说实话，非结构化数据的管理确实让人头疼。IDC预测到2025年，全球数据量会到175ZB，其中80%-90%都是非结构的。这些数据怎么存、怎么访问、怎么控制、怎么共享协同，每一环都是难题。更麻烦的是，这些数据的利用率低得惊人。格式太杂了，文本、图像啥都有，处理成本高，分析难度大。有数据显示，55%-80%的企业业务数据基本都在“睡觉”，价值完全没被挖出来。
另一个老大难问题，是大模型在落地时暴露出的短板。
大模型虽然像个万事通，但说到底，它不懂企业。行业知识和专业知识，它只能泛泛而谈。你要把企业内部的知识和业务跟它打通？这事没那么简单。更不用说数据安全了——内部的Know How那可是核心竞争力，哪能随便喂给大模型，那不是明摆着泄露家底吗。还有上下文的问题，光靠用户的一个问题，很难把业务行为的上下文全盘托出，推理周期长、准确率也不高。
那360文档云在哪些方面有优势？
首先，它能存管海量的高质量企业数据资产。企业文档里藏着大量高质量的私域语料，Office文件、PDF这些都能统一处理成结构化数据，而且只要文档持续产生，数据就是活水。其次，它基于组织和权限来保护数据安全。9级权限校验、全生命周期安全防护、云端扫描加本地态势感知，外发也有管控。最后，它还能记录用户行为，形成上下文关联。比如用户最近用过什么文档、收藏了什么、常打什么标签，这些操作行为都能串起来。
360 智能文档方案
从企业网盘到智能文档，这个转变挺有意思。
以前大家用网盘或文档云，主要就是上传存管，企业内部再搭个私有的。企业网盘帮大家从基础工具升级到数字资产管理平台，比如上传文档到文档归类，一站式文件全生命周期管理，还有知识协作服务，打造文档云、知识库、大数据平台，最终构建起非结构化数据的中台，协同效率也就提上来了。
现在大模型来了，玩法变了。文档云和GPT一结合，文件助手和智能知识库就出来了。文件助手能帮大家做知识洞察、发现和创作，把内容价值打开。最终目标是把云盘升级成企业和个人的知识大脑，让产业知识智能化的步子快起来。
360智能文档方案的核心，是三个层次的能力：读得懂、搜得到、答得准。读得懂，就是对文档内容做深度解读和总结；搜得到，是在海量知识文档里快速定位答案；答得准，是给出精准匹配的搜索结果。这三个层次，一个比一个难。
360 智能文档应用
具体怎么用？几个方向值得说。
第一个，是一站式知识问答、AI助手和智能推荐。用户可以创建知识号，把文档上传后直接提问。默认的助手应用还可以做推荐，接入大模型和Agent平台。在云盘文档里，图片转文字、PDF转DOC这些细活儿，也都安排上了。而且，整个界面的任何地方，随时都能唤起AI助手，还能做通用问答，接上360搜索和外部搜索能力，再融合用户场景和上下文感知。
第二个，是文档总结、翻译和推荐。在科研领域，快速总结论文、了解外文文献核心内容，筛选效率一下子就上来了。自媒体那边，很多公众号已经开始用大模型自动生成问题，做成FAQ挂上去。文档翻译可以配合总结之后做精读。而文档推荐，当用户预览某篇文档时，系统会自动推荐相关文档，背后甚至可以用知识图谱的关联网络来推荐。
第三个，是智能撰写、样式、人工监督和进度跟踪。写文档时，设定好需求，大模型就能帮忙编写大纲，然后细化、撰写段落。智能样式那块，文档理解引擎可以把标题识别出来，再做样式转换。如果觉得机器写得不够好，人工还能随时介入，调整大纲和参数。进度跟踪也能让整个生成流程一目了然。
第四个，是文档搜索。划词搜索，先用大模型对选中的内容分段、提取，再调用搜索。搜索模式也升级了，大模型可以把一个搜索内容扩展成多个相关问题，然后并行搜索，最后把多个搜索结果做相关性排序，返回给用户。
KG 在文档 RAG 问答中的应用
绕不开的一个话题是，知识图谱到底怎么用到RAG里去。
回顾知识图谱
先说一个基本判断。知识图谱为什么会出现？说到底，背后是一系列数据层面的核心难题没有解决。比如，非结构化数据计算机理解不了；多源异构的数据很难融合到一起；数据模式一变，调整就费劲；数据用起来专业门槛太高；还有大量的重复数据在里面。这时候，需要一个中间层——知识图谱，来做统一化管理。它有两层意思：一层是网络里那些节点代表的各种知识，另一层是结构化数据。经过统一管理、转换处理之后，就得到标准化的知识库，语义理解、数据关联探索、业务动态扩展、智能检索与问答，这些能力就都有了。
360之前也做了一个知识图谱平台。它的思路是，结构化数据通过标准化构建来定，非结构化数据通过抽取式构建来定。然后分析文本、做知识抽取，再做统一图谱管理，包括知识映射、知识标准化、知识融合。最后是图分析工具、图谱存储和知识应用。坦率地说，这个平台在市场上推广得不算太顺，因为技术门槛确实高。
现实及方向：知识图谱与大语言模型
大模型来了之后，局面发生了微妙的变化。有一篇很火的综述文章《Knowledge Graphs》，把大模型和知识图谱的优劣势梳理得很清楚。大模型知识边界不敏感，优势在于高度参数化、容易起量，但不够精细。知识图谱很精细、结构化，但容易不完整。现在很多模型都在尝试融合：ERNIE 3.0做了知识图谱增强，Doctor AI也在做知识图谱的融合。两者的结合，有两种主流范式：一种是知识图谱增强大模型（KG-enhanced LLMs），另一种是大模型增强知识图谱（LLM-augmented KGs）。
结合方案
先说RAG知识增强的文档问答。RAG现在可以说是搜索问答里最强的方式了。流程大致是：先把文档按策略分块（Chunks），然后用好一些的Embedding策略（比如M3E、Text2Vec、E5等），再做文档召回。召回之后，制定上下文生成策略，包括检索多少块、如何处理重叠块等。接下来选模型，360智脑、ChatGLM、Llama2、ChatGPT都行。然后尝试所有可能的组合——分块策略、嵌入策略、上下文生成策略、LLM选择，最后生成响应，再做结果评估，挑出分数最高的那套配置。
但文档问答里的实际问题，远没有这么简单。比如，大模型做私有化文档问答时，长尾问题一多，幻觉就冒出来了。私有文档的内容结构又很复杂，层级多、元素杂，大模型区分起来力不从心。RAG的流程也很长，受文档标准化、Chunk切分、Lost in Middle这些因素干扰，Chunk之间的语义也容易断掉。
所以，用知识图谱来增强大模型问答，成了一个很自然的思路。具体来说，可以在四个阶段注入图谱的能力：
知识整理阶段：用知识图谱把文档内容做语义化组织。
意图识别阶段：用知识图谱进行实体的别称补全和上下位推理，相当于做了受控改写。
Prompt组装阶段：从知识图谱里查询背景知识，放进去作为上下文，实现精准召回。
结果封装阶段：用知识图谱做知识修正和知识溯源。
KG 在文档标准化、层次化、结构化应用
文档本身的标准化，也是个实打实的硬骨头。
支撑方案
第一个支撑方案是复杂文档版面分析。需要在图文混排、多段落划分这些复杂版式里，把结构识别出来、存起来，这样用户提问时才能给出更准的答复。而且后续做跨模态搜索时，还得把代表同一个事物的图片和文本链接起来。这时候就要做内容对齐：页面文本内容、目录文本内容、图片内容抽取、表格内容抽取、文档页码抽取，一样都不能少。
版面分析之后，要解决的是问答增强。很多文档有高品质的问答需求，需要基于文档生成问题，或者基于问答记录生成问题，再基于问题泛化成相似问题。构造错误样例也是增强的关键一步，用图谱的方式来实现，效果更可控。
还有一个支撑方案是知识管理。这里需要判断一件事：走微调路线，还是走RAG路线。这俩的选择，取决于具体场景和数据量。
KG 增强方案
先说基于知识图谱生成文档微调问答对。我们可以基于结构化数据生成QA对，用人工定义模板来快速生成。也可以基于百科的InfoX数据和正文，生成RAG微调数据。还可以让模型针对Q进行改写，这样能缓解领域微调数据荒的问题。有意思的是，构成微调问答对的数据量其实不需要太多，几百条数据就能取得不错的效果。
第二个方案，是基于知识图谱存储文档的复杂层级信息。读文档时，文字、图片、表格这些信息混杂在一起，知识图谱可以让智能文档处理更靠谱。智能文档处理，就是用计算机自动识别、分析、处理文档中的各种信息，实现自动化。文档里有图表、标题、目录、表格、段落等层级信息，利用知识图谱的结构来存储这些布局信息，就能把逻辑层级结构、文本内容、表格内容、Key-Value键值字段、样式信息都提取出来，最终以结构化数据的形式输出。
第三个方案，是基于知识图谱的实体链接和召回。相关的技术，可以参考一份研究论文，思路其实很直接：对用户输入的Query做实体提取，然后构造一个子图作为上下文，最后送入大模型完成生成。具体步骤是：先用LLM或BERT模型从问题里提取关键实体（实体识别、链接），然后根据实体检索子图，如果子图太多，就做排序、剪枝，最后利用获得的上下文让LLM输出答案。比如在医疗场景，先做医疗实体识别，然后生成图数据库，再去搜索疾病图谱。大模型对图谱本身不太敏感，所以可以把疾病图谱转换成自然语言，再算相似度，处理好了再放进LLM，效果就好起来了。
进一步延伸：融合 KG 的泛 AI 搜索几种方案思考
最后这点，说说把知识图谱融合到泛AI搜索里的几种思路。
一种是以结构化知识为中心的Magi知识搜索，它完全是围绕知识来构建的。另一种是以摘要为核心的Perplexity等大模型搜索。流程是这样的：输入用户Query后，先做意图理解，包括去停用词、实体识别、关键词提取、归一化，然后做Query扩展，一个问题扩展成多个子问题，扩大召回面。接着用并发检索的方式，粗排、精排，召回符合阈值的相关网页文档。最后，把这些网页文档追加到Prompt里，让大模型总结回答，同时给出答案来源和对应链接。
还有第三种形式，是把图谱的影子纳入到AI搜索里。Query泛化时容易失控，可以通过预先建好的知识图谱来管控。在结果整理阶段，也可以加入一些图谱的例子。本质上，这是一种Schema驱动的AI搜索思路。
KG 与 LLM 在文档场景下的挑战及展望
理想很丰满，现实中的挑战也不少。
第一，知识图谱在问题改写和问题泛化的受控上确实有直接收益。但如果问题涉及多个实体，怎么做实体链接？通常得一个个Case去处理。如果实体的关系或属性太多，又得做好排序，防止检索时炸掉。
第二，结构化的知识图谱在微调数据上有帮助，尤其是拒答场景。但问题是，怎么更快、更好地自动化构建出这么一张图谱？实时性和准确性怎么保证？
第三，知识图谱的本体Schema在组织搜索内容时收益明显，能把搜索内容重新梳理一遍。但Schema的自动化构建，一直是个老大难，怎么规模化地生成它，也是问题。
第四，知识图谱可以作为一个单独的知识召回源，参与到文档问答里。但新的问题又来了：怎么正确检测大模型本身的知识和结构化知识图谱有没有冲突？两个召回源给出的结果，怎么取舍？怎么排序？
这些问题，目前还没有标准答案，但方向很明确——融合，而不是替代。
问答环节
Q：PPL 对 query 做搜索扩展的摘要，扩展后的摘要如何评估？
A：做Query扩展时，先要算相关性，这一步只能用量化指标来做。扩展后的摘要怎么评估？本质上还是通过相关性来评。扩展之后，让大模型生成结果，然后看整体用户体验好不好。最后，由人工来做评价和比对，给出一个综合判断。