Güvenilir LLM Hatları: Model Önerir, Şema Karar Verir

Büyük dil modelleri yani LLM’ler, e-posta, belge ve form gibi dağınık insan girdilerini anlamlandırmakta oldukça başarılı. Ancak bir LLM’in ürettiği çıktıyı hiçbir kontrol olmadan doğrudan sisteme yazmak, production ortamında ciddi sorunlara yol açabilir.

Güvenilir yaklaşım aslında oldukça basit:

Model önerir. Schema doğrular. Business rules karar verir. Sistem uygular.

Bu ayrım, LLM tabanlı otomasyon sistemlerini daha kontrollü ve güvenilir hale getirmenin temel yollarından biridir.

LLM otomasyonundaki asıl problem nedir?

Bir LLM’i n8n gibi bir automation platformuna bağlamak oldukça kolay. Gelen bir e-postayı modele gönderirsiniz. Müşterinin adını, sipariş numarasını veya talep türünü çıkarmasını istersiniz. Sonra gelen sonucu workflow’un bir sonraki adımına gönderirsiniz.

İlk bakışta her şey düzgün çalışıyor gibi görünür.

Sorun, sistem gerçek verilerle karşılaşmaya başladığında ortaya çıkar.

Model bir bilgiyi yanlış yorumlayabilir. Eksik bir değeri tahmin edebilir. Hatta yapısal olarak doğru görünen ama gerçekte yanlış olan bir JSON üretebilir.

Bu çıktı doğrudan ERP, CRM veya başka bir sisteme yazılırsa hata artık sadece modelin verdiği yanlış bir cevap olmaktan çıkar. Sistemin gerçek verisine dönüşür.

Bu nedenle üretim ortamında temel yaklaşım şu olmalıdır:

LLM çıktısını gerçeğin kendisi olarak değil, doğrulanması gereken bir öneri olarak değerlendirin.

Güvenilir bir LLM pipeline nasıl kurulur?

Güvenilir bir yapı kurarken amaç LLM’i her şeyden sorumlu hale getirmek değildir. Tam tersine, modelin iyi olduğu işi ona vermek ve geri kalan kısmı daha kontrollü mekanizmalarla yönetmektir.

1. Workflow’u n8n ile yönetin

n8n burada workflow’u yöneten katman olarak çalışabilir.

E-posta, PDF, form veya başka bir kaynaktan gelen veri alınır. LLM’e gönderilir. Sonuç validation adımından geçirilir. Ardından workflow, sonuca göre devam eder veya başka bir yola gider.

Bu yapı içinde retry, error handling, conditional branching ve human review gibi adımlar yönetilebilir.

Böylece LLM tek başına sistemi kontrol etmez. Daha büyük bir workflow’un parçası olarak çalışır.

2. LLM’i veri çıkarmak için kullanın

LLM’lerin en güçlü olduğu alanlardan biri, insanların farklı biçimlerde yazdığı metinlerden düzenli veri çıkarmaktır.

Örneğin bir müşteri şöyle yazabilir:

“Merhaba, geçen hafta verdiğimiz 250 adet siyah ürün siparişinin teslimat tarihini öğrenebilir miyiz?”

LLM bu metinden şöyle bir çıktı üretebilir:

{
  "quantity": 250,
  "color": "siyah",
  "request_type": "teslimat_tarihi_sorgusu"
}

Burada önemli olan nokta şu:

Bu veri henüz doğrulanmış değildir.

Model yalnızca metni yorumlamış ve bir sonuç önermiştir.

Yani LLM burada karar veren taraf değil, veriyi anlamlandıran taraftır.

3. Çıktıyı schema ile doğrulayın

Güvenilirliğin asıl başladığı yer burasıdır.

Schema, sistemin kabul edeceği verinin kurallarını tanımlar.

Örneğin:

• quantity sayı olmalıdır.
• request_type yalnızca izin verilen değerlerden biri olmalıdır.
• Zorunlu alanlar boş bırakılamaz.
• Beklenmeyen alanlar reddedilebilir.
• Belirli alanların belirli formatlarda olması gerekebilir.

Model ne kadar güvenilir görünürse görünsün, çıktısı schema kurallarına uymuyorsa sistem bunu kabul etmemelidir.

Burada çok önemli bir fark vardır:

LLM tahmin eder. Schema kontrol eder.

Bu yüzden modelin ne kadar iyi olduğu kadar, modelin çıktısının nasıl kontrol edildiği de önemlidir.

LLM output ile business logic aynı şey değildir

Bir LLM bir metni doğru şekilde anlayabilir. Ancak bu, sistemin hangi işlemi yapması gerektiğini otomatik olarak belirlediği anlamına gelmez.

Örneğin müşteri şöyle yazabilir:

“Teslimatı cuma günü yapabilir misiniz?”

LLM bunun bir teslimat talebi olduğunu anlayabilir.

Ama sistemin karar vermesi gereken sorular farklıdır:

Sipariş mevcut mu?
Ürün stokta mı?
Cuma günü teslimat mümkün mü?
Müşterinin hesabı aktif mi?
Teslimat adresi geçerli mi?

Bunlar LLM’in karar vermesi gereken konular değildir.

LLM burada isteği anlamlandırabilir. Sistem ise kendi kurallarına ve gerçek verilerine bakarak karar vermelidir.

Bu nedenle LLM ile business logic’i birbirinden ayırmak önemlidir.

4. Geçici hatalar için retry kullanın

Her başarısız request modelin yanlış cevap verdiği anlamına gelmez.

API timeout, network problemi, rate limit veya servis tarafındaki geçici bir sorun nedeniyle request başarısız olabilir.

Bu gibi durumlarda workflow kontrollü şekilde retry yapabilir.

Örneğin ilk deneme başarısız olduysa sistem kısa bir süre bekleyip tekrar deneyebilir. Gerekirse sonraki denemelerde bekleme süresi artırılabilir.

Ancak burada önemli bir ayrım var:

Geçici teknik hata retry edilebilir. Gerçek belirsizlik tahmin edilmemelidir.

Model bir adresi net şekilde anlayamıyorsa veya kritik bir bilgiyi çıkaramıyorsa sistem sürekli yeni bir tahmin üretmeye çalışmamalıdır.

5. Belirsiz durumları human review’a gönderin

Schema validation başarısız olduğunda veya business rules açısından belirsiz bir durum oluştuğunda sistemin yapması gereken şey yeni bir tahminde bulunmak değildir.

Bu kayıt human review’a gönderilebilir.

Örneğin workflow şöyle ilerleyebilir:

LLM
↓
Schema validation
↓
Business validation
↓
Başarılı → Workflow devam eder
Başarısız → Human review

Böylece sistem sadece emin olduğu durumlarda otomatik olarak ilerler.

Belirsiz bir durumda ise kararı bir insana bırakır.

Buradaki temel prensip çok basit:

Sistem bilmediği şeyi icat etmemelidir.

Production ortamında güvenilirlik neden farklıdır?

Bir automation’ın çalışıyor olması, production için hazır olduğu anlamına gelmez.

Demo ortamında her şey düzgün çalışabilir. Gerçek kullanım başladığında ise aynı workflow’un aynı veriyi iki kez işlemesi, API’nin geçici olarak hata vermesi veya bir adımın başarısız olması gibi durumlarla karşılaşırsınız.

Bu noktada iki konu özellikle önem kazanır:

Idempotency ve observability.

Idempotency

Bir workflow aynı veriyi iki kez işlerse aynı işlemi iki kez gerçekleştirmemelidir.

Örneğin bir network problemi nedeniyle aynı sipariş isteği iki kez gönderilirse sistem iki ayrı sipariş oluşturmamalıdır.

Bu nedenle kritik işlemlerin idempotent şekilde tasarlanması gerekir.

Özellikle webhook, queue ve retry kullanılan sistemlerde bu konu oldukça önemlidir.

Observability

Bir automation yalnızca çalışmamalı, ne yaptığını da gösterebilmelidir.

Örneğin şu bilgileri takip edebilmeniz gerekir:

• Hangi workflow çalıştı?
• Hangi veri işlendi?
• LLM request başarılı oldu mu?
• Schema validation geçti mi?
• Kaç retry yapıldı?
• Hata hangi adımda oluştu?
• Kaç kayıt human review’a gönderildi?

Logs, metrics ve alerts sayesinde bir sorun ortaya çıktığında nerede oluştuğunu daha hızlı anlayabilirsiniz.

Bu da production sistemlerini yönetmeyi ciddi şekilde kolaylaştırır.

Bu yaklaşım hangi işlerde kullanılabilir?

Bu yapı yalnızca e-posta otomasyonu için kullanılmaz.

Invoice processing

PDF’den firma adı, invoice number, tutar ve diğer gerekli bilgiler çıkarılır.

Ardından schema validation yapılır ve gerekli kontrollerden sonra veri ERP’ye aktarılır.

Customer support

Müşteri e-postası analiz edilir. Talebin ne olduğu anlaşılır. Gerekli bilgiler çıkarılır ve ticket ilgili ekibe yönlendirilir.

Order processing

Serbest formatta yazılmış bir sipariş mesajından ürün, miktar ve teslimat bilgileri çıkarılır.

Veri doğrulandıktan sonra order management sistemine aktarılır.

Document processing

Contract, form veya benzeri belgelerden gerekli bilgiler çıkarılır.

Eksik veya belirsiz bilgiler human review’a gönderilir.

Bu örneklerin hepsinde temel yapı aynıdır:

Unstructured data → LLM → Schema validation → Business validation → System action

Güvenilir LLM otomasyonu aslında ne demek?

Güvenilir bir LLM automation sistemi, her şeyi modelin kendisine bırakmak anlamına gelmez.

Tam tersine, modelin sınırlarını doğru şekilde belirlemek anlamına gelir.

LLM insan dilini anlamlandırır.

Schema gelen çıktıyı kontrol eder.

Business rules verinin operasyon açısından uygun olup olmadığını belirler.

Sistem yalnızca doğrulanmış veriye göre işlem yapar.

Human review ise sistemin çözemediği durumları ele alır.

Bunu basitçe şöyle düşünebilirsiniz:

Unstructured input
        ↓
       LLM
        ↓
   Schema check
        ↓
 Business rules
        ↓
     Decision
      ↙    ↘
  Success   Unclear
     ↓         ↓
  System   Human review

Bu yaklaşım sayesinde manuel copy-paste işleri azaltılabilir. Hatalı verilerin production sistemlerine ulaşma riski düşürülebilir. Aynı yapı farklı belge türlerine ve farklı business process’lere de uygulanabilir.

Sonuç

LLM tabanlı automation sistemlerinde güvenilirlik, sadece daha iyi bir model kullanmakla çözülmez.

Asıl önemli olan, modelin etrafına doğru kontrol mekanizmalarını kurmaktır.

LLM veriyi anlamlandırır ve bir çıktı önerir.

Schema bu çıktının kabul edilebilir olup olmadığını kontrol eder.

Business rules gerçek iş kurallarını uygular.

System doğrulanmış veriye göre işlem yapar.

Human review ise modelin emin olmadığı durumları ele alır.

Özetle:

Model önerir. Schema doğrular. Business rules karar verir. System uygular. İnsan istisnaları çözer.

Güvenilir bir LLM pipeline’ın amacı her şeyi tamamen otomatik hale getirmek değildir.

Amaç, otomasyonu kontrollü, takip edilebilir ve güvenilir hale getirmektir.

Öne çıkan noktalar

• LLM output’unu source of truth olarak kabul etmeyin.
• LLM’i unstructured data’dan bilgi çıkarmak için kullanın.
• Output’u schema ile validate edin.
• Geçici hatalar için retry kullanın.
• Gerçek belirsizliği tahmin etmek yerine human review’a yönlendirin.
• Idempotency ile duplicate işlemleri önleyin.
• Observability ile workflow’ları takip edin.
• LLM ile business logic’i birbirinden ayırın. Otomasyon ve ERP entegrasyonu hizmetimize bakın.