Якщо ти Java-розробник — AI-інтеграція у твоїх проєктах рано чи пізно стане реальністю. Клієнти питають про чат-боти, семантичний пошук і автоматизацію на основі LLM. І перше що ти шукаєш — як це зробити в Spring Boot без переписування всього застосунку і без вивчення Python.
Spring AI відповідає саме на це питання. У цій статті — пояснення : що це таке, як працює і чи варто витрачати на це час у 2026 році.
📚 Зміст статті
- 📌 Чому AI більше не тільки для Python-розробників
- 📌 Що таке Spring AI — пояснення без жаргону
- 📌 Чим Spring AI відрізняється від прямого виклику OpenAI API
- 📌 Які провайдери підтримуються: OpenAI, Ollama, Anthropic, Gemini
- 📌 Що можна побудувати зі Spring AI прямо зараз
- 📌 Для кого Spring AI — і де він надлишковий
- ❓ Часті питання (FAQ)
- ✅ Висновки
🎯 Чому AI більше не тільки для Python-розробників
До 2024 року більшість AI-інструментів і фреймворків були Python-орієнтованими: LangChain, LlamaIndex, Hugging Face Transformers. Java-розробники або писали HTTP-клієнти вручну, або шукали обхідні шляхи. У 2025 році ситуація змінилася — Spring AI 1.0 GA вийшов 20 травня 2025 і закрив цю прогалину.
Spring AI робить для AI-інтеграції те, що Spring Data зробив для баз даних: абстрагує деталі провайдера і дозволяє зосередитися на бізнес-логіці.
Що змінилося конкретно? Кілька речей одночасно.
LLM API стали стандартизованими
OpenAI випустила специфікацію API яку всі наслідують. Ollama, Mistral, DeepSeek, OpenRouter — всі сумісні з OpenAI-форматом. Це означає: один клієнт працює з десятками провайдерів. Spring AI використав цю стандартизацію і побудував на ній уніфікований шар абстракції для Java.
Відкриті моделі наздогнали комерційні
Llama 3.3, Qwen 2.5, Mistral, DeepSeek R1 — моделі які запускаються локально через Ollama і дають результат порівнянний з GPT-4 на більшості практичних задач. Для Java-розробника це означає: можна будувати AI-функції без залежності від зовнішніх платних API і без передачі корпоративних даних у хмару.
Spring Boot 3.x і Java 17+ — зрілий стек
Spring AI підтримує Java 17+ і Spring Boot 3.3+ — стек який вже є в більшості корпоративних проєктів. Нічого нового встановлювати не потрібно — додаєш залежність і починаєш.
- ✔️ Spring AI 1.0 GA вийшов травень 2025 — стабільний API
- ✔️ Spring AI 1.1 вийшов листопад 2025 — MCP, reasoning, Advisors API
- ✔️ Понад 850 покращень і фіксів за один release cycle
- ✔️ Активна спільнота і підтримка від Broadcom/VMware
Висновок: 2025–2026 — це момент коли AI-інтеграція для Java стала такою ж природною як підключення бази даних через Spring Data.
🎯 Що таке Spring AI — пояснення без жаргону
Spring AI — це фреймворк від команди Spring який дозволяє підключати AI-моделі до Spring Boot застосунків через єдиний уніфікований API. Один і той самий код працює з OpenAI, Ollama, Anthropic і Gemini — провайдер змінюється через конфігурацію, не через переписування сервісів.
Аналогія: Spring Data дозволяє писати
userRepository.findById(id)— і не думати чи під капотом PostgreSQL чи MongoDB. Spring AI дозволяє писатиchatClient.prompt().user(question).call().content()— і не думати чи під капотом OpenAI чи локальний Ollama.
За описом офіційного GitHub-репозиторію, Spring AI — це Application Framework для AI-інженерії. Ключова ідея: портабельність. Код написаний під Ollama локально запускається без змін з OpenAI на продакшні — достатньо змінити конфігурацію.
Архітектура: три рівні абстракції
Spring AI побудований у три шари які відповідають за різні рівні роботи з AI. Розберемо кожен конкретно.
Рівень 1 — Model API: базові інтерфейси
Офіційна документація Spring AI описує перший рівень як набір базових інтерфейсів і абстракцій:
- ✔️ ChatModel — низькорівневий інтерфейс для розмовних
моделей.
ChatModel.call(Prompt)— базовий виклик. Безпосередньо з ним рідко працюєш — для цього є ChatClient. - ✔️ EmbeddingModel — перетворює текст у числовий вектор.
embeddingModel.embed("текст")повертаєList<Double>. Один інтерфейс для OpenAI text-embedding-3, Ollama nomic-embed-text і будь-якого іншого провайдера. - ✔️ ImageModel — генерація зображень через DALL-E або інші провайдери.
- ✔️ ToolDefinition / ToolCallback — function calling, виклик зовнішніх інструментів з моделі.
Рівень 2 — VectorStore: єдиний інтерфейс для векторних баз
Spring AI надає
уніфікований інтерфейс VectorStore для роботи з векторними базами.
Два основних методи:
// Додати документи — ембединги генеруються автоматично
vectorStore.add(List<Document> documents);
// Пошук по схожості
List<Document> results = vectorStore.similaritySearch(
SearchRequest.query("семантичний пошук")
.withTopK(5)
.withSimilarityThreshold(0.7)
);
Той самий код працює з pgvector, Redis, Chroma, Pinecone і ще десятком
провайдерів. Зміна vector store — одна залежність в pom.xml
і рядок в конфігурації.
Рівень 3 — ChatClient: головний інтерфейс для розробника
GitHub Spring AI описує ChatClient
як Fluent API для роботи з AI Chat моделями — ідіоматично схожий на
WebClient і RestClient які ти вже знаєш.
Це основний інтерфейс з яким ти працюєш 90% часу:
// Базовий виклик
String answer = chatClient.prompt()
.user("Поясни що таке pgvector")
.call()
.content();
// З системним промптом і streaming
Flux<String> stream = chatClient.prompt()
.system("Ти Java-архітект. Відповідай стисло і з прикладами коду.")
.user(question)
.stream()
.content();
// Structured output — відповідь прямо у Java record
record BlogSummary(String title, List<String> keywords, String category) {}
BlogSummary summary = chatClient.prompt()
.user("Проаналізуй: " + articleText)
.call()
.entity(BlogSummary.class);Advisors: готові патерни поверх ChatClient
Baeldung детально описує Advisors API: це механізм перехоплення і збагачення промптів — chain-патерн який додає контекст, пам'ять або логування до кожного запиту. Три готових Advisor які вирішують найчастіші задачі:
- ✔️ QuestionAnswerAdvisor — RAG одним рядком. Автоматично робить similarity search у VectorStore і додає релевантний контекст у промпт перед відповіддю моделі.
- ✔️ MessageChatMemoryAdvisor — пам'ять розмови.
Зберігає і відновлює контекст між запитами через
InMemoryChatMemoryабо persistent storage. - ✔️ VectorStoreChatMemoryAdvisor — семантична пам'ять. Зберігає історію розмови у VectorStore для пошуку по змісту, а не тільки по останніх повідомленнях.
// RAG + пам'ять розмови одночасно
ChatClient.create(chatModel)
.prompt()
.advisors(
new QuestionAnswerAdvisor(vectorStore),
new MessageChatMemoryAdvisor(chatMemory)
)
.user(question)
.call()
.content();Document Pipeline: від сирого тексту до vector store
Spring AI включає готовий пайплайн для підготовки документів до індексації:
- ✔️ Document Readers — читають PDF
(
PagePdfDocumentReader), HTML (WebDocumentReader), Markdown, текст - ✔️ TokenTextSplitter — розбиває документ на чанки з урахуванням токенів, а не символів. Розмір чанка і overlap налаштовуються.
- ✔️ Document — базова одиниця з полями
text,metadataі автоматично згенерованими ембедингами при додаванні у VectorStore
// Повний пайплайн індексації — 4 рядки
var reader = new PagePdfDocumentReader("classpath:article.pdf");
var splitter = new TokenTextSplitter();
List<Document> chunks = splitter.split(reader.get());
vectorStore.add(chunks); // ← ембединги генеруються автоматичноSpring Boot Auto-configuration
Кожен провайдер має свій стартер який auto-configure всі необхідні біни.
Додаєш залежність — і ChatClient.Builder,
EmbeddingModel, VectorStore вже доступні
для інʼєкції без жодного @Bean методу:
@RestController
public class AiController {
// Spring AI auto-configure — просто інʼєктуєш
private final ChatClient chatClient;
public AiController(ChatClient.Builder builder) {
this.chatClient = builder.build();
}
@GetMapping("/ask")
public String ask(@RequestParam String question) {
return chatClient.prompt()
.user(question)
.call()
.content();
}
}Висновок: Spring AI — це не обгортка навколо OpenAI SDK. Це три рівні абстракції — Model API, VectorStore і ChatClient — плюс готові патерни через Advisors і Document Pipeline. Разом вони вирішують більшість практичних AI-задач без написання інфраструктурного коду вручну.
🎯 Чим Spring AI відрізняється від прямого виклику OpenAI API
Прямий виклик OpenAI API через RestTemplate або WebClient прив'язує весь твій код до одного провайдера. Spring AI абстрагує провайдера — і ти отримуєш портабельність, готові патерни і Spring Boot інтеграцію замість написання HTTP-клієнтів вручну.
Писати HTTP-клієнт до OpenAI вручну у 2026 — це як писати JDBC-запити вручну коли є Spring Data JPA. Технічно можна, але навіщо.
Чому vendor lock-in — це реальна проблема
Уяви: ти написав сервіс який викликає OpenAI API напряму. Через місяць OpenAI підняв ціни вдвічі — і ти хочеш перейти на Anthropic або локальний Ollama. Що потрібно змінити? Всі HTTP-запити, всі моделі відповідей, всі парсери, всі тести — фактично переписуєш сервіс заново.
Або інший сценарій з реальної практики: локально для розробки
використовуєш Ollama щоб не витрачати кредити API,
а на продакшні — OpenAI або OpenRouter. Без абстракції
це або два різних сервіси, або купа if/else
на профілі. Spring AI вирішує це на рівні конфігурації.
Конкретне порівняння коду
Без Spring AI — прямий виклик OpenAI:
// HTTP клієнт вручну — прив'язаний до OpenAI
@Service
public class AiService {
private final RestTemplate restTemplate;
private final String apiKey = System.getenv("OPENAI_API_KEY");
public String ask(String question) {
var headers = new HttpHeaders();
headers.set("Authorization", "Bearer " + apiKey);
headers.setContentType(MediaType.APPLICATION_JSON);
var body = Map.of(
"model", "gpt-4o",
"messages", List.of(Map.of("role", "user", "content", question))
);
var response = restTemplate.postForObject(
"https://api.openai.com/v1/chat/completions",
new HttpEntity<>(body, headers),
Map.class
);
// парсинг відповіді вручну...
return ((List<Map>) response.get("choices"))
.get(0).get("message").toString();
}
}Що не так з цим кодом крім обсягу? Він жорстко прив'язаний до: формату запиту OpenAI, URL ендпоінту, структури відповіді і навіть назви моделі. Зміна провайдера = переписування класу.
Зі Spring AI — той самий результат, але портабельно:
// Spring AI — один код для будь-якого провайдера
@Service
public class AiService {
private final ChatClient chatClient;
public AiService(ChatClient.Builder builder) {
this.chatClient = builder.build();
}
public String ask(String question) {
return chatClient.prompt()
.user(question)
.call()
.content();
}
}
І в application.yml вибираєш провайдера —
код сервісу не чіпаєш взагалі:
# Локально — Ollama (безкоштовно, офлайн)
spring.ai.model.chat=ollama
spring.ai.ollama.chat.model=llama3.3:8b
# Продакшн — OpenRouter (безкоштовний tier)
spring.ai.model.chat=openai
spring.ai.openai.base-url=https://openrouter.ai/api
spring.ai.openai.chat.options.model=meta-llama/llama-3.3-8b-instruct:freeЩо ще дає Spring AI порівняно з ручним підходом
| Можливість | Ручний HTTP клієнт | Spring AI |
|---|---|---|
| Зміна провайдера | Переписування сервісів | Один рядок в yml |
| Structured output | JSON парсинг вручну | .entity(MyClass.class) |
| Streaming | SSE клієнт вручну | .stream().content() |
| RAG | Весь пайплайн вручну | QuestionAnswerAdvisor |
| Пам'ять розмови | Управління контекстом вручну | MessageChatMemoryAdvisor |
| Vector store | SQL/HTTP запити вручну | VectorStore інтерфейс |
| Retry/timeout | Вручну через Resilience4j | Auto-configuration |
| Метрики | Вручну | Micrometer out-of-the-box |
| Unit тести | Mock RestTemplate | MockChatModel |
Висновок розділу: Spring AI не просто скорочує код — він вирішує архітектурну проблему vendor lock-in і дає готові патерни для складних AI-сценаріїв які без фреймворку займають тижні розробки.
