LLM Halüsinasyonları: Neden Olur ve Nasıl Azaltılır?

Büyük dil modelleri bazen, hiç tereddüt etmeden, son derece kendinden emin bir tonla yanlış bir cevap üretir. Buna "halüsinasyon" diyoruz ve bu, modelin bozuk olmasından değil, tam olarak tasarlandığı gibi çalışmasından kaynaklanır. Peki bu kaçınılmaz mı? Hayır. Doğru önlemlerle halüsinasyonu sıfırlayamasak bile büyük ölçüde dizginleyebiliriz. Bu yazıda nedenini sezgisel olarak anlatıp, pratik bir azaltma kemeri kuracağız.

Halüsinasyon nedir, neden olur?

Bir büyük dil modeli (LLM) bir "gerçek deposu" değildir. Devasa metin yığınlarından öğrendiği örüntülere bakarak bir sonraki kelimenin ne olması gerektiğini tahmin eden istatistiksel bir motordur. Telefon klavyenizdeki kelime tahminini düşünün: "Bugün hava çok…" yazdığınızda "güzel", "sıcak" önerir. LLM aynı işi yapar; ama milyonlarca belge okuduğu için tahminleri o kadar isabetli olur ki akıcı paragraflar, kod, hatta şiir üretebilir.

İşte sorun da burada: modelin hedefi "doğruyu söylemek" değil, "akla yatkın görünen bir sonraki kelimeyi üretmek"tir. Ona var olmayan bir kaynak sorduğunuzda, gerçek bir kaynağı hatırlamaz; sadece "gerçek bir kaynağın nasıl görünmesi gerektiğini" üretir. Sonuç: gerçekte olmayan ama inandırıcı duran içerik.

Halüsinasyonun tehlikesi modelin yanılmasında değil; yanıldığını gizleyecek kadar akıcı ve kendinden emin olmasındadır.

Bunu somutlaştıran gerçek bir olay var: 2023'te ABD'de görülen Mata v. Avianca davasında avukatlar, bir dilekçeyi hazırlarken ChatGPT'nin ürettiği altı emsal karara atıf yaptı. Kararların hiçbiri gerçek değildi; altısı da tamamen uydurmaydı. Mahkeme avukatlara para cezası verdi. Ders açık: hata yapay zekayı kullanmak değil, çıktısını hiç doğrulamadan kabul etmekti.

Halüsinasyonu besleyen başlıca etkenler şunlardır:

• Bilgi boşluğu: Modelin eğitim verisinde olmayan ya da çok seyrek geçen bir konu sorulduğunda model "boşluğu doldurmaya" eğilimlidir.
• Güncellik sınırı: Modelin bilgisi belirli bir tarihte donar; sonrasını "tahmin eder".
• Belirsiz veya çelişkili soru: Net olmayan bir istem, modeli varsayım yapmaya iter.
• Aşırı yardımseverlik: Model "bilmiyorum" demek yerine bir cevap üretmeye eğilimli hâle getirilmiş olabilir.

Kaynağa demirleme (grounding) ve RAG

En etkili tek önlem, modeli kendi "hafızasıyla" baş başa bırakmamaktır. Bir öğrenciyi düşünün: kapalı kitap sınavında ezberinden uydurabilir; ama açık kitap sınavında cevabını önündeki metne dayandırmak zorundadır. Kaynağa demirleme tam da bunu yapar.

Bunun en yaygın yöntemi RAG'dir (Retrieval-Augmented Generation — Getirmeyle Güçlendirilmiş Üretim). Mantığı basittir: model cevabı doğrudan belleğinden yazmaz. Önce güvenilir bir kaynaktan (belge tabanı, dokümantasyon, kullanıcının yüklediği dosya) ilgili metni getirir, sonra cevabını bu metne demirleyerek üretir.

// Basit RAG akışı (sözde kod)
soru = kullanici_girdisi()

// 1) GETİR: soruya en yakın belgeleri bul
parcalar = vektör_db.ara(göm(soru), ust_k=5)

// 2) DEMİRLE: yalnızca bu parçaları bağlam olarak ver
istem = """
Aşağıdaki KAYNAK metnine dayanarak cevap ver.
Cevap kaynakta yoksa "Kaynakta bulunamadı" de.
Her iddianın yanına [parça-no] olarak atıf ekle.

KAYNAK:
{parcalar}

SORU: {soru}
"""

// 3) ÜRET + ATIF
cevap = llm(istem, temperature=0.2)

Üç kritik ayrıntıya dikkat: (1) Modele "kaynakta yoksa uydurma, 'bulunamadı' de" talimatı verin. (2) Atıf isteyin; izlenebilir cevap doğrulanabilir cevaptır. (3) Getirme adımının kendisi isabetli olmalı — yanlış belge getirilirse, üzerine kurulan cevap da yanlış olur. RAG halüsinasyonu büyük ölçüde azaltır ama sıfırlamaz; bu yüzden tek katman değil, savunma katmanlarından biridir.

Sıcaklık (temperature) ve çözümleme ayarları

Temperature, modelin bir sonraki kelimeyi seçerken ne kadar "yaratıcı" davranacağını belirleyen bir ayardır. Düşük değer (örn. 0–0.3) modeli en olası, en güvenli seçeneğe yönlendirir; yüksek değer (örn. 0.8–1.2) çeşitliliği ve sürprizi artırır.

Bunu bir aşçının tuz eline benzetebiliriz: az tuz tutarlı ve öngörülebilir bir tat verir; çok tuz bazen muhteşem bazen felaket sonuç doğurur. Olgusal doğruluk istediğiniz görevlerde (özetleme, soru-cevap, veri çıkarımı) düşük temperature kullanın. Beyin fırtınası, reklam metni, yaratıcı yazım gibi görevlerde yüksek değer mantıklıdır.

• Olgusal/teknik cevaplar: temperature ≈ 0.0–0.3
• Dengeli sohbet: ≈ 0.4–0.7
• Yaratıcı üretim: ≈ 0.8–1.2

Önemli bir uyarı: düşük temperature halüsinasyonu azaltır ama yok etmez. Model emin bir tonla yanlış bir bilgiyi "en olası" sayıyorsa, sıcaklığı düşürmek o yanlışı daha kararlı biçimde tekrar ettirir. Yani temperature tek başına bir çözüm değil, demirlemeyi tamamlayan bir ayardır.

Doğrulama ve kendini kontrol

İnsanlar da ilk taslakta hata yapar; farkımız, yazdığımızı bir kez daha okumamızdır. Modele de aynı disiplini uygulayabiliriz.

• Kendini kontrol (self-check): Modelden, ürettiği cevabı kaynağa karşı bir kez daha denetlemesini ve desteklenmeyen iddiaları işaretlemesini isteyin.
• Çapraz doğrulama: Aynı soruyu birkaç kez (veya farklı modellere) sorun; cevaplar tutarsızsa bu bir "düşük güven" sinyalidir.
• Programatik doğrulama: Çıktının biçimini ve gerçekliğini kodla denetleyin — örneğin verilen URL'in açılıp açılmadığını, atıf numarasının kaynakta gerçekten geçip geçmediğini.
• İnsan denetimi: Yüksek riskli alanlarda (hukuk, sağlık, finans) son onay her zaman bir uzmandadır. Yapay zeka taslağı hızlandırır; sorumluluğu devralmaz.

// Atıfların gerçekliğini koda dökerek denetleyin
for iddia in cevap.iddialar:
    if iddia.atif not in kaynak_metin:
        isaretle(iddia, "Kaynakta doğrulanamadı")
        # kullanıcıya göster veya cevabı reddet

Doğrulamayı modelin iyi niyetine bırakmayın. Doğrulanabilir olanı kodla doğrulayın; yalnızca yargı gerektireni insana bırakın.

Prompt ve sistem tasarımı

Çoğu halüsinasyon, kötü modelden değil, belirsiz istemden doğar. İstemi netleştirmek tek başına büyük fark yaratır:

• Bilmeme iznini açıkça verin: "Emin değilsen 'bilmiyorum' de" cümlesi, modelin uydurma baskısını azaltır.
• Kapsamı daraltın: "Yalnızca verilen metne dayan", "tarih aralığını şu yapma" gibi sınırlar varsayımları keser.
• Adım adım düşünme isteyin: Karmaşık görevlerde önce muhakeme, sonra sonuç istemek tutarlılığı artırır.
• Çıktı biçimini sabitleyin: Yapısal (JSON, tablo) çıktı, hem doğrulamayı kolaylaştırır hem serbest uydurmayı azaltır.

Kaynağa demirlenmiş, doğrulanabilir ve insan denetiminden geçen bir mimari kurmak istiyorsanız, bu yaklaşımı pratikte nasıl uyguladığımızı EcoFluxion sayfamızda anlatıyoruz.

Pratik kontrol listesi

1. Olgusal görevde RAG kullan; cevabı kaynağa demirle ve atıf iste.
2. Temperature'ı göreve göre seç; doğruluk istiyorsan düşük tut.
3. İsteme "bilmiyorsan söyle" iznini ekle.
4. Atıf ve biçimi kodla doğrula; serbest metni denetlenebilir hâle getir.
5. Tutarsızlık testi için cevabı çapraz doğrula.
6. Yüksek riskte insan onayını akışa zorunlu kıl.

Özetle: halüsinasyon, akıcılığın bedelidir; ama kaderimiz değildir. Modeli gerçeğe demirleyip cevaplarını doğrulanabilir kıldığınızda, yapay zeka "kendinden emin bir uydurma makinesi" olmaktan çıkıp güvenilir bir yardımcıya dönüşür. Anahtar tek bir sihirli düğme değil; üst üste binen küçük, disiplinli önlemlerdir.