作者 | Syed Danish Ali

譯者 | 馬可薇

摘要

• 檢索增強(qiáng)生成（RAG）可以有效將大語(yǔ)言模型的輸出與外部知識(shí)對(duì)齊，但它并不會(huì)建模運(yùn)行時(shí)上下文，例如用戶身份、會(huì)話狀態(tài)或業(yè)務(wù)約束，而這些正是企業(yè)應(yīng)用所依賴的關(guān)鍵要素。

• 上下文增強(qiáng)生成（CAG）是在現(xiàn)有 RAG 流程之上的擴(kuò)展，通過引入一個(gè)顯式的上下文管理器，在不需要重新訓(xùn)練模型或改動(dòng)檢索基礎(chǔ)設(shè)施的前提下，對(duì)運(yùn)行時(shí)上下文進(jìn)行組裝和規(guī)范化。

• 在基于 Java 的系統(tǒng)中，這種模式可以通過 Spring Boot 清晰地實(shí)現(xiàn)：在現(xiàn)有的檢索器和 LLM 服務(wù)之上增加一層上下文編排邏輯，從而保持既有的應(yīng)用結(jié)構(gòu)和部署方式不變。

• 將“上下文”視為一等架構(gòu)要素，有助于提升系統(tǒng)的可追蹤性和可復(fù)現(xiàn)性，使得在受監(jiān)管或多租戶環(huán)境中可以清晰解釋 AI 響應(yīng)的生成過程。

• CAG 模式為以文檔為中心的 RAG 原型提供了一條漸進(jìn)式演進(jìn)路徑，使其發(fā)展為具備上下文感知能力的企業(yè)級(jí) AI 服務(wù)，同時(shí)保留已有投入和系統(tǒng)穩(wěn)定性。

檢索增強(qiáng)生成（RAG）已經(jīng)迅速成為企業(yè)系統(tǒng)中集成大語(yǔ)言模型的一種基礎(chǔ)模式。通過將語(yǔ)義檢索與基于提示的生成結(jié)合起來，RAG 可以在不重新訓(xùn)練底層模型的情況下，讓應(yīng)用基于領(lǐng)域知識(shí)和最新數(shù)據(jù)生成更可靠的回答。因此，它已廣泛應(yīng)用于知識(shí)助手、內(nèi)部搜索工具以及客戶支持系統(tǒng)等生產(chǎn)場(chǎng)景。

隨著企業(yè)級(jí)應(yīng)用的深入落地，一個(gè)反復(fù)出現(xiàn)的架構(gòu)問題逐漸顯現(xiàn)：雖然 RAG 能提升事實(shí)準(zhǔn)確性，但它并不會(huì)自動(dòng)處理企業(yè)軟件所依賴的運(yùn)行時(shí)上下文，例如用戶身份、會(huì)話歷史、流程狀態(tài)以及領(lǐng)域約束。這類問題在真實(shí)部署中越來越明顯，尤其是在受監(jiān)管或多租戶環(huán)境中，不同用戶和不同情境下，系統(tǒng)必須給出差異化的響應(yīng)。

因此，很多生產(chǎn)系統(tǒng)并不是替代 RAG，而是在其基礎(chǔ)上疊加上下文信息，對(duì)檢索和生成過程進(jìn)行擴(kuò)展。本文將這種實(shí)踐稱為“上下文增強(qiáng)生成”（CAG），并介紹 Java 團(tuán)隊(duì)如何基于 Spring Boot 對(duì)其進(jìn)行清晰的結(jié)構(gòu)設(shè)計(jì)與實(shí)現(xiàn)。文章重點(diǎn)放在系統(tǒng)設(shè)計(jì)和生產(chǎn)落地，而不是模型訓(xùn)練或?qū)嶒?yàn)性機(jī)器學(xué)習(xí)流程。

什么是 RAG，以及它在企業(yè)系統(tǒng)中的局限

RAG 已成為將大語(yǔ)言模型與企業(yè)數(shù)據(jù)結(jié)合的一種實(shí)用基礎(chǔ)方案。它通過從外部知識(shí)庫(kù)中檢索相關(guān)文檔，并將其注入到模型提示中，使應(yīng)用能夠生成比僅依賴訓(xùn)練數(shù)據(jù)更準(zhǔn)確、更及時(shí)的回答。因此，RAG 已被廣泛應(yīng)用于知識(shí)助手、內(nèi)部搜索工具以及面向客戶的支持系統(tǒng)。

但在生產(chǎn)環(huán)境中，團(tuán)隊(duì)逐漸發(fā)現(xiàn)，僅靠檢索并不能解決 AI 系統(tǒng)嵌入真實(shí)業(yè)務(wù)流程后遇到的諸多問題。盡管 RAG 提升了信息準(zhǔn)確性，但它通常將每一次請(qǐng)求視為相對(duì)獨(dú)立的處理單元，并未考慮企業(yè)系統(tǒng)所依賴的運(yùn)行時(shí)上下文。

一個(gè)典型的 RAG 流程包括三個(gè)階段：檢索、增強(qiáng)和生成。在檢索階段，向量數(shù)據(jù)庫(kù)或搜索引擎返回與查詢語(yǔ)義相關(guān)的文檔；在增強(qiáng)階段，這些文檔會(huì)與用戶輸入組合；最終將構(gòu)造好的提示傳遞給語(yǔ)言模型生成結(jié)果。

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

例如，回答可能因用戶身份和角色的不同而不同，因?yàn)樾畔⒃L問通常受權(quán)限控制；也可能依賴會(huì)話連續(xù)性，即后續(xù)問題需要基于前文上下文理解；在很多場(chǎng)景中，領(lǐng)域規(guī)則和策略（如合規(guī)要求、審批流程或訪問控制）也必須參與決策；甚至?xí)r間或流程狀態(tài)也會(huì)影響結(jié)果，因?yàn)樵诓煌A段，正確答案可能不同。

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

因此，一旦 RAG 從原型走向生產(chǎn)，團(tuán)隊(duì)往往會(huì)遇到一類典型問題：回答在事實(shí)層面正確，但在上下文上不合適，例如忽略用戶角色或流程狀態(tài)；對(duì)于類似問題，不同用戶或不同會(huì)話之間的回答可能不一致；同時(shí)，也很難解釋或?qū)徲?jì)某個(gè)回答為何產(chǎn)生。隨著時(shí)間推移，如果僅通過 prompt 邏輯來強(qiáng)行嵌入業(yè)務(wù)規(guī)則，會(huì)不斷增加復(fù)雜度，但無法真正解決架構(gòu)層面的缺口。

這些局限并不否定 RAG 的價(jià)值，而是界定了它的適用范圍。RAG 擅長(zhǎng)解決“找什么信息”的問題，但并不負(fù)責(zé)建模企業(yè)系統(tǒng)運(yùn)行所需的上下文。要彌補(bǔ)這一點(diǎn)，需要將“上下文”提升為一等架構(gòu)要素，而不是簡(jiǎn)單作為 prompt 的附加信息。

CAG 架構(gòu)模式的組織方式

當(dāng)團(tuán)隊(duì)逐漸意識(shí)到“僅靠檢索”無法滿足需求時(shí)，一種更完整的架構(gòu)模式開始形成：在應(yīng)用層顯式管理運(yùn)行時(shí)上下文，對(duì) RAG 進(jìn)行擴(kuò)展。與其將每個(gè)請(qǐng)求視為獨(dú)立的檢索問題，不如在調(diào)用語(yǔ)言模型之前，將用戶、會(huì)話和策略等信號(hào)與檢索結(jié)果一起統(tǒng)一組織起來。

盡管不同組織的術(shù)語(yǔ)有所不同，但在大規(guī)模企業(yè)系統(tǒng)中，“文檔檢索”和“上下文編排”之間的分層已經(jīng)逐漸清晰。例如，DoorDash 在其基于大語(yǔ)言模型 的客服自動(dòng)化系統(tǒng)中，就明確區(qū)分了檢索組件和更高層的上下文模塊，后者負(fù)責(zé)整合騎手狀態(tài)、流程上下文以及業(yè)務(wù)約束。類似地，微軟在 Copilot 的語(yǔ)義索引 中，也強(qiáng)調(diào)不僅要基于內(nèi)容進(jìn)行檢索，還要結(jié)合組織上下文、權(quán)限以及用戶特征來生成響應(yīng)。

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

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

在具體實(shí)現(xiàn)上，CAG 并不會(huì)替代檢索或生成，而是在其旁邊引入一個(gè)獨(dú)立的上下文管理器。這個(gè)組件負(fù)責(zé)在構(gòu)建 prompt 或調(diào)度檢索之前，收集并規(guī)范化運(yùn)行時(shí)信號(hào)，例如用戶身份、會(huì)話歷史和領(lǐng)域策略。

這種設(shè)計(jì)會(huì)帶來重要的架構(gòu)收益。通過將上下文處理集中在一個(gè)組件中，系統(tǒng)可以更清晰地實(shí)現(xiàn)關(guān)注點(diǎn)分離：檢索質(zhì)量、模型行為和上下文影響可以分別分析，從而提升測(cè)試性、可審計(jì)性以及后續(xù)演進(jìn)能力。

對(duì)于企業(yè)級(jí) Java 應(yīng)用而言，這種方式也與既有設(shè)計(jì)原則天然契合。用戶上下文、授權(quán)狀態(tài)以及流程元數(shù)據(jù)本來就存在于應(yīng)用層，而不是機(jī)器學(xué)習(xí)基礎(chǔ)設(shè)施中。CAG 的做法，是將上下文能力保留在業(yè)務(wù)邏輯附近，由應(yīng)用架構(gòu)進(jìn)行治理，而不依賴具體的 LLM 或向量數(shù)據(jù)庫(kù)。

在 CAG 架構(gòu)下，RAG 的核心組件（檢索器、向量存儲(chǔ)和 LLM 服務(wù)）本身并不發(fā)生變化。不同之處在于，請(qǐng)求在進(jìn)入這些組件之前的準(zhǔn)備方式。通過在上游引入上下文管理器，團(tuán)隊(duì)可以在保持現(xiàn)有 RAG 投入和運(yùn)行穩(wěn)定性的前提下，為 AI 交互引入企業(yè)級(jí)的上下文能力。

在 Spring Boot 中實(shí)現(xiàn)上下文管理器（企業(yè)場(chǎng)景）

圖一：在傳統(tǒng) RAG 流程之上疊加的 CAG 架構(gòu)

圖一展示了在 Spring Boot 應(yīng)用中，CAG 如何擴(kuò)展現(xiàn)有的 RAG 流程。虛線區(qū)域表示未發(fā)生變化的 RAG 組件（檢索器和 LLM 服務(wù)），而上下文管理器層則在調(diào)用 RAG 流程之前，為請(qǐng)求補(bǔ)充用戶、會(huì)話和策略等上下文信息。

本節(jié)說明如何在現(xiàn)有基于 Spring Boot 的 RAG 應(yīng)用中，通過引入一個(gè)輕量級(jí)的上下文管理器層來集成 CAG。目標(biāo)并不是構(gòu)建完整的演示系統(tǒng)，而是展示企業(yè)團(tuán)隊(duì)如何在不改變現(xiàn)有檢索與生成組件的前提下，為標(biāo)準(zhǔn) RAG 架構(gòu)增加顯式的上下文處理能力。

基于 Spring 的 RAG 系統(tǒng)通常遵循一種成熟結(jié)構(gòu)：文檔先被處理并嵌入向量庫(kù)，在查詢時(shí)由檢索器將相關(guān)內(nèi)容注入到 prompt 中，再發(fā)送給 LLM 生成結(jié)果。這種架構(gòu)在使用 Spring AI 構(gòu)建的生產(chǎn)系統(tǒng)中較為常見，也可以參考 InfoQ 關(guān)于 Spring Boot + MongoDB + OpenAI 構(gòu)建 RAG 應(yīng)用的文章。本文后續(xù)均以這一典型流程作為基礎(chǔ)假設(shè)。

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

企業(yè)場(chǎng)景示例

設(shè)想一個(gè)企業(yè)內(nèi)部的政策助手，供多個(gè)部門使用。雖然政策文檔是統(tǒng)一的，但具體回答往往需要根據(jù)用戶角色或部門、當(dāng)前會(huì)話上下文，以及組織內(nèi)部的信息披露規(guī)則進(jìn)行調(diào)整。

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

架構(gòu)說明

如圖一所示，在基于 Spring Boot 的應(yīng)用中，整體結(jié)構(gòu)依然保持清晰。Spring Boot API 繼續(xù)作為入口，對(duì)外接口和交互方式與傳統(tǒng) RAG 系統(tǒng)一致。

在應(yīng)用層中，引入上下文管理器作為獨(dú)立組件，負(fù)責(zé)收集運(yùn)行時(shí)信號(hào)，包括用戶信息、會(huì)話歷史和策略約束。其職責(zé)僅限于對(duì)這些上下文進(jìn)行整理和規(guī)范化，然后傳遞給下游。

現(xiàn)有的 RAG 流程（檢索器、向量存儲(chǔ)和 LLM 服務(wù)）保持不變，在圖中以虛線區(qū)域表示。上下文會(huì)影響檢索方式和 prompt 構(gòu)建，但不會(huì)改變底層組件本身。

這種結(jié)構(gòu)與常見的 Spring RAG 實(shí)現(xiàn)方式保持一致，也使得 CAG 更像是一種漸進(jìn)式擴(kuò)展，而不是整體重構(gòu)。

上下文管理器的角色

上下文管理器將企業(yè)系統(tǒng)中原本分散存在的職責(zé)進(jìn)行了顯式化。相比于將上下文邏輯散落在控制器或臨時(shí) prompt 模板中，CAG 將其集中在一個(gè)獨(dú)立組件中統(tǒng)一處理。

從功能上看，它負(fù)責(zé)收集用戶屬性（如角色、部門）、整合會(huì)話歷史，并應(yīng)用領(lǐng)域策略或業(yè)務(wù)約束，最終生成一個(gè)統(tǒng)一的上下文對(duì)象，在檢索和生成階段一致使用。

通過將上下文處理與檢索、生成解耦，系統(tǒng)在理解、審計(jì)和演進(jìn)上都會(huì)更加清晰。

在 Spring Boot 中的集成方式

下面的示例展示了上下文管理器在典型 Spring Boot 請(qǐng)求流程中的位置。作者有意簡(jiǎn)化了這些示例，并假設(shè)系統(tǒng)中已經(jīng)有一個(gè)類似 Spring AI 架構(gòu)的 RAG 服務(wù)。

}

一個(gè)簡(jiǎn)化的上下文對(duì)象通常會(huì)包含：

}

RAG 服務(wù)本身的行為不會(huì)改變，仍然負(fù)責(zé)檢索和生成。唯一的不同是，在構(gòu)建 prompt 或執(zhí)行檢索調(diào)度時(shí)，可以顯式使用上下文信息。

CAG 作為 RAG 的擴(kuò)展

需要強(qiáng)調(diào)的是，CAG 并不是對(duì) RAG 的替代。檢索器、向量存儲(chǔ)和 LLM 服務(wù)仍按原方式在基于 Spring 的 RAG 應(yīng)用中運(yùn)行。上下文管理器只是作為一個(gè)附加層，在請(qǐng)求進(jìn)入 RAG 流程之前進(jìn)行增強(qiáng)。

這種設(shè)計(jì)帶來幾個(gè)實(shí)際好處：現(xiàn)有 RAG 實(shí)現(xiàn)無需改動(dòng)，可以直接復(fù)用；由于核心的檢索生成組件不變，因此引入過程可以漸進(jìn)推進(jìn)，風(fēng)險(xiǎn)較低；同時(shí)，上下文邏輯被顯式化，更容易測(cè)試、審計(jì)和分析系統(tǒng)行為。

通過將“上下文”提升為一等架構(gòu)要素，基于 Spring Boot 的系統(tǒng)可以在不大規(guī)模改造的前提下，從以文檔為中心的 AI 助手演進(jìn)為具備上下文感知能力的企業(yè)服務(wù)。

最佳實(shí)踐與注意事項(xiàng)：讓 CAG 可用于生產(chǎn)環(huán)境

將上下文作為明確的約束

引入上下文管理器可以讓上下文處理變得顯式，但同時(shí)也帶來了一個(gè)新的架構(gòu)約束。在生產(chǎn)環(huán)境中，上下文不應(yīng)被當(dāng)作隨意拼接的一組屬性來處理。用戶身份、會(huì)話狀態(tài)和業(yè)務(wù)約束各自承擔(dān)不同作用，其變化節(jié)奏也不相同。通過清晰的結(jié)構(gòu)劃分和責(zé)任歸屬，將這些差異明確下來，有助于避免無意間的耦合，也能讓系統(tǒng)在需求不斷變化的情況下依然保持可維護(hù)性。

控制上下文的范圍

上下文越多并不一定越好。過多的歷史或業(yè)務(wù)相關(guān)元數(shù)據(jù)會(huì)增加延遲、提高推理成本，還可能稀釋關(guān)鍵信息。實(shí)踐中，應(yīng)優(yōu)先保留最關(guān)鍵的內(nèi)容，如近期會(huì)話信息、標(biāo)準(zhǔn)化用戶屬性，以及確實(shí)影響結(jié)果的業(yè)務(wù)約束。

保持現(xiàn)有 RAG 流程的穩(wěn)定性

CAG 的一個(gè)核心優(yōu)勢(shì)在于，它不會(huì)改變?cè)械臋z索和生成流程。這種分離關(guān)系需要被有意識(shí)地保留下來。具體來說，上下文相關(guān)的邏輯應(yīng)當(dāng)只存在于上下文管理器中，而不應(yīng)該被嵌入到檢索器或 LLM 的封裝層里。如果將上下文處理分散到這些組件中，不僅會(huì)增加系統(tǒng)復(fù)雜度，也會(huì)模糊不同模塊的職責(zé)邊界。

讓上下文具備可觀測(cè)性

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

在實(shí)踐中，合理范圍控制和脫敏處理后的元數(shù)據(jù)記錄可以用來解決這個(gè)問題，幫助團(tuán)隊(duì)理解“為什么會(huì)生成這個(gè)結(jié)果”，同時(shí)也為審計(jì)、合規(guī)等場(chǎng)景提供支持。CAG 的價(jià)值，很大一部分正體現(xiàn)在讓上下文從“隱式存在”變?yōu)椤帮@式可見”。

針對(duì)上下文缺失或不完整的情況進(jìn)行設(shè)計(jì)

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

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

隨著 CAG 系統(tǒng)不斷演進(jìn)，一個(gè)常見的問題是：上下文管理器逐漸承擔(dān)越來越多的職責(zé)。一旦 CAG 開始包含業(yè)務(wù)邏輯甚至決策邏輯，上下文管理器就有可能演變?yōu)橄到y(tǒng)瓶頸。更合理的做法是，將其職責(zé)限制在“編排和整理上下文”這一層面，也就是負(fù)責(zé)收集、聚合和規(guī)范化數(shù)據(jù)，而不是對(duì)這些數(shù)據(jù)做業(yè)務(wù)層面的解釋或決策。這樣可以保持系統(tǒng)結(jié)構(gòu)的清晰性，同時(shí)也有利于測(cè)試和長(zhǎng)期維護(hù)。

安全與隱私方面的考慮

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

以漸進(jìn)方式引入 CAG

在實(shí)際落地中，成熟的團(tuán)隊(duì)通常不會(huì)一次性全面引入 CAG，而是選擇分階段推進(jìn)。可以先從一個(gè)最小化的上下文層開始，只引入少量關(guān)鍵上下文信息，再根據(jù)實(shí)際效果逐步擴(kuò)展。這樣的方式可以在不影響現(xiàn)有 RAG 系統(tǒng)運(yùn)行的前提下，對(duì)設(shè)計(jì)假設(shè)進(jìn)行驗(yàn)證，并根據(jù)反饋不斷調(diào)整實(shí)現(xiàn)策略。隨著系統(tǒng)逐步演進(jìn)，這種有節(jié)奏的推進(jìn)方式能夠幫助團(tuán)隊(duì)從以文檔為中心的 AI 助手，平滑過渡到具備上下文感知能力的企業(yè)級(jí)服務(wù)。

從整體來看，讓 CAG 具備生產(chǎn)可用性，關(guān)鍵不在于具體工具的選擇，而在于是否具備良好的架構(gòu)約束。只有在上下文被清晰定義、邊界明確、具備可觀測(cè)性，并且與底層 RAG 流程保持解耦的前提下，團(tuán)隊(duì)才能在擴(kuò)展系統(tǒng)上下文能力的同時(shí)，維持既有系統(tǒng)的穩(wěn)定性和可控性。

總 結(jié)

RAG 已成為將大語(yǔ)言模型與企業(yè)數(shù)據(jù)結(jié)合的一種實(shí)用基礎(chǔ)方案。但隨著 AI 系統(tǒng)從原型走向生產(chǎn)，我們可以看到，僅靠檢索并不足以滿足需求。企業(yè)軟件本質(zhì)上是有狀態(tài)的，受到用戶角色、會(huì)話連續(xù)性和業(yè)務(wù)約束的影響，而這些因素并未在傳統(tǒng) RAG 中顯式建模。

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

對(duì)于使用 Java 和 Spring Boot 的團(tuán)隊(duì)來說，CAG 與現(xiàn)有架構(gòu)模式天然契合。通過明確劃分職責(zé)——應(yīng)用層負(fù)責(zé)上下文組裝，RAG 流程負(fù)責(zé)檢索與生成——團(tuán)隊(duì)可以以較低成本、較小風(fēng)險(xiǎn)逐步引入 CAG。

作者說明：本文基于作者個(gè)人的技術(shù)研究整理，僅代表個(gè)人觀點(diǎn)，不對(duì)應(yīng)任何具體組織的實(shí)際架構(gòu)實(shí)現(xiàn)。

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。