TEMSİLÎ VAKA · LOJİSTİK
Sevkiyat bildirimlerinde şablon dışı metin üretimi
Sevkiyat durumundaki değişiklikler müşteriye operasyon temsilcileri tarafından elle yazılıyordu. Sabit şablon vardı ama yetersiz olduğu için herkes esnetiyordu: bir temsilci sebebi hiç yazmıyor, diğeri 'yarın kesin teslim' gibi taahhüt veriyor, üçüncüsü gecikmenin sorumluluğunu üstlenen bir cümle kuruyordu. Aynı olay tipinde müşteriye giden metin temsilciye göre değişiyordu ve bu metinlerin hiçbiri sonradan denetlenebilir biçimde saklanmıyordu. Bir şikâyet geldiğinde 'bu cümleyi kim, hangi bilgiyle yazdı' sorusunun cevabı yoktu.
Beklenen etki
- İzlenebilirlik
- Gönderilen her metnin kaydında istem sürümü, model sürümü ve dayandığı olay verisi bulunuyor
- Ölçüm
- Doğrulama kapısının reddettiği çıktı sınıfları ve şablona geri dönüş sebepleri ayrı izleniyor
- Karar sınırı
- Hasar, gümrükte bekleme ve iptal bildirimleri her zaman temsilci onayından geçiyor; risk sınıfı olay tipinden geliyor, modele sorulmuyor
- Veri sınırı
- Alıcı adı ve adresi üretim girdisine girmiyor; kimlik alanları doğrulamadan sonra şablonda birleşiyor
Temsilî senaryo: buradaki satırlar ölçüm sonucu değil, bu kurulumda hangi büyüklüğün izlenmesi gerektiğini gösterir.
Bu kayıt gerçek bir müşteri işi değildir. Sinaptik Lab'in bu problemde izlediği yaklaşımı, mimari kararları ve ölçüm düzenini göstermek için yazılmış temsilî bir senaryodur: kurum adı taşımaz, içindeki hiçbir değer gerçek ölçüm değildir ve referans olarak gösterilemez. Gerçek projelerden vakalar müşteri onayı alındıkça bu kütüphaneye eklenir.
Problem
Sevkiyat durumundaki değişiklikler müşteriye operasyon temsilcileri tarafından elle yazılıyordu. Sabit şablon vardı ama yetersiz olduğu için herkes esnetiyordu: bir temsilci sebebi hiç yazmıyor, diğeri 'yarın kesin teslim' gibi taahhüt veriyor, üçüncüsü gecikmenin sorumluluğunu üstlenen bir cümle kuruyordu. Aynı olay tipinde müşteriye giden metin temsilciye göre değişiyordu ve bu metinlerin hiçbiri sonradan denetlenebilir biçimde saklanmıyordu. Bir şikâyet geldiğinde 'bu cümleyi kim, hangi bilgiyle yazdı' sorusunun cevabı yoktu.
Yaklaşım
Metin üretimi serbest bırakılmadı; olay verisine bağlı kısıtlı bir üretim olarak kuruldu. Girdi serbest metin değil yapısal olay kaydı: olay tipi, sebep kodu, yeni teslim penceresi, sevkiyat referansı. İstem koddan ayrı, sürümlü bir kaynakta tutuluyor ve üretilen her metnin kaydına istem sürümü ile model sürümü yazılıyor, çünkü bir şikâyet geldiğinde o cümleyi hangi talimatın ürettiğini bulmak gerekiyor. Örnekleme dar tutuldu: burada çeşitlilik bir değer değil, aynı olayda benzer metin üretmek bir değer. Üretimden sonra deterministik bir doğrulama kapısı var; zorunlu unsurlar, taahhüt kalıpları ve metindeki tarihin olay verisiyle tutarlılığı orada kontrol ediliyor ve kapı düştüğünde sistem sessizce kötü metin göndermiyor, sabit şablona geri dönüyor.
Kullanılan teknolojiler
- Sürümlenmiş istem kaynağı
- Yapısal olay girdisi ve kimlik alanı maskeleme
- Dar örnekleme ayarı
- Deterministik çıktı doğrulama kapısı
- Şablona geri dönüş
- Risk sınıfına bağlı insan onay kapısı
Bağlam, kurulum ve ölçüm
Problem ve yaklaşım özetin üstünde; burada kararların gerekçesi ve mimarinin ayrıntısı var.
Bağlam ve kısıtlar#
Sevkiyat bildirimi müşteriyle kurulan en düzenli temas: teslim planı, gecikme, gümrükte bekleme, hasar, iptal. Metin operasyon tarafında yazılıyor ama sonucu satış ve hukuk tarafında doğuyor; bir taahhüt cümlesi sözleşmede olmayan bir yükümlülük tartışması açabiliyor. İnsan onayının kaldırılamayacağı eşik de burada: yüksek riskli olay tiplerinde müşteriye ne söyleneceği bir operasyon kararı değil ticari karar. Sistem bu kararı almadı; düşük riskli tiplerde yazma işini, yüksek riskli tiplerde ise yalnızca taslak hazırlama işini aldı.
Veri ve erişim#
Bildirimi kuran veri operasyon sisteminde duruyor: sevkiyat durumu, sebep kodu, tahmini teslim penceresi. Alıcı iletişim bilgisi ise müşteri kaydında ve bu iki kümeyi birleştiren tek nokta gönderim servisi. Üretim katmanına yalnızca olay verisi gidiyor; metin kişiye özel görünse de ad, adres ve iletişim alanları doğrulama sonrası şablonda birleşiyor. Üretim modeli yurt dışındaki bir sağlayıcıda çalıştığında bu ayrım aktarım tartışmasını küçültüyor, çünkü dışarı çıkan içerikte kişisel ad ve adres yok. Sebep kodlarının müşteriye söylenebilir karşılıkları ayrı bir sözlükte ve o sözlük hukuk onayından geçiyor.
- Olay kaydı: olay tipi, sebep kodu, eski ve yeni teslim penceresi, sevkiyat kimliği
- Sebep kodu sözlüğü: operasyon kodlarının müşteriye söylenebilir karşılıkları, hukuk onaylı
- Alıcı iletişim bilgisi: müşteri kaydında; üretim katmanına açılmıyor, yalnızca gönderim servisinde birleşiyor
- İstem kaynağı: sürümlü ve gözden geçirilmiş; her sürüm kendi değerlendirme kümesiyle birlikte duruyor
- Gönderim kaydı: metin, istem sürümü, model sürümü, kapı sonucu ve onaylayan kişi
Mimari kararlar#
Tasarımın çekirdeği, üretimi denetlenebilir bir boru hattının ortasına yerleştirmek oldu: girdi yapısal, talimat sürümlü, çıktı deterministik bir kapıdan geçiyor. Kapıyı modele yaptırmadık; aynı modelin kendi çıktısını denetlemesi, aynı hatayı iki kez yapma riski taşıyor. Risk sınıfı da modele sorulmuyor, olay tipinden geliyor — çünkü risk değerlendirmesini üretime bağlamak, model yanıldığında onayı da kaldırıyor.
| Karar | Seçilen yol | Neden |
|---|---|---|
| Üretimin girdisi | Serbest metin değil yapısal olay kaydı | Serbest girdi, metne olay verisinde olmayan bilgi sızdırıyor |
| İstemin yeri | Koddan ayrı, sürümlü kaynak; sürüm kimliği çıktı kaydında | Şikâyet geldiğinde metni üreten talimatın bulunabilmesi gerekiyor |
| Örnekleme | Dar ve tekrarlanabilirliğe yakın ayar | Müşteriye giden metinde çeşitlilik denetim yüzeyini büyütüyor |
| Doğrulama | Üretimden sonra deterministik kapı | Modelin kendi çıktısını denetlemesi aynı hatayı iki kez yapıyor |
| Kapı düşerse | Sabit şablona geri dönüş | Gönderilecek güvenli bir metin olmadığında kapı zamanla gevşetiliyor |
| Onay kapsamı | Risk sınıfı olay tipinden gelir, modelden değil | Riski modele sormak, model yanıldığında onay kapısını da kaldırıyor |
Güvenlik ve yetki#
Bildirim akışı alıcı adı, adresi ve iletişim bilgisiyle çalışıyor; veri minimizasyonu bu yüzden mimari bir kısıt hâline getirildi ve kimlik alanları üretim katmanına hiç açılmadı. Amaç sınırlaması ikinci kısıt: sevkiyat bilgilendirmesi için işlenen iletişim verisi pazarlama iletisine kaynak olarak kullanılmıyor ve bu ayrım sistemde iki farklı gönderim yolu olarak duruyor. Üçüncü konu yanlış alıcı riski: metin doğru üretilse bile yanlış kişiye gitmesi bir veri ihlali; gönderim öncesi alıcı eşleşmesi sevkiyat kimliği üzerinden ayrıca doğruluyor. Erişim tarafında temsilci yalnızca kendi müşterilerinin gönderim kayıtlarını görüyor.
Ölçüm düzeni#
İki farklı kalite ayrı ayrı izlendi: kapının tuttuğu şeyler ve kapıdan geçip temsilcinin düzelttiği şeyler. İkincisi asıl bilgi kaynağı oldu. Düzeltmeler ton düzeltmesi ve bilgi düzeltmesi olarak ayrıldı, çünkü ikisi farklı işi gerektiriyor: biri istem sürümüne dokunuyor, diğeri olay verisinin ya da sebep kodu sözlüğünün eksikliğini gösteriyor.
- Kapı redleri: kural kimliği bazında — zorunlu unsur eksik, tarih tutarsız, taahhüt kalıbı, uzunluk
- Şablona geri dönüş sebepleri ve hangi olay tiplerinde yoğunlaştığı
- Temsilci düzeltmeleri: ton mu bilgi mi, ve hangi istem sürümünde arttığı
- Müşteri yanıtı sınıfları: 'anlamadım', 'çelişki var', 'tarih farklı' yanıtları ayrı etiketleniyor
- Sürüm karşılaştırması: yeni istem sürümü aynı olay kümesinde eski sürümle yan yana koşuluyor
Devreye alma ve işletme#
- 1Şablon envanteri
Mevcut metinler olay tipine göre toplandı; hukukla birlikte yasaklı kalıplar ve zorunlu unsurlar yazıldı
- 2Gölge üretim
Metin üretildi ama gönderilmedi; temsilcinin yazdığıyla yan yana karşılaştırıldı
- 3Düşük riskli olayla açılış
Teslim planı bildirimi temsilci onayıyla açıldı; hasar ve iptal tipleri elle yazma akışında bırakıldı
- 4Onayın daraltılması
Yalnızca düşük riskli tiplerde onay kaldırıldı; hasar, gümrük ve iptal onayda bırakıldı
- 5Sürüm yönetimi
İstem ve model sürüm değişimi dağıtım olayı sayıldı; her değişimde değerlendirme kümesi yeniden koşuldu
Nerede yanıldık#
En açık hata örnekleme ayarıyla oynamak oldu: metinleri 'daha insani' yapmak istedik, sıcaklığı yükselttik ve taahhüt ifadeleri tam o anda sızmaya başladı. İkincisi az örnekli örnekleri eski yazışmalardan toplamaktı; eski süreçteki hatalı kalıp doğrudan öğretilmiş oldu. Üçüncüsü yasaklı kelime listesine fazla güvenmek: kapıdan geçen bir metin, hiçbir yasaklı kelime kullanmadan gayet net bir taahhüt kuruyordu. Bugün kapı unsur seviyesinde çalışıyor ve şüpheli kalıpları reddetmek yerine insana yönlendiriyor; ayrıca model sürümü değiştiğinde değerlendirme kümesi yeniden koşulmadan dağıtım yapılmıyor.
Bir sonraki projede ne değişir?
Bir vakanın en değerli bölümü sonuç değil, tekrar edilebilir dersidir.
- 01
Metni 'daha doğal' yapmak için örnekleme sıcaklığını yükseltmek doğrudan taahhüt ifadesi sızmasına yol açtı. Müşteriye giden metinde çeşitlilik bir kazanç değil, denetim yüzeyinin genişlemesi.
- 02
Az örnekli örnekleri eski süreçten toplamak, eski süreçteki hatalı kalıbı modele öğretti. Örnek kümesi kullanılmadan önce hukuk tarafından gözden geçirilmeli.
- 03
Yasaklı kelime listesi yetmiyor: 'kesin' ya da 'garanti' kelimesi hiç geçmeden de taahhüt kuran cümle yazılabiliyor. Kapının kelime değil unsur seviyesinde kontrol etmesi, şüpheli kalıpları da insana yönlendirmesi gerekiyor.
- 04
İstem sabit kalsa bile model sürümü değiştiğinde ton kayıyor. Çıktı kaydında model sürümü yoksa bu kayma fark edilmiyor; sürüm değişimi bir dağıtım olayı olarak ele alınmalı.
- 05
Şablona geri dönüş bir kayıp değil, sistemin en değerli parçası oldu. Üretim başarısız olduğunda gönderilecek güvenli bir metin yoksa ekip kapıyı gevşetmeye başlıyor.
Vaka kütüphanesinden
- EğitimDers materyali üretiminde telif ve kaynak zinciriBir eğitim içeriği ekibinin slayt, çalışma kâğıdı ve ders notu arşivi yıllar içinde karışık kaynaklardan büyümüştü: internetten alınmış görseller, yabancı kitaplardan çevrilmiş paragraflar, farklı lisanslarla dolaşan açık ders materyalleri. Bir hak sahibi itiraz ettiğinde hangi paragrafın nereden geldiğini kimse söyleyemiyor; arama dosya adına ve ekip hafızasına kalıyordu. Model destekli üretim devreye girdikten sonra bu belirsizlik büyüdü, çünkü üretilen metnin dayandığı kaynak hiçbir yerde yazılı olmuyordu. Ekipte yaygın olan eğitim amaçlı kullanım serbesttir varsayımı da hiç denetlenmemiş bir varsayımdı.
- EğitimÖdeve biçimlendirici geri bildirim üretimiBir özel okul grubunda dil ve sosyal bilimler öğretmenleri her hafta çok sayıda yazılı ödev okuyordu; not zamanında giriliyordu ama öğrenciye dönen şey bir puan ile kısa bir genel yorumdu. Hangi öğrencinin hangi rubrik ölçütünde tekrar tekrar zorlandığı hiçbir yerde toplu olarak durmuyordu; öğretmen bunu kendi defterindeki izlenimden hatırlıyordu. Geri bildirim yazma işi mesai dışına taştığı için dönem başındaki ödevlerde ayrıntılı, dönem sonuna doğru tek cümleye inen bir kalite farkı oluşuyordu. Velinin gördüğü tabloda puan vardı, gerekçe yoktu.
- EğitimÖğrenci risk modelinde etik sınırlarBir yükseköğretim kurumunda akademik danışmanlar, dersi bırakma ya da kayıt yenilememe riski taşıyan öğrencilere ulaşmayı sezgiyle yapıyordu: yokluğu fark edilen öğrenciye yazılıyor, fark edilmeyen kimseye görünmüyordu. Devam bilgisi, ödev teslimleri ve öğrenme yönetim sistemi hareketleri ayrı sistemlerde durduğu için kimse bunları tek bir öğrenci için yan yana koymuyordu. Danışmanın haftada yapabileceği görüşme sayısı sınırlıydı ama bu sınırın kime harcandığı hiçbir kayıtta yoktu. Risk modeli gündeme geldiğinde ilk itiraz teknik değildi: skor öğrenciye yapışan bir etikete dönerse ne olacağı soruldu.
BUILD
Aynı yaklaşımı kurumunuzda kurmak ister misiniz?
Discovery oturumunda mevcut durumunuzu, veri erişiminizi ve başarı tanımınızı birlikte yazıyoruz.