Arsitektur Content Moderation: AI Scent Detection vs Heuristik Regex

Menjaga kualitas konten pada platform blogging developer memerlukan pipeline moderasi yang mampu menyaring spam dan artikel sintetis bernilai rendah (AI-generated garbage). Arsitektur moderasi menentukan apakah pipeline ingestion platform Anda tetap responsif atau justru membebani infrastruktur dengan latensi tinggi dan tagihan API model yang membengkak.

Problem Statement: Degradasi Pipeline dan Kualitas Konten

Konten sintetis yang diproduksi otomatis sering kali lolos dari filter kata kunci sederhana, namun membawa pola linguistik yang seragam: repetisi struktur kalimat, minim variasi leksikal, serta ketiadaan detail teknis implementasi konkret. Menjalankan evaluasi ke seluruh payload tulisan secara sinkron menggunakan LLM pada HTTP request thread menciptakan bottleneck langsung. Solusi moderasi harus membedakan konten bermutu tanpa mengorbankan Service Level Agreement (SLA) latensi penulisan.

Pilihan Arsitektur: Edge Heuristics vs Async LLM Workers

Terdapat dua paradigma utama yang dapat diterapkan secara mandiri atau bertingkat (tiered):

1. Synchronous Edge Heuristics (Regex & Token Statistics)

Evaluasi dijalankan langsung di layer ingestion (API gateway, Cloudflare Workers, atau Go middleware) sebelum data disimpan ke database utama.

• Metode: Pengecekan regular expression terhadap pola promosi/frasa klise AI, penghitungan variasi kosakata (Type-Token Ratio / TTR), dan kalkulasi Shannon Entropy pada distribusi n-gram karakter atau token.
• Keunggulan: Latensi sub-milidetik, biaya komputasi nol per request (tanpa third-party billing), tidak memblokir thread IO.
• Kekurangan: Rawan false positive pada tulisan teknis yang sah namun repetitif (seperti log trace, query SQL, atau konfigurasi YAML), serta rapuh terhadap variasi teknik penulisan baru.

2. Asynchronous LLM Evaluation (Background Workers)

Data payload disimpan langsung dengan status pending_review, kemudian ID event diteruskan ke message broker (misal: Redis Streams, RabbitMQ, atau Kafka) untuk diproses oleh worker.

• Metode: Worker mengambil batch teks, memanggil inference API (atau model open-weight lokal via vLLM), dan mengevaluasi kedalaman teknis serta mendeteksi "AI scent" berdasarkan prompt sistem yang teruji.
• Keunggulan: Kontekstual, tingkat akurasi tinggi, mampu mengenali tulisan dangkal berbobot rendah dengan tingkat halusinasi minim jika diarahkan dengan rubrik evaluasi ketat.
• Kekurangan: Biaya operasional tinggi jika volume artikel besar, waktu publikasi tertunda (asynchronous lag), dan risiko kegagalan upstream API jika provider mengalami outage.

Perbandingan Trade-Off Sistem

Implementasi Kalkulasi Shannon Entropy (TypeScript / Go)

Salah satu sinyal paling efisien untuk membedakan teks sampah otomatis, obfuscation, atau distribusi kata yang abnormal adalah Shannon Entropy. Teks alami bahasa manusia memiliki rentang entropi tertentu. Variasi yang terlalu rendah mengindikasikan teks repetitif template-based, sementara entropi yang abnormal tinggi sering kali merupakan hash atau base64 terenkripsi.

Berikut implementasi kalkulasi entropi tingkat token tanpa dependensi eksternal di Node.js / TypeScript:

/**
 * Menghitung Shannon Entropy dari teks input berdasarkan frekuensi token kata.
 * Nilai yang lebih rendah menunjukkan distribusi kata yang sangat berulang.
 */
export function calculateTextEntropy(text: string): number {
  const tokens = text
    .toLowerCase()
    .replace(/[^a-z0-9\s]/g, '')
    .split(/\s+/)
    .filter(Boolean);

  if (tokens.length === 0) return 0;

  const frequencies = new Map<string, number>();
  for (const token of tokens) {
    frequencies.set(token, (frequencies.get(token) || 0) + 1);
  }

  let entropy = 0;
  const totalTokens = tokens.length;

  for (const count of frequencies.values()) {
    const p = count / totalTokens;
    entropy -= p * Math.log2(p);
  }

  // ponytail: edge check text entropy. upgrade path: tambahkan n-gram byte fallback jika tokenisasi spasi bocor.
  return entropy;
}

// Runnable self-check
const naturalPost = "Arsitektur sistem microservices membutuhkan database terpisah per service agar independensi terjaga dengan baik saat scale up horizontal.";
const lowQualityPost = "Artikel ini sangat penting. Penting sekali untuk membaca artikel ini karena artikel ini penting untuk dibaca berkali-kali.";

console.assert(calculateTextEntropy(naturalPost) > calculateTextEntropy(lowQualityPost), "Natural text must have higher entropy than repetitive content");

Desain Hybrid Recommended

Gunakan pendekatan tiered filter untuk CMS developer berukuran sedang hingga besar:

1. Filter Lapis 1 (Edge Middleware): Jalankan pemeriksaan regex untuk blacklist domain, sanitasi XSS, dan pengecekan entropi dasar. Jika payload gagal uji dasar, tolak langsung dengan HTTP 422.
2. Simpan dengan Flag: Tulis ke database dengan status published untuk draft normal, atau flagged jika melewati batas skor entropi tertentu.
3. Filter Lapis 2 (Async Queue): Masukkan artikel dengan status flagged ke Redis queue untuk diperiksa oleh background worker menggunakan model LLM berbiaya rendah (misal: open-source model ukuran 8B params). Hanya artikel yang gagal pada tahap ini yang dikirim ke human moderator dashboard.