czay.dev
0/5
Yol haritaları

LLM vs. Karar Modeli (Decision Model) & Shadow Mode Geçiş Rehberi

Bu interaktif mimari rehber, Amazon Web Services (AWS) mühendisleri Carr Onstott ve Mehul Jaiswal'ın dünyanın en büyük iç ticket sistemlerinden birinde Claude Sonnet 4.6'yı söküp yerine Gemma 4 tabanlı Strands Decider E4B karar modelini koyarak 1 milyon ticket maliyetini 22.200 dolardan 500 dolara (%98 tasarruf, 44 kat ucuzlama) indirdiği gerçek mühendislik vakasına dayanır.

Modern yazılım ekiplerinin en pahalı hatası, sadece 10-20 sabit seçenek arasından yönlendirme veya sınıflandırma yapacak bir işe devasa bir Generative LLM bağlayıp her istekte yüzlerce token'lık JSON ve açıklama metni yazdırmaktır. Aşağıdaki 4 aşamalı kontrol listesiyle kendi projenizde hangi işleri 1-Token'lık karar modellerine yıkabileceğinizi ve canlı trafiği riske atmadan 3 konumlu Shadow Mode şalteriyle nasıl geçiş yapacağınızı adım adım uygulayabilirsiniz.

  • Temelİşe girmeden önce sağlam bilinmeli
  • İyi olurİlanlarda sık geçiyor, elini güçlendirir
  • Sonraİşe girdikten sonra, ihtiyaç doğunca

Bir konuya tıkla: ne bilmen gerektiği ve kaynaklar açılır.

  1. 01

    1. Aşama: Teşhis — Neden 170 Output Token Yazdırıyoruz?

    Sisteminizde metin üretimi (Generative AI) yerine olasılık dağılımı (Decision Model) gerektiren gizli darboğazları tespit edin.

  2. 02

    2. Aşama: Prompt Sıkıştırma & JSON Key Sıralaması Tuzağı

    4.096 token penceresine sığmak için kategori tanımlarını daraltın ve olasılık skorunu %19 saptıran JSON key sırası hatasını önleyin.

  3. 03

    3. Aşama: 3 Konumlu Shadow Mode Şalteri (BEDROCK -> DUAL -> DECIDER)

    Şalteri tek seferde indirip dua etmeyin: Canlı trafikte iki modeli paralel koşturup 45 saniyede geri dönebilen mimariyi kurun.

  4. 04

    4. Aşama: İzole GPU Altyapısı & %98 Maliyet Doğrulaması

    Modeli dış ağa kapalı tek bir A10G GPU üzerinde koşturun ve $22.200 -> $500 maliyet düşüşünü doğrulayın.

Konu konu

Haritadaki her konunun açıklaması, bilmen gerekenler ve kaynaklar — tek listede.

  1. 011. Aşama: Teşhis — Neden 170 Output Token Yazdırıyoruz?

    • Sabit Katalog (Closed Choice) İş Yüklerini Ayıklama· Temel

      Amazon'un iç ticket sisteminde müşteri eskalasyonları, kapasite talepleri, otomatik alarmlar ve güvenlik bulguları toplam 20 sabit kategoriye ayrılıyordu. Claude Sonnet 4.6 her ticket için 6.554 input token okuyor ve JSON + gerekçe yazmak için 170 output token üretiyordu.

      Bilmen gerekenler

      • Uygulamanızdaki LLM çağrılarını listeleyin: Çıktı olarak üretilen JSON'un içindeki metin kullanıcıya gösteriliyor mu, yoksa kodunuz sadece 'category_id' veya 'route' alanını okuyup if/switch bloğuna mı sokuyor?
      • Seçenek sayınız sabitse (ör. 5 ila 50 kategori + 1 'none' seçeneği) ve açıklama metnine ihtiyaç yoksa bu iş bir LLM işi değil, Karar Modeli (Decision Model) işidir.
      • Output token'lar her zaman input token'lardan 5 kat daha pahalıdır ($15/1M vs $3/1M) ve gecikmenin (latency) asıl sebebidir. 170 output token'ı 1 token'a indirmek gecikmeyi anında %78 keser.

      Kaynaklar

  2. 022. Aşama: Prompt Sıkıştırma & JSON Key Sıralaması Tuzağı

    • 6.554 Input Token'ı 2.009 Token'a İndirmek· Temel

      Amazon'un Sonnet 4.6 için kullandığı mevcut kategori açıklamaları tek başına Strands Decider'ın 4.096 token'lık penceresinden daha uzundu. Ekip 20 kategorinin her birini 1-2 cümlelik net kriterlere indirdi.

      Bilmen gerekenler

      • Strands Decider 2B yerine Gemma 4 tabanlı E4B (4 milyar parametre) sürümünü seçin; Amazon'un testlerinde E4B hem 2B'yi hem de canlıdaki Claude Sonnet 4.6'yı doğrulukta geçti.
      • Her seçeneği 1-2 cümlelik keskin bir kriter olarak tanımlayın ve modele 'hiçbiri uymuyorsa' kaçış yapabilmesi için mutlaka bir 'none' seçeneği ekleyin.
      • Çok uzun ticket veya dokümanlarda en yeni bilgileri koruyup en eski yorumları kırparak (truncate oldest comments) 4.096 token sınırını koruyun.
    • Kritik Tuzak: JSON Key Sıralaması (%19 Olasılık Sapması)· Temel

      Amazon mühendislerinin canlı testlerde yakaladığı en şaşırtıcı bulgu: Aynı ticket verisini JSON içindeki key'lerin sırasını değiştirerek gönderdiklerinde modelin olasılık skoru 0.19 (%19) oranında değişti!

      Bilmen gerekenler

      • Karar modeline (veya herhangi bir LLM sınıflandırıcıya) JSON payload göndermeden önce tüm objeleri deterministik olarak alfabetik key sırasıyla (JSON.stringify replacer / sort_keys=True) serileştirin.
      • Etiket uygulama (label application) için bir güven eşiği (confidence threshold) belirleyin; modelin skoru eşiğin altındaysa zorla etiket atamak yerine insan incelemesine veya üst modele yönlendirin.

  3. 033. Aşama: 3 Konumlu Shadow Mode Şalteri (BEDROCK -> DUAL -> DECIDER)

    • Feature Flag / AppConfig İle 3 Modlu Çalışma· Temel

      SQS kuyruğundan tetiklenen etiketleme Lambda'sı her mesajda AWS AppConfig'den 3 konumlu bir ayar okur: BEDROCK (sadece Sonnet), DUAL (ikisi paralel çalışır, Sonnet sonucu uygulanır ama farklar loglanır) ve DECIDER (sadece Strands Decider çalışır).

      Bilmen gerekenler

      • 1. Adım (BEDROCK / Mevcut LLM): Mevcut üretim hattınız; yeni model henüz çağrılmaz.
      • 2. Adım (DUAL / Shadow Mode): Canlıdaki her ticket için hem Sonnet 4.6 hem Strands Decider paralel çağrılır. Ticket'a Sonnet'in cevabı yazılır ama iki modelin farklı karar verdiği her vaka CloudWatch'a kaydedilip incelenir.
      • 3. Adım (DECIDER / Tam Geçiş): Uyuşmazlık analizinde karar modelinin daha isabetli olduğu kanıtlandığında şalter DECIDER konumuna alınır. Herhangi bir sorunda geri dönmek (rollback) sadece 45 saniyelik bir config değişikliğidir.

  4. 044. Aşama: İzole GPU Altyapısı & %98 Maliyet Doğrulaması

    • SageMaker ml.g5.xlarge (1x A10G 24GB) & Ağ İzolasyonu· Temel

      Strands Decider E4B, 24 GB VRAM'li tek bir NVIDIA A10G GPU (ml.g5.xlarge, saati $1.408) üzerinde yaklaşık 19 GiB VRAM tüketir ve istek başına 640 ms (uçtan uca 897 ms) sürede yanıt verir.

      Bilmen gerekenler

      • Model ağırlıklarını başlangıçta S3'ten çekin ve container'ın dış dünyaya (outbound internet) erişimini tamamen kapatarak tam veri izolasyonu sağlayın.
      • Tek bir ml.g5.xlarge instance saatte ~5.600 ticket işler: Tam kapasitede 1 milyon ticket maliyeti $250, ani trafik artışları (burst headroom) için bırakılan payla pratikte ~$500 olur (Sonnet 4.6'nın $22.200 maliyetine kıyasla 44 kat ucuz!).
      • Yan kazanım: Çağrı süresi 4.215 ms'den 897 ms'ye düştüğü için modeli çağıran AWS Lambda fonksiyonlarının çalışma süresi ve maliyeti de %74 azalır!

      Kaynaklar