Canlıdaki Yapay Zeka Ajanlarının Yarısı, GPU Faturası Eklenmiş `if` Koşullarından İbaret

Yazılım geliştirme dünyasında yeni bir teknik borç türü ortaya çıkıyor: "Özgeçmiş odaklı yapay zeka mühendisliği" (resume-driven AI engineering). Bu yaklaşım, problemin gerçek ihtiyacından ziyade CV'de etkileyici durduğu gerekçesiyle bir ajan çatısı, vektör veritabanı veya çok modelli orkestrasyon katmanı seçmek anlamına geliyor. Ortaya çıkan çözüm demoda kusursuz çalışsa da canlı ortama (production) alındığında çok daha yavaş, maliyetli, hata ayıklaması zor ve gereksiz yere deterministik olmayan bir yapıya dönüşüyor.

Demo Büyüsü ve Canlı Ortam Gerçekleri

Bir eğitim içeriğinde veya demoda karmaşıklık bedavadır. Birkaç satır kodla bir ajan kurabilir, vektör deposunu bağlayabilir ve on adet örnek doküman üzerinde sihirli sonuçlar üretebilirsiniz. Ancak canlı ortamda her hareketli parçanın somut bir bedeli vardır: gecikme süresi (latency), token harcaması, yeni hata modları ve gece saat 3'te nöbetçi mühendisin anlaması gereken yeni kırılma noktaları. Buradaki temel mühendislik sorusu şudur: "Bir LLM bunu yapabilir mi?" değil, "LLM bu işi güvenilir biçimde yapan en yalın araç mı?"

İşte sektörde bu sorunun yanıtının genellikle "hayır" olduğu üç tipik hata modu:

1. Regex Yetecek Yerde Model Çağrısı Yapmak

Gelen e-postalardan belirli bir şablondaki fatura numaralarını (örneğin INV- ve ardından gelen sekiz basamak) ayıklamak isteyen bir ekip, her e-postayı LLM'e göndererek numarayı çıkarmasını ister. Bu yaklaşım %98 oranında çalışsa da kalan %2'lik kısımda model numarayı yeniden biçimlendirir ya da alakasız bir sipariş kodunu seçer. Üstelik her çağrı gecikme ve ek maliyet üretir.

Pratik Çıkarım: Belirli desenlere sahip yapılar için mikrosaniyeler içinde çalışan, deterministik, birim testleri kolay ve neredeyse sıfır maliyetli Regex kullanın. LLM'i yalnızca kuralın yetersiz kaldığı karmaşık uç durumlar (edge case) için bir yedek (fallback) yönlendirme katmanı olarak tutun.

2. SQL Yetecek Yerde Vektör Arama Yapmak

"Müşteri 4417'nin son 30 gündeki ödenmemiş tüm siparişlerini göster" sorgusu semantik bir soru değil, kesin bir veritabanı filtresidir. Buna rağmen bu sorguyu embedding'e çevirip vektör veritabanında aratmak ve LLM'e özetletmek sık yapılan bir hatadır. Bu yöntem, eksik veya halüsinasyon içeren sonuçlar doğurur.

Pratik Çıkarım: SQL sorguları kesin, eksiksiz, indekslenebilir ve denetlenebilirdir. Vektör araması anlamsal benzerlikleri eşleştirmek için güçlüdür; fakat somut olgusal verileri ve kesin kuralları filtrelemek için yanlış araçtır.

3. Karar Ağacı Yetecek Yerde Otonom Ajan Kurmak

Kurumsal müşteri ve fatura sorunu varsa hesap yöneticisine yönlendir; hata bildirimi ise bilet aç; aksi halde SSS bağlantısı gönder. Bu süreç yalnızca dört dallı basit bir akıştır. Bunu planlama döngüsü ve bellek mekanizması olan otonom bir ajanla çözmeye çalışmak, yönlendirmeyi olasılıksal hale getirir, döngülere yol açar ve hataların nedenini belirsizleştirir.

Pratik Çıkarım: Mantığını bir beyaz tahtaya akış şeması olarak çizebildiğiniz kurallar için ajanın bunu her seferinde baştan keşfetmesine gerek yoktur. Basit bir karar ağacı veya if/else yapısı çok daha güvenilir, kararlı ve maliyetsizdir.

[Orijinal kaynağa buradan ulaşabilirsiniz.](https://dev.to/cyclopt_dimitrisk/half-the-ai-agents-in-production-are-if-statements-with-a-gpu-bill-4934)

Bu konuyu derinlemesine öğrenmek isterseniz: Production'da Agent Güvenilirliği modülüne göz atın.