- e-ticaret verileriyle çalışan yapay zeka uygulamalarının geliştirilmesine yardımcı olunurken, Retrieval-augmented generation (RAG) yaklaşımının bazı sorgularda iyi çalışırken bazılarında çalışmadığı bir sorun fark edildi
- Bu tür sorunları çözerken girdi verilerini (indekslenen kaynak metin, aramada kullanılan kullanıcı sorguları) incelemek önemlidir
- Özellikle chunking ve tokenization açısından optimizasyon gerektiği görüldü
[Tokenization]
- Tokenization, metnin tokenizer tarafından token adı verilen daha küçük parçalara ayrılması sürecidir
- Bu token'lar, tokenizer sözlüğünde token'ı benzersiz olarak tanımlayan tamsayı değerleri olan token ID'lere eşlenir
- Tokenizer sözlüğü, tokenizer eğitimi sırasında kullanılan tüm olası token'ların kümesidir
- Metindeki token'lar LLM'in tokenizer sözlüğünde yoksa sorun çıkabilir
- Çoğu LLM 30k~300k büyüklüğünde geniş bir sözlüğe sahiptir
- Yaygın olarak kullanılan çoğu LLM, subword tokenizer'lara dayanır (BPE, Wordpiece vb.)
- Tokenizer türleri
- word: boşluk karakterleri ve noktalama işaretleri gibi sınırlara göre bölme
- character: tek tek karakterlere (bazen noktalama işaretlerine kadar) bölme
- subword: token'ları anlamlı görünmeyen alt sözcüklere bölme
- çoğu LLM subword tokenizer kullanır
- BPE(Byte-Pair Encoder): OpenAI'nin tiktoken kütüphanesi
- Wordpiece: Cohere, MiniLM-L6-v2 vb.
MiniLM-L6-v2 ve tiktoken karşılaştırması
- MiniLM-L6-v2 modelinin tokenizer sözlük boyutu 30522 olup tiktoken'dan (200019) çok daha küçüktür
- "tokenizer tokenizes text into tokens" cümlesi tokenize edildiğinde
- MiniLM-L6-v2: [CLS] token ##izer token ##izes text into token ##s [SEP]
- tiktoken: token, izer, token, izes, text, into, tokens
- OpenAI'nin tiktoken kütüphanesi BPE tokenizer uygular ve ChatGPT LLM modellerinde kullanılır
- MiniLM-L6-v2 sözlüğünde Almanca ve Japonca karakterler de bulunur
Emoji, yazım hataları ve alan-özel kelimelerin tokenization'ı
- MiniLM-L6-v2, emojileri [UNK] token'ı olarak tokenize eder
- tiktoken bazı Unicode karakter token'larıyla eğitilmiş olsa da RAG için yine de sorun yaratabilir
- "Gucci Savoy Leathertrimmed Printed Coatedcanvas Suitcase" gibi alan-özel ürün adları da düzgün tokenize edilmez
- Yazım hatalı bir cümlede ("I hve received wrong pckage")
- MiniLM-L6-v2: i, h, ##ve, received, wrong, pc, ##ka, ##ge
- tiktoken: I, h, ve, received, wrong, p, ck, age
[Embeddings]
- Tokenizer tek başına çok faydalı değildir. Esas olarak tekil token frekanslarına dayalı karmaşık sayısal analizler yapmak için geliştirilmiştir
- Metnin bağlamsal anlamını korumak için token'lar arasındaki ilişkileri yakalayabilen bir yönteme ihtiyaç vardır
- Embedding'ler, token'ları temsil eden vektörlerdir ve metindeki sözcüklerin anlamını ve aralarındaki ilişkileri iyi yakalar
- Embedding'ler, transformer eğitiminin bir yan ürünüdür ve gerçekte tokenize edilmiş büyük metin yığınlarından öğrenilir
- Metin üretimi istendiğinde LLM'e girdi olarak verilen şey embedding'lerdir
- LLM iki ana bileşenden oluşur: encoder ve decoder
- Hem encoder hem decoder embedding'leri girdi olarak alır
- Encoder'ın çıktısı da embedding'dir; bu çıktı decoder'ın cross-attention head'lerine iletilir ve decoder çıktısındaki token üretiminde (tahmininde) önemli rol oynar
- RAG hattında metin önce tokenize edilir, sonra embedding'e dönüştürülür ve ardından transformer'a girer
- Token ID'ler tokenizer sözlüğünde indeks görevi görür ve embedding matrisinden embedding almak için de kullanılır
- Alınan embedding'ler tensor olarak birleştirilip transformer girdisi olarak verilir
- Encoder akışı: metni tokenize etme -> her token için embedding alma -> embedding tensor'unu oluşturma -> transformer girdisine verme -> encoding -> encoder çıktısını decoder cross-attention'ına iletme -> decoder çıktısını üretme
Embedding örnekleri
- "You can break it 😞" ile "You can not break it 😊" duygusal olarak zıt olsalar da MiniLM-L6-v2'de embedding mesafeleri çok yakındır
- OpenAI, token sözlüğü emojileri iyi işlediği için daha iyi performans gösterir
- Yazım hatalarında da OpenAI daha iyi sonuç verir
- Ancak OpenAI'de bile cümlenin sonuna boşluk eklendiğinde embedding'ler arasındaki mesafe beklenmedik biçimde açılır
- Tarih biçimlerini ele alırken geliştiriciler zorlanır. Göreli zaman ifadeleri ("dün gönderildi") özellikle daha büyük sorun olabilir
- Para birimi yazım biçimlerindeki farklılıklar (£40, $50, 40£, 50¢ vb.) da tuhaf sorunlara yol açabilir
- Gucci çanta örneğinde olduğu gibi alan-özel veriler için bu genelde fine-tuning ile çözülür, ancak veri ve değerlendirme metrikleri her zaman mutlaka kontrol edilmelidir
Sonuç
- Bu yazı, tokenizer'ların RAG uygulamalarını nasıl etkileyebileceğini ve neden tokenizer'lara dikkat etmek gerektiğini daha iyi anlamayı sağlıyor
- Agent uygulamalarında garbage-in garbage-out her zaman beklendiği kadar iyi sonuç vermeyecektir
- Girdi metnini biraz temizlemek bile büyük fayda sağlayabilir
- Tarih biçimlerini tutarlı şekilde standartlaştırın
- Mümkün olduğunca sondaki boşlukları kaldırın (embedding üzerindeki etkisi görüldü)
- Aynısını farklı para birimlerindeki fiyatlar gibi diğer sayısal veriler için de uygulayın
- Bir gün tokenizer'ları hiç düşünmek zorunda kalmamayı diliyorum. Tamamen ortadan kaldırabilmeyi
- O zaman yazım hataları, rastgele boşluk karakterleri, sözcük perplexity tabanlı adversarial saldırılar gibi şeylerle uğraşmaya gerek kalmaz. Bir tür keder bir gecede yok olabilir
- O zamana kadar sorumlulukla tokenize edin
GN⁺ Görüşü
- Bu yazı, tokenizer'ların ve embedding'lerin RAG tabanlı yapay zeka uygulamalarının performansını nasıl etkileyebileceğini iyi gösteriyor. Özellikle emojiler, yazım hataları ve alan-özel terimler ele alınırken dikkat edilmesi gereken noktaları gerçek örneklerle anlattığı için geliştiricilere çok yardımcı olabilir
- Ancak bu yazıda tanıtılan MiniLM-L6-v2 ve OpenAI'nin tiktoken'ı, İngilizceye optimize edilmiş modellerdir; bu nedenle Korece gibi başka diller ele alınırken ek hususlar olabilir. Korece için morfolojik çözümleyici kullanan tokenization yaygındır; buna bağlı avantajlar, dezavantajlar ve sınırlamalar da incelenmeye değerdir
- Ayrıca bu yazı RAG hattında tokenizer ve embedding'in rolüne odaklansa da gerçek üretim ortamlarında veri ön işleme, hiperparametre ayarı, model hafifletme gibi dikkate alınması gereken çok daha fazla konu vardır. Bu yüzden yazının içeriği bir başlangıç noktası olarak alınmalı, ancak gerçek geliştirme sürecinde çeşitli deneyler ve değerlendirmelerle en uygun yöntem bulunmalıdır
- Öte yandan GPT-4 gibi büyük dil modellerinin ortaya çıkışıyla tokenizer'ların öneminin azaldığını savunan görüşler de vardır. Bunun nedeni, bu modellerin token düzeyi yerine cümle veya paragraf düzeyinde çalışması ve bu yüzden tekil token kalitesinin performansa etkisinin görece azalabilmesidir. Ancak bu konuda henüz yeterli araştırma olmadığı için kesin konuşmak zordur
- Son olarak, yazıda belirtildiği gibi, girdi verisini önceden temizlemek ve standartlaştırmak bile model performansını ciddi biçimde iyileştirebilir. Gerçek hizmet geliştirirken kullanıcı girdisinin çeşitliliği ve gürültüsü dikkate alınarak dayanıklı bir veri ön işleme hattı kurmak çok önemlidir. Bunun yanında veri etiketleme ve anotasyon çalışmalarına da yeterli kaynak ayırarak yüksek kaliteli eğitim verisi sağlamak gerekir
1 yorum
Hacker News görüşü
Tokenizer, LLM’lerin "seksi" kısmı olarak görülmüyor, ancak bunu fırsat olarak görenler de var. xVal gibi makaleler, tokenization için uzmanlaşmış stratejiler öneriyor. Heceleme ve karakter düzeyindeki işler de tokenization yeniliklerinden fayda görebilecek başka bir sorun alanı
Anlamlı işler yapabilmek için veriyi anlamak gerekir. Birçok insanın otomatik veri işleme araçlarını kullanmasının başlıca nedeni, veriye doğrudan bakmak istememeleri. Bilgisayarın veriyi görüp ek bilgi toplama taleplerinde bulunabilmesini istiyorlar
Blog yazısındaki yazım hatalarıyla ilgili kısmı özellikle takdir ettim. Bir projede RAG benzeri uygulamalara yardımcı oluyorum ve kullanıcı sorgularındaki küçük yazım hatalarının veya biçim farklarının embedding mesafesi hesaplamalarını nasıl etkilediği konusunda endişeliyim
wrkilework’ün muhtemelen eşanlamlı olduğunu öğrenmesini sağlayıp sağlamamak gerektiğini düşünüyorumElasticsearch kullanarak, 1-2 cümlelik girdiler ile paragraf uzunluğundaki belgeler arasındaki benzerliği gelişmiş metin sorgularıyla ele alan bir uygulamada çalışma deneyimim oldu. Tokenization stratejisinin belirli sorguları ne kadar etkileyebildiğini görmek ilginçti
W-4veyaW4gibi durumlarda, standart tokenization-işaretinden veya harf/rakam sınırından bölebilir. Bu girdi, indeks içinde tamamen tanınamaz hale gelebilirMakalede her sorun için çözümlerin tartışıldığı bölümün eksik olduğunu düşünüyorum. Yazım denetimini tokenization’dan önce çalıştırmayı veya yanlış yazılmış kelimeleri ve olası düzeltilmiş hallerini yan yana tokenization etmeyi öneriyorum
Birçok geliştirici geleneksel (deterministik) alanda geliştirme yapmaya alışkın, ancak sorunları istatistiksel alanda düşünme biçimine geçemiyor. LLM uygulamaları sonuçta istatistiksel bir alan
RAG uygulayan çoğu kişi tokenization yerine embedding hakkında düşünüyor
Blog yazısındaki bazı sayıları yeniden üretemiyorum. Örneğin SentenceTransformer kullanan kodda iki cümlenin cosine similarity değerini hesapladığımda sonuç beklediğim gibi çıkmıyor
Birden fazla RAG uygulamasında, hedef belgenin gelen sorgu için iyi bir arama anahtarı olacağını varsayma sorununu gördüm. Yakın tarihli bir projede arama anahtarını döndürülen değerden (parçalara ayrılmış belge) ayırıp uygun anahtarı üretmek için LM kullanarak ve bunu embedding’e dönüştürerek arama ilgililiğini büyük ölçüde artırdık
Birçok büyük LLM söz dağarcığının epey büyük olduğu söyleniyor, ancak yalnızca İngilizcede bile 1 milyondan fazla kelime var. 30k-300k token küçük görünüyor