当前位置：首页 > news >正文

艾体宝洞察 | Semantic Layer vs. Context Layer / #0

news 2026/6/19 2:07:22

越来越多的团队开始把 AI Agent 接入企业数据系统时，一个认知误区正在悄悄埋下隐患，即把 BI 语义层（Semantic Layer）当作 AI 的数据底座。本文厘清两者的本质差异，以及为何构建可靠的 AI Agent，必须在语义层之上再建一层 Context Layer。

BI 语义层解决了什么

任何做过数据治理的团队都对这个场景不陌生：同一个指标"客户获取成本"，在销售看板、财务报表和市场分析系统中，出现了三种不同的口径。

语义层（Semantic Layer）的核心价值，正是打破这种混乱。它作为原始数据源与上层消费端（看板、API、分析平台）之间的抽象层，将指标定义、维度体系、层级关系、实体关联统一沉淀在一处，所有下游系统查询的都是同一套治理过的数字。

在技术实现上，语义层通常允许团队用 YAML 或 DSL 定义指标，再由工具将其编译成优化后的 SQL，对接数仓执行。这套机制带来了三个关键特性：

SQL 查询输出：面向数仓关系型数据的结构化查询
数仓导向架构：请求进入 → 生成 SQL → 数仓执行 → 结果返回
无状态翻译：每次查询独立处理，没有会话上下文，没有历史记忆

这三个特性让语义层成为 BI 场景的优秀解决方案，但同时也界定了它的边界。

语义层的力不从心

当把 AI Agent 接入语义层时，会发现上述三个优点在 Agent 场景下逐一成为瓶颈。

SQL 不原生支持向量检索

Agent 的核心检索逻辑是按语义相似度搜索，而不是精确匹配或范围过滤。尽管部分数据库系统可以以插件形式补充这些能力，但 SQL 是为结构化关系型数据设计的集合运算语言，标准规范并未原生定义 Embedding、近似最近邻（ANN）搜索或相似度评分。

更深层的问题在于：让 LLM 理解业务数据，还需要自然语言同义词映射、字段展示规则、示例查询，以及领域特定的解读说明。一条指标定义，承载不了这些权重。

批量刷新无法满足推理时的实时性要求

语义层通常依赖定时刷新（小时级或天级）来保持数据一致性，而非在查询时实时拉取。但 Agent 的工作方式截然不同，检索和上下文组装发生在推理过程中，每一个推理步骤都需要当前最新的数据。刷新延迟直接叠加进端到端的响应延迟里。

无状态意味着没有多轮推理能力

Agent 的推理天然是多轮的——它需要记住三轮前用户问了什么，记住它已经调用过哪些工具，记住当前任务的工作状态。语义层暴露的是无状态 API，对话历史、工作记忆、工具调用记录，一概没有。

指标一致性无法防止幻觉

语义层能给 LLM 传入定义清晰的数字，但无法约束模型的输出，也无法验证生成内容的正确性。面对一个"言之凿凿的错误答案"，语义层没有任何拦截手段。

非结构化数据完全在边界之外

企业知识的绝大部分并不存在于行列表格之中——产品文档、合同 PDF、工单记录、客服对话……语义层专注于结构化数据，这些内容从一开始就不在其设计范围内。

什么是 Context Layer

以上五个缺口共同指向一个结论：AI Agent 需要一层专属的运行时基础设施。

Context Layer（上下文层）的核心职责是：在 Agent 的每一个推理步骤中，管理它能看到什么信息。用更工程化的语言描述，就是在运行时动态填充并管理 LLM 的 Context Window。

这是一个近年来被称为Context Engineering的工程领域——不只是拼接 Prompt，而是系统性地决定在每次推理调用中，哪些信息应该进入上下文窗口，包括任务描述、few-shot 示例、RAG 检索结果、多模态数据、可用工具列表、状态记录、对话历史，以及上下文压缩策略。RAG 只是其中一个组成部分。

一个完整的 Context Layer 通常包含以下要素：

值得注意的是：语义定义在 Context Layer 中依然存在，但它只是众多输入之一，而非全部。

两层架构的本质差异

最后一行的差异在生产环境中尤为关键。看板上的营收数字算错了，有人会发现、会追查；而 Agent 在错误或过时的上下文基础上采取了行动，失败可以完全无声，并在后续推理步骤中持续放大。

没有 Context Layer 会出什么问题

许多团队在把 Agent 接入真实系统时，很快遇到同类型的工程故障，根源往往是把上下文组装当成胶水代码，而不是基础设施来对待。

上下文腐化（Context Rot）

随着对话轮次推进，消息历史不断追加工具调用结果，上下文长度无限增长。有实际生产数据显示，某任务类型平均需要约 50 次工具调用，每次调用都向历史记录追加新的观察结果。长上下文下 LLM 的性能通常会下降，团队不得不反复重设计上下文的构建、压缩与检索逻辑。

多存储碎片化

为了凑齐上下文所需的能力，许多团队拼接多个本不兼容的存储系统：向量检索用一套，JSON 文档用另一套，关系型数据再来一套，事务数据又是一套。这种 Polyglot Persistence 架构意味着：独立的安全模型、独立的备份策略、独立的扩缩容机制，以及成倍增加的故障点。

检索覆盖盲区

纯向量检索在企业场景中常常不够用，因为用户的查询往往包含精确的产品名称、合同条款编号、工单 ID 或错误码。语义检索擅长理解意图，关键词检索擅长精确匹配，生产级的检索方案通常需要混合检索，并结合租户隔离、语言、时效性等维度的元数据过滤。

Redis 如何构建 Context 基础设施

应对以上挑战，业界的趋势是将碎片化的向量存储、记忆系统、缓存层和特征服务整合到一个统一的运行时层，以单一 API 面向上层暴露能力。

Redis Iris正是 Redis 在这个方向上的系统性布局——一个专为 AI Agent 设计的上下文引擎，将以下五个组件整合为一套低延迟的运行时平台：

Redis Context Retriever：Schema-first 的检索路径，让 Agent 能够按实体（客户、订单、工单等）结构化推理外部数据
Redis Data Integration：基于 Change Data Capture（CDC）将业务系统的操作数据实时流入 Redis，确保 Agent 拿到的是当前数据而非昨晚的快照
Redis Agent Memory：两层记忆架构——工作记忆（当前会话）与长期记忆（跨会话、跨渠道、跨 Agent 共享）
Redis LangCache：语义缓存，识别语义等价的不同表达，避免对 LLM 的重复调用；Redis 公布的基准测试数据显示，高重复性工作负载下推理成本最高降低 73%，且无需修改应用代码
Redis Search：底层检索引擎，统一支持向量、结构化、非结构化及实时数据的混合查询

对于生产 ML 模型，Redis 还提供 Redis Feature Form，作为托管特征存储，解决训练与推理之间的特征一致性问题（Training-Serving Skew）。