Üç format bir planlama toplantısına giriyor. JSON her şeyi yönetebileceğini söylüyor. CSV hızlı ve hafif olduğunu söylüyor. TOON yapay zeka ile konuşmak için orada olduğunu söylüyor. Hepsi haklı — farklı işler için. Can sıkıcı kısım bu formatların var olması değil, kullanım senaryonuz için yanlış olanı seçmenin sizi gerçek, somut şekillerde etkilemesidir: ayrıntılı yükler, bozuk içe aktarmalar, pahalı LLM faturaları veya ayrıştırma baş ağrıları. Bu kılavuz size net bir seçim çerçevesi sunar.

Her Formatın Hızlı Bir Portresi

JSON (JavaScript Object Notation), 2000'lerin başında JavaScript'ten ortaya çıktı ve basitliği ve ifade gücü sayesinde web API'leri için baskın format haline geldi. İç içe geçmiş yapıları yerel olarak yönetir, ek bir törensel öge gerektirmeksizin dizeler, sayılar, booleanlar ve null'lar arasında ayrım yapar ve RFC 8259 tarafından belirtilmiştir. Her modern dilin birinci sınıf bir JSON kütüphanesi vardır.

CSV (Comma-Separated Values, Virgülle Ayrılmış Değerler) webden daha eski. RFC 4180 tarafından tanımlanmış ve özünde düz tablo verilerinin ortak dili. Herhangi bir CSV'yi Excel, Google Sheets veya Numbers'da açın ve çalışır. Saf düz tablolar için mevcut en kompakt ve evrensel olarak içe aktarılabilir format budur.

TOON özellikle LLM iş akışları için oluşturulmuş daha yeni bir format. Her ikisinden de ilham alır — CSV gibi tablo verileri için başlık-bir-kez-sonra-satırlar yapısı kullanır, ancak JSON gibi iç içe geçmiş nesneleri ve dizileri de kodlayabilir. Tüm tasarımı, büyük dil modellerine veri iletirken ve alırken token sayısını en aza indirmeye yöneliktir.

Üç Formatta Aynı Veriler

Bunu somutlaştırmak için, iç içe geçmiş bir specs nesnesi içeren bir ürün kataloğu kullanalım — üç formatı da anlamlı şekilde kullanan gerçek dünya şekli. Bir elektronik mağazasından dört ürün:

JSON — ifadeli, iç içe geçişi doğal olarak yönetir, ancak tekrarlayan satır verileri için ayrıntılı:

json
[
  {
    "id": "P001",
    "name": "Wireless Headphones",
    "category": "Audio",
    "price": 79.99,
    "inStock": true,
    "specs": { "weight": "250g", "connectivity": "Bluetooth 5.2", "battery": "30h" }
  },
  {
    "id": "P002",
    "name": "USB-C Docking Station",
    "category": "Peripherals",
    "price": 129.99,
    "inStock": true,
    "specs": { "ports": 11, "maxPower": "100W", "display": "4K@60Hz" }
  },
  {
    "id": "P003",
    "name": "Mechanical Keyboard",
    "category": "Input",
    "price": 94.99,
    "inStock": false,
    "specs": { "layout": "TKL", "switches": "Cherry MX Red", "backlight": "RGB" }
  },
  {
    "id": "P004",
    "name": "27" IPS Monitor",
    "category": "Display",
    "price": 299.99,
    "inStock": true,
    "specs": { "resolution": "2560x1440", "refreshRate": "165Hz", "panel": "IPS" }
  }
]

CSV — kompakt, Excel dostu, ancak iç içe geçmiş specs nesnesi düzleştirilmek zorunda. Bunu temsil etmenin standart bir yolu yok, bu nedenle ya iç içe geçişi kaybediyoruz ya da bir dizeye dönüştürüyoruz:

text
id,name,category,price,inStock,specs_weight,specs_ports,specs_layout,specs_resolution
P001,Wireless Headphones,Audio,79.99,true,250g,,,
P002,USB-C Docking Station,Peripherals,129.99,true,,11,,
P003,Mechanical Keyboard,Input,94.99,false,,,TKL,
P004,27" IPS Monitor,Display,299.99,true,,,,2560x1440
CSV'deki seyrek sütunlara dikkat edin. Her ürünün farklı özellik anahtarları olduğundan, her olası özellik alanı için bir sütun oluşturmak zorunda kaldık — ve satırların çoğu büyük ölçüde boş. Bu, tekdüze olmayan iç içe geçmiş veriler için CSV kullanmanın temel sorunudur.

TOON — başlık bir kez tanımlanır, satırlar kompakttır, iç içe geçmiş nesneler satır içinde kodlanır:

text
products[4]{id,name,category,price,inStock,specs}:
  P001,Wireless Headphones,Audio,79.99,true,{weight:250g,connectivity:Bluetooth 5.2,battery:30h}
  P002,USB-C Docking Station,Peripherals,129.99,true,{ports:11,maxPower:100W,display:4K@60Hz}
  P003,Mechanical Keyboard,Input,94.99,false,{layout:TKL,switches:Cherry MX Red,backlight:RGB}
  P004,27" IPS Monitor,Display,299.99,true,{resolution:2560x1440,refreshRate:165Hz,panel:IPS}

Her Formatın Çöktüğü Yer

Başarısızlık modlarını anlamak, güçlü yönleri bilmek kadar önemlidir.

  • JSON tablolar için çöker. Her satırda her anahtar adını tekrarlamak gerçekten israftır. Her satırın 8 anahtarı olduğu 1000 satırlık bir veri kümesi, "id", "name", "price" vb.nin her biri 1000 kez yazılması anlamına gelir. LLM girişi için bu doğrudan token maliyetine dönüşür; insan incelemesi için sadece gürültüdür.
  • CSV iç içe geçmiş veriler için çöker. Formatta iç içe geçme kavramı yoktur. İç içe geçmiş bir nesneyi bir hücreye dizeye dönüştürebilirsiniz, ancak tüketicinin o hücreyi ayrıştırmayı bilmesi gerekir — sorunu sadece taşımış olursunuz. CSV'nin yerel bir tür sistemi de yoktur: true bir dizedir, 42 bir dizedir, null belirsizdir. Araçlar bunu tutarsız şekilde ele alır.
  • TOON LLM bağlamları dışında çöker. Daha dar bir ekosisteme sahip niş bir formattır. PostgreSQL'de, REST çerçevenizde veya Excel'de yerel TOON desteği bulamazsınız. npm paketi JavaScript/TypeScript iş akışlarını iyi kapsar, ancak yapay zeka ile ilgisi olmayan bir bağlamda TOON kullanıyorsanız muhtemelen aşırı mühendislik yapıyorsunuzdur.
  • CSV virgül veya satır sonları içeren değerler için çöker. RFC 4180 tırnaklaması kuralları bunu ele alır, ancak birçok CSV üretici ve tüketicisi bunları tutarsız şekilde uygular. 27" IPS Monitor, Black gibi bir ürün adı veya satır sonları olan bir açıklama güvenilirlik riski haline gelir.

Karar Matrisi

İşte pratik bir kılavuz. Durumunuzu uygun formatla eşleştirin:

  • Verileriniz bir LLM istemine gidiyor → TOON. Özellikle tablo şeklindeyse. API çağrısından önce dönüştürmek için JSON'dan TOON'a kullanın.
  • Verileriniz bir LLM'den dönüyor ve işlenmesi gerekiyor → TOON (çıktı için), sonra aşağı akış kullanımı için TOON'dan JSON'a ile JSON'a veya yerel nesneye çözün.
  • Verileriniz tamamen düz tablo (her satırda aynı anahtarlar) ve elektronik tablolara gidiyor/geliyor → CSV. En küçük temsil ve evrensel olarak içe aktarılabilir.
  • Verileriniz düz tablo ama kod tarafından dönüştürülecek (elektronik tablolar değil) → CSV veya JSON. Tipler önemliyse JSON daha güvenlidir (true yerine "true" istemezsiniz).
  • Verilerinizin iç içe geçmiş nesneleri veya dizileri var → JSON. CSV'nin sadece düz sınırlamasıyla savaşmayın. İç içe geçme bir LLM'ye gidiyorsa, yapıyı oluşturduktan sonra TOON'a kodlayın.
  • Verileriniz bir REST API'ye gidiyor veya bir veritabanında depolanıyor → JSON. Her zaman.
  • Verileriniz bir yapılandırma dosyası → JSON veya YAML. Ne CSV ne de TOON burada yer alır.
  • Maksimum taşınabilirlik ve bağımlılıksız ayrıştırıcı ihtiyacınız var → JSON veya CSV. Her ikisi de her yerde yerel veya neredeyse yerel destek sunar.

Tek Bir Hatta Üçünü Birden Kullanma

Gerçekçi bir hat üçünü de kullanabilir. AI tarafından oluşturulan açıklamalarla ürün verilerini zenginleştiren bir e-ticaret iş akışı hayal edin:

ts
import { encode, decode } from '@toon-format/toon';

// Step 1: Products arrive as JSON from your REST API
const products = await fetch('/api/products').then(r => r.json());

// Step 2: Encode to TOON to minimise tokens before the LLM call
const toonInput = encode(products);

const response = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [
    {
      role: 'user',
      content: `Here is our product catalogue in TOON format:\n\n${toonInput}\n\n
                For each product, write a one-sentence marketing description.
                Return results as TOON with fields: id, description`
    }
  ]
});

// Step 3: Decode the LLM's TOON response back to objects
const enriched = decode(response.choices[0].message.content);

// Step 4: Export to CSV for the marketing team's spreadsheet
const csvRows = enriched.map(row => `${row.id},"${row.description}"`);
const csv = ['id,description', ...csvRows].join('\n');

API katmanı için JSON, LLM katmanı üzerinden TOON, insan tarafından okunabilir çıktı için CSV. Her format tam olarak tasarlandığı işi yapıyor.

Hızlı Araç Referansı

Bu formatlar arasında geçiş yapıyorsanız, bu araçlar yaygın dönüşümleri kapsayacaktır. TOON Biçimleyici TOON dizelerini doğrulamak ve temizlemek için en hızlı yoldur. JSON'dan TOON'a dönüştürücü LLM hazırlık adımını yönetir. Bir LLM TOON döndürdükten sonra diğer yönde giderken, TOON'dan CSV'ye doğrudan elektronik tablo hazır bir dışa aktarma üretebilir ve CSV'den JSON'a, Excel veya üçüncü taraf veri sağlayıcılarından içe aktarmaları normalleştirmek için başvurulacak araçtır. TOON'a özgü ayrıntılar için resmi paket npm'de yer alır.

Özet

JSON, CSV ve TOON'un her birinin net bir alanı vardır. JSON, yapılandırılmış veri değişimi için evrensel format — iç içe geçmiş veya düz, API'ler, yapılandırma, depolama. CSV, sistemler ve insanlar arasında seyahat etmesi gereken düz tablo verileri için evrensel format — elektronik tablolar, içe aktarmalar, dışa aktarmalar. TOON, her tokenın önemli olduğu yapay zeka sistemleri üzerinden yapılandırılmış veri aktarımı için formattır. Çoğu geliştiricinin yaptığı hata, LLM istemleri dahil her şey için JSON'a varsayılan olarak geçmek veya CSV'ye varsayılan olarak geçip proje ortasında iç içe geçme gereksinimlerini keşfetmektir. Verilerinizin şeklini bilin, nereye gittiğini bilin ve doğru format genellikle kendiliğinden seçilir.

Özellikle JSON ile TOON arasındaki değiş tokuşa daha derin bir dalış için, TOON ile JSON karşılaştırmasına bakın. CSV spesifikasyonu ve tuhaflıkları hakkında arka plan için, CSV hakkında Wikipedia makalesi geçmişi ve format çeşitlemelerini iyi kapsar.

← All TOON articles Browse all categories →