Otomasyon Sinyallerini Gizlemek İçin Bir QC Kapısı Nasıl Oluşturdum

Otomasyon, kendisini beklemediğiniz şekillerde belli eder.

Bluesky için otomatik bir içerik hattı (content pipeline) çalıştırıyordum. "the content pipeline" ifadesinin geçtiği bir gönderi paylaşıldı. Teknik bir blogda bu sorun değil, ancak sosyal bir zaman tünelinde bu bir kırmızı bayraktır. Okuyuculara bir botla konuştuklarını hissettirir.

Bunu durdurmak için bir kalite kontrol (QC) betiği oluşturdum. Bu betik, üretim adımı ile paylaşım adımı arasında bir kapı görevi görüyor.

Yeni iş akışı şu şekilde görünüyor: bluesky-qc.mjs → (GEÇTİ) bluesky-post-queue.mjs → Bluesky API

Betik, her girişi kontrol etmek için dört kapı kullanıyor:

  • Kapı 1: İfade Filtreleme Otomasyon sinyali veren kelimeleri yakalamak için bir regex listesi kullanıyorum. "AI-generated", "cron", "content pipeline" veya "batch test" gibi terimleri engelliyor. Eğer bir gönderi bir geliştirici raporu gibi tınlıyorsa, başarısız sayılıyor.

  • Kapı 2: Güncelliğini Yitirme Kontrolleri İki tür güncelliğini yitirmiş içerik kontrolü yapıyorum: • Güncelliğini yitirmiş ifadeler: Gönderinin gecikmesi durumunda anlamını yitiren "bugün" veya "henüz yayına girdi" gibi kelimeleri yakalar. • Güncelliğini yitirmiş zaman damgaları: Eğer bir giriş 14 günden eskiyse reddedilir.

  • Kapı 3: Etkileşim Tahmini Betik, geçmişteki 300 gönderime bakıyor. Yeni bir gönderideki hashtag'lerin iyi performans gösterip göstermeyeceğini tahmin ediyor. Şu anda bu sadece bir uyarı günlüğü tutuyor, ancak yakında bunu kesin bir hata (hard fail) durumuna dönüştüreceğim.

  • Kapı 4: Kalite Onayı (Planlanıyor) İnce hataları yakalamak için bir kalite protokolü kullanarak son bir katman eklemeyi planlıyorum.

Her başarısızlık bir ret günlüğüne (rejection log) kaydediliyor. Bu günlüğü haftada bir kez inceliyorum. Bu, istemlerimi (prompts) düzeltmeme yardımcı oluyor. Eğer kapı sürekli "content pipeline" ifadesini yakalıyorsa, yapay zekanın yazım şeklini değiştirmem gerektiğini anlıyorum.

Neden sadece daha iyi istemler (prompts) yerine bir kapı kullanmalıyım? İstemler olasılıksaldır. Başarısız olabilirler. Bir kapı ise deterministiktir. Katı kuralları takip eder.

Her iki katmanı da kullanmak, insani bir tonu korumanın en güvenli yoludur.

Kaynak: https://dev.to/morinaga/how-i-built-a-pre-post-qc-gate-that-blocks-bluesky-automation-from-self-revealing-41ja