Bir sürece AI eklemek, o süreci otomatik olarak daha iyi yapmaz. Yanlış tanımlanmış bir işi daha hızlı çalıştırmak da mümkündür. İlk karar hangi modeli kullanacağınız değil, sistemin hangi kararları kendi başına verebileceğidir. Bu sınır açık değilse küçük bir içerik yardımı, fark edilmeden stok veya müşteri iletişimini etkileyen bir uygulamaya dönüşebilir.
Bu yazı bir araç listesi sunmuyor. Aynı problemi basit kurallarla, model destekli bir iş akışıyla veya daha bağımsız bir agent ile nasıl ele alabileceğinizi karşılaştırıyor. Örnekler açıklama amacıyla hazırlanmıştır; gerçek bir projede elde edilmiş performans, tasarruf veya başarı sonucu olarak okunmamalıdır. Amaç seçeneği büyütmek değil, problem için gerekli karar alanını tanımlamaktır.
Önce üç yaklaşımı ayırın
Kural tabanlı otomasyonda akışın önemli adımları önceden tanımlanır. Belirli bir olay olduğunda belirli koşullar kontrol edilir ve belirli işlem uygulanır. Model destekli iş akışında ise yorum gerektiren bir adım dil modeline bırakılabilir; sonraki adımların sınırı yine uygulama tarafından çizilir. Agent yaklaşımında sistem, hedefe ulaşmak için sonraki adımı ve kullanacağı araçları daha dinamik seçer.
Anthropic’in mühendislik rehberi de iş akışlarını önceden tanımlanmış yollarla, agent’ları daha dinamik karar süreçleriyle ayırır ve basit çözümlerle başlamayı önerir. Bu ayrım bir olgunluk sıralaması değildir. Daha çok bağımsızlık, her problemde daha iyi sonuç anlamına gelmez. Building effective agents
Örneğin stok belirli eşiğin altına düştüğünde görev açmak için serbestçe plan yapan bir sisteme ihtiyaç olmayabilir. Buna karşılık çok farklı biçimlerde gelen tedarikçi yazışmalarını özetlemek, dil yorumlama yeteneğinden yararlanabilir. Yazışmayı özetlemekle tedarikçiye sipariş geçmek ise aynı yetki değildir. Uygulama tasarımı bu iki eylemi açıkça ayırmalıdır.
Kararı araç isminden önce işin yapısı belirlesin
Bir iş akışını değerlendirmek için beş soruyla başlayın: Girdi ne kadar düzenli? Doğru sonucun ölçütü ne kadar açık? Yanlış işlemin maliyeti ne? İşlem geri alınabilir mi? İnsan kontrolü hangi noktada değer katıyor? Bu sorular çoğu zaman yeni bir agent kurmadan önce mevcut sürecin eksiklerini gösterir.
Girdi düzenli ve doğru sonuç kesin ise kurallar güçlü bir başlangıçtır. Yorum ihtiyacı yüksek ama son eylem riskliyse modelin yalnız öneri üretmesi daha uygun olabilir. Hem yol hem bilgi kaynağı görevden göreve değişiyorsa sınırlı bir agent denenebilir. Ancak değişkenlik tek başına izin sınırlarını genişletmek için gerekçe değildir.
| İş örneği | Başlangıç yaklaşımı | Sınır |
|---|---|---|
| Düşük stokta görev açma | Kural tabanlı akış | Tekrarlanan görevleri önle |
| Destek mesajını sınıflandırma | Model destekli akış | Belirsiz kaydı insana ilet |
| Ürün açıklaması taslağı | Model ve editör | Doğrulanmayan özellik ekleme |
| Kaynaklardan araştırma özeti | Sınırlı agent denemesi | Kaynak, süre ve araç sınırı |
| İade veya ödeme kararı | Yetkili insan kontrolü | Öneri ile işlemi ayır |
Tablo kesin bir ürün mimarisi değildir. Aynı işin farklı işletmelerde farklı riskleri olabilir. Bir taslak metnin yanlışlığı kolay düzeltilebilirken, metindeki yanlış teslimat vaadi müşteriye gönderildiğinde etkisi büyür. Bu nedenle “metin üretimi düşük risklidir” gibi geniş etiketlerden kaçının. Çıktının nerede kullanılacağını da değerlendirin.
Sürecin başarısını çıktı sayısıyla ölçmeyin
Bir sistemin yüz mesajı sınıflandırması, yüz işi doğru tamamladığını göstermez. Önce doğru sonucun tanımını yazın. Destek sınıflandırmasında amaç doğru kategori olabilir; araştırma görevinde iddiaların kaynakla desteklenmesi; katalog işinde mevcut ürün bilgisinin korunması olabilir. Her iş için aynı değerlendirme puanı kullanmak önemli farkları gizler.
Küçük bir değerlendirme kümesi oluşturun. Olağan örneklerle birlikte eksik veri, çelişkili talimat, yanlış dil, çok uzun metin ve alışılmadık ürün adı içeren kayıtlar ekleyin. Bu örnekleri kişisel bilgilerden arındırın. Test kümesinin yalnız sistemi kuran kişinin aklına gelen kolay örneklerden oluşmaması için işi yapan kişiden de katkı alın.
Kabul eşiğini denemeden önce belirlemek, sonuca göre hedef değiştirmeyi azaltır. Hangi hata insan kontrolünü zorunlu kılıyor? Hangi hata yeniden denemeyle çözülebilir? Hangi durumda sistem tamamen durmalı? Bu kararlar modelin akıl yürütmesine bırakılacak ayrıntılar değildir. İşletmenin uygulama kurallarıdır ve bağımsız olarak izlenebilmelidir.
Yetkiyi üç katmanda sınırlayın
Birinci katman bilgi erişimidir. Sistem hangi kayıtları okuyabilir? İkinci katman işlem yetkisidir. Okuduğu kaydı değiştirebilir mi, yalnız taslak mı oluşturabilir? Üçüncü katman işlem hacmidir. Tek seferde kaç kayıt üzerinde çalışabilir ve hangi maliyet sınırına kadar devam edebilir? Bu katmanların her biri ayrı tanımlanmalıdır.
Örneğin ürün açıklaması hazırlayan bir yardımcıya bütün mağazayı değiştirme yetkisi vermek gerekli değildir. Önce belirli ürünler için öneri üreten bir sürüm oluşturulabilir. Editör öneriyi karşılaştırır ve kabul eder. Daha sonra güvenilirliği kanıtlanan, geri alınabilir alanlarda sınırlı otomasyon denenebilir. Kademeli ilerleme, hatanın etki alanını anlamayı kolaylaştırır.
Araç çıktıları ve dış sayfalar da talimat kaynağı sayılmamalıdır. Bir web sayfasındaki metin, sistemin kullanıcı adına işlem yapmasına izin vermez. Araştırma için okunan içerikle uygulamanın yetki kurallarını birbirinden ayırın. Özellikle dış içerik okuyan ve başka bir sisteme yazabilen yapılarda bu ayrım teknik tasarımın merkezinde olmalıdır.
İnsan kontrolünü yalnız son ekrana koymayın
Her çıktıyı bir kişiye onaylatmak güvenli görünebilir; fakat yüzlerce benzer öneri arasında dikkat azalabilir. İnsan kontrolünün hangi belirsizliği çözmesi gerektiği açık olmalıdır. Bir onay ekranında yalnız son metni göstermek yerine kaynak alanları, değişen değerleri ve sistemin emin olmadığı noktaları göstermek daha yararlıdır.
Kontrol gerektiren işleri önceliklendirin. Belirli alanlar eksikse, öneri mevcut bilgiyle çelişiyorsa veya işlem geri alınamıyorsa insan kararını zorunlu tutun. Düşük etkili, geri alınabilir ve açık kurallı işlemler için farklı akış kullanılabilir. Böylece insan katkısı rastgele bir imza adımı olmaktan çıkar ve belirli bir değerlendirmeye bağlanır.
İnsan reddinin nedenini de kaydedin. “Yanlış” seçeneği tek başına modelin mi, verinin mi, iş kuralının mı sorunlu olduğunu açıklamaz. Yanlış ürün özelliği, eksik bağlam, uygunsuz ton ve yanlış hedef ayrı nedenlerdir. Bir sonraki iyileştirme bu ayrım sayesinde doğru yere yapılabilir. Her sorunu daha güçlü modele geçerek çözmeye çalışmak pahalı bir refleks olabilir.
Maliyet hesabına yeniden denemeyi ve kontrolü dahil edin
Yalnız model kullanım maliyetini hesaplamak yanıltıcıdır. Araç çağrıları, tekrar denemeler, insan kontrol süresi, hata düzeltme ve bakım da toplam maliyete dahildir. Başarısız bir görev on kez yeniden deneniyorsa düşük birim fiyat gerçek verimliliği göstermeyebilir. Görev başına harcamayı başarılı ve kabul edilmiş sonuçla birlikte izleyin.
Bir deneme için azami süre, azami araç çağrısı ve azami yeniden deneme sayısı belirleyin. Sınıra ulaşıldığında sistem “tamamlandı” dememeli; hangi aşamada durduğunu ve neyin eksik kaldığını göstermelidir. Kısmi sonuç faydalı olabilir, fakat tamamlanmış sonuç gibi sunulması sonraki kararları bozabilir. Durum bilgisinin kendisi ürün deneyiminin bir parçasıdır.
Karşılaştırmayı mevcut sürece karşı yapın. İnsan bir işi zaten hızlı ve doğru yapıyorsa yeni sistemin getirdiği kontrol yükü kazanımı azaltabilir. Buna karşılık aynı bilgiler farklı ekiplerce tekrar tekrar aranıyorsa sınırlı bir özetleme aracı bile yararlı olabilir. Teknolojiyi seçmeden önce tekrarın nerede oluştuğunu görmek gerekir.
Küçük bir deneme nasıl tasarlanır?
Örnek olarak destek mesajlarından ürün bilgisi eksiklerini çıkarmak istediğinizi düşünün. İlk sürüm müşteriye cevap göndermez, siparişi değiştirmez ve ürün sayfasını yayımlamaz. Yalnız izin verilen kayıt kümesini okur, tekrar eden soruları gruplaştırır ve önerilen içerik eksiklerini gerekçeleriyle listeler. Bu sınır, değerlendirmeyi daha anlaşılır kılar.
Her önerinin yanında anonimleştirilmiş kanıt ve belirsizlik bulunmalıdır. “Teslimat süresi açık değil” önerisi için hangi ifadelerin bu sonuca yol açtığı gösterilir. Daha sonra editör, sayfada gerçekten eksik bilgi olup olmadığını kontrol eder. Destek mesajındaki sorun her zaman içerikten kaynaklanmaz; ürün, lojistik veya yanlış beklenti de neden olabilir.
Deneme sonunda yalnız öneri sayısını değil, kaç önerinin yararlı bulunduğunu ve ne kadar düzeltme gerektiğini ölçün. Sonuçlar zayıfsa kapsamı daraltın veya veri girişini iyileştirin. Başarılıysa otomatik yayın yetkisi vermeden önce daha çeşitli örneklerde tekrar değerlendirin. Bir küçük kümede iyi sonuç, tüm işletme için yeterli kanıt değildir.
Uygulama kararını bir sayfada tutun
Bir karar notunda problem, mevcut süreç, önerilen yaklaşım, izin verilen araçlar, insan kontrol noktası, başarı ölçütü ve durdurma koşulu bulunsun. Bu notu uzun bir teknik tasarımın yerine değil, ortak başlangıç noktası olarak kullanın. Teknik ekip ile operasyon ekibi aynı hedefi farklı kelimelerle tarif ediyorsa sorun henüz çözülmemiştir.
Notta kapsam dışı eylemler de açık olmalıdır. Sistem ürün açıklaması önerebilir ama fiyat değiştiremez; kaynak okuyabilir ama üçüncü kişiye mesaj gönderemez; görev oluşturabilir ama ödeme başlatamaz. Bu sınırlar yalnız açıklama metninde kalmamalı, araç izinleri ve sunucu kontrollerinde uygulanmalıdır. Ürünün iddiasıyla uygulamanın davranışı aynı olmalıdır.
İyi başlangıç, en bağımsız sistemi kurmak değildir. Doğru başlangıç; işi ölçülebilir hâle getirmek, belirsiz adımı bulmak ve yalnız o adım için gereken yeteneği eklemektir. Kendi operasyonunuzda hangi süreçlerin otomasyon, hangilerinin insan kararı gerektirdiğini netleştirmek için çalışma kapsamını birlikte belirleyebiliriz.