Sistemimiz tek bir şeyi çok iyi yapıyordu: Doğal dildeki soruları API çağrılarına dönüştürmek.
Kullanıcı kitlemiz analistler, hesap yöneticileri ve operasyon liderlerinden oluşuyordu. Hangi verilere ihtiyaç duyduklarını çok iyi biliyorlardı; ancak bu veriyi manuel olarak derlemek; dört farklı dashboard, iki BI aracı ve bir Salesforce rapor oluşturucusu arasında gidip gelmek demekti. Sistemimiz sayesinde, kullanıcıların sadece yalın bir dille isteklerini yazmaları yeterliydi. “2026 Ocak-Mart dönemi için Kuzeydoğu bölgesindeki satış hacmi raporunu şehirlere göre dökümle” gibi bir talep, sistemin işleyebileceği bir API çağrısına dönüştürülüyordu:
"description": "Kullanıcı belirtilen tarih aralığı için satış hacmi istedi, API çağrısı aşağıdadır",
"api_call": "/api/sales_volume"
Pipeline’ın geri kalanı geleneksel mühendislik prensipleriyle çalışıyordu. Sistem, çağrıyı ilgili arka uca (dahili raporlama portalları, Salesforce ve çeşitli özel hizmetler ile entegrasyonlarımız mevcuttu) iletiyor, yanıtı filtrelemek ve biçimlendirmek için LLM tarafından üretilen bir JSON sorgusunu uyguluyor ve sonucu e-posta, Drive dokümanı veya tarayıcıda bir grafik olarak sunuyordu.
2025 yılının ortalarına gelindiğinde sistem ayda birkaç yüz rapor üretiyordu. Bu raporlar liderlik kadrosu ve analistler tarafından tüketiliyor, dış paydaşlara iletiliyordu. Artık ekiplerin büyük çoğunluğu için ad-hoc veri çekmenin varsayılan yolu haline gelmişti.
LLM ile sistemin geri kalanı arasındaki “sözleşme”, yukarıdaki örnekte görülen yapılandırılmış JSON nesnesiydi.
2025’in başında sistemi Claude Sonnet 3.5 üzerine inşa ettik. 3.7’ye ve ardından 4.0’a geçişlerimiz sorunsuz oldu. Sonnet 4.5 sürümü yayınlandığında, LLM’lerin basit problemleri çözmedeki kararlılığı ve öngörülebilirliği konusunda fazlasıyla rehavete kapılmıştık. Model güncellemeleri, tıpkı iyi huylu bir kütüphanenin minor sürümünü yükseltmek kadar rutin bir iş haline gelmişti.
Ardından 4.5 sürümünü yayına aldık. İsteklerin önemli bir kısmında model, post_body içeriğini hatalı bir şekilde description alanına gömmeye başladı. Bunun sonucunda iki ana hata modu ortaya çıktı.
İlki şuydu: Filtre parametreleri asla API’ye ulaşmadı. Sistemimiz, istek yükü (payload) için post_body alanını “doğru kaynak” olarak kabul ediyordu ve bu alan boş geliyordu. API çağrısı, tarih aralığı veya bölge filtresi olmadan gerçekleşti. İlgili API’nin yapısına bağlı olarak arka uç, ya tüm zamanların/tüm bölgelerin verisini döndürdü ya da bir 500 hatası verdi.