企业级人工智能架构：RAG负责信息检索，大语言模型负责推理，决策模型负责最终选择
为何仅靠检索与语言推理不够——GraphRAG、智能体以及Jev这类系统1决策模型如何将知识、上下文、推理、决策与执行分开。
来源: The Emerging Architecture of Enterprise AI — RAG Finds, LLMs Reason, Jev Decides.
寻找事实并基于其进行推理已不再是罕见的技能。开放式设计面临的挑战在于如何快速做出业务软件可信赖的有限选择，同时避免将每个微小步骤都转化为自由形式的文本生成。
行业讨论遵循着熟悉的脉络——基础模型、检索增强、图结构增强检索，再到智能体。每一阶段都在填补不同的空白。但有一个环节依然发展不足：决策功能——它既不是对话式的讨论，也不是另一篇散文式的输出，而是应用程序能够执行的、有明确形式的决策结果。
像Jev（TypeSafe AI）这样的系统1风格决策工具让这一层变得具体可感。它们表明，生产环境可能需要在与检索和语言推理并行的基础上，增设专用的决策路径。
企业级人工智能的演进
简化的时间线有助于理清这一缺失的部分。
1. 大语言模型：“能生成什么文本？”
基础模型让机器能够流畅地阅读和书写自然语言。它们“知道”的内容仍然取决于预训练结果以及推理时提供的上下文窗口。
在企业内部，这一差距会立刻显现。关键的专有知识很少存储在模型权重中，而是存在于文档、代码库、API、数据库、政策文件、操作手册、工单、邮件、业务规则、维基页面以及各类应用中。
这种压力促使技术架构向更高层次发展。
2. RAG：“相关资料存放在哪里？”
检索增强生成技术让模型能够查询企业内部的资料库。它不再要求从模型权重中获取所有信息，而是通过特定流程检索相关内容，并将其作为工作上下文提供给语言模型。
该技术流程变为：
企业资料库 → 检索 → 工作上下文 → 语言模型 → 回复
那次突破帮助很大。RAG仍然面临结构性障碍：相似文档检索与理解公司各类事实之间的关联并非同一回事。
以理赔争议为例：
“是什么导致了该索赔被拒，是否需要升级处理？”
要回答这个问题可能需要按以下路径梳理：
客户 → 定保单 → 产品 → 理赔范围 → 索赔申请 → 问题诊断 → 排除条款 → 定保单条款 → 相关法规
这不仅仅是关键词搜索的问题，更是关系与推理问题。
3. GraphRAG：“这些事物之间是如何关联的？”
接下来出现了图结构与GraphRAG。这类平台不再处理孤立的信息片段，而是对实体和边关系进行建模。例如：
Customer
│
├── owns → Policy
│ │
│ ├── covers → Product
│ │
│ └── governed by → Rule
│
└── submitted → Claim
│
├── relates to → Diagnosis
│
└── evaluated against → Coverage
遍历机制取代了“最近段落”检索方式。它正是结构化知识、OKF风格工作以及GraphRAG实验背后的企业级知识层。
即便如此，另一个问题依然存在：在理解并分析完上下文之后：系统究竟应该做什么？
4. 智能体：“接下来应该发生什么？”
智能体设计将语言模型视为指挥者。它能够进行思考、选择工具、调用API、检查结果、决定下一步行动、再次调用其他工具，如此循环直至任务完成。
这种能力带来了架构上的压力：同一个通用模型被要求承担所有阶段的工作：
Understand
↓
Reason
↓
Choose
↓
Route
↓
Decide
↓
Call API
↓
Inspect result
↓
Decide again
↓
Call another API
随之而来的是一些令人困扰的问题：每个智能体的微小决策都需要大型推理模型吗？以语言处理为主的模型是否应该负责做出如下决策：
“将此工单转交给A团队还是B团队？”“继续当前工作流程？”“需要人工介入吗？”“五种预定义操作中哪一种适用？”“这笔交易是否超过升级阈值？”
这些通常属于决策问题，而非语言生成问题。
系统1决策模型
这里Jev的概念很重要。TypeSafe AI将其定义为系统1模型。从概念上讲，两者的区别很简单：
- 大型语言模型主要被优化为生成语言（“用哪种措辞合适？”）。
- 决策模型则基于结构化状态，用结构化输出回答预定义的问题（“应选择哪种软件决策？”）。
公开资料称，Jev会根据共享的应用状态输出预设好的答案并展现自信态度，更注重速度而非冗长的文字描述。这种分离方式有助于构建更为简洁的架构。
缺失的层次
企业级人工智能并不一定非得是以下那种形式：
Enterprise Data
↓
RAG
↓
LLM
↓
Agent
↓
Actions
更为分离的设计则表现为：
Enterprise Systems
↓
Knowledge Engineering
↓
Enterprise Knowledge Layer
↓
Context Engineering
↓
┌──────────────┬──────────────┐
│ │ │
▼ ▼ ▼
Reasoning Decision Rules
LLM Model Engine
│ │ │
└──────────────┴──────────────┘
↓
Agent Control
↓
Deterministic Code
↓
APIs / Workflows
各功能模块的职责会更加清晰。
大语言模型无需包办一切
以保险服务流程为例。客户会这样写道：
“这份住院理赔申请被拒了，但似乎应该得到赔付。”
平台首先需要明确相关背景信息，可能需要调取客户的记录、保单详情、产品配置、保障范围、理赔数据、医院信息、免责条款、保单规定以及监管规则。正是在这里，企业知识层和GraphRAG发挥了重要作用。
此时大语言模型可以开始推理：
“该拒绝似乎与排除项X有关。在条件Z下，条款Y可能会构成例外情况。”
接下来是有限选项的筛选：
Does this require human review?
→ YES
Which workflow?
→ Claims InvestigationPriority?
→ HighAdditional evidence required?
→ YESCustomer communication template?
→ Coverage Review
这些属于结构化的决策，而非开放式生成——这正是像Jev这样的决策模型适用的场景。
架构开始呈现不同面貌
企业级人工智能可以被划分为不同的认知职责。
知识层
公司掌握哪些事实？
OKF——知识图谱——文档——源代码——API——数据库。
上下文层
哪些信息与当前问题相关？
RAG、GraphRAG、上下文工程。
推理层
这些信息意味着什么？
大语言模型与推理模型。
决策层
鉴于当前状况，平台应当采取什么行动？
诸如Jev这样的决策模型。
执行层
应如何执行该决策？
API、工作流、业务规则、确定性软件。
这种分离很重要：智能系统并不需要一个庞大的模型来处理所有事务。
这改变了我们看待企业知识的方式
企业的知识基础设施不仅仅是检索功能的升级，它还可以成为机器决策的状态基础。
想象一个包含以下内容的图结构：
Customer
Policy
Product
Claim
Agent
Branch
API
Business Rule
Regulation
Risk
Transaction
以及诸如以下的关联关系：
Customer → owns → Policy
Policy → belongs to → ProductPolicy → covers → BenefitClaim → relates to → PolicyClaim → triggered by → EventProduct → governed by → RuleRule → derived from → Regulation
系统不再仅仅检索“与索赔相关的文档”，而是构建出业务状态的结构化视图，供不同的智能组件使用：
- 用于推理的LLM
- 用于有限选项选择的决策模型
- 用于确定性约束的规则
- 用于执行的代码
这种组合方式比单一的超级提示语更易于维护。
有趣之处在于：置信度成为了一种架构基础元素
决策模型也会体现置信度。许多人工智能应用仅停留在“模型输出了X”这一层面，而操作人员还需要知道：该结果的可靠性如何，以及当置信度过低时应采取什么措施？
试想：
Decision
↓
Confidence
↓
┌───────────────┐
│ │
High Low
│ │
▼ ▼
Auto Human
execute review
阈值需根据具体应用场景进行调整，但这种模式极具效力。应将人工智能输出视为一种存在不确定性的决策，进而制定自主性策略：
High confidence
↓
Autonomous execution
Medium confidence
↓
Secondary validationLow confidence
↓
Human intervention
受监管行业尤其需要这样的框架。
这还可能改变人工智能行业的经济模式
如果每个智能体的微小决策都会消耗大量计算资源，那么在处理成千上万甚至数百万次请求的集群规模下，成本和延迟都会上升。当许多决策都是狭隘且重复的时，专门的决策系统就能改变成本与延迟的变化趋势。
这就需要另一层路由机制：
Complex reasoning
↓
LLM
Bounded decision
↓
Decision ModelDeterministic rule
↓
Rule EngineExecution
↓
Code
其目的并非取代大型语言模型，而是停止让它们承担本不必执行的任务。
这也会改变我们衡量人工智能的方式
目前的控制面板通常会追踪用户数量、提示词、令牌数、模型使用情况、延迟时间、采用率以及成本。这些指标依然有用。一旦人工智能开始承担实际决策功能，就会出现另一套衡量标准。
决策智能指标
| 指标 | 它能告诉我们什么 |
|---|---|
| 决策数量 |
这使讨论从AI应用转向了AI智能经济学。
此外还有一个重要注意事项
Jev还是全新的产品。值得注意的是，其正式面向公众的时间为2026年9月——因此目前尚缺乏独立的实证数据。另外，现在就将Jev或任何新兴的决策工具视为成熟的LLM替代品还为时过早。
有价值的实验问题是：
在哪些情况下，专门设计的决策工具能优于语言模型、传统规则引擎或混合架构？
应当通过实测来验证，而非凭猜测。
值得进行的实验
选择一种有限的企业流程作为示例，比如服务请求路由，然后将相同的结构化上下文输入到多种不同的处理方法中。
方法1
LLM → 结构化输出 → 应用逻辑
方法2
规则引擎 → 确定性决策
方法三
决策模型 → 类型化决策
方法四
混合式方法：
Rules
↓
Decision Model
↓
LLM when ambiguity requires reasoning
↓
Human when confidence is insufficient
随后需要衡量准确性、确定性校准、延迟、成本、令牌使用量、升级率、可解释性、可维护性、故障模式以及业务成果。
这样的实验比那些仅声称某模型“更优”的排行榜更具说服力。其目的并非为Jev加冕，而是弄清楚哪种智能原语适用于何种场景。
从RAG到推理再到决策
再来看看这个层次结构：
RAG会询问：
“相关资料存储在何处？”
知识图谱会询问：
“这些元素之间是如何关联的？”
GraphRAG会询问：
“应选择哪条上下文路径？”
大语言模型会询问：
“此上下文意味着什么？”
智能体会询问：
“接下来应该做什么？”
决策模型具备以下功能：
决策智能会提出这样的问题：
“在当前状态下，平台应当选择哪种受限的行动？”
这是一种有意义的架构差异。
因此，企业级AI框架可能具备认知能力，而不仅仅是技术功能
团队通常将AI架构视为各种组件来设计：
LLM
Vector DB
Embedding Model
RAG
Orchestrator
API Gateway
Guardrails
而基于认知责任的视角则更像是这样：
ENTERPRISE AI
│
┌────────────┴────────────┐
│ │
KNOWLEDGE CONTEXT
│ │
KG / OKF / Data RAG / GraphRAG
│ │
└────────────┬────────────┘
│
┌─────────┴─────────┐
│ │
REASONING DECISION
│ │
LLM/SLM Jev / similar
│ │
└─────────┬─────────┘
│
ORCHESTRATION
│
GUARDRAILS
│
HUMAN-IN-LOOP
│
EXECUTION
│
APIs / Workflows
企业的AI设计正逐渐从“一个模型统管一切”的模式转向由多种智能组件构成的体系——每种组件都为不同的认知任务而设计。
整体视角
在企业级AI设计中反复出现的主题是：
未来或许不会由拥有最大模型的一方来决定，而会由那些能够基于这些模型构建最佳系统的人来决定。
差异化竞争越来越依赖于专有知识、结构化关系、情境构建、深思熟虑、决策智能以及受控执行等要素的结合。值得注意的是，大语言模型仅是其中的一个组成部分。
未来的发展态势如下：
从生成模型发展到理解系统，再到推理系统，继而发展为决策系统，最终形成行动系统。
因此，持久的竞争优势可能并不在于某个单一的模型版本，而在于将知识、情境、推理、决策与行动有机连接的架构设计——这比单纯追求参数数量更具工程挑战性。