Tokenomics: Ajan tipi yazılım mühendisliğinde token’ların nerede kullanıldığını nicelleştirmek
(arxiv.org)- LLM tabanlı çok ajanlı yazılım geliştirme sistemlerinin yürütme izlerini SDLC aşamalarına eşleyerek, token tüketiminin ilk üretimden ziyade kod inceleme ve doğrulamaya yoğunlaştığını ölçen bir çalışma
- ChatDev'in gerçekleştirdiği 30 yazılım geliştirme görevinde kod inceleme aşamasının ortalama %59,4 token kullandığı ve en büyük tüketim bölgesi olduğu doğrulandı
- Görevler genelinde ortalama token bileşimi girdi %53,9, çıktı %24,4, akıl yürütme %21,6 olarak ölçüldü; ajanlar arasında tekrarlanan bağlam aktarımı büyük bir communication tax oluşturuyor
- Kodlama aşamasında çıktı token oranı %58,0 ile yüksekken, dokümantasyon aşamasında girdi token oranı %80,2 ile yüksek; bu da geliştirme aşamalarına göre token kullanım örüntülerinin belirgin biçimde ayrıştığını gösteriyor
- Maliyet tahmini ve iş akışı optimizasyonu için daha token verimli ajan işbirliği protokollerine ve standartlaştırılmış değerlendirme çerçevelerine ihtiyaç duyulduğu sonucuna varılıyor
Özet
- LLM tabanlı çok ajanlı (LLM-MA) sistemler, gereksinim mühendisliği, kod üretimi ve test gibi karmaşık yazılım mühendisliği görevlerini otomatikleştirmede giderek daha fazla uygulanıyor
- Operasyonel verimlilik ve kaynak tüketimi yeterince anlaşılmadığı için öngörülemeyen maliyetler ve çevresel etki, gerçek kullanımın önünde engel oluşturuyor
- Bu çalışma, ChatDev çerçevesinin GPT-5 reasoning model ile yürüttüğü 30 yazılım geliştirme görevinin yürütme izlerini analiz ediyor ve iç adımları tasarım, kodlama, kod tamamlama, kod inceleme, test ve dokümantasyon olarak eşliyor
- Ön bulgular, yinelemeli kod inceleme aşamasının ortalama %59,4 ile en büyük token tüketim bölgesi olduğunu gösteriyor
- Girdi token’ları ortalama %53,9 ile sürekli olarak en büyük payı oluşturuyor; bu da ajan işbirliğinde önemli verimsizlik olasılığına dair ampirik kanıt sunuyor
- Ajan tipi yazılım mühendisliğinde başlıca maliyet, ilk kod üretiminden değil; otomatik iyileştirme ve doğrulama süreçlerinden kaynaklanıyor
- Yöntembilim; maliyet tahmini, iş akışı optimizasyonu ve daha token verimli ajan işbirliği protokolleri araştırmalarında kullanılabilir
Giriş
- Büyük ölçekli yazılım mühendisliği, SDLC genelindeki karmaşık görevlerin otomasyonu için LLM tabanlı çok ajanlı sistemleri araştırıyor
- LLM-MA çerçeveleri; ürün yöneticisi, mimar, geliştirici ve testçi gibi insan ekip rollerini uzmanlaşmış LLM ajanlarıyla simüle ederek tasarım, kodlama ve doğrulama görevlerini işbirlikçi biçimde yürütüyor
- LLM-MA sistemleri, ilke olarak görevleri ajanlar arasında bölerek özerkliği ve dayanıklılığı artırabilir
- Önceki çalışmalar, LLM-MA sistemlerinin farklı yönlerde düşünmeyi teşvik edebildiğini, akıl yürütme ve olgusallığı güçlendirdiğini ve tek ajan kapasitesini aşan problemlere ölçeklenebildiğini ele alıyor
- Yazılım mühendisliğinde, gereksinimlerden teste kadar uçtan uca iş akışlarının bütünleşik biçimde otomatikleştirilebilmesi önemli bir olasılık olarak görülüyor
- AGENTTAXO çerçevesi, genel LLM-MA sistemlerinde token dağılımını analiz etmek için bir sınıflandırma şeması sunuyor ve ajanlar arası etkileşim yükünü açıklayan “communication tax” kavramını tanıtıyor
- MAST hata sınıflandırması, LLM-MA sistemlerindeki birçok sorunun tekil LLM sınırlarından ziyade aşama tekrarları ve eksik doğrulama gibi sistem tasarımı ve koordinasyon problemlerinden kaynaklandığını doğruluyor
- Mevcut araştırmalar genel bağlamdaki ajan davranışlarını analiz etmiş olsa da, çok aşamalı yazılım mühendisliği iş akışlarına uygulanan sistemlerin kaynak verimliliği konusunda bilgi boşluğu bulunuyor
- Pratik benimsemenin kilit sorusu olan “token’lar nereye gidiyor?” yazılım mühendisliği alanında hâlâ yeterince yanıtlanmış değil
- Tokenomics, LLM-MA sistemlerinin operasyonel verimliliği ve kaynak tüketimini inceleyen bir terim olarak kullanılıyor
- Analiz, ChatDev’in iç adımlarını geliştirme aşamalarına eşleyerek token tüketimi dağılımını inceleme yaklaşımını benimsiyor
- ChatDev, sanal bir yazılım şirketini simüle ediyor; programcı ve testçi gibi birden çok ajan rolü, çok turlu konuşmalar üzerinden SDLC’yi tamamlıyor
- 30 yürütme izinden oluşan kürasyonlu bir veri kümesi ve tam çoğaltım paketi sağlanıyor
Araştırma tasarımı
-
Hedef ve analiz kapsamı
- Amaç, LLM-MA sistemlerinin uçtan uca yazılım geliştirme görevlerini yürütürken token tüketiminin nasıl dağıldığını ampirik olarak incelemek
- İlk analiz nesnesi ChatDev
- ChatDev’in “chat chain” mimarisi, tasarım → kodlama → test şeklinde net sıralı bir şelale modelini temsil ediyor; aşamalar belirgin olduğu için yazılım geliştirme aşaması eşlemesi için uygun
- ChatDev, popüler ve çok atıf alan açık kaynak çerçevelerden biri
-
Veri kümesi kürasyonu
- ChatDev, birbirinden farklı 30 yazılım geliştirme görevinde çalıştırıldı
- Prompt’lar, MAST çalışmasında kullanılan ProgramDev Dataset’ten derlendi
- Seçilen prompt’lar, Fibonacci sayısı üretimi gibi basit algoritmalardan satranç oyunu gibi daha karmaşık uygulamalara kadar uzanıyor
- Akıl yürütme token sayısının görev karmaşıklığı için vekil gösterge olabileceğini öne süren yakın tarihli çalışmalara dayanarak çeşitlilik doğrulandı
- 30 görevin akıl yürütme token tüketim aralığı 17.280 ile 40.000 arasında; bu aralık, çalışma için yeterli görev karmaşıklığı çeşitliliğine işaret ediyor
-
Model seçimi
- Tüm ajanların temel modeli GPT-5 reasoning model
- Seçim ölçütleri; modelin popülerliği ve güncelliği, ajan tipi kullanım senaryolarına uygunluğu ve otonom ajan beklentileriyle uyumlu güçlü akıl yürütme yeteneği
- Deneylerde kullanılan model sürümü
gpt-5-2025-08-07 temperatureparametresi bu modelde desteklenmediği için varsayılan1.0kullanıldı- Bağlam penceresi 400.000 token, azami çıktı token sayısı 128.000 token
- Bilgi kesim tarihi 30 Eylül 2024
-
Analiz hattı
- İz toplama aşamasında, ChatDev ölçümlenerek 30 görevin her biri için tam yürütme izleri loglandı
- Her LLM çağrısının prompt’u, yanıtı ve girdi/çıktı/akıl yürütme token sayıları yakalandı
- Aşama eşlemesi, ChatDev’in çerçeve içindeki adımlarını evrensel geliştirme aşamalarına dönüştüren temel yöntem olarak kullanıldı
- Bu soyutlama, genellenebilir analiz sağlıyor ve diğer yazılım mühendisliği LLM-MA çerçevelerine genişletilebiliyor
- Token toplulaştırması Python betikleriyle yapıldı
- Toplanan izler ayrıştırıldı ve 30 çalıştırmanın tamamında geliştirme aşaması bazında token sayıları toplandı
- Sonuçlar girdi, çıktı ve akıl yürütme token’ları olarak ayrıştırıldı
-
ChatDev iç adımları ile geliştirme aşamalarının eşlenmesi
- Tasarım aşaması
DemandAnalysisveLanguageChooseadımlarına karşılık geliyor; gereksinimlerin anlaşılmasına ve üst düzey teknik kararlara odaklanıyor - Kodlama aşaması
Codingadımına karşılık geliyor ve ilk kaynak kodun yazımına doğrudan katılıyor - Kod tamamlama aşaması
CodeCompleteadımına karşılık geliyor ve kodlama aşamasında kalan yer tutucuları veya tamamlanmamış kod dosyalarını bitiriyor - Kod inceleme aşaması
CodeReviewadımına karşılık geliyor; programcı ajan ile kod inceleyici ajan arasındaki yinelemeli diyaloglar üzerinden kod gözden geçirme, düzeltme ve iyileştirme yapılıyor - Test aşaması
Testadımına karşılık geliyor ve çalıştırılabilirlik hatalarını bulup düzeltmek için dinamik sistem testine odaklanıyor - Dokümantasyon aşaması
EnvironmentDoc,ReflectionveManualadımlarına karşılık geliyor; kullanıcı kılavuzu ile gerekli ortam bağımlılıklarının belgelenmesini kapsıyor
- Tasarım aşaması
Bulgular ve tartışma
-
Araştırma sorusu
- Temel soru, yazılım geliştirme görevlerinde LLM-MA sistemlerinin token tüketim örüntüleri
- Ajan tipi yazılım mühendisliği sistemlerinin tokenomics yapısını anlamak, pratik ve sürdürülebilir benimseme açısından önemli
- Yüksek token kullanımı; finansal maliyet, enerji tüketimi ve çevresel etkinin artışıyla doğrudan bağlantılı
- SDLC içinde token’ların nerede tüketildiğini belirlemek, maliyet tahmini ve iş akışı optimizasyonunda kullanılabilecek bir “maliyet haritası” oluşturmayı mümkün kılıyor
- Analiz iki eksende yürütülüyor
- Tasarım, kodlama vb. eşlenmiş geliştirme aşamalarına göre toplam token dağılımı
- Her aşama içindeki girdi, çıktı ve akıl yürütme token oranları
-
Bulgu 1: Kod inceleme aşaması token tüketimine hükmediyor
- Geliştirme süreci genelindeki token kullanımı son derece dengesiz bir dağılım gösteriyor
- Kod inceleme aşaması, 30 görevin genelinde ortalama %59,4 token kullanarak en büyük tüketim bölgesini oluşturuyor
- Kod tamamlama aşaması 30 görevin 6’sında görüldü ve bu çalıştırmalarda ortalama %26,8 token tüketti
- Dokümantasyon aşaması ortalama %20,1, test aşaması ise ortalama %10,3 token tüketti
- Test aşaması 30 görevin 12’sinde gerçekleşti
- İlk kodlama ortalama %8,6, tasarım ise ortalama %2,4 ile görece düşük maliyetli kaldı
- Ajan tipi yazılım mühendisliğinde başlıca maliyet, ilk kod üretiminden çok yinelemeli ve diyalog tabanlı iyileştirme/doğrulama süreçlerinde yoğunlaşıyor
- Şekildeki
ndeğeri, 30 görev içinde belirli bir aşamanın yürütüldüğü görev sayısını ifade ediyor - Tüm aşamalar her zaman yürütülmüyor; çok ajanlı sistem içindeki ajanlar hangi aşamaların çalıştırılacağına özerk biçimde karar veriyor
- Hata çubukları ±1 standart sapmayı gösteriyor ve her aşamadaki token tüketimi değişkenliğini yansıtıyor
-
Bulgu 2: Token tüketimi girdi token’ları merkezli
- Kodlama aşaması hariç tüm aşamalarda, girdi token’larının çıktı ve akıl yürütme token’larını açık biçimde aştığı bir örüntü görülüyor
- Görev bazında genel ortalama token kullanım bileşimi girdi %53,9, çıktı %24,4, akıl yürütme %21,6
- Girdi ve çıktı token’ları arasındaki yaklaşık 2:1 oranı, önceki çalışmalardaki “communication tax” için güçlü ampirik kanıt sunuyor
- Ajanlar, işbirlikçi diyalog sırasında büyük bağlamları tekrar tekrar aktararak token harcıyor
- Mevcut ajan işbirliği protokollerinde, yeni çıktı üretmekten çok bağlam taşımaya token harcanması şeklinde bir verimsizlik bulunuyor
- communication tax, konuşma tabanlı çok ajanlı mimarilerin doğasında bulunan bir özellik olabilir ve gelecekte ek araştırma gerektiriyor
-
Bulgu 3: Geliştirme aşamalarına göre farklı tokenomic profile’lar
- Aşama bazındaki token oranları, her yazılım mühendisliği etkinliği için kendine özgü örüntüler oluşturuyor
- Kodlama aşaması, çıktı odaklı istisnai bölge olarak öne çıkıyor; çıktı %58,0, girdi %6,9
- Kodlama aşamasının çıktı merkezli yapısı, kısa tasarım belirtimlerinden uzun kaynak kod üretme görevlerinin doğasıyla uyumlu
- Kod inceleme ve dokümantasyon gibi doğrulama/belgeleme aşamaları ise girdi merkezli
- Kod incelemede girdi oranı %51,4
- Dokümantasyonda girdi oranı %80,2
- Bu aşamalar, mevcut kodu büyük bağlam olarak tüketip daha küçük analitik çıktılar üretiyor
- Aşama bazlı token profilleri, mühendislik etkinlikleri için bir maliyet haritası olarak kullanılabilir
- Uygulayıcılar, maliyet tahmini ve süreç optimizasyonu fırsatlarını daha iyi belirleyebilir
-
Aşama bazlı token oranları
- Tasarım aşamasının ortalama oranı girdi %60,4, çıktı %3,6, akıl yürütme %36,0
- Kodlama aşamasının ortalama oranı girdi %6,9, çıktı %58,0, akıl yürütme %35,1
- Kod tamamlama aşamasının ortalama oranı girdi %47,7, çıktı %41,7, akıl yürütme %10,5
- Kod inceleme aşamasının ortalama oranı girdi %51,4, çıktı %24,7, akıl yürütme %23,9
- Test aşamasının ortalama oranı girdi %60,8, çıktı %20,7, akıl yürütme %18,4
- Dokümantasyon aşamasının ortalama oranı girdi %80,2, çıktı %8,3, akıl yürütme %11,5
- Görev bazında genel ortalama oran girdi %53,9, çıktı %24,4, akıl yürütme %21,6
-
Tartışma
- Ön bulgular, ajan tipi yazılım geliştirmenin ilk maliyet haritasını sunuyor
- Kod inceleme aşamasının yüksek token maliyeti bir “konuşma maliyeti” olarak yorumlanabilir
- Bu maliyet, ajanların tüm kod bağlamını tekrar tekrar paylaşarak kodu iyileştirdiği LLM-MA sistemlerinin diyalog tabanlı mimarisinden doğrudan kaynaklanıyor
- Mevcut doğrulama amaçlı ajan işbirliği protokolleri, yalnızca küçük düzeltmeler gerektiren görevlerde bile devasa kaynak tüketebildiği için oldukça verimsiz olabilir
- Bu sonuçlar, MAST sınıflandırmasındaki doğrulama hataları ve aşama tekrarlarıyla ilgili bulgularla da uyumlu
- Yüksek token kullanımı, ajan sistemlerinin içkin koordinasyon problemlerini zorlayıcı diyaloglarla aşmaya çalışmasının bir belirtisi olabilir
- Uygulayıcılar, ajan tabanlı proje maliyetlerini ihtiyaç duyulan iş türüne göre tahmin edebilir
- İlk kodlama payının yüksek olduğu greenfield projeler ile mevcut kod refaktörizasyonu/hata ayıklama odaklı projeler farklı maliyet yapılarına sahip
- Mevcut kod refaktörizasyonu ve hata ayıklamaya odaklı projelerde, pahalı ve girdi merkezli kod inceleme döngüleri maliyete hâkim oluyor
- Kod inceleme aşamasından önce “human-in-the-loop” kontrol noktaları eklemek, maliyetli yineleme döngülerini önleyerek ekonomik ve hesaplama verimliliğini artıran tasarım kararlarına yardımcı olabilir
- Araştırmanın temel gündemlerinden biri, doğrulama ve iyileştirme için daha token verimli işbirliği protokolleri tasarlamak
- Bunun için, tüm bağlamı basitçe iletmenin ötesine geçen yöntemlere ihtiyaç var
- Standartlaştırılmış ve kapsamlı bir değerlendirme çerçevesi de gerekli
- Bu çerçeve, ChatDev’in hiyerarşik konuşma tabanlı iş akışı ile MetaGPT’nin SOP tabanlı montaj hattı gibi farklı LLM-MA mimarilerinin verimliliğini kıyaslamak ve karşılaştırmak için ortak zemin sağlayabilir
- Ayrıca çerçevelere özgü davranışları evrensel yazılım mühendisliği etkinliklerine çeviren bir “Rosetta Stone” işlevi görebilir
Geçerlilik tehditleri ve gelecekteki çalışmalar
-
Geçerlilik tehditleri
- Analiz, tek bir LLM-MA sistemi olan ChatDev’e ve tek bir LLM olan GPT-5 Reasoning Model’e dayanıyor
- Gözlenen token tüketim örüntüleri, farklı LLM-MA mimarilerinde veya token verimliliği farklı başka LLM’lerde değişebilir
- 30 yazılım geliştirme görevi çeşitli olsa da, tüm olası yazılım geliştirme senaryolarını ve karmaşıklıklarını temsil etmiyor olabilir
- Kürasyonlu veri kümesinin ölçeği, yazılım mühendisliği odaklı ajan izleri için kamuya açık büyük ölçekli benchmark eksikliğinden doğrudan kaynaklanıyor
- Veri kürasyonu zaman ve maliyet açısından ağır bir süreç
- Bazı geliştirme aşamaları, 30 görevin yalnızca küçük bir alt kümesinde yürütüldü
- Kod tamamlama
n=6, test isen=12ile nadiren tetiklendi - Bu belirli aşamaların tokenomic profile’larına ilişkin sonuçlar küçük örnekleme dayanıyor; dolayısıyla temsil gücü düşük ve genellenebilirlikleri sınırlı olabilir
- ChatDev’in iç adımlarını yazılım geliştirme aşamalarına eşleme yöntemi bir soyutlama
- Standartlaştırılmış bir değerlendirme çerçevesi oluşturmak için mantıklı ve kullanışlı olsa da, ajan etkinliklerini eşlemenin olası yollarından yalnızca biri
-
Sonuç ve gelecekteki çalışmalar
- Ajan tipi yazılım mühendisliğinde token maliyeti eşit dağılmıyor; baskın biçimde yinelemeli ve diyalog tabanlı kod inceleme aşamasında yoğunlaşıyor
- “communication tax”ı oluşturan girdi token’ları, toplam token kullanımının çoğunu meydana getiriyor ve gelecekteki optimizasyon için kilit alanı oluşturuyor
- Gelecek çalışmaların ilk görevi, genellenebilirliği artırmak için veri kümesini daha fazla görevle genişletmek
- İkinci görev, model bazlı etkileri anlamak için analizi diğer LLM’lere genişletmek
- Üçüncü görev, mimari farklılıkların tokenomics üzerindeki etkisini karşılaştırmak için analizi diğer LLM-MA sistemlerine genişletmek
- Dördüncü görev, token tüketim örüntüleri ile hata modları arasındaki ilişkiyi incelemek
- Beşinci görev, yazılım mühendisliği ajan verimliliğini kıyaslamak için sağlam ve evrensel bir geliştirme aşaması eşleme çerçevesini daha da geliştirmek ve doğrulamak
1 yorum
Hacker News görüşleri
Kişisel kullanım için bir çok ajanlı sistem kurup kullanıyorum
Bir problem verildiğinde önce hızlı ve ucuz bir model sorular soruyor, ardından bu yanıtlara dayanarak giriş promptunu rafine ediyor
Sonrasında problemi bölümlere ayırıyor ve nihai hakem sonuca varıyor ya da birkaç ajan tartıştıktan sonra hakem özet çıkarıyor gibi bir strateji seçiyor
En iyi yöntem, benim all angles dediğim yaklaşım; birden fazla stratejiyi paralel çalıştırıp son bir meta hakemin yanıtları birleştirmesi
Son dönemde eklediğim özellikler içinde en yararlısı, her strateji arasındaki sapmayı görebildiğim ekran oldu
Bunu konut arama, okul ve aile meseleleri gibi günlük yaşam konularında kullanıyorum
Hangi stratejileri kullandığını ve stratejiye göre maliyetlerin nasıl değiştiğini de bilmek isterim
Sibernetik bir yaklaşımla, prompt çıktısının kararlılığını korumak için deterministik kontroller ve otomatik düzeltme kütüphanesini sürekli büyütüyorum
Bu kütüphanenin ele alamadığı “sorunlar” ise süreci yöneten kişiye görünür hale geliyor
Bir ay boyunca GitHub Copilot’u kesintisiz ve yoğun biçimde kullandım ama fiyat değişikliğinden sonra ertesi ay tokenları iki günde tükettim
Bu kadar sert bir değişim, token fiyatlarının keyfi olduğunun ve yapay zeka işinin hızla nakit yaktığının işareti gibi görünüyor
Çıkarım marjlarının %70’in üzerinde olduğuna dair söylentiler de var
Örnek olarak SpaceX son 6 ayda tüketici ürünlerinin fiyatlarını genel olarak artırdı ama Alphabet ile Anthropic birlikte ayda 2 milyar doların üzerinde ödediği için ortada para sıkıntısı yok
Microsoft/GitHub ise başkasının ürününü yeniden paketleyen taraftı; bu durumda zararı onlar üstlenmiş oldu
Genel olarak fiyatlar çeşitli temel etkenlere göre belirlenir; bu, başlı başına keyfi oldukları anlamına gelmez
Mesela GitHub yöneticileri token fiyatlarını bir rastgele sayı üreteciyle belirleseydi, işte bu keyfi fiyatlandırma olurdu
“Girdi tokenlarının ortalama %53,9 ile tüketimin en büyük payını oluşturduğu” deniyor ama benim kullanımımda oran kabaca 10:1
Harcanan tokenların ezici çoğunluğu girdi tarafında ve ajanların tek satır kod düzeltmek için bir milyon token okuduğu sık oluyor
Oran 1:1’e yakınsa ya da çıktı tarafı daha büyükse, bunun ajanlarda bir sorun olduğu ya da kod tabanının yeni veya boş olduğu anlamına geldiğini düşünürüm
Cache edilmemiş bir milyon token oldukça fazla görünüyor
Modele ilgili kod bölümlerini dump eden tek seferlik bir “sıkıştırma” adımı yaptırıp, çıkan sonucu çok sayıda alt ajan çağrısı için cache’lenmiş önek olarak kullanmak mümkün olabilir
Kodlama için ajan kullandığınızda unit test yazmayı binlerce adede çıkarmak istiyorlar ama dinamik test yapma eğilimleri zayıf
Statik test dediğimiz şey lint veya type checking gibi şeylerdir
Unit test dışında başka tür dinamik testler istiyorsanız, bunu plan veya PRD aşamasında gereksinim olarak açıkça belirtmeyi denediniz mi merak ediyorum
Onların çıkarları her zaman sizin çıkarlarınızla örtüşmeyebilir
Bu durumda sizi gereksiz işlere gereksiz para harcamaya yöneltmek istiyorlar
Artık “token” gibi örtmeceleri bırakmak iyi olabilir
Dinamik testlerden bir ölçüde kaçınmalarının nedeni muhtemelen bunun hızı düşürmesi ve yazılımı beklenmedik yerlerde durdurabilmesi
Geçen yıl token kullanım verimliliğini optimize etmek için bütçe yönlendirme bilgisi veren bir makaleyi hatırladım
[1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...
Bu, havayolu ödül millerine benziyor ve şirket açısından bare-metal GPU zamanı kiralamaya göre bir avantajı yok
Yapay zeka talebinin büyük kısmı şirket içi ya da cihaz üstü donanım ve modellerle karşılanabilir hale geldiğinde, bu kadar pahalı işletilen devasa hesaplama çiftliklerinin ve modellerin ne işe yarayacağını merak ediyorum
Muhtemelen geriye sadece büyük devlet müşterileri kalacak ve sonuçta yapay zeka kartelinin yatırdığı milyarlarca doların faturasını vergi mükellefleri ödeyecek
Aralık ayında bu konuda bir Substack yazısı yazdım: https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...
Eskiden Google gibi şirketler, mühendisleri altyapıyı ne kadar iyi optimize edebildiklerine bakarak işe alırdı
Yakında şirketler mühendislerin yapay zeka token verimliliği optimizasyonu becerisine de bakabilir
Geliştiricilerin daha fazla token kullanacak yeni alanlar bulma hızının, fiyatların düşme hızı kadar yüksek olup olmayacağından emin değilim
Tokenları internet gibi bir kamu hizmeti gideri sayıp ücretini doğrudan mühendislere ödetmek yeterli
İlginç bir yan not olarak, yeni ürün adaylarının değerlendirildiği bir toplantıdaydım; her şey iyi gidiyordu ama sonra ürüne AI eklediklerini gösteren bir ekran açıldı
Elbette AI eklemişlerdi ve çok zorlama duruyordu
Bunun zorlama olduğunun işaretlerinden biri, her sorguda kaç token harcandığını gösteren bir sütun bulunmasıydı
Token maliyetini kimin ödediğini sordum, lisansa dahil olduğunu söylediler; peki bir bütçe limiti mi var yoksa sınırsız mı diye sordum, iyi soru deyip kontrol edeceklerini söylediler
Sorma nedenim, az önce gösterdikleri basit bir cihaz sorgusunun 250 bin token yakmış olmasıydı
O anda karşı taraftaki yöneticilerden birinin yüksek sesle “Biz bunu müşteriye neden gösteriyoruz?” dediğini duydum ve epey güldük
Buradan çıkardığım ders şu: Her şeye AI eklemenin maliyeti doğru hesaplanmıyor ve gerçek AI operasyonlarının maliyeti ise hiç hesaba katılmıyor
İstesek de istemesek de, AI eklenen her şey daha pahalı olacak
Tokenomics zaten kripto para ekonomisini anlatan bir kelime; AI’da kullanılan tokenlar farklı bir tür olsa da neden bu kelimeyi yeniden tanımlamak istediklerini anlamıyorum
Eski modayı unutun; bunun da ömrü kısa olacak, o yüzden çok geç olmadan trene atlamak lazım
“Web 3.0” da kriptocular Web3’ü kripto merkezli hale getirmeden önce vardı
Dolayısıyla burada neyin sorun olduğunu anlamıyorum
Terimler farklı bağlamlarda sürekli yeniden kullanılıyor
Ayrıca çoğu kişi zaten kriptodan AI’a geçtiği için, büyük bir karışıklık çıkma ihtimali de düşük