1. Giriş

AI observability, yapay zekâ sistemlerinin (özellikle LLM ve RAG tabanlı uygulamaların) üretim ortamında sağlıklı, güvenilir ve izlenebilir biçimde çalışmasını garanti eden uygulamalar bütünüdür. Geleneksel uygulama izleme (APM) ile benzer hedefleri olsa da AI sistemleri; veri drift, model drift, hallucination, retriever kalitesi gibi modele özgü yeni riskler getirir. Bu nedenle hem model içi hem sistem düzeyinde özel metriklerin, izleme araçlarının ve operasyonel proseslerin kurulması gerekir.

Bu konu neden konuşuluyor?

• LLM ve retrieval tabanlı sistemlerin üretime alınması ile hataların maliyeti arttı; hataların erken tespiti ve sınıflandırılması kritik.
• Regülasyon ve güven gereksinimleri (audit trail, explainability) observability gerektiriyor.
• Model davranışları zamanla değişebildiğinden (drift), sürekli izleme ve otomatik uyarı mekanizmaları gerekli.

Kimler için önemli?

MLOps mühendisleri, ML mühendisleri, platform ve SRE ekipleri, veri mühendisleri ile ürün yöneticileri için AI observability kritik bir konu. Üretim performansı, maliyet kontrolü, güvenlik ve kullanıcı deneyimi üzerinde doğrudan etkisi vardır.

Hangi problemleri çözüyor?

AI observability; latency ve hata ayıklama, performans regresyonu, veri/model drift tespiti, hallucination izleme, retriever başarısızlıklarını tanımlama, güvenlik olaylarının takibi ve audit gereksinimlerinin karşılanması gibi problemleri çözer.

2. Kavramsal Temeller

Temel kavramlar

• Observability: Sistemin iç durumunu dışarıdan ölçülebilir sinyaller (metric, log, trace) ile gözlemleme yeteneği.
• Metric: Zaman serisi şeklinde toplanan sayısal göstergeler (latency, token usage, throughput).
• Log: Olay bazlı kayıtlar; prompt, model response, retriever sonuçları gibi bağlamsal içerik içerebilir.
• Trace: Dağıtık sistem çağrı zincirlerinin takibi; request'in tüm mikroservislerdeki yolunu gösterir.
• Drift: Veride (input drift) veya model performansında (model drift) zamanla oluşan sapma.
• Hallucination rate: Modelin doğrulanmamış veya yanlış bilgi üretme oranı; genelde sampling + human eval ile ölçülür.
• Retrieval recall@k: Retriever'ın ilgili dokümanları ne sıklıkta getirdiğini gösteren metrik.

Temel bileşenler

1. Telemetry pipeline: Metric, log ve trace toplayan altyapı (Prometheus, Grafana, Elastic, Jaeger).
2. Event/metadata enrichment: Her çağrıya context ekleme (model id, prompt id, embedding versi, retriever snapshot id).
3. Monitoring & alerting: SLA/SLO bazlı uyarılar ve anomali tespiti.
4. Evaluation & labeling: İnsan değerlendirmesi ve otomatik doğrulama katmanları.
5. Replay & forensics: Kayıtlı çağrıların yeniden çalıştırılması ve root-cause analysis (RCA).

3. Nasıl Çalışır? — Teknik Mimari

Sistem mimarisi — yüksek seviyede veri akışı

1. Client → API Gateway: Kimlik doğrulama, rate-limiting, quota ve ön filtreleme.
2. Orchestrator: Prompt assembly, retriever çağrısı, model seçimi (cost-aware routing).
3. Model/Provider çağrısı: LLM, embedding veya reranker servisi.
4. Post-processing: Output filter, attribution, PII scrub.
5. Telemetry collector: Her çağrı için metric, log ve trace üretip observability pipeline'a gönderir.
6. Monitoring & Anomaly detection: Metrikleri izler, drift/hallucination/downtime olaylarını yakalar.
7. Incident response & HITL: Uyarılar insan operatöre veya otomatik kompansasyon akışına gönderilir.

Telemetry ve enrichment stratejileri

Observability verisi faydalı olabilmesi için zengin metadata içermelidir. Özgün uygulama bağlamında her çağrıya şu alanlar eklenmelidir:

• request_id, user_id (anonimized), timestamp
• model_id, model_version, prompt_template_id
• retriever_snapshot_id, index_version, top_k_results (IDs + scores)
• token_usage, latency_ms, response_size
• confidence_score, reranker_scores, hallucination_flag (human/eval)

Metrik kategorileri

• Infrastructure metrics: CPU, memory, disk, network, container health.
• Latency & throughput: p50/p95/p99 latency, requests per second, queue length.
• Cost metrics: token usage, model-inference cost per request, storage costs.
• Quality metrics: recall@k (retriever), hallucination rate, answer accuracy, user satisfaction (CSAT).
• Drift metrics: input distribution change, embedding distance drift, label distribution change.
• Security & privacy metrics: PII detection rate, unauthorized access attempts.

4. Gerçek Dünya Uygulamaları

Netflix — içerik QA ve moderation

İçerik QA pipeline'larında observability, modelin içerik tanımlamalarındaki regressiyonları ve moderation kararlarının doğruluğunu izlemek için kullanılır. Hallucination veya yanlış kategori ataması tespit edilirse canary rollback veya HITL tetiklenir.

Uber — müşteri destek agent'ları

Dispatch agent'ları ve destek asistanları için latency/availability SLA'ları kritiktir. Ayrıca retriever başarısızlıkları veya yanlış ücret hesaplamaları hızlıca yakalanmalı ve otomatik kompansasyon devreye alınmalıdır.

Amazon — RAG destekli e-ticaret asistanı

RAG sistemleri ürün catalog güncellik sorunlarına karşı observability ile korunur: index_version mismatch veya stale embeddings saptandığında reindex job'ı tetiklenir.

OpenAI/Platform sağlayıcıları — hizmet seviyesi

Model sağlayıcıları model performansını regional olarak izler ve yeni model sürümlerinin regressiyon testlerini otomatik metriklerle değerlendirir. Kullanıcı deneyimi metrikleri (latency, error-rate, hallucination trend) SLA kararlarını etkiler.

5. Avantajlar ve Sınırlamalar

Avantajlar

• Erken uyarı: Performans veya doğruluk düşüşleri erken tespit edilir.
• Hızlı RCA: Zengin telemetry sayesinde root-cause analysis daha hızlı yapılır.
• Uyumluluk: Audit trail ve replay özelliği regülasyon gereksinimlerini destekler.
• Maliyet kontrolü: Token ve model kullanım metrikleri ile maliyet optimizasyonu mümkün olur.

Sınırlamalar

• Veri hacmi: Log ve metric artışı depolama ve işleme maliyetlerini yükseltir.
• False positive uyarılar: Çok hassas alarm kuralları operasyonel yük yaratabilir.
• İnsan kaynağı: İnsan değerlendirmesi (labeling/HITL) süreçleri maliyetlidir.
• Gizlilik: Prompt ve response logging PII riski taşıyabilir; maskleme ve erişim kontrolleri zorunlu.

6. Alternatifler ve Karşılaştırma

Observability çözümü seçimi altyapıya ve organizasyon önceliklerine bağlıdır. Aşağıdaki tablo genel yaklaşımları özetler.

7. En İyi Pratikler

Production kullanımı

• Telemetry-first design: Her yeni özellik telemetry tasarımıyla birlikte planlanmalı.
• Prompt/model/version tagging: Hangi prompt ve modelin hangi sonucu ürettiği açıkça kayıtlı olmalı.
• SLO/SLA tanımlama: latency, availability ve quality için açık hedefler belirleyin.
• Canary & staged rollout: Model veya prompt değişikliklerini aşamalı dağıtın ve metrikleri karşılaştırın.

Performans optimizasyonu

• Sampling stratejileri: Tüm çağrıyı saklamak pahalıdır; stratified sampling ile hem hata tespiti hem maliyet kontrolü sağlar.
• Asenkron logging: Production latency'ni etkilemeden telemetry gönderin (fire-and-forget + retry/backpressure).
• Summarization for logs: Uzun prompt/response'ları özetleyip saklayın; raw data sadece kısa dönemli tutulsun.

Güvenlik

• PII masking: Ingestion aşamasında otomatik PII tespiti ve maskeleme uygulayın.
• Access control: Log ve telemetry verilerine erişimi sıkı RBAC ile kontrol edin.
• Immutable audit logs: Kritik eylem ve karar kayıtlarını değiştirilmez şekilde saklayın.

Ölçeklenebilirlik

• Metric aggregation: Prometheus tarzı timeseries aggregator ile ham veriyi özetleyin.
• Hot/cold storage: Uzun dönem raw log'ları daha ucuz depolara taşıyın, kısa dönem için hızlı erişim sağlayın.
• Autoscale telemetry pipeline: Backpressure ve queue length metriklerine göre telemetry collector'ları ölçekleyin.

8. Sık Yapılan Hatalar

• Telemetry sonradan eklemek: Observability baştan tasarlanmalı, sonradan eklemek kapsamlı refactor gerektirebilir.
• Her şeyi loglamak: Hem maliyet hem de gizlilik riski. Özet ve sampling kombinasyonu tercih edin.
• Uyarı fırtınası: Çok hassas uyarılar ops overload'a yol açar; noiseless alarm tuning yapın.
• HITL olmadan sadece otomatik kararlara güvenmek: Model belirsizliği insan onayı gerektirir.

9. Gelecek Trendler

• Automated observability pipelines: Model güncellemeleriyle otomatik metrik ve test set generator'ları entegre olacak.
• Explainability-first observability: Model kararlarını destekleyen provenance ve kanıt (evidence) otomatik toplanacak.
• Federated telemetry: Gizlilik gereksinimli uygulamalarda merkezi olmayan observability yöntemleri yaygınlaşacak.
• Self-healing systems: Anomali tespitinde otomatik düzeltme ve rollback mekanizmaları gelişecek.

10. Sonuç

AI observability, modern AI uygulamalarının sürdürülebilir, güvenilir ve uyumlu şekilde işletilebilmesi için zorunlu bir yatırımdır. Metrikler, loglar, trace'ler ve insan değerlendirmesini birleştiren bir gözlemleme katmanı; drift, hallucination ve performans problemlerini erken tespit ederek maliyetleri düşürür ve güveni artırır. Mühendis bakış açısıyla öneri: Observability'i baştan tasarlayın, prompt/model versiyonlamasını zorunlu kılın, stratified sampling ve canary rollout ile üretime geçin ve HITL süreçleri ile kaliteyi güvence altına alın.

Ek Bölümler

FAQ (Sık Sorulan Sorular)

1. AI observability nedir ve neden gereklidir?

   AI observability, model ve pipeline'ların üretim ortamında izlenmesi ve analiz edilmesi aktiviteleridir. Özellikle drift, hallucination ve retriever hatalarını erken tespit etmek için gereklidir.

2. Hangi metrikler önceliklidir?

   Latency (p50/p95/p99), token usage, hallucination rate, recall@k (retriever), error rate ve user satisfaction (CSAT) başlangıç için önceliklidir.

3. Hallucination nasıl ölçülür?

   Genelde örnekleme bazlı human-eval ile; otomatik olarak da verifier/retriever cross-check metrikleri ile tahmini ölçülebilir.

4. Log'larda hangi veriler saklanmalı?

   Prompt ID, model ID, top-k retriever IDs, token usage, latency ve anonimleştirilmiş user/session ID saklanmalı; raw PII avoid edilmelidir.

5. Telemetry maliyetini nasıl kontrol ederim?

   Sampling, summarization, retention policy ve hot/cold storage ile maliyeti kontrol altına alın.

6. Drift tespitinde hangi yöntemler kullanılır?

   Statistical tests (KL divergence, PSI), embedding distance monitoring ve label distribution monitoring yaygın yöntemlerdir.

7. Observability için hangi araçlar uygundur?

   Prometheus+Grafana, Elastic Stack, Jaeger/Zipkin, Honeycomb, Datadog ve özel ML observability çözümleri (Arize, WhyLabs) tercih edilebilir.

8. HITL süreçlerini nasıl entegre ederim?

   Low-confidence, disagreement veya critical-action durumlarını belirleyip insan onayı akışına yönlendirin; decisions ve gerekçeler audit'e kaydedilsin.

Anahtar Kavramlar

• Telemetry: Metric, log ve trace toplama.
• Drift: Zamanla veri veya model performansındaki sapma.
• Hallucination rate: Modelin yanlış bilgi üretme oranı.
• Recall@k: Retriever doğruluğunu ölçen metrik.
• HITL: İnsan-in-the-loop değerlendirme süreçleri.

Öğrenme Yol Haritası

1. Temel: Observability (metrics/logs/traces) ve dağıtık sistem izleme prensipleri.
2. ML tarafı: Drift detection yöntemleri, embedding space monitoring ve evaluation metrikleri.
3. Tooling: Prometheus, Grafana, Elastic, Jaeger, Arize, WhyLabs gibi araçlarla pratik yapın.
4. Operationalization: Canary rollout, SLO tanımlama, incident response ve HITL entegrasyonu öğrenin.
5. Advanced: Explainability, provenance ve automated remediation tekniklerini çalışın.