从 RAG 到 Knowledge Layer：腾讯乐享企业知识库的实践

写在前面

过去两年，企业在落地大模型与 Agent 时，RAG、Text-to-SQL、MCP 等底座架构已经高度成熟。但当这套经典组合步入真实、复杂的业务深水区时，却频频在供给侧遇冷。作为深耕企业知识库多年的平台，腾讯乐享在自研的乐享AI知识库中，也经历了同样的瓶颈与思考。

本文是一篇来自腾讯乐享的技术复盘：大模型并非推理能力不足——当供给侧只有粗糙的文档生料，AI 的每一次推理都退化为概率层面的猜测。企业知识的真正壁垒，在于原始数据与语义语境之间那道被长期忽视的鸿沟。

解决这一问题的技术共识，正在指向一个新的架构层——Knowledge Layer（知识层）。本文将从真实业务场景中 RAG 的隐性瓶颈切入，拆解企业 AI 知识层的重构链路，并如实呈现腾讯乐享的企业知识库产品（乐享AI知识库）在这一技术路线上的探索与落地实践。

乐享的知识图谱功能

01 BOTTLENECK 一个注定答不好的查询

考虑一个典型的技术运维或业务分析查询：「为什么昨日支付服务的可用率出现了异常波动？」

这是一个在真实企业场景中极其普遍的跨域查询。理论上，支持该问题解答的所有原始物料都是完备的：关系型数据库里记录着实时的错误率、请求量与响应延迟；文档库中存放着支付系统的架构方案、微服务拓扑和运维白皮书。然而，单纯依赖现有的向量检索与模型组装，大模型很难稳定给出高质、可信的回答。

大模型无法在混杂的上下文中识别「可用率」在当前业务部门的官方统一定义（不同业务线可能存在三套统计口径）；模型不知道「昨日」该统计域内是否存在微服务发布、变更或例行维护事件；模型更无法判断，面对多套并存的监控指标，哪一个才是经过企业核心团队审计并认可的权威数据源。

「这些隐藏在系统规范、口头约定、实时上下文中的高维知识，被称为 Enterprise Context（企业上下文）——它游离于静态的关系型数据库和松散的非结构化文档之外。」

问题的本质并非大模型的认知能力不足，而是其输入端缺乏结构化的「企业语义供给」。当供给侧只有粗糙的文档或数据库「生料」（Raw Data），大模型在推理时便只能退化为概率层面的猜测。要从根本上破解这一瓶颈，就必须重构大模型的知识输入链路——构建面向 AI 的 Knowledge Layer（知识层）。这也是腾讯乐享的乐享AI知识库在选择技术路线时的核心出发点。

构建这一技术层并非追求单一的功能堆砌，而是一套有先后依赖、有技术取舍的工程链路。

02 AGGREGATION 知识供给的起点是持续聚合，而非孤立建图

行业中一种常见的技术偏见是：构建知识层等同于直接开展大规模的知识图谱建设。

在工程实践中，这种自上而下的重度建模往往导致项目陷入泥潭。腾讯乐享认为，知识层的起点并非直接建模，而是一套面向多源异构数据的持续聚合系统（Continuous Aggregation Pipeline）。

真实的企业语境下，知识具有高动态性、分布散落和多源异构的物理特征。它不仅散落在企业 Wiki、Office 文档、各业务系统数据库中，更沉淀在历史复盘、技术沉淀和日常协同的无形链路里。这也决定了企业知识库的建设无法通过一次性的「快照导入」或静态建库来完成。

任何静态的企业知识库，在其建设完成的瞬间，便已经开始了信息折旧和「元数据腐烂」。唯有建立起一套长效、自动化的持续聚合管道，将数据变更与事件通知链无缝打通，供给大模型的语义语境才能保持实时、有效。

然而，持续聚合只是解决了管线（Pipeline）畅通的问题，汇入的原始知识必须经历深度清洗。在乐享AI知识库的工程实践中，聚合链路紧跟着一道标准化清洗工序，用以实现敏感数据脱敏、冗余条目去重、时效性冲突消解以及非结构化格式的归一化。地基不洗干净，后续的语义增强与建模便会退化为 Garbage in, Garbage out。

03 ENRICHMENT 语义增强：用 AI 持续加工、养厚企业知识

干净的数据并不等同于大模型可以直接消费的高效语境。知识层的第二道核心工序，是语义增强（Semantic Enrichment）。

这是一个利用大模型自身能力，对已聚合知识进行深度再加工、提高「信息密度」的过程。

比如一个技术指标、一个业务领域术语（Term），对于人类来说，其定义可以通过经验和上下文轻易脑补。但对 AI 而言，它需要精准地得知该实体的边界、所属的业务域、关联的开发团队、高频出现的业务场景，以及它与哪些现有的文档和 API 产生咬合。

传统的数据治理中，这些元数据（Metadata）完全依赖人工维护，成本极高且版本迭代难以标准化管控。在腾讯乐享的工程链路中，这一加工环节被完全交由大模型自动、持续地进行：通过对新注入内容的智能打标、分类聚合、实体关系提取与摘要生成，大模型得以不断提取出更稠密的结构化信息。这就是乐享AI知识库所强调的「以 AI 治理知识」的自我增强闭环。

通过这种闭环，新注入的扁平文档开始自发长出语义关联。它不再是一堆存放在服务器深处的死档案，而是一套能够自我演进、不断「增厚」的业务语境图景，为后续大模型的推理提供极高的信息密度——这正是企业知识库从「存储」走向「智能供给」的关键一步。

04 MODELING 建模哲学：构建任务导向的 Context，而非静态图谱

在完成了聚合、清洗与语义增强后，知识层步入最关键的建模环节。在这里，我们提出一个核心的技术辨析：企业 AI 真正需要的建模，是以任务为中心的 Context，而非传统意义上庞大而静态的 Knowledge Graph。

传统的知识图谱建模倾向于描绘全局实体之间的大一统关系。这种自底向上的建模策略有着天然的「完美主义冲动」，致力于把图谱画得更全、更深、更密。但在真实的 LLM 推理场景下，一张无所不包的巨大静态关系网往往是不堪重用的：它不仅会带来严重的 Token 窗口膨胀、极高的推理延迟，还会给大模型引入海量的语义噪音。

「面向大模型的建模，更需要一种 Context 思维：针对当前的特定提问（Task-driven），动态、精准、高内聚地把支撑这次推理所需的上下文子图提取并呈现出来。」

仍以「分析支付服务可用率异常」为例，AI 这次推理所需要的，并不是全局拓扑大图，而是与「该可用率指标」直接绑定的一组动态上下文——其底层的微服务依赖、负责的研发团队、近期的代码变更事件、运维手册中对应部分的定位指南、以及该指标由企业认定的权威核算代码。这组精准组织出来的上下文，才是一次完美推理所需要的 Context Graph。

腾讯乐享在此处的建模布局由三个模块互为支撑，进度如实表述：

• 图谱（已上线）：负责跨文档、跨实体的拓扑关系构建，让关系型检索成为可能，并在供给侧暴露并消解多源数据的定义分歧。
• LLM Wiki（进行中）：旨在通过大模型，将散落、破碎的知识片段自动重组为百科式（Wiki-style）的高可读性结构化词条。
• 本体（Ontology，进行中）：定义企业知识的元骨架和术语对齐标准，防止多部门、多系统的建模链路滑向各自为政的泥潭。

必须强调，图谱在企业知识库架构中扮演的是一种增强角色，而非必然。在绝大多数中低复杂度的问答场景下，传统的 Vector RAG 配合合理的 Chunk 治理已经完全能够提供合格的语义供给；只有当业务场景步入深水区、出现高密度的跨文档血缘和关系冲突时，图谱辅助的 Context 供给才会真正展现出不可替代的技术红利。

05 RETRIEVAL 检索范式重构：提供组织好的上下文，而非文档生料

知识层的引入，必然带来检索环节在物理链路上的深层次重构。

在经典的向量 RAG 架构中，检索链路呈现一种「生料供给」状态：用户提问 → 向量数据库执行 Top-K 检索 → 召回若干原始文档 Chunk → 直接塞入 Prompt 并交付模型。在这种模式下，大模型不仅要完成复杂的推理与分析，还要承担在未经清洗、充满冗余、甚至存在版本冲突的「生料」中筛选信息、甄别噪声和校对口径等额外工作。这导致推理链极易断裂或发生幻觉。

这种重构，本质上将「知识的组织与净化」前置在知识层内完成，最大程度释放了大模型在逻辑推理与跨域分析上的核心算力，使其能够心无旁骛地专注于回答的生成与逻辑自洽。这也是乐享AI知识库在检索链路上与传统企业知识库问答最大的差异所在。

范式对比：

06 CONFLICT 面对定义分歧：以技术暴露冲突，而非替组织拍板

在企业知识的真实治理中，一个极高频的工程挑战是：同一个问题、同一个概念，在企业内部往往并存着多个互相矛盾的口径版本。

「这个流程该找谁审批？」「这个可用率指标究竟由哪些部分相除得到？」不同部门、不同时期的文档给出了完全打架的算法。如果一味强求「让大模型去判定哪个是唯一权威」，或者试图建立一套极其沉重、高度依赖人工维护的「公司权威答案库」，项目往往会在落地过程中夭折——因为在现实中，很难有一套高灵敏度的跨域人工审计机制能持续运作。

顺着「可信供给」的技术路线，腾讯乐享选择了一种更为务实的图谱落地策略：去发现、去关联、去暴露冲突，而非替人类完成拍板决策。

借助图谱构建的关系血缘，当多源数据中出现对同一实体的对立定义时，企业知识库的知识层能够自动检索出这些版本差异，并并排呈现出来，标明它们各自的创建时间、维护团队、修改版本与前置约束。决策和纠偏是人和组织治理的权责，产品在技术层面上所能给予的最佳支撑，是让这些暗流涌动的信息冲突彻底显性化，让人和模型都能在完全透明的血缘关系中，迅速定位最合理的知识源。

结语：腾讯乐享知识供给重构的当前进度与技术边界

概括而言，Knowledge Layer（知识层）并非某个单一的功能模块，而是企业大模型和 Agent 的工程地基。它的技术实质，是在大模型每一次发起推理之前，将混杂的多源企业原始知识，转化为高纯度、高一致性、带强语义特征的企业上下文（Enterprise Context）并精准供给。

这一技术链路的长效建设并非一蹴而就。腾讯乐享在这一路径上始终保持着严谨而踏实的工程节奏：目前图谱能力已正式上线，结构化的 LLM Wiki 与本体对齐能力仍在按计划稳步补齐。作为腾讯旗下深耕多年的企业知识库平台，腾讯乐享正将乐享AI知识库逐步升级为面向大模型时代的「知识供给底座」。

「如果贵团队在大模型落地中已经跑通了基础链路，却频繁在真实业务供给侧遇冷，那么或许缺的并不是一个参数量更大的模型，而是一层被认真治理、深度组织的知识层供给。」

我们在这个领域积攒了丰富的工程实践经验与踩坑教训，也非常期待倾听贵团队在特定业务语境下的场景挑战。欢迎与腾讯乐享共同探讨企业大模型时代下，企业知识库与知识重构的未来图景。