500 Satır SQL ile Yazılmış GPT

 (explainextended.com)
1 puan yazan GN⁺ 2024-02-25 | 1 yorum | WhatsApp'ta paylaş
  • Yalnızca PostgreSQL ve pgvector kullanarak GPT-2 çıkarım akışını SQL'e taşıyor; tokenization'dan Transformer bloklarına ve bir sonraki token üretimine kadar tüm süreci yeniden kuruyor
  • Üretken LLM'ler, aynı girdide aynı aday token olasılıklarını veren deterministik işlevlere yakındır; yanıtın değiştiği nokta, aday token'ların seçildiği olasılıksal seçim aşamasıdır
  • Uygulama, GPT-2'nin BPE tokenizer'ını, 50.257 token'ı, 768 boyutlu embedding'leri, 1.024 token context window'u, 12 blok, 12 attention head ve GELU tabanlı feedforward yapısını SQL sorguları ve tablolarla ifade ediyor
  • PostgreSQL regex'lerinin Unicode özelliklerini desteklememesi ve EXP fonksiyonunun çok küçük değerleri işlemedeki sınırları gibi nedenlerle, veritabanı ortamına uygun gerçekçi geçici çözümler gerekti
  • Örnek, "Happy New Year! I wish you" ifadesinden 10 token üreterek "Happy New Year! I wish you all the best in your new year!" çıktısını verdi ve yazarın ortamında 2 dakika 44 saniye sürdü

SQL ile GPT-2 çıkarım hattı kurmak

  • ChatGPT, SQL'in büyük dil modeli uygulamak için uygun olmadığını söylemiş olsa da, PostgreSQL SQL ile bir GPT-2 çıkarım hattı uygulanmış
  • Başvurulan uygulama açıklaması Jay Mody'nin GPT in 60 Lines of NumPy yazısı ve aynı bileşenler veritabanı tabloları ile sorgulara taşınmış
  • Üretken bir LLM, llm(prompt: str) -> list[tuple[str, float]] biçiminde bir işlev gibi görülebilir
    • Girdi, metin prompt'udur
    • Çıktı, sıradaki olası string'ler ve bunların olasılık dizisidir
    • İç matematik ve parametreler aynıysa, aynı girdiye aynı sonucu döndürür
  • ChatGPT gibi ürünlerin aynı soruya farklı yanıtlar verebilmesinin nedeni, modelin kendisinden çok bir sonraki token seçimi aşamasındaki olasılıksal tercihtir

Metin üretim döngüsü

  • Üretim süreci, prompt'u bir token dizisine çevirdikten sonra modeli tekrar tekrar çağırıp bir sonraki token'ı seçerek bunu prompt'un sonuna ekleyen bir yapıdadır
  • Temel akış şu adımlardan oluşur
    • tokenize(prompt) ile string'i token ID dizisine dönüştürme
    • gpt2(tokens) ile 50.257 token için olasılık hesaplama
    • select_next_token(candidates) ile sonraki token'ı seçme
    • Seçilen token'ı diziye ekleme
    • Belirlenen token sayısı, timeout veya stopword gibi koşullarda durma
    • detokenize(tokens) ile token dizisini yeniden string'e çevirme
  • Bu şekilde biriken token dizisi; dilbilgisi, sözdizimi, anlam ve akıl yürütme izlenimi taşıyan doğal dil metnine dönüşebilir

BPE tokenizer'ı SQL ile uygulamak

  • Sinir ağına girdi olmadan önce metnin sayı listesine çevrilmesi gerekir; ancak Unicode code point'lerini doğrudan kullanmak token uzayı ve uzunluk açısından verimsizdir
  • GPT-2, Byte pair encoding'in bir varyantını kullanır
    • Token sözlüğü 50.257 code point kullanır
    • UTF-8 byte dizilerini ve “end of text” token'ını içerir
    • Başlangıçta 256 byte token ile başlar, ardından sık görülen bitişik token çiftlerini yeni token'lar olarak ekler
    • Bu birleştirme işlemi 50.000 kez tekrarlanarak 50.256 token elde edilir ve son olarak end-of-text token'ı eklenir
  • GPT-2 tokenizer'ında byte'ları string karakterlerine eşleyen ek bir katman vardır; bu eşleme OpenAI GPT-2'nin encoder.py dosyasında tanımlanır
  • SQL uygulamasında OpenAI'den indirilen token sözlüğü tokenizer tablosuna, byte-karakter eşlemesi ise encoder tablosuna kaydedilmiş
  • "Mississippilessly" örneği, recursive CTE ile tek byte'lardan başlayıp birleştirilebilecek en iyi bitişik çifti tekrar tekrar birleştiriyor
    • Örnekte token sayısı 17'den 5'e düşüyor
    • Unicode'un yaklaşık 150 bin code point'lik alanı yerine GPT-2'nin yaklaşık 50 bin token'lık alanı kullanılıyor
  • Birden çok kelime işlenirken GPT-2, metni regex ile bölüp her kelimenin içinde birleştirme yapıyor
    • PostgreSQL, regex içinde Unicode karakter özelliklerini desteklemediği için özgün GPT-2 regex'i kısmen değiştirilmiş
    • Bu değişiklik uygun Unicode desteğini zedelemiş olabilir
  • "PostgreSQL is great", SQL tokenizer'da [6307, 47701, 318, 1049] biçimine dönüşür
    • Token kümeleri Post, greSQL, Ġis, Ġgreat şeklindedir
    • Ġ boşluğu temsil eder

Embedding ve context window

  • Token ID'leri model hesaplamasında doğrudan kullanılmaz; önce embedding vektörlerine dönüştürülür
  • GPT-2, token ve konumu ayrı ayrı embedding eder
    • WTE, word token embedding'dir ve 50257×768 matristir
    • WPE, word position embedding'dir ve 1024×768 matristir
  • Her token konumu için WTE vektörü ile WPE vektörü toplanarak sonraki aşamanın giriş vektörü oluşturulur
  • WPE yalnızca 1024 konum içerdiği için, GPT-2 prompt'unda kullanılabilecek azami token sayısı 1024'tür
    • Bu sayı, LLM'in context window'una karşılık gelir
    • Model tasarlanırken belirlenen bir hiperparametredir; eğitimle değişmez
  • SQL uygulaması pgvector kullanır
    • Vektör işlemleri dizi üzerinde tanımlanarak saf SQL ile de yapılabilir, ancak performans düşer
    • İlk sürüm saf SQL işlevleriyle çalışıyordu ama yavaştı

self-attention'ı SQL sorgularına açmak

  • Transformer'ın çekirdeği self-attention mekanizmasıdır ve 2017 tarihli Attention is all you need makalesine dayanır
  • Attention, token vektörlerinin birbirini etkilemesini sağlayarak prompt'un başındaki bilginin son vektöre taşınmasına imkan verir
  • GPT-2 uygulaması 12 set Q, K, V matrisi kullanır
    • Her set bir attention head'dir
    • Her head 64 boyutludur
    • c_attn, 768×2304 doğrusal dönüşümdür; sonuç, yatay olarak birleştirilmiş Q, K, V içeren 2304 boyutlu vektördür
    • Ağırlıklar ve bias değerleri c_attn_w, c_attn_b tablolarında tutulur
  • Attention hesabından önce layer normalization uygulanır
    • Scale ve shift parametreleri ln_1_g, ln_1_b tablolarında saklanır
  • Causal self-attention'da, sonraki token'ların önceki token'ları etkilemesini önlemek için causal mask uygulanır
    • Modelin bir sonraki token adayı en sonunda son embedding'den belirlenir
    • Bilgi akışı son vektöre doğru gitmelidir; son vektörün ara değerleri önceki vektörleri etkilememelidir
  • SQL uygulaması, softmax hesabında PostgreSQL EXP'nin çok küçük sayılarda başarısız olmasını önlemek için girdi -745.13'ten küçükse bunu 0 kabul eder
  • Causal mask sayesinde yeni token prompt'a eklendiğinde önceki token'lar için hesaplanan sonuçlar değişmez
    • Özgün GPT-2 uygulaması bu özelliği kullanır
    • SQL uygulaması ise sadelik için bu yeniden kullanımı yapmaz

multi-head attention ve residual connection

  • 12 head'in attention sonuçları ayrı ayrı 64 boyutludur; bunlar yatay olarak birleştirilip yeniden 768 boyuta getirilir
  • Ardından, c_proj_w, c_proj_b içinde saklanan eğitilmiş doğrusal dönüşüm ile attention çıktısı projekte edilir
  • multi-head attention sonucuna özgün girdi yeniden eklenir
    • Bu residual connection, özgün Transformer makalesinde yer alan bir tekniktir
    • Eğitim sırasında vanishing gradient ve exploding gradient sorunlarını hafifletmek için sunulmuştur

feedforward aşaması ve Transformer blokları

  • Attention'dan sonra bir feedforward sinir ağı gelir
  • GPT-2'nin feedforward aşaması, 3 katmanlı bir multi-layer perceptron'dan oluşur
    • Boyutlar 768 → 3072 → 768'dir
    • Aktivasyon işlevi olarak GELU kullanılır
  • Doğrusal dönüşüm parametreleri şu tablolarda tutulur
    • mlp_c_fc_w, mlp_c_fc_b
    • mlp_c_proj_w, mlp_c_proj_b
  • Feedforward girdisi de önce ln_2 parametreleri ile normalize edilir
    • ln_2_g, ln_2_b scale ve shift değerlerini saklar
  • Feedforward çıktısına da girdiyi yeniden ekleyen residual connection uygulanır
  • Bu attention + feedforward birleşimi bir block'tur ve GPT-2, 12 block'u bir hat gibi art arda bağlar
    • Her block'un kendine ait eğitimli parametre kümesi vardır
    • SQL'de block'lar recursive CTE ile bağlanır
  • Son block çıktısı ln_f parametreleri ile yeniden normalize edilir

Bir sonraki token'a geri dönmek

  • Nihai çıktının son konumundaki 768 boyutlu vektör, bir sonraki token'ın embedding'idir
  • Bu vektörü yeniden token'a çevirmek için, ilk token embedding'inde kullanılan WTE matrisi tekrar kullanılır
  • Tam ters dönüşüm genellikle mümkün değildir
    • Tahmin edilen embedding, WTE içindeki belirli bir satırla tam olarak aynı olmayabilir
    • Bu yüzden her token embedding'i ile dot product hesaplanarak en yakın token bulunur
  • WTE ile tahmin embedding'inin dot product sonucu 50.257 skor, yani logit üretir
  • Bu skorlar softmax ile olasılığa dönüştürülür
    • En üst aday sayısı top_n
    • Olasılık dağılımını ayarlayan değer temperature'dır
    • Temperature yükseldikçe, ilk sıradaki olmayan token'ların seçilme ihtimali artar ve çıkarım daha az öngörülebilir hale gelir
  • "PostgreSQL is great" örneğinde ilk 5 sonraki token adayı şunlardır
    • Ġfor
    • ,
    • .
    • Ġat
    • Ġto
  • Temperature 0.5, 1 ve 2 olarak değiştirildiğinde aynı adayların softmax olasılık dağılımı farklılaşır

Gerçek çıkarım sonucu ve kod

  • Nihai SQL, token'ları olasılığa göre seçip prompt'a ekleme işlemini tekrarlar
  • Modelin kendisi deterministiktir; deterministik olmayan tek unsur token seçimi içindeki rastgeleliktir
  • Örnek ayarlar şöyledir
    • Prompt: "Happy New Year! I wish you"
    • Üretilecek token sayısı: 10
    • Temperature: 2
    • top_n: 1
    • SETSEED(0.20231231) kullanılmış
  • Yazarın ortamında sorgu 2 dakika 44 saniyede çalıştı
  • Çıktı "Happy New Year! I wish you all the best in your new year!" oldu
  • Sorgu ve kurulum kodu GitHub deposu quassnoi/explain-extended-2024 içinde yer alıyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-02-25
Hacker News görüşleri

  • Güzel. Ben de SQLite ile benzer bir tavşan deliğine dalmıştım, ama henüz sinir ağlarını işin içine katacak aşamaya gelmemiştim
    makemore ders serisinden[0] ilham almıştım; yaklaşık 1 saat sonra sayma yaklaşımından sinir ağlarına geçiyor, benim ulaştığım nokta da kabaca orasıydı
    Bunu ilişkisel modele parçalayarak bakmak gerçekten iyi bir alıştırma
    [0] https://www.youtube.com/watch?v=PaCmpygFfXo

    • İzlemeye devam ederseniz sinir ağının sayma yöntemiyle tamamen aynı tabloyu çıkardığını ve üretim sırasında da tamamen aynı sonucu verdiğini görürsünüz

  • İyi bir demo, ancak yazıdaki nedensel maskeleme açıklaması eğitim ile çıkarımı birbirine karıştırmış gibi
    Nedensel maskelemenin amacı, eğitim sırasında gelecekteki token'lara “göz atılmasını” engellemek; GPT türü yapılarda çıkarım sırasında özbağlanımı zorunlu kılma amacı da var
    Çıkarımda zaten yalnızca son token kullanıldığı için, o token tüm girdi dizisine dikkat eder; dolayısıyla bir sonraki token yalnızca son token'ın embedding'iyle belirlenmiş olmaz

  • Bunun GPT'nin sürücü döngüsünü doğru ifade edip etmediğini merak ediyorum: prompt'u tokenize etmek, gpt2(tokens) ile 50257 token olasılığı elde etmek, sonraki token'ı seçmek, token listesine eklemek, durma koşulunu kontrol etmek ve en sonda ters tokenization yapmak gibi görünüyor
    Ama bu, durum makinesinin Shlemiel the painter algoritmasını uygulaması gibi göründüğünden, üretim işinin özündeki hesaplama maliyeti konusunda soru işareti doğuruyor

    • İnsanların büyük dil modellerinde bahsettiği bağlam penceresini, tutulan token sayısının bir üst sınırı olduğu ve en eski token'ların atıldığı anlamında anlıyorum
      Bu pencere kayan bir penceredir
    • Evet, döngü bu; sihrin tamamı gpt2 fonksiyonunun içinde
    • Bu, algoritmanın çok küçük bir parçası
      Daha çok, üretilen token'ların cümle halinde nasıl toplandığını göstermeye benziyor

  • İlgili kaynak: A GPT in 60 Lines of NumPy - https://news.ycombinator.com/item?id=34726115 - Şubat 2023, 146 yorum

    • Bu kaynak yazının başlarında zaten geçiyor

  • Benzer bir bağlamda GPT'yi tamamen elektronik tablo fonksiyonlarıyla uyguladım ve yanında izlenebilecek bir video eğitim de hazırladım
    https://spreadsheets-are-all-you-need.ai/

    • İlk video harika
      LLM'lerin oldukça havalı olduğunu düşünen ama gerçek çalışma biçimlerini mesleki olarak öğrenmesi gerekmemiş biri olarak, 10 dakikalık video bana yıllarca anlaşılması zor HN yorumları ve yüzeysel ana akım medya yazıları okumaktan daha fazlasını öğretti
      Hesaplanmayı bekleyen muazzam sayıda kayan noktalı sayının yığıldığını görünce, bu teknolojinin neden bu kadar çok GPU tükettiğini de çok daha sezgisel biçimde anlıyorsunuz
    • Elektronik tablolar, LLM açıklamak için doğal bir yol
      Her eğitim örneğinde her parametrenin türevini hesaplayıp bunun ilgili parametreye nasıl eşlendiğini açıkça gösterirseniz, eğitim süreci de iyi açıklanabilir gibi

  • Güzel. Bir yıl önce bir tür sihir gibi görünen şey, artık böyle iyi, neredeyse bir çocuğun bile izleyebileceği kadar anlaşılır biçimde açıklanıyor

    • Bu sihir bir yıl önce başlamadı
      Yazıda açıklanan model, 2019 başında yayımlanan GPT-2
    • “Bir çocuğun bile izleyebileceği kadar” değil
      Bu yazıyı doğru anlamak için sağlam bir bilgisayar bilimi arka planı gerekir; başlığın kendisi bile insanlığın %99'u için erişilebilir değil

  • GPT ve LLM'lerden tamamen uzak durmuştum; bu yaklaşım metin çıktısında bir dereceye kadar akıcılık üretebiliyor gibi, ama soruları yorumlayıp cevaplama yeteneğine kadar uzanmıyor gibi görünüyor
    Gerçekte nasıl çalıştığını açıklayan ya da Python gibi oyuncak bir motor gösteren basit bir blog yazısı veya eğitim var mı merak ediyorum
    Şimdiye kadar gördüğüm eğitim materyalleri platformun nasıl kullanılacağına odaklanıyor, iç işleyişi pek ele almıyordu

  • İlginç biçimde modern makine öğrenmesi Turing tamlığı gerektirmiyor
    Buna rağmen AGI olasılığını değerlendiriyoruz; Turing tamlığının gerekli olmadığı sonucuna varılırsa epey ilginç olurdu

    • Turing tamlığı gerekli gibi görünüyor
      Basit bir nedenle: kafamın içinde Turing tam kodun yürütülmesini takip edebiliyorum
    • Token çıkarımının kendisi Turing tam değil, ama çıktı yan etkiler oluşturabiliyorsa; örneğin bir sonraki yinelemenin prompt'unu değiştirebiliyorsa, iş tamamen değişir

  • Yazı harikaydı; her bileşenin açıklaması net ve oldukça kapsamlıydı, okuması keyifliydi
    Ancak yanlışlıkla “+ expand source”a basıp o inanılmaz canavarı gördükten sonra, ChatGPT'nin “SQL büyük dil modeli uygulamak için uygun değildir” demesine hak verir hale geldim

    • Ben de bastım ve tekrar nasıl kapatacağımı bulamadım

  • “Sıradan Unicode sinir ağlarıyla iyi uyuşmaz” sözü doğru değil. Örneğin ByT5'e bakın
    Yazıda “alfabe” denilen şeye genelde sözlük denir; UTF-8 baytlarını sözlük olarak kullanırsanız token sayısı 149186 değil, 256 olur
    ByT5 de tam olarak bunu yapar

    • Mesele bunun hiç işe yaramaması değil; sahip olduğumuz diğer yaklaşımlar kadar iyi çalışmaması
      Piyasadaki en iyi performans gösteren modellerin hepsinin tokenization kullanması bunun kanıtı
      Tokenization'ın temelde bir hack'e yakın olduğu ve idealde bir gün bir şekilde ortadan kaldırılmak istendiği sır değil (https://twitter.com/karpathy/status/1657949234535211009)
      İlke olarak bayt düzeyi tokenization'ın kusurları daha büyük modeller ve daha büyük bağlamla telafi edilebilir; ama pratikte aynı zeka düzeyine sahip bir modeli eğitmek çok daha fazla kaynak gerektirir
      Elbette bir kelimedeki harf sayısını saymak gibi tokenization'ın zekaya aksine zarar verdiği belirli görevler de var