从 RAG 到 CAG：企业级 AI 系统的上下文进化

检索增强生成（RAG）作为当前企业集成大语言模型的主流范式，已在知识问答、智能客服等场景中展现出强大的实用性。它通过将外部知识库的检索结果注入模型提示，有效缓解了模型“幻觉”问题，提升了回答的准确性与时效性。然而，随着 AI 系统在真实业务环境中的深入落地，一个关键短板逐渐暴露：RAG 擅长“找对信息”，却难以“理解情境”。

企业系统从来不是孤立运行的。用户身份、会话历史、业务流程状态、合规策略等运行时上下文，往往决定了答案的合法性与适用性。例如，同一份财务政策文档，对普通员工和审计人员的解释必须不同；一个审批流程中的问题，其答案可能因当前所处阶段而异。若仅依赖 RAG，系统只能返回“正确”的文档片段，却无法判断“谁该看到什么”或“在什么条件下该说什么”。

这正是上下文增强生成（Context-Aware Generation, CAG）应运而生的背景。

CAG 的核心：将上下文提升为架构一等公民

CAG 并非要取代 RAG，而是在其基础上构建一层显式的上下文管理机制。它通过在检索与生成之间引入“上下文编排”逻辑，将用户身份、会话状态、业务规则等动态信息结构化地整合进提示工程流程。

在 CAG 架构中，系统不再将每次请求视为孤立的查询，而是将其置于完整的运行时上下文中进行理解与响应。例如，在调用 LLM 前，系统会先通过上下文管理器获取当前用户的角色权限、所属租户、会话历史摘要以及当前业务流程阶段，再将这些信息以规范化方式注入提示模板。

这种分层设计带来了多重优势：
- 可解释性增强：每个 AI 响应都可追溯至具体的上下文输入，便于审计与合规；
- 一致性保障：相同上下文下生成结果更稳定，避免因提示拼接随机性导致的不一致；
- 多租户支持：通过上下文隔离，天然适配不同客户或部门的差异化策略；
- 渐进演进：无需重构现有 RAG 基础设施，可在已有检索与 LLM 服务之上叠加上下文层。

基于 Spring Boot 的 CAG 实现实践

在 Java 生态中，Spring Boot 为 CAG 提供了理想的落地框架。其依赖注入、AOP 切面、Web 过滤器等机制，可清晰地将上下文管理从业务逻辑中解耦。

典型的实现路径如下：
1. 上下文提取：通过 Spring Security 获取用户身份，利用 @SessionAttributes 或 Redis 维护会话状态，结合业务服务获取流程上下文；
2. 上下文组装：定义统一的 ContextEnvelope 对象，封装用户、会话、策略等维度信息；
3. 提示编排：在调用 LLM 服务前，由专门的 PromptComposer 组件将上下文与 RAG 检索结果融合，生成结构化提示；
4. 响应后处理：根据上下文对输出进行二次校验或过滤，确保符合业务约束。

这种设计保持了 Spring Boot 应用的模块化特性，检索器、LLM 客户端与上下文管理器各自独立，便于测试与维护。更重要的是，它无需改动向量数据库或模型接口，即可实现从“文档驱动”到“情境驱动”的平滑升级。

从原型到生产：CAG 的企业价值

CAG 的真正意义，在于为以文档为中心的 RAG 原型提供了一条通往企业级 AI 服务的演进路径。许多团队在初期快速搭建 RAG 应用后，很快面临“功能可用但无法上线”的困境——原因往往不是技术缺陷，而是缺乏对上下文的系统性建模。

通过引入 CAG，企业可以在保留已有技术投入的同时，逐步构建具备上下文感知能力的智能系统。这不仅提升了 AI 输出的合规性与用户体验，也为后续的监控、审计与持续优化奠定了基础。在金融、医疗、政务等强监管领域，这种可追踪、可复现的架构尤为重要。

未来，随着多模态交互、长时记忆、动态策略等需求的增长，上下文管理将成为 AI 系统架构的核心支柱之一。而 CAG 所倡导的“显式建模运行时状态”理念，也将超越提示工程的范畴，成为构建可靠、可信、可治理的企业 AI 的通用范式。

标签： RAG CAG Spring Boot 上下文感知 企业级AI