RPA nedir? RPA ve yapay zeka ajanı arasındaki fark
Yayın: · yapayzeka.org.tr
Kısa yanıt
RPA (robotik süreç otomasyonu), tanımlı kurallarla tekrar eden işlemleri yürüten yazılım otomasyonudur; ekran etkileşimi de bu kapsamdadır. Yapay zeka ajanı ise değişken girdiyi yorumlayıp sonraki eylemi seçer. RPA ve yapay zeka aynı süreçte, yorumlama ile kayıt işlemini paylaşacak biçimde kullanılabilir.
RPA'da işlemin yolu önceden tanımlanır
IBM'in RPA açıklamasında yazılım, insanın form doldurma veya veri taşıma gibi işlerini taklit eder; uygulama arayüzleriyle ve API'lerle çalışabilir. API, uygulamaların haberleşmesi için sunulan programlama arayüzüdür. Bu nedenle RPA'yı değerlendirirken hangi ekranda hangi alanın doldurulacağını veya hangi hazır işlemin çağrılacağını somutlaştırmak gerekir. İş kuralı, akışı tasarlayan ekibin tanımıyla belirlenir.
Diyelim ki onaylı bir listeden ürün kodunu alıp eski bir stok uygulamasına giriyorsunuz. Kaynak sütunla hedef alanın belli olduğu bu görev için, listedeki kodu taşıyan ve ekranda beklenmeyen bir uyarı çıktığında işi çalışana bırakan kural tabanlı bir akış öneriyoruz. Son işlenen satırı gösterin. Çalışan bu kaydı açtığında, hangi ürünlerin girildiğini baştan araştırmadan devam edeceği noktayı belirler.
Bu örnekte seçilmiş kod taşınıyor; ürünün hangi ihtiyaca uygun olduğuna karar verme işi bu adımın dışında kalıyor. Seçim işi de aynı projeye girecekse onu ayrıca tarif etmekte yarar var; aksi hâlde sorumlular basit bir veri taşıma denemesini, satın alma kararının doğruluğunu da sınamış gibi yorumlayabilir. Kabul ölçütünü de devredilen adımla sınırlamak gerekir.
Ajanın işi değişken talebi yorumlamak olabilir
UiPath'in ajan otomasyonu duyurusunda, ajanların belirli kuralları yürüten otomasyonlarla aynı süreçte birlikte çalışması tarif ediliyor. Ajan tarafını değerlendirmek için örnek stok işine serbest yazılmış bir talep ekleyebilirsiniz: çalışan ürün kodu yerine aradığı parçanın kullanımını anlatıyor olsun. Bu metinden olası ürünleri çıkarma ve eksik bilgiyi sorma işi, sabit alan aktarımından farklı bir değerlendirme gerektirir.
Olası ürün önerisini doğrudan siparişe çevirmemeyi öneriyoruz. Örnek denemede çalışana, önerinin yanında hangi ifadeden bu sonuca ulaşıldığı ve ürünün katalogdaki karşılığı da gösterilsin. Modelin kayıtta bulunmayan bir ürün için yeni kod üretmesi, denemenin reddedilme nedenlerinden biri olmalı. Bu sınır, ajanın yorum yapabildiği alanla işlem sisteminin kabul ettiği değerleri ayrı tutar.
Değişken bir girdi her zaman ajan gerektirmez. Şirketinizdeki bütün talepler, eksik alanları tamamlanan bir forma dönüştürülebiliyorsa önce bu seçeneğin iş yükünü karşılaştırabilirsiniz. Bizce ajan kararını, süreç sahibinin seçtiği yorum gerektiren örneklerle sınamak daha yerinde. Tek bir düzgün metin üzerinde çalışan demo, karşılaşacağınız istisnaları ne ölçüde ele aldığını anlatmaz.
Yorumlama ile kayıt işlemini paylaşmak
RPA ve yapay zekayı birleştirme yaklaşımını IBM de anlatıyor. Kendi tasarımınızda ajan talebi yorumlayıp öneri üretebilir. Onaylanmış veri ise RPA adımına geçebilir. Stok senaryosunda ürün seçimi çalışanın kontrolünde kalırken onaylı kodu eski ekrana yazmayı otomasyona bırakabilirsiniz. Böylece denemede yorum hatasıyla alan aktarım hatasını ayrı incelemek mümkün olur.
Aradaki teslim biçimi açık olmalı. Örnek stok görevinde ajanın hazırladığı serbest açıklamadan ürün kodu tahmin etmesini RPA adımına bırakmak yerine, onaylanan kodla işlem kimliğini belirli alanlarda taşıyan bir kayıt tasarlamanızı öneriyoruz. Gerekli alanlardan biri eksikse işlem başlamamalı. İnceleyen çalışan önerilen kodla yazılan kodu bu işlem kimliği üzerinden karşılaştırabilir; başarısız kaydı yeniden açtığında da hangi önerinin kabul edildiğini görür.
Onayı da bu kayda bağlayın. Çalışan seçimi kabul ettikten sonra ürün kodu değişmişse önceki kabulün kullanılmaması gerekir. İnsan onayı tasarımı rehberi, değişen önerinin yeniden incelenmesini planlarken başvuracağınız bir kaynaktır. Deneme kaydında hem önerilen hem de ekrana gerçekten yazılan değer tutulursa ekip uyuşmazlığı nerede arayacağını bilir.
Sürecin hangi parçası için hangisini seçmeli?
Kurallar açık, girdi düzenli ve hedef ekran sabitse önce RPA seçeneğini inceleyin. Örneğin onaylı bir listeyi uygulamaya geçirmek, hedef alanlar doğru eşleştirildiğinde sınırları belli bir kabul testine dönüşür. Aranan değer zaten listenin içindeyken modelden yeniden yorum istemek için ayrıca gerekçe bulunmalı. Bu gerekçe yoksa deneme kapsamını büyütmek zorunda değilsiniz.
Belirsiz metinden bilgi çıkarma veya eksik talepte soru sorma ihtiyacı varsa ajan seçeneğini o adımda deneyin. Sonuçları değerlendirirken 'görev tamamlandı' kaydının yanında doğru ürünün seçilip seçilmediğini kontrol etmek gerekir. Hızlı veri girişi, yanlış eşleşmeyi düzeltemez; yanlış kaydın otomatik biçimde daha erken oluşmasına da yol açabilir.
Erişilebilir bir API varsa onunla kurulacak bağlantıyı da değerlendirmeye alın. Ekran üzerinden geçmenin teknik bir zorunluluk mu, sürdürülen bir alışkanlık mı olduğunu BT ekibi açıklasın. ERP ve CRM entegrasyonu bu ayrım için yararlı sorular içerir. Satın alma kararında işlem adımını, uygulama sahibinin desteklediği bağlantı yolu üzerinden karşılaştırın.
Kapsamı işlemin adına göre de ayırabilirsiniz. Örnek bir 'sipariş oluşturma' işi, ihtiyacı anlama ve seçilmiş satırları sisteme girme adımlarını birlikte içeriyorsa, tamamına tek araç seçmek zorunda değilsiniz. Süreç haritasında çalışanın karar verdiği noktayı işaretlemek, yorumlama adımını otomatikleştirmeden önce kayıt taşıma kısmını ayrı denemenizi kolaylaştırır. Bu durumda ilk kabul, sipariş seçiminin doğruluğunu kapsamaz.
Bakım denemesinde farklı arızaları sınayın
Örnek RPA akışında hedef uygulamanın alan adı veya ekran düzeni değişmiş olsun. Ekipten, otomasyonun yanlış alana yazmadan durduğunu ve başarısız satırı işaretlediğini göstermesini isteyin. Bu testte incelenen sorun ekranla etkileşimdir. Modelin talebi doğru yorumlamış olması, sonraki kayıt adımının değişiklikten etkilenmediğini kanıtlamaz.
Ajan için de çelişkili bir talep hazırlayın: aynı metinde farklı ürün koşulları bulunsun ve katalogda tam karşılığı olmasın. Süreç sahibi beklenen davranışı yazsın. Hangi koşulda soru sorulacağı ve hangi durumda işin insana kalacağı belli olduğunda, test sonucu yalnızca 'yanıt güzel' değerlendirmesine sıkışmaz. Bakım sorumlusu bu örneği kural değişikliklerinden sonra yeniden kullanabilir.
Birlikte çalışan yapıda görevin sonunu hedef uygulamadaki kayıttan doğrulamak yararlı. Ekran adımı tamamlanmış görünebilir. İşin kabul edildiğini gösteren kaydı da bulun. Canlıya geçişten önce süreç sahibinizle test talebini baştan sona izleyin ve öneriden kayda kadar değişen değerleri karşılaştırın. Bir uyuşmazlık varsa yürütme yetkisini genişletmeden bu sorunu düzeltin.