Yapay Zeka Mimarisi Nasıl Kurgulanır? Kurumsal LLM ve CV Sistemleri İçin Kapsamlı Rehber

Büyük dil modelleri (LLM) ve bilgisayarlı görü (CV) sistemlerini prototipten üretime taşımak, çoğu ekibin sandığından çok daha fazla mimari disiplin gerektirir. Bir modelin Jupyter notebook'ta doğru sonuç vermesi ile o modelin saniyede binlerce isteği, kesintisiz ve öngörülebilir maliyetle karşılayabilmesi arasında devasa bir mühendislik uçurumu vardır. Yapay zeka mimarisi kurarken karşılaşılan zorluklar sadece "modeli nasıl çalıştırırım" sorusuyla sınırlı değildir; veri akışından maliyet kontrolüne, gözlemlenebilirlikten güvenliğe kadar uzanan bütünsel bir sistem tasarımı gerektirir. Bu kapsamlı rehberde, canlı sistemlere yapay zeka entegre ederken karşılaştığımız temel mimari kararları, bu kararların neden kritik olduğunu ve pratikte nasıl uygulandığını detaylı biçimde ele alıyoruz.

1. Model Sunumu: Senkron mu, Asenkron mu?

İlk ve en kritik karar, modelin nasıl sunulacağıdır. Düşük gecikme gerektiren, kullanıcı arayüzüne doğrudan bağlı senaryolarda (örneğin gerçek zamanlı nesne tespiti veya sohbet asistanı) senkron bir REST veya gRPC katmanı mantıklıdır. Ancak toplu işleme, rapor üretimi veya büyük veri setleri üzerinde çalışan modellerde asenkron kuyruk tabanlı mimari (RabbitMQ, Redis Streams veya Kafka ile) hem sistemi koruma altına alır hem de maliyeti öngörülebilir kılar.

Pratikte bu ayrım, sistemin trafik profiline göre hibrit bir yaklaşımla da uygulanabilir: kullanıcıya anında görünen kısa yanıtlar senkron bir uç nokta üzerinden dönerken, aynı isteğin arka planda tetiklediği daha ağır analizler (örneğin bir belgenin tamamının özetlenmesi) kuyruğa alınıp tamamlandığında webhook veya websocket ile kullanıcıya bildirilir. Bu tasarım, hem kullanıcı deneyimini hem de sistem kaynaklarının verimli kullanımını aynı anda sağlar.

Kural şu: kullanıcı ekranın karşısında bekliyorsa senkron, sistem arka planda çalışıyorsa asenkron. Bu ayrımı atlayan ekipler, trafik arttığında modelin kendisini değil, mimarilerini yeniden yazmak zorunda kalır.

2. GPU Kaynak Yönetimi ve Maliyet Optimizasyonu

GPU, bulut altyapısındaki en pahalı kaynaktır ve boşta bekletmek doğrudan yakılan paradır. Üretim ortamında öne çıkan birkaç temel strateji şunlardır:

• Dinamik batching: Gelen istekleri milisaniyeler içinde gruplayıp tek seferde GPU'ya göndermek, throughput'u ciddi şekilde artırır. vLLM veya TensorRT-LLM gibi sunum motorları bu batching mantığını otomatikleştirir.
• Model quantization: FP32 yerine FP16, BF16 veya INT8 kullanmak, bellek kullanımını yarıya indirirken çoğu senaryoda doğruluk kaybı gözle görülür seviyede olmaz. Daha agresif 4-bit quantization ise özellikle edge dağıtımlarında tercih edilir.
• Autoscaling politikaları: Klasik CPU/RAM tabanlı autoscaling GPU iş yükleri için yetersizdir; kuyruk derinliği veya GPU utilization metrikleri temel alınmalıdır.
• Spot/preemptible instance kullanımı: Eğitim veya toplu çıkarım (batch inference) gibi kesintiye toleranslı iş yüklerinde spot GPU örnekleri kullanmak, maliyeti %60-70 oranında düşürebilir.
• Model routing (yönlendirme): Her isteği en pahalı, en büyük modele göndermek yerine, isteğin karmaşıklığına göre küçük ve büyük modeller arasında yönlendirme yapan bir "router" katmanı kurmak, ortalama maliyeti ciddi oranda azaltır.

3. Veri Pipeline'ı: Modelin Görmediği Kısım

Bir modelin başarısı, aslında ona giden veri pipeline'ının kalitesiyle doğru orantılıdır. Canlıya alınan sistemlerde en sık gördüğümüz hata, eğitim ve üretim ortamındaki veri ön işleme adımlarının (normalizasyon, tokenization, görüntü boyutlandırma) birbirinden sapmasıdır — buna literatürde train-serve skew denir ve sessizce doğruluğu düşüren en tehlikeli hatalardan biridir.

Bunu önlemek için ön işleme kodunu tek bir paylaşılan kütüphanede tutuyor, hem eğitim hem de servis katmanının aynı fonksiyonları çağırmasını zorunlu kılıyoruz. Basit gibi görünse de bu tek karar, üretimdeki en pahalı hataların büyük kısmını ortadan kaldırıyor. Ayrıca, RAG (Retrieval-Augmented Generation) tabanlı sistemlerde veri pipeline'ı; belge parçalama (chunking) stratejisi, embedding modeli seçimi ve vektör veritabanı indexleme politikası gibi ek katmanlar da içerir. Bu katmanlardaki küçük bir yanlış yapılandırma, modelin kendisi mükemmel olsa bile sonuç kalitesini ciddi şekilde düşürebilir.

4. Gözlemlenebilirlik (Observability)

Klasik uygulama loglaması, AI sistemleri için yeterli değildir. İzlenmesi gereken üç ek katman var:

• Model drift: Giriş verisinin dağılımı zamanla değişir mi? Değişiyorsa model sessizce kötüleşiyor demektir.
• Latency percentile'ları: Ortalama gecikme değil, p95 ve p99 değerleri kullanıcı deneyimini belirler.
• Confidence score dağılımı: Modelin kendine olan "güveni" zamanla düşüyorsa, bu genelde veri kalitesinde bir sorunun erken sinyalidir.
• Token bazlı maliyet takibi: LLM tabanlı sistemlerde her isteğin girdi/çıktı token sayısını ve buna karşılık gelen maliyeti izlemek, bütçe aşımlarını erken fark etmenin tek yoludur.
• Hallucination / halüsinasyon oranı: Otomatik değerlendirme (LLM-as-a-judge) veya kullanıcı geri bildirimleriyle modelin yanlış veya uydurma bilgi üretme oranı düzenli olarak ölçülmelidir.

5. Fallback ve Graceful Degradation

Hiçbir model %100 uptime garantisi veremez. İyi tasarlanmış bir sistem, model erişilemez olduğunda kullanıcıya hata vermek yerine daha basit bir kural tabanlı sisteme veya önbelleklenmiş bir sonuca düşebilmelidir. Bu, kullanıcı deneyimini korumanın yanı sıra, ekibe model tarafında sorun giderme için zaman kazandırır. Çok sağlayıcılı (multi-provider) mimarilerde, birincil model sağlayıcısı yanıt veremediğinde otomatik olarak ikincil bir sağlayıcıya geçiş yapan bir katman kurmak da yaygın bir dayanıklılık pratiğidir.

6. Yaygın Hatalar ve Nasıl Kaçınılır

Kurumsal AI projelerinde tekrar tekrar karşılaştığımız birkaç hata örüntüsü şunlardır:

• Prompt'ları versiyonlamamak: Prompt metinleri de tıpkı kod gibi versiyon kontrolüne tabi tutulmalı, her değişiklik test edilip ölçülmelidir.
• Değerlendirme setinin olmaması: "Model iyi çalışıyor mu?" sorusunun cevabı sübjektif izlenimlere değil, önceden hazırlanmış bir değerlendirme (eval) setine dayanmalıdır.
• Tek sağlayıcıya bağımlılık: Tek bir model sağlayıcısına tam bağımlı bir mimari, fiyat değişikliklerine ve kesintilere karşı kırılgandır.
• Güvenlik katmanının ihmal edilmesi: Prompt injection saldırılarına karşı girdi doğrulama ve çıktı filtreleme mekanizmaları olmadan üretime çıkmak ciddi risk taşır.

Sıkça Sorulan Sorular

LLM tabanlı bir sistemi üretime almadan önce hangi testler yapılmalı?

Fonksiyonel doğruluk testlerinin yanı sıra yük testi, halüsinasyon oranı ölçümü, gecikme (latency) testleri ve kötüye kullanım senaryolarına (prompt injection, jailbreak) karşı güvenlik testleri mutlaka yapılmalıdır.

Küçük bir ekip için en uygun model sunum stratejisi nedir?

Kaynak kısıtlı ekipler için genellikle yönetilen bir API sağlayıcısıyla başlamak, trafik ve maliyet öngörülebilir hale geldiğinde kendi barındırdığı (self-hosted) açık kaynak modellere geçmek en dengeli yoldur.

Model drift nasıl erken tespit edilir?

Giriş verisinin istatistiksel dağılımını (örneğin embedding uzayındaki merkez kayması) periyodik olarak referans dağılımla karşılaştıran otomatik izleme panelleri kurarak drift erken aşamada yakalanabilir.

Sonuç

Yapay zeka mimarisi kurgulamak, aslında bir model seçme meselesinden çok, o modelin etrafındaki sistemi güvenilir, ölçeklenebilir, maliyet açısından sürdürülebilir ve gözlemlenebilir hale getirme meselesidir. Doğru mimari kararlarla kurulan bir altyapı, model değiştiğinde bile ayakta kalır — çünkü asıl değer modelde değil, onu çevreleyen mühendislikte saklıdır. Kurumsal ölçekte başarılı bir AI ürünü, en gelişmiş modeli değil, en dayanıklı ve en iyi izlenen sistemi kuran ekiplerin elinden çıkar.