Ajans faturasında yapay zekâ kalemleri: neyi yanlış kurduk

🇬🇧 English: Read this in English →

Bu serinin üç yazısında yapay zekâya neden ayrı ücret yazdığımızı, işe yaramayan dört token fiyatlama denemesini ve sonunda oturttuğumuz birimi anlattım. Hepsi aritmetikti. Bu yazı ise bunların sana ulaşıp ulaşmadığına karar veren kısımla ilgili: faturanın kendisi ve onu taşımak zorunda olan proje yönetim aracı.

Ölçüm ilginç problemdi, fatura ise sıkıcı uygulama kısmı olacaktı. Olmadı. İlk kurgumuzu yanlış yapının üstüne kurduk, bu yüzden bir müşteriye şişik rapor gitti ve düzeltmek için elli sekiz kaydı taşımak gerekti. Burada asıl işe yarayan kısım hatalar, o yüzden en çok yeri onlara ayırdım.

Müşteri adlarını yazmıyorum, iş ticari açıdan hassas. Rakamların hepsi gerçek ve hiçbiri yuvarlanmadı.

Kısıt: bir birim, hem araç hem fatura kabul etmedikçe hiçbir işe yaramaz

Eylül başında birim elimizdeydi. Bir birim 100.000 ağırlıklı token; ağırlıklı token girdi artı beş kere çıktı demek ve marj maliyetin iki katı, açıkça yazılı. Nasıl çıktığını görmek istersen üçüncü yazıda duruyor.

Birimin sana söylemediği şey, kaydın nerede yaşayacağı. Bizim proje yönetim sistemimiz ActiveCollab; faturayı görevlere bağlı kayıtlardan çıkarıyor ve bir sayıyı koyabileceğin iki bariz yer sunuyor: süre kaydı ya da harcama. Bu bir dosyalama tercihi gibi görünüyordu. Meğer tasarımın tamamıymış.

Birinci deneme: yapay zekâ tüketimini süre olarak yazmak. Bu müşteriye kadar gitti.

Süre kayıtlarıyla başladık, çünkü her iş türü için zaten bir iş tipi vardı ve model katmanları için üç tane daha eklemek on dakika sürdü. Token kaydı 0,61 değeriyle giriyordu, yani 0,61 birim.

Sonra haftalık müşteri raporu önizlendi ve sayı mümkün olan en kötü yönde yanlıştı. Hesabın aylık bütçesi iki saatti. Rapor dokuz virgül bir saat kullanıldığını, yedi virgül bir aşım olduğunu söylüyordu. O ayın gerçek insan saati: 0,81.

Büyük hesapta fark daha genişti: rapor 43,86 saat gösteriyordu, gerçeği 15,51. Aradaki yirmi sekiz saatin 23,67’si saat sayılan token birimi, 4,68’i saat sayılan euro tutarıydı.

İki sebep vardı ve ikisi de raporlama mantığında değil veri kaynağındaydı, kodu okumanın yakalayamamasının nedeni bu:

• Kullandığımız raporlama ucu süre kayıtlarını ve harcama satırlarını birlikte döndürüyor, bizim kod ise her satırın value alanını türüne bakmadan topluyordu. 4,80 euroluk bir harcama 4,80 saat sayılmıştı.
• Aynı uç iş tipi kimliğini döndürmüyor. Yani veri modelinde türler ayrı dursa da rapor token kaydını insan saatinden ayırt edemiyordu. Token kaydında 0,61 birim demek. İnsan kaydında saat demek. Aynı kolon, iki anlam ve okuma anında ayırmanın yolu yok.

Bunun bedeli teorik değildi. Token kayıtları 4 Eylül’de başladı, 7 Eylül’de bir müşteriye rapor gitti; yani bir müşteriye var olmayan bir aşım gösterildi. Bütün argümanı faturalama şeffaflığı olan bir iş için mevcut en kötü sonuç bu ve sebebi, saklama yapısını kolayına göre seçmemiz.

İkinci ve üçüncü deneme: araç direndi, hassasiyet yanlış sayıya bağlıydı

Süre kaydı sürümü hâlâ ayaktayken iki problem daha çıktı; hangi proje yönetim aracında olursan ol aynısını denemeye kalkarsan ikisini de bilmek istersin.

Bir iş tipi var olabilir ama kullanılamaz olabilir. API’den açmak çalıştı, ücret yerinde ve arşiv bayrağı kapalı geldi. Ona kayıt yazmak 400 "Job type not available." döndürdü. Tip arayüzden ayrıca açılmak zorunda ve bu durumu bildiren hiçbir API ucu yok. Dahası kısıt proje bazında değil kullanıcı bazında çıktı: aynı iş tipi bir kullanıcı kimliğine kayıt kabul ederken başkasını reddediyor, başka bir tip ikisini de alıyordu. Kullanıcının iş tiplerini listelemek üçünü de gösteriyor, yani liste neyin kabul edileceğini söylemiyor. Çözüm, kaydı izinli kullanıcı adına yazıp hemen devretmek.

Hassasiyet saat ücretine bağlıydı. Süre kaydının değer alanı sessizce iki ondalık tutuyor. 1,6107 gönderdik, yanıt 1,6107 olarak geri döndü, kaydı okuyunca 1,61 geldi. Değer saat olduğu için paradaki hata iş tipinin taşıdığı ücrete bağlıydı ve budama yazma anında görünmüyor. Ücreti seçerken faturalama hassasiyetini de seçiyorsun, bunu kimsenin kazara yapmaması gerekir.

Vardığımız yer: kaynak tüketimi paradır, o yüzden paranın gittiği yere gider

Çözüm, bir kez görülünce tek cümleydi. Kaydettiğin şeyin süre mi para mı olduğunu sor ve ona uyan yapıyı kullan. Yapay zekâ tüketimi paradır, o yüzden harcamalara taşındı.

Şimdi on iki harcama kategorisi taşıyor; projeye değil tek tek göreve bağlı ve euro cinsinden. Görevde Time alanı yalnızca insan saati, Cost Summary alanı kaynak maliyeti. Görevi açan müşteri iki farklı şey anlatan iki sayı görüyor; bütün uğraş bunun içindi.

Harcamanın miktar alanı yok, sadece tutar var; miktar açıklamada yaşıyor. Biçim zorunlu ve denetleniyor:

ÖN EK · kalem · miktar birim × ücret = tutar · yapılan iş

TOKEN · Token Usage (Opus) · 0,61 birim × 3,00 € = 1,83 € · İçerik rehberinin hazırlanması

Metnin içinde yaşamak miktarı aslında kaybetmiyor ve bu kulağa geldiğinden daha önemli. Tutarı birim ücrete bölünce miktar birebir geri geliyor, yani haftalık rapor cümleyi ayrıştırmak yerine hesaplıyor. Metin ayrıştıran bir rapor, biri açıklamayı ilk düzenlediğinde bozulur. İki sayıyı bölen bozulmaz.

O biçimdeki bir kural tamamen sırayı yanlış test ettiğimiz için var. Görev adı açıklamada geçmemeli. ActiveCollab fatura satırını kendisi kuruyor: görev adı: harcama açıklaması (tarih). Görev adını açıklamaya da yazarsan müşteri aynı satırda iki kez okuyor. Bunu biçimi altmış kayda uyguladıktan sonra fark ettik, çünkü biçim faturaya değil veri modeline bakılarak tasarlanmıştı. Altmış düzeltme ucuz bir ders ama kaçınılabilirdi: gerçek faturada bir satır üret, ona bak, sonra yay.

Süre kaydı sürümündeki üç tuzaktan ikisi kendiliğinden yok oldu. API’den açılan harcama kategorisi anında kullanılıyor, arayüz adımı da kullanıcı kısıtı da yok. Hassasiyet ise çözüm gerektirmek yerine iyileşti, çünkü değer artık para: iki ondalık euro, bir faturanın tam olarak istediği şey ve başka gerekçelerle seçtiğin bir ücretin arkasında durmuyor.

Taşımanın kendisi elli sekiz kayıt, iki hesapta 86,51 euro tuttu ve onu kurtaran tek bir detay var: önce harcamayı yaz, doğrula, ancak ondan sonra süre kaydını çöpe at. İlk turda on dört kaydın on dördü düştü, çünkü kayıt tarihini epoch sayısı olarak gönderdik ve API hiçbir şey anlatmayan bir 500 ile “An unexpected error occurred” dedi. Düz YYYY-MM-DD metni istiyor. Sıra sayesinde tek bir süre kaydı kaybolmadı. Önce çöpe atsaydık o öğleden sonra veri kurtarma işine dönerdi.

Eski token iş tipleri sonrasında arşivlendi ki alışkanlıkla oraya kayıt girilmesin. Bilinmesi gereken bir şey: bir iş tipini ya da harcama kategorisini silmek başarı kodu döndürüyor ama yalnızca arşiv bayrağını kaldırıyor, çöpe atılan süre kaydı da geri geliyor. Yanlış temizlik geri alınabilir; bu aracın iyi bir özelliği ve dikkatsiz olmak için kötü bir gerekçe.

Her yeni sağlayıcıda kataloğun çatlamasını önleyen kural

Kataloğun dayandığı ilke bu ve başkasının yazısını okusam çalacağım kısım da bu. Her kalemin birimi, sağlayıcının kendi faturalama birimidir. Token token kalır, GPU saniyesi GPU saniyesi kalır, ses dakikası ses dakikası kalır. Ücret maliyetin iki katı ve maliyet, o birim için sağlayıcının kendi liste fiyatı.

Bu on iki satır veriyor: üç token katmanı, sonra on görsel başına görsel üretimi, on saniye başına video, yüz GPU saniyesi başına işlem, altmış dakika başına sesten metne, milyon karakter başına makine çevirisi, bin sayfa başına web taraması, bin sorgu başına veri API’si ve yüz gigabayt başına medya CDN’i. Birim her satırın adının içine yazılıyor, çünkü araç kategoriye açıklama alanı vermiyor ve kaydı giren kişi ne girdiğini yalnızca addan anlamak zorunda.

Asıl işi yapan on ikinci satır. Adı External API Cost ve birimi bir euro sağlayıcı maliyeti, iki euro olarak ücretlendiriliyor. Katalogda olmayan her şey için genel karşılık. Yeni bir servis çıkıyor, sağlayıcının faturasındaki tutarı değere yazıyorsun ve sistem çatlamıyor. O satır olmasa her yeni araç bir şema değişikliğine ve bir toplantıya dönüşür.

Bugünkü durumu açık söyleyeyim: yalnızca üç token satırı canlı. Diğer dokuzu kamuya açık liste fiyatlarından tahmin edilmiş maliyetler taşıyor ve henüz gerçek bir sağlayıcı faturasıyla doğrulanmadı, çünkü daha faturalandırmadık. Biri ilk kez kullanıldığında rakam sağlayıcının gerçekten kestiği tutarla karşılaştırılıp düzeltilecek. Bir alıcı, fiyat listesindeki hangi sayının sınandığını ve hangisinin sınanmadığını bilmeyi hak eder.

Bir soru da hâlâ açık. Küçük kalemlerde tutar neredeyse komik: yirmi beş dakikalık deşifre 0,32 euro çıkıyor. Parasından çok dikkat harcatan bir kalem, hiç kalem olmamasından tartışmalı biçimde daha kötü. Satır başına asgari tutar, mesela bir euro, konuşuluyor ve karara bağlanmadı.

Birim, yayınladıktan beş gün sonra sınandı

Üçüncü yazı, faturayı dolar yerine birim cinsinden yazmanın model fiyat değişikliklerini müşteri görüşmesine dönüşmekten kurtardığını savunuyordu. Bu iddia alışılmadık bir hızla sınandı.

Üçüncü yazı 17 Eylül’de çıktı; Opus 5 milyon girdi tokenı başına beş dolar, milyon çıktı başına yirmi beş dolardı. Beş gün sonra, 22 Eylül’de, Anthropic Opus 5.5’i dört ve yirmi dolara açtı; Opus 5’ten yüzde yirmi daha düşük ve varsayılan ayarlarda tipik iş yüklerinde yaklaşık yüzde kırk daha ucuz olduğunu söylüyor. Önbellek okumaları milyon başına elli senten yirmi sente indi, yüzde altmış kesinti.

Bizim tarafta hiçbir şey oynamadı. Bir birim hâlâ 100.000 ağırlıklı token. Çıktı, güncel her katmanda girdinin tam olarak beş katı fiyatlandığı için ağırlıklı tokenın maliyeti girdi fiyatına eşit; yani birimin içindeki ham maliyet elli sentten kırk sente, faturaya yazılan tutar bir dolardan seksen sente indi. Yeni fiyat listesi yok, yeniden fiyatlama görüşmesi yok. Sessiz kısım önbellek indirimi: önbellek okumaları ikinci yazıda anlattığım gibi faturalamadığımız, kendi üstlendiğimiz genel gider. Oradaki yüzde altmışlık düşüş kimsenin faturasına dokunmadan bizim marjımızı iyileştiriyor. Sessizce cebe atmak yerine söylemeye değer.

Neyi farklı yapardık, sen neyi alabilirsin

Üç şey, en çok dert açtıklarından başlayarak.

• Nereye koyacağını seçmeden önce “bu para mı süre mi” diye sor. İlk sürümdeki bütün problemler, parayı süre anlamına gelen bir alana yazmaktan çıktı. Tasarım dosyalama değil, yapının kendisi.
• Bir biçimi altmış kayda uygulamadan önce gerçek bir fatura satırı bas. Açıklama biçimini veri modeline karşı doğruladık, yanlış nesne. Müşteri faturayı okuyor, o yüzden test edilecek şey fatura.
• Ayrım insan saatini yemesin. Taşımadan bir gün sonra yan etki çıktı: iş bitti, harcama yazıldı, insan saati atlandı. Maliyeti olup süresi olmayan bir görev bedavaya yapılmış gibi duruyor. Sıra artık dört adım ve dört adım olarak yazılı: yorum, insan saati, harcama, etiket.

Hesabında yapay zekâ ölçen birinden iş alıyorsan, faturanın dürüst olup olmadığını anlamanın yolunu dört soru büyük ölçüde açıyor. Yapay zekâ tüketimi insan saatinden ayrı bir satır mı, yoksa raporlamanın herhangi bir yerinde ikisi toplanıyor mu? Her satırdaki birim ne ve sağlayıcının birimi mi yoksa kendi uydurdukları mı? Fiyat listesindeki hangi rakamlar gerçek bir sağlayıcı faturasıyla doğrulandı? Ve bir model yüzde yirmi ucuzladığı hafta benim faturamda ne oluyor?

Son soru asıl ölçüt. Onu cevaplayamayan bir tedarikçi ya hiç düşünmemiştir ya da tasarrufun kendi tarafında kalmasını umuyordur. Hâlihazırda aldığın bir faturaya ikinci bir göz istersen, gel konuşalım.