19 Haz 2025·8 dk
AI Prototipleri Üretime Hazır Olduğunda: Belirtiler ve Sonraki Adımlar
AI prototipinizin üretime hazır olduğunu gösteren sinyalleri ve sertleştirme adımlarını öğrenin: güvenilirlik, güvenlik, izleme, test ve yayılım.
AI prototipinizin üretime hazır olduğunu gösteren sinyalleri ve sertleştirme adımlarını öğrenin: güvenilirlik, güvenlik, izleme, test ve yayılım.
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?”
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.
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.
Ü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.
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.
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.
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.
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.
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.
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.
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ı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.
İş 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 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.
Gözlemleri somut sertleştirme işlerine dönüştürmek için hafif bir tablo kullanın:
| Sinyal | Risk | Gerekli sertleştirme adımı |
|---|---|---|
| Yanlış cevaplar için artan destek talepleri | Güven erozyonu, churn | Koruyucular ekle, değerlendirme setini iyileştir, UX beklentilerini netleştir |
| Müşteri SLA talebi | Sözleşme riski | Çalışma süresi/gecikme hedefleri tanımla, izleme + olay süreci ekle |
| Haftalık prompt acil düzeltmeleri | Öngörülemez davranış | Promptları sürümlendir, regresyon testleri ekle, değişiklikleri kod gibi gözden geçir |
| Çıktıların manuel temizlenmesi | Operasyonel yük | Doğrulamayı otomatikleştir, fallback yollar ekle, veri işleme iyileştir |
Bu tabloyu gerçek örneklerle doldurabiliyorsanız, muhtemelen prototipi aştınız ve üretim adımlarını planlamaya hazırsınız.
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.
3–5 ölçülebilir metrikle başlayın; his yerine gerçek değeri yansıtan metrikler olsun. Tipik üretim metrikleri:
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 kriterleri de eşit derecede önemlidir. LLM uygulamaları için yaygın olanlar:
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.
Şunları yazın:
Eval setini bir ürün varlığı gibi ele alın: sahibi yoksa kalite sürüklenir ve hatalar sizi şaşırtır.
Bir prototip bir insan izlerken “yeterince iyi” olabilir. Üretim ise kimse izlemediğinde bile öngörülebilir davranış gerektirir—özellikle kötü günlerde.
Ç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:
Bir ana yol ve en az bir fallback planlayın:
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.
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.
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.
Basit bir diyagram veya tabloyla her veri yolunu takip edin:
Amaç bilinmeyen hedefleri ortadan kaldırmaktır—özellikle loglarda.
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ı.
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.
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:
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.
Çevrimdışı skorlar yanıltıcı olabilir, bu yüzden kontrollü yayılma desenleriyle üretimde doğrulayın:
Basit bir kapı tanımlayın:
Bu süreç “demoda daha iyi görünüyordu”yü tekrarlanabilir bir sürüm sürecine dönüştürür.
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.
Davranışı yeniden oluşturacak kadar ayrıntı loglayın ama kullanıcı verisini radyoaktif kabul edin.
Yardımcı bir kural: davranışı açıklıyorsa logla; özelse maskele; gerek yoksa saklama.
Sağlık durumunu çabucak gösteren küçük bir pano seti hedefleyin:
Kalite tek bir metrikle ölçülemez; birkaç vekili birleştirip örnekleri inceleyin.
Her dalgalanma birini uyandırmamalı.
Eşikleri ve minimum süreyi (örn. “10 dakikayı aşan” gibi) tanımlayın ki gürültülü alarmlar olmasın.
Geri bildirim altın değerindedir ama kişisel verileri sızdırabilir veya önyargıları güçlendirebilir.
İ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).
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.
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:
Şu soruyu cevaplayabilecek hale getirin: “Bu çıktıyı üreten tam prompt + model + retrieval konfigürasyonu hangisiydi?”
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.
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.
Bir olay playbook’u oluşturun:
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.
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.
Çoğu LLM maliyeti kullanım odaklıdır. En büyük sürücüler:
Bütçeleri iş modelinize bağlayın, sadece “aylık harcama” değil. Örnekler:
Basit kural: tek bir istek izi üzerinden maliyeti tahmin edemiyorsanız, onu kontrol edemezsiniz.
Küçük değişiklikleri birleştirerek anlamlı tasarruf elde edersiniz:
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).
Ü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.
Rolleri adlandırarak başlayın (bir kişi birden fazla rolü üstlenebilir ama sorumluluklar açık olmalı):
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.
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.
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.
İ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.
Prototipi esnek tutun, ama gerçeği kaydetmeye başlayın:
Pilot, bilinmeyenleri azaltma yeridir:
Ancak bir ürün gibi çalıştırabildiğinizde genişletin, bilim projesi gibi değil:
Genişletmeden önce onaylayın:
Paketleme ve yayın seçeneklerini planlamak isterseniz, daha sonra /pricing veya destekleyici rehberlere bakabilirsiniz.
Bir prototip hıza ve öğrenmeye odaklıdır: manuel, kırılgan olabilir ve kontrollü bir demo için "yeterince iyi" sayılabilir.
Üretim ise tekrarlanabilir sonuçlara odaklıdır: öngörülebilir davranış, gerçek verilerin güvenli işlenmesi, tanımlı başarı/başarısızlık kriterleri, izleme ve modeller/araçlar başarısız olduğunda devreye giren geri dönüş yolları gerektirir.
Aşağıdakilerden biri veya birkaçı ortaya çıktığında üretime geçiş tetiklenmiş sayılır:
Bu durumlardan herhangi biri geçerliyse, ölçeklemeden önce sertleştirme (hardening) çalışmalarını planlayın.
Demolar kaosu ve insan müdahalesini gizler.
Gerçek kullanıcılar uzun/belirsiz girdiler gönderecek, uç durumları deneyecek ve tutarlılık bekleyecek. Prototipler genellikle ölçeklendiğinde bozulacak varsayımlara dayanır (sabit gecikme, sınırsız kota, tek model sürümü veya birinin gizlice promptu yeniden çalıştırması). Üretimde o gizli insan müdahalesi otomasyona ve güvenlik önlemlerine dönüşmelidir.
Başarıyı iş terimleriyle tanımlayın ve haftalık olarak ölçülebilir hale getirin. Yaygın metrikler:
Açık hedefler koyun (ör. “eval set’te ≥%85 görev başarı ve iki hafta içinde ≥4.2/5 CSAT”).
“Olmaması gerekenler” kurallarını yazın ve otomatik uygulama ekleyin. Örnekler:
Zararlı çıktı, halüsinasyon ve uygunsuz red oranlarını izleyin. Kural tetiklendiğinde bloke, güvenli geri dönüş ve olay incelemesi başlatın.
Tekrar çalıştırılabilir bir çevrimdışı test setiyle başlayın, sonra üretimde doğrulayın:
Değişiklikleri shadow mode, canary veya A/B ile dikkatle yayınlayın ve eşiklerin geçilmesini şart koşun.
Kötü günleri de tasarlayın:
Amaç: rastgele hatalar değil, kademeli sadeleşme (graceful degradation).
Veri akışlarını baştan sona haritalayın ve bilinmeyenleri ortadan kaldırın:
Ayrıca prompt enjeksiyonu, kullanıcılar arası veri sızması ve tehlikeli araç çağrılarına karşı önlemler alın.
Olayı açıklamaya yetecek kadar ama gereksiz hassas veri içermeyecek şekilde kayıt tutun:
Sürekli hatalar/latency artışı, güvenlik filtresi ihlali veya maliyet sapanı gibi önemli durumlarda alarm verin; küçük düşüşleri ticket’a yönlendirin.
Aşamalandırılmış bir yayın planı ve geri alınabilirlik ile ilerleyin:
Geri alma zor veya sahip yoksa, hazır değilsiniz demektir.