Tahmin, arama değil
Model bir veritabanından cevap "çekmez"; her token'ı öğrendiği örüntülere göre üretir. Bu yüzden aynı soruya farklı ama makul yanıtlar verebilir.
Büyük dil modelleri (LLM), göründükleri kadar gizemli değildir: özünde, bir metnin devamında en olası sonraki parçayı tahmin eden istatistiksel sistemlerdir. Bu basit çekirdek, yeterince büyük veriyle ölçeklendiğinde metin yazma, kod üretme ve soru yanıtlama gibi yeteneklere dönüşür. Bu sayfada bir LLM'in nasıl çalıştığını temelden ele alıyoruz: metni nasıl token'lara böldüğünü ve anlamı embedding'lerle nasıl temsil ettiğini, ne kadar bağlamı bir arada tutabildiğini (context window), yanıtın çeşitliliğini belirleyen temperature'ı, neden bazen kendinden emin biçimde yanlış ürettiğini (hallucination), bir modeli kendi verinize uyarlamanın yolları olan fine-tuning ile RAG arasındaki farkı ve son olarak çıktıyı değerlendirme ile maliyet tarafını. Terimlerin İngilizce karşılıklarını olduğu gibi kullanıyoruz; çünkü sahada bu adlarla karşılaşacaksınız.
Bir LLM, devasa metin verisi üzerinde tek bir görevle eğitilir: verilen bir metin dizisinin ardından gelecek en olası sonraki token'ı tahmin etmek. Model her adımda tüm kelime dağarcığı üzerinde bir olasılık dağılımı üretir, bir token seçer, onu girdiye ekler ve tahmini yineler. "Zeki" görünen davranış, bu tahminin milyarlarca parameter üzerinden, cümlenin bağlamına duyarlı biçimde yapılmasından doğar. Modelin altında yatan mimari transformer'dır; onu güçlü kılan da attention mekanizmasıdır: model, sonraki token'ı seçerken girdideki hangi kelimelerin birbiriyle ilişkili olduğunu tartabilir. Önemli olan şu: model gerçeği "bilmez", olasılığı modeller — bu ayrım, ilerideki hallucination bölümünün de anahtarıdır.
# girdi
"Bugün hava çok"
# model sonraki token için olasılık üretir
güzel 0.62
sıcak 0.21
soğuk 0.09
yağmurlu 0.05 # … dağarcığın tamamı
# bir token seçilir, girdiye eklenir, tahmin yinelenir
Model bir veritabanından cevap "çekmez"; her token'ı öğrendiği örüntülere göre üretir. Bu yüzden aynı soruya farklı ama makul yanıtlar verebilir.
Eğitim sırasında ayarlanan milyarlarca sayısal ağırlık, dilin örüntülerini kodlar. Model "bilgisini" bu ağırlıklarda taşır; ayrı bir kayıt tutmaz.
Eğitim bir kez yapılır; kullandığınız her istek bir inference'tır. Maliyet ve gecikme de büyük ölçüde bu anda, işlenen token sayısıyla belirlenir.
Model harflerle ya da kelimelerle değil, token'larla çalışır. Tokenization, metni modelin işleyebileceği alt-kelime parçalarına böler: "kitaplarım" tek bir kelime olsa da birden çok token'a ayrılabilir. Kaba bir kural olarak İngilizcede bir token ortalama dört karaktere denk gelir; Türkçe gibi eklemeli dillerde kelime başına token sayısı daha yüksektir. Her token daha sonra bir embedding'e, yani anlamı temsil eden yüksek boyutlu bir sayı vektörüne çevrilir. Bu vektör uzayında anlamca yakın şeyler birbirine yakın konumlanır — "kral" ile "kraliçe" arasındaki ilişki, "kadın" ile "erkek" arasındakine benzer bir yönde durur. Embedding'ler yalnızca LLM'in içinde değil; arama, öneri ve RAG gibi sistemlerin de temelidir.
# metin token'lara bölünür
"unutulmaz" → un · utul · maz
# her token bir embedding vektörüne çevrilir
utul → [ 0.14, -0.92, 0.37, … ] # n boyut
# anlamca yakın token'lar uzayda yakın durur
kral − erkek + kadın ≈ kraliçe
Bir token bir kelimenin parçası, tamamı ya da bir noktalama olabilir. Faturalandırma ve context sınırı hep token cinsindendir — kelime değil.
Metni sayıya çeviren bu vektörler, iki metnin ne kadar "benzer" olduğunu ölçmeyi (cosine similarity) mümkün kılar; semantik aramanın temelidir.
Türkçe bir metin, aynı anlamdaki İngilizce metne göre daha fazla token'a bölünebilir; bu da context tüketimini ve maliyeti doğrudan etkiler.
Model kalıcı bir hafızaya sahip değildir; her istekte ona verdiğiniz metin, yani context, o anki tüm "bildiği"dir. Context window, modelin bir seferde işleyebileceği toplam token sınırıdır (girdi + üretilen çıktı). Bu pencereye sığdırdığınız talimat, örnekler ve veriye prompt denir. Üretimin ne kadar "yaratıcı" ya da "tutarlı" olacağını ise örnekleme ayarları belirler: düşük temperature en olası token'lara yaslanıp kararlı ve tekrarlanabilir çıktı verir, yüksek temperature çeşitliliği artırır ama sapma riskini de büyütür. top-p (nucleus sampling) benzer bir amaca farklı bir yoldan hizmet eder.
# prompt, context window'a sığmak zorunda
system "Sen bir destek asistanısın…" # rol/talimat
user "Faturamı nasıl indiririm?" # soru
context [ilgili doküman parçaları] # RAG ile eklenir
# örnekleme ayarları çıktının karakterini belirler
temperature = 0.1 → kararlı, tekrarlanabilir
temperature = 0.9 → çeşitli, yaratıcı ama sapma riski ↑
system davranışı, user isteği taşır. İyi bir prompt, çıktının kalitesini en ucuz biçimde artıran kaldıraçtır.Hallucination, modelin gerçekte doğru olmayan bir bilgiyi akıcı ve emin bir dille üretmesidir. Bu bir "arıza" değil, çalışma mantığının doğrudan sonucudur: model doğruluğu değil, olasılığı optimize eder. Elinde gerçek bir kaynak olmadığında da en olası görünen devamı üretir — bu devam bazen uydurma bir kaynak, var olmayan bir API ya da yanlış bir tarih olur. Model "bilmediğini bilmez"; çünkü içinde bir doğruluk denetleyicisi yoktur. Bu yüzden LLM çıktısı, özellikle olgusal iddialar ve kod söz konusuysa, doğrulanması gereken bir taslak gibi ele alınmalıdır. Riski azaltmanın en etkili yolu, modele güvenilir bağlamı context içinde vermek ve çıktıyı kaynağa dayamaktır.
Model en olası devamı üretir; kaynağı yoksa boşluğu makul görünen bir uydurmayla doldurur. Akıcılık, doğruluğun garantisi değildir.
İsim, tarih, alıntı, kütüphane adı ve API imzası gibi doğrulanabilir ayrıntılarda risk yüksektir. Bu çıktılar üretimde her zaman denetlenmeli.
Güvenilir kaynağı context'e koymak (RAG), yanıtı alıntıya bağlamak ve kritik adımlarda insan onayı, hallucination'ın zararını belirgin biçimde düşürür.
Genel bir modeli kendi alanınıza uydurmanın üç kademesi vardır ve çoğu zaman en ucuzu yeter. En hafifi prompt engineering: talimatı ve birkaç örneği (few-shot) doğrudan context'e koymak. Bir üst kademe RAG (retrieval-augmented generation): sorguyla ilgili belgeleri bir arama katmanından çekip prompt'a ekleyerek modele "kendi verinizi" okutmak — güncel ve denetlenebilir bilgi için idealdir. En ağırı fine-tuning: modelin ağırlıklarını kendi örneklerinizle yeniden eğitmek; davranış ve üslubu kalıcı olarak şekillendirir ama veri, maliyet ve bakım yükü getirir. Pratik kural: önce prompt'u zorlayın, bilgi güncelliği sorunuysa RAG'e geçin, fine-tuning'i yalnızca ilk ikisi yetmediğinde düşünün.
Talimat + örnekleri context'e koyarsınız. Kod yok, eğitim yok; en hızlı ve en ucuz kaldıraç. Çoğu ihtiyaç burada çözülür.
İlgili belgeleri arayıp prompt'a ekler. Bilgi modelde değil, denetlediğiniz kaynaktadır; güncelleme yeniden eğitim gerektirmez. Kaynak gösterimini de mümkün kılar.
Modeli kendi örneklerinizle yeniden eğitir; üslup ve davranışı kalıcı kılar. Güçlüdür ama veri hazırlığı, maliyet ve versiyon bakımı ister.
RAG bir bilgi sorununu, fine-tuning bir davranış sorununu çözer. "Model güncel/doğru bilgiye ulaşsın" istiyorsanız RAG; "model belirli bir biçim ya da üslupla tutarlı yanıt versin" istiyorsanız fine-tuning düşünün. İkisi birlikte de kullanılabilir. Bağlamı dış sistemlerden çekerken API tasarımı ve veri katmanı kararları da işin bir parçasıdır.
LLM çıktısı olasılıksal olduğu için "çalışıyor mu?" sorusu tek bir denemeyle yanıtlanamaz; sistematik evaluation gerekir. Pratikte bu, temsili bir test kümesi üzerinde çıktıları ölçmek (insan değerlendirmesi, kural tabanlı kontroller ya da bir modeli hakem olarak kullanan LLM-as-judge) ve bir prompt ya da model değişikliğinin sonucu iyileştirip iyileştirmediğini görmek demektir. Maliyet ve gecikme tarafı ise büyük ölçüde token ekonomisidir: hem gönderdiğiniz (input) hem ürettiğiniz (output) token'lar için ödersiniz, gecikme de üretilen token sayısıyla artar. Uzun context güçlüdür ama pahalıdır; gereksiz bağlamı budamak, hem faturayı hem yanıt süresini doğrudan düşürür.
# her istek için ödenen: input + output token
input = system + prompt + context # siz doldurursunuz
output = modelin ürettiği token'lar # gecikmeyi belirler
# kaldıraçlar
↓ context'i buda gereksiz belgeyi prompt'a koyma
↓ çıktıyı sınırla kısa yanıt iste, format zorla
↑ cache kullan tekrar eden bağlamı yeniden gönderme
Bir test kümesi kurun ve değişiklikleri ona göre kıyaslayın. "Bana daha iyi geldi" bir metrik değildir; regresyonu ancak ölçerek yakalarsınız.
Uzun prompt'lar hem maliyeti hem yanıt süresini büyütür. Bağlamı ihtiyaç kadar tutmak en pratik optimizasyondur.
Her görev en güçlü modeli gerektirmez; basit işleri daha küçük/ucuz modele vermek kalite kaybı olmadan maliyeti düşürür.
Fine-tuning modelin ağırlıklarını değiştirir; üslup ve davranışı kalıcı kılar ama bilgi güncellemek için yeniden eğitim ister. RAG ağırlıklara dokunmaz; bilgiyi çalışma anında context'e enjekte eder, güncellemesi kolaydır ve kaynak gösterebilir. Bilgi sorununda RAG, davranış sorununda fine-tuning.
Token modelin işlediği metin parçasıdır; her istekte context'e girer ve faturalandırılır. Parameter ise eğitimde öğrenilen ve modelin içinde sabit duran ağırlıktır. Token akıp geçer, parameter modelin kalıcı "bilgisidir"; ikisi farklı şeyleri sayar.
İkisi de çıktı çeşitliliğini ayarlar ama farklı düğmelerdir. Temperature olasılık dağılımını düzleştirir ya da sivriltir. Top-p ise yalnızca olasılığı belli bir eşiği dolduran token kümesinden seçer. Genellikle birini sabit tutup diğerini ayarlamak önerilir; ikisini birden agresif değiştirmek çıktıyı öngörülemez kılar.
Üretken AI (generative AI) yeni içerik üreten tüm sistemleri kapsayan geniş bir şemsiyedir — metin, görsel, ses, video. LLM bu şemsiyenin metne (ve koda) odaklanan alt kümesidir. Her LLM üretken AI'dır; ama her üretken AI bir LLM değildir. Görsel üreten bir difüzyon modeli üretken AI'dır, LLM değildir.
Training modeli veriyle bir kez (ya da ara ara) eğitip ağırlıkları oluşturmaktır; pahalı ve yavaştır. Inference ise eğitilmiş modeli kullanıp yanıt üretmektir; her isteğinizde olan budur. Günlük maliyet ve gecikme neredeyse tamamen inference tarafındadır.
Transformer mimarisini tanımlayan temel makale, kavramları görselleştiren açıklayıcılar ve LLM uygulamalarının güvenlik tarafı için OWASP rehberi.
Prompt tasarımından RAG mimarisine, değerlendirme ve maliyet optimizasyonuna kadar; AI'ı güvenli ve ölçülebilir biçimde devreye almak için bize yazabilirsiniz. Güvenlik tarafı için prompt injection ve AI ajanları yazımıza da göz atabilirsiniz.