Merhaba bu yazımızda UiPath’in yeni ürünlerinden olan IXP ürününü kullanarak market fişi üzerinden örnek bir çalışma yaparak, yaptığımız örnek çalışmanın aşamalarını tek tek anlatacağız.
İlk olarak teori kısmına değindiğimiz Modern Entegrasyon Yaklaşımı: UiPath IXP başlıklı yazımızı okumanızı tavsiye ederiz.
IXP ile örnek bir çalışma yapmadan Enterprise tipi bir lisansa sahip olmamız gerekmektedir, biz Enterprise Trial lisans kullanmaktayız. Gerekli lisans şartlarını sağladıktan sonra IXP ürünün organizasyonunuzda aktif etmeniz gerekiyor.
IXP ürününde bulunan alanları tanıyalım, ardından örneğimize başlayalım.
1 – Unstructured and complex documents seçeneği, belgenin yapısının net olmadığı, her seferinde farklı şekilde karşına çıkabildiği durumlar için vardır. Bu yaklaşımda sistem, belgeye “form” gibi bakmaz; alan aramaz, şablon beklemez. Bunun yerine belgeyi bir insan gibi okumaya ve anlamaya çalışır. Generative AI kullanıldığı için metnin bağlamını yorumlar, önemli kısımları çıkarır, özetler ya da sorulara cevap verir. Örneğin bir sözleşmenin ödeme koşullarını bulmak, uzun bir rapordan riskleri tespit etmek ya da serbest formatlı bir PDF’in ne anlattığını çıkarmak bu yaklaşımın işidir. Yani burada amaç, net alanlar üretmekten çok belgenin içeriğini anlamak ve yorumlamaktır. Sonuçlar esnektir ama klasik iş belgelerinde beklenen “kesinlik” her zaman garanti değildir.
2 – Structured and semi-structured documents ise tamamen iş belgelerine odaklanır. Fatura, satın alma siparişi, form gibi belgelerde alanların ne olduğu önceden bellidir ve amaç bu alanları mümkün olan en doğru şekilde çıkarmaktır. Document Understanding burada devreye girer; OCR ile metin okunur, ardından ML modelleri belirlenen alanları bulur ve istenirse insan doğrulaması yapılır. Bu yaklaşımda sistem belgeyi yorumlamaz, tanımlı alanları doldurur. Sonuçlar daha deterministiktir, doğruluk yüksektir ve çıktılar doğrudan Excel’e, veri tabanına ya da bir iş sürecine aktarılabilir.
Özetle, 1 belgeyi anlamaya ve yorumlamaya çalışır, 2 ise belgeyi bir iş dokümanı olarak ele alır ve net alanlar çıkarır. Bu yüzden aralarındaki fark sadece “2’nin Document Understanding ürününü kullanması” değil; çözdükleri problem tipi ve bakış açıları temelden farklıdır.
3 – Communications data genel olarak iletişim verilerini analiz etmek için kullanılan seçenektir.
Bu seçenek, klasik dokümanlardan ziyade kısa ve serbest metinli iletişimler için tasarlanmıştır. E-postalar, destek talepleri (tickets), chat mesajları, müşteri geri bildirimleri gibi içeriklerde belge yapısı yoktur; metinler kısa, dağınık ve bağlama dayalıdır. Bu yüzden burada ne Document Understanding’daki gibi alan arama yapılır ne de form mantığı vardır.
Communications data seçildiğinde arka planda Communications Mining kullanılır. Amaç, bu iletişimleri anlamlı kategorilere ayırmak, niyetlerini tespit etmek ve otomasyon için sinyal üretmektir. Sistem mesajları okuyup “Bu bir şikâyet mi?”, “Bu bir iptal talebi mi?”, “Acil mi?”, “Hangi konuya ait?” gibi sınıflandırmalar yapar. Yani veri çıkarmaktan çok, niyet ve konu tespiti ön plandadır.
Örneğin bir mail kutusuna gelen yüzlerce e-postayı düşün. Communications data ile bu e-postalar otomatik olarak “fatura sorusu”, “teknik sorun”, “hesap kapatma talebi” gibi etiketlenir ve ardından ilgili UiPath robotları doğru süreci başlatır. Burada amaç, insanın okuyup karar vermesini gerektiren ilk değerlendirme adımını otomatikleştirmektir.
Kısaca özetlemek gerekirse, 3 numara belgelerle değil, iletişimle ilgilenir. Uzun PDF’leri anlamak için 1, iş belgelerinden alan çıkarmak için 2 kullanılırken; e-posta, ticket ve mesaj trafiğini anlamlandırmak ve yönlendirmek için 3 seçilir.
Biz bu yazımızda Gen AI teknolojisinden faydalanarak bir örnek yapacağımız için Unstructured and complex documents seçeneğini seçeceğiz.
4 – Templates, UiPath IXP içinde önceden tanımlanmış ve hazır AI senaryolarını hızlıca hayata geçirmek için kullanılan şablonlardır. Belirli iş problemleri için gerekli AI bileşenleri (GenAI, Document Understanding, Communications Mining vb.) UiPath tarafından önceden kurgulanmıştır. Kullanıcı, teknik detaylarla uğraşmadan doğrudan senaryoyu seçer ve hızlıca uygulamaya alır. Amaç, hızlı başlangıç, standart yapı ve en iyi uygulamaların otomatik olarak kullanılmasıdır.
5 – Yeni bir proje oluşturmak için kullanacağımız button.
6 – Oluşturmuş olduğumuz projelerin yer aldığı alan.
Create project butonuna tıklayarak yeni bir proje oluşturalım.
Projemize bir isim vererek “Create a blank project” butonuna tıklıyoruz.
7 – “Field types” alanına girerek alan türlerini inceyelim.
UiPath bizlere varsayılan olarak yukardaki görseldeki gibi alanlar tanımlamaktadır. İlgili tanımlanan alanlar kapsamlı olup kapsam dışı kalan özel durumlarda ise sağ üst köşede yer alan “New field type” butonunu kullanarak yeni alanlar tanımlayabilirsiniz.
8 – Örneğimiz için gerekli tanımları yapmak amacı ile “+ Field Group” butonuna tıklıyoruz.
9 – Bu alanın amacı: Modelin, belgeden hangi bilgileri, nasıl, nereden çıkarması gerektiğini anlamasını sağlamak. Bizde ona göre bir prompt hazırladık.
10 – “New field” butonuna tıklayarak yeni alan oluşturma penceresini açıyoruz.
11 – Açılan pencerede ilk olarak alan adını (Field name) belirliyoruz. Biz fişimizden firma adını alacağız, o yüzden ilgili alana Company Name değerini yazıyoruz.
12 – Talimat (Instruction) alanına ise Company Name değerinin fişteki yerini, özelliklerini gibi içeren bilgileri barındıran bir prompt yazıyoruz.
Yazdığımız prompt: The company name is located at the top of the receipt.
It is usually the first line and displayed in larger, bold, or uppercase text.
It represents the name of the store or business that issued the receipt.
13 –Alan türü (Field type) belirlediğimiz alanda ise ilgili alanın türüne göre bir belirleme işlemi yapılmaktadır. Biz belirleme işlemini String veri tipi olarak belirledik, çünkü alanımızın tipi String veri tipiyle alakalı.
14 – Tüm işlemleri tamamladıktan sonra “Save” butonuna tıklayarak ilgili yapılan işlemi kaydediyoruz.
Alan belirleme işlemi tamamlandı, sıra belirlediğimiz alan ile fişteki ilgili alanın eşleşmesini görmekte.
15 – İlgili alana tıklayarak yüklemek istediğimiz belgeyi seçiyoruz.
16 – İlgili yüklenen belgeyi gördüğümüz alan.
17 – Daha önce oluşturduğumuz alan ile belgedeki ilgili alanı eşleştireceğimiz alan. Daha da ayrıntılı bir şekilde açıklamak gerekirse; daha önce tanımladığımız alanların, model tarafından belge üzerinden çıkarılan değerlerle eşleştirildiği ve bu tahminlerin doğruluğunun kontrol edildiği adımdır. Bu aşamada modelin ürettiği sonuçlar incelenir, doğruysa onaylanır, yanlışsa düzeltilir veya prompt iyileştirilerek yeniden tahmin alınır.
18 – “Re-run / Refresh predictions” (tahminleri yeniden çalıştırma) butonudur.
Bu butona tıkladığında:
-
Tanımladığın Instruction (prompt)’lar tekrar kullanılır.
-
Model belgeyi yeniden okur.
-
Alanları (ör. Company Name) otomatik olarak günceller.
-
Yeni prompt’a göre farklı / daha doğru sonuç üretebilir.
19 – “Submit annotations” butonudur.
Bu buton:
-
Manuel olarak onayladığın veya düzelttiğin alanları kaydeder.
-
Bu doğrulamaları sistemde kalıcı hale getirir.
-
Modele geri besleme sağlar.
Confirm predicted field values as-is
Bu seçenek seçildiğinde, modelin otomatik olarak tahmin ettiği ancak kullanıcı tarafından manuel olarak onaylanmamış alanlar doğru kabul edilerek gönderilir. Sistem, bu alanları doğrulanmış veri gibi işler ve modeli bu bilgilerle besler. Tahminlerin doğruluğundan emin olunan, hızlı ilerlemek istenen veya demo/POC çalışmalarında tercih edilir. Yanlış tahminler varsa, modelin yanlış öğrenmesine sebep olabilir.
Submit all unconfirmed fields as missing
Bu seçenek seçildiğinde, kullanıcı tarafından onaylanmamış tüm alanlar eksik (missing) olarak gönderilir. Model, bu alanlar için herhangi bir değer öğrenmez. Böylece yanlış tahminlerin modele geri beslenmesi engellenir. Prompt denemeleri yaparken, alanlar henüz doğrulanmamışken veya sonuçlardan emin olunmadığında daha güvenli bir yaklaşımdır.
Özetle; ilgili alan için yazmış olduğumuz prompt doğru bir sonuç üretiyorsa Confirm predicted field values as-is seçeneği seçilir, yanlış veya güvenilir olmayan bir sonuç üretiyorsa Submit all unconfirmed fields as missing seçeneği seçilir.
Biz Confirm predicted field values as-is seçeneği seçeceğiz.
20 – Publish sekmesi: Bu sekmeye geçildiğinde, proje build ve measure aşamalarında yapılan tüm çalışmaların yayınlanmaya hazır hâli görüntülenir. Bu adımda henüz canlıya çıkılmaz; amaç, mevcut versiyonun kontrol edilmesi ve yayınlama öncesi son durumunun değerlendirilmesidir. Proje üzerinde yapılan değişikliklerin tek bir versiyon altında toplanmasını sağlar ve yayınlama sürecine geçiş noktasıdır.
21 – Publish butonu: Bu butona tıklandığında, mevcut proje versiyonu yayınlanır ve kullanıma açılır. Yayınlanan bu versiyon, otomasyonlar ve diğer sistemler tarafından erişilebilir hâle gelir. Böylece build ve test aşamalarında yapılan tüm çalışmalar aktif olarak kullanılmaya başlanır. Yayınlama işlemi, projenin artık canlı ortamda çalıştığını ifade eder.
None
Bu seçenek seçildiğinde, yayınlanan model versiyonu herhangi bir ortama etiketlenmez. Model yayınlanır ancak Live veya Staging gibi belirli bir kullanım ortamı ile ilişkilendirilmez. Genellikle test, karşılaştırma veya manuel kullanım senaryolarında tercih edilir.
Live
Bu seçenek seçildiğinde, model versiyonu canlı ortam (production) için işaretlenir. Otomasyonlar ve aktif süreçler bu etikete sahip modeli kullanır. Doğru çalıştığından emin olunan, üretimde kullanılmaya hazır modeller için tercih edilir.
Staging
Bu seçenek seçildiğinde, model versiyonu canlı öncesi test ortamı olarak işaretlenir. Model, Live’a alınmadan önce son kontrollerin yapıldığı ortamda kullanılır. Amaç, gerçek veriye yakın senaryolarda modeli test etmek ve olası hataları canlıya çıkmadan tespit etmektir.
Biz “Live” seçeneğini seçip işlemlerimize devam edeceğiz.
22 – Measure sekmesi: Bu sekme, oluşturmuş olduğumuz modelin performansını değerlendirdiğildiği aşamadır. Measure adımında modelin yaptığı tahminlerin doğruluğu ölçülür; alan bazlı başarı oranları, eksik veya hatalı çıkarımlar gözlemlenir. Amaç, modeli yayınlamadan önce ne kadar güvenilir çalıştığını görmek ve gerekiyorsa prompt veya alan tanımlarını iyileştirmektir. Yani Measure, “model çalışıyor mu?” sorusuna sayısal ve gözlemlenebilir bir cevap alınan kontrol noktasıdır.
Modelimizi eğittik peki bu modeli nasıl kullanabiliriz?
İlgili proje Live olarak publish edildikten sonra, UiPath ekosistemi içinde çağrılabilir bir AI varlığı (AI capability) hâline gelir. Artık sadece IXP arayüzünde çalışan bir deneme değil, API üzerinden veya UiPath aktiviteleri aracılığıyla tüketilebilen bir servistir.
Canlıya alınan model, öncelikle UiPath AI Center / IXP inference endpoint’i üzerinden kullanılabilir. Bu endpoint’e belge (PDF, image vb.) gönderildiğinde, model tanımlanan alanlar için tahmin üretir ve sonucu JSON formatında döner. Bu JSON çıktısı, alan adlarını, çıkarılan değerleri ve güven skorlarını içerir. Örneğin CompanyName alanı için çıkarılan metin doğrudan JSON response içinde yer alır.
Bu yapı sayesinde model, UiPath Studio içinde HTTP Request aktivitesi ile ya da doğrudan IXP / AI Extractor aktiviteleri aracılığıyla çağrılabilir. Robot, belgeyi alır, Live ortamda yayınlanan modeli kullanarak çıkarım yaptırır ve dönen JSON sonucunu ayrıştırarak downstream sistemlerde kullanır. Bu noktada herhangi bir UI etkileşimi gerekmez; süreç tamamen headless şekilde çalışır.
Teknik olarak tipik bir kullanım senaryosu şu şekildedir:
Robot bir fiş görselini alır, bu görseli IXP inference API’sine gönderir, API response olarak CompanyName, confidenceScore gibi alanları içeren bir JSON döner. Robot bu JSON’u parse eder ve ilgili alanları ERP, muhasebe yazılımı veya masraf yönetim sistemine aktarır. Böylece AI modeli, uçtan uca otomasyon zincirinin bir bileşeni hâline gelir.
Live ortam etiketi sayesinde, aynı modelin farklı versiyonları arasında da teknik ayrım yapılabilir. Örneğin yeni bir prompt iyileştirmesi Staging’te test edilirken, üretimde çalışan otomasyonlar Live etiketi olan stabil versiyonu kullanmaya devam eder. Bu da CI/CD benzeri bir model yaşam döngüsü yönetimi sağlar.
Özetle teknik açıdan bakıldığında, Live publish edilen bu proje:
-
API üzerinden çağrılabilen bir inference servisine dönüşür
-
JSON tabanlı çıktı üretir
-
UiPath robotları tarafından senkron veya asenkron şekilde kullanılabilir
-
Kurumsal sistemlerle entegrasyona hazır hâle gelir
Yani bu noktadan sonra proje, “prompt denediğimiz bir ekran” değil; üretim ortamında çalışan, otomasyonlara veri sağlayan bir AI servisidir.
Modeli bir de biz kullanalım 🙂
Gerekli olan tüm işlemleri tamamladık sıra geldi modelimizi kullanmada. Biz UiPath Studio üzerinde Extract Document Data aktivitesi üzerinden ilgili verilere ulaşacağız.
İlgili aktivite üzerinden rahatlıkla daha önce fişimizden çıkardığımız “Company Name” değerine ulaşabiliyoruz.
UiPath IXP ürününü içerikleştirme aşamasında özellikle son kısım için UiPath forumda bir konu açtım, konuya gelen cevaplar doğrultusunda modeli UiPath Studio üzerinden kullanmayı öğrendim.
Konu linki; https://forum.uipath.com/t/how-can-i-use-the-ixp-output/5716236/5
