Skip to main content

Spring AI RAG Source Code Analysis

Retrieval-Augmented Generation is the architectural pattern that transforms a general-purpose large language model into a domain-aware system capable of answering questions grounded in private, up-to-date data. In Spring AI, RAG is not a single component but a coordinated pipeline that spans document ingestion, chunking, embedding generation, vector storage, retrieval, and prompt augmentation. Understanding how this pipeline is implemented at the source code level is essential for senior engineers and architects who need to customize, debug, or performance-tune production RAG systems.

This chapter dissects the RAG architecture inside Spring AI. It traces the complete lifecycle of a RAG request, identifies the key interfaces and their implementations, and explains how the framework achieves portability and extensibility through clean separation of concerns. After reading this chapter, you will be able to navigate the RAG source code with confidence, understand where and how to extend it, and diagnose issues that arise in enterprise deployments.

What Is RAG in Spring AI?​

Retrieval-Augmented Generation (RAG) combines retrieval from an external knowledge base with the generative capabilities of a language model. Instead of relying solely on the model’s training data, a RAG system retrieves relevant documents at query time, injects them into the prompt as context, and instructs the model to base its answer on that provided information.

In Spring AI, RAG is more than a feature; it is a first-class architectural pattern realized as a composable pipeline. The framework provides building blocks for each stage of the RAG workflow—document readers, text splitters, embedding models, vector stores, and advisors—that can be assembled declaratively. The heavy lifting of retrieval and prompt augmentation is encapsulated in advisor components that plug into the ChatClient advisor chain, keeping the core business logic clean and independent of retrieval mechanics.

A deep understanding of the RAG source code matters for enterprise systems because production RAG pipelines are rarely turnkey. They require customization of chunking strategies, metadata filtering, ranking algorithms, and failure handling. The source code reveals the extension points and design decisions that enable these customizations without sacrificing framework integrity.

RAG in Spring AI Architecture​

RAG in Spring AI is implemented as a collaboration among several framework modules. The following diagram illustrates the layers involved in a typical RAG request.

Application – The user’s service or controller. It calls ChatClient with a user question, unaware that retrieval is happening.

ChatClient – The entry point that orchestrates the request. It holds a list of advisors, one of which is the RAG advisor (typically QuestionAnswerAdvisor). The advisor intercepts the request, performs retrieval, enriches the prompt, and then lets the model call proceed.

Prompt – The initial prompt containing the user question. The RAG advisor modifies this prompt by appending the retrieved context.

RAG Advisor / Advisor Chain – The core of the RAG logic. The advisor queries the vector store (using an embedding of the user question) to retrieve candidate documents. It may apply filtering, re-ranking, and then injects the document text into the prompt as a system or user message. The advisor ensures that the model is instructed to answer based solely on the provided context.

EmbeddingModel – Converts the user question into a vector for similarity search. The same embedding model must be used during ingestion to ensure vector space compatibility.

VectorStore – Stores document embeddings and metadata. The advisor calls similaritySearch to find the most semantically similar chunks to the query vector.

Retrieved Documents – The raw list of Document objects returned by the vector store, each containing the chunk text and metadata.

Prompt Augmentation – The advisor formats the retrieved chunks into the prompt, typically as a block of context with a system instruction like “Use the following documents to answer the question.”

ChatModel – The language model that generates the final answer based on the augmented prompt.

LLM Response – The final answer, grounded in the retrieved context.

This layering means the application code need not know about vector stores or retrieval strategies. The RAG advisor encapsulates that complexity, keeping the business logic provider- and store-agnostic.

Core Interfaces and Classes​

The following table lists the key components involved in a Spring AI RAG pipeline. Understanding their roles is the first step in reading the source code.

Class / InterfaceResponsibility
ChatClientEntry point for building and executing AI requests; holds the advisor chain.
PromptThe input to the model, composed of Message objects (system, user, assistant).
ChatModelAbstraction for invoking the language model; returns ChatResponse.
EmbeddingModelAbstraction for generating vector embeddings from text.
VectorStoreUnified interface for storing and querying document embeddings.
AdvisorInterceptor that can modify Prompt and ChatResponse.
QuestionAnswerAdvisorDefault RAG advisor implementation that orchestrates retrieval and prompt augmentation.
DocumentRepresents a text chunk with associated metadata.
DocumentReaderInterface for reading documents from various sources (PDF, JSON, etc.).
DocumentTransformerInterface for transforming documents, e.g., splitting, cleaning.
TokenTextSplitterA concrete DocumentTransformer that splits text by token count with overlap.
SearchRequestRequest object for vector similarity search, including query, filters, and top-K.
RetrievalAugmentationAdvisor(Alternative) advisor that focuses on prompt augmentation without embedding.

These classes span multiple packages, but they come together in the advisor chain to realize the full RAG lifecycle.

Source Code Structure​

The RAG functionality is distributed across several packages, reflecting the separation of concerns:

  • org.springframework.ai.chat.client – Contains ChatClient and the Advisor interface, which are the orchestration points for RAG.
  • org.springframework.ai.chat.client.advisor – Home of QuestionAnswerAdvisor and other advisor implementations. This is where the retrieval orchestration, prompt augmentation, and response post-processing logic resides.
  • org.springframework.ai.document – Defines Document, DocumentReader, and DocumentTransformer. The chunking strategies (TokenTextSplitter, etc.) live here.
  • org.springframework.ai.vectorstore – Contains the VectorStore interface and the SearchRequest model. Each vector database (PGVector, Milvus, etc.) provides a VectorStore implementation in its own starter module.
  • org.springframework.ai.embedding – Defines EmbeddingModel and related classes.

This separation means you can study the RAG advisor in isolation, or dive into the document processing pipeline without tracing through model adapters. The RAG advisor depends on VectorStore and EmbeddingModel only through their interfaces, preserving the framework’s portability.

RAG Execution Lifecycle​

The following sequence diagram traces a complete RAG request from the application to the final answer. It assumes documents have already been ingested and indexed.

Key lifecycle stages:

  1. Request interception – The ChatClient invokes the advisor chain. QuestionAnswerAdvisor is one of the registered advisors.
  2. Query embedding – The advisor extracts the user’s question (last user message) and passes it to EmbeddingModel.embed().
  3. Vector search – The resulting vector is used in VectorStore.similaritySearch(), along with a SearchRequest that specifies topK, similarity threshold, and optional metadata filters.
  4. Candidate processing – The advisor may re-rank, filter, or otherwise process the returned Document list.
  5. Prompt augmentation – The advisor injects the document text (and optionally metadata) into the Prompt. It typically adds a system message instructing the model to use the provided context.
  6. Model invocation – The enhanced prompt flows to ChatModel.call(). The model generates a response grounded in the provided documents.
  7. Response delivery – The ChatResponse is returned to the application, often with the source documents attached as metadata for citation.

Understanding this flow is essential for debugging retrieval quality issues: you can inspect the embedding, the search results, and the augmented prompt at each stage if you instrument the advisor.

Document Processing Pipeline​

Before retrieval can happen, documents must be ingested, normalized, and chunked. The document processing pipeline prepares the raw content that will later be stored in the vector database.

  • Document ingestion – DocumentReader implementations (e.g., JsonReader, PdfReader, TextReader) read from various sources and produce a list of Document objects. Each document contains the raw text and an initial set of metadata.
  • Document normalization – Cleaning steps remove noise: headers, footers, extraneous whitespace, and non-content elements. This is often done by custom DocumentTransformer implementations chained together.
  • Text extraction and transformation – For complex formats (PDFs, HTML), the reader parses the content and extracts a continuous text stream. Spring AI integrates with libraries like Apache Tika for these tasks.
  • Metadata attachment – Each document is annotated with metadata: source file, page number, document ID, creation date, access control tags. This metadata is critical for filtering during retrieval.
  • Preprocessing before chunking – Text is normalized to a common encoding and structure. This ensures that chunk boundaries align with logical units (paragraphs, sections) rather than cutting mid-word.

The quality of this preprocessing directly impacts retrieval accuracy. Poorly cleaned text produces noisy embeddings that degrade search relevance.

Chunking Architecture​

Chunking splits long documents into manageable pieces that can be embedded individually and retrieved independently. The architecture of chunking in Spring AI is centered around the DocumentTransformer interface and its implementations.

  • Why chunking exists – Embedding models have token limits (typically 512–8192 tokens). Documents longer than this limit cannot be embedded as a whole. Moreover, retrieving smaller, focused chunks improves precision.
  • Chunk size trade-offs – Larger chunks preserve more context but may dilute relevance. Smaller chunks are more precise but may miss critical surrounding information. The optimal size depends on the document structure and the use case.
  • Overlap strategy – TokenTextSplitter supports overlap between adjacent chunks. This ensures that sentences that sit on a boundary are not split, and that retrieval can capture cross-boundary context.
  • Metadata preservation – Each chunk inherits the parent document’s metadata, and additional chunk-specific metadata (chunk index, position) is added. This enables source tracking and filtering.
  • Chunk boundaries – The splitter tries to respect natural boundaries (sentence endings, paragraph breaks) by using separators and a recursive splitting strategy. The source code in TokenTextSplitter shows a configurable list of separators and a controlled splitting algorithm.
  • Impact on retrieval quality – The chunking strategy is one of the most impactful design decisions in a RAG system. It directly affects retrieval recall and the coherence of the context fed to the model. The source code exposes configuration options (chunk size, overlap, separators) that allow fine-tuning for specific document types.

Understanding the chunking implementation enables you to create custom DocumentTransformer implementations for domain-specific splitting (e.g., by legal clause or code function).

Embedding Pipeline​

Embeddings are the numeric bridge between text and vector search. The embedding pipeline in Spring AI is straightforward but architecturally significant.

  • How documents become vectors – During ingestion, each chunk is passed to EmbeddingModel.embed(String text), which returns a List<Double> or a float array. The vector, along with the chunk’s text and metadata, is stored in the VectorStore.
  • Role of EmbeddingModel – This interface abstracts the actual embedding service (OpenAI, Azure, Ollama, etc.). The ingestion code depends only on the interface, not on the provider.
  • Batch embedding considerations – For efficiency, documents can be embedded in batches. The source code supports batch calls via embed(List<String>) to reduce API overhead. The VectorStore.add(List<Document>) method often expects pre-computed embeddings.
  • Indexing versus query-time embedding – During retrieval, the user’s query is embedded using the same EmbeddingModel instance. Consistency between the ingestion embedding model and the query embedding model is essential; mismatched models lead to poor retrieval because the vectors exist in different semantic spaces.
  • Embedding consistency and model selection – The source code does not enforce this consistency; it is the architect’s responsibility. However, the advisor typically uses the same bean name or qualifier to ensure the correct model is injected.

A deep read of the EmbeddingModel interface and its implementations reveals how dimensions, normalization, and API parameters are handled. This knowledge is useful when comparing provider-specific embedding quality.

VectorStore Integration​

VectorStore is the backbone of retrieval. Its source code defines a clean abstraction that isolates application logic from database specifics.

  • Role of VectorStore in RAG – It stores document vectors and their metadata and provides similarity search capabilities. The advisor relies solely on this interface for retrieval.
  • Storing chunks and metadata – The add(List<Document>) method persists documents (with embeddings) to the underlying store. Implementations map the Spring AI Document to the database-specific schema.
  • Retrieving candidates – similaritySearch(SearchRequest) takes a query vector (or query string that triggers auto-embedding), topK, similarityThreshold, and filterExpression. It returns the most similar documents.
  • Metadata filtering – The SearchRequest can include a filter expression (e.g., author == 'John' && year >= 2023) that is applied before or during the vector search. This filtering is critical for multi-tenant and domain-specific retrieval.
  • Vendor independence – The abstraction means you can start with SimpleVectorStore (in-memory) for development and switch to PGVector or Pinecone for production by changing a starter dependency. The advisor code remains unchanged.

Reading the VectorStore interface and a few implementations (e.g., PgVectorVectorStore, MilvusVectorStore) illustrates the adapter pattern in action: each adapter translates the uniform SearchRequest into the native query dialect.

Retrieval and Ranking​

Once documents are embedded and stored, the retrieval stage selects the most relevant chunks for a given user query.

  • How retrieval works – The advisor calls VectorStore.similaritySearch with the embedded query. The database performs an approximate nearest neighbor (ANN) search and returns up to topK results.
  • Candidate selection – The advisor can further filter or truncate the results based on metadata or score thresholds. This post-filtering is done in Java and is transparent in the source code.
  • Similarity scoring – Each returned document includes a similarity score (e.g., cosine distance). The advisor may use this score to drop candidates below a threshold.
  • Reranking – Spring AI does not include a built-in re-ranker as part of the core framework, but the QuestionAnswerAdvisor can be subclassed or composed with a custom Advisor that calls an external re-ranking model (e.g., a cross-encoder). The extension point is the advisor’s beforeCall method, where you can manipulate the retrieved documents before augmentation.
  • Hybrid retrieval – Some VectorStore implementations support hybrid search (vector + keyword). The SearchRequest includes a filterExpression for keyword matching, and the store merges results. The advisor need not change; it receives the merged list.
  • Precision versus recall trade-offs – Increasing topK improves recall but may introduce noise. The source code exposes this parameter; understanding its effect on prompt length and model performance is a key architectural decision.

The retrieval logic in QuestionAnswerAdvisor is relatively concise, making it an excellent entry point for customizing the retrieval pipeline.

Prompt Augmentation​

Prompt augmentation is the final step before the model call. It transforms the retrieved documents into a format the model can understand and use.

  • How retrieved context is inserted – The advisor creates a new UserMessage (or SystemMessage) containing the concatenated text of the retrieved documents, often prefixed with a header like "Use the following context to answer the question." This message is added to the Prompt before the existing user message.
  • Prompt template design – The advisor uses configurable templates for the system instruction and the context format. The source code reveals template variables like {context} and {question} that are populated at runtime.
  • Context window constraints – The advisor must respect the model’s context window. If the retrieved documents exceed the token limit, the advisor truncates or reduces the number of chunks. The source code includes a maxContentLength parameter for this.
  • Grounding the answer – The system instruction explicitly tells the model to answer using only the provided context and to say "I don’t know" if the context is insufficient. This reduces hallucination.
  • Reducing hallucination risk – The combination of strict instructions, source attribution, and context clipping forms a defense-in-depth against fabrication.

By studying the prompt augmentation code, you can tailor the prompting strategy to your domain’s requirements—for example, adding citation formatting or multi-hop reasoning instructions.

Relationship with ChatClient​

ChatClient is the orchestrator that brings the RAG advisor to life. The advisor is registered via ChatClient.Builder.defaultAdvisors() or per-request advisors. When call() is invoked, ChatClient builds the initial prompt and then iterates through the advisor chain.

  • Request preparation – The ChatClient prepares a Prompt containing the user’s messages. If no RAG advisor is present, it proceeds directly to the model.
  • Advisor registration – RAG advisors are typically registered as @Bean instances and added globally. The ChatClient builder allows ordering, which is critical if multiple advisors (e.g., logging, memory, RAG) must interact correctly.
  • Context injection – The RAG advisor modifies the prompt before passing it to the next advisor or the model. The ChatClient does not know or care about this modification.
  • Response generation flow – After all advisors have executed, the ChatClient calls ChatModel.call(). The response may also pass through response-oriented advisors on the way back to the caller.

The source code of ChatClient shows a clean delegation pattern. Understanding its flow is essential for debugging advisor interactions and ensuring that RAG and other cross-cutting concerns do not conflict.

Relationship with Prompt​

Prompt is the data structure that carries the conversation. The RAG advisor reads the user’s question from the prompt and writes the augmented context back into it.

  • Templates – The advisor uses a PromptTemplate to generate the system instruction and context block. This template is configurable, allowing engineers to adjust wording without changing code.
  • User input – The advisor typically extracts the last UserMessage text as the query. It may also consider conversation history if memory is involved.
  • Context assembly – Retrieved documents are formatted according to the template and inserted as a new message. The order of messages matters: system instruction first, then context, then user question, then conversation history.
  • Formatting retrieved content – Documents may be concatenated with separators, their metadata appended, or structured as numbered lists. The advisor code includes formatting logic that can be overridden.

Reading the prompt augmentation code shows how to construct effective prompts programmatically, a skill transferable to any AI framework.

Relationship with EmbeddingModel​

Embeddings tie the ingestion and retrieval halves of RAG together. The EmbeddingModel is used both during indexing and at query time.

  • Indexing embeddings – When documents are ingested, the EmbeddingModel generates vectors that are stored in the VectorStore.
  • Query embeddings – The RAG advisor embeds the user question on the fly.
  • Model consistency – Using the same EmbeddingModel instance (or a model from the same provider family) ensures that query vectors are compatible with stored vectors. The source code does not enforce this, but dependency injection can be configured to share a single bean.
  • Impact on RAG quality – The choice of embedding model significantly affects retrieval relevance. The source code makes no assumptions; it simply calls embed(). The architect must select an appropriate model and ensure it is the same across ingestion and query.

Understanding the EmbeddingModel interface and its use in QuestionAnswerAdvisor shows how the framework separates model concerns from retrieval logic.

Relationship with VectorStore​

VectorStore is the retrieval engine. The RAG advisor depends on it entirely for fetching candidate documents.

  • Abstraction layer – The advisor calls similaritySearch(SearchRequest). It does not know whether the store is PGVector, Milvus, or a mock for testing.
  • Implementation independence – This allows swapping stores without changing the advisor or application code. The source code demonstrates true portability.
  • Operational considerations – The advisor must be aware of store-specific limitations (e.g., filter syntax, latency). These are abstracted behind the SearchRequest filter expression.
  • Retrieval quality and latency – The advisor configures topK and similarityThreshold, which directly affect result quality. The source code shows these as configurable properties.

Studying the integration between QuestionAnswerAdvisor and VectorStore reveals how Spring AI achieves database-agnostic retrieval while still allowing fine-tuning.

Relationship with Advisors​

Advisors are the extension mechanism that makes RAG possible without modifying the core framework. QuestionAnswerAdvisor is just one implementation of the Advisor interface.

  • Request interception – The Advisor.next() method wraps the call to the next advisor or the model. The RAG advisor performs retrieval and prompt augmentation inside this method.
  • Retrieval orchestration – The advisor owns the retrieval logic: embed query, call vector store, process results, augment prompt. This is all executed within the advisor’s beforeCall phase.
  • Prompt enrichment – The advisor modifies the AdviseContext to pass an enriched prompt downstream.
  • Response post-processing – After the model call, the advisor can intercept the ChatResponse to add source citations or metadata. The QuestionAnswerAdvisor may attach the retrieved documents to the response.
  • Ordering of advisors – If multiple advisors are registered, the order determines whether memory is applied before retrieval, or logging after. The source code of ChatClient shows a list of advisors executed in insertion order.

By implementing a custom Advisor, engineers can introduce alternative retrieval strategies, logging, or security filters without touching the framework.

Design Patterns Used​

The RAG subsystem employs several classic patterns:

  • Pipeline Pattern – The overall RAG flow (ingest → chunk → embed → store → retrieve → augment → generate) is a pipeline. Each stage is a discrete component that can be replaced independently.
  • Strategy Pattern – Different chunking strategies (TokenTextSplitter, custom DocumentTransformer) and retrieval strategies (pure vector, hybrid) can be plugged in.
  • Adapter Pattern – VectorStore implementations adapt various databases to a common interface. The EmbeddingModel does the same for embedding providers.
  • Advisor Pattern – The advisor chain is an interceptor pipeline that allows cross-cutting RAG logic to be inserted transparently.
  • Repository Pattern – VectorStore acts as a repository for document embeddings, abstracting storage details.
  • Dependency Injection – All components (advisor, vector store, embedding model) are injected via the Spring context, enabling easy substitution and testing.

These patterns make the RAG codebase modular, testable, and extensible—hallmarks of good Spring architecture.

Extension Points​

For teams that need to go beyond the defaults, Spring AI RAG offers clear extension points:

  • Document ingestion – Implement custom DocumentReader for proprietary formats.
  • Chunking strategy – Create custom DocumentTransformer for domain-specific splitting (e.g., by legal sections, code functions).
  • Embedding strategy – Use a different embedding model per document type by qualifying beans.
  • Retrieval strategy – Subclass QuestionAnswerAdvisor to override document selection, or implement a completely new Advisor that combines multiple vector stores.
  • Ranking strategy – Inject a re-ranker as a separate advisor or inside a custom advisor’s beforeCall.
  • Prompt augmentation – Override the template and formatting logic in the advisor.
  • Vector storage implementation – Implement VectorStore for a new database.
  • Advisor behavior – Compose advisors to create complex pipelines (e.g., RAG + memory + content filtering).

All these extensions are possible without modifying framework code, preserving upgradeability.

Enterprise RAG Best Practices​

From a source code perspective, the following practices help build robust enterprise RAG systems:

  • Metadata design – Define a clear metadata schema and enforce it during ingestion. The vector store’s filter expression relies on this metadata.
  • Document quality – Invest in preprocessing. Garbage in, garbage out applies to embeddings too.
  • Chunking discipline – Test different chunk sizes and overlaps against real queries. Use a systematic evaluation set.
  • Retrieval evaluation – Measure recall and precision with a labeled dataset. Use the source code’s configurability to run experiments.
  • Access control – Apply metadata filters to ensure users only see documents they are authorized to view. Integrate with Spring Security.
  • Latency optimization – Profile embedding and search latency. Consider caching embeddings or using faster index types.
  • Observability – Instrument the advisor with Micrometer to track retrieval latency, number of documents retrieved, and token usage. The source code can be wrapped with custom advisors for logging.
  • Incremental indexing – Design the ingestion pipeline to handle updates and deletes without full re-indexing. Use upsert operations in VectorStore.
  • Testing strategy – Use SimpleVectorStore (in-memory) and mock EmbeddingModel for unit tests; use integration tests with a real database for retrieval quality.

The source code’s modularity makes these best practices achievable without brittle workarounds.

Error Handling and Failure Modes​

Production RAG pipelines encounter several failure modes. The source code reveals how to handle them gracefully.

  • Empty retrieval results – If no documents pass the similarity threshold, the advisor may choose to skip augmentation and let the model answer from general knowledge, or return a controlled “I don’t know.” The behavior can be configured.
  • Low-quality chunks – If the retrieved chunks are irrelevant, the model may still produce a plausible but incorrect answer. Mitigation: adjust threshold, use re-ranking, or apply post-retrieval validation.
  • Embedding mismatches – If the query embedding model differs from the ingestion model, search results will be poor. The source code cannot detect this; it must be prevented via configuration.
  • Vector store errors – Network issues, timeouts, or auth failures must be caught. The advisor should handle exceptions and optionally fall back to a non-RAG response.
  • Prompt overflow – If retrieved context exceeds the model’s context window, truncation occurs. The source code’s maxContentLength setting mitigates this, but must be set appropriately.
  • Malformed document inputs – Document readers should handle corrupted files gracefully, logging errors and continuing.
  • Stale indexes – Documents change; the index must be refreshed. The source code provides no automatic invalidation; it must be orchestrated by the application.

Robust systems wrap the advisor in a try-catch and use Spring Retry for transient errors. The source code’s design allows such wrapping without modifying the advisor itself.

Performance Considerations​

RAG performance is multifaceted, involving ingestion throughput, retrieval latency, and model token consumption.

  • Ingestion throughput – Embedding generation is often the bottleneck. Batching and concurrency can improve speed. The source code’s add(List) methods support batch operations.
  • Embedding cost – Large-scale indexing can be expensive. Monitor token usage and consider caching embeddings for unchanged chunks.
  • Retrieval latency – The vector database’s index type (HNSW, IVF) and the network round-trip are primary factors. Filter expressions add complexity. Profile with representative query loads.
  • Storage overhead – Vectors consume significant memory/disk. Dimension reduction or quantization may be necessary at scale, though the abstraction layer hides this.
  • Token consumption – More retrieved chunks mean longer prompts and higher model costs. Tune topK and maxContentLength to balance answer quality and cost.
  • Batching strategies – For high query throughput, consider batching embedding requests or using asynchronous advisors.
  • High-scale retrieval – Use sharded vector databases and deploy the advisor service with horizontal scaling. The stateless advisor design (all state in the store) supports this.

The source code exposes configuration knobs (topK, threshold, maxContentLength) that directly influence these performance dimensions. Profiling and tuning these parameters is part of the production engineer’s role.

Source Code Reading Guide​

To master the Spring AI RAG internals, follow this reading order:

  1. Advisor interface – Understand the contract and the execution model (next, aroundCall).
  2. QuestionAnswerAdvisor – The primary implementation. Study how it integrates with VectorStore, EmbeddingModel, and prompt augmentation.
  3. VectorStore interface and SearchRequest – Understand the retrieval contract.
  4. Document, DocumentReader, DocumentTransformer – Grasp the ingestion and chunking abstractions.
  5. TokenTextSplitter – Concrete chunking logic; see how separators, overlap, and token counting work.
  6. ChatClient advisor chain – Trace how advisors are invoked and ordered.
  7. EmbeddingModel interface – Note the minimal API; no RAG-specific logic.
  8. Provider-specific VectorStore implementations – Pick PGVector or Milvus and see how the adapter pattern connects.

To trace a request: set breakpoints in QuestionAnswerAdvisor.advise(), VectorStore.similaritySearch(), and ChatModel.call(). Send a test query and follow the data flow.

RAG touches nearly every part of the Spring AI framework. The following source code chapters provide deeper insight into the components involved:

Summary​

Spring AI’s RAG implementation is a well-architected pipeline that spans multiple modules but converges in the advisor chain. The source code reveals a clean separation of concerns: document processing, chunking, embedding, vector storage, retrieval, and prompt augmentation are each encapsulated in their own abstractions. The QuestionAnswerAdvisor (or a custom advisor) orchestrates retrieval and context injection, keeping application logic clean and portable.

The key architectural concepts—pipeline composition, advisor-based interception, interface-driven portability—enable the framework to support a wide range of RAG patterns while remaining extensible. Senior engineers who understand these internals can customize every stage of the pipeline, diagnose failures with precision, and design RAG systems that meet enterprise demands for reliability, security, and performance.

We recommend continuing with the Advisor Source Code Analysis to fully understand the interceptor mechanism that makes RAG so elegantly integrated, and then VectorStore Source Code Analysis to appreciate the database abstraction that powers retrieval.