Spring AI frente a LangChain4j: configuración, primer endpoint y estilo de diseño
Comparamos Spring AI y LangChain4j en arquitectura, starters de Spring Boot, configuración y un primer endpoint REST de chat, y vemos qué estilo encaja con tu equipo.
Las listas de funciones dicen poco. Lo que de verdad quieres saber de un framework es qué tal se trabaja con él tras unas semanas de desarrollo, y eso la documentación no lo responde. Así que imagina un equipo que arranca un proyecto nuevo con Spring Boot y prueba tanto Spring AI como LangChain4j. La comparación de abajo repasa la arquitectura, la configuración del proyecto, el primer endpoint de IA y la experiencia diaria del desarrollador. Las dos bibliotecas resuelven el mismo problema, pero lo abordan de forma muy distinta.
Dos filosofías de arquitectura
La diferencia de diseño condiciona casi todas las decisiones posteriores, así que conviene mirarla antes de escribir código.
La arquitectura de Spring AI
Spring AI sigue un patrón que cualquier desarrollador de Spring Boot reconocerá.
Spring Boot Application
│
ChatClient API
│
Spring AI Abstractions
│
OpenAI | Gemini | Ollama | Claude | Azure
│
Large Language Model
El framework se sitúa entre tu aplicación y el proveedor de IA. En lugar de llamar directamente a OpenAI o Gemini, tu código habla con las abstracciones de Spring AI. Eso compensa de varias maneras. Pasar de Gemini a OpenAI normalmente no toca tu código de negocio: solo cambia la configuración. Es la misma idea por la que Spring Data te deja cambiar de base de datos sin reescribir la lógica de los repositorios.
Por qué este enfoque resulta familiar
Para quien lleva años creando aplicaciones con Spring Boot, la estructura es familiar desde el primer momento. La inyección de dependencias está en el centro, los beans se configuran solos y los ajustes viven en application.yml. No parece que estés aprendiendo un framework de IA, sino un starter más de Spring, y para los equipos empresariales eso es una gran ventaja.
La arquitectura de LangChain4j
LangChain4j tiene otra mentalidad. No construye todo alrededor de una abstracción central, sino que te da varios bloques reutilizables.
Spring Boot Application
│
AI Service Interface
│
┌──────────┬─────────────┬──────────────┐
│ │ │ │
Chat Model Memory Tools Retriever
│
OpenAI / Gemini / Ollama
Además, no oculta los conceptos de IA, los expone. Trabajarás directamente con estos componentes:
- Modelos de chat y modelos de embeddings
- Memoria de chat
- Servicios de IA
- Recuperadores de contenido y proveedores de herramientas
Cada uno tiene una única tarea clara, y tú los ensamblas en tu propio pipeline de IA. Al principio puede parecer trabajo extra. Pero cuando la aplicación crece, el diseño modular empieza a tener sentido.
Configurar Spring AI
Empezar con Spring AI es rápido. Funciona igual que añadir Spring Data JPA o Spring Security: incorporas el starter correspondiente.
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-starter-model-gemini</artifactId>
</dependency>
Después pones tu clave de API en la configuración.
spring:
ai:
vertex:
ai:
gemini:
project-id: your-project
location: us-central1
# OR
spring:
ai:
openai:
api-key: ${OPENAI_API_KEY}
A partir de ahí, Spring Boot crea los beans necesarios por ti. Sin clases factoría, sin cableado manual y sin builders: todo queda listo para la inyección de dependencias. Para alguien que trabaja con Spring, esto resulta de lo más natural.
Configurar LangChain4j
LangChain4j también trae starters de Spring Boot, y la configuración apenas cambia.
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-open-ai-spring-boot-starter</artifactId>
</dependency>
La configuración es casi igual.
langchain4j:
open-ai:
chat-model:
api-key: ${OPENAI_API_KEY}
model-name: gpt-4o-mini
De nuevo, Spring Boot crea los beans automáticamente, así que en un proyecto Spring Boot existente la experiencia es casi la misma que con Spring AI. Pero LangChain4j añade una opción más: puedes prescindir por completo de los starters y montarlo todo a mano.
ChatLanguageModel model = OpenAiChatModel.builder()
.apiKey(apiKey)
.modelName("gpt-4o-mini")
.build();
Esa flexibilidad es una ventaja real. En una aplicación Java sin más o en Quarkus no cambia nada, porque la biblioteca no está atada a Spring.
Un primer endpoint de IA
Ahora viene lo interesante. Con cada framework se construye el mismo endpoint REST, que recibe una pregunta y devuelve una respuesta generada.
La versión con Spring AI
@RestController
@RequestMapping("/chat")
public class ChatController {
private final ChatClient chatClient;
public ChatController(ChatClient.Builder builder) {
this.chatClient = builder.build();
}
@GetMapping
public String chat(@RequestParam String message) {
return chatClient.prompt()
.user(message)
.call()
.content();
}
}
Queda sorprendentemente limpio. La API fluida recuerda al WebClient de Spring y cada paso se lee con naturalidad.
prompt()
↓
user()
↓
call()
↓
content()
Quien haya usado las API fluidas de Spring seguramente entenderá la idea de un vistazo.
La versión con LangChain4j
@RestController
@RequestMapping("/chat")
public class ChatController {
private final ChatLanguageModel model;
public ChatController(ChatLanguageModel model) {
this.model = model;
}
@GetMapping
public String chat(@RequestParam String message) {
return model.generate(message);
}
}
Esta es aún más corta. En lugar de montar un prompt con un builder, hablas directamente con el modelo de lenguaje. Hay menos ceremonia y el código parece casi la llamada a un servicio Java cualquiera.
¿Cuál es más fácil?
Los desarrolladores lo preguntan a menudo, y la respuesta honesta es que los dos son excelentes. Para una aplicación de chat básica no hay un ganador claro. Ambos necesitan pocas líneas, se integran en Spring Boot, configuran sus propias dependencias y producen código limpio y legible.
La diferencia no está en la cantidad de código, sino en cómo evoluciona la aplicación. Spring AI quiere que todo pase por un ChatClient, y a medida que el proyecto crece vas añadiendo alrededor de ese cliente Advisors, memoria, llamadas a herramientas, RAG y observabilidad.
LangChain4j va en sentido contrario. En vez de hacer crecer un cliente central, te anima a crear servicios de IA especializados, de modo que la aplicación acaba con este aspecto:
CustomerSupportAgent
DocumentAssistant
CodeReviewAgent
EmailGenerator
MeetingSummarizer
Cada uno es su propia interfaz Java con una tarea bien definida. Para aplicaciones de IA grandes, este enfoque es muy elegante. Pero si tu proyecto ya sigue los patrones de servicio tradicionales de Spring, Spring AI te resultará más familiar. Ninguno es objetivamente mejor, porque están pensados para formas de pensar distintas.
Lo que enseña construir el mismo chatbot dos veces
Un primer chatbot con Spring AI se siente como escribir otra aplicación Spring Boot más. Hay pocas sorpresas: todo está donde esperas, la inyección de dependencias funciona como siempre, la configuración sigue en application.yml y en una hora puedes tener un endpoint de IA funcionando.
El mismo chatbot con LangChain4j deja otra primera impresión. En lugar de integrar una API, empiezas a pensar en diseñar un asistente inteligente. Es un matiz sutil, pero cambia cómo organizas el código. LangChain4j te empuja desde el primer día a separar prompts, herramientas, memoria y recuperación en componentes reutilizables, mientras que Spring AI te deja añadir esas capacidades de una en una según evoluciona la aplicación. Ninguna de las dos filosofías está equivocada. La elección correcta depende del tipo de software que construyes y de cómo le gusta a tu equipo estructurar el código.
Dónde se separan de verdad
Hasta aquí las diferencias son pequeñas. La divergencia real aparece cuando construyes funciones de IA para producción, como salidas estructuradas, llamadas a herramientas, generación aumentada por recuperación (RAG) y agentes. Ahí es donde cada framework muestra sus verdaderos puntos fuertes y donde elegir entre ellos empieza a importar mucho más.