Spring AI, RAG y agentes: cómo construir aplicaciones Java con inteligencia artificial real

Un LLM (Large Language Model) es un modelo estadístico que predice el siguiente token a partir de los tokens anteriores. Un token es una unidad de texto — aproximadamente tres cuartos de una palabra en español —, y el modelo aprende durante el entrenamiento qué tokens tienden a seguir a qué otros en función de patrones lingüísticos. Nada más. No hay base de datos detrás, no hay motor de búsqueda y no hay razonamiento simbólico: hay una distribución de probabilidad sobre el vocabulario, condicionada por el texto que ya ha visto.

Tratar al LLM como una base de datos es el origen del 80% de los problemas. Si le pides un dato concreto que no estaba en su entrenamiento o que no le has dado en la conversación, no te dirá "no lo sé" — completará con lo más plausible. Eso es lo que se llama alucinación, y no es un bug del modelo, es la consecuencia natural de su naturaleza generativa.

Cada modelo tiene una ventana de contexto: el número máximo de tokens que puede procesar en una sola petición, sumando entrada y salida. Esa ventana es finita (4k, 32k, 128k, 1M según el modelo) y todo lo que el modelo necesite saber para responder tiene que caber dentro, junto con la pregunta del usuario y la instrucción del sistema. Diseñar bien una aplicación con IA consiste, en buena parte, en decidir qué entra y qué se queda fuera de esa ventana en cada momento.

Los LLM son stateless. Cada petición empieza de cero: el modelo no recuerda quién eres, qué te dijo ayer ni qué documentos te ha enseñado. Si la aplicación parece tener memoria, es porque el backend está enviándole los mensajes anteriores en cada llamada. Si parece conocer la documentación interna, es porque el backend la está recuperando y adjuntando al prompt. Si parece actuar sobre un CRM, es porque el backend está orquestando esa acción tras una solicitud del modelo.

Esto convierte el backend en el verdadero responsable de la inteligencia percibida. Allí viven las conversaciones, los usuarios, los permisos, el estado, las fuentes de información y las herramientas. Allí se decide qué contexto recibe el modelo en cada momento, cómo se persiste lo que importa y cómo se controlan los costes, la latencia y la trazabilidad. Sin esa capa, la IA se queda en un chat aislado sin valor de negocio.

Para proyectos serios en empresa, Spring Boot sigue siendo una base sólida para construir esta capa. Aporta inyección de dependencias, configuración por perfiles, transacciones, seguridad, observabilidad con Micrometer, integraciones probadas con bases de datos y colas, y un modelo de despliegue conocido. Sobre esa base, Spring AI añade las primitivas específicas de IA sin obligar a salir del ecosistema.

Spring AI permite integrar modelos de IA en aplicaciones Java y Spring Boot de forma estructurada. Es el módulo oficial del ecosistema Spring para consumir LLMs, embeddings y vector stores, y abstrae las diferencias entre proveedores (OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Vertex AI, Ollama) bajo interfaces estables.

La pieza central es el ChatClient: un cliente conversacional que recibe un prompt, una conversación previa y, opcionalmente, un conjunto de herramientas, y devuelve la respuesta del modelo. Cambiar de proveedor de modelo no implica reescribir código de aplicación, sino ajustar la configuración. Esto da margen para experimentar con varios modelos y elegir el más adecuado por calidad, coste y latencia en cada caso de uso.

Alrededor del ChatClient, Spring AI ofrece varias piezas que importan en producción. ChatMemory persiste la conversación entre llamadas — en memoria, en base de datos relacional o en un store dedicado — y permite recuperar el histórico por un ConversationId que identifica unívocamente una conversación de un usuario. Los Advisors son interceptores que envuelven cada llamada al modelo y aplican lógica transversal: añadir contexto recuperado de RAG, registrar trazas, aplicar guardrails, reintentar con un modelo alternativo si el primero falla.

• ChatClient: API unificada para hablar con cualquier proveedor de LLM, con soporte para prompts, conversación, structured output y tools.
• ChatMemory: capa de memoria conversacional con varias implementaciones (in-memory, JDBC, Redis) accesible por ConversationId.
• Advisors: interceptores que envuelven la llamada al modelo para aplicar RAG, logging, retries, guardrails o cualquier lógica transversal.
• VectorStore: abstracción sobre PGVector, Qdrant, Pinecone, Redis, Elasticsearch o Chroma para indexar y recuperar embeddings.
• Tools: métodos Java expuestos al modelo como funciones que puede invocar para obtener datos o ejecutar acciones.
• Observabilidad: métricas de tokens, latencia y coste expuestas a Micrometer y compatibles con Prometheus, Grafana o Datadog.

RAG (Retrieval-Augmented Generation) permite que un modelo genere respuestas usando información propia de la empresa sin reentrenarlo. La idea es sencilla: antes de llamar al modelo, el backend busca fragmentos de documentación interna relevantes para la pregunta y los adjunta al prompt como contexto. El modelo responde apoyándose en esos fragmentos, no en su conocimiento general.

El flujo tiene cinco etapas reconocibles. Primero, extracción: se leen las fuentes (PDFs, HTML, Confluence, SharePoint, base de datos, tickets) y se normaliza el texto. Segundo, fragmentación: cada documento se divide en chunks del tamaño adecuado para que un grupo de fragmentos quepa en la ventana de contexto. Tercero, embeddings: cada chunk se transforma en un vector mediante un modelo de embeddings, capturando su significado semántico. Cuarto, almacenamiento en un vector store. Quinto, recuperación: ante una consulta, se busca por similitud vectorial los chunks más relevantes y se inyectan en el prompt.

En Spring AI, este flujo se construye con el VectorStore y un Advisor de tipo QuestionAnswerAdvisor (o uno propio). PGVector es la opción natural cuando ya hay Postgres en producción y el volumen está por debajo de varios millones de vectores; Qdrant entra cuando el volumen, la latencia o la presión sobre la base relacional exigen una base vectorial dedicada. La elección no es ideológica: depende del stack actual y del caso de uso real.

1. 1. Extracción

   leer las fuentes (PDFs, HTML, wikis, base de datos) y normalizar el texto en una representación común con metadatos.

2. 2. Fragmentación

   dividir cada documento en chunks coherentes — por sección, por encabezado o por tamaño — para que el retrieval devuelva piezas útiles.

3. 3. Embeddings

   convertir cada chunk en un vector usando un modelo de embeddings (text-embedding-3, BGE, E5, modelos especializados por idioma).

4. 4. Indexación

   cargar los vectores y los metadatos (origen, permisos, fecha, tenant) en el vector store, conservando el texto original para citar la fuente.

5. 5. Recuperación

   ante una consulta, buscar por similitud vectorial los chunks más relevantes, aplicar filtros por metadatos y devolverlos al ChatClient como contexto.

El RAG básico funciona en escenarios sencillos, pero se queda corto cuando las consultas son ambiguas, multi-paso o tocan dominios técnicos con vocabulario específico. Tres técnicas amplían su alcance sin cambiar la arquitectura general.

Query rewriting reescribe la pregunta original antes de buscar, ajustándola al lenguaje real de los documentos: convierte una consulta coloquial en una más formal, expande siglas, elimina ruido. Query expansion genera variantes de la consulta — sinónimos, reformulaciones, descomposiciones en sub-preguntas — y agrega los resultados de cada una para mejorar la cobertura. Reranking aplica un segundo modelo, más pequeño y especializado, que reordena los top-N chunks recuperados para priorizar los realmente relevantes antes de pasarlos al LLM.

RAG agéntico es la evolución natural cuando el retrieval simple no basta. En lugar de buscar una sola vez al inicio, el agente decide en cada paso si necesita más información, evalúa si lo recuperado es suficiente y, si no lo es, vuelve a buscar con una consulta refinada. Esto cambia el control del flujo: el modelo deja de ser un pasivo que recibe contexto y pasa a ser un actor que pide contexto cuando lo necesita.

• Query rewriting: el backend transforma la pregunta del usuario en una versión más adecuada para el retrieval antes de buscar.
• Query expansion: se generan varias variantes de la consulta y se combinan los resultados para aumentar la cobertura semántica.
• Reranking: un modelo secundario reordena los chunks recuperados según relevancia real frente a la pregunta original.
• RAG agéntico: el agente decide cuándo buscar, evalúa los resultados y vuelve a iterar si la información no es suficiente.
• Retrieval híbrido: combinar búsqueda vectorial con búsqueda por palabra clave (BM25) suele mejorar la precisión en dominios técnicos.

Un agente de IA puede decidir qué herramienta necesita usar para completar una tarea. En la práctica, es un LLM al que se le ha dado un objetivo, un conjunto de herramientas disponibles y libertad para decidir, paso a paso, cuál usar y con qué argumentos. El backend ejecuta la herramienta solicitada, devuelve el resultado al modelo y el ciclo se repite hasta que el agente considera completada la tarea o se agotan los límites configurados.

Tool Calling es el mecanismo que conecta el LLM con métodos Java reales. En Spring AI, una tool es un método anotado o registrado como tal en el ChatClient: el modelo recibe la descripción de la herramienta (nombre, qué hace, qué parámetros espera) y, cuando decide usarla, devuelve una llamada estructurada con los argumentos. El backend es quien ejecuta el método y devuelve el resultado al modelo. El LLM no ejecuta nada directamente: solicita una acción, y la lógica crítica permanece bajo el control del backend.

Esa distinción es fundamental para sistemas reales. El modelo puede pedir que se consulte un CRM, que se cree un ticket, que se envíe un email o que se actualice un registro — pero el backend valida quién lo pide, si tiene permisos para esa acción, si los parámetros están dentro de límites razonables y si la operación cumple con la política de la empresa. La seguridad no se delega al modelo; se aplica en el método Java que ejecuta la acción.

1. 1. Usuario

   envía una petición al backend ("Mándale el último informe al cliente X").

2. 2. LLM

   recibe la petición junto con la lista de tools disponibles y decide qué herramienta necesita usar y con qué argumentos.

3. 3. Llamada a función

   el modelo devuelve una solicitud estructurada (nombre de la tool, parámetros) en lugar de texto final.

4. 4. Método Java

   el backend valida permisos, ejecuta el método correspondiente (buscar cliente, recuperar informe, enviar email) y obtiene un resultado.

5. 5. Resultado al LLM

   el backend devuelve el resultado al modelo en una nueva llamada, junto con el historial de la conversación.

6. 6. Respuesta final

   el modelo, ya con el resultado disponible, genera la respuesta en lenguaje natural para el usuario.

Durante un tiempo, todo el foco de las aplicaciones con IA estuvo en el prompt: cómo redactar la instrucción perfecta para obtener la mejor respuesta. Sigue siendo importante — un prompt bien diseñado mejora consistencia y reduce alucinaciones —, pero no es suficiente. En proyectos empresariales reales, la mayoría de problemas no se resuelven cambiando una frase del prompt, sino diseñando bien qué información llega al modelo y cuándo.

Context Engineering es la disciplina de diseñar el contexto completo que recibe el modelo en cada interacción: la instrucción del sistema, la memoria conversacional, los fragmentos recuperados por RAG, los resultados de las tools usadas, las restricciones de seguridad y los metadatos relevantes. Incluye decidir qué se persiste, qué se descarta, qué se resume y qué se envía al modelo en cada llamada. También incluye gestionar el ciclo de vida del contexto: cuándo expira una conversación, cómo se limpia, cómo se audita.

Esta capa toca a la vez memoria, RAG, herramientas, seguridad, estado, usuarios y permisos. No es un detalle de implementación: es la diferencia entre un chat aislado que responde con coherencia durante diez minutos y un sistema que sostiene conversaciones útiles a lo largo de semanas, sobre datos propios, respetando permisos y manteniendo costes bajo control.

• Prompt Engineering: redactar la instrucción del sistema y la pregunta para guiar al modelo dentro de una sola llamada.
• Context Engineering: diseñar el contexto completo que recibe el modelo en cada interacción, gestionando memoria, RAG, tools, seguridad y estado.
• Memoria: qué se conserva entre llamadas, en qué store, con qué TTL y cómo se resume cuando crece demasiado.
• RAG: qué fragmentos se recuperan, con qué filtros de metadatos y qué prioridad sobre la memoria conversacional.
• Tools: qué herramientas tiene disponibles el modelo, con qué permisos por usuario y con qué auditoría por llamada.
• Ciclo de vida: cuándo expira una conversación, cómo se limpia el contexto, cómo se traza una respuesta hasta sus fuentes.

Para tener una referencia clara, esta es la diferencia operativa entre los cuatro enfoques que aparecen mezclados en cualquier conversación sobre IA. No son sustitutos: cada uno cubre una capa distinta del problema, y los proyectos serios combinan varios.

• Prompt Engineering — qué cubre: la instrucción que recibe el modelo. Cuándo basta: tareas autocontenidas, sin datos propios ni acciones, sin memoria entre llamadas. Limitaciones: el modelo solo sabe lo que sabía en su entrenamiento.
• RAG — qué cubre: aportar al modelo conocimiento propio de la empresa. Cuándo encaja: cuando hay documentación interna que el modelo debe usar para responder. Limitaciones: no permite actuar sobre sistemas, solo informar.
• Agentes con Tool Calling — qué cubre: que el modelo pueda decidir qué herramientas usar y ejecutar acciones a través del backend. Cuándo encaja: cuando hay que consultar varios sistemas o ejecutar operaciones reales. Limitaciones: mayor coste, mayor latencia y necesidad estricta de guardrails.
• Context Engineering — qué cubre: la disciplina completa que orquesta prompt, memoria, RAG, tools, seguridad y ciclo de vida del contexto. Cuándo encaja: cualquier aplicación seria con IA en producción. Limitaciones: requiere diseño backend explícito y observabilidad desde el día uno.

Si solo te llevas unos puntos del artículo, que sean estos. Son las afirmaciones que repetimos en cada proyecto donde acompañamos a un equipo Java a llevar IA a producción.

• Un LLM predice tokens. No es base de datos, no recuerda y no decide por sí mismo — todo eso se diseña en el backend.
• Spring AI permite integrar modelos de IA en aplicaciones Java y Spring Boot con ChatClient, ChatMemory, Advisors y VectorStore.
• RAG permite que un modelo genere respuestas usando información propia de la empresa sin reentrenarlo.
• Un agente de IA puede decidir qué herramienta necesita usar para completar una tarea, mientras el backend mantiene el control de la lógica crítica.
• Tool Calling conecta el LLM con métodos Java reales: el modelo solicita la acción, el backend la ejecuta con permisos y trazabilidad.
• Context Engineering — no solo Prompt Engineering — es lo que hace viable una aplicación con IA real en producción.