AI Prototipleri Üretime Hazır Olduğunda: Belirtiler ve Sonraki Adımlar

Prototip vs Üretim: Ne Değişir ve Neden

Bir prototip tek bir soruya cevap verir: “Bu fikir peşinden gitmeye değer mi?” Hız, öğrenme ve inandırıcı bir deneyim sunmak için optimize edilmiştir. Bir üretim sistemi ise farklı bir soruya cevap verir: “Bunu gerçek kullanıcılar için—tekrar tekrar, güvenli ve öngörülebilir şekilde—çalıştırabilir miyiz?”

Prototip ile üretim arasında ne sayılır

Bir prototip, bir notebook, bir UI içindeki prompt veya minimal korumalarla LLM çağıran basit bir uygulama olabilir. Uygulamanın biraz manuel olması (birinin uygulamayı resetlemesi, çıktıları elden düzeltmesi veya başarısız çağrıları yeniden denemesi) sorun değil.

Bir üretim AI özelliği ise bir taahhüttür: birçok kullanıcıda tutarlı davranmalı, uç durumları ele almalı, hassas verileri korumalı, bütçe içinde kalmalı ve model API'si yavaşladığında, kapandığında veya değiştiğinde bile çalışmaya devam etmelidir.

"Demoda çalışıyor" neden gerçek kullanıcıda başarısız olur

Demolar kontrollüdür: seçilmiş promptlar, öngörülebilir girdiler ve sabırlı bir izleyici kitlesi. Gerçek kullanım ise karışıktır.

Kullanıcılar uzun belgeler yapıştıracak, belirsiz sorular soracak, sistemi “kırmaya” çalışacak veya farkında olmadan eksik bağlam sağlayacak. LLM'ler küçük girdi değişikliklerine duyarlıdır ve prototipiniz ölçeklendiğinde geçerli olmayan varsayımlara dayanıyor olabilir—örneğin sabit gecikme, cömert kota izinleri veya aynı stilde çıktı veren tek model sürümü.

Aynı zamanda önemli olan: bir demo genellikle insan emeğini gizler. Bir ekip arkadaşınız promptu yeniden çalıştırıyor, ifadeyi düzeltiyor veya en iyi çıktıyı seçiyorsa, bu bir özellik değil—otomatikleştirmeniz gereken bir iş akışıdır.

Beklentileri ayarlamak: zamanlama ve sonraki adımlar

Üretime geçmek UI'yi cilalamakla ilgili değildir. Bir AI davranışını güvenilir bir ürün yeteneği haline getirmekle ilgilidir.

Pratik bir kural: özellik müşteri kararlarını etkiliyorsa, özel veriye dokunuyorsa veya bunu temel bir metrik gibi ölçecekseniz, zihniyetinizi “promptlama”dan bir AI sistemi mühendisliğine çevirin—açık başarı kriterleri, değerlendirme, izleme ve güvenlik kontrolleri ile.

Hızla inşa ediyorsanız, Koder.ai gibi platformlar fikri çalışır bir uygulamaya daha hızlı taşımanıza yardımcı olabilir (web için React, backend Go + PostgreSQL, mobil için Flutter). Önemli olan bu hızı prototip avantajı olarak görmek—üretim sertleştirmesini atlama bahanesi değil. Kullanıcılar buna güvenmeye başladığında, yine de aşağıda özetlenen güvenilirlik, güvenlik ve operasyon kontrollerine ihtiyacınız olacak.

Prototipten çıktığınızı gösteren 5 tetikleyici

Prototip öğrenme içindir: “Bu işe yarıyor mu ve kullanıcılar önemsiyor mu?” Üretim güven içindir: “Buna her gün, gerçek sonuçlarla güvenebilir miyiz?” Bu beş tetikleyici üretime geçmeniz gerektiğinin en açık sinyalleridir.

1) Kullanıcı sayısı (veya kullanım sıklığı) artmaya başlar

Günlük aktif kullanıcılar, tekrar eden kullanım veya müşteri karşısında görünürlük artıyorsa, yanlış, yavaş veya kullanılamaz olduğunda etkilenecek kişi sayısını—patlama yarıçapınızı—artırmışsınızdır.

Karar noktası: büyüme sorunları sizin düzeltebilme kabiliyetinizi geçmeden önce güvenilirlik için mühendislik zamanı ayırın.

2) İş, çıktılara bağımlı hale gelir

Ekipler AI sonuçlarını müşteri e-postalarına, sözleşmelere, kararlara veya finansal raporlara kopyaladığında, hatalar gerçek maliyetlere dönüşür.

Sorun: Bu özellik 24 saat kapalıysa ne kırılır? Cevap “temel iş akışı durur” ise, artık prototip değildir.

3) Uyumluluk, gizlilik veya güvenlik gereksinimleri ortaya çıkar

Düzenlenen veriler, kişisel veriler veya müşteri gizli bilgileriyle ilgilenmeye başladığınız anda resmi kontroller (erişim, saklama, tedarikçi incelemesi, denetim izi) gerekir.

Karar noktası: hangi verilerin gönderildiğini, saklandığını ve kaydedildiğini kanıtlayana kadar genişlemeyi durdurun.

4) Kontrolünüz dışındaki değişiklikler davranışı etkilemeye başlar

Küçük prompt düzenlemeleri, araç değişiklikleri veya model sağlayıcı güncellemeleri çıktıları bir gecede değiştirebilir. “Dün çalışıyordu” dediğiniz olduysa, sürümlendirme, değerlendirme ve geri alma planlarına ihtiyacınız var.

5) Sürüklenme (drift) ortaya çıkar: yeni kullanıcılar, yeni içerik, yeni hata modları

Girdiler değiştikçe (mevsimsellik, yeni ürünler, yeni diller) doğruluk sessizce düşebilir.

Karar noktası: başarı/başarısızlık metriklerini tanımlayın ve ölçeceğiniz etki öncesinde bir izleme tabanı belirleyin.

Pratik sinyaller: Kullanıcı, İş ve Mühendislik

Bir prototip “yeterince iyi” hissi verebilir—ta ki gerçek kullanıcıları, gerçek parayı veya gerçek operasyonları etkilemeye başlayana kadar. Üretime geçiş genellikle tek bir metriğin tetiklemesiyle olmaz—üç yönden gelen sinyallerin bir desenidir.

Kullanıcı güveni sinyalleri

Kullanıcılar sistemi oyuncak olarak gördüğünde kusurlar tolere edilir. Güvenmeye başladıklarında küçük hatalar maliyetli hale gelir.

Şuna dikkat edin: yanlış veya tutarsız cevaplar hakkında şikayetler, sistemin neleri yapıp yapamayacağı konusunda kafa karışıklığı, tekrar eden “hayır, demek istediğim bu değil” düzeltmeleri ve artan destek talepleri. Özellikle güçlü bir sinyal, kullanıcıların geçici çözümler geliştirmesidir ("her zaman üç kere yeniden ifade ediyorum")—bu gizli sürtünme benimsemeyi sınırlar.

İş sinyalleri

İş anı, çıktı gelirinizi, uyumluluğu veya müşteri taahhütlerini etkilemeye başladığında gelir.

İzlenecekler: müşteri SLA talebi, satışın özelliği farklılaştırıcı olarak konumlandırması, ekiplerin sistemi teslim tarihlerine ulaşmak için kullanması veya liderliğin öngörülebilir performans ve maliyet beklemesi. “Geçici” ifadesi temel bir iş akışının parçası olduysa, sistem hazır olsun veya olmasın siz zaten üretimdesiniz.

Mühendislik sinyalleri

Mühendislik ağrısı genellikle teknik borcun ödendiğinin en net göstergesidir.

Dikkat edin: hatalardan sonra yapılan manuel düzeltmeler, acil durum kaldıraçı olarak prompt düzenlemeleri, bir API değiştiğinde bozulan kırılgan bağ kodu ve tekrarlanabilir değerlendirme eksikliği (“dün çalışıyordu”). Eğer sadece bir kişi sistemi ayakta tutabiliyorsa, bu ürün değil—canlı bir demodur.

Sinyalleri eyleme dönüştürmenin basit yolu

Gözlemleri somut sertleştirme işlerine dönüştürmek için hafif bir tablo kullanın:

Bu tabloyu gerçek örneklerle doldurabiliyorsanız, muhtemelen prototipi aştınız ve üretim adımlarını planlamaya hazırsınız.

Üretim Düzeyinde Başarı ve Başarısızlık Kriterleri Belirleyin

Prototip birkaç demoda işe yaradığı için “yeterince iyi” gelebilir. Üretim farklıdır: güvenle göndermenizi sağlayan ve risk yüksek olduğunda göndermemenizi sağlayan net geçme/kalma kurallarına ihtiyacınız var.

Başarıyı iş terimleriyle tanımlayın

3–5 ölçülebilir metrikle başlayın; his yerine gerçek değeri yansıtan metrikler olsun. Tipik üretim metrikleri:

• Doğruluk / görev başarı oranı (kullanıcı doğru sonuca ulaştı mı?)
• Görev başına kazandırılan zaman (eski iş akışına göre dakikalar kazancı)
• Görev başına maliyet (model + araç maliyeti)
• Kullanıcı memnuniyeti (CSAT, onay oranı veya "tekrar kullanır mısınız?")

Hedefleri haftalık ölçülebilir olarak belirleyin. Örneğin: “eval set’te ≥%85 görev başarı ve iki hafta sonra ≥4.2/5 CSAT.”

Başarısızlık metrikleri ve “olmaması gereken” kurallar

Başarısızlık kriterleri de eşit derecede önemlidir. LLM uygulamaları için yaygın olanlar:

• Zararlı çıktı oranı (politika ihlalleri, taciz, güvensiz tavsiye)
• Red oranı (geçerli istekleri ne sıklıkla reddediyor)
• Halüsinasyon oranı (kesin ama yanlış iddialar, uydurulmuş alıntılar, uydurulmuş eylemler)

Açık olmaması gereken kurallar ekleyin (ör. “PII ifşa etmeyecek”, “iadeleri uydurmayacak”, “gerçekleştirilmemiş eylemleri gerçekleştirdiğini iddia etmeyecek”). Bu durumlar otomatik bloklama, güvenli fallback ve olay incelemesini tetiklemelidir.

Değerlendirme setini ve sahibini belgeleyin

Şunları yazın:

• Değerlendirme veri setleri (altın cevaplar, uç durumlar, red-team promptları)
• Nasıl sürümlendiği ve güncellendiği
• Sahiplik: olaylar, destek ticket’ları veya ürün değişikliklerinden sonra yeni vakaları kim ekler

Eval setini bir ürün varlığı gibi ele alın: sahibi yoksa kalite sürüklenir ve hatalar sizi şaşırtır.

Güvenilirlik: Gecikme, Çalışma Süresi ve Fallback Planları

Bir prototip bir insan izlerken “yeterince iyi” olabilir. Üretim ise kimse izlemediğinde bile öngörülebilir davranış gerektirir—özellikle kötü günlerde.

Güvenilirlik pratikte ne demektir

Çalışma süresi (uptime) özelliğin erişilebilir olup olmadığını gösterir. Müşteri odaklı bir AI asistanı için genelde net bir hedef istersiniz (ör. “ayda %99.9”) ve “kapalı” sayılacak durumun tanımını (API hataları, zaman aşımı veya kullanılamaz yavaşlamalar).

Gecikme (latency) kullanıcının ne kadar beklediğidir. Sadece ortalamayı değil, yavaş tail’i (p95/p99) izleyin. Yaygın bir üretim deseni, sert bir zaman aşımı ayarlamak (ör. 10–20 saniye) ve sonra ne olacağına karar vermektir—çünkü sonsuza kadar beklemek kontrollü bir fallback almaktan daha kötüdür.

Zaman aşımı yönetimi şunları içermelidir:

• açık bir kullanıcı mesajı (“Hâlâ çalışıyor…” vs. “Tekrar deneyin”)
• güvenli yeniden denemeler (aynı pahalı isteği üç kez çalıştırmamak)
• bir circuit breaker (model sağlayıcısı başarısızsa, sürekli istek göndermeyi durdurmak)

Güveninizi koruyan fallback davranışları

Bir ana yol ve en az bir fallback planlayın:

• Önbelleğe alınmış cevaplar: sık sorulan sorular için (örn. “Çalışma saatleriniz nedir?”) sağlayın, böylece sağlayıcı sorununda bile anında cevap verilebilir.
• Daha basit/ucuz bir model: en iyi model yetersizse yönlendirme yapın.
• İnsan devri: yüksek riskli akışlar (faturalandırma, tıbbi, hesap erişimi) veya güven düşükse insan müdahalesi.

Buna kademeli bozulma (graceful degradation) denir: deneyim bozulmaz, basitleşir. Örnek: “tam” asistan belgeleri zamanında çekemiyorsa, kısa bir cevapla en iyi kaynaklara bağlantı sunar ve yükseltme önerir—hata döndürmek yerine.

Kota, eşzamanlılık ve kuyruklar (basitçe)

Güvenilirlik aynı zamanda trafik kontrolüne de bağlıdır. Rate limit ani dalgaların her şeyi çökertmesini önler. Concurrency aynı anda kaç isteği işlediğinizdir; çok yüksek olursa herkes için yanıtlar yavaşlar. Kuyruklar isteklerin hemen başarısız olmasını engelleyip kısa süre bekleterek ölçeklenme veya fallback için zaman kazandırır.

Güvenlik ve Gizlilik: Lansmandan Önce Doğru Olması Gerekenler

Prototip gerçek müşteri verilerine dokunuyorsa “sonra düzeltiriz” seçeneği artık geçerli değildir. Lansmandan önce AI özelliğinin hangi verileri görebileceğinin, nereye gittiğinin ve kimlerin erişebildiğinin net bir resmi olmalıdır.

Hassas veri akışlarını baştan sona haritalayın

Basit bir diyagram veya tabloyla her veri yolunu takip edin:

• Girdiler: promptlar, sohbet geçmişi, yüklenen dosyalar, yapıştırılan ekran görüntüleri, form alanları
• Tanımlayıcılar: kullanıcı kimlikleri, e-postalar, hesap numaraları, cihaz kimlikleri, IP adresleri
• Çıktılar: model yanıtları, alıntılar, oluşturulan dosyalar
• Depolama/telemetri: loglar, analiz olayları, hata izleri, destek ticket’ları
• Üçüncü taraflar: model API’leri, vektör veritabanları, arama/araçlar, moderasyon hizmetleri

Amaç bilinmeyen hedefleri ortadan kaldırmaktır—özellikle loglarda.

Uygulamanız gereken gizlilik temel kuralları

• Veri minimizasyonu: yalnızca özellik için gerekeni toplayın. “İhtimale karşı” tüm kaydı prompta dökmekten kaçının.
• Saklama kuralları: promptlar, dosyalar ve çıktılar ne kadar tutulacak belirleyin. Kullanıcı/hesap bazında silmeyi kolaylaştırın.
• Erişim kontrolü: konuşmaları ve ekleri kimlerin görebileceğini sınırlayın (mühendislik, destek, tedarikçiler). En az ayrıcalık ve denetlenebilir erişim kullanın.
• Kırpma (redaction): loglardan varsayılan olarak sırlar ve PII scrub edin (API anahtarları, tokenler, e-postalar, adresler). Promptları potansiyel olarak hassas kabul edin.

Açıkça hafifletmeniz gereken tehditler

• Prompt enjeksiyonu: kullanıcıların (veya getirilen içeriğin) talimatları ezmeye ve gizli verileri çıkarmaya çalışabileceğini varsayın.
• Veri sızması: modelin diğer kullanıcıların içeriğini, sistem promptlarını veya dahili araçları ifşa etmesini önleyin.
• Güvensiz araç çağrıları: ödemeler, silmeler, dışa aktarmalar gibi eylemleri kısıtlayın. Onay, allowlist ve sınırlı izinler gerektirin.

Hafif bir güvenlik inceleme kontrol listesi (kopyala/yapıştır)

• Veri akışı dokümante edildi (girdiler, depolama, tedarikçiler, loglar)
• Loglar ve analizlerde PII/sırlar kırpıldı
• Saklama + silme politikası uygulandı
• Tedarikçi koşulları ve veri kullanımı doğrulandı (eğitim, depolama, bölge)
• Prompt enjeksiyon savunmaları (araç allowlistleri, içerik sınırları, “asla ifşa etme” kuralları test edildi)
• Araç izinleri kullanıcı bazında sınırlandırıldı; yüksek riskli eylemler gate’lendi
• Kötüye kullanım izleme + olay planı (kim müdahale eder, özelliği nasıl devre dışı bırakırsınız)

Bu kontrol listesini bir yayın kapısı olarak kullanın—her seferinde çalıştırılacak kadar küçük, sürprizleri önleyecek kadar sıkı.

Test ve Değerlendirme: Demo Promptlarından Regresyon Süitlerine

Bir prototip genellikle birkaç dostça prompt yüzünden “çalışıyor” görünür. Üretim farklıdır: kullanıcılar dağınık, belirsiz sorular soracak, hassas veriler ekleyecek ve tutarlı davranış bekleyecektir. Bu, klasik birim testlerinin ötesinde testler gerektiği anlamına gelir.

Birim testleri hâlâ önemli (API sözleşmeleri, auth, girdi doğrulama, önbellekleme), ama bunlar modelin yardımcı, güvenli ve doğru kalıp kalmayacağını göstermez.

Çevrimdışı değerlendirme: yeniden çalıştırılabilir bir gold set oluşturun

Küçük bir gold set ile başlayın: 50–300 temsilci sorgu ve beklenen sonuçlar. “Beklenen” her zaman tek bir mükemmel cevap anlamına gelmez; bir rubrik de olabilir (doğruluk, ton, alıntı gereksinimi, reddetme davranışı).

İki özel kategori ekleyin:

• Regresyon testleri: daha önce başarısız olmuş anonimleştirilmiş gerçek kullanıcı soruları, eski hataların geri gelmemesini sağlamak için
• Red-team promptları: düşmanca girdiler (prompt enjeksiyonu, politika atlatma, hassas veri çıkarma, güvensiz talimatlar). Bunlar güvenlik birim testlerinizdir.

Bu süiti her anlamlı değişiklikte çalıştırın: prompt düzenlemeleri, araç yönlendirme mantığı, retrieval ayarları, model yükseltmeleri ve sonrası işlemler.

Çevrimiçi değerlendirme: gerçek trafikle güvenli kanıtlayın

Çevrimdışı skorlar yanıltıcı olabilir, bu yüzden kontrollü yayılma desenleriyle üretimde doğrulayın:

• Shadow mode: yeni sürüm paralel çalışır ve çıktıları loglar; kullanıcılar eski sürümü görür.
• Canary yayınları: trafiğin %1–5’i yeni sürüme gider, sıkı izleme ve anında geri alma ile.
• A/B testleri: etkileri görev tamamlama, çözüm süresi, insan müdahalesi oranı gibi kullanıcı sonuçlarında ölçün.

Prompt/model değişikliklerini onaylama (hafif ama sıkı)

Basit bir kapı tanımlayın:

1. Değişiklik talebi niyeti, örnek promptları ve risk notlarını içermeli.
2. Çevrimdışı gold set ve red-team eşiklerini geçmeli.
3. Canary veya shadow sonuçları kısa bir metrik kontrol listesine karşı incelenmeli.
4. Son onay bir sahibi tarafından verilmeli (ürün + mühendislik, yüksek riskli özelliklerde güvenlik de).

Bu süreç “demoda daha iyi görünüyordu”yü tekrarlanabilir bir sürüm sürecine dönüştürür.

Gözlemlenebilirlik: Loglama, İzleme ve Alarm

Gerçek kullanıcılar AI özelliğine güvenmeye başlayınca, temel soruları hızlıca yanıtlamanız gerekir: Ne oldu? Ne sıklıkla? Kime? Hangi model sürümü? Gözlemlenebilirlik yoksa her olay tahmine dönüşür.

Ne loglanmalı (sırları toplamadan)

Davranışı yeniden oluşturacak kadar ayrıntı loglayın ama kullanıcı verisini radyoaktif kabul edin.

• Girdiler ve çıktılar: hassas alanları maskelenmiş şekilde prompt ve yanıtları saklayın. Saklanamıyorsa hash, özet veya güvenli alıntılar kullanın.
• Model ve konfigürasyon: model adı, sağlayıcı, temperature, max tokens, sistem prompt sürümü, embeddings indeks sürümü—davranışı değiştiren her şey.
• Araç eylemleri: hangi araçların çağrıldığı (arama, veritabanı, takvim, ödemeler), maskelenmiş parametreler, yanıt kodları ve zamanlamalar.
• Karar noktaları: guardrail sonuçları (bloklandı/izin verildi), politika eşleşmeleri, fallback yolu ve insan devri bilgisi.

Yardımcı bir kural: davranışı açıklıyorsa logla; özelse maskele; gerek yoksa saklama.

Fayda sağlayan panolar

Sağlık durumunu çabucak gösteren küçük bir pano seti hedefleyin:

• Hata oranı: başarısız araç çağrıları, zaman aşımı, ayrıştırma hataları, “cevap veremiyor” oranı
• Gecikme: p50/p95 uçtan uca ve araç başına gecikme
• Maliyet: istek başı token, kullanıcı/oturum başı maliyet ve sürümlerde maliyet sıçramaları
• Kalite vekilleri: onay/ret oranı, “kullanıcı hemen yeniden ifade etti”, insan devrine yükseltme oranı

Kalite tek bir metrikle ölçülemez; birkaç vekili birleştirip örnekleri inceleyin.

Alarm: kim çağrılır, ne ticket olur

Her dalgalanma birini uyandırmamalı.

• Acil (page): kullanıcılar bloke olduğunda veya zarar riski olduğunda: sürekli yüksek hata oranı, büyük gecikme regresyonu, araçların yetki hataları, güvenlik filtresi hata.
• Ticket (iş günü içinde): temel akışı bozmayacak bozulmalar: hafif kalite düşüşü, küçük maliyet kaymaları.

Eşikleri ve minimum süreyi (örn. “10 dakikayı aşan” gibi) tanımlayın ki gürültülü alarmlar olmasın.

Kullanıcı geri bildirim döngülerini sorumlu şekilde yönetme

Geri bildirim altın değerindedir ama kişisel verileri sızdırabilir veya önyargıları güçlendirebilir.

• Geri bildirimi kimlikten ayrı saklayın; ham kişisel detay yerine referans ID tutun.
• Eğitime almadan önce inceleyin: geri bildirimi temizleme, de-dup ve önyargı kontrollerinden geçirin.
• Şeffaf olun: kullanıcılara geri bildirimin nasıl kullanılacağını ve nasıl çıkış yapabileceklerini söyleyin.
• Döngüyü kapatın: geri bildirimi model/sürüm ile etiketleyin ki değişikliğin sorunu çözüp çözmediğini doğrulayabilesiniz.

İyi olmanın ne demek olduğu konusunda hizalanmak isterseniz, bunu üretim başarı kriterleriyle eşleştirin (bkz. /blog/set-production-grade-success-and-failure-criteria).

Operasyonel Hazırlık: Sürümleme, Yayınlar ve Geri Alma

Bir prototip "geçen haftaki ne çalıştıysa o" diyebilir. Üretim edilemez bir şey değildir. Operasyonel hazırlık, değişiklikleri güvenli, izlenebilir ve geri alınabilir hale getirmektir—özellikle davranışınız promptlara, modellere, araçlara ve verilere bağlıysa.

Davranışı değiştiren her şeyi sürümlendirin

LLM uygulamalarında “kod” sistemin yalnızca bir parçasıdır. Bunları birinci sınıf, sürümlenmiş varlıklar olarak ele alın:

• Promptlar ve şablonlar (sistem mesajları, araç talimatları, few-shot örnekleri dahil)
• Modeller ve parametreler (model adı, temperature, max tokens, fonksiyon/araç şemaları)
• Embeddings ve retrieval ayarları (embedding modeli, chunk stratejisi, top-k, filtreler)
• Veri setleri ve bilgi kaynakları (dokümanlar, etiketler, eval setleri, red-team promptları)
• Araçlar ve entegrasyonlar (API sözleşmeleri, izinler, rate limitler)

Şu soruyu cevaplayabilecek hale getirin: “Bu çıktıyı üreten tam prompt + model + retrieval konfigürasyonu hangisiydi?”

Yapıları tekrarlanabilir kılın

Tekrar üretilebilirlik ortam değiştiğinde ortaya çıkan hayalet hataları azaltır. Bağımlılıkları pin’leyin (lockfile), çalışma zamanı ortamlarını kaydedin (container görüntüleri, OS, Python/Node sürümleri) ve gizli/config’i koddan ayrı tutun. Yönetilen model endpoint’leri kullanıyorsanız, sağlayıcı, bölge ve mevcutsa tam model sürümünü loglayın.

Gerçek bir yayın akışı kullanın

Basit bir pipeline benimseyin: dev → staging → production, net onaylarla. Staging, üretime olabildiğince benzemeli (veri erişimi, rate limitler, gözlemlenebilirlik) ve güvenli test hesapları kullanmalıdır.

Prompt veya retrieval ayarlarını değiştirdiğinizde bunu hızlı bir düzenleme gibi değil, bir yayın olarak ele alın.

Geri almayı önceden planlayın

Bir olay playbook’u oluşturun:

• Geri alma adımları (önceki prompt/model/konfig; feature flag kapatma)
• Sahip rolleri (kim karar verir, kim uygular, kim iletişim kurar)
• Tetikleyiciler (hata oranları, maliyet sıçraması, zararlı içerik, destek hacmi)

Geri alma zorsa, yayın süreciniz değil şansıdır.

Eğer hızlı geliştirme platformu kullanıyorsanız, tersinirliği kolaylaştıran operasyonel özelliklere bakın. Örneğin Koder.ai snapshot ve rollback, dağıtım/barındırma ve özel domain desteği gibi kolay geri almayı sağlayan primitive’ler sunar—canary sırasında hızlı, düşük riskli sürümler için faydalıdır.

Maliyet ve Performans: Ölçeklenmeden Önce Bütçeleme

Prototip düşük kullanımda "ucuz" gelebilir ve hatalar tolere edilebilir. Üretim ise tersine döner: demo sırasında birkaç dolara mal olan bir prompt zinciri, binlerce kullanıcı günlük olarak kullandığında önemli bir satır haline gelebilir.

Harcamayı gerçekten ne belirler bilmeniz gerekir

Çoğu LLM maliyeti kullanım odaklıdır. En büyük sürücüler:

• Tokenlar: uzun sistem promptları, ayrıntılı çıktılar, çok turlu sohbetler
• Araç çağrıları: web aramaları, kod çalıştırma, veritabanı sorguları, ücretli API’ler
• Retrieval: embedding oluşturma, vektör DB okumaları, büyük belgelerin getirilmesi
• Yeniden denemeler: zaman aşımı, model hataları, “tekrar dene” döngüleri
• Uzun bağlamlar: her isteğe tüm geçmişi veya belgeleri göndermek

Maliyetleri ürün terimleriyle koyun

Bütçeleri iş modelinize bağlayın, sadece “aylık harcama” değil. Örnekler:

• İstek başı maliyet (ör. ort. $0.02, p95 $0.10)
• Aktif kullanıcı başı günlük maliyet
• İş akışı başı maliyet (örn. “rapor oluştur” $0.50 altı olmalı)

Basit kural: tek bir istek izi üzerinden maliyeti tahmin edemiyorsanız, onu kontrol edemezsiniz.

Kaliteyi bozmayacak optimizasyon kolları

Küçük değişiklikleri birleştirerek anlamlı tasarruf elde edersiniz:

• Önbellekleme: tekrarlanan sorular ve deterministik araç sonuçları için
• Kesme & özetleme: modele yalnızca gerekli olanı verin (geçmişi özetleyin)
• Küçük modeller: “kolay” işleri ucuz modellere yönlendir, zorlu vakaları büyük modellere ayır
• Batching: gecikme izin veriyorsa embedding veya öğe işleme toplu yapma

Sürpriz faturaları önleyin

Kontrolsüz davranışa karşı guardrail ekleyin: araç çağrı sayısını sınırla, yeniden deneme limitleri koy, max tokens uygula ve ilerleme durduğunda döngüyü durdur. Maliyeti izleme ilk seviye metrik yapın ki finans sürprizleri güvenilirlik olayına dönüşmesin (bkz. /blog/observability-basics).

İnsanlar ve Süreç: Sahiplik, Destek ve Yönetişim

Üretim yalnızca teknik bir kilometre taşı değildir—organizasyonel bir taahhüttür. Gerçek kullanıcılar bir AI özelliğine güvendiği anda net sahiplik, bir destek yolu ve sistemin “kimsenin işi değil” haline gelmemesi için yönetişim döngüsü gerekir.

Kimin neye sahip olduğunu tanımlayın

Rolleri adlandırarak başlayın (bir kişi birden fazla rolü üstlenebilir ama sorumluluklar açık olmalı):

• Ürün sahibi: kullanıcı için neyin “iyi” olduğunu belirler, düzeltmeleri ve özellikleri önceliklendirir, davranış değişikliklerini onaylar
• ML/AI sahibi: model seçimi, prompt değişiklikleri, değerlendirme sonuçları ve genel AI kalitesinden sorumludur
• Güvenlik sahibi: veri işleme, erişim kontrolleri, üçüncü taraf hizmetler ve olay müdahale hazırlığını gözden geçirir
• Destek lideri: ticket, yükseltmeler ve kullanıcı takibi iş akışını yönetir
• Hukuk/uyumluluk ortağı: kullanıcıya yönelik iddiaları, feragatnameleri ve düzenlenen veri işlemlerini onaylar

Destek modelini belirleyin

Gönderim öncesi sorunları kimin aldığını, neyin “acil” olduğunu ve kimlerin özelliği durdurabileceğini belirleyin. Bir yükseltme zinciri tanımlayın (destek → ürün/AI sahibi → gerekirse güvenlik/hukuk) ve yüksek etkili hatalar için beklenen yanıt sürelerini belirleyin.

Kullanıcılarla erken iletişim kurun

Kısa, sade yönergeler yazın: AI’nin neleri yapıp yapamayacağı, yaygın hata modları ve kullanıcı yanlış görürse ne yapacağı. Kararların yanlış anlaşılabileceği yerlerde görünür feragatnameler ekleyin ve kullanıcıların sorun bildirebileceği bir yol verin.

Değişiklik yönetimi ritmi belirleyin

AI davranışı geleneksel yazılımdan daha hızlı değişir. Olayları gözden geçirmek, prompt/model değişikliklerini denetlemek ve kullanıcıya etki eden güncellemeleri yeniden onaylamak için düzenli bir periyot (ör. aylık) belirleyin.

Basit Bir Yol Haritası: Nasıl Sertleştirip Güvenli Lansman Yaparsınız

İyi bir üretim lansmanı genellikle sakin, aşamalı bir yayın sonucudur—kahramanca "gönder" anı değil. İşte demodan güvenilir bir şeye geçiş için pratik bir yol.

Adım 1: Prototip → “Gerçeği Arama”

Prototipi esnek tutun, ama gerçeği kaydetmeye başlayın:

• AI’nin yapması gereken tek işi yazın (ve ne yapmaması gerektiğini)
• Gerçek kullanıcı girdilerinden küçük bir set toplayın (izinli) ve "iyi"nin ne olduğunu etiketleyin
• Temel çıktıları takip edin: yardımcı/yardımcı değil, güvenli/tehlikeli, doğru/yanlış

Adım 2: Pilot → “Kontrollü maruziyet”

Pilot, bilinmeyenleri azaltma yeridir:

• Sınırlı bir kohorta açın (örn. %1–5 kullanıcı veya bir iç ekip)
• Özelliği feature flag arkasına koyun ki dağıtım yapmadan kapatabilesiniz
• AI yolunu anında kapatan bir kill switch ekleyin ve test edin
• Operatör kuralları tanımlayın: ne zaman insana yükseltilir, ne zaman engellenir, olaylara nasıl yanıt verilir

Adım 3: Üretim → “Tekrarlanabilir operasyon”

Ancak bir ürün gibi çalıştırabildiğinizde genişletin, bilim projesi gibi değil:

• Trafiği kademeli artırın (5% → 25% → 50% → 100%) ve her adımda go/no-go kontrolü yapın
• Yayınları geri alınabilir yapın: küçük değişikliklerle gönderin, izleyin, hazır olun
• Sabit test setinize karşı periyodik değerlendirmeler çalıştırın ki kalite sürüklenmesin

Hazırlık kontrol listesi (kısa özet)

Genişletmeden önce onaylayın:

• Açık, ölçülebilir başarı/başarısızlık kriterleri yazılı
• Feature flag ve kill switch test edilmiş
• Fallback davranışı kullanıcılar ve destek için kabul edilebilir
• Temel riskler kapsanmış: gizlilik, prompt enjeksiyonu, hassas veri işlemleri
• İzleme yanıt veriyor: “Çalışıyor mu? Güvenli mi? Kötüleşiyor mu?” sorularına cevap veriyor
• Üretimde bir sahibi var (on-call, olay playbook, yükseltme yolu)

Paketleme ve yayın seçeneklerini planlamak isterseniz, daha sonra /pricing veya destekleyici rehberlere bakabilirsiniz.