Lojistikte anomali yakalamak: kural, model ve insan aynı akışta

Lojistik verisinde anomali aramak, bir dil modeline “bu kayıtlarda tuhaf bir şey var mı?” diye sormak için çok cazip bir alan. Kayıtlar dağınık, açıklama alanları serbest metin, istisnalar sürekli değişiyor. Yine de bu soruyu doğrudan modele sorarsanız iki şeyi kaybedersiniz: tutarlılığı ve maliyet kontrolünü.

UiPath Maestro ve ajanlarla kurduğumuz lojistik anomali akışı işi üçe bölüyor: kural tabanlı RPA kontrolleri, dil modeliyle sınıflandırma ve operasyon paydaşlarına otomatik istisna bildirimi. Bu yazıda bu iş bölümünün mantığını anlatıyorum.

Bir sevkiyat kaydının akıştaki yolu

Kural, sınıflandırma ve bildirim teslim ettiğimiz akışın omurgası. Adımlardaki ayrıntılar ve insan inceleme kapısı ise benim bu tür akışlar için önerdiğim tasarım.

Sistem

Veri çekme

Sevkiyat kayıtları belirli aralıklarla kaynak sistemlerden alınır ve tek bir biçime getirilir. Sonraki adımların hepsi bu ortak biçimle çalışır.

Kural

Kural kontrolleri

Belirlenimci kontroller önce çalışır: eksik alan, eşik aşımı, mükerrer kayıt gibi. Kuralın kesin söyleyebildiği bir şeyi modele sormanın anlamı yok.

Model

Sınıflandırma

Kuralın işaretlediği kayıtlar, açıklama ve not alanlarıyla birlikte bir dil modeline gider. Model anomalinin türünü ve kısa bir gerekçeyi önceden tanımlı bir şemaya göre döner.

Kural

Yönlendirme

Türe ve modelin güvenine göre yol ayrılır. Açık durumlar doğrudan bildirime, belirsiz olanlar insan incelemesine gider.

İnsan

İnsan incelemesi

Belirsiz durumlarda kararı operasyon sorumlusu verir ve kararı gerekçesiyle kaydeder. Bu kayıtlar, modelin hangi türde zorlandığını gösteren en iyi veridir.

Sistem

Bildirim ve iz

İlgili paydaşa otomatik bildirim gider; kayıt, karar ve gerekçe denetim izine yazılır. Aynı anomali için, durum değişmedikçe ikinci mesaj gitmemeli.

Kuralın kesin bildiğini modele sormayın

Bir sevkiyat kaydında zorunlu alan boşsa, bunu söylemek için dil modeline gerek yok. Tanımlı bir eşik aşıldıysa ya da aynı kayıt iki kez geldiyse de öyle. Bu kontroller ucuzdur, her seferinde aynı sonucu verir ve denetimde açıklaması kolaydır.

Modeli, kuralın tek başına karar veremediği yerde devreye sokmak gerekir. Bence en net örnek serbest metin. Bir operasyon notunda geçen gecikmenin nedeni, açıklama alanında yazan bir ifade ya da iki alan arasındaki tutarsızlığın anlamı gibi şeyleri kural yazarak yakalamak zordur ve her yeni durumda kural sayısı artar. Sınıflandırma burada işe yarar.

Bu sıralamanın bir yan faydası da var: model yalnızca kuralın işaretlediği kayıtları görür. Böylece maliyet, toplam kayıt sayısıyla değil, şüpheli kayıt sayısıyla büyür.

Modelden serbest yazı değil, form isteyin

Sınıflandırma adımında modelin çıktısını önceden tanımlı bir şemaya bağlamak, akışın geri kalanının sağlam çalışması için şart. Anomali türü sabit bir listeden seçilmeli, gerekçe kısa tutulmalı, model emin değilse bunu söyleyebileceği bir alan olmalı. Serbest metin dönen bir model, akışın sonraki adımlarını tahmin yürütmeye zorlar.

Türler listesini operasyon ekibiyle birlikte yazmak da işin parçası. Listede olmayan bir tür ortaya çıktığında modelin bunu “diğer” diye işaretlemesi, yanlış bir türe zorla yerleştirmesinden iyidir.

Bildirim de bir tasarım işi

Otomatik bildirim, akışın en az konuşulan ama en çok şikâyet alan parçası olabilir. Herkes her şeyi alırsa kısa sürede kimse hiçbir şeyi okumaz. Benim bildirim tasarımında baktığım üç şey var:

Kim alıyor? Anomali türüne göre ilgili ekip ya da kişi.
Ne görüyor? Kayıt, anomali türü ve tek cümlelik gerekçe. Okuyanın sisteme girip aramasına gerek kalmamalı.
Ne zaman tekrar alıyor? Aynı anomali için ikinci bildirim gitmemeli, durum değişmedikçe.

Maestro’nun yeri

Bu akışta orkestrasyonun işi, adımları doğru sırayla çalıştırmak ve bir kaydın hangi aşamada beklediğini görünür kılmak. Kural, model ve insan adımları farklı hızlarda ilerler: kural milisaniyeler içinde biter, insan incelemesi saatler sürebilir. UiPath’in FUSION 2026’da Maestro’yu uzun soluklu süreçler için Orchestrate ve yüksek hacimli kısa işler için Automate diye ikiye ayırması bu farkı ürün düzeyinde tanıyor. Konuyu ilk radarda biraz daha açtım.

İnsan kapısını baştan koyun

Teslim ettiğimiz akışın çekirdeği kural, sınıflandırma ve bildirimden oluşuyor. Benzer bir akışı yeniden kursam, modelin emin olmadığı durumlar için en baştan bir insan inceleme adımı koyardım. Gerekçem basit: bu kayıtlar modelin hangi anomali türünde zorlandığını gösteren en değerli veri. İnsan kararı gerekçesiyle kaydedildiğinde, bir sonraki iyileştirmenin nereden başlayacağı da belli olur.

Genişletmeden önce ölçün

Bir anomali akışını yeni bir bölgeye ya da yeni bir veri kaynağına yaymadan önce üç şeyi ölçerdim:

Etiketli küçük bir örnek setinde sınıflandırmanın doğruluğu. Bunu kabul testine yazın.
Yanlış alarm oranı. Operasyon ekibinin güveni ilk haftalarda kazanılır ya da kaybedilir.
Kayıt başına maliyet. Model çağrıları hacimle birlikte büyür, kural kontrolleri büyümez.

Üçü de ölçülmüyorsa elinizde umut verici bir demo var; o kadar.