过去几年，企业在 AI 基础设施上的投入主要聚焦于两条路径：一是让大模型能够访问企业知识库，二是使 AI 应用基于企业数据生成更精准的回答。由此，RAG、向量数据库、知识库问答、企业 Copilot 等方案迅速普及。

然而，随着业务场景不断深入，一个更为棘手的问题浮出水面： AI 能回答问题，并不代表 AI 能发现问题；AI 能检索相似文档，也不代表 AI 能识别隐含关系。

许多极具价值的业务洞察，并非直白地写在某份文档或某个字段里，而是隐匿于客户、合同、供应商、产品、工单、代码、设备、账户、交易、组织、知识和流程之间错综复杂的关联网络之中。

传统搜索只能命中用户明确输入的关键词，常规 RAG 主要依赖文本语义相似度，BI 仪表盘则受制于预设指标与查询逻辑。它们都擅长回答“用户已知如何提问”的问题，却难以触及“用户尚不知该问什么”的未知领域。

Arango Contextus，正是一种面向“上下文发现”的 AI 能力。它并非普通的聊天机器人，也不仅是 RAG 检索工具，而是深度融合图结构、图神经网络（GNN）与大语言模型（LLM）的发现型 AI。其目标，是将 AI 的能力从“回答已知问题”推向“发现未知线索”。

一、企业 AI 的关键缺口：不缺数据，缺的是关系视角

企业环境中，数据往往并不匮乏。

CRM 中沉淀着客户与商机，ERP 中记录着订单与库存，ITSM 系统中留存着工单与变更，代码仓库里蕴藏着模块与依赖，合同系统存储着条款与履约信息，安全系统则汇集了资产、漏洞、告警与攻击路径。

问题在于，这些数据分散于不同系统，形态各异。即便企业将其一股脑接入 AI，也常常只是简单切片、向量化，再交给大模型做问答。

这种方式能解决部分知识检索问题，比如：

• “某产品的配置步骤是什么？”
• “某合同条款如何解释？”
• “某客户最近有哪些沟通记录？”

但当问题升级为：

• “哪些客户存在类似的流失风险？”
• “哪些供应商可能引发连锁交付危机？”
• “哪些代码模块在不同项目中具有架构相似性？”
• “哪些漏洞与资产组合可能形成攻击路径？”

此时，单纯的文本相似度便力不从心。

根源在于：这些问题的答案不只取决于文本内容本身，更依赖于实体之间的连接方式。企业 AI 真正需要的，不只是一个“知识库”，而是一个能理解业务结构关系的上下文数据层。

图 1：企业 AI 从文档检索走向上下文发现

二、Contextus 的核心价值：发现用户未曾搜索的东西

传统搜索的逻辑是：用户输入关键词，系统返回匹配结果。RAG 的逻辑是：用户提出问题，系统检索语义相近的内容，再交由 LLM 生成回答。

而 Contextus 致力于解决另一类问题： 当用户不知道应该搜什么，也不清楚哪些实体之间可能存在潜在关联时，AI 能否主动发现值得关注的关系？

这正是 Contextus 的独特之处。

它并不只看单个节点的文本描述，而是分析该节点在图中的位置、周遭连接、间接路径和结构模式。借助图神经网络，系统能识别那些虽无直接边相连、却在结构上高度相似或具有潜在关联的实体。

这种能力在业务中极具现实意义：

• 金融风控：某个金融产品或许并未直接暴露于高风险资产，却可能通过交易对手、资产组合、行业敞口及相关市场形成间接风险传导。
• 供应链管理：两家供应商可能无直接业务往来，却依赖同一上游原材料、同一港口、同一物流渠道或同一区域产能。
• 网络安全：两个资产可能分属不同业务系统，却共享相似的漏洞、权限路径、组件依赖或攻击入口。
• 销售与客户管理：两个客户行业、规模迥异，却可能在采购路径、技术栈、服务问题及决策链条上呈现相似模式。

这些发现绝非简单搜索所能企及，它们要求系统真正理解“关系”与“结构”。

三、技术拆解：Contextus 如何工作

Contextus 的处理流程可拆解为四个阶段：图数据摄取与嵌入、BFS 图遍历、链接预测，以及 LLM 解释。

第一步：图数据摄取与 GNN 训练

将企业图数据加载至 Arango 多模型数据平台，并基于图结构训练图神经网络（GNN）。GNN 不仅学习节点属性，更学习节点在整个图中的位置及其与邻居的连接模式。这与普通向量化截然不同——文档 embedding 表达的是文本语义，而 GNN embedding 捕捉的是结构语义。两个节点文本内容可能完全不同，但若其连接模式相似，便可能被识别为潜在关联。

第二步：图遍历（BFS）

从用户指定的查询节点出发，使用 AQL 执行广度优先搜索（BFS），提取 N 跳范围内的局部子图。这个子图囊括了查询节点周边的直接连接、间接连接和多跳路径，相当于系统不仅审视某个客户、资产或代码模块本身，还将其关联的联系人、合同、产品、服务记录、风险事件、依赖关系及历史行为一并纳入分析。

第三步：链接预测（Link Prediction）

系统计算查询节点与其他节点间的结构相似度，发掘那些虽无显式连接、但在图结构上可能存在潜在关系的实体。这一步是 Contextus 区别于传统图查询的关键——传统图查询回答“已知存在什么关系”，而链接预测试图回答“哪些关系可能尚未被显式建模或发现”。

第四步：LLM 解释

图算法与 GNN 能输出相似度分数和候选关系，但业务用户难以直接理解这些数值的含义。因此，Contextus 借助大语言模型，将发现结果转化为符合行业语境的自然语言解释，包括为何两个实体可能相关、经由哪些路径相关、以及这种关系在业务上意味着什么。

这使得 Contextus 不再是一个孤立的算法组件，而更像一位面向业务分析师、工程师和决策者的 AI 发现助手。

图 2：Contextus 的图智能发现流程

四、对企业的实际意义

从客户视角看，企业采购 AI 平台，不是为了追逐技术概念，而是为了提升业务判断效率、降低风险、减少重复劳动、挖掘增长机遇。Contextus 这类上下文发现 AI 的价值，集中体现在三个方面：

第一，发现跨系统的隐藏关联。

企业系统通常按部门与流程割裂建设——CRM 管销售，ERP 管订单，ITSM 管服务，安全平台管资产与告警，代码仓库管研发。系统间的边界往往成为洞察的藩篱。Contextus 将这些对象统一映射到图结构中，让 AI 能够跨越系统边界进行分析，而非囿于单一系统的数据表或文档集。

第二，帮助用户发现“未被提出的问题”。

许多风险与机遇在萌芽期并不会以明确的问题形式出现。客户不会直接问“哪个客户下个月可能流失”，供应链团队也未必想到“哪个二级供应商会影响核心产品交付”。若系统只能响应已提出的问题，其价值便大打折扣。上下文发现 AI 的意义，在于主动将潜在模式暴露出来，让业务人员提前介入。

第三，将技术发现转化为业务语言。

GNN、嵌入、链接预测对技术团队有意义，但对业务人员而言，真正重要的是“为什么这件事值得关注”。Contextus 借助 LLM，将结构相似性、连接路径与潜在关系翻译为自然语言，大幅降低了图分析结果的使用门槛，也更易融入企业实际工作流。

五、典型业务场景

客户 360 视图：Contextus 可帮助销售团队发现相似客户、潜在续费风险及隐藏的交叉销售机会。传统 CRM 主要记录客户、联系人、商机阶段与跟进历史，但客户真实状态往往还与合同、产品使用、支持工单、历史项目、技术架构和组织关系交织相关。通过图结构分析，AI 能识别出“表面不同但行为结构相似”的客户，辅助销售提前制定策略。例如，某客户当前商机金额不大，但其技术栈、采购链条、服务问题及历史互动模式，却与过往某个高价值客户高度相似——这种线索，单看 CRM 字段几乎无法察觉。

金融风险：Contextus 可用于识别资产、账户、交易对手及市场事件之间的间接风险传导路径。许多金融风险并非单点暴露，而是经由多个中间实体传播。图结构天然适合表达此类复杂关系，GNN 则能进一步发掘结构相似的风险模式，助力风险预警、关联账户分析、异常交易发现及潜在传导路径识别。

供应链管理：企业可将供应商、物料、工厂、物流路线、订单、地区及风险事件建模为图。Contextus 有助于识别供应链中的脆弱节点，例如多个关键产品是否依赖同一上游供应商，或某区域风险是否波及多条业务线。这对制造业、能源、汽车、电子及医药行业尤为重要，因其供应链通常具有多层级、多地域和强依赖特征。

网络安全：资产、漏洞、权限、账号、服务、网络连接、告警及攻击路径天然适合图建模。Contextus 可帮助安全团队发现分散但结构相似的攻击面，或识别潜在的横向移动路径。相比孤立地查看单个告警或漏洞，这种方式更贴近真实攻击者的视角——他们关注的不是单一弱点，而是漏洞、权限、资产与网络路径组合后的可利用链路。

研发与代码分析：Contextus 能发现不同代码仓库间结构相似的模块、组件依赖及架构模式。原文提到，在一个包含 27,583 个节点、40,955 条边和 24 种节点类型的 RISC-V 处理器图上，Contextus 成功识别出不同处理器仓库间结构相似的内存管理单元。这表明它并非在做文本检索，而是在挖掘跨代码库、跨架构的潜在结构关联。

六、Contextus 与 Arango 上下文数据平台

从产品定位来看，Contextus 进一步强化了 Arango 的上下文数据平台叙事。

Arango 并不单纯标榜自己是图数据库或向量检索工具，而是致力于将图、文档、向量、搜索与治理能力统一于一个平台之中。

这对企业 AI 架构至关重要。许多企业在构建 AI 应用时，往往将向量数据库、图数据库、搜索引擎、ETL 工具、权限系统与审计系统拼接在一起。这种拼凑架构在原型阶段尚可应付，但长期运行会带来数据同步、权限一致性、查询延迟、系统复杂度和维护成本等诸多问题。

Arango 的主张是：与其将多个工具强行拼合成一个 AI 栈，不如在统一的多模型平台上管理图结构、节点属性、向量嵌入与检索能力，让上下文在同一数据基础上生成并调用。

对企业客户而言，这不仅是技术简化，更是降低 AI 项目从 PoC 走向生产环境的复杂度。真正的企业 AI 应用，不能只回答得“像”，还要回答得有依据、可追溯、符合权限边界，并能适应业务关系的变化——统一上下文数据层的价值正在于此。

七、对企业 AI 建设的启示

Contextus 代表了企业 AI 的一个重要转向：从基于文本的问答系统，迈向基于关系的发现系统。

早期阶段，企业 AI 的重心是“让模型能读企业文档”。而随着应用深化，客户真正需要的是“让模型理解企业业务结构”。这意味着 AI 不仅要知道某段文本说了什么，还要知道这段文本对应哪个客户、哪个产品、哪个合同、哪个流程、哪个风险事件，以及这些对象之间如何连接。

因此，企业在构建 AI 应用时，不应只盯着大模型本身，也不能只关注向量检索效果，更应审视底层上下文数据是否被正确组织。

如果企业数据仍是孤立的文档、表格与系统，AI 的能力便极易停留在摘要与问答层面；而若能将业务对象、关系、权限、历史记录与证据链统一建模，AI 才有望进入分析、推理与发现的更高层次。

结语

Contextus 的价值，不在于替代搜索、RAG 或 BI，而在于补足它们共同缺失的一环：发现隐匿于关系结构中的未知线索。

• 搜索回答的是“我知道我要找什么”。
• RAG 回答的是“我知道我要问什么”。
• Contextus 试图回答的是“我尚未意识到哪些东西值得关注”。

对企业 AI 而言，这种能力具有鲜明的现实意义。因为最有价值的洞察，往往并非孤立地存在于某份文档之中，而是潜伏于客户、合同、产品、流程、风险、代码、资产和组织之间复杂的连接网络里。

Arango 通过其上下文数据平台与 Contextus 传递的核心信息是：企业 AI 的下一阶段，不只是将数据接入大模型，而是将企业数据编织成可发现、可解释、可治理的上下文网络。这也正是企业从普通 RAG 走向 GraphRAG，再迈向 AI Discovery 的关键路径。