Tekil Metin Yanılsamasının Sonu: Spring AI 2.1.0-M1, MessagePart Mimarisi ve OpenAI /v1/responses Dönüşümü

Yazılım mühendisliği tarihinde en tehlikeli teknik borçlar, genellikle yanlış yazılmış algoritmalardan değil; güncelliğini yitirmiş veri yapılarından (data structures) doğar. Üretken yapay zeka (GenAI) ekosisteminin ilk yıllarında, büyük dil modelleriyle (LLM) kurulan iletişimi modellemek son derece basitti: Kullanıcı bir metin (String) gönderir, model de karşılığında bir metin dönerdi. Zamanla modeller görsel algılama (multimodality) ve fonksiyon çağırma (tool calling) yetenekleri kazandığında, sektördeki neredeyse tüm orkestrasyon çatıları aynı pratik yamayı tercih etti: Mesaj nesnesinin merkezinde yine tekil bir metin alanı bırakıldı, yanına ise toolCalls ve media adında iki ayrı yan liste (side lists) iliştirildi.

Ancak sınır modellerin (frontier models) çalışma doğası bu kaba soyutlamayı tamamen parçaladı. Bugün GPT-5.4, Claude veya Gemini tabanlı otonom bir ajan çalıştırdığınızda model tek bir metin bloğu üretmez. Önce içsel bir muhakeme (reasoning) yürütür, bu muhakemenin ortasında bir araç çağrısı (tool call) tetikler, aracın çıktısını okuduktan sonra ikinci bir muhakeme bloğu açar, araya iki farklı grafik görseliyle harmanlanmış metin parçaları yerleştirir ve bir sonraki turda doğrulama için geri gönderilmesi zorunlu olan kriptografik düşünce imzaları (thinking signatures / encrypted reasoning blobs) üretir.

Modelin çıktısını "düz metin + yan listeler" şeklindeki eski şablona sıkıştırdığınız anda, parçalar arasındaki kronolojik sıra ve nedensellik bağı (hangi muhakemenin hangi araç çağrısını tetiklediği) geri döndürülemez biçimde yok olur.

Spring AI ekibinin (Christian Tzolov, Soby Chacko, Dimitar Proynov ve katkıda bulunanların) Spring Boot 4.2 (4.2.0-M2) tabanı üzerinde yayınladığı Spring AI 2.1.0-M1 sürümü, tam olarak bu mimari kırılmayı onarmak üzere tasarlandı. Mesaj içeriklerini sıralı ve tipli parçalara bölen MessagePart mimarisi, OpenAI'ın yeni yeteneklerinin merkezi haline gelen /v1/responses uç noktası desteği ve önceden hesaplanmış vektörler için gelen VectorStore.upsert() yeteneği, kurumsal Java ekosisteminde yeni bir dönemin kapısını aralıyor.

"Mimari Not: Bir çerçevede (framework) veri modelini değiştirmek, yeni bir entegrasyon eklemekten çok daha zordur. Spring AI 2.1.0-M1'in getirdiği MessagePart dönüşümü, yüzeysel bir API makyajı değil; otonom ajanların düşünce zincirini (train of thought) ağ ve bellek katmanları boyunca kayıpsız taşıyabilmesi için atılmış temel bir veri yapısı devrimidir."

1. "Metin + Yan Listeler" Yanılsamasının Sonu: MessagePart Mimarisi

Spring AI 2.1.0-M1 öncesinde AssistantMessage, UserMessage ve ToolResponseMessage sınıfları, içeriklerini ayrık alanlarda tutuyordu. Eğer bir kullanıcı mesajında iki görselin arasına açıklayıcı metinler serpiştirmek isterseniz veya bir asistan yanıtında Muhakeme 1 -> Araç Çağrısı A -> Muhakeme 2 -> Araç Çağrısı B -> Nihai Metin şeklindeki iç içe geçmiş (interleaved) akışı korumak isterseniz, eski yapı tüm metinleri tek bir dizgede birleştirip araç çağrılarını ayrı bir listeye atarak kronolojiyi düzleştiriyordu.

Yeni mimaride AbstractMessage tabanlı mesaj sınıfları, içeriklerini sağlayıcının ürettiği veya çağrıyı yapanın (caller) tanımladığı sırayı birebir koruyan List<MessagePart> yapısı olarak tutuyor. MessagePart arayüzü, Java'nın mühürlü (sealed) hiyerarşi yetenekleriyle tasarlanmış durumda ve şu altı temel kayıt (record) tipine izin veriyor:

• TextPart: Model tarafından üretilen veya kullanıcı tarafından sağlanan düz metin parçalarını temsil eder.
• ReasoningPart: Yanıttan önce gelen veya yanıta eşlik eden model muhakemesini (thinking) tutar. İnsan tarafından okunabilir text ve sağlayıcı özeti olan summary alanlarının yanı sıra, sağlayıcıya geri gönderilmesi gereken şifreli veriyi taşıyan payload bileşenine sahiptir.
• ToolCallPart: Modelin talep ettiği tekil bir araç/fonksiyon çağrısını tam sırasıyla temsil eder.
• ToolResultPart: Çağrılan aracın ürettiği ve modele geri gönderilen sonucu barındırır.
• MediaPart: Görsel, ses veya PDF gibi çoklu ortam (multimodal) içeriklerini metinlerin arasına istediğiniz sırayla yerleştirmenizi sağlar.
• UnknownPart: Adaptörün henüz açıkça modellemediği sağlayıcıya özgü blokların ham JSON (raw JSON) verisini tutar.

Kriptografik Süreklilik: OpaquePayload ve UnknownPart

Modern sınır modellerde çok turlu (multi-turn) bir konuşma yürütürken en kritik sorun, sağlayıcıya özgü doğrulama verilerinin korunmasıdır. Örneğin Anthropic'in thinking signature yapısı, Google Gemini'nin thought signature verisi veya OpenAI /v1/responses uç noktasının ürettiği şifreli muhakeme içeriği (encrypted_content), bir sonraki turda modele tek bir biti bile değiştirilmeden (verbatim) geri gönderilmek zorundadır. Aksi takdirde sağlayıcı API'si isteği reddeder veya model önceki turdaki tüm muhakeme bağlamını kaybederek sıfırdan düşünmeye başlar.

Spring AI 2.1.0-M1 bu sorunu OpaquePayload ile çözüyor. Her MessagePart, sağlayıcıya ait olan ve değiştirilmeden geri oynatılması (replay) gereken veriyi @Nullable OpaquePayload payload() metoduyla taşıyabiliyor. Üstelik ReasoningPart üzerinde bulunan replayableTo(String provider) metodu, çoklu model (multi-model) yönlendirmesi yapılan mimarilerde hayat kurtarıyor: Örneğin Anthropic tarafından üretilmiş bir muhakeme parçası bir sonraki turda OpenAI'a gönderilmeye çalışıldığında, replayableTo("openai.responses") kontrolü bunun uyumsuz olduğunu tespit ediyor ve OpenAI API'sinin hatayla çökmesini engellemek için bu parçayı güvenli bir DEBUG loguyla atlayarak konuşmanın devam etmesini sağlıyor.

Ayrıca serileştirme (serialization) katmanında kullanılan tip ayırıcı (type discriminator), mevcut sürümün tanımadığı yeni bir blok tipiyle karşılaştığında hata fırlatmak yerine bunu otomatik olarak UnknownPart nesnesine dönüştürüyor. Böylece hiçbir veri sessizce yutulmuyor (silently dropped). Geriye dönük uyumluluk için korunan getText(), getMedia(), getToolCalls() ve yeni eklenen getReasoning() metotları ise artık bu sıralı MessagePart listesi üzerinde çalışan birer görünüm (view) olarak görev yapıyor.

2. OpenAI /v1/responses Desteği: Yeni Bir Uç Nokta Değil, Bir "Doğruluk" Zorunluluğu

OpenAI ekosisteminde uzun süredir /v1/chat/completions uç noktası standart kabul ediliyordu. Ancak OpenAI yeni nesil yeteneklerini artık Responses API (/v1/responses) üzerine inşa ediyor. Spring AI 2.1.0-M1, mevcut OpenAiChatModel yapısının yanına ikinci bir model uygulaması olarak OpenAiResponsesChatModel sınıfını ekledi.

Peki bir sistem mimarı neden mevcut Chat Completions yapısından Responses API'ye geçmeli? Spring AI dokümantasyonu bu soruya çok net bir mühendislik yanıtı veriyor: Yenilik (novelty) için değil, doğruluk (correctness) için.

GPT-5.4 Kısıtlaması ve Ajanik Döngüler

GPT-5.4 ve sonrasındaki güncel amiral gemisi modellerden itibaren, klasik Chat Completions uç noktası none dışındaki herhangi bir muhakeme eforu (reasoningEffort) ile araç çağırmayı (tool calling) aynı anda desteklememektedir. Eğer güncel bir sınır model üzerinde hem derin muhakeme yapan (medium veya high reasoning effort) hem de harici araçları çağıran bir ajan inşa ediyorsanız, Chat Completions uç noktası mimari olarak kilitlenir. /v1/responses uç noktası ise muhakeme ve araç çağrılarının aynı döngü içinde iç içe çalışmasını doğal olarak destekler.

Aşağıdaki mimari karşılaştırma tablosu, Spring AI içerisindeki iki OpenAI modelinin kritik farklarını özetlemektedir:

"Mimari Not: OpenAI'ın Responses API'si sunucu tarafında konuşma geçmişi saklama yeteneğine sahip olsa da, Spring AI ekibi OpenAiResponsesChatModel tasarımını bilinçli olarak durumsuz (deliberately stateless) kurgulamıştır. Her çağrı tüm Prompt içeriğini gönderir. Bu sayede mevcut ChatMemory, Advisor zincirleri ve Modüler RAG boru hatlarınız hiçbir değişikliğe uğramadan aynı şekilde çalışmaya devam eder."

Çok parçalı Akış ve Hibrit Model Yapılandırması

Spring AI 2.1.0-M1'de OpenAiResponsesChatModel ile çok parçalı girdi oluşturmak, şifreli muhakeme adımlarını okumak ve aynı uygulamada maliyet optimizasyonu için her iki OpenAI uç noktasını birlikte kullanmak son derece zarif bir API ile sunuluyor.

Aşağıdaki kapsamlı örnekte, önce Spring AI (Java) tarafında hibrit model yapılandırmasını ve sıralı MessagePart kullanımını, hemen ardından ise bu çok parçalı çıktıyı tüketen bir mikroservis ağ geçidinin (TypeScript) veri sözleşmesini inceleyebilirsiniz:

// 1. BÖLÜM: Spring AI 2.1.0-M1 (Java 21+ / Spring Boot 4.2) 
// Uygulama Katmanı: Hibrit Uç Nokta ve Sıralı MessagePart Kullanımı
/*
package com.tastutanlabs.ai.config;

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.chat.messages.*;
import org.springframework.ai.chat.model.ChatResponse;
import org.springframework.ai.chat.prompt.Prompt;
import org.springframework.ai.openai.OpenAiResponsesChatModel;
import org.springframework.ai.openai.OpenAiResponsesChatOptions;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.io.Resource;
import java.util.List;

@Configuration
public class HybridOpenAiConfig {

    // Not: Tek bir model kullanılacaksa application.properties içinde
    // spring.ai.openai.chat.api=responses tanımlamak yeterlidir.
    // Ancak ucuz sınıflandırma için Chat Completions, ajanlar için Responses API
    // aynı anda istenirse ikinci model Bean olarak tanımlanır:
    @Bean
    public OpenAiResponsesChatModel agentResponsesChatModel() {
        return OpenAiResponsesChatModel.builder()
            .options(OpenAiResponsesChatOptions.builder()
                .model("gpt-5.4")
                .reasoningEffort("high")
                .build())
            .build();
    }

    public AssistantMessage analyzeFinancialCharts(
            OpenAiResponsesChatModel responsesModel, 
            Resource q3Chart, 
            Resource q4Chart) {

        // Görseller ve metinler modelin görmesi gereken kesin sırayla dizilir:
        UserMessage orderedQuestion = UserMessage.builder()
            .part(TextPart.of("Aşağıdaki Q3 grafiğini baz alarak anomali noktalarını tespit et:"))
            .part(MediaPart.of(q3Chart))
            .part(TextPart.of("Şimdi Q4 grafiği ile karşılaştır ve araçları kullanarak risk skorunu hesapla:"))
            .part(MediaPart.of(q4Chart))
            .build();

        ChatResponse response = responsesModel.call(new Prompt(orderedQuestion));
        AssistantMessage output = response.getResult().getOutput();

        // Sıralı MessagePart listesi üzerinde tip güvenli (sealed) gezinme:
        for (MessagePart part : output.getParts()) {
            switch (part) {
                case ReasoningPart r -> {
                    System.out.println("[MUHAKEME]: " + r.text());
                    if (r.payload() != null && r.replayableTo("openai.responses")) {
                        System.out.println("Şifreli imza korundu: " + r.payload().type());
                    }
                }
                case ToolCallPart tc -> System.out.println("[ARAÇ ÇAĞRISI]: " + tc.toolCall().name());
                case TextPart t      -> System.out.println("[METİN]: " + t.text());
                case UnknownPart u   -> System.out.println("[HAM BLOK (HostedTool vb.)]: " + u.rawJson());
                default              -> {}
            }
        }
        return output;
    }
}
*/

// 2. BÖLÜM: BFF / API Gateway Katmanı (TypeScript)
// Spring AI 2.1.0-M1 MessagePart Serileştirme Sözleşmesi (Type Discriminator)
export interface OpaquePayload {
  readonly provider: "openai.responses" | "anthropic" | "gemini" | string;
  readonly type: "encrypted_content" | "thinking_signature" | string;
  readonly data: string; // Base64 veya şifreli blob, değiştirilmeden geri gönderilmelidir
}

export type MessagePart =
  | { type: "text"; text: string; payload?: OpaquePayload; attributes: Record<string, string> }
  | { type: "reasoning"; text: string | null; summary: string | null; payload: OpaquePayload | null; attributes: Record<string, string> }
  | { type: "tool_call"; id: string; name: string; arguments: string; payload?: OpaquePayload; attributes: Record<string, string> }
  | { type: "tool_result"; toolCallId: string; content: string; attributes: Record<string, string> }
  | { type: "media"; mimeType: string; dataUrl: string; attributes: Record<string, string> }
  | { type: "unknown"; rawJson: unknown; attributes: Record<string, string> };

export function reconstructAgentTranscript(parts: ReadonlyArray<MessagePart>): void {
  parts.forEach((part, index) => {
    if (part.type === "reasoning" && part.payload?.type === "encrypted_content") {
      console.log(`[Adım ${index}] Şifreli muhakeme bloğu doğrulandı (${part.payload.provider}).`);
    }
  });
}

Akış (Streaming) Mimarisi ve HostedTool Detayları

Akış (streaming) modunda çalışan modeller artık mesaj parçalarını artımlı (incremental) olarak teslim edebiliyor. Gelen her akış yığını (chunk), indekslenmiş kısmi parçalar (indexed partial parts) ve bir yanıt kimliği (response id) taşıyor; MessageAggregator ise bu parçaları arka planda birleştirerek eksiksiz MessagePart listesini yeniden inşa ediyor. Sadece getText() metodunu dinleyen mevcut aboneler (subscribers) eskisi gibi metin deltalarını almaya devam ederken, araç çağrıları yine tamponlanıp (buffered) tek seferde eksiksiz bir çağrı olarak teslim ediliyor.

Buna ek olarak, OpenAiResponsesChatOptions ile sunucu tarafında OpenAI tarafından çalıştırılan HostedTool yetenekleri (Web Search, File Search, Code Interpreter, Remote MCP ve görsel üretimi) doğrudan etkinleştirilebiliyor. Sunucu tarafında çalışan bu araçlar istemci tarafında bir ToolCallPart olarak görünmezler; bunun yerine tek bir istek içindeki aktiviteleri openai.responses.hosted_tool_calls altında özetlenir ve yanıt içindeki asıl kopyaları UnknownPart olarak ham JSON formatında saklanır.

3. RAG Boru Hatlarında Ayrışma: VectorStore.upsert() ve EmbeddedDocument

Spring AI 2.1.0-M1'e kadar tüm vektör veritabanı (VectorStore) uygulamalarında yapısal bir kısıtlama mevcuttu: Gömü (embedding) hesaplama işlemi doğrudan add(List<Document>) metodunun içinde gerçekleşiyordu. Eğer vektörlerinizi gece çalışan toplu iş (batch API) boru hatlarında önceden hesapladıysanız, başka bir veri bilimi ekibinin 파이프라인ından (pipeline) hazır vektörler alıyorsanız veya bir görsel/video üzerinden çok modlu (multimodal) bir modelle ürettiğiniz vektörleri doğrudan veritabanına yazmak istiyorsanız, Spring AI buna izin vermiyordu.

2.1.0-M1 sürümü, hesaplama ile depolama katmanını birbirinden ayıran yeni EmbeddedDocument kaydını ve VectorStore.upsert() metodunu tanıttı.

• İdempotent Yazım ve Kararlı Kimlikler (Stable IDs): upsert metoduna aynı belge kimliği (ID) ile tekrar veri gönderdiğinizde, mevcut satır kopyalanmak yerine güncellenir (replace). Bu sayede yarıda kesilen büyük veri aktarım (ingestion) işleri, mükerrer kayıt (duplicate) korkusu olmadan güvenle yeniden çalıştırılabilir.
• Boyut Doğrulaması ve Gözlemlenebilirlik: Veritabanına tek bir bayt bile yazılmadan önce, gönderilen her vektör yığını (batch) indeks genişliğine (index width / dimension) karşı kontrol edilir. Ayrıca AbstractObservationVectorStore üzerindeki doUpsert kancası sayesinde tüm UPSERT işlemleri Micrometer metriklerinde doğrudan izlenebilir.
• DocumentMetadata.CONTENT_REF Anahtarı: Vektörü bir görselden, videodan veya veritabanı satırına sığmayacak kadar büyük bir dosyadan üretilmiş belgeler için yeni bir CONTENT_REF üstveri anahtarı eklendi. Vektör deposu bu referansı (örneğin bir S3 URI'sini) okumaya çalışmaz; arama sonrasında asıl içeriği çözmek uygulama katmanına bırakılır.

Bu kilometre taşında upsert() metodu pgvector, Redis, Elasticsearch ve Qdrant tarafından desteklenmektedir; henüz bu özelliği uygulamayan diğer depolar çağrıldığında varsayılan olarak UnsupportedOperationException fırlatır.

Aşağıdaki Python betiği, gece çalışan bir GPU kümesinde önceden hesaplanan çok modlu gömülerin (pre-computed embeddings) ve harici S3 referanslarının (CONTENT_REF), Spring AI 2.1.0-M1 tabanlı bir indeksleme servisine nasıl aktarıldığını göstermektedir:

import uuid
import requests
import numpy as np
from typing import List, Dict, Any

# Gece çalışan Batch GPU Pipeline'ı: Gömüleri önceden hesaplar ve 
# Spring AI 2.1.0-M1 VectorStore.upsert() uç noktasına idempotent olarak yazar.

def generate_normalized_embedding(dim: int = 1536) -> List[float]:
    vec = np.random.randn(dim).astype(np.float32)
    return (vec / np.linalg.norm(vec)).tolist()

def build_upsert_payload(s3_uri: str, summary_text: str) -> Dict[str, Any]:
    # Deterministik UUID: İş yarıda kalıp tekrar çalıştırıldığında aynı ID üretilir,
    # böylece VectorStore.upsert() mükerrer kayıt açmak yerine satırı günceller.
    stable_doc_id = str(uuid.uuid5(uuid.NAMESPACE_URL, s3_uri))
    
    return {
        "document": {
            "id": stable_doc_id,
            "text": summary_text,
            "metadata": {
                "source": "overnight-multimodal-batch",
                # Spring AI 2.1.0-M1 DocumentMetadata.CONTENT_REF standardı:
                "content_ref": s3_uri
            }
        },
        "embedding": generate_normalized_embedding(1536)
    }

if __name__ == "__main__":
    batch_entries = [
        build_upsert_payload(
            s3_uri="s3://tastutanlabs-vault/schematics/turbine-v4.pdf",
            summary_text="Türbin V4 termodinamik basınç diyagramı ve akış şeması."
        )
    ]
    
    # Spring Boot 4.2 / Spring AI 2.1.0-M1 tarafında bu JSON doğrudan
    # vectorStore.upsert(List<EmbeddedDocument>) metoduna de-serileştirilir:
    print(f"Upsert için hazır kararlı belge ID: {batch_entries[0]['document']['id']}")

4. Üretim Ortamı (Production) Gerçekleri: 60 Saniyelik Zaman Aşımı Hatası ve Bilinmesi Gereken Kısıtlar

Bir kilometre taşı (milestone) sürümünü incelerken sadece yeni özelliklere odaklanmak büyük bir yanılgıdır; bazen tek satırlık bir hata düzeltmesi üretim ortamındaki en büyük yangını söndürür.

60 Saniyelik Gizli Zaman Aşımı (Timeout) Regresyonunun Çözümü

Eğer Spring AI 2.0.1 kullanıyorsanız ve 1 dakikadan uzun süren derin muhakeme veya uzun akış (streaming) çağrılarınız tam 60. saniyede OpenAIIoException: Stream failed hatasıyla kesiliyorsa, sorununuz ağınızda, yük dengeleyicinizde (load balancer) veya proxy katmanınızda değildi. 2.0.1 sürümünde her isteğe sabit kodlanmış (hard-coded) 60 saniyelik bir çağrı başı zaman aşımı eklenmişti ve bu değer spring.ai.openai.timeout ile spring.ai.openai.chat.timeout ayarlarınızı tamamen eziyordu. Spring AI 2.1.0-M1 bu regresyonu tamamen düzeltti; artık yapılandırdığınız zaman aşımı değerleri eksiksiz olarak uygulanıyor.

Bununla birlikte 2.1.0-M1 sürümünde gelen üç önemli düzeltme daha bulunuyor:

1. OpenAI Strict-Mode Araç Şemaları: MCP sunucularından veya elle yazılmış şemalardan gelen araç tanımlarında her nesne seviyesine otomatik olarak additionalProperties: false eklenerek (backfill) strict mode hataları giderildi.
2. AWS Bedrock Görsel Mesajları: Metin içermeyen ancak medya taşıyan Bedrock mesajlarında boş metin bloğu gönderilmesi engellendi (Converse API'sinin 400 Bad Request dönmesine neden oluyordu).
3. Stateless MCP Özelleştiricileri: Durumsuz (stateless) MCP sunucuları artık tüm sunucu bean'ini yeniden tanımlamaya gerek kalmadan McpStatelessSyncServerCustomizer ve McpStatelessAsyncServerCustomizer ile ince ayara tabi tutulabiliyor. Ayrıca TextReader içindeki dosya tanıtıcı (file descriptor) sızıntısı kapatıldı.

Mimarlar İçin Kritik Geçiş Notları (Caveats)

Spring AI 2.1.0-M1'i bugün test ve geliştirme ortamlarınıza entegre ederken şu iki mimari sınırı mutlaka göz önünde bulundurmalısınız:

1. Yerel MessagePart Desteğinin Kapsamı: 2.1.0-M1 sürümünde yalnızca yeni OpenAiResponsesChatModel mesaj parçalarını (MessagePart) doğal (native) olarak üretir ve tüketir. Diğer ChatModel uygulamaları (Anthropic, Gemini, Bedrock, klasik OpenAI vb.) 2.1.0-RC1 sürümünde bu yeni yapıya geçirilecektir.
2. Kalıcı Konuşma Hafızası (ChatMemory) Durumu: Mevcut durumda hiçbir kalıcı hafıza deposu (JDBC, Cassandra, Neo4j vb.) MessagePart hiyerarşisini veritabanına yazmamaktadır; tam konuşma yapısını (şifreli muhakeme blokları dahil) yalnızca InMemoryChatMemoryRepository korumaktadır. Kalıcı SessionRepository / ChatMemoryRepository uygulamalarının 2.1.0-M2 (ve Kasım 2026'da ayrı bir proje olarak çıkması planlanan yeni ajanik destek paketleri) ile birlikte tam MessagePart serileştirmesine kavuşması hedeflenmektedir. Ancak unutulmamalıdır ki, tek bir araç çağırma döngüsü (single tool loop) içindeki süreklilik her zaman korunur; çünkü ChatMemory bu döngünün dışında yer alır.

Sonuç: Yazılımcılar ve Sistem Mimarları İçin Çıkarımlar

Spring AI 2.1.0-M1, kurumsal Java dünyasının üretken yapay zeka entegrasyonlarında "basit sohbet botu" aşamasından "çok adımlı, durum koruyan otonom ajan" aşamasına geçişinin en somut mimari kanıtıdır.

Ekiplerinizde önümüzdeki çeyrek için yol haritası belirlerken şu üç adımı önceliklendirmenizi öneririm:

• Veri Sözleşmelerinizi Sıralı Parçalara Hazırlayın: Ön yüz (UI) veya API ağ geçidi katmanlarınızda asistan yanıtlarını tekil bir content: string alanı olarak bekleyen sözleşmeleri terk edin. Muhakeme adımlarını, araç çağrılarını ve metinleri sıralı bir dizi (MessagePart[]) olarak işleyen akış mimarilerine geçin.
• Ajan İş Yüklerini /v1/responses Üzerine Taşıyın: GPT-5.4 ve üstü modellerde muhakeme eforu ile araç çağrısını bir arada kullanmak için spring.ai.openai.chat.api=responses geçişini test ortamlarınızda hemen devreye alın.
• Vektör İndeksleme Boru Hatlarını Ayrıştırın: Büyük ölçekli RAG mimarilerinizde canlı uygulama sunucularını embedding hesaplama yükünden kurtarın; gömüleri asenkron iş hatlarında üretip VectorStore.upsert() ve kararlı belge kimlikleriyle (stable IDs) veritabanına yazan idempotent mimarilere yönelin.