Üretim Ortamında Yapılandırılmış LLM Çıktıları ve Halüsinasyon Kontrolü

Büyük dil modellerini (LLM) kullanıcıya yönelik üretim sistemlerine entegre ederken karşılaşılan en büyük mühendislik zorluğu, modellerin doğası gereği stokastik (olasılıksal) olmasıdır. Bir sohbet penceresinde kabul edilebilir olan ufak biçim sapmaları veya beklenmedik yanıtlar, arka uç veritabanına yazılan veya istemci arayüzünde belirli veri tiplerini bekleyen bir uygulamada çalışma zamanı (runtime) hatalarına neden olur.

Revalune gibi sembol çözümleme ve analitik metin işleme motorları inşa ederken edindiğimiz temel tecrübe şudur: Model çıktısı asla denetimsiz ham metin olarak kabul edilmemeli, daima kesin bir veri sözleşmesi (schema contract) ile sınırlandırılmalıdır.

1. Serbest Metinden Şematik Çıktıya Geçiş#

Klasik istem mühendisliğinde (prompt engineering) modele "Yanıtını yalnızca JSON formatında ver" talimatı vermek, üretim ölçeğinde yetersiz kalır. Model ara sıra açıklama metni ekleyebilir, kapanış süslü parantezini unutabilir veya anahtar isimlerini küçük-büyük harf açısından değiştirebilir.

Bu sorunu çözmek için üretim sistemlerinde çok katmanlı bir çıktı kontrol mekanizması uygulanır:

// İstemci ve arka uç arasında kesinleşmiş tip sözleşmesi
export interface AnalysisResponse {
  primaryTheme: string;
  confidenceScore: number;
  extractedEntities: {
    name: string;
    category: 'character' | 'setting' | 'symbol' | 'emotion';
    significance: string;
  }[];
  interpretations: {
    frameworkId: string;
    perspectiveSummary: string;
    actionableInsight: string;
  }[];
}

2. Çıktı Güvenilirliği Problemleri: Semantik vs. Yapısal İhlaller#

Üretim ortamlarında model çıktılarında karşılaşılan güvenilirlik sorunları iki temel kategoriye ayrılır:

A. Semantik Doğruluk Problemleri (Halüsinasyon)#

• Varlık Halüsinasyonu (Entity Hallucination): Girdide hiç yer almayan kişi, nesne veya sembollerin üretilmesi. Savunma: Çapraz metin varlık eşleme ve bağlam kısıtlaması.
• İlişki Sapması (Relation Hallucination): Girdideki gerçek iki varlık arasında asılsız veya hatalı bir bağ kurulması. Savunma: Adım adım çıkarım ve referans denetimi.

B. Yapısal Sözleşme İhlalleri#

• Geçersiz JSON (Invalid JSON): Kapanmamış parantezler veya sözdizimsel bozulmalar.
• Eksik Alan (Missing Field): Şemada zorunlu kılınan bir anahtarın model yanıtında bulunmaması.
• Yanlış Veri Tipi (Wrong Type): Dizi beklenen yerde serbest metin veya sayı dönmesi.
• Geçersiz Enum Değeri (Invalid Enum): İzin verilen kategori listesi haricinde bir değer üretilmesi.

3. Çalışma Zamanı Şema Doğrulaması ve Hata Yönetimi#

Şematik çıktı kullanımında bile ağ kesintileri, token limitine çarpma veya sağlayıcı kaynaklı sapmalar nedeniyle yanıt bozulabilir. Bozuk veya şema dışı model çıktılarında regex ile eksik parantezleri veya anahtarları tahmin etmeye çalışmak, sessiz veri bozulmalarına (silent data corruption) yol açabileceğinden önerilmez.

Üretim ortamlarında güvenilir akış şu dört aşamadan oluşmalıdır:

1. Ayrıştırma (Parse): Ham model çıktısının standart JSON ayrıştırıcı ile okunması.
2. Çalışma Zamanı Doğrulaması (Runtime Validation): Zod veya eşdeğer bir doğrulayıcı ile tip, aralık ve enum kontrolü.
3. Sınırlı Yeniden Deneme (Bounded Retry): Yalnızca kurtarılabilir hatalarda sınırlı sayıda geri bildirimli yeniden istek.
4. Güvenli Başarısızlık / Yedek Yanıt (Safe Failure / Fallback): Hata giderilemiyorsa kontrollü durum bildirimi veya deterministik güvenli yanıt sunulması.

import { z } from 'zod';

const AnalysisSchema = z.object({
  primaryTheme: z.string().min(3),
  confidenceScore: z.number().min(0).max(1),
  extractedEntities: z.array(z.object({
    name: z.string(),
    category: z.enum(['character', 'setting', 'symbol', 'emotion']),
    significance: z.string(),
  })),
  interpretations: z.array(z.object({
    frameworkId: z.string(),
    perspectiveSummary: z.string(),
    actionableInsight: z.string(),
  })),
});

export type AnalysisResult = z.infer<typeof AnalysisSchema>;

export function parseAndValidate(rawOutput: string): AnalysisResult | null {
  // 1. Standart JSON ayrıştırma
  let parsed: unknown;
  try {
    parsed = JSON.parse(rawOutput);
  } catch {
    // Sözdizim hatasında regex ile tahmin yapmak yerine açık hata döndürülür
    return null;
  }

  // 2. Çalışma zamanı şema doğrulaması
  const result = AnalysisSchema.safeParse(parsed);
  if (!result.success) {
    // Şema ihlalinde güvenli başarısızlık veya kontrollü yeniden deneme tetiklenir
    return null;
  }

  return result.data;
}

4. Çıktı Bütünlüğü ve Kullanıcı Denetimi#

Yapay zekâ destekli analizlerde modelin çıkarımları kullanıcıya "nihai ve tartışılmaz gerçek" olarak sunulmamalıdır. Üretim uygulamalarında kullanıcı denetimini korumak için benimsenen tasarım prensipleri:

1. Varlık Çıkarımları Kullanıcı Denetimine Açık Olmalı: Otomatik etiketlenen bir varlık veya sembol, kullanıcı tarafından incelenebilmeli, düzenlenebilmeli veya gerektiğinde silinebilmelidir.
2. Çoklu Bakış Açısı Ayrışmalı: Farklı teorik modeller veya analitik yorum çerçeveleri tek bir monolitik metinde birbirine karıştırılmamalı, bağımsız modüller halinde sunulmalıdır.
3. Açıklanabilir Ürün Tasarımı (Genel İlke): Kullanıcı arayüzünde modelin hangi veriye dayanarak çıkarım yaptığı belirginleştirilmeli, yapay zekâ çıktısı kullanıcının karar verme sürecini ikame etmek yerine desteklemelidir.

5. Sonuç#

Üretim kalitesinde bir yapay zekâ uygulaması, modelin ham zekâsından ziyade onun etrafına örülen yazılım mühendisliği disiplini ile ölçülür. Katı şema tanımları, çalışma zamanı doğrulamaları ve kullanıcı denetimine izin veren arayüz tasarımı ile olasılıksal model davranışını bir uygulama içerisinde daha öngörülebilir, sınırlandırılmış, gözlemlenebilir ve kurtarılabilir kılmak mümkündür.