Üretken Yapay Zeka: Büyük Dil Modelleri ve Difüzyon

Bu sunumu bir arkadaşım için, ona ilham vermek niyetiyle hazırladım. Amacım, Üretken Yapay Zekanın temelini — Transformers mekanizmasından dosya formatlarına kadar — anlaşılır kılmak ve ardından uygulamalı egzersizler ile pratiğe geçmekti. Sunum teknik kaçarsa lütfen sadece anlamaya çalışın: önemli olmayan bilgi yok ve tek bir prensibi anlamanız dahi gelecekte işinizi kolaylaştıracaktır. Anlamadıysanız da önceki bölümlere geri dönüp anlayabilirsiniz.

Not: Bu yazı, sunum PDF'inden makale formuna bir yapay zeka asistanı olan Claude tarafından dönüştürülmüştür.

Üretken Yapay Zeka için gerçek bir ön gereksinim yoktur. Yazılım konusunda mühendislik bilgisi ve prensipleri yararlı olur, ama "yazılım sayısal ve matematik becerisi ve bilgisi gerektirir" öngörüsü tehlikeli ve yanlıştır. Bilgisayar, adı üzerinde olduğu gibi, bilgi ve sayıları bizim için sayar ve hesaplar.

Yeni bir model mimarisi geliştirilmediği sürece matematik bilgisine gerek yoktur — geliştirildiğinde de çoğu zaman ihtiyaç yoktur, çünkü yazılım da sanat gibi birbirinden alma ve üzerine inşa etme & geliştirme üzerine kuruludur. Herkes Üretken Yapay Zeka kullanabilir, üzerinde oynama yapabilir ve geliştirebilir. Gereken tek şey sabır ve zamandır.

Ekosisteme aşinalık da işe yarar. Şu isimlerden ne kadar çoğu tanıdık geliyorsa o kadar iyi: OpenAI, Claude, Gemini, LLaMA, Qwen (通義千問), DeepSeek, Mistral, MiniMax, Command R+, Gemma, Grok, EleutherAI, Kumru; araç tarafında llama.cpp, LM Studio, HuggingFace; görsel tarafta Stability AI, FLUX.1, Midjourney, character.ai, Perplexity, Copilot.

Üretken Yapay Zekanın temeli, 2017 yılında "Attention is All You Need" adlı makalede tanıtılan Transformetör (Transformers) mimarisidir. ChatGPT, Gemini, Claude, Qwen, DeepSeek, LLaMA, Mistral, MiniMax, Command R+ ve onlarca diğer model, aralarında ufak mimari farklılıklara sahip olsa bile temelinde bu mimariye — özellikle decoder-only transformers mimarisine — dayanır.

Aslında bütün olay, verilen girdinin çeşitli matematiksel işlemlerden geçirilmesi ve ihtimallere (temperature, top_p, top_k vb.) bakılıp girdi değerlerine göre sıradaki çıktının tahmin edilmesidir. Çoğu model bunu chat şemaları ve reasoning blokları ile kullanıcı dostu yapar.

Bu sunumda JEPA (LeCun) gibi daha farklı çalışan yapay zekalara değinilmemiştir.

Embedding: Token'lar sayı olarak işlenir. Kelime embedding'i, pozisyonel embedding (sinüs ve kosinüs değerleri) ile toplanır ve nihai embedding elde edilir. "LLaMA 2 is better than LLaMA 1" ile "LLaMA 1 is better than LLaMA 2" cümlelerinin farkı, tam olarak aynı kelimelerin farklı pozisyon değerleri almasından ortaya çıkar.

Parametre: Masanın üzerinde bir su olduğunu düşünelim. "Pembe etiketli 500g Evian markalı su" yüksek parametre iken "500g su" daha düşük parametrelidir. Yani parametre sayısı arttıkça genellikle kalite artar ve nicelendirme etkisi genellikle azalır. Ama genel konuşamayız — mimari kötü olduğu sürece parametre sayısı etki etmez. Buna "Fallacy of Scaling Up" denir ve "Scaling Up" kavramı özellikle büyük dil modelleri sahnesinde eleştirilir.

Büyük Dil Modellerinde genelleme yapılacak olur ise iki tür önemli Transformers mimarisi bulunur.

Mixture of Experts (MoE): En önemli akademik kağıdı "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer" (https://arxiv.org/abs/1701.06538). Bütün model belleğe yüklenir, ama belli bir anda sadece belirli uzmanlar aktif olur; bundan dolayı kaynak kullanımı daha azdır. Örneğin 2025'in başlarında DeepSeek V3, 671B parametreye sahip olup bunlardan 37B kısmını aktif olarak kullanıyordu. Bellek gereksinimi, kaynak kullanımına rağmen değişmez; ama llama.cpp ile daha iyi optimize edildiği için dense modellere göre çok daha etkin çalışır. Bundan dolayı genellikle oldukça büyük modellerdir (120B GPT-OSS'ten 700B Kimi K2'ye). Açık ağırlık sahnesinde Mixtral 8x7B ile tanınmaya başlandı.

Dense: En önemli akademik kağıdı "Attention is All You Need" (https://arxiv.org/abs/1706.03762). Bütün model belleğe yüklenir ve bütün parametreler aynı anda etkin halde bulunur. Gelenekseldir ve eğitimi daha kolay ve tahmin edilebilir şekildedir. Açık ağırlık sahnesinde genel toplum tarafından LLaMA'nın sızdırılması ile tanınmaya başlansa da GPT-2 tanınırlık konusunda en önemli ilk gelişmedir.

Önemli bir not: Akıl yürütme modellerinin (büyük dil modelleri konusunda) normal modellerin mimarisinden özel bir farkı yoktur.

Transformers'ın kalbindeki işlem Q, K, V değerleri etrafında döner: Query, Key, Value.

- Query (Sorgu) = "Ben ne arıyorum?"
- Key (Anahtar) = Signifier (Gösteren): Bu, verinin "etiketi" veya "biçimi"dir. Tıpkı "A-Ğ-A-Ç" ses dizisinin bir kavramı işaret etmesi veya "AĞAÇ" kelimesinin yazılı olarak kavramı işaret etmesi, "木" karakterinin bir kavramı işaret etmesi gibi, Key de verinin hangi bağlamda aranabileceğini belirten vektörel formudur.

- Value (Değer) = Signified (Gösterilen): Bu, o etiketin taşıdığı asıl "anlam" veya "içerik"tir. Sorgu (Query) ile Anahtar (Key) eşleştiğinde, sistem asıl bilgiyi yani Value'yu döndürür.

Klasik örnek: "The animal didn't cross the street because it was too tired" cümlesinde "it" kelimesi, dikkat mekanizması sayesinde "street"e değil "animal"a bağlanır.

Eğitim (Pre-Training) maliyetli ve özel donanım (NVIDIA CUDA) gerektirir. Son zamanlarda ROCm (AMD) ve MLX (Apple) gibi alternatif teknolojiler de çıkmaya başlamıştır. Bir Transformatör'ün ağırlıklarının — tensor içindeki, dikkat mekanizmasındaki önemi temsil eden numaraların; embedding değeri ile ağırlıkların çarpımı Büyük Dil Modellerinin çalışmasında önemlidir — eğitilmesi maliyetlidir ve çok veri ister (birkaç yüz GB'dan TB'a kadar çıkabilir).

İnce Ayar (Fine-Tuning) ise genellikle, yüksek parametreli modeller dahil, normal kullanıcı ekran kartlarında çeşitli kütüphaneler ile (Unsloth gibi) optimize bir şekilde yapılabilir. Eğitilmesi daha az maliyetlidir ve daha az veri ister; ama iyi sonuçlar için bu veri düzenli bir formatta olmalıdır.

Örnek olarak sunumda, Kanbun-Kundoku odaklı bir ince ayar için hazırlanmış, HuggingFace Chat Formatında bir veri örneğinden kesit gösterdim: her satırda bir system-user-assistant üçlüsü ve assistant cevabının başında <think>...</think> bloğu. Bu Reasoning Model formatıdır — model önce düşünür, sonra cevabı düşüncesine göre verir. Reasoning bazen performansı düşürebilir; bazen ve hatta normal kullanımda çoğu pratik kullanımda performansı arttırır.

Tensor, sayıları tutan bir veri kabı olarak düşünülebilir. Bu kap farklı boyutlarda olabilir: Skaler 0 boyutlu, vektör 1 boyutlu, matris 2 boyutlu tensör oluşturur. 3 boyutlu tensör kavramını anlamak için bir fotoğraf düşünebiliriz: siyah-beyaz bir fotoğraf 2D bir tensör iken, renkli bir resim kırmızı, yeşil ve mavi (RGB) pikselleri temsil eden 2D tensör serisinden oluştuğu için 3D bir tensör oluşturur.

SafeTensor (Güvenli Tensor), içinde bir modelin ağırlıklarını tensor biçiminde bulunduran dosya formatıdır ve Üretken Yapay Zeka için standart dosya formatıdır. Sadece tensor'lar bulundurulur; içinde çalıştırılabilen bir kod bulunmaz. Standart .pkl, .pt ve .bin dosyalarına nazaran SafeTensor modelleri güvenlidir: Pickle (.pkl) gibi dosya formatlarına "bu veriyi nasıl birleştirebilirim" adı altında küçük kod parçacıkları gömülebilir; kötü niyetli biri bu yöntemi kullanarak zararlı kod saklayabilir ve dosya yüklendiğinde bu kod kullanıcıdan habersiz otomatik bir biçimde çalışır. Bu yüzden SafeTensor dosyaları popülerleşmiş ve standart hale gelmiştir.

Oldukça basit bir mimarisi vardır: dosyanın ilk 8 baytlık kısmı bize içindekiler (header) bölümünün uzunluğunu verir. JSON (içindekiler) kısmı ise her tensör için bir tanım kartı bulundurur: dtype (veri tipi; F16, yani 16-bit ondalıklı sayı, örnek verilebilir), shape (tensörün şekli) ve offsets: [BEGIN, END] (tensörün başlangıç ve sonlanma noktası). Geri kalan kısım asıl verileri ve ağırlıkları bulundurur.

GGUF dosya formatı, SafeTensor formatını kullanan yapay zeka modellerini erişilebilir kılar. GGUF, harici bir kütüphane (bitsandbytes gibi) olmadan yapay zeka modellerini herhangi bir donanımda (NVIDIA, AMD, Apple Silicon) istediğimiz nicelendirmede çalıştırmamızı sağlar.

GGUF, 2026 yılına kadar HuggingFace'den bağımsız yürütülen bir proje iken 2026 yılında HuggingFace platformuna katıldı (https://huggingface.co/blog/ggml-joins-hf adlı adresten daha fazla bilgi edinilebilir). Genellikle Büyük Dil Modelleri ile kullanılırlar, ama Difüzyon modellerinde de kullanımı görülmeye başlanmıştır (ComfyUI-GGUF).

Nicelendirme, ağırlık dosyalarının optimize ediliş sürecidir. Nicelendirme konusunda toplum tarafından çeşitlilik ve kolaylık açısından (işlenmiş dosya çeşitliliği, donanım kolaylığı ve uyumluluğu) GGUF şiddetle önerilir ve standart haline gelmiştir.

Tercihen GGUF direkt indirilmemeli; donanım müsaade ediyorsa SafeTensor dosyası llama.cpp ile GGUF'a dönüştürülmeli ve ardından nicelendirme yapılmalıdır. Ama GGUF indiren biri genellikle bu donanıma zaten sahip değildir. SafeTensor dosyalarında nicelendirme BitsAndBytes gibi kütüphaneler ile yapılır ve 8BIT, 4BIT değerleri kullanılabilir; BitsAndBytes macOS gibi ortamlarda çalışmaz.

GGUF dosyalarında nicelendirme FP16'dan TQ1_0'a kadar değişir. TQ1_0 (Ternary Quantization) dosyasında sadece -1, 0, 1 değerleri bulunur (Bits Per Weight bunun dolayısı ile genellikle 1.58'dir). Nicelendirme ciddileştikçe model performansı düşer.

Ufak bir not: isimlendirme ile ağırlık nicelendirmeleri genellikle uyuşur, ama Unsloth gibi nicelendirmeyi yapan kişiler bazen bir türde çeşitli ağırlıklar kullanabilirler. Bir Qwen3.5-397B-A17B-UD-TQ1_0.gguf dosyasının yükleme kaydında f32 ve q8_0'dan iq2_xxs ve mxfp4'e kadar farklı türlerde tensörlerin bir arada bulunduğu görülebilir. Bu değerleri karıştırmak, ciddi nicelendirmede daha iyi bir performans almamızı sağlayabilir. Bu yüzden model seçerken aslında BPW (Bits Per Weight) değerine bakmamız gerekir: 3-4 değerinin altında ciddi performans kayıpları başlar iken, 4 ve üstünde performans kaybı görmezden gelinebilir.

LoRA (4 bit olduğunda QLoRA), belli bir yapay zeka modelini kısmen ince ayar yapma sürecidir. Tam ince ayar yapmaktan daha pratik ve ucuzdur ve en çok kullanılan ince ayar yöntemidir.

LoRA dosyalarını ayrı ayrı indirip istediğimiz zaman yükleyerek modelimizi kişiselleştirebiliriz — yani bütün modelin değiştirilmiş halini indirmemize gerek yoktur. Her modelin LoRA dosyası farklı olur: Qwen3.5'te çalışan bir LoRA, Mistral Large 3'te çalışmaz.

LoRA, Büyük Dil Modelleri ve Difüzyon modellerinin kişiselleştirilmesinde büyük rol oynar. Difüzyon modellerinde RAG (Retrieval Augmented Generation) neredeyse yok gibi olduğu için daha da önemlidir.

Bu egzersiz yerel donanımda yapay zeka kullanımına odaklanır.

Önce donanıma uygun llama.cpp indirilmelidir: Windows için https://github.com/ggml-org/llama.cpp/releases adresinden temin edilebilir; macOS ve Linux'ta brew (brew install llama.cpp) kullanılarak indirilmesi daha sağlıklıdır. En sağlıklısı kodu sıfırdan derlemektir ama gereksizdir. llama.cpp bir komut sistemi uygulaması olduğu için kurulum gerektirmez. Alternatif olarak LM Studio ve Ollama gibi arayüzler de vardır.

Uygun dil modeli seçmek için VRAM (ekran kartı RAM) ve RAM (bellek) miktarımızı bilmemiz gerekir; Görev Yöneticisi veya Activity Monitor gibi programlarda yazar. Günümüzde çoğu bilgisayarda 8GB VRAM ve 16GB RAM bulunur. Güvende olmak için sunumda https://huggingface.co/unsloth/Qwen3-VL-4B-Instruct-GGUF modelini baz aldık; nicelendirme bölümünde bahsedildiği üzere Q4_K_M üstü herhangi bir nicelendirme değeri güvenle seçilebilir. Qwen3-VL bir multimodal büyük dil modelidir, yani görsel desteği vardır — o yüzden egzersiz için iyi bir seçenektir. Model GGUF dosyası ile beraber MMPROJ dosyası (mmproj-F16.gguf) indirmemiz gerekir.

Model dosyalarını ve llama.cpp'yi indirdikten sonra çalıştırmak için iki seçeneğimiz bulunur. llama-cli komut sistemi ile etkileşime geçmemizi sağlarken, llama-server web arayüzü ve API bağlantılarına izin verir:

- llama-cli -m qwen3-8b.Q8_0.gguf --system-prompt "You are an expert translator specializing in converting texts into Classical Japanese Kanbun-Kundoku style" -p "通義千問 çok güzel bir modeldir" --temp 0.7 --top-p 0.8 --top-k 20
- llama-server -c 32768 -m Qwen3.5-27B.Q6_K.gguf --mmproj Qwen3.5-27B.mmproj-f16.gguf --chat-template-kwargs '{"enable_thinking": false}' --host 0.0.0.0

Argümanlar üzerine notlar: --temp, --top-p ve --top-k hiperparametreleri temsil eder; bu değerler softmax işlemi sonucu çıkan ihtimallerin filtrelenmesinde kullanılır. --chat-template-kwargs konuşma şablonunu direkt etkiler ve akıl yürütme modellerinde akıl yürütmeyi kapatmak için kullanılabilir. -c bağlam miktarını belirtir (egzersiz için 4096 olarak tuttuk). -m model dosyasının konumunu, --mmproj mmproj dosyasının konumunu belirtir. MoE (Mixture of Experts) modeli kullanıyor olsaydık ve ekran kartı-CPU dağılımı yapmak istiyor olsaydık --n-cpu-moe ile --ngl 99 veya --fit on değerlerini kullanabilirdik (--ngl ekran kartına yükleyeceğimiz ağırlık katmanlarını belirtir; 99 genellikle "bütünü" anlamında kullanılır, çünkü 99 değerini geçen bir açık ağırlık modeli şu an da yok). Çoklu harfli argümanlarda (--mmproj gibi) çift tireye dikkat edelim.

Görsel yapay zeka eğitimi, yazılı yapay zeka eğitiminden daha kolaydır. Günümüzdeki teknolojik gelişmeler sayesinde 20 resim ile dahi difüzyon modelleri etkili bir şekilde eğitilebilmektedir.

Görsel yapay zeka eğitimi yapmadan önce hedefimizi belirlemeliyiz: Stil mi eğitmek istiyoruz? Karakter mi eğitmek istiyoruz? Hedefi belirttikten sonra eğitmek istediğimiz konuyu en iyi anlatan görselleri derlememiz gerekir — bu egzersiz için 20 tane görsel yeterlidir. Bu görseller tercihen şu önem sırasına göre gitmelidir: 1. Aynı çözünürlük, aynı aspect ratio; 2. Aynı aspect ratio. Modern modeller (Qwen Image gibi) ve eğitim kütüphaneleri (ostris/ai-toolkit gibi) farklı çözünürlüklerde ve farklı aspect ratio'da bulunan görselleri de destekler.

Normal bir model için görsellerimizi anlatan bir prompt (caption) yazmamız gerekir ve prompt'umuzda öğretmek istediğimiz konsept sabit kalmalıdır (burada "skeskin person"). Edit modellerinde ise control (elimizde olan görsel) ve dataset/target (elde etmek istediğimiz görsel) bulunur — yani edit modellerinde örnekler verilerek öğretilir ve prompt genellikle sabit kalır: bütün resimlere "Turn this photograph into a still from an animated film, similar to that of 君の名は。Anime." gibi tek bir caption yazılır.

Uygulamada önemli notlar: 18 yaş altının, RunPod veya Google Colab gibi servisler kullanılacak ise bu egzersizi ebeveyn kontrolü altında yapması gerekir. İmkân varsa bu eğitim yerel yapılmalıdır — şahsen benim imkânım yok (AMD ekran kartı + MLX). Sunumda Qwen-Image-2512 ve Qwen-Image-Edit baz alındı; eğitimde 40GB VRAM harcayan bu modeli kimsenin yerel çalıştırmasını beklemediğim için RunPod üzerinden örneklendirildi. Bulut ekran kartı hizmetleri genellikle (RunPod gibi) "pay-as-you-go" sisteminde çalışır; Google Colab ise tek bir ücret alıp size aylık "credits" verir.

Eğitim akışı: RunPod'da ekran kartı kiraladık (RTX 6000 PRO), ostris/ai-toolkit üzerinde hazırladığımız dataset'i yükledik ve caption'ları yerleştirdik. Qwen Image Edit modelini seçtik; learning rate'i bu deneme için 0.00002 olarak (varsayılan 0.00001) ayarladık. Target olarak dataset'i, control olarak control'ü seçtik. Üç tane sample resmi yükledik ki eğittikçe gelişimi takip edebilelim — 3000 iterasyon sürecinde resimler zaman içinde gelişecek ve prompt'u daha yakın takip edecek. 3000 iterasyonluk eğitim bu ekran kartında yaklaşık 3-5 saat sürecek.

Bu egzersizin amacı, komut sistemi veya bir arayüz ile llama-server'a bağlanmak ve herhangi bir formatta çıktı almaktır.

Yazılım bilmiyorsanız, yapay zeka ile bu kısmı kolayca halletmekle kalmayıp RAG (Retrieval Augmented Generation) konseptini de arada öğrenmiş olursunuz; çünkü llama-server çok hızlı gelişmekte olduğundan büyük bir ihtimal eğitim veritabanlarında eski dokümanlar mevcut olacaktır. RAG, verilen bir sorgunun embedding'lerinin hesaplanması ve bunun bir dokümanın embedding'leri ile karşılaştırılıp en alakalı kısımları alma sürecine verilen isimdir. Lütfen egzersiz öncesi Miniconda ve/veya bir vibe-coding aracını bilgisayarınıza kurun (dikkatli olun: Anaconda değil, Miniconda — Miniconda, Python dependency hell, versiyon uyumsuzluğu ve dependency chasing sorunlarını önler). Yazılım biliyorsanız bile bu egzersiz faydalı olacaktır.

Vibe Coding üzerine önemli prensipler: Vibe Coding, Büyük Dil Modeli asistanlığıyla kullanıcının yürüttüğü kodlama sürecine verilen isimdir. Vibe Coding "bilgisayara emret o yazsın, ben keyfime bakayım" değildir. Vibe Coding'de kullanılan yazılım ve yazılım dili hakkında en azından teorik bilgi gerekir; kişinin yazılmış olan kodu anlaması ve debug (hataları çözümleyebilmesi) gerekir. Kişi eğer teorik ve tercihen pratik bilgiye sahip ise, işi hızlandırmak ve prototiplendirmek için vibe coding yapıyor ise kısa sürede etkili sonuca ulaşabilir. Kendi gözlemimden: çoğu yazılımcı günümüzde artık geleneksel yöntemlerle yazılım yazmıyor; bazı yazılımcılar tehlikeli biçimde ne yazdığını bilmeden, bakmadan, incelemeden vibe-coding yapıyor. Vibe-Coding'de ne yaptığını bilmemek tehlikelidir.

KV Cache: adı üstünde olduğu üzere mesaj tarihçesinin bellekte yüklü bulunması durumudur. Bu durumun sağlanması için mesaj tarihçesinin olması (System, User, Assistant, User, Assistant...) ve döngünün doğru olması (kullanıcı önce, asistan sonra) gerekmektedir. Mesaj tarihçesindeki öğelerin gönderildikten ve işlendikten sonra tekrar işlenmemesi gerekmektedir; yoksa KV Cache geçersiz olur. Ciddiyet, mesajın bulunduğu yere göre değişir.

Metadata: kullanıcı gönderisinde zaman, RAG sonuçları, araç çağrı sonuçları gibi çeşitli metadata'lar bulunabilir. Bütün metadata XML tag'leri ile kaplı olmalıdır: <time>...</time>, <tool_call_results>...</tool_call_results> veya birleşik bir <metadata> bloğu gibi. Araç çağrıları konusunda "tools" parametresi (OpenAI API) deneyimlerime göre asla kullanılmamalıdır (deneyimlerim hep kötü ve bazı modeller desteklemiyor). Onun yerine prompt edilmeli; model bu promptu takip ederek tool call'ı yine XML veya JSON içinde kendisi yazmalıdır. Bu sebepten dolayı jinja argümanı llama.cpp ile kullanılmamalı veya kaçınılmalıdır. Bu aynı zamanda streaming ve tool call'ların aynı anda kullanılmasını da sağlayacaktır. Bu çıktı, bir parser yazılarak parse edilmeli ve koşullar yerine getiriliyorsa araç çağrısı yapılmalıdır. Araçlar Model Context Protokolüne uygun olmalı; sunucular buna göre otomatik keşfedilip bağlanılmalı ve bu sunucular modelin en başta sistem mesajında, araç çağrı kullanım talimatları ile birlikte verilmelidir.

API'yi aktif etmek: llama-server --models-dir models --fit on -c 131072 -n -1 --host 0.0.0.0 gibi bir komut ana modelleri; llama-server --models-dir embeddings --embedding --pooling rank --host 0.0.0.0 --port 8081 ise embedding/reranker modellerini sunar. --models-dir, llama-server'a yeni eklenmiş bir komut olduğundan dolayı vibe-coding asistanları tanımakta zorluk çekebilir; bunu lütfen dokümanı (https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md) asistana besleyerek belirtin. --models-dir ile vision modellerini yüklemek için model kendi klasörü altında olmalıdır. Bir model belirtmez iseniz -m ile istediğiniz modeli yükleyebilirsiniz.

Uygulama örneğinde Flask ile bir /chat endpoint'i yazdık: kullanıcı mesajı alınıyor, RAG araması yapılıp sonuçlar <relevant_documents> tag'i içinde, zaman <time> tag'i içinde metadata olarak ekleniyor; istek llama-server'a stream edilerek gönderiliyor; çıktıdaki tool call'lar parse edilip sonuçları <tool_call_results> içinde tekrar modele veriliyor.

Sunumun sonunda dinleyicilere beş görev bıraktım:

1. Yerel bir büyük dil modelinde (örneğin LM Studio veya llama-cli üzerinden) aynı girdiyi üç farklı sıcaklık ayarında çalıştır, ne fark ettin? Farklı parametreler ile oyna, denemeler yap!
2. Herhangi bir Büyük Dil Modeli kullanarak 20 tane, HuggingFace JSON Chat Formatında bir konuda ince ayar veritabanı hazırla. Daha sonra bu veritabanının gerçekten RAG ile de çalışıp çalışmayacağını gözden geçir ve dene.
3. Egzersiz 1'de LoRA eğitmiştik. ComfyUI (yerel) / Draw Things (iOS, macOS, yerel) / Fal.AI (bulut) kullanarak API bağlantısı ile o LoRA ile bir resim üretebilir misin?
4. Prompt Mühendisliği: Herhangi bir yerel modele, sadece sistem mesajını değiştirerek ve gerekli içerik & dokümanları sağlayarak doğru bir Kakari Musubi cümlesi yazdırabilir misin?
5. Nicelendirme ile deneyim: Aynı modelin çok düşük bir varyantı ile (TQ1_0 gibi) yüksek bir varyantını (Q8_0 gibi) indir. Ne farklar gözlemledin? Daha sonra daha üst bir modelin daha aşağı bir niceleme ile daha aşağı modelin daha yüksek bir niceleme varyantını indir (mesela 4B'de Q8_0, 8B'de ise Q6_K gibi, veya 14B Q4_K_M), ne gözlemledin?