Kimsenin Modellemediği Fatura: LLM Harcaması Nereye Gidiyor

Neredeyse her üretim LLM faturasındaki ilk sürpriz, faturanın tahmine benzememesidir. Tahmin ortalama bir istek üzerinden kurulmuştur: şu kadar girdi tokenı, şu kadar çıktı tokenı, beklenen hacimle çarpılır. Fatura ise kuyruktan doğar. Çıktı tokenları esasen her sağlayıcıda girdi tokenlarının bir katı olarak fiyatlanır. Oran sağlayıcıdan sağlayıcıya değişir ve zamanla da değişir, ama daima bir kattır, asla eşitlik değildir. Bu da uzun düzyazı üreten bir iş yükünün, aynı bilgiyi taşıyan kısa ve yapılandırılmış bir nesne üreten iş yükünden yapısal olarak daha pahalı olması demektir. Tahminlerinde girdiyi ve çıktıyı hiç ayırmayan ekipler, kendi harcamalarını öngöremeyen bir modelle çalışıyor demektir.

Kimsenin bütçelemediği ikinci kalem yeniden denemelerdir. Otomatik yeniden denemeyle birlikte yüzde üçlük bir iletim hatası oranı harcamaya yüzde üç ekler ve bu sorun değildir. Doğrulama hatası döngüsü ise sorundur: model bozuk yapılandırılmış çıktı döndürdüğünde ve kodunuz düzeltici bir mesajla yeniden denediğinde başarısız denemeyi de, düzeltici promptu da, ikinci üretimi de ödersiniz. Devraldığımız iş yüklerinde toplam harcamanın yüzde 20 ila 40'ı kadar yeniden deneme yükü sık görülür ve bu neredeyse her zaman görünmezdir, çünkü yeniden denemeler uygulama düzeyinde başarı olarak loglanır. Biri parayı aramaya başlayana kadar kimse başarılı yanıt başına deneme sayısını bir metrik olarak izlemez.

Üçüncü ve en büyüğü ajan döngüsüdür. Tek çağrılık bir iş akışı bir çağrı eder. Bir görevi 8 ila 15 adımda yürüten bir ajan 8 ila 15 çağrı eder ve her adım birikmiş geçmişi yeniden gönderdiği için toplam token, adım sayısıyla doğrusal değil kabaca karesel büyür. Buna uzun bir sistem promptu ekleyin, aritmetik hızla çirkinleşir: 20 turluk bir konuşmada 4.000 tokenlık bir sistem promptu, daha kimse işe yarar bir şey söylemeden 80.000 tokenlık saf tekrar demektir. Gartner, kuruma özgü uygulamaların yüzde 40'ının 2026 sonuna kadar göreve özel yapay zeka ajanları içereceğini, bu oranın 2025'te yüzde 5'in altında olduğunu öngörüyor; yani bu fatura biçimi yakında normal biçim hâline gelecek.

Model Yönlendirme (model routing) Tek Cümlede

Her isteği onu gerçekten kaldırabilecek en ucuz modele yönlendirin. Fikrin tamamı bu ve gücünü ortalamaların gizlediği bir gerçekten alıyor: iş yükleri türdeş değildir. Gördüğümüz üretim sistemlerinde trafiğin kabaca yüzde 60 ila 80'i rutin iştir; gelen bir mesajı sınıflandırmak, bir formdan alan çıkarmak, kısa bir metni özetlemek, metni yeniden biçimlendirmek, retrieval katmanının zaten cevapladığı bir soruyu yanıtlamak. Belki yüzde 10 ila 25'i gerçekten mevcut en güçlü modeli gerektirir: çok adımlı akıl yürütme, belirsiz talimatlar, çelişkili kaynaklar arasında sentez ve yanılmanın pahalıya patladığı her şey. Aradaki fark, bir e-postanın hangi departmana gideceğini belirlemekle bir sözleşmedeki çelişkili iki maddeyi uzlaştırmak arasındaki farktır ve bu iki işi aynı fiyattan çalıştırmak için hiçbir mühendislik gerekçesi yoktur.

Hepsini en güçlü modele gönderirseniz sınıflandırma işine sınır modeli fiyatı ödersiniz. Hepsini küçük bir modele gönderirseniz trafiğin zor çeyreğinde başarısız olur ve kullanıcı kaybedersiniz. Tüm uygulama için tek model seçmek, iş yükünün tamamını en zor isteğin maliyeti üzerinden fiyatlamaya zorlar; bu da bir sunucu filosundaki her makineyi tepe yüke göre boyutlandırmakla aynı hatadır. ICLR 2025'te yayımlanan RouteLLM makalesi, MT-Bench üzerinde GPT-4 kalitesinin yaklaşık yüzde 95'ini korurken yüzde 85'e varan maliyet düşüşü bildirdi; bu, aynı noktanın akademik ifadesidir: isteklerin çoğu pahalı modele ihtiyaç duymaz ve bir yönlendirici hangilerinin duyduğunu ayırt edebilir.

Model yönlendirmenin ne olmadığını da net söylemek gerekir. Bir makine öğrenmesi projesi değildir. Elde edilebilir tasarrufun ezici çoğunluğu, iş yükünü anlayan birinin yazdığı sıkıcı ve deterministik kurallardan gelir; sofistike yaklaşımlar bunun üzerine mütevazı bir artış ekler. Bir yönlendirici sınıflandırıcısı eğiterek başlayan ekipler genellikle iki günde ulaşabilecekleri sonuca iki ayda varır. Kurallarla başlayın, ölçün ve yalnızca kuralların gösterilebilir biçimde yanlış yönlendirdiği yerlere zeka ekleyin. Bu, küçük dil modelleri için önerdiğimiz işlem sırasının aynısıdır: ucuz yolun bir dilimde çalıştığını kanıtlamadan onu sanayileştirmeyin. Ölçüm olmadan eklenen her katman, sonradan neyin gerçekten işe yaradığını ayırt etmenizi imkânsızlaştırır.

Yönlendirme Kararı Nerede Verilir: Ağ Geçidi (gateway) Katmanı

Yönlendirmenin yaşayacağı bir yere ihtiyacı var ve o yer bir ağ geçididir: her model çağrısının geçtiği tek katman. Model adı uygulamanızın kırk farklı çağrı noktasında sabit yazılmışsa sizin bir yönlendirme probleminiz yok, bir refactoring probleminiz var demektir ve bu düzelene kadar hiçbir akıllı yönlendirici tasarımı işe yaramaz. Ağ geçidi; model seçimi, sağlayıcı hatasında yedeğe geçme, yeniden deneme politikası, önbellekleme, bütçe uygulaması, hız sınırlama ve yapılandırılmış loglamanın hepsinin ait olduğu yerdir. LiteLLM tam olarak bu katmanın yaygın kullanılan bir açık kaynak uygulamasıdır ve kendi ince sürümünüzü yazmak birkaç günlük iştir. Hangi yolu seçerseniz seçin, kritik olan kararın tek bir yerde verilmesidir; uygulamaya dağılmış bir kararı sonradan merkezileştirmek çok daha pahalıya mal olur.

Ağ geçidinin yönlendirme yapabilmesi için metaveriye ihtiyacı var ve ekiplerin eksik tasarladığı kısım burasıdır. Her çağrı şunları taşıyarak gelmelidir: görev tipi, ki en öngörücü tek sinyaldir; müşteri ya da kiracı bilgisi, çünkü kurumsal katmanların sözleşmeye bağlı model gereksinimleri olabilir; kullanıcı seviyesi, çünkü ücretsiz plan ile ücretli plan meşru biçimde farklı rotalar alabilir; gecikme bütçesi, çünkü etkileşimli bir sohbetle gece çalışan bir toplu işin kısıtları tamamen farklıdır; ve veri hassasiyeti bayrağı, çünkü bazı içerikler maliyet ne olursa olsun belirli bir yargı alanından çıkmamalı ya da kurum içi bir modelde çalışmalıdır. Bu beş alanı isteğin başladığı yerde doldurmak, sonradan çağrı gövdesine bakıp çıkarım yapmaya çalışmaktan çok daha ucuzdur.

Bu son boyut, maliyet mühendisliğinin uyumla buluştuğu yerdir ve düzenlemeye tabi Türkiye kurulumlarında yönlendirme ile yönetişimin neden aynı konuşma olduğunu açıklar. 6698 sayılı Kanun kapsamında özel nitelikli kişisel veriye dokunan bir istek, daha ucuz olduğu için değil tek hukuka uygun seçenek olduğu için kurum içi bir modele yönlendirilebilir ve bunu dayatmanın tek makul yeri ağ geçididir. Metaveri akmaya başladıktan sonra yönlendirme kurallarının kendisi genellikle otuz satır koddur. Asıl mühendislik işi metaveriyi ağ geçidine taşımaktır ve bu işi düzgün yapmaya değer, çünkü bu yazıdaki diğer her şey buna bağlıdır. Metaverisi olmayan bir ağ geçidi yalnızca bir vekil sunucudur ve tek başına hiçbir maliyet kazancı getirmez.

Yönlendirici Tipleri ve Gecikme Maliyetleri

Kural tabanlı yönlendirme bir tablo bakışı ve birkaç karşılaştırmadır: uç nokta görev tipini, belge uzunluğu bağlam gereksinimini, kiracı bilgisi seviyeyi belirler. Milisaniye mertebesinde çalışır. Gösterişsizdir, tamamen açıklanabilirdir, kolayca test edilir ve deneyimimizde ilk geçişte elde edilebilir tasarrufun büyük çoğunluğunu yakalar. Her yönlendirme programı buradan başlamalı ve ölçüm kuralların anlamlı bir trafik payını yanlış yönlendirdiğini kanıtlayana kadar burada kalmalıdır. Kod incelemesinde okuyabildiğiniz bir kural, bir müşteri cevapların kötüleştiğini söylediğinde gecenin ikisinde ayıklayabildiğiniz kuraldır da. Pratikte ilk tur kurallar genellikle üç beş satırdan ibarettir: kısa sınıflandırma istekleri küçük modele, uzun belge analizleri orta modele, çok adımlı akıl yürütme gerektiren istekler en güçlü modele. Bu kadarı bile çoğu ekipte faturayı gözle görülür biçimde aşağı çeker.

Embedding benzerliğine dayalı yönlendirme, gelen isteğin embedding'ini çıkarır ve her rota için etiketlenmiş merkezlerle karşılaştırır. Bir embedding çağrısı maliyeti getirir, tipik olarak 10 ila 40 milisaniye, ve aynı uç noktanın gerçekten farklı türde sorular aldığı durumu çözer. semantic-router projesi yaygın açık kaynak referansıdır. Bir adım ötesinde, kendi etiketlenmiş trafiğinizle eğitilmiş küçük bir encoder sınıflandırıcısı onlarca milisaniyede çalışır ve merkez temelli yaklaşımın kodlayamayacağı incelikleri yakalayabilir; bedeli bir etiketleme çalışması ve trafik dağılımı her kaydığında bakımını ve yeniden değerlendirmesini üstlendiğiniz bir modeldir. Bu maliyeti üstlenmeden önce kuralların gerçekten yetersiz kaldığını ölçümle gösterin; aksi hâlde bakım yükünü hiçbir karşılığı olmadan satın almış olursunuz.

LLM'i yönlendirici olarak kullanmak pahalı seçenektir: hangi modeli çağıracağınıza karar vermek için bir model çağırırsınız. Tam bir çıkarım maliyeti getirir, tipik olarak yüzlerce milisaniyeden birkaç saniyeye kadar, üstüne token ödersiniz ve yalnızca yönlendirme kararı daha ucuz hiçbir şeyin sağlayamayacağı bir anlayış gerektiriyorsa haklı çıkar. Çoğu sistemde bu, görev taksonomisinin yeterince düşünülmediğinin işaretidir. Büyüklük mertebelerini bir mühendis gibi okuyun: yaklaşık bir milisaniyelik bir kural ve onlarca milisaniyelik bir sınıflandırıcı, yüzlerce ila binlerce milisaniyeyle ölçülen çıkarımın bir ila üç büyüklük mertebesi altında durur. Gecikme, yönlendirme yapmamak için neredeyse hiçbir zaman savunulabilir bir gerekçe değildir.

Kademeli Yapı (cascade): Önce Ucuz, Şüphede Yükselt

Kademeli yapı yönlendirme sorusunu tersine çevirir. Bir isteğin hangi modele ihtiyaç duyacağını önceden tahmin etmek yerine ucuz modeli çalıştırır, cevabın yeterince iyi olup olmadığını kontrol eder ve yalnızca değilse yukarı yükseltirsiniz. Bu, tahminden kesinlikle daha isabetlidir, çünkü soruya bakıp tahmin yürütmek yerine gerçek bir cevabı değerlendiriyorsunuzdur ve zarif biçimde bozulur: yanlış değerlendirilmiş bir yükseltme kaliteye değil paraya mal olur. Desenin bedeli fazladan bir karar adımı ve yükseltilen isteklerde boşa giden bir ucuz çağrıdır. Tasarım sorusunun tamamı güven kontrolüyle ilgilidir. Kontrol ucuz ve güvenilir değilse kademeli yapı çözdüğünden fazla problem üretir; bu yüzden desenin başarısı model seçiminden çok kontrolün tasarımına bağlıdır.

Bu kontrol için seçenekleriniz, kabaca güvenilirlik sırasına göre: uygulanabildiği her yerde en iyisi olan deterministik doğrulayıcı. Çıktı şemaya göre ayrıştırılıyor mu, zorunlu alanlar var mı, çıkarılan toplam satır kalemlerinin toplamına eşit mi, atıf verilen belge kimliği gerçekten getirilen belgelerden biri mi. Sonra sağlayıcının açtığı durumlarda logprob temelli belirsizlik. Sonra iki bağımsız ucuz koşu arasındaki mutabakat; ucuz maliyeti ikiye katlar ama çıkarım görevlerinde çok etkilidir. Sonra küçük bir hakem modeli. En sonda ve en güvenilmezi, modelin kendi beyan ettiği güven skoru; tek başına neredeyse değersizdir ve asla tek kapınız olmamalıdır. Pratikte en iyi sonucu, deterministik doğrulayıcıyı temel alıp yalnızca doğrulayıcının sessiz kaldığı vakalarda ikinci bir sinyale başvurmak verir.

Aritmetiği bir beyaz tahtada yapılabilecek kadar basittir. Ucuz model trafiğin bir kısmını başarıyla hallediyor ve gerisi yükseliyorsa toplam maliyetiniz her istek için bir ucuz çağrı artı yükselen pay için bir pahalı çağrıdır. Kademeli yapı, ucuz çağrı pahalı çağrının küçük bir kesri olduğu ve yükseltme oranı düşük kaldığı sürece kazandırır; yükseltme oranı tırmandığında kazandırmayı bırakır, çünkü o noktada isteklerin çoğunda iki modeli birden ödüyorsunuzdur. Yükseltme oranını birinci sınıf bir metrik olarak ölçün ve alarm kurun; çünkü yükselen bir yükseltme oranı, genellikle trafik karışımınızın ayağınızın altından kaydığının ilk görünür işaretidir. Eşik değerlerini de sürüm kontrolüne alın; sessizce gevşetilmiş bir eşik, sessizce bozulmuş bir kalite demektir.

Prompt Önbellekleme (prompt caching) ve Sabit Önek

Prompt önbellekleme mevcut en ucuz kazançtır ve yalnızca prompt yapısı yüzünden en sık masada bırakılan kazançtır. Sağlayıcılar promptunuzun bir önekini önbelleğe alır ve o öneki paylaşan sonraki isteklerde önbelleğe alınmış girdi tokenları için belirgin biçimde daha az ücretlendirir. Koşul katıdır: önek bir istekten diğerine token token aynı olmalıdır. Onuncu karakterdeki tek bir fark, sonrasındaki her şeyi geçersiz kılar. Bu, prompt düzenini üslup meselesi olmaktan çıkarıp maliyet kararına dönüştürür ve güzel okunan bir promptun biraz daha kötü okunan bir prompttan birkaç kat pahalıya gelmesinin nedeni budur. Önbellek isabet oranını ölçmeyen ekipler bu kaybı hiçbir zaman göremez, çünkü fatura yalnızca toplamı gösterir.

Kural doğrudan bundan çıkar: önce statik içerik, sonra dinamik içerik. Sistem talimatları, araç ve fonksiyon tanımları, örnek gösterimler, politika metni, sözlükler ve uzun referans belgeleri en üste, sabit bir sırayla yerleşir ve hiç yer değiştirmez. Kullanıcının o anki turu, getirilen parçalar, zaman damgaları, oturum kimlikleri ve istek başına değişen her şey en alta iner. Klasik hata, sistem promptunun tepesindeki güncel tarih satırı veya istek kimliğidir; ayıklama için kullanışlıdır ve önbelleği her çağrıda yok eder. İkinci klasik hata, birbirinin aynı sorgularda sırası kararlı olmayan getirilmiş parçalardır. Retriever'ınız aynı sorguya aynı sırayı vermiyorsa, önbelleğe uygun görünen bir promptunuz olsa bile isabet oranınız sıfıra yakın kalır.

İki uyarı bu tabloyu dürüst tutar. Önbellek ömürleri kısadır, tipik olarak dakikalarla ölçülür; bu yüzden önbellekleme yoğun ve çok turlu konuşmalarda muazzam kazandırır, saatler arayla gelen seyrek tek atımlık trafikte neredeyse hiç kazandırmaz. Ayrıca çok uzun sistem promptlu iş yüklerinde önbellekleme sıklıkla model seçiminden daha fazla tasarruf sağlar; bu da doğru iş sırasının şu olduğu anlamına gelir: önce prompt yapısını düzeltin, sonra yönlendirin, sonra kademeli yapıyı düşünün. Yönlendirmenin bağlam mühendisliği ile örtüştüğü yer burasıdır ve uzun bağlam mı RAG mi sorusunun mimari tercih değil maliyet kararı hâline geldiği yer de burasıdır.

Çıktı Token Disiplini

Çıktı, faturanın hem pahalı hem yavaş yarısıdır; çünkü üretim, girdiyi okumanın olmadığı bir biçimde sıralıdır. Modelin yazdığı her token para eder ve gecikme ekler, dolayısıyla iki kat uzun bir cevap hiçbir ek bilgi taşımadan kabaca iki kat pahalı ve iki kat yavaştır. En etkili tek müdahale, cevabı tüketen taraf kodken düzyazı istemeyi bırakmaktır. Sonucu bir alt servis ayrıştıracaksa şemaya bağlı yapılandırılmış bir nesne isteyin, başka hiçbir şey değil. Deneyimimizde sohbet biçimli bir promptu şema kısıtlı bir prompta çevirmek, aynı bilgi içeriği için çıktı tokenlarını yüzde 30 ila 60 azaltıyor. Üstelik kazanç yalnızca parasal değil: kısalan çıktı, kullanıcının ilk tam cevabı görme süresini de aşağı yukarı aynı oranda kısaltır.

Görev başına azami token limitini bir emniyet supabı olarak değil, bilinçli bir bütçe olarak belirleyin. Prompta kısa ve öz ol yazmak bir ricadır; sert bir limit ise bir kontroldür ve model, tesadüfen en büyük müşterinizden gelen o tek istekte kapsamlı olmaya karar verdiğinde bu fark önemlidir. Çıktının doğal bir sonlandırıcısı varsa durdurma dizileri kullanın. Modelin üretmek yerine seçim yaptığı yerlerde içerik değil kimlik isteyin: bir belge kimliği ve karakter aralığı döndürmek bir avuç token eder, işaret ettiği paragrafı yeniden yazmak yüzlerce token eder ve yeniden yazılmış hâli ayrıca ince biçimde yanlış olabilir.

Sonra prompta diğer yönden bakın. Örnek gösterimler, önbelleğe girmeyen her çağrıda ödediğiniz girdi tokenlarıdır ve ekipler rutin olarak üçünün yeteceği yerde sekiz örnek taşır, çünkü ayıklama sırasında eklenenleri kimse geri çıkarmamıştır. Akıl yürütme gerektirmeyen görevlerdeki uzun düşünme zinciri talimatları, ödeyip sonra attığınız akıl yürütme tokenları üretir. Gerçekten zor problemlerde bu akıl yürütme değerlidir; akıl yürüten modeller bu yüzden varsayılanınız değil belirli bir rotanın sahibi olmalıdır. Onları görev tipine göre yönlendirmek, ağ geçidinin tam da vermek için var olduğu türden bir karardır. Akıl yürütmeyi varsayılan olarak açık bırakmak, buna ihtiyaç duymayan görevlerde faturayı sessizce katlar.

Toplu İşleme (batching) ve Asenkron İşleme

Sağlayıcıların çoğu, gecikmeyi belirgin bir indirimle takas eden bir toplu işleme yolu sunuyor: bir istek kümesi gönderirsiniz, sonuçları saatlerle ölçülen bir pencere içinde alırsınız ve token başına anlamlı biçimde daha az ödersiniz. İlginç soru indirimin var olup olmadığı değil, iş yükünüzün ne kadarının gerçekten eşzamanlı olduğudur. Pratikte ekiplerin varsaydığından çok daha azı. Önceki günün taleplerinin gece sınıflandırılması, bir arşivde metaveri geriye dönük doldurma, model yükseltmesinden sonra embedding'leri yeniden üretme, bir katalogu zenginleştirme, bir değerlendirme paketi koşturma: hiçbiri iki saniyede cevap istemez ve hepsi rutin olarak etkileşimli uç noktadan geçirilir, çünkü kod zaten öyle yazılmıştır.

Asenkron hâle getirmek yalnızca maliyeti değil ürün tasarımını da değiştirir. Uzun bir belgeyi analize gönderip hazır olduğunda bildirim alan bir kullanıcı, doksan saniye boyunca dönen çarkı izleyen kullanıcıdan daha iyi bir deneyim yaşar; üstelik asenkron sürüm kullanıcı fark etmeden toplu işlenebilir, yeniden denenebilir, önceliklendirilebilir ve hız sınırına tabi tutulabilir. Tasarım kuralı şudur: cevabı gerçekten bir insanın beklediği istekleri belirleyin, onları sıkı bir gecikme bütçesiyle etkileşimli yolda tutun ve geri kalan her şeyi maliyet optimizasyonunun bedava olduğu bir kuyruğa itin. Bu ayrımı yapmadan önce ekiplerin çoğu iş yükünün tamamını eşzamanlı sanır; ayrımı yaptıktan sonra genellikle isteklerin yarısından azının gerçekten bir insanı beklettiği ortaya çıkar.

Tekilleştirme de aynı bölüme aittir, çünkü aynı içgörünün tekrara uygulanmış hâlidir. Belirli bir zaman penceresi içinde birebir aynı isteklerde tam eşleşmeli önbellekleme uygulaması çok kolaydır ve özellikle birçok kullanıcının aynı soruyu aynı şekilde sorduğu destek ve kurum içi araç yüklerinde beklenenden fazlasını yakalar. Anlamsal önbellekleme, yani neredeyse aynı bir sorgunun benzerlik eşiğinin üzerinde önceden hesaplanmış bir cevabı döndürmesi, deneyimimizde bu tür iş yüklerinde tipik olarak yüzde 10 ila 30 isabet oranına ulaşıyor. Eşiği temkinli belirleyin, her isabeti loglayın ve önbellekten gelen bir cevabın asla kiracı sınırını geçemeyeceğinden emin olun. Anlamsal önbellek izin modelini atlayan bir yan kanala dönüşürse, tasarruf ettiğiniz paranın çok üstünde bir bedel ödersiniz.

Asıl Risk: Sessiz Kalite Gerilemesi

Yönlendirmeyi tehlikeli kılan ve deneyen birçok ekibin sessizce geri almasına yol açan başarısızlık biçimi şu. Yönlendirme yanlış gittiğinde hata fırlatmaz. Ucuz model akıcı, kendinden emin, makul görünen ve biraz daha kötü bir cevap döndürür: düşen bir nüans, atlanan bir koşul, yuvarlanan bir sayı, çıkarılan bir çekince. Hiçbir şey başarısız olmaz. Hiçbir alarm çalmaz. Maliyet paneli aşağı iner ve herkes birbirini tebrik eder; altı hafta sonra destek ekibi cevapların son zamanlarda tuhaf hissettirdiğini söyler ve kimse ne zaman başladığını gösteremez, çünkü değişiklikten önce hiçbir şey ölçülmemiştir. Bu, klasik yazılım hatalarından bambaşka bir başarısızlık sınıfıdır: sistem çalışmayı sürdürür, yalnızca biraz daha kötü çalışır.

Savunma, değişiklik yayına çıktıktan sonra değil merge olmadan önce koşan bir değerlendirme kapısıdır. Görev tipi başına sabit bir değerlendirme seti kurun; ilk üretim iş yükü için 100 ila 300 vaka gerçekçi bir başlangıç boyutudur. Notlandırılmış beklenen çıktılarla birlikte tutun ve yönlendirme kurallarında, model sürümlerinde, promptlarda veya eşiklerde her değişiklikte koşturun. Bir geçme eşiği belirleyin ve altındaki merge işlemlerini reddedin, tıpkı başarısız bir birim testinde yapacağınız gibi. Bu, yapay zeka gözlemlenebilirliği ve eval yazısında anlatılan disiplinin, ucuz rotanın yeterince iyi olup olmadığı sorusuna uygulanmış hâlidir. Değerlendirme seti bir kez kurulduğunda, sonraki her yönlendirme fikri haftalar değil dakikalar içinde denenebilir hâle gelir.

Kapının gerçekten işlemesini iki ayrıntı sağlar. Birincisi, kaliteyi rota başına ölçün, asla toplamda değil: toplam skor rahat görünmeye devam ederken ucuz rota, en kötü hallettiği yüzde on beşlik trafikte ciddi biçimde bozulur ve pahalı rotanın iyi skorları bunu maskeler. İkincisi, trafiği çevirmeden önce gölge modunu kullanın. Aday rotayı mevcut rotayla paralel çalıştırın, iki çıktıyı da loglayın, çevrimdışı karşılaştırın ve ancak ondan sonra canlı trafiğin küçük bir yüzdesini taşıyın. Yönlendirme değişiklikleri şema migration'ları kadar sürüm disiplini hak eder, çünkü bir sistemi haftalar sonra yüzeye çıkacak biçimde bozma kapasiteleri en az onlarınki kadardır.

İş Akışı Başına Maliyeti Ölçmek ve Bizim Uygulamamız

Önemli olan metrik iş akışı yürütmesi başına maliyettir; token başına maliyet değil, aylık fatura hiç değil. Hacimle birlikte artan toplam harcama sağlıklı bir işletmedir; yürütme başına maliyetin artması ise bir gerilemedir ve yalnızca ikincisi size eyleme dönüştürülebilir bir şey söyler. Ölçmek için her iş akışının giriş noktasında bir iz kimliği iliştirin ve o izin altında yapılan her çağrının token sayılarını, model kimliklerini ve gecikmelerini biriktirin; yeniden denemeler, yükseltmeler, güvenlik bariyeri çağrıları ve embedding çağrıları dahil. Tamamlanan yürütme sayısına bölün ve çözülen bir destek talebinin, taranan bir sözleşmenin ya da zenginleştirilen bir kaydın gerçekte kaça mal olduğunu nihayet söyleyebilin.

Bu sayıyı kiracı, görev tipi, rota ve prompt sürümüne göre dilimleyin; optimizasyon hedefleri kendini gösterir. Belge boyutları alışılmadık tek bir kiracı, yükseltme oranı yukarı kaymış tek bir görev tipi, örnek gösterim bloğunu sessizce ikiye katlamış tek bir prompt sürümü. Toplam harcama yerine yürütme başına maliyete alarm kurun ve bu metriği kalite skorlarınızla aynı panele koyun ki kimse birini iyileştirirken diğerini sessizce bozamasın. Bu aynı zamanda bir finans ekibiyle dürüst bir yapay zeka projesi maliyeti konuşması yapmayı mümkün kılan sayıdır, çünkü token muhasebesini zaten anladıkları birim ekonomisine çevirir. Bir destek talebinin çözümünün kaç liraya mal olduğunu söyleyebildiğinizde bütçe tartışması tahminden çıkar, ölçüme dayanır.

Kendi çalışmamızda sıra nadiren değişir. Model seçimine dokunmadan önce her şeyin önüne bir ağ geçidi koyarız, çünkü tek bir darboğaz noktası olmadan yönlendirme uygulanabilir değildir. Ardından prompt yapısını önbelleğe uygun hâle getiririz; kalite riski olmayan en ucuz değişiklik budur. Sonra görev tipine göre kural tabanlı yönlendirme, sonra bir değerlendirme kapısı ve ancak ölçüm kuralların yanlış yönlendirdiğini söylüyorsa kademeli yapı ya da öğrenilmiş bir yönlendirici. Bir müşterinin dar bir görevdeki hacmi yeterince yüksekse yönlendirme konuşması doğal olarak bir ince ayarın ekonomisi konuşmasına dönüşür ve büyük dil modeli eğitimi çalışmalarımız genellikle tam burada başlar: arkasına amaca özel bir model koymayı haklı çıkaracak sıklıkta çağrılan bir rotada.