TOON ve TONL: LLM çağında JSON’a hafif rakipler

TOON ve TONL: LLM çağında JSON’a hafif rakipler

Meta Açıklama: TOON ve TONL formatlarını, JSON’dan farklarını ve büyük dil modelleri (LLM’ler) için sağladıkları token verimliliği, semantik yapı ve kullanım senaryolarını keşfedin.

Giriş

TOON ve TONL, büyük dil modelleri (LLM’ler) için optimize edilmiş, JSON’a alternatif iki yeni veri formatı olarak son yıllarda dikkat çekmeye başladı. JSON’un basitliği ve yaygınlığı tartışılmaz; ancak LLM çağında, özellikle token maliyeti ve bağlam penceresi verimliliği söz konusu olduğunda JSON’un bazı yapısal dezavantajları daha görünür hale geliyor. TOON (Token-Oriented Object Notation) ve TONL (Token-Optimized Notation Language), tam da bu noktada devreye girerek, aynı yapısal veriyi daha az token ile, model için daha “okunabilir” bir biçimde sunmayı hedefliyor.

Bugün API’lerden konfigürasyon dosyalarına, loglardan analitik raporlara kadar sayısız alanda JSON kullanıyoruz. Ancak bir LLM’e büyük bir JSON gövdesi gönderdiğinizde, süslü parantezler, tırnak işaretleri ve tekrar eden anahtar adları, modelin bağlam penceresini gereksiz yere dolduruyor. Bu da hem maliyeti artırıyor hem de modele gerçekten önemli olan içeriğe daha az yer bırakıyor. TOON ve TONL, JSON veri modelini tamamen terk etmeden, bu “görsel ve token gürültüsünü” azaltan, LLM-dostu serileştirme yaklaşımları sunuyor.

Bu yazıda, TOON ve TONL formatlarının ne olduğunu, JSON’dan hangi açılardan ayrıldıklarını ve özellikle LLM tabanlı sistemlerde neden önemli hale geldiklerini detaylı biçimde inceleyeceğiz. Ayrıca, hangi senaryolarda JSON’un hâlâ en pratik çözüm olduğunu, hangi durumlarda ise TOON veya TONL gibi token-optimize formatlara geçmenin anlamlı olacağını örneklerle tartışacağız.

Arka Plan: JSON ve Yapılandırılmış Veri Formatları

JSON (JavaScript Object Notation), insan tarafından okunabilirliği yüksek, anahtar-değer temelli, hafif bir veri değişim formatı olarak web’in fiili standardı haline geldi. Temel veri tipleri; string, number, boolean, null, array ve object’tir. Bu basit tip seti ve JavaScript ile doğal uyumu, JSON’u hem istemci hem sunucu tarafında son derece popüler kıldı.

JSON’un güçlü yönleri oldukça net:

• Basitlik: Sözdizimi kolay, öğrenme eğrisi düşük.
• Yaygın destek: Hemen her programlama dilinde yerleşik veya olgun kütüphanelerle destekleniyor.
• Ekosistem araçları: JSON Schema, OpenAPI, GraphQL gateway’leri, log toplayıcılar, ETL araçları vb. ile güçlü bir ekosisteme sahip.

Buna karşın, özellikle LLM ve karmaşık bilgi temsili bağlamında bazı sınırlamaları da var:

• Şema zorunluluğu yok: JSON kendi başına şema tanımlamaz; tip güvenliği ve doğrulama için ek katmanlar (JSON Schema vb.) gerekir.
• Tekrarlı anahtarlar: Tablosal veya tekrarlı yapılarda her satırda aynı alan adlarının tekrar yazılması, hem boyutu hem de LLM token maliyetini artırır.
• Gürültülü sözdizimi: Süslü parantezler, tırnaklar, virgüller; insanlar için okunabilir olsa da, LLM tokenleştirmesi açısından ciddi bir “overhead” oluşturur.
• Semantik zenginlik sınırlı: JSON, veri tiplerini ve yapıyı tanımlar; ancak ilişkiler, ontolojiler, bağlam ve kısıtlar için ek katmanlara ihtiyaç duyar.

LLM’ler metin tabanlı çalıştığı için, onlara gönderdiğiniz her karakter, bir veya daha fazla tokene dönüşür. JSON’un yapısal karakterleri, model için anlamlı bilgi taşımadığı halde token tüketir. Özellikle RAG (Retrieval-Augmented Generation), log analizi, analitik raporlar veya büyük konfigürasyon bloklarını modele “yedirirken”, bu gereksiz token maliyeti ciddi bir sorun haline gelir. TOON ve TONL, bu sorunu hedefleyen, LLM bağlamında optimize edilmiş formatlardır.

TOON Formatı: Tanım, Amaç ve Özellikler

TOON (Token-Oriented Object Notation), JSON veri modelini koruyan ancak LLM’ler için token sayısını ve görsel gürültüyü azaltmayı hedefleyen metin tabanlı bir serileştirme formatıdır. Temel fikir, aynı yapısal veriyi JSON’a göre %30–60 daha az token ile ifade edebilmek ve özellikle tekrarlı/tablolu verilerde anahtar adlarının tekrarını ortadan kaldırmaktır.

TOON’un ortaya çıkış motivasyonu, LLM’e büyük JSON gövdeleri gönderen geliştiricilerin yaşadığı iki temel sıkıntıya dayanıyor:

1. Yüksek token maliyeti: Her bir tırnak, virgül, süslü parantez ve tekrar eden alan adı, gereksiz token tüketimi demek.
2. Bağlam penceresi baskısı: Modelin bağlam penceresi sınırlı; gereksiz karakterler, gerçekten önemli olan içeriğe ayrılabilecek alanı daraltıyor.

TOON, bu sorunları çözmek için özellikle tablosal ve tekrarlı yapılarda kolon başlıklarını bir kez tanımlayıp, satırları sıkıştırılmış biçimde temsil eder. Böylece hem insan hem de model için daha kompakt ve düzenli bir görünüm elde edilir.

TOON’un Temel Tasarım İlkeleri

• JSON veri modelini koruma: TOON, JSON’un nesne/dizi yapısını ve temel tiplerini kavramsal olarak korur; yani JSON’dan TOON’a ve tekrar JSON’a kayıpsız dönüşüm hedeflenir.
• Token verimliliği: Sözdizimi, LLM tokenleştirmesine göre optimize edilmiştir; gereksiz tırnaklar ve anahtar tekrarları azaltılır.
• Tablosal veri odaklılık: Özellikle aynı şemaya sahip kayıt dizileri (örneğin kullanıcı listeleri, log satırları, ürün katalogları) için kolon başlıkları + satırlar yaklaşımı kullanılır.
• İnsan tarafından okunabilirlik: JSON kadar yaygın olmasa da, geliştiricilerin birkaç örnek gördükten sonra rahatça okuyup yazabileceği bir yapı sunar.

JSON ve TOON Yan Yana Örnek

Basit bir kullanıcı listesi düşünelim.

JSON:

[
  {"id": 1, "name": "Alice", "role": "admin"},
  {"id": 2, "name": "Bob", "role": "user"},
  {"id": 3, "name": "Carol", "role": "user"}
]

Bu yapı, her satırda "id", "name", "role" anahtarlarını tekrar ediyor. Aynı veri TOON ile kabaca şöyle temsil edilebilir (sözdizimi örnektir, fikir vermek içindir):

users:
  columns: id, name, role
  rows:
    1, Alice, admin
    2, Bob, user
    3, Carol, user

Burada kolon adları bir kez tanımlanıyor, satırlar ise virgülle ayrılmış değerler olarak listeleniyor. LLM açısından bakıldığında:

• Daha az tırnak ve süslü parantez var.
• Anahtar adları tekrar etmiyor.
• Tablo yapısı satır/kolon bazlı daha net görünüyor.

Gerçek benchmark’larda, bu tür yapılarda JSON’a göre %30–50 civarı token tasarrufu rapor ediliyor.

TOON’un LLM Odaklı Avantajları

• Token tasarrufu: Özellikle büyük dizilerde ve log benzeri yapılarda ciddi tasarruf sağlar.
• Yapısal netlik: LLM, tabloyu satırlar ve kolonlar olarak daha kolay “okur”; sorgulama ve özetleme görevlerinde doğruluk artabilir.
• Ara format rolü: Uygulama tarafında hâlâ JSON kullanırken, LLM’e veri gönderirken JSON → TOON dönüşümü yaparak bağlam penceresini daha verimli kullanabilirsiniz.

TONL Formatı: Tanım, Amaç ve Özellikler

TONL (Token-Optimized Notation Language), yine LLM’ler için optimize edilmiş, metin-öncelikli bir serileştirme formatıdır. TOON gibi token verimliliğini hedefler; ancak yaklaşımı biraz daha geneldir: sadece tablosal veriyi değil, konfigürasyon, yapılandırılmış veri ve LLM I/O (girdi/çıktı) senaryolarını da kapsayan bir “notasyon dili” olarak tasarlanmıştır.

TONL’un temel farkı, JSON veri modelini bire bir kopyalamak yerine, daha kompakt bir sözdizimi sunmasıdır. Daha az süslü parantez, daha az tırnak ve LLM tokenleştirmesine göre optimize edilmiş semboller kullanır. Amaç, hem insanlar hem de makineler için okunabilir kalırken, JSON’a göre %50’ye varan token azaltımı sağlayabilmektir.

TONL’un Tasarım İlkeleri

• Kompakt sözdizimi: Gereksiz yapısal karakterleri azaltır; anahtarlar çoğu zaman tırnaksız, blok yapıları daha sade sembollerle ifade edilir.
• LLM tokenleştirmesine göre optimizasyon: Kullanılan semboller ve boşluk düzeni, yaygın tokenizer’ların davranışları dikkate alınarak seçilmiştir.
• Genel amaçlılık: Sadece tablosal veri değil, konfigürasyon dosyaları, fonksiyon çağrısı tanımları ve LLM çıktı formatları için de uygundur.
• Sıfır bağımlılık: Basit bir spesifikasyonla, farklı dillere gömülmesi kolay olacak şekilde tasarlanmıştır.

JSON ve TONL Yan Yana Örnek

Basit bir konfigürasyon düşünelim.

JSON:

{
  "service": "search",
  "replicas": 3,
  "features": {
    "logging": true,
    "tracing": false
  }
}

TONL (örnek sözdizimi):

service: search
replicas: 3
features:
  logging: true
  tracing: false

Burada dikkat ederseniz:

• Anahtarlar tırnaksız.
• Süslü parantez yok, blok yapısı girintiyle ifade ediliyor.
• Virgüller gereksiz; her satır bir alanı temsil ediyor.

Bu yapı, YAML’e benzer görünse de, TONL’ün amacı YAML’in genel esnekliğinden çok, LLM tokenleştirmesine göre optimize edilmiş, daha dar ve öngörülebilir bir sözdizimi sunmaktır.

TONL’un LLM Odaklı Avantajları

• Daha az yapısal gürültü: LLM’in gerçekten önemli olan anahtar ve değerleri daha az tokenla görmesini sağlar.
• Genel kullanım alanı: Tablosal veriyle sınırlı kalmadan, konfigürasyon, prompt şablonları, tool tanımları gibi geniş bir yelpazede kullanılabilir.
• Kolay gömülebilirlik: Basit parser’larla farklı dillere entegre edilebilir; JSON ↔ TONL dönüştürücüleri yazmak görece kolaydır.

TOON ve TONL’un JSON’dan Farkları – Karşılaştırmalı Analiz

Aşağıdaki tablo, JSON, TOON ve TONL’u birkaç temel boyutta karşılaştırır (26 Kasım 2025 itibarıyla ekosistem durumu da göz önüne alınarak):

Pratikte bu farklar ne anlama geliyor?

• JSON, hâlâ API’ler, depolama, mikroservisler arası iletişim ve genel veri alışverişi için en pratik ve standart çözüm.
• TOON, özellikle RAG, analitik raporlar, log/telemetri özetleri ve büyük tablosal veri setlerini LLM’e gönderirken ciddi token tasarrufu sağlayan bir ara format.
• TONL, hem yapılandırılmış veri hem de konfigürasyon ve LLM I/O senaryolarında, JSON’a göre daha kompakt ve model-dostu bir notasyon dili olarak konumlanıyor.

Büyük Dil Modelleri (LLM’ler) Bağlamında TOON ve TONL’un Önemi

LLM’ler, temelde metin dizilerini işleyen olasılıksal modellerdir. Ancak gerçek dünyadaki uygulamalarda, sadece düz metinle değil, yapılandırılmış veri, fonksiyon çağrıları ve bilgi tabanlarıyla da etkileşime girmeleri gerekir. Bu noktada şu kavramlar öne çıkar:

• Tool use / function calling: Modele, belirli bir şemaya uygun JSON (veya benzeri) çıktı üretmesi söylenir; bu çıktı daha sonra bir fonksiyon çağrısına dönüştürülür.
• Structured outputs: Modelden, belirli bir şemaya uyan yapılandırılmış yanıtlar istenir (örneğin bir dizi nesne, belirli alanlara sahip kayıtlar vb.).
• Knowledge grounding: Modelin, harici bir bilgi tabanından (RAG, vektör veritabanı, knowledge graph) çekilen veriye dayanarak yanıt üretmesi.

Bu senaryolarda, LLM’e gönderilen veri miktarı ve biçimi kritik hale gelir. JSON, bu amaçlar için yaygın olarak kullanılsa da, token verimliliği açısından ideal değildir. TOON ve TONL, tam da bu noktada avantaj sağlar.

Daha Zengin Semantik ve Bağlam

TOON’un tablosal yaklaşımı, LLM’in veriyi satır/kolon bazlı olarak daha net görmesini sağlar. Örneğin, bir satış raporunu düşünün:

sales:
  columns: date, region, amount
  rows:
    2025-11-01, EU, 12000
    2025-11-01, US, 15000
    2025-11-02, EU, 9000

Bu yapı, model için “tarih-bölge-tutar” üçlüsünü çok net bir şekilde ortaya koyar. JSON’da aynı veri, tekrar eden anahtarlar arasında kaybolabilir. LLM, TOON formatında sunulan bu tabloyu özetlerken veya sorgularken daha az hata yapabilir.

TONL tarafında ise, konfigürasyon ve tool tanımları gibi yapılarda, gereksiz tırnak ve parantezlerden arındırılmış, daha kompakt bir yapı sunmak, modelin hem girdiyi hem de çıktıyı daha az tokenla temsil etmesini sağlar.

Daha Güvenilir ve Doğrulanabilir Çıktılar

TOON ve TONL, doğrudan şema/ontoloji katmanı sunmasalar da, JSON ile birlikte kullanıldıklarında güçlü bir doğrulama zinciri oluşturabilirler:

1. Uygulama tarafında JSON Schema ile şema tanımlanır.
2. LLM’e, bu şemaya uygun TOON veya TONL çıktısı üretmesi söylenir.
3. Üretilen TOON/TONL, JSON’a dönüştürülür ve JSON Schema ile doğrulanır.

Bu akış, LLM kaynaklı hataları (eksik alanlar, yanlış tipler, bozuk yapı) tespit etmeyi kolaylaştırır. Özellikle kritik iş süreçlerinde (ödeme, sipariş, sağlık verisi vb.) bu tür doğrulama katmanları hayati önem taşır.

RAG ve Bilgi Tabanlı Sistemlerde Kullanım

RAG senaryolarında, genellikle vektör veritabanından çekilen belgeler veya kayıtlar, modele ek bağlam olarak gönderilir. Bu bağlamın boyutu, modelin yanıt kalitesi ve maliyeti üzerinde doğrudan etkilidir. TOON ve TONL, bu bağlamı daha kompakt biçimde temsil ederek:

• Aynı bağlam penceresine daha fazla kayıt sığdırmanıza,
• Veya aynı sayıda kayıtla daha düşük maliyetle çalışmanıza

olanak tanır.

Örneğin, bir kurumsal bilgi yönetimi asistanında, politika dokümanlarından çıkarılmış tablo ve listeleri TOON formatında modele göndermek, hem özetleme hem de soru-cevap görevlerinde daha iyi sonuçlar verebilir.

Güvenlik ve Halüsinasyon Azaltma

Yapılandırılmış ve şemalı formatlar, LLM halüsinasyonlarını tamamen ortadan kaldırmasa da, tespit etmeyi ve sınırlamayı kolaylaştırır. TOON/TONL → JSON → şema doğrulama zinciri sayesinde:

• Eksik veya fazla alanlar yakalanabilir.
• Tip uyuşmazlıkları tespit edilebilir.
• Beklenmeyen değerler (örneğin negatif fiyat, geçersiz tarih) filtrelenebilir.

Bu da özellikle üretim ortamında çalışan LLM tabanlı sistemlerin güvenilirliğini artırır.

Uygulama Örnekleri ve Kullanım Senaryoları

Geliştirici Perspektifinden Basit Akış

Diyelim ki bir e-ticaret sisteminiz var ve LLM’den, sipariş verilerini özetlemesini istiyorsunuz. Uygulama tarafında verileriniz JSON olarak tutuluyor:

[
  {"order_id": 1, "user": "alice", "total": 120.5, "status": "shipped"},
  {"order_id": 2, "user": "bob", "total": 80.0, "status": "pending"}
]

LLM’e doğrudan bu JSON’u göndermek yerine, önce TOON’a dönüştürebilirsiniz:

orders:
  columns: order_id, user, total, status
  rows:
    1, alice, 120.5, shipped
    2, bob, 80.0, pending

Ardından prompt’unuzda şöyle bir yapı kullanabilirsiniz:

Aşağıda TOON formatında son siparişler listesi var.
Bu veriyi kullanarak kısa bir özet üret ve riskli siparişleri işaret et.

<DATA>
[TOON VERİSİ BURAYA]
</DATA>

Model, daha az tokenla aynı bilgiyi görür ve özetleme görevini yerine getirir.

LLM’den TOON/TONL Çıktısı İstemek

Bir başka senaryoda, LLM’den belirli bir şemaya uygun veri üretmesini isteyebilirsiniz. Örneğin, teknik dokümantasyon asistanı geliştiriyorsunuz ve modelden hata raporlarını TOON formatında döndürmesini istiyorsunuz:

Lütfen aşağıdaki şemaya uygun TOON çıktısı üret:

- tablo adı: errors
- kolonlar: id, message, severity, component

Yanıtını sadece TOON formatında ver.

Beklenen çıktı örneği:

errors:
  columns: id, message, severity, component
  rows:
    101, Null pointer in payment flow, high, payments
    102, Slow response on search endpoint, medium, search

Bu çıktıyı uygulama tarafında JSON’a dönüştürüp, log sisteminize veya hata izleme aracınıza gönderebilirsiniz.

TONL tarafında ise, örneğin bir tool tanımı veya konfigürasyon çıktısı isteyebilirsiniz:

Aşağıdaki alanlara sahip bir servis konfigürasyonu üret ve TONL formatında döndür:
- service (string)
- replicas (int)
- logging_enabled (bool)

Modelin üreteceği TONL:

service: recommendation
replicas: 4
logging_enabled: true

Bu yapı, kolayca JSON’a veya başka bir formata dönüştürülebilir.

Entegrasyon Örnekleri

• API tasarımı: API’leriniz JSON döndürmeye devam eder; ancak LLM’e veri gönderirken, gateway katmanında JSON → TOON/TONL dönüşümü yaparsınız.
• Konfigürasyon yönetimi: İnsan tarafından düzenlenen konfigürasyon dosyalarını TONL formatında tutup, deploy sırasında JSON’a dönüştürebilirsiniz.
• ETL süreçleri: Büyük log veya analitik veri setlerini LLM tabanlı analiz aşamasına taşırken TOON formatına dönüştürerek maliyeti düşürebilirsiniz.

Performans, Ölçeklenebilirlik ve Araç Desteği

Performans açısından bakıldığında, TOON ve TONL’ün serileştirme/deserialize maliyeti, çoğu durumda JSON’a yakın veya biraz üzerindedir; çünkü ek bir dönüşüm katmanı söz konusudur. Ancak LLM tarafındaki token tasarrufu, bu ek maliyeti çoğu senaryoda fazlasıyla telafi eder.

• Serileştirme maliyeti: JSON → TOON/TONL dönüşümü için ek CPU süresi gerekir; ancak bu genellikle milisaniye mertebesindedir.
• Depolama boyutu: TOON/TONL, düz metin olarak saklandığında JSON’dan daha kompakt olabilir; ancak çoğu sistemde asıl depolama formatı yine JSON veya ikili formatlar (Parquet, Avro, Protobuf) olacaktır.
• Sorgulama ve indeksleme: TOON/TONL, doğrudan sorgulama için değil, daha çok LLM’e veri aktarımı için tasarlandığından, indeksleme genellikle orijinal veri formatı üzerinde yapılır.

Ekosistem tarafında (26 Kasım 2025 itibarıyla):

• TOON: Aktif GitHub reposu, Python ve JavaScript için örnek dönüştürücüler, blog yazıları ve benchmark’lar mevcut. Bazı RAG framework’lerinde (örneğin topluluk fork’larında) deneysel TOON desteği görülmeye başladı.
• TONL: Resmi site ve temel dokümantasyon mevcut; örnekler ve basit parser’lar yayınlanmış durumda, ancak TOON’a kıyasla daha erken aşamada.

Henüz hiçbirisi resmi bir standart değil; daha çok “LLM çağında JSON’a hafif, token-dostu alternatifler” olarak niş ve deneysel kullanımda.

Güncel Durum ve Gelecek Öngörüleri (26 Kasım 2025 İtibarıyla)

Bugün itibarıyla TOON ve TONL, geniş ölçekli kurumsal standartlar olmaktan ziyade, LLM topluluğu içinde hızla ilgi gören deneysel formatlar konumunda. Özellikle:

• RAG projeleri geliştiren start-up’lar,
• LLM tabanlı analitik ve gözlemlenebilirlik (observability) araçları,
• Prompt mühendisliği ve tool orchestration üzerine çalışan ekipler,

bu formatları denemeye ve blog yazılarıyla deneyimlerini paylaşmaya başladı.

Büyük bulut sağlayıcıları ve model platformları (OpenAI, Anthropic, Google, Azure OpenAI vb.) henüz resmi olarak TOON/TONL desteği açıklamış değiller; ancak structured outputs ve function calling özelliklerinin yaygınlaşması, bu tür formatlara olan ilgiyi artırıyor.

Geleceğe yönelik olası senaryolar:

• Birlikte var olma: JSON’un tamamen yerini almaları beklenmiyor; daha çok “LLM’e veri gönderirken kullanılan ara formatlar” olarak konumlanmaları olası.
• Standartlaşma: Eğer toplulukta yeterli benimsenme sağlanırsa, TOON/TONL benzeri formatlar için hafif RFC’ler veya community spec’ler ortaya çıkabilir.
• Araç zinciri entegrasyonu: LangChain, LlamaIndex, Haystack gibi LLM araç zincirlerinin, JSON dışında TOON/TONL gibi formatları da desteklemesi beklenebilir.
• Otomatik dönüştürücüler: API gateway’leri ve LLM proxy’leri, JSON ↔ TOON/TONL dönüşümünü şeffaf biçimde yaparak geliştiricinin işini kolaylaştırabilir.

Sonuç

TOON ve TONL, JSON’un basitliğini ve yaygınlığını hedef almadan, LLM çağında ortaya çıkan çok spesifik bir soruna odaklanıyor: token verimliliği ve model için okunabilirlik. JSON, API’ler, depolama ve genel veri alışverişi için hâlâ en pratik ve standart çözüm olmaya devam ediyor. Ancak LLM’e büyük miktarda yapılandırılmış veri gönderirken, JSON’un sözdizimsel gürültüsü ve tekrarlı anahtarları ciddi bir maliyet oluşturuyor.

TOON, özellikle tablosal ve tekrarlı yapılarda kolon başlıkları + satırlar yaklaşımıyla, JSON’a göre %30–60’a varan token tasarrufu sağlayabiliyor. TONL ise daha genel bir notasyon dili olarak, konfigürasyon ve LLM I/O senaryolarında daha kompakt ve model-dostu bir alternatif sunuyor.

Hangi durumda ne kullanmalı?

• Sadece API ve depolama: JSON yeterli ve pratik.
• LLM’e büyük tablosal veri, log veya analitik rapor göndermek: TOON ciddi avantaj sağlar.
• LLM tabanlı konfigürasyon, tool tanımları, prompt şablonları: TONL gibi kompakt notasyonlar daha uygun olabilir.

İlk adım olarak, mevcut LLM iş akışlarınızda JSON → TOON/TONL dönüşümünü küçük bir pilot projede deneyebilir, token tasarrufunu ve yanıt kalitesini ölçebilirsiniz. Resmi TOON ve TONL dokümantasyonlarını inceleyerek, kendi dilinizde basit dönüştürücüler yazabilir veya mevcut açık kaynak kütüphaneleri entegre edebilirsiniz.

LLM ekosistemi geliştikçe, TOON ve TONL gibi formatların rolü de netleşecek. Ancak bugün bile, özellikle maliyet duyarlı ve veri yoğun senaryolarda, bu hafif formatları denemek için yeterince güçlü gerekçeler mevcut.

Etiketler

#TOON #TONL #JSON #LLM #YapayZeka #RAG #VeriFormatları #TokenOptimizasyonu

Kaynakça

• https://github.com/toon-format/toon
• https://openapi.com/blog/what-the-toon-format-is-token-oriented-object-notation
• https://tonl.dev/

Tarih: 26 Kasım 2025