Hata Yapmayan Yapay Zeka Asistanı Mümkün Mü?

Yapay zeka asistanlarını iş akışlarında kullanmaya çalışanların sıkça düştüğü o çaresizliği biliyorsunuzdur: Sistem promptunun bir köşesine büyük harflerle “LÜTFEN, KESİNLİKLE, ASLA HALÜSİNASYON GÖRME!!” yazıp her şeyin yolunda gitmesini ummak…

Yapay zeka sektörü, sırf bu “hata yapma” sorununu çözmek için milyarlarca dolar harcadı, harcıyor. Diyorlar ki, bizim platformu kullanırsanız bu hatalar çözülür.

Bu tür platformları bir umutla satın alan firmalar, renkli grafiklerden oluşan arayüzler, teknik entegrasyon rehberleri vs sonrasında sorunun devam ettiğini görünce iyice karamsarlığa kapıldılar. Çünkü bu platformlar, “bozulan” bir yapay zeka asistanını nasıl tamir edeceğimizi veya neyi nasıl test etmemiz gerektiğini pek anlatmadılar. Kendi başımıza kaldık.

Prompt’larda ufak oynamalar yapıp, daha uzun sistem mesajları yazarak çözülmeyecek şeyler de var. Yapay zeka ile tembellik yapan bir çalışanmış gibi pazarlık etmeye çalışmanın pek anlamı yok.

Yapay zeka asistanı özür diler, daha iyisini yapacağına söz verir ve iki hafta sonra farklı bir saat diliminde veya biraz farklı bir sorguda tamamen aynı hatayı tekrar yapar.

Çünkü o hataya dair hiçbir belleği (memory) yoktur. Hatayı yakalayacak bir testi yoktur.

Hepimiz biliyoruz ki; prompt karmaşıklaştığı an, güvenilirlik buharlaşıp uçuyor.

Eğer gerçekten ölçeklenebilen yapay zeka ürünleri geliştirmek istiyorsak (ister operasyonları otomatikleştiriyor olalım, ister Tap Grow’da yaptığımız gibi bir platform inşa edelim), yapay zekayı “bir şeyi on kere söyleyince anlayan” bir çalışan gibi yönetmeyi bırakıp onu bir mühendislik sistemi gibi ele almamız gerekiyor.

O zaman önce biz nerede yanlış yapıyoruz bunu anlamalı ve kendi yaramıza merhem olmaya çalışmamız lazım. Bültenimizin bu sayısında bu konuya odaklanıyoruz.

Temel Hata: Yaklaşımları Karıştırmak

Gelişmiş herhangi bir yapay zeka mimarisinde, iki iş türü arasına kesin ve net bir çizgi çekmemiz lazım: örtük (latent) ve deterministik.

• Örtük İşler; belirsiz, subjektif, tek bir doğrusu olmayan, yargı, akıl yürütme ve dilsel yorumlama gerektirir. Her seferinde farklı bir sonucun çıkması doğaldır. Büyük Dil Modellerinin (LLM) en iyi yaptığı şey.

• Deterministik İşler; kesinlik gerektirir. Bir dosyada arama yapmak (grep), bir API’yi sorgulamak, matematiksel hesaplamalar yapmak gibi. Aynı girdi, her seferinde aynı çıktıyı vermelidir. Bunun için bir modele ihtiyacımız yoktur.

Günümüzde yapay zeka asistanlarındaki en yaygın ve ölümcül hata “yanlış cevap” vermek değil aslında. Asıl hata, deterministik bir işi örtük bir bağlamda yapmaya çalışmak.

Burası çok önemli, biraz daha açalım;

Diyelim ki bir kullanıcı, müşteri destek asistanınıza şunu sordu: “Eğer bugün iptal edersem, gün bazında toplam iade tutarım ne olacak?”

Sadece llm modeline dayalı çalışan bir yapay zeka asistanı, kullanıcının yıllık 1.200 TL aboneliğine bakar, 214. günde olduklarını görür, bölme işlemini kafasından yapmaya çalışır, aydaki gün sayısını uydurur (halüsinasyon görür) ve kendinden emin bir şekilde 550 TL iade teklif eder.

Doğru mu?

Malesef değil. Tam ve kesin iade tutarı 496.43 TL.

Model, finansal matematiği örtük alanda yapmaya çalıştı ve işletmenize 50 TL zarar ettirmiş oldu.

Sistem prompt’una “İade teklif etmeden önce matematiğini her zaman iki kez kontrol et” yazarak bunu çözmeye çalışabiliriz ama bu pek de işe yaramaz.

Gerçek çözüm, modelin matematik yapma yeteneğini tamamen ortadan kaldırmaktır.

Doğrudan veritabanından sorgu yapabilen bir webservis ve temiz bir JSON çıktısı (payload) döndüren 50 milisaniyelik bir betik (calculate-proration.ts) yazmamız gerekir.

Yani llm’in her seferinde farklı sonuçlar vermesinin muhtemel olduğu ama bizim kesinlik istediğimiz her noktada buna benzer bir işleyiş ayrımı yapmak zorundayız.

---

1. Bağlam Mühendisliği: Bağlam Penceresini RAM Gibi Kullanmak

LLM’lerin sınırlı bir “bağlam penceresi” (context window) vardır.

Bir asistan dışarıdan veri çektiğinde (örneğin crm’den gelen saha raporlarını analiz ederken), geliştiriciler genellikle 50.000 satırlık log kayıtlarını doğrudan prompt’un içine yığarlar. Yapay zeka bunalır, “bağlam şişkinliği” (context bloat) yaşar, ana görevini unutur ve halüsinasyon görmeye başlar.

Mesela, son ay satışların nasıl gittiğini anlamak için, masa üzerinde yığılmış binlerce A4 sayfası ile başbaşa kaldığınızı hayal edin. Ama size önce sadece içerik başlıklarını versem ve ihtiyacınız olduğunda 42. sayfayı istemenize izin verirsem, işiniz çok daha kolay olur değil mi?

Teknik Çözüm: Bağlamı Dışa Aktarmak (Context Offloading)

LLM’in bağlam penceresini asla bir sabit disk gibi görmememiz lazım. Onu bir L1 işlemci önbelleği (L1 CPU cache) gibi düşünmeliyiz.

Asistanımızın bir CSV dosyasındaki 10.000 satırlık kullanıcı geri bildirimini analiz etmesi gerekiyorsa, bu satırları sohbet geçmişine (chat history) gönderemeyiz.

Bunun yerine asistan, ham CSV verisini bir S3 bucket’ına veya bir vektör veritabanına kaydeden bir Python betiği çalıştırır.

Betik, asistana yapılandırılmış, minicik bir yük (payload) döndürür: {"status": "saved", "file_id": "cust_data_99", "summary": "10 bin satır geri bildirim içeriyor."}

Eğer asistanın daha derine inmesi gerekirse, ona query_chunk(file_id, keyword) adında ikincil bir araç sağlarız. Böylece aktif belleğe sadece ihtiyacı olan o tam 5 satırı çekebilir.

---

2. “Üret-Doğrula-Düzelt” Döngüsü

Çoğumuz artık farkındayız, LLM’lerin hepsi aslında “people-pleaser” yani kullanıcı ne yazarsa “ağam, paşam, en çok sen haklısın, bravo” şeklinde cevap vermeye meğillidirler.

Bu yüzden ona, kendi yazdığı cevabı geri yollayıp, “Bu doğru mu?” deseniz, “Evet! Çok doğru, çok haklısın!” diye yanıt döner.

Özellikle kritik altyapılarla uğraşırken, bir LLM’in kendi ödevine not vermesine asla izin vermemek lazım.

Aynen bir yazarın da kendi kitabının editörlüğünü sağlıklı bir şekilde yapamaması gibi düşünün. Beyni yazım hatalarını otomatik olarak doldurur ve düzeltir. Oraya duygusuz, katı bir editörün müdahale etmesi gerekir.

Teknik Çözüm: Deterministik Doğrulama

LLM’in ürettiği ama geleneksel, deterministik yazılımın doğruladığı hibrit graflar inşa etmeliyiz.

Varsayalım ki asistanımız, satış verilerini getirmek için karmaşık bir SQL sorgusu oluşturuyor.

1. LLM SQL dizesini (string) oluşturur.

2. Sistemi körü körüne çalıştırmak yerine, araya girip güvenli bir kopya veritabanında (replica database) bir EXPLAIN komutuyla deneme (dry-run) yapmak lazım.

3. Eğer veritabanı bir hata döndürürse (örneğin, SyntaxError: missing comma at line 3), sistem durur. Bu tam ve ham hata dizisini arka planda LLM’e geri besler: “Sorgun şu hatayla başarısız oldu: [SyntaxError...]. Bunu düzelt.”

Deterministik derleyici, mantığın kusursuz olduğunu kanıtlayana kadar asistan bu döngüde hapsolur.

---

3. Hata Durumu Akışlarını Görünür Hale Getirmek

Hepimiz biliyoruz ki, başarısızlık en büyük öğretmen. Ama bu öğrenimi yapay zeka akışları geliştirirken aklımızda tutmuyoruz.

Geliştiriciler genellikle başarısızlıkları yapay zekalarından saklıyorlar. Ne gerek var…

Bir asistan bir API aracını kullanıp yanlış parametreler gönderdiğinde, mühendisler çökmeleri önlemek için genellikle hatayı bir try/except bloğunda yakalar ama bu hatayı LLM’e geri iletmeyi unuturlar. Yapay zeka da başarılı olduğunu varsayar ve iş akışının geri kalanını halüsinasyonla uydurur.

Bu, gözleri bağlı dart oynamaya benziyor. Dartı fırlatırsınız ve arkadaşınız okun duvara çarptığını söylemek yerine tamamen sessiz kalır. Siz de aynı yanlış yöne doğru fırlatmaya devam edersiniz.

Teknik Çözüm: Kendi Kendini Düzeltmeyi Zorunlu Kılmak

Rotasını düzeltebilmesi için ham API istisnalarını doğrudan LLM’e geri beslemeliyiz.

Bir asistan webservis API üzerinden, satışın detayı için bir crm kaydı yapmaya çalışıyor ama para birimi (currency) parametresini unutuyor. Webservis 400 Bad Request: missing 'currency' parameter hatası fırlatıyor.

Bunu bir terminale kaydedip kullanıcıya bir “Beklenmeyen bir hata oldu” ekranı göstermek yerine, arka ucumuz (backend) webservis hatasını is_error=True bayrağı taşıyan bir ToolMessage formatına dönüştürmesi gerekir.

Bunu LLM’e geri besleriz. Hatayı okur, akıl yürütmesini kullanır ve derhal "currency": "TL" içeren düzeltilmiş bir API çağrısı yapar.

---

4. Test Etme Yöntemlerini Ekonomikleştirmek

Sorun: Yapay zeka denince çoğumuzun aklına su gibi akan token’lar, kredi kartına gelen sürpriz faturalar geliyor.

Bunun en önemli ama pek de üzerinde durulmayan kalemlerinden biri de test süreçlerimiz. Yapay zekayı her koşul ile test edeceğiz derken bir sürü token yakıyoruz.

500 ayrı test case’inin her yeni geliştirme sonrasında tekrar yapıldığını bi hayal edin…

Her tiyatro provası için 50 kişilik canlı bir orkestra kiralamak gibi bir şey bu. Mantıklı olan nedir? Orkestrayı bir kez kaydedersiniz ve oyuncular açılış gecesine kadar o kayıtla pratik yaparlar.

Teknik Çözüm: Oturum Kaydetme:

Karmaşık akıl yürütmeleri bedavaya test etmek için “VCR” test desenini kullanmamız harika bir yöntem.

Bir kullanıcının rezervasyonu yapmasını simüle eden otomatik bir test yazarız. İlk çalışma sırasında VCR yazılımımız canlı ağ çağrılarını yakalar, tam isteği ve LLM’in tam yanıtını basit bir metin dosyasına (bir “kasete”) kaydeder.

Sonraki her test çalışmasında (örneğin GitHub Actions üzerinden), sistem çağrıyı yakalar ve canlı API’ye vurmak yerine doğrudan kasetten kaydedilmiş yanıtı döndürür.

Böylece gerçek LLM çıktılarının nüansını kaybetmeden; yönlendirme mantığımızı, formatlamamızı ve araç yürütmemizi günde 1.000 kez 0 dolar maliyetle titizlikle test edebiliriz.

---

5. Riske Göre Yönlendirilmiş Kademelendirme: “Bir Araç Olarak İnsan”

Sorun: İnsanlar yapay zekaya gerçek bir otonomi vermekten feci şekilde korkuyorlar çünkü “yanlış” iade tutarı hesaplamak veya bir veritabanını silmek gibi bir felaketi tetikleyebileceğini düşünüyorlar.

Bu korkuyla hareket ederek, yapay zekayı adeta lobotomiye uğratıp, işe yaramaz salt okunur (read-only) görevlere hapsediyorlar.

Son derece eğitimli bir banka veznedarı, ihtiyaçlarınızın %90’ını halledebilir. Ama 100.000 dolar çekmek isterseniz, bir şube müdürü gelip bir anahtarı çevirene kadar sistemleri fiziksel olarak kitlidir.

Teknik Çözüm: İki Kişi Kuralı

İnsan onayını, asistanın araç çantasındaki (toolkit) sıradan bir API uç noktası gibi ele almalıyız.

Her araca, kodun içine gömülmüş (hardcoded) bir “Risk Puanı” atamalıyız. read_user_data (kullanıcı verisini oku) düşük risklidir; asistan bunu anında çalıştırır.

Ancak issue_cash_refund (nakit iadesi yap) yüksek risklidir. Asistanın tüm ağır işleri (isteği doğrulamak, JSON yükünü formüle etmek) yapmasına izin verilir, ama sistem son çalıştırmada (execution) araya girer.

İş akışı duraklatılır, durumunu kaydeder ve bir yöneticiye email yollar: “Asistan, 405 Numaralı Kullanıcıya 50$ iade yapmak istiyor. [Onayla] / [Reddet]”.

LLM’e bir sistem prompt’u verilir: “İnsan onayını başarıyla talep ettiniz. Lütfen bekleyin”. İnsan “Onayla”ya tıkladığı anda eylem tetiklenir.

Güvenliği matematiksel olarak işte böyle garanti ederiz. Yapay zekanın yeteneklerini korkudan dolayı köreltmemeliyiz; etkimizi sorumlu bir şekilde ölçekleyebilen ürünler geliştirmek için görev devrini (hand-off) doğru bir şekilde mimarilendirmeliyiz.

---

Yapay Zeka Sihirli Bir Kara Kutu Değil

Kurduğumuz yapay zeka asistanlarımızdan her şeyi tek başına kusursuzca halletmesini beklemek yerine, etraflarına sağlam bir sistem kurmamız lazım.

Kesinlik isteyen hesaplamaları asistandan alıp doğrudan koda devretmeliyiz. Asistana “lütfen hata yapma” diye yalvarmak yerine, hatalarını sistem üzerinden anında gösterip kendi kendini düzeltmesini sağlamalıyız. Kritik yerlerde ise son onayı insana bırakmaktan çekinmemek lazım.

Özetle; asistanlar destan gibi promptlarla veya mucizelerle değil, etraflarına kurduğumuz bu yapısal sınırlarla gelişir. Yapay zekayı sihirli bir kara kutu olmaktan çıkarıp güvenilir bir sisteme dönüştürdüğümüzde, asıl farkı o zaman yaratabiliriz.