LLM'iniz Geçerli Bir JSON Döndürdü. Bu, Doğruyu Söylediği Anlamına Gelmez.

Otomotiv telemetrisi üzerine bir uygulama geliştirmek; yapılandırılmış çıktı (structured output), kanıt doğrulaması ve üretilen bir yanıta ne zaman güvenilmemesi gerektiği konusunda kritik yazılım mühendisliği dersleri barındırır.

Yanıt kusursuz görünüyordu#

Bir konferans konuşması hazırlığı sırasında, otomotiv telemetri verilerini açıklamak için büyük dil modeli (LLM) kullanan bir uygulama geliştiriyordum. Amaç; ölçümleri toplamak, zaman içindeki değişimlerini analiz etmek, anomalileri tespit etmek ve sonuçları insanların anlayabileceği açıklamalara dönüştürmekti. Mimari oldukça basitti: TypeScript tabanlı bir backend telemetriyi işleyecek, dil modeli yapılandırılmış bir açıklama üretecek ve Angular tabanlı bir kontrol paneli bunu görselleştirecekti.

Ancak göz ardı edemeyeceğim bir soru vardı: Model, yapısal olarak tamamen doğru görünen ama gerçeği yansıtmayan bir sonuç döndürdüğünde ne olur?

Örneğin şu çıktıyı ele alalım:

{
  "text": "Coolant temperature reads 118°C.",
  "measurementClaim": {
    "sensorId": "coolant_temp",
    "value": 118,
    "unit": "°C",
    "evidenceId": "ev-meas-coolant-01"
  }
}

Buradaki JSON tamamen geçerlidir:

• Her alan beklenen veri tipindedir.
• Kanıt referansı (evidenceId) meşru görünmektedir.
• Bir şema doğrulayıcının (schema validator) hata vermesi için hiçbir neden yoktur.

Tek bir sorun vardır: Gerçek soğutma sıvısı sıcaklığı 106.1°C'dir.

Bu örnek, gerçek dünya verilerini açıklamak için LLM kullanan uygulamalardaki temel bir problemi gösterir: Bir yanıt yapısal olarak kusursuz olabilir ancak olgusal olarak tamamen yanlış olabilir. Bu yanıt şık bir kullanıcı arayüzünde sunulduğunda, kullanıcılar doğal olarak verinin doğrulandığını varsayar. İşte gerçek mühendislik çalışması tam burada başlar.

Neden LLM'in her şeyi yapmasını istemedim?#

Aldığım ilk mimari kararlardan biri, veri analizi ile doğal dil açıklamasını birbirinden ayırmak oldu. Uygulama; sıcaklık trendlerini hesaplamak, eşik değer aşımını tespit etmek veya bir ölçümün değişim hızını tahmin etmek için dil modelini kullanmaz. Bu sorumluluklar tamamen deterministik koda aittir.

Backend telemetriyi işler, trendleri hesaplar, yapılandırılmış kuralları değerlendirir ve yapılandırılmış bulgular üretir. LLM ise yalnızca bu bulguları alır ve açıklar. Bunun temel nedenleri şunlardır:

• Bağımsız test edilebilirlik: Hesaplamaları modelden bağımsız olarak test edebilmek gerekir. Sıcaklık belirli bir aralıkta yükseldiyse bu sonuç tekrar üretilebilmelidir.
• İzlenebilirlik: Uygulama bir eşik aşımı bildirdiğinde, bunu tam olarak hangi kuralın tetiklediği bilinmelidir.
• Görev ayrımı: Deterministik kod da hata içerebilir ancak davranışı incelenebilir ve tekrarlanabilirdir. Dil modelinin görevi ise yeni olgular uydurmadan bu sonuçları anlaşılır kılmaktır.

Yapılandırılmış çıktı, olgu doğrulaması değildir#

Dil modellerini uygulamalara entegre ederken Structured Output ve JSON Modu kullanmak son derece faydalıdır. Öngörülemez bir metin bloğu almak yerine, yanıtın hangi alanları içermesi gerektiğini belirten net bir sözleşme (contract) tanımlayabiliriz.

TypeScript örneğinde gözlemleri, çıkarımları, önerilen kontrolleri ve kanıt referanslarını temsil etmek için Zod kütüphanesi kullanılmıştır:

export const MeasurementClaimSchema = z.object({
  sensorId: z.string().min(1),
  value: z.number(),
  unit: z.string().min(1),
  evidenceId: z.string().min(1)
});

Yazılım geliştiriciler için buradaki en önemli pratik çıkarım şudur: Zod veya benzeri şema doğrulayıcılar yalnızca verinin şeklini (veri tiplerini ve zorunlu alanları) doğrular; modelin içerideki sayısal değeri halüsinasyonla değiştirip değiştirmediğini kontrol etmez. Üretim ortamında güvenilir AI uygulamaları geliştirmek için şema doğrulamasının ötesine geçmeli ve modelin döndürdüğü değerleri kaynak verilerle (kanıtlarla) karşılaştıran deterministik doğrulama katmanları eklemelisiniz.