# Tek ekipten birçok ekibe: bir kez işe yarayan yapay zeka sistemi nasıl yaygınlaştırılır?

> Bu saha notunda veridive, bir yapay zeka sistemini tek ekipten birçok ekibe taşımak için bir yaygınlaştırma planı sunuyor: her ekip için bir ön kontrol listesi, her ekibin vakalarının değerlendirme setine eklenmesi, yerel sahipler ve yapay zeka elçileri, her seferinde tek bir şeyi değiştiren bir sıra ve kopyalar yerine yerel ayarlarla çalışan tek bir ortak çekirdek.

İkinci ekip hiçbir zaman ilkinin kopyası değildir: vakaları, dili, sistemleri ve alışkanlıkları farklıdır. Başlangıç ölçümünü yenileyin, değerlendirme setini yeni ekibin vakalarıyla çalıştırın, yerel yapay zeka elçileri bulun ve kapsamı adım adım genişletin.

## Öne çıkanlar

- Her yeni ekip kendi vaka dağılımını, dilini, sistemlerini ve alışkanlıklarını getirir; yaygınlaştırmanın her adımını küçük bir pilot gibi ele alın.
- Bir ekip başlamadan önce başlangıç ölçümünü, vaka dağılımını, dilini, sistem farklarını, veri erişimini ve yerel sahibini kontrol edin.
- Canlıya geçmeden önce her ekibin vakalarını değerlendirme setine ekleyin; sonuçları ekibe ve vaka türüne göre raporlayın.
- Yerel ayarlarla tek bir ortak çekirdek tutun ve her seferinde tek bir şeyi değiştirin: vakaları, kanalı, dili ya da ülkeyi.

Pilot ekibi sistemi çok sevdi. Kararlar hızlandı, süreç sahibi onay verdi ve canlıya geçiş değerlendirmesi çabucak bitti. Sonra ikinci ekip devreye girdi ve müdahaleler birikti: farklı ürün grupları, daha eski bir sipariş sistemi ve aynı mesajda hem Türkçe hem İngilizce yazan müşteriler.

Sistemde bir sorun yoktu. Yalnızca bu ekibin işiyle hiç karşılaşmamıştı. İkinci ekip hiçbir zaman ilkinin kopyası değildir ve her fark, sistemin test edilmediği bir alandır. Bu yüzden iyi bir yapay zeka yaygınlaştırma (rollout) planı, bir dosyayı kopyalamaktan çok her ekip için kısa bir pilota benzer: Başlangıç ölçümünü yenileyin, değerlendirme setini yeni ekibin vakalarıyla yeniden çalıştırın, yerel yapay zeka elçileri bulun ve kapsamı adım adım genişletin.

## Bir ekipte işe yarayan sistem neden bir sonrakinde tökezler?

Çünkü kanıtı tek bir ekipten geldi. Değerlendirme seti, eşikler, promptlar ve inceleme rutini hep o ekibin işine göre ayarlandı. Bir sonraki ekipte genellikle dört şey farklıdır:

- **Vaka dağılımı.** Başka ürünler, başka müşteriler, başka sezonlar ve sistemin hiç görmediği vaka türleri.
- **Dil.** Türkçe, İngilizce, Arapça ya da bunların karışımı; farklı yazım alışkanlıkları, kısaltmalar ve isimlerle.
- **Sistemler.** Başka bir ERP kurulumu, farklı alanlar ve kodlar, daha eski bir entegrasyon, daha eksik veriler.
- **Alışkanlıklar.** Farklı bir inceleme kültürü, haftalık ritmi farklı bir yönetici, pilotta yer almış kimsenin olmaması.

Pilot, yaygınlaştırmanın göremeyeceği bir ilgi de gördü: yakındaki geliştiriciler, istekli bir süreç sahibi ve sistemin işe yaramasını isteyen gönüllüler. Bu ilgi varsayılamaz; yeniden kurulması gerekir.

## Her yeni ekip başlamadan önce neler kontrol edilmeli?

Her ekip için aynı kontrol listesini kullanın; boş kalan tek bir satır bile başlangıcı durdursun:

1. **Başlangıç ölçümü.** Hacim, vaka başına süre, hata oranı ve maliyet; pilottan ödünç alınmadan, bu ekip için ölçülmüş.
2. **Vaka dağılımı.** Hangi vaka türlerinin hangi oranlarda geldiği ve hangilerinin sistem için yeni olduğu.
3. **Dil.** Girdilerdeki ve çıktılardaki diller ile bu dillerde anadili düzeyinde inceleme yapabilecek kişiler.
4. **Sistem farkları.** Kurulumlar, alanlar, kodlar ve entegrasyonlar ile bunların arkasındaki verinin kalitesi.
5. **Veri erişimi.** Yetkiler, işleme yeri ve saklama süresi. Yeni bir tüzel kişilik ya da ülke, veri koruma görevliniz (DPO) için yurt dışına veri aktarımı dahil yeni sorular doğurur.
6. **Yerel sahip.** Bu ekipte iş akışının sahibi olan ve onayı verecek, adı belli bir kişi.

## Değerlendirme seti nasıl uyarlanır?

Yeni ekibin güncel vakalarından, zor olanlar dahil bir örneklem alın ve referans yanıtları ekibin kendi uzmanlarına yazdırın. Bu vakaları ekip ve dil etiketiyle ortak değerlendirme setine ekleyin ve seti canlıya geçmeden önce çalıştırın. Sonuçları hiçbir zaman tek bir karma sayı olarak değil, ekibe ve vaka türüne göre raporlayın.

> Bir değerlendirme seti yalnızca içerdiği vakalar adına konuşur.

Çıtayı geçemeyen vaka türleri insanlarda kalır ya da geçene kadar gölge modda çalışır. Bundan sonra her değişiklikte, tüm ekiplerin vakaları dahil setin tamamı çalıştırılır; böylece yeni ekip için yapılan bir düzeltme eskisini sessizce bozamaz.

## Yerelde kimler işin içinde olmalı?

Önce bu ekip için “iyi”yi tanımlayan ve onayı veren yerel sahip. Ayrılmış zamanı olan, iş arkadaşlarına yardım eden ve sorunları toplayan yerel yapay zeka elçileri. Yöneticiler de, çünkü ilk ekibi başarılı kılan rutinin (yeni çıktıyı her hafta isteyen bir yönetici) burada yeniden kurulması gerekir; nedenini [yapay zekanın yeni bir günlük rutin gerektirdiğini anlatan notumuz](https://veridive.com/tr/saha-notlari/yapay-zeka-benimseme-pratigi/) açıklıyor. Ardından entegrasyonlar için yerel BT ekibi, anadilinde inceleme yapabilecek kişiler ve ekip başka bir tüzel kişilikte ya da ülkedeyse veri korumadan sorumlu kişi.

Eğitim de pilottaki kuralı izler: bu ekibin kendi vakaları üzerinde, ekibin çalıştığı dilde kısa oturumlar. Bu tür bir pratik, [yapay zeka eğitimi ve dönüşüm](https://veridive.com/tr/hizmetler/yapay-zeka-egitimi-ve-donusum/) çalışmalarımızın özüdür.

## Ekipler, kanallar ya da ülkeler hangi sırayla katılmalı?

İşin pilota en çok benzediği yerden başlayın, sonra her seferinde tek bir şeyi değiştirin: ya yeni vakalar ya yeni bir kanal ya da yeni bir dil; asla üçü birden değil. Sonuçlar düştüğünde nedenini bilirsiniz.

Temsili bir vaka düşünün: Çevrimiçi iade ekibiyle pilotu yapılmış bir iade asistanı.

1. **Bir mağaza bölgesi.** Aynı politika, aynı sistemler. Yeni olan: mağazada açılan vakalar ve personelin çektiği fotoğraflar. Fotoğraf kalitesini ve mağaza rutininin inceleme adımına nasıl uyduğunu kontrol edin.
2. **Çağrı merkezi.** Yeni bir kanal. Vakalar temsilci notları olarak, daha az yapılandırılmış halde gelir ve yanıt müşteri beklerken gerekir. Vaka dağılımını, yanıt süresini ve inceleme adımının canlı bir görüşme sırasında işleyip işlemediğini kontrol edin.
3. **İkinci bir ülke.** Farklı bir dil karışımı: Arapça ve İngilizce, iki alfabede de yazılan isimler, yerel iade kuralları ve sipariş sisteminin başka bir kurulumu. Anadili düzeyinde inceleme yapacak kişileri, yerel politika kaynaklarını ve DPO’ya gidecek veri sorularını kontrol edin.

Her adımın değerlendirme setinde kendi vakaları, kısa bir gölge mod dönemi, ilk adımla aynı koşullara göre yapılan kendi canlıya geçiş değerlendirmesi ve ayrı raporlanan sonuçları olur. Bir sonraki adım, bir öncekinin oturmasını bekler.

## Birçok sürüm yerine tek bir sistem nasıl korunur?

Kopya değil, yapılandırma. Tek bir ortak çekirdek tutun: kod, promptların ortak bölümleri, değerlendirme araçları ve izleme. Her ekibe yerel ayarlar verin: dil, politika kaynakları, yönlendirme eşikleri, onay limitleri, kuyruk adları ve sistem bağlantıları. Ayarlar aynı kod deposunda durur ve kod gibi incelenir. Gösterge panelleri de aynı mantığı izler: Ekibe göre filtrelenen tek bir görünüm; böylece süreç sahipleri benzeri benzeriyle karşılaştırır.

Kopyalar daha hızlı görünür ama daha pahalıya gelir. Birinde yapılan düzeltme diğerlerine hiç ulaşmaz, değerlendirme setleri birbirinden uzaklaşır ve her model değişikliğinin defalarca test edilmesi gerekir. Ayrı bir sürüme ancak iş akışının kendisi farklıysa gidin; iadelerin yanında garanti talepleri gibi. O zaman bu, kendi sahibi ve kendi pilotu olan yeni bir iş akışıdır; [pilotun kavram kanıtından farkını](https://veridive.com/tr/saha-notlari/kavram-kaniti-pilot-mvp-farki/) ayrı bir notta anlattık.

## Bir sonraki ekip başlamadan önce ne yapılmalı?

Bir tarih açıklamadan önce bir sonraki ekibiniz için altı maddelik kontrol listesini doldurun ve önce o ekibin vakalarını değerlendirme setine ekleyin. Her adım, ilk adımla aynı [canlıya geçiş koşullarını](https://veridive.com/tr/saha-notlari/yapay-zeka-pilottan-canliya-gecis/) geçmelidir; bu koşulları [nasıl çalıştığımızı anlatan sayfada](https://veridive.com/tr/nasil-calisiyoruz/) da bulabilirsiniz. Sistem yayılırken ekibinizin yanında bir ekip isterseniz, aylık Yerleşik Yapay Zeka Ekibi modeliyle sunduğumuz [yapay zeka güvenilirliği](https://veridive.com/tr/hizmetler/yapay-zeka-guvenilirligi/) hizmeti izlemeyi, regresyon testlerini ve bir sonraki iyileştirmeleri üstlenir.

## Sık sorulan sorular

### Bir yapay zeka sistemi daha fazla ekibe nasıl yaygınlaştırılır?

Her yeni ekibi kısa bir pilot gibi ele alın. Ekibin kendi başlangıç ölçümünü yapın; vaka dağılımını, dillerini, sistemlerini ve veri erişimini kontrol edin ve yerel bir sahip belirleyin. Gerçek vakalarını değerlendirme setine ekleyip canlıya geçmeden önce test edin, yerel yapay zeka elçileri bulun ve sonuçları ekip bazında raporlayarak kapsamı adım adım genişletin.

### Her ülke ya da ekip için yapay zeka sisteminin ayrı bir sürümü mü olmalı?

Genellikle hayır. Kopyalar zamanla birbirinden uzaklaşır: Birinde yapılan düzeltme diğerlerine ulaşmaz, değerlendirme setleri ayrışır ve maliyetler katlanır. Kodu, değerlendirme araçlarını ve izlemeyi içeren tek bir ortak çekirdek tutun; dil, politikalar, kaynaklar, eşikler ve bağlantılar için yerel ayarlar kullanın ve her değişikliği tüm ekiplerin vakalarıyla test edin. Ayrı bir sistemi ancak iş akışının kendisi farklıysa kurun.