Önce sonuç: Müşteri hizmetleri botlarının para yakmasının nedeni yüzde seksen oranında modelin birim fiyatının pahalı olması değil, çağrı yönteminde bir sorun olmasıdır. Şirket içinde günlük birkaç bin aktif kullanıcısı olan bir satış sonrası soru-cevap botumuz, yayına girdikten sonraki ilk ay faturası doğrudan bütçenin üç katına fırladı. İncelediğimizde model birim fiyatının bir kuruş bile değişmediğini, tüm maliyetin çağrı yapısındaki görünmez giderlerden kaynaklandığını gördük. Bu yazıda değerlendirme sürecini kaleme alıyorum; büyük dil modeli API maliyet optimizasyonuyla ilgilenenler kendi faturalarıyla karşılaştırabilir.
Anormal fatura neye benzer
Anormalliğin özelliği "toplamın yüksek olması" değil, "yapının tuhaf olması"dır. Günlük çağrı detaylarını çıkardığımızda üç terslik fark ettik: çağrı hacminin en yüksek olduğu günlerde tek istek başına ortalama token sayısı yukarı doğru gidiyordu; yeniden deneme sayısı oranı neredeyse beşte bire yaklaşıyordu; aynı kullanıcı sorusu bazen birkaç yüz token, bazen on binlerce token sürüyordu, varyans son derece yüksekti. Bu üçü bir araya geldiğinde sorunun model tarafında değil, kendi çağrı zincirimizde olduğunu neredeyse kesin olarak tespit edebiliyoruz.
Dört görünmez gider, her biri diğerinden daha gizli
Birincisi, amiral gemisi modelin kaba iş yapması. Başlangıçta kolaylık olsun diye tüm istekleri tek tip amiral gemisi modelden geçiriyorduk. Ancak müşteri hizmetleri senaryosunda yüzde yetmişten fazlası "siparişim nerede", "nasıl iade ederim" gibi niyet tanıma ve sabit yanıt şablonu gerektiren işler; bu tür görevler için küçük model tamamen yeterli ve maliyet farkı bir mertebe. Amiral gemisi modele "çalışma saatleri kaçta başlıyor" sorusunu yanıtlattırmak, kamyonla yemek dağıtmaya benziyor.
İkincisi, bağlamın sınırsız şişmesi. Çok turlu diyaloglarda geçmiş mesajların tamamını geri gönderiyorduk; kullanıcı onuncu tura geldiğinde sadece geçmiş token'ların büyük kısmını kaplıyordu. Daha can sıkıcısı, geçmişin çoğunun mevcut soruyla hiçbir ilgisi yoktu, sadece boşuna eşlik ediyordu. Bağlam ne kadar uzun olursa o kadar akıllı olmaz; belirli bir uzunluğu geçtikten sonra doğruluk artışı sınırlı kalırken maliyet doğrusal olarak yükselir.
Üçüncüsü, yeniden deneme fırtınası. Basit bir başarısız yeniden deneme ayarlamıştık ama geri çekilme ve devre kesici koymamıştık. Yukarı akışta ara sıra zaman aşımı olduğunda aynı istek grubu tekrar tekrar gönderiliyordu; bir kez başarısız olunca bir kez yeniden deniyor, yeniden deneme yine başarısız olunca yine deniyordu. Faturadaki bu çağrılar tamamen boşa gidiyordu, kullanıcı tarafında ise hâlâ hata görünüyordu.
Dördüncüsü, akışlı ve akışsız çift faturalandırma. En kolay gözden kaçan bu. Bazı zincirlerimizde tam sonucu alıp son işleme yapmak için akışsız bir kez çağırıyorduk; ön uçta daktilo efekti için akışlı bir kez daha çağırıyorduk. Aynı soru, iki ödeme. Sonradan akışlı alım ve yerel birleştirme olarak birleştirdik, bu çift gider ancak o zaman ortadan kalktı.
Katmanlı yönlendirme nasıl uygulanır
Fikir karmaşık değil: görev zorluğuna göre yönlendirme. Niyet tanıma, slot çıkarımı, sabit yanıt şablonları gibi işler hafif modele gider; gerçekten akıl yürütme, çok adımlı karar verme, duygusal yatıştırma gerektiren karmaşık konuşmalar amiral gemisi modele bırakılır. Araya karar vermesi için bir model ağ geçidi eklenir; istek geldiğinde önce sınıflandırıcıdan geçer, görev etiketi vurulur ve hangi modele yönlendirileceğine karar verilir.
Biz göreve göre otomatik en uygun modeli seçme mantığını kullanıyoruz; SiCore TokenWorks'ün çoklu model yönlendirmesinde bir tur karşılaştırma yaptık, basit görevler hafif modele kaydırıldıktan sonra genel maliyet belirgin şekilde düştü, yanıt da daha hızlı oldu. Buradaki kilit nokta "hangi modeli kullanmak" değil, "hangi göreve hangi model" eşleme tablosunun sürekli ayarlanması. Yayına girdiğimiz ilk dönemde deneyime göre yapılandırdık; iki hafta çalıştırdıktan sonra gerçek isabet oranına göre yeniden kalibre ettik, sonuç tahmine göre yapılandırmaktan çok daha iyi oldu. Çoklu model birleşik entegrasyonun avantajı da burada ortaya çıktı: yönlendirme stratejisini değiştirmek için iş kodunu değiştirmek gerekmiyor, ağ geçidi katmanında bir ayar yeterli.
Optimizasyon öncesi ve sonrası fatura karşılaştırması
Somut rakam vermeyeceğim, oran vereceğim. Toplam çağrı hacmi değişmedi, çünkü kullanıcı sayısı değişmedi. Toplam maliyet yaklaşık yüzde altmış düştü; bunun içinde amiral gemisi model çağrı payı neredeyse yüzde yüzden yüzde otuza kadar indi, geri kalanı hafif modele dağıldı. Yeniden denemeyle ilgili çağrılar neredeyse beşte birden tek haneli yüzdelere çekildi. Tek istek başına ortalama token sayısı yaklaşık yüzde kırk azaldı, bu esas olarak bağlam kırpmasından geldi. Akışlı çift faturalandırma kısmı doğrudan sıfırlandı. Genel hesapta bütçeyi üç kat aşmaktan bütçe içinde artı paya döndük.
İzleme ve uyarı nasıl yapılandırılır
Tasarruf edilen parayı korumak öz disiplinle değil, izlemeyle olur. Dört uyarı yapılandırdık: tek istek token sayısı eşiği aşınca tetiklenir, bağlamın kontrolden çıkmasını önler; yeniden deneme oranı belirlenen oranı aşınca tetiklenir, yeniden deneme fırtınasını önler; amiral gemisi model çağrı payı anormal yükselince tetiklenir, yönlendirmenin bozulmuş olabileceğini gösterir; günlük maliyetin günlük değişim artışı eşiği aşınca tetiklenir. Bu dördünü çok karmaşık yapmaya gerek yok; günlük toplama ve çizgi aşımı uyarısı yeterli. Token faturalandırma modelinde maliyet gerçek zamanlı birikir; ay sonunda faturaya bakıp optimize etmeyi beklerken para çoktan harcanmış olur.
Tek cümleyle özet: Müşteri hizmetleri botunun maliyetinin büyük kısmı çağrı yapısında, model birim fiyatında değil. Katmanlı yönlendirme, bağlam kırpma, yeniden deneme kontrolü ve akışlı birleştirme — bu dört işi sağlam yapın, fatura kendiliğinden düşer. Bir adım ileri gidersek, senaryonuzda RAG erişimi de varsa, vektör veritabanının geri getirme sayısı da aynı mantıkla bir kez gözden geçirilmeye değer.