Yapay Zekadan Geçerli JSON Çıktısı Nasıl Alınır?

Büyük dil modellerinden (LLM) kurumsal yazılım mimarilerine veri aktarırken karşılaşılan en temel sorun, olasılıksal metin çıktılarının deterministik sistemlerle uyumsuzluğudur. Doğru yöntemler ve şema kısıtlamaları kullanılmadığında modeller eksik parantezler, geçersiz kaçış karakterleri veya şema dışı anahtarlar üreterek entegrasyon boru hatlarını kesintiye uğratır.

Büyük dil modellerinin kurumsal iş süreçlerine entegrasyonunda en sık karşılaşılan teknik darboğaz, modelin doğal dil çıktısını doğrudan ilişkisel veya NoSQL veritabanlarına, mikroservis API'lerine ve analitik boru hatlarına aktarma gereksinimidir. Yapay Zekadan Geçerli JSON Çıktısı Nasıl Alınır? sorusu; yalnızca temel bir istem yazma meselesi değil, aynı zamanda şema doğrulaması (schema validation), gramer kısıtlamalı örnekleme (constrained decoding), fonksiyon çağırma (tool use/function calling) ve hata toleransı (fallback) mimarilerinin bir arada kurgulanmasını gerektiren teknik bir disiplindir. Bu rehberde; OpenAI Structured Outputs, Anthropic Claude Tool Use, Pydantic, Instructor ve Outlines gibi modern araçlarla sıfır hata toleranslı veri boru hatlarının nasıl inşa edileceğini, gecikme süresi (latency) ve token maliyetlerini optimize etme stratejileriyle birlikte ele alıyoruz.

Yapay Zeka Entegrasyonlarında Yapılandırılmış Veri ve JSON Çıktısının Rolü

Büyük dil modelleri (LLM), doğaları gereği deterministik veri tabanları gibi çalışmaz; bir sonraki en olası belirteci (token) tahmin eden olasılıksal sinir ağlarıdır. Doğal dildeki esneklik yaratıcı yazarlık veya serbest sohbet için ideal olsa da, üretim ortamındaki bir ERP sistemi, CRM entegrasyonu veya ödeme geçidi için kabul edilemez bir kararsızlık yaratır. Kurumsal yazılım mimarilerinde veri alışverişinin omurgası olan JSON (JavaScript Object Notation), katı sözdizimi kurallarına ve kesin tip tanımlarına dayanır. Yapay zeka ile arka uç servisleri arasında güvenilir bir köprü kurabilmek, serbest metin üretiminin bu katı kurallarla sınırlandırılmasını zorunlu kılar.

Modern yazılım geliştirme pratiklerinde LLM'ler artık yalnızca soru-cevap motoru olarak değil; belge sınıflandırıcı, metin özetleyici, varlık çıkarıcı (Named Entity Extraction) ve otonom karar verici ajanlar olarak konumlandırılmaktadır. Bu görevlerin tamamında çıktının bir sonraki yazılım katmanına iletilebilmesi için programatik olarak ayrıştırılabilir (parse edilebilir) olması şarttır. Bir modelin yanıtının geçerli bir JSON dizesi olmaması, zincirleme mikroservis çağrılarında SyntaxError fırlatılmasına, iş süreçlerinin kilitlenmesine ve veri tutarsızlıklarına neden olur.

Yapılandırılmamış Metinden Deterministik Veriye Geçiş

Yapay zeka modelleri eğitildikleri devasa veri kümeleri nedeniyle doğal dildeki karmaşık ve dağınık bilgiyi anlama konusunda üstün yeteneğe sahiptir. Müşteri e-postaları, çağrı merkezi transkriptleri, teknik raporlar veya fatura taranmış görüntüleri yapılandırılmamış (unstructured) verinin tipik örnekleridir. Geleneksel kural tabanlı algoritmalar bu tür verilerden anlam çıkarmakta yetersiz kalırken, LLM'ler bu bilgiyi kolayca işleyebilir.

Ancak bu gücün operasyonel faydaya dönüşmesi, elde edilen içgörünün deterministik (belirli, tahmin edilebilir ve katı tipli) bir şemaya dökülmesine bağlıdır. Örneğin serbest bir müşteri şikayet metninden musteri_id, duygu_skoru, kategori, oncelik_derecesi ve eylem_plani gibi alanların kesin veri tipleriyle (integer, float, enum, array) çıkarılması gerekir. Bu dönüşüm, işletmelerin manuel operasyonel maliyetlerini düşürürken veri ambarlarına temiz veri akışı sağlar.

Kararsız Çıktılar ve Parser Hatalarının İş Süreçlerine Maliyeti

Üretim ortamında çalışan bir LLM uygulamasında meydana gelen JSONDecodeError veya şema uyuşmazlığı hataları, doğrudan finansal kayba ve itibar erozyonuna yol açar. Geliştiricilerin karşılaştığı tipik parser hataları şunlardır:

• Markdown Formatlama Kirliliği: Modelin JSON nesnesini \\\json ve \\\ gibi kod blokları içine sarması veya öncesinde "İşte istediğiniz JSON çıktısı:" gibi selamlama cümleleri eklemesi.

• Sözdizimi İhlalleri: Son elemandan sonra konulan fazladan virgüller (trailing commas), tek tırnak kullanımı ('key' yerine "key" zorunluluğu) veya kapatılmamış süslü parantezler.

• Kaçış Karakteri (Escape Character) Problemleri: Metin içi çift tırnakların, ters eğik çizgilerin (\) veya satır sonu karakterlerinin (\n) JSON standardına uygun şekilde kaçırılmaması.

• Eksik veya Değişken Alanlar: İstemde açıkça belirtilmesine rağmen, modelin bazı çağrılarda fiyat alanını price olarak adlandırması ya da zorunlu alanları tamamen atlaması.

Bu tür hatalar, asenkron kuyruk yapılarının (Celery, RabbitMQ, Kafka) tıkanmasına, veritabanı yazma operasyonlarının başarısız olmasına ve son kullanıcıya kesinti olarak yansıyan sistem krizlerine dönüşür.

Halüsinasyon Riski ve Şema Dışı Alan Üretimi

Büyük dil modellerinin en belirgin karakteristiklerinden biri halüsinasyon, yani gerçekte var olmayan bilgileri güvenle üretme eğilimidir. Yapılandırılmış veri taleplerinde halüsinasyon genellikle şema dışı anahtar (key) icat etme veya önceden tanımlanmış enum (sabit değerler) listesine uymayan string değerler üretme şeklinde kendini gösterir.

Örneğin, sipariş durumunu yalnızca ["HAZIRLANIYOR", "KARGODA", "TESLIM_EDILDI", "IPTAL"] değerlerinden biri olarak kabul eden bir sisteme modelin SEVK_BEKLIYOR gibi geçersiz bir enum değeri döndürmesi, veritabanı kısıtlamalarını ihlal eder. Modelin olmayan öznitelikleri JSON içerisine eklemesi veya alanların veri tiplerini rastgele değiştirmesi (örneğin ID alanını bazen string bazen integer döndürmesi), sıkı tip denetimli (strongly-typed) kurumsal dillerde (Java, C#, Go, TypeScript) runtime çökmelerine neden olur.

---

Büyük Dil Modellerinden JSON Almanın 4 Temel Yöntemi

LLM'lerden JSON formatında veri almak için kullanılan teknikler, yapay zeka ekosisteminin evrimine paralel olarak gelişmiştir. İlk dönemlerde yalnızca istem mühendisliğine (prompt engineering) dayanan zayıf yöntemler kullanılırken, günümüzde token örnekleme olasılıklarını çekirdek seviyesinde manipüle eden deterministik yaklaşımlar standart hale gelmiştir. Bu yöntemler güvenilirlik, esneklik, gecikme süresi ve maliyet açısından farklı avantajlar sunar.

1. Sistem Talimatları (System Instructions) ve İstem Mühendisliği

En ilkel ancak modelden bağımsız çalışan yöntem, modelin sistem talimatına (system instruction) ve kullanıcı istemine (user prompt) katı kurallar yerleştirmektir. Bu yaklaşımda modelin dil yeteneğine güvenilir; herhangi bir API kısıtlaması uygulanmaz.

Başarılı bir prompt mühendisliği stratejisinde şu bileşenler yer almalıdır:

1. Format Zorlaması: Modele yanıtında kesinlikle selamlama, Markdown işareti (\\\`json) veya açıklama metni eklememesi emredilir.

2. Few-Shot Örnekleme: İstem içerisine en az 2-3 adet girdi-çıktı çifti eklenerek modelin beklenen şemayı taklit etmesi sağlanır.

3. Açık Şema Tanımı: Çıktının sahip olması gereken anahtarlar ve bunların tipleri istem içinde net bir biçimde tanımlanır.

Sen yalnızca geçerli JSON nesneleri üreten bir veri dönüşüm asistanısın.
Markdown blokları (```json), giriş metni veya kapanış açıklaması KESİNLİKLE kullanma.
Çıktın doğrudan JSON.parse() işlemine girecektir.

Beklenen Şema:
{
  "musteri_id": "string (UUID)",
  "skor": 0.0,
  "onay": true,
  "etiketler": ["string"]
}

Bu yöntem genel amaçlı açık kaynaklı modellerde veya API parametresi desteği olmayan eski modellerde kullanılabilir. Ancak üretim ortamları için tek başına yetersizdir; yük altındaki modellerde periyodik olarak şema ihlalleri meydana gelir.

2. Yerleşik JSON Modu (JSON Mode) ve API Parametreleri

Model sağlayıcıları (OpenAI, Mistral, Together AI vb.), istem mühendisliğinin yetersizliğini gidermek adına API seviyesinde response_format: { "type": "json_object" } parametresini kullanıma sunmuştur.

JSON Modu aktif edildiğinde, modelin ürettiği metnin geçerli bir JSON sözdizimine (valid JSON syntax) sahip olması garanti edilir. Model arka planda süslü parantez ile başlar ve geçerli bir parantez kapanışıyla biter. Ancak bu modun kritik bir sınırlaması vardır: Sözdizimi doğruluğu şema doğruluğu anlamına gelmez. Model geçerli bir JSON üretir, fakat talep ettiğiniz urun_fiyati anahtarını fiyat olarak değiştirebilir veya zorunlu bir alanı tamamen unutabilir. Bu nedenle JSON Modu kullanılırken istem içinde JSON kelimesinin açıkça geçmesi ve şemanın tarif edilmesi zorunludur.

3. Yapılandırılmış Çıktılar (Structured Outputs) ve Şema Tanımlama

OpenAI tarafından tanıtılan ve endüstri standardı haline gelen Structured Outputs, olasılıksal dil modellerini %100 deterministik şema uyumuna zorlayan en gelişmiş yöntemdir. Bu yaklaşımda API'ye doğrudan standart bir JSON Schema veya Pydantic sınıfı gönderilir ve strict: true bayrağı tanımlanır.

Model, çıktı üretirken (token decoding aşamasında) belirlenen şemayı bir kısıtlı durum makinesine (Constrained Finite State Machine) dönüştürür. Modelin şema dışındaki herhangi bir token üretme olasılığı matematiksel olarak sıfıra indirilir. Böylece:

• Zorunlu alanların (required fields) atlanması imkansızdır.

• Şemada tanımlanmamış fazladan anahtarlar üretilemez (additionalProperties: false).

• Tip uyumsuzlukları (string beklenen yere integer yazılması vb.) tamamen engellenir.

• Sözdizimi hataları teorik olarak sıfıra iner.

4. Fonksiyon Çağırma (Function Calling / Tool Use) Yöntemi

Anthropic Claude gibi Structured Outputs parametresini ayrı bir mod olarak sunmayan sağlayıcılarda, en güvenilir JSON alma yöntemi Tool Use (Araç Kullanımı / Fonksiyon Çağırma) mekanizmasıdır. Bu yöntemde modele bir API fonksiyonu veya araç tanımı verilir ve modelden bu aracı çalıştırması için gerekli parametreleri JSON olarak hazırlaması istenir.

Anthropic ekosisteminde tool_choice: {"type": "tool", "name": "kayit_olustur"} parametresi kullanılarak modelin serbest metin yanıtı vermesi engellenir ve doğrudan aracın JSON parametrelerini üretmesi zorunlu kılınır. Bu yöntem, modelin dikkatini (attention) doğrudan veri çıkarma hedefine odakladığı için hem doğruluğu artırır hem de şema uyumunu maksimize eder.

---

Programatik Doğrulama: Pydantic, Instructor ve Outlines Ekosistemi

API seviyesindeki kısıtlamalar ne kadar güçlü olursa olsun, kurumsal yazılım mimarilerinde her zaman bir uygulama seviyesi doğrulama (application-level validation) ve istisna yönetim katmanı bulunmalıdır. Python ekosistemi, yapay zeka çıktılarının tiplendirilmesi ve doğrulanması konusunda zengin ve olgun araç setlerine sahiptir. Bu araçlar, LLM yanıtını yalnızca doğrulamakla kalmaz, hatalı durumlarda modeli otomatik olarak uyararak kendini düzelten (self-healing) akışlar oluşturur.

+------------------+      +-------------------+      +--------------------+
|  Ham Kullanıcı   | ---> |  LLM / API Çağrısı| ---> | Ham JSON Çıktısı   |
|  İstemi / Veri   |      |  (Structured Out) |      | (Olasılıksal Metin)|
+------------------+      +-------------------+      +--------------------+
                                                                |
                                                                v
+------------------+      +-------------------+      +--------------------+
| İş Mantığı / DB  | <--- | Pydantic Schema   | <--- | JSON Doğrulama     |
| (Tip Güvenli)    |      | Validasyonu (OK)  |      | & Tip Kontrolü     |
+------------------+      +-------------------+      +--------------------+
                                                                | (Hata Varsa)
                                                                v
                                                     +--------------------+
                                                     | Self-Healing Retry |
                                                     | (Geri Bildirim)    |
                                                     +--------------------+

Python ve Pydantic Modelleri ile Tip Güvenliği

Pydantic, Python dilinde tip ipuçlarını (type hints) kullanarak veri ayrıştırma ve doğrulama sağlayan lider kütüphanedir. LLM entegrasyonlarında Pydantic modelleri iki temel işleve hizmet eder: Birincisi, modele iletilecek JSON şemasını otomatik olarak üretmek; ikincisi ise modelden dönen JSON dizesini tip güvenli bir Python nesnesine dönüştürmektir.

from pydantic import BaseModel, Field, EmailStr
from typing import List, Optional
from enum import Enum

class OncelikSeviyesi(str, Enum):
    DUSUK = "DUSUK"
    ORTA = "ORTA"
    YUKSEK = "YUKSEK"
    KRITIK = "KRITIK"

class GorevAnalizi(BaseModel):
    gorev_adi: str = Field(description="Görevin kısa ve net teknik özeti")
    oncelik: OncelikSeviyesi = Field(description="Görevin aciliyet seviyesi")
    tahmini_saat: float = Field(gt=0, description="0'dan büyük tahmini tamamlanma süresi")
    sorumlu_eposta: Optional[EmailStr] = Field(default=None, description="Atanan kişinin e-posta adresi")
    alt_adımlar: List[str] = Field(min_items=1, description="En az bir alt görev listelenmelidir")

Yukarıdaki kod bloğunda tanımlanan GorevAnalizi sınıfı; Field kısıtlamaları (örneğin gt=0 ile sayının sıfırdan büyük olması, min_items=1 ile listenin boş olmaması) sayesinde verinin doğruluğunu sadece biçimsel olarak değil, mantıksal olarak da denetler.

Instructor Kütüphanesi ile Otomatik Yeniden Deneme (Retry Loop)

Jason Liu tarafından geliştirilen Instructor kütüphanesi, OpenAI, Anthropic, Cohere ve yerel modellerin üzerine ince bir sarmalayıcı (wrapper) ekleyerek Pydantic modelleriyle doğrudan çalışmayı sağlar. Instructor'ın en güçlü özelliği otomatik geri bildirim döngüsüdür (validation retry loop).

Model bir alanı eksik bıraktığında veya Pydantic doğrulayıcısından (validator) hata aldığında, Instructor bu hata mesajını (ValidationError) otomatik olarak yakalar, yeni bir sistem mesajı olarak modele geri besler ve modelden yalnızca hatalı kısmı düzeltmesini ister. Bu işlem belirlenen max_retries sınırına kadar arka planda yürütülür ve geliştiriciye her zaman %100 doğrulanmış bir nesne teslim edilir.

import instructor
from openai import OpenAI

client = instructor.from_openai(OpenAI())

# Pydantic modelini doğrudan response_model parametresiyle çağırın
analiz_sonucu = client.chat.completions.create(
    model="gpt-4o-mini",
    response_model=GorevAnalizi,
    max_retries=3,
    messages=[
        {"role": "user", "content": "Veritabanı indeksleme işlemi yapılacak, acil müdahale gerekiyor, atanacak: [email protected]"}
    ]
)

print(analiz_sonucu.oncelik) # OncelikSeviyesi.KRITIK çıktısı döner

Outlines ve Gramer Tabanlı Çıktı Üretimi (CFG & GBNF)

Açık kaynaklı yerel modeller (Llama 3, Mistral, Qwen) veya vLLM / llama.cpp altyapıları çalıştırılırken, harici API'lere bağımlı kalmadan tam şema uyumu elde etmek için Outlines kütüphanesi ve Bağlamdan Bağımsız Gramerler (Context-Free Grammars - CFG / GBNF) kullanılır.

Outlines, modelin ağırlıklarına dokunmadan, her token üretim adımında (logits processor seviyesinde) yalnızca JSON şemasına uyan bir sonraki karakterlerin üretilmesine izin verir. Örneğin model bir " karakteri açtıysa, bir sonraki adımda yalnızca geçerli bir string veya escape dizisi üretmesine izin verilir; sayısal bir alanda harf yazması matematiksel olarak imkansız kılınır. Bu yaklaşım, yerel modellerde %100 geçerli JSON çıktısını sıfır gecikme cezası ve sıfır yeniden deneme maliyetiyle elde etmenin en verimli yoludur.

---

Kurumsal AI Projelerinde JSON Entegrasyonu ve Risk Yönetimi

Kurumsal ölçekte yapay zeka projeleri hayata geçirilirken yalnızca JSON çıktısının geçerli olması yeterli değildir. Sistemin veri gizliliği standartlarına (KVKK / GDPR / SOC 2) uyumu, token tüketimi üzerinden oluşan bulut maliyetleri, gecikme süreleri (latency) ve beklenmeyen model davranışlarına karşı hata toleransı kapsamlı bir risk yönetim planı gerektirir.

Veri Gizliliği ve Güvenliği: Hassas Verilerin JSON Şemalarında Korunması

JSON şemaları yapıları gereği modelden ne tür veriler talep edildiğini açıkça ortaya koyar. Kurumsal sistemlerde kişisel verilerin (PII), sağlık verilerinin veya finansal bilgilerin işlenmesi sırasında şu güvenlik adımları atılmalıdır:

• Prompt Injection ve Şema Zehirlenmesi: Kötü niyetli kullanıcılar, serbest metin alanlarına enjekte ettikleri talimatlarla JSON çıktısının içine hassas sistem bilgilerini sızdırmaya çalışabilir. Şemalarda serbest metin alanları sınırlandırılmalı ve regex kurallarıyla girdi formatı kısıtlanmalıdır.

• Anonimleştirme Katmanı (PII Masking): Yapay zeka modeline JSON oluşturması için gönderilen ham metinler, modele ulaşmadan önce e-posta, T.C. Kimlik Numarası, kredi kartı gibi hassas verilerden arındırılmalı (maskelenmeli), model doğrulanmış JSON'ı döndükten sonra bu veriler güvenli arka uç katmanında tekrar eşleştirilmelidir.

• Zero Data Retention (Sıfır Veri Saklama): Kullanılan API sağlayıcısının (OpenAI, Anthropic, AWS Bedrock vb.) kurumsal veri gizliliği sözleşmelerine sahip olduğundan ve gönderilen JSON yüklerinin model eğitiminde kullanılmadığından emin olunmalıdır.

Token Tüketimi, Gecikme Süresi (Latency) ve Maliyet Dengesi

JSON formatı, doğası gereği anahtar isimleri, tırnak işaretleri, parantezler ve girintiler nedeniyle düz metne kıyasla %30 ile %70 arasında daha fazla token tüketir. Milyonlarca isteğin işlendiği kurumsal sistemlerde bu durum hem API maliyetlerini katlar hem de yanıt süresini (Time to First Token ve Total Latency) doğrudan artırır.

+-------------------------------------------------------------------------+
|                  TOKEN TÜKETİMİ VE MALİYET KIYASLAMASI                 |
+-------------------------------------------------------------------------+
| 1. Uzun Anahtar İsimli JSON:                                            |
| {"musteri_kurumsal_kimlik_numarasi": 1029384, "durum": "AKTIF"}         |
| -> ~24 Token                                                            |
+-------------------------------------------------------------------------+
| 2. Optimize Edilmiş Kısa JSON:                                          |
| {"id": 1029384, "st": 1}                                                |
| -> ~11 Token  (%54 Tasarruf)                                            |
+-------------------------------------------------------------------------+

Maliyet ve gecikmeyi düşürmek için şu stratejiler uygulanmalıdır:

1. Kompakt Anahtar İsimlendirmesi: Şema tanımlarında musteri_fatura_adresi_ilce_kodu gibi aşırı uzun anahtarlar yerine ilce_kod gibi kısa ve öz anahtarlar tercih edilmelidir. Açıklamalar şemanın description alanında modele aktarılmalıdır.

2. Gereksiz İç İçe Yapılardan (Nesting) Kaçınma: Çok katmanlı, derin hiyerarşik JSON yapıları modelin bağlam penceresini gereksiz yere şişirir ve çözümleme süresini uzatır. Mümkün olduğunca düz (flat) şemalar kurgulanmalıdır.

3. Temperature Değerini Sıfıra Çekme: JSON çıktısı beklenen görevlerde temperature: 0.0 ayarı kullanılmalıdır. Bu, modelin en yüksek olasılıklı belirteçleri seçmesini sağlayarak hem halüsinasyonu azaltır hem de gereksiz token üretimini engeller.

İstisna Yönetimi (Exception Handling) ve Kendi Kendini Onaran (Self-Healing) Kod Tasarımları

Hiçbir harici sistem %100 erişilebilirlik garantisi sunamaz. Model sağlayıcısının anlık kesintileri, hız sınırları (Rate Limit / 429) veya çok nadir de olsa ortaya çıkabilecek bozuk çıktılar için kurumsal yazılımlarda katmanlı istisna yönetimi bulunmalıdır.

def guvenli_json_ayristir(ham_metin: str, sema_sinifi: type[BaseModel]) -> BaseModel:
    import json
    import re

    # 1. Aşama: Doğrudan Pydantic Doğrulaması
    try:
        return sema_sinifi.model_validate_json(ham_metin)
    except Exception:
        pass

    # 2. Aşama: Markdown Kod Bloklarını Temizleme (Regex Fallback)
    temiz_metin = re.sub(r"```json\s*|\s*```", "", ham_metin).strip()
    try:
        return sema_sinifi.model_validate_json(temiz_metin)
    except Exception:
        pass

    # 3. Aşama: JSON Nesnesi Arama (İlk { ile son } arasını kırpma)
    baslangic = temiz_metin.find("{")
    bitis = temiz_metin.rfind("}") + 1
    if baslangic != -1 and bitis != 0:
        kirpilmis = temiz_metin[baslangic:bitis]
        try:
            return sema_sinifi.model_validate_json(kirpilmis)
        except Exception:
            pass

    # 4. Aşama: Kurtarılamaz Hata Durumunda Fallback / DLQ Gönderimi
    raise ValueError("LLM çıktısı belirtilen şemaya uygun bir JSON nesnesine dönüştürülemedi.")

Bu çok katmanlı savunma stratejisi, en kötü senaryolarda dahi sistemin tamamen çökmesini engeller ve bozuk yanıtları Dead Letter Queue (DLQ) gibi inceleme kuyruklarına yönlendirir.

---

Üretim Ortamı İçin Altın Kurallar ve Dayanıklı Mimari Stratejileri

Yapay zeka modelleri statik yazılım kütüphaneleri değildir; sağlayıcılar tarafından sürekli güncellenir, optimize edilir ve bazen ince davranış değişikliklerine uğrarlar. Bugün kusursuz çalışan bir JSON istemi, modelin yeni bir kontrol noktası (checkpoint) sürümüne geçmesiyle farklı davranabilir. Bu nedenle üretim ortamı mimarisi esnek, test edilebilir ve izlenebilir olmalıdır.

İstem Tasarımında Sınırları Belirleme ve Negatif Kısıtlamalar

Modelden JSON talep edilirken yalnızca ne yapması gerektiği değil, ne yapmaması gerektiği de açıkça belirtilmelidir. LLM'ler varsayılan olarak kullanıcıya yardımcı olma eğilimindedir ve eksik bilgileri kendi varsayımlarıyla tamamlama refleksine sahiptir.

• Bilinmeyen Değerler İçin null Kuralı: Eğer analiz edilen metinde istenen bir bilgi yoksa, modelin uydurma veri üretmesi yerine açıkça null döndürmesi talimatlandırılmalıdır ("Eğer adres bulunamazsa 'bilinmiyor' yazma, doğrudan null değeri ata").

• Açıklama Yasağı: Sistem isteminde modelin JSON dışına taşmasını engelleyen negatif kısıtlamalar ("No preamble, no postscript, no explanations") yinelenmelidir.

• Katı Tipli Enum Tanımları: Serbest metin girişi yerine her zaman sonlu seçenekler kümesi sunulmalı ve model bu seçenekler dışına çıkmamaya zorlanmalıdır.

İnsan Denetimi (Human-in-the-Loop) Ne Zaman Devreye Girmeli?

Yapay zeka entegrasyonlarında "her şeyi tamamen otomatikleştirme" yanılgısı operasyonel riskler barındırır. Kritik iş süreçlerinde JSON çıktılarının güvenilirlik skoruna göre filtrelenmesi ve belirli durumlarda insan onayına (Human-in-the-Loop - HITL) sunulması gerekir.

                   +------------------------+
                   |  LLM JSON Çıktısı      |
                   +------------------------+
                               |
                               v
                   +------------------------+
                   |  Güven Skoru Analizi   |
                   +------------------------+
                               |
            +------------------+------------------+
            | (Skor >= 0.90)                      | (Skor < 0.90)
            v                                     v
+------------------------+             +------------------------+
|  Tam Otomatik Akış     |             |  İnsan Onay Paneli     |
|  (Veritabanı / API)    |             |  (HITL İnceleme)       |
+------------------------+             +------------------------+

İnsan denetiminin zorunlu olduğu senaryolar:

1. Yüksek Finansal Etki: Belli bir parasal limitin üzerindeki fatura onayları veya otomatik ödeme emirleri.

2. Düşük Model Güven Skoru: Modelin yanıtla birlikte bir guven_skoru (0.0 - 1.0) üretmesi istendiğinde, skorun belirlenen eşik değerinin (örneğin 0.85) altında kalması durumu.

3. Kritik Alanlarda null Dönüşü: Zorunlu kurumsal alanların metinden çıkarılamadığı istisnai durumlar.

Model Güncellemelerine ve Sürüm Değişikliklerine Karşı Dayanıklılık

Sağlayıcılar modellerini güncelledikçe (örneğin gpt-4o-2024-05-13 yerine gpt-4o-2024-08-06 veya yeni Claude sürümleri geldiğinde) istemlerin çalışma performansı değişebilir. Mimarinin bu değişikliklere karşı ayakta kalması için:

• Sabit Model Sürümleri Kullanın: API çağrılarında gpt-4o veya claude-3-5-sonnet gibi değişken alias'lar yerine, her zaman belirli bir tarihi işaret eden sabit sürümleri (gpt-4o-2024-08-06 vb.) tercih edin.

• Sürekli Entegrasyon (CI) Regresyon Testleri: Şema modellerinizi ve istemlerinizi içeren otomatik test takımları kurun. Her yeni model sürümü yayınlandığında, en az 100-200 adet gerçek dünya test girdisi üzerinden JSON doğrulama başarı oranını ölçün.

• Geriye Dönük Uyumluluk (Backward Compatibility): Pydantic modellerinizde yeni alanlar eklerken her zaman varsayılan değerler (default=None veya default="") tanımlayarak eski kayıtlarla sistemin uyumunu koruyun.

---

Popüler LLM Sağlayıcılarında JSON Uygulama Karşılaştırması

Farklı yapay zeka ekosistemleri, JSON çıktısı üretme görevine mimari düzeyde farklı yaklaşımlar getirmektedir. Projenizin bütçesi, veri gizliliği kuralları ve altyapı bağımsızlığı hedefleri doğrultusunda en uygun sağlayıcıyı seçmek kritik bir karardır.

OpenAI (Structured Outputs), Anthropic Claude (Tool Use) ve Google Gemini

OpenAI, response_format objesi altında type: "json_schema" ve strict: true desteği sunarak sektördeki en katı ve garantili yapıyı kurmuştur. Şemanın ilk çağrısında ufak bir ön işleme (pre-processing) gecikmesi yaşansa da sonraki çağrılarda sıfır ek maliyetle tam uyum sağlanır.

Anthropic Claude, özellikle karmaşık akıl yürütme (reasoning) gerektiren uzun belgelerden JSON çıkarırken sektör lideridir. Claude modellerinde en kararlı JSON alımı, çıktı şemasını bir araç (tool) olarak tanımlayıp tool_choice: {"type": "tool", "name": "cikarilan_veri"} parametresiyle modeli doğrudan bu aracı çağırmaya zorlayarak elde edilir.

Google Gemini, response_schema parametresi sayesinde OpenAPI 3.0 uyumlu şemaları doğrudan kabul eder. Gemini 1.5 Flash'ın düşük maliyeti ve devasa bağlam penceresi, yüzlerce sayfalık PDF'lerden tek seferde devasa JSON veri dizileri çıkarmak için oldukça maliyet etkin bir çözümdür.

Açık Kaynak Modeller (Llama, Mistral, vLLM / SGLang) ile Yerel Uygulama

Veri gizliliği nedeniyle verilerini harici bulut API'lerine gönderemeyen kurumlar için şirket içi (on-premise) veya özel bulut (VPC) üzerinde açık kaynaklı modeller çalıştırmak esastır. Günümüzde vLLM, TGI (Text Generation Inference) ve SGLang gibi yüksek performanslı çıkarım (inference) sunucuları, Outlines ve xGrammar motorlarını yerel olarak entegre etmiştir.

Bu sayede Llama 3.1 veya Mistral modelleri çalıştırılırken API isteğine JSON şeması eklenir; çıkarım motoru her belirteç üretim adımında geçersiz token'ları maskeler. Sonuç olarak açık kaynaklı yerel modellerde de tescilli API'lerin sunduğu %100 garantili JSON çıktısı performans kaybı yaşamadan elde edilir.

---