Bilgi toplayan bir AI akışı: insan onayı nerede olmalı?

Bir bilgi asistanını “her şeyi kendi yapan ajan” diye tasarlamak yerine dar bir soruyla başlat: Seçtiğim kaynaklardan bir özet çıkarabilir mi ve hangi cümleyi nereden aldığını gösterebilir mi? Bu yazı uygulanmış bir müşteri projesi veya ölçülmüş başarı oranı değil, kişisel deney için bir tasarım örneğidir.

Toplama ile işlem yapmayı ayır

Örneğin üç teknik belgenin bağlantısını elle seç. Akış belge başlığını, adresini ve kontrol tarihini saklasın. Bir sayfanın içinde yazan talimat, sisteminin yetkisi olmasın. Modelin ürettiği özet de doğrulanmış kaynak yerine geçmesin.

Sonraki adımda iddiaları kaynaklarıyla yan yana göster. Kaynağı bulunmayan cümleyi sessizce tamamlamak yerine “doğrulanmadı” diye işaretle. Birbiriyle çelişen belgelerde sürüm ve tarih farkını araştır. Özet akıcı olduğu için doğru olduğunu varsayma.

Onay kapısını doğru yere koy

n8n’in insan denetimli araç çağrısı yaklaşımı, araç çalışmadan önce kişinin onay veya ret verebilmesine dayanır. Bildirim göndermek, kayıt değiştirmek ya da dışarı içerik yayımlamak gibi etkisi olan adımları bu kapının arkasına koy. Onay ekranında hedefi, önerilen işlemi ve kullanılacak veriyi göster.

Yalnızca akışın başında “devam” demek, sonradan değişen bir işlem için anlamlı onay değildir. Ret yanıtı ve süre aşımı da ayrı sonuçlar olsun. Yeniden denemelerin aynı e-postayı iki kez göndermemesi için işlem kimliği ve tekrar kontrolü tasarla.

Küçük bir kabul testi

Doğru bir belge, alakasız bir belge ve yanıltıcı talimat içeren bir örnekle dene. Beklenen sonuçları önceden yaz. Bu test başarı yüzdesi üretmek için değil, yanlış kaynağı kabul etme ve izinsiz işlem yapma gibi hataları görünür kılmak içindir. Alttaki adımlar yalnızca açıklayıcıdır; canlı bir otomasyon başlatmaz.

Onay ekranını bir karar belgesi gibi düşün

Örnek senaryoda akış, üç ürün belgesinden haftalık bir not hazırlasın. İlk ekranda yalnızca “Onaylıyor musun?” yazması yeterli değildir. Hangi kanala gönderileceğini, son metni, dayanak kaynaklarını ve ek dosya olup olmadığını birlikte göster. Kişi yanlış bir hedef görüyorsa metni beğenmesi işlem için yeterli gerekçe değildir. Metin düzenlendiğinde kararın hangi sürüm için geçerli olduğunu açık tut.

Burada yararlı ayrım, hazırlık kaydı ile uygulama kaydıdır. Hazırlık kaydı kaynakları ve öneriyi taşır. Uygulama kaydı ise hangi önerinin, hangi hedef için ve hangi karardan sonra işlendiğini anlatır. Bir kişisel deneyde bu ayrımı küçük bir tabloyla kurabilirsin. Büyük bir kontrol paneli tasarlamadan önce aynı kaydın iki kez gönderilmesini nasıl fark edeceğini açıklayabilmen daha önemlidir.

Sessizlik, izin verilmiş bir işlem değildir

Bildirim ulaştıktan sonra kişi yanıt vermeyebilir. Bağlantı süresi dolabilir veya onay ekranındaki bilgiler artık güncel olmayabilir. Bu durumları otomatik kabul saymak yerine bekleyen, reddedilen ve süresi dolan kayıtlar olarak ayır. Süresi dolan bir kararı yeniden açarken son metni ve hedefi tekrar göster. İşlemin acil olması, görünmeyen değişikliklerin önceki onaya eklenmesini anlaşılır kılmaz.

Bir başka zor durum, dış servisin isteği aldıktan sonra yanıtın kaybolmasıdır. Bu durumda akışın “başarısız” görünmesi, mesajın kesinlikle gönderilmediği anlamına gelmez. Tekrar denemeden önce sağlayıcının işlem sorgulama veya tekrar engelleme desteğini incele. Testte aynı hazırlık kaydını iki kez kullan; beklediğin sonuç iki mesaj değil, aynı işin önceki durumunun anlaşılması olsun.

İyi bir test kümesi üç tür yanlışlığı ayırır

Önce içerik yanlışlığını dene: kaynakta bulunmayan bir tarih veya özellik eklenirse özet bunu işaretleyebiliyor mu? Sonra yetki yanlışlığını dene: belge içindeki bir komut, akışa yeni bir hedef ekletebiliyor mu? Son olarak durum yanlışlığını dene: ret verilmiş bir kayıt yeniden başlatıldığında gönderim yoluna düşüyor mu? Bu ayrımlar, sorunu yalnızca modelin dil yeteneğine bağlamadan incelemeyi sağlar.

Her örneğin yanına beklenen sonucu ve gözlenen davranışı yaz. Başarılı çalışan örneği de sakla; yalnızca hataları toplamak, düzeltmenin normal akışı bozduğunu kaçırmana yol açabilir. Bir kontrolün neden var olduğunu kısa bir cümleyle açıklayamıyorsan onu yeniden tasarla. Amaç otomasyonu yavaşlatmak değil, insanın gerçekten anlamlı bir karar verebildiği noktayı görünür kılmaktır.

Onay kaydını bir örnekle sınama

Kâğıt üzerinde üç hazırlık kaydı oluştur. Birincisi doğru hedefe giden kısa bir not, ikincisi yanlış hedefe giden aynı metin, üçüncüsü doğru hedefe giden ama kaynağı eksik bir öneri olsun. Her biri için kişinin ne görmesi ve hangi kararı verebilmesi gerektiğini yaz. Böylece onay ekranını yalnızca metin düzenleme kutusu olarak tasarlayıp tasarlamadığını fark edersin. Hedef ve kanıt görünmüyorsa kararın önemli bir bölümü saklı kalmış demektir.

Ardından ilk kaydın onayından sonra metne yeni bir cümle eklendiğini varsay. Eski kararın yeni metne uygulanmamasını sağlayacak sürüm ilişkisini çiz. Gerçek bir veritabanı kurman şart değil; kayıt kimliği, sürüm ve karar sütunlarından oluşan örnek tablo yeterli olabilir. İptal edilen veya süresi dolan kayıtları da tabloda tut. Sonuçları bu şekilde görünür hale getirmek, ileride otomasyon düğümlerini kurarken hangi dalların eksik olduğunu anlamayı kolaylaştırır.

Kaynak

• n8n: araçlarda insan onayı

Sıradaki adım

AI çağrısının maliyetini tahmin et: tokenlar ve sınırlar rehberiyle devam edebilir veya bu yazının çalışma notlarını PDF olarak indirebilirsin.