超越 RAG：用 Spring Boot 構建具備上下文感知能力的 AI 系統

作者 | Syed Danish Ali

譯者 | 馬可薇

摘要

• 檢索增強生成（RAG）可以有效將大語言模型的輸出與外部知識對齊，但它并不會建模運行時上下文，例如用戶身份、會話狀態或業務約束，而這些正是企業應用所依賴的關鍵要素。

• 上下文增強生成（CAG）是在現有 RAG 流程之上的擴展，通過引入一個顯式的上下文管理器，在不需要重新訓練模型或改動檢索基礎設施的前提下，對運行時上下文進行組裝和規范化。

• 在基于 Java 的系統中，這種模式可以通過 Spring Boot 清晰地實現：在現有的檢索器和 LLM 服務之上增加一層上下文編排邏輯，從而保持既有的應用結構和部署方式不變。

• 將“上下文”視為一等架構要素，有助于提升系統的可追蹤性和可復現性，使得在受監管或多租戶環境中可以清晰解釋 AI 響應的生成過程。

• CAG 模式為以文檔為中心的 RAG 原型提供了一條漸進式演進路徑，使其發展為具備上下文感知能力的企業級 AI 服務，同時保留已有投入和系統穩定性。

檢索增強生成（RAG）已經迅速成為企業系統中集成大語言模型的一種基礎模式。通過將語義檢索與基于提示的生成結合起來，RAG 可以在不重新訓練底層模型的情況下，讓應用基于領域知識和最新數據生成更可靠的回答。因此，它已廣泛應用于知識助手、內部搜索工具以及客戶支持系統等生產場景。

隨著企業級應用的深入落地，一個反復出現的架構問題逐漸顯現：雖然 RAG 能提升事實準確性，但它并不會自動處理企業軟件所依賴的運行時上下文，例如用戶身份、會話歷史、流程狀態以及領域約束。這類問題在真實部署中越來越明顯，尤其是在受監管或多租戶環境中，不同用戶和不同情境下，系統必須給出差異化的響應。

因此，很多生產系統并不是替代 RAG，而是在其基礎上疊加上下文信息，對檢索和生成過程進行擴展。本文將這種實踐稱為“上下文增強生成”（CAG），并介紹 Java 團隊如何基于 Spring Boot 對其進行清晰的結構設計與實現。文章重點放在系統設計和生產落地，而不是模型訓練或實驗性機器學習流程。

什么是 RAG，以及它在企業系統中的局限

RAG 已成為將大語言模型與企業數據結合的一種實用基礎方案。它通過從外部知識庫中檢索相關文檔，并將其注入到模型提示中，使應用能夠生成比僅依賴訓練數據更準確、更及時的回答。因此，RAG 已被廣泛應用于知識助手、內部搜索工具以及面向客戶的支持系統。

但在生產環境中，團隊逐漸發現，僅靠檢索并不能解決 AI 系統嵌入真實業務流程后遇到的諸多問題。盡管 RAG 提升了信息準確性，但它通常將每一次請求視為相對獨立的處理單元，并未考慮企業系統所依賴的運行時上下文。

一個典型的 RAG 流程包括三個階段：檢索、增強和生成。在檢索階段，向量數據庫或搜索引擎返回與查詢語義相關的文檔；在增強階段，這些文檔會與用戶輸入組合；最終將構造好的提示傳遞給語言模型生成結果。

這種架構在以文檔為中心的場景中表現良好，但企業應用往往需要更多上下文信息，而這些信息并不是單純通過檢索就能獲得。即使在查詢相同的情況下，運行條件不同，合理的回答也可能不同。

例如，回答可能因用戶身份和角色的不同而不同，因為信息訪問通常受權限控制；也可能依賴會話連續性，即后續問題需要基于前文上下文理解；在很多場景中，領域規則和策略（如合規要求、審批流程或訪問控制）也必須參與決策；甚至時間或流程狀態也會影響結果，因為在不同階段，正確答案可能不同。

這些問題本質上并不屬于“檢索”范疇。即使檢索結果完全相關，RAG 系統也無法理解答案適用于誰、在什么條件下應該給出，或企業規則應如何影響輸出。

因此，一旦 RAG 從原型走向生產，團隊往往會遇到一類典型問題：回答在事實層面正確，但在上下文上不合適，例如忽略用戶角色或流程狀態；對于類似問題，不同用戶或不同會話之間的回答可能不一致；同時，也很難解釋或審計某個回答為何產生。隨著時間推移，如果僅通過 prompt 邏輯來強行嵌入業務規則，會不斷增加復雜度，但無法真正解決架構層面的缺口。

這些局限并不否定 RAG 的價值，而是界定了它的適用范圍。RAG 擅長解決“找什么信息”的問題，但并不負責建模企業系統運行所需的上下文。要彌補這一點，需要將“上下文”提升為一等架構要素，而不是簡單作為 prompt 的附加信息。

CAG 架構模式的組織方式

當團隊逐漸意識到“僅靠檢索”無法滿足需求時，一種更完整的架構模式開始形成：在應用層顯式管理運行時上下文，對 RAG 進行擴展。與其將每個請求視為獨立的檢索問題，不如在調用語言模型之前，將用戶、會話和策略等信號與檢索結果一起統一組織起來。

盡管不同組織的術語有所不同，但在大規模企業系統中，“文檔檢索”和“上下文編排”之間的分層已經逐漸清晰。例如，DoorDash 在其基于大語言模型 的客服自動化系統中，就明確區分了檢索組件和更高層的上下文模塊，后者負責整合騎手狀態、流程上下文以及業務約束。類似地，微軟在 Copilot 的語義索引 中，也強調不僅要基于內容進行檢索，還要結合組織上下文、權限以及用戶特征來生成響應。

與此同時，在 DZone、Meilisearch 等工程社區的討論中，這種方式通常被稱為“上下文增強生成（CAG）”，強調生成效果不僅取決于檢索到的文檔，還取決于“是誰在問、在什么場景下問，以及受到哪些約束”。不過，這類討論往往停留在概念層面，缺乏一個可以在企業中穩定落地的架構結構。尤其是在 Java 系統中，狀態管理、治理能力和可追蹤性本身就是一等需求，更需要清晰的實現方式。

本文將 CAG 視為一種架構層面的演進，而不是新的檢索技術。實際上，大多數企業系統已經在以非正式的方式使用上下文信息：例如將用戶屬性拼接到 prompt 中、手動加入對話歷史，或通過零散邏輯注入策略文本。CAG 的價值在于將這些做法規范化，使“上下文組裝”成為系統中一個明確且可復用的能力。從本質上看，兩者的區別可以概括為：RAG 關注“哪些信息相關”，而 CAG 關注“這些信息對誰相關、在什么情境下相關，以及受到哪些約束”。

在具體實現上，CAG 并不會替代檢索或生成，而是在其旁邊引入一個獨立的上下文管理器。這個組件負責在構建 prompt 或調度檢索之前，收集并規范化運行時信號，例如用戶身份、會話歷史和領域策略。

這種設計會帶來重要的架構收益。通過將上下文處理集中在一個組件中，系統可以更清晰地實現關注點分離：檢索質量、模型行為和上下文影響可以分別分析，從而提升測試性、可審計性以及后續演進能力。

對于企業級 Java 應用而言，這種方式也與既有設計原則天然契合。用戶上下文、授權狀態以及流程元數據本來就存在于應用層，而不是機器學習基礎設施中。CAG 的做法，是將上下文能力保留在業務邏輯附近，由應用架構進行治理，而不依賴具體的 LLM 或向量數據庫。

在 CAG 架構下，RAG 的核心組件（檢索器、向量存儲和 LLM 服務）本身并不發生變化。不同之處在于，請求在進入這些組件之前的準備方式。通過在上游引入上下文管理器，團隊可以在保持現有 RAG 投入和運行穩定性的前提下，為 AI 交互引入企業級的上下文能力。

在 Spring Boot 中實現上下文管理器（企業場景）

圖一：在傳統 RAG 流程之上疊加的 CAG 架構

圖一展示了在 Spring Boot 應用中，CAG 如何擴展現有的 RAG 流程。虛線區域表示未發生變化的 RAG 組件（檢索器和 LLM 服務），而上下文管理器層則在調用 RAG 流程之前，為請求補充用戶、會話和策略等上下文信息。

本節說明如何在現有基于 Spring Boot 的 RAG 應用中，通過引入一個輕量級的上下文管理器層來集成 CAG。目標并不是構建完整的演示系統，而是展示企業團隊如何在不改變現有檢索與生成組件的前提下，為標準 RAG 架構增加顯式的上下文處理能力。

基于 Spring 的 RAG 系統通常遵循一種成熟結構：文檔先被處理并嵌入向量庫，在查詢時由檢索器將相關內容注入到 prompt 中，再發送給 LLM 生成結果。這種架構在使用 Spring AI 構建的生產系統中較為常見，也可以參考 InfoQ 關于 Spring Boot + MongoDB + OpenAI 構建 RAG 應用的文章。本文后續均以這一典型流程作為基礎假設。

CAG 的做法并不是修改該流程，而是在其之上增加一層。

企業場景示例

設想一個企業內部的政策助手，供多個部門使用。雖然政策文檔是統一的，但具體回答往往需要根據用戶角色或部門、當前會話上下文，以及組織內部的信息披露規則進行調整。

傳統的 RAG 流程可以檢索相關政策并生成回答，但不會顯式建模這些運行時因素。因此，即便查詢相同，在不同上下文下也可能需要不同答案，而這正是企業系統的常見要求。CAG 通過上下文管理器，在調用既有 RAG 流程之前，將用戶、會話和策略信息統一組織起來，以滿足這一需求。

架構說明

如圖一所示，在基于 Spring Boot 的應用中，整體結構依然保持清晰。Spring Boot API 繼續作為入口，對外接口和交互方式與傳統 RAG 系統一致。

在應用層中，引入上下文管理器作為獨立組件，負責收集運行時信號，包括用戶信息、會話歷史和策略約束。其職責僅限于對這些上下文進行整理和規范化，然后傳遞給下游。

現有的 RAG 流程（檢索器、向量存儲和 LLM 服務）保持不變，在圖中以虛線區域表示。上下文會影響檢索方式和 prompt 構建，但不會改變底層組件本身。

這種結構與常見的 Spring RAG 實現方式保持一致，也使得 CAG 更像是一種漸進式擴展，而不是整體重構。

上下文管理器的角色

上下文管理器將企業系統中原本分散存在的職責進行了顯式化。相比于將上下文邏輯散落在控制器或臨時 prompt 模板中，CAG 將其集中在一個獨立組件中統一處理。

從功能上看，它負責收集用戶屬性（如角色、部門）、整合會話歷史，并應用領域策略或業務約束，最終生成一個統一的上下文對象，在檢索和生成階段一致使用。

通過將上下文處理與檢索、生成解耦，系統在理解、審計和演進上都會更加清晰。

在 Spring Boot 中的集成方式

下面的示例展示了上下文管理器在典型 Spring Boot 請求流程中的位置。作者有意簡化了這些示例，并假設系統中已經有一個類似 Spring AI 架構的 RAG 服務。

}

一個簡化的上下文對象通常會包含：

}

RAG 服務本身的行為不會改變，仍然負責檢索和生成。唯一的不同是，在構建 prompt 或執行檢索調度時，可以顯式使用上下文信息。

CAG 作為 RAG 的擴展

需要強調的是，CAG 并不是對 RAG 的替代。檢索器、向量存儲和 LLM 服務仍按原方式在基于 Spring 的 RAG 應用中運行。上下文管理器只是作為一個附加層，在請求進入 RAG 流程之前進行增強。

這種設計帶來幾個實際好處：現有 RAG 實現無需改動，可以直接復用；由于核心的檢索生成組件不變，因此引入過程可以漸進推進，風險較低；同時，上下文邏輯被顯式化，更容易測試、審計和分析系統行為。

通過將“上下文”提升為一等架構要素，基于 Spring Boot 的系統可以在不大規模改造的前提下，從以文檔為中心的 AI 助手演進為具備上下文感知能力的企業服務。

最佳實踐與注意事項：讓 CAG 可用于生產環境

將上下文作為明確的約束

引入上下文管理器可以讓上下文處理變得顯式，但同時也帶來了一個新的架構約束。在生產環境中，上下文不應被當作隨意拼接的一組屬性來處理。用戶身份、會話狀態和業務約束各自承擔不同作用，其變化節奏也不相同。通過清晰的結構劃分和責任歸屬，將這些差異明確下來，有助于避免無意間的耦合，也能讓系統在需求不斷變化的情況下依然保持可維護性。

控制上下文的范圍

上下文越多并不一定越好。過多的歷史或業務相關元數據會增加延遲、提高推理成本，還可能稀釋關鍵信息。實踐中，應優先保留最關鍵的內容，如近期會話信息、標準化用戶屬性，以及確實影響結果的業務約束。

保持現有 RAG 流程的穩定性

CAG 的一個核心優勢在于，它不會改變原有的檢索和生成流程。這種分離關系需要被有意識地保留下來。具體來說，上下文相關的邏輯應當只存在于上下文管理器中，而不應該被嵌入到檢索器或 LLM 的封裝層里。如果將上下文處理分散到這些組件中，不僅會增加系統復雜度，也會模糊不同模塊的職責邊界。

讓上下文具備可觀測性

一旦上下文開始影響系統行為，可觀測性就變成了必需，而不是可選項。如果無法清楚地看到系統在某次請求中實際使用了哪些上下文信息，那么無論是問題排查還是系統治理，都會變得非常困難。

在實踐中，合理范圍控制和脫敏處理后的元數據記錄可以用來解決這個問題，幫助團隊理解“為什么會生成這個結果”，同時也為審計、合規等場景提供支持。CAG 的價值，很大一部分正體現在讓上下文從“隱式存在”變為“顯式可見”。

針對上下文缺失或不完整的情況進行設計

在企業系統中，數據不完整幾乎是常態，而不是例外。用戶信息可能缺失，會話歷史可能已經過期，策略服務也可能在某些時刻不可用。因此，一個健壯的上下文管理器不應假設所有信息都是齊全的，而應該具備良好的降級能力。例如，在必要時使用默認值，或者在不影響核心邏輯的前提下忽略部分非關鍵上下文，而不是直接導致整個請求失敗。如果設計得當，CAG 不僅不會降低系統穩定性，反而可以提升整體可靠性；反之，如果對上下文依賴過強且缺乏容錯機制，就可能引入新的故障點。

避免讓上下文管理器“過載”

隨著 CAG 系統不斷演進，一個常見的問題是：上下文管理器逐漸承擔越來越多的職責。一旦 CAG 開始包含業務邏輯甚至決策邏輯，上下文管理器就有可能演變為系統瓶頸。更合理的做法是，將其職責限制在“編排和整理上下文”這一層面，也就是負責收集、聚合和規范化數據，而不是對這些數據做業務層面的解釋或決策。這樣可以保持系統結構的清晰性，同時也有利于測試和長期維護。

安全與隱私方面的考慮

上下文中往往包含用戶或組織層面的敏感信息，因此安全問題應作為顯式設計的一部分。在將上下文信息注入 prompt 之前，應當先進行訪問控制、數據最小化處理以及必要的脫敏。CAG 應該強化企業已有的安全與治理機制，而不是繞開這些機制。

以漸進方式引入 CAG

在實際落地中，成熟的團隊通常不會一次性全面引入 CAG，而是選擇分階段推進?？梢韵葟囊粋€最小化的上下文層開始，只引入少量關鍵上下文信息，再根據實際效果逐步擴展。這樣的方式可以在不影響現有 RAG 系統運行的前提下，對設計假設進行驗證，并根據反饋不斷調整實現策略。隨著系統逐步演進，這種有節奏的推進方式能夠幫助團隊從以文檔為中心的 AI 助手，平滑過渡到具備上下文感知能力的企業級服務。

從整體來看，讓 CAG 具備生產可用性，關鍵不在于具體工具的選擇，而在于是否具備良好的架構約束。只有在上下文被清晰定義、邊界明確、具備可觀測性，并且與底層 RAG 流程保持解耦的前提下，團隊才能在擴展系統上下文能力的同時，維持既有系統的穩定性和可控性。

總 結

RAG 已成為將大語言模型與企業數據結合的一種實用基礎方案。但隨著 AI 系統從原型走向生產，我們可以看到，僅靠檢索并不足以滿足需求。企業軟件本質上是有狀態的，受到用戶角色、會話連續性和業務約束的影響，而這些因素并未在傳統 RAG 中顯式建模。

CAG 通過引入一個專門的上下文管理層來彌補這一缺口。它并不替代現有的檢索器或 LLM 服務，而是在應用層將上下文處理能力顯式化——也正是企業上下文本來就存在的地方。這種分層方式既保留了已有的 RAG 投入，又讓系統在行為一致性、可追蹤性以及 AI 行為和業務契合度方面得到提升。

對于使用 Java 和 Spring Boot 的團隊來說，CAG 與現有架構模式天然契合。通過明確劃分職責——應用層負責上下文組裝，RAG 流程負責檢索與生成——團隊可以以較低成本、較小風險逐步引入 CAG。

作者說明：本文基于作者個人的技術研究整理，僅代表個人觀點，不對應任何具體組織的實際架構實現。

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。