AI mi, ML mi, LLM mi lazım?

Sorun: tüm çekiçler aynı görünüyor

"Bu özelliğe AI ekleyelim" toplantılarında sık görülen kafa karışıklığı şu üç kavramı eşitlemekten doğar: yapay zeka (AI), makine öğrenmesi (ML) ve büyük dil modelleri (LLM). Aslında üçü iç içe geçmiş halkalar:

• AI en geniş çatıdır. Bir bilgisayarın "akıllıca" davranmasını sağlayan her teknik — kural tabanlı sistemler dahil.
• ML AI'nın bir alt kümesidir. Veriden öğrenen sistemler.
• LLM ML'nin (özellikle derin öğrenmenin) bir alt kümesidir. Devasa metin verisinde eğitilmiş, dil tahmin eden modeller (GPT, Claude, Gemini).

Bu rehber, bir özelliği uygularken hangisini seçmen gerektiğini somutlaştırmaya çalışıyor. Çoğu zaman doğru cevap "ikisi birden" değil, "şuna en sade çözüm" olur — ve sade cevap çok defa LLM bile değildir.

Karar şeması (akış)

Bir özellik kafanda canlanırken sırayla şu soruları sor:

Soru 1: Sabit bir kural çözüyor mu?

"Sipariş tutarı > 10.000 TL ise manuel onaya yönlendir."

Bu, AI / ML / LLM değil — basit bir if/else'dir. Bir mühendisin yazıp commit ettiği iki satırlık bir kural. Tahmin etmek değil, bilineni uygulamak söz konusu.

Kural: İş mantığı net, sabit ve insan tarafından kolayca yazılabiliyorsa, AI'ya bulaşma. Daha az sürpriz, daha kolay test, daha düşük maliyet.

Soru 2: Tahmin yapması gereken sayısal/kategorik bir şey var mı?

"Bu kullanıcı önümüzdeki 30 gün içinde aboneliğini iptal eder mi?" "Bu evin satış fiyatı ne olur?" "Bu işlem dolandırıcılık mı?"

Bu sorular klasik makine öğrenmesi alanına girer. Etiketli geçmiş veriden bir model eğitirsin (gradient boosting, lojistik regresyon, random forest); model yapısal verideki örüntüleri öğrenir, yeni örnekte tahmin verir.

Kural: Geçmiş verin var, tahmin etmek istediğin şey net (sayı ya da kategori), tabular düzendeyse, ML bunun için tasarlandı. LLM çağırmak hem 1000x daha pahalı hem de daha düşük doğruluk verir.

Soru 3: Görüntü, ses ya da yapısal olmayan veri mi?

"Bu fotoğraftaki nesneleri tanı." "Bu konuşmayı metne çevir." "Bu MR görüntüsünde tümör var mı?"

Bu, derin öğrenmenin klasik alanıdır — özel mimariler (CNN, RNN, Vision Transformer, Whisper) bu işlere optimizedir. Hazır pre-trained modeli kullanmak en pratik yoldur.

Kural: Yapısal olmayan veri (görüntü, ses, video) için derin öğrenme; LLM bu görevlerde nadiren en iyi seçim, multi-modal LLM ise pahalı bir genel-amaçlı çözümdür.

Soru 4: Doğal dil mi içeriyor?

"Bu müşteri yorumunu özetle." "Bu uzun belgenin sorularına cevap ver." "Bu metni İngilizce'den Türkçe'ye çevir." "Kullanıcının niyetini anla, doğru iş akışına yönlendir."

Bu sorular LLM'in tatlı noktasıdır. Doğal dili anlama, üretme, dönüştürme görevlerinde GPT/Claude/Gemini uzun yıllar süren araştırmaları arkasına alıyor. Sıfırdan model eğitmek yerine API çağırmak %95 senaryoda doğru karar.

Ama: Yapısal cevap istiyorsan (JSON, sınıf etiketi, sayı), LLM'i bir sınıflandırıcı gibi kullanmak yerine önce sıradan ML'i değerlendir. Hız, maliyet, açıklanabilirlik üçlüsü çoğu zaman ML lehine.

Soru 5: Birden fazla iş akışını koordine etmesi gerekiyor mu?

"Müşterinin sorusunu anla, veritabanını sorgula, sonucu özetle, bir e-posta yaz."

Bu, AI ajanı (agent) alanıdır. LLM artık tek bir cevap üretmiyor, kararlar zincirini yönetiyor: hangi tool'u çağırayım, sonucu nasıl yorumlayayım, sırada ne var. MCP server'ları, function calling, ReAct döngüsü bu mimarinin parçaları.

Kural: Çok adımlı, koşullu iş akışı varsa LLM ajanı düşün. Ama önce: gerçekten ajan mı lazım, yoksa düz bir otomasyon (cron + lambda + API çağrısı) yeter mi? Ajan pahalı, hatalı ve takip etmesi zor — basit bir cron işiyse cron seç.

Senaryolarla pekiştirme

Senaryo A: e-ticaret arama kutusu

İhtiyaç: kullanıcı "kırmızı yazlık elbise 36 beden" yazıyor; sonuçlar ilgili olsun.

Yanlış cevap: "GPT'ye gönderelim, niyeti çıkarsın." Pahalı, yavaş.

Doğru cevap: Klasik arama (BM25 veya OpenSearch) + ürün filtre etiketleri + (opsiyonel) embedding tabanlı semantic search. İhtiyaç ML, hatta çoğunlukla klasik IR.

LLM ne zaman gelir? "Yeni anneler için pratik tişört" gibi soyut sorular geldiğinde, niyet yorumu için LLM bir adım eklenebilir. Ama temel arama altyapı LLM olmamalı.

Senaryo B: müşteri destek bot

İhtiyaç: kullanıcı sorusunu sorar, ürün dokümanından cevap üretilsin.

Doğru cevap: RAG mimarisi — embedding ile dokümanı vektör DB'ye al, soruyla en alakalı parçaları getir, LLM'e ver, cevap üret. Burada LLM doğal yerinde: doğal dil anlama + üretme. Klasik ML bu işi yapamaz; doğal dil çıkarımı pre-trained transformer'ın güçlü yanı.

Senaryo C: kredi başvurusu skoru

İhtiyaç: Yeni başvuruyu "düşük / orta / yüksek risk" olarak skorla.

Doğru cevap: Klasik ML — gradient boosting veya lojistik regresyon. Doğruluk yüksek, latency düşük, açıklanabilirlik yüksek (yasal zorunluluk). LLM'e başvurmak hem yavaş, hem regülatör nezdinde savunulamaz.

Senaryo D: PDF özetleyici

İhtiyaç: 50 sayfalık raporu 1 sayfaya indir.

Doğru cevap: LLM, doğrudan. Doğal dil özetleme klasik ML'in çok zayıf olduğu ve LLM'lerin doğduğu işlerden. API çağır, prompt yaz, bitti.

Senaryo E: dolandırıcılık tespiti

İhtiyaç: Saniyede 10.000 işlemi anlık skorla.

Doğru cevap: Klasik ML (gradient boosting) — milisaniyede tahmin, yüksek doğruluk, açık feature importance. LLM'in 200 ms gecikmesi bu volümde imkansız.

Senaryo F: kişisel asistan ajanı

İhtiyaç: "Bana yarın saat 10'da müsait olduğum saatlere uygun bir restoran ayarla, takvimime ekle, eşime SMS gönder."

Doğru cevap: LLM ajanı + MCP server'ları (calendar, sms, restaurant API). Çok adımlı, koşullu, doğal dil arayüzlü iş akışı; tam olarak ajan ne için tasarlandıysa o.

Pratik karar tablosu

Görev	Doğru çözüm
Sabit iş kuralı uygula	if/else
Tabular tahmin (sayı/kategori)	Klasik ML
Görüntü / ses tanıma	Derin öğrenme
Doğal dil özet/üretim/çeviri	LLM
Yapılandırılmış cevap (JSON, sınıf)	Önce ML, gerekirse LLM
Çok adımlı iş akışı	LLM ajanı (gerekçeli)
Soruya doküman tabanlı cevap	RAG (LLM + embedding)
Dengesiz nadir sınıf tespiti	Anomali tespiti
Zaman içinde tahmin	Forecasting

Paralel maliyet ve risk düşüncesi

Hangi kategoriyi seçerken aklında olsun:

• Maliyet: if/else ücretsiz, ML eğitim bir kerelik + ucuz inference, LLM her çağrıda token ücreti.
• Latency: if/else mikrosaniye, ML milisaniye, LLM 100ms-2s arası.
• Açıklanabilirlik: if/else mükemmel, klasik ML iyi, LLM kara kutu.
• Düzenleyici uyum: Sağlık/finans gibi alanlarda LLM'in kara kutu doğası problem; ML tercih edilir.
• Bakım yükü: if/else en az; ML model retrain ihtiyacı; LLM provider değişikliği takibi.

Yaygın anti-pattern'ler

"Her şeye GPT"

Yeni başlayan ekiplerin klasik tuzağı. Tek bir if/else yerine API çağırmak, her tabular tahmin için LLM kullanmak — pahalı ve yavaş. Önce sade çözümü dene.

"AI'sız bir özellik şahsen olamaz"

Bir özellik AI içermek zorunda değildir. Toplantılarda AI talep edilirse, "asıl iş probleminin çözümü ne?" sorusunu öne çek. AI çözüm değil, bir araçtır.

"Pre-trained model var, kullanmayalım, kendimizi eğitelim"

%99 zamanda hazır modeli almak doğru karar. Sıfırdan eğitmek hem pahalı hem geç. Ancak özel bir alanın uzun-kuyruk gereksinimi varsa fine-tuning veya custom model düşünülür.

Sonuç

Bir özellik üzerinde düşünürken karar şemasını sırayla geçir:

1. Sabit kural? → if/else
2. Tabular tahmin? → ML
3. Yapısal olmayan veri? → derin öğrenme
4. Doğal dil? → LLM
5. Çok adımlı iş akışı? → ajan

Bu sıra doğal olarak en sade ve en uygun olanı yukarı çeker. AI'ya bulaşmadan önce, gerçekten gerekli mi sorusunu sor.

Devamı için

• AI — en geniş çatı: bilgisayarın "akıllı" davranması.
• Makine Öğrenmesi — veriden öğrenen sistemler ailesi.
• LLM — modern AI'ın merkezi: büyük dil modelleri.
• RAG — modeli yeniden eğitmeden ona bilgi vermenin standart yolu.
• Token Tasarrufu Yöntemleri — LLM kullanırken maliyeti düşürmek.