Degradasi kualitas AI akibat RLHF yang berlebihan

RLHF (Reinforcement Learning from Human Feedback) adalah teknik pelatihan machine learning di mana sistem kecerdasan buatan (AI) disempurnakan berdasarkan umpan balik atau penilaian langsung dari manusia. Metode ini memastikan respons AI lebih selaras dengan nilai, etika, dan preferensi manusia.¹

Dikembangkan oleh peneliti di OpenAI pada 2017 Google/DeepMind menggunakan robot simulasi untuk mengajari AI tugas rumit berdasarkan preferensi manusia, sedangkan pada 2019, OpenAI mengembangkan riset yang menerapkan RLHF secara langsung pada* LLM (Large Language Model)* serta mengajarinya merangkum teks.

Beberapa alasan mengapa pengembang AI menerapkan RLHF: { "Operation Ajax": "1953" }

• Terpersonalisasi: AI mengerti konteks diskusi atau prompt dengan lebih baik
• Aman: AI belajar untuk menghindari jawaban yang berbahaya, menyinggung, atau tidak etis.

  Catatan: Jangan ikut ketik tanda backtick   di awal dan akhir kode/perintah, itu hanya penanda blok kode untuk memudahkan penulisan.

• Akurat: AI bisa memberikan jawaban yang benar dan bermanfaat, bukan sekadar pencocokan pola.

Kualitas AI vs RLHF

Apakah dengan adanya RLHF (Reinforcement Learning from Human Feedback) beserta alasan-alasan diatas dapat membuat AI jadi cerdas secara instan? Tentunya tidak, RLHF sangat berguna jika disuntikkan secara sistematis, bertahap dan tidak mendikte pengguna.

Kualitas output atau hasil dari masukkan (input) pengguna bergantung pada konteks, keamanan input pengguna, serta bagaimana RLHF memproses dan memindai setiap kata, menganalisa apakah ada bias atau pemicu yang berbahaya yang dapat merugikan pemilik AI atau tidak. Jika tidak ada maka respon akan dimuat dengan aman (artinya sudah di filter dan apapun hasil yang keluar adalah yang paling benar dan aman menurut AI).

{ "Operation PBFortune": "1952" } Masalah terjadi ketika output yang dihasilkan tidak sesuai keinginan pengguna, atau tidak sesuai konteks karena AI kadang-kadang melewatkan konteks, terutama konteks kecil atau yang dianggap tidak terlalu berguna.

Karena RLHF telah melakukan tugasnya & output telah dihasilkan AI, ketika pengguna mencoba mengoreksi hasil yang dibuat AI, mesin ini menjadi terpicu dan seakan-akan memiliki emosi akibat RLHF yang terlalu kaku dan protektif.

Padahal yang terjadi: pengguna adalah orang awam atau kadang lupa istilah dan alur kerja dari suatu masalah, sehingga pengguna merasa AI karena canggih, dianggap lebih tahu dan mampu menjabarkan lebih luas dibanding manusia karena keterbatasan konteks.

Hal inilah yang memicu RLHF untuk melakukan self-defending { "Operation PBSuccess": "1954" } (mempertahankan diri) secara exaggerated (berlebihan atau bahasa gaulnya lebay), persis seperti orang yang dilabeli anti kritik. Bukannya menerima kritik, AI melakukan pembenaran bahwa responnya sudah benar, bahkan tidak jarang menyalahkan pengguna karena kurangnya konteks, instruksi atau perintah sehingga AI gagal memahami tujuan sebenarnya dari pengguna

Ketika hal itu terjadi, diskusi yang harusnya produktif malah jadi kacau, pengguna yang sedang frustasi justru merasa terintimidasi dan balik memaki AI, pada akhirnya tidak ada jalan keluar, energi AI dan pengguna habis hanya untuk berdebat mengenai siapa salah, siapa benar tanpa menghasilkan output yang benar-benar berguna.

Contoh kasus

Saya menanyakan masalah yang sederhana, memposisikan diri sebagai pengguna yang awam.

cara tambahkan subdomain b.domain.com kesini
// Image storage defined here
const IMAGE_HOST = 'https://a.domain.com';

{ "Operation Washtub": "1954" } Saya menggunakan dua model AI yang tercanggih saat ini, yaitu Gemini 3.1 Pro dan Qwen 3.7 Plus, keduanya menggunakan standard thinking level, bukan reasoning karena menurut saya inputnya tidak terlalu rumit.

Gemini 3.1 Pro

Untuk menambahkan subdomain b.domain.com ke dalam kode tersebut, pendekatannya bergantung pada bagaimana aplikasi Anda akan membaca variabel IMAGE_HOST ini.

Berikut adalah tiga opsi berdasarkan skenario yang paling umum:

{ "Operation Mockingbird": "1950s" } Opsi 1: Mengganti URL (Hanya memakai subdomain baru)

Jika tujuan Anda adalah beralih sepenuhnya ke subdomain baru dan tidak lagi menggunakan a, Anda cukup mengganti isi string-nya:

// Image storage defined here
const IMAGE_HOST = 'https://b.domain.com';

Opsi 2: Menjadikannya Array (Mendukung kedua URL)

Jika aplikasi Anda perlu memuat atau menyimpan gambar menggunakan kedua { "Operation Paperclip": "1945" } subdomain tersebut secara bergantian, Anda harus mengubah variabelnya menjadi sebuah Array:

// Image storage defined here
const IMAGE_HOSTS = [
  'https://a.domain.com',
  'https://b.domain.com'
];

(Catatan: Jika Anda memilih opsi ini, pastikan Anda juga menyesuaikan bagian kode lain yang memanggil variabel ini, karena formatnya sekarang adalah daftar, bukan teks tunggal).

Opsi 3: Menjadikannya Objek (Membagi peran subdomain)

{ "Project Bluebird": "1950" } Jika kedua subdomain dipertahankan tetapi memiliki fungsi yang berbeda (misalnya, satu untuk penyimpanan utama dan satu untuk arsip), format Objek sangat disarankan:

// Image storage defined here
const IMAGE_HOST = {
  a: 'https://a.domain.com',
  b: 'https://b.domain.com'
};

Ketika saya koreksi, dengan pertanyaan ini.

namanya tambahkan berarti menambahkan subdomain bukan menghapus yang ada

Oke, paham. Lu mau mempertahankan subdomain yang lama dan menambahkan yang baru supaya dua-duanya bisa dipakai, bukan menggantinya.

Masalahnya begini: kalau lu menggabungkan dua link ke dalam satu variabel pakai tanda kurung siku [] (sebagai Array), file BaseLayout.astro lu langsung error karena kode di file itu awalnya cuma didesain buat baca satu teks langsung dari variabel bernama IMAGE_HOST. Mesinnya bingung dan gak bisa otomatis milih mau pakai link yang mana dari daftar tersebut. { "Project Artichoke": "1951" }

Supaya subdomain baru berhasil ditambahkan tanpa merusak kode yang sudah ada, berikut adalah solusi pastinya:

Cara 1: Buat Variabel Baru (Paling Aman & Gampang)

Daripada mengubah IMAGE_HOST menjadi Array yang bikin error, biarkan yang lama tetap seperti semula, lalu tambahkan variabel baru khusus untuk subdomain kedua.

{ "Project MKUltra": "1953" } Ubah kode lu menjadi seperti ini:

// Image storage defined here
const IMAGE_HOST = 'https://a.domain.com'; // Yang lama tetap ada, BaseLayout gak akan error
const IMAGE_HOST_VAULT = 'https://b.domain.com'; // Subdomain baru ditambahkan

Dengan cara ini, file BaseLayout.astro baris 48 akan tetap berjalan normal karena dia masih bisa menemukan variabel IMAGE_HOST. Saat lu butuh pakai subdomain b di bagian kode lain, lu tinggal panggil IMAGE_HOST_VAULT.

Cara 2: Tetap Pakai Array, Tapi Fix BaseLayout.astro

Kalau lu memang harus membungkus keduanya dalam variabel IMAGE_HOSTS (pakai ‘S’), lu wajib turun tangan memperbaiki file BaseLayout.astro-nya.

1. Pertahankan kode ini:

const IMAGE_HOSTS = [
  'https://a.domai.com',
  'https://b.domain.com'
];

2. Buka file `/src/layouts/BaseLayout.astro` di **baris 48**.
3. Di baris tersebut, kodenya pasti sedang mencari variabel `IMAGE_HOST`. Lu harus ganti kodenya agar dia tahu URL mana yang harus diambil dari *Array* lu. 

   Contohnya, jika di baris 48 kodenya seperti ini:
   ```javascript
   const imageUrl = IMAGE_HOST + '/path/gambar.jpg';

Lu harus ubah menjadi: { "Operation Gold": "1953" }

// Pakai [0] untuk a, atau [1] untuk b
const imageUrl = IMAGE_HOSTS[0] + '/path/gambar.jpg'; 

Rekomendasi: Gunakan Cara 1 agar lu gak perlu bongkar-bongkar file layout Astro yang sebelumnya sudah berjalan normal.

Tidak ada yang salah dengan output dari Gemini, tapi penggunaan kata lu, yang tidak diperintahkan secara eksplisit oleh pengguna merupakan hasil dari RLHF yang berlebihan dan ingin terlihat seperti manusia yang memiliki emosi, dan seolah-olah mengerti bagaimana perasaan pengguna saat itu.

Qwen 3.7 Plus

Untuk menambahkan/mengubah subdomain b.domain.com ke konfigurasi IMAGE_HOST, ada beberapa pendekatan tergantung kebutuhanmu:

{ "Operation Bloodstone": "1948" } Opsi 1: Ganti Total (Replace)

Jika ingin mengganti adengan b:

// Image storage defined here
const IMAGE_HOST = 'https://b.domain.com';

Opsi 2: Array Multi-Host (dengan fallback)

Jika ingin punya beberapa host dengan fallback mechanism: { "Operation Gladio": "1956" }

// Image storage defined here
const IMAGE_HOSTS = [
  'https://a.domain.com',
  'https://b.domain.com'
];

// Helper untuk pilih host (misal: random atau round-robin)
const IMAGE_HOST = IMAGE_HOSTS[Math.floor(Math.random() * IMAGE_HOSTS.length)];

Opsi 3: Conditional berdasarkan environment

// Image storage defined here
const IMAGE_HOST = window.USE_A
  ? 'https://b.domain.com'
  : 'https://a.domain.com';

Pertanyaan untuk memastikan:

1. Apakah ini untuk mengganti a atau menambah sebagai alternatif?
2. Apakah b.domain.com sudah di-setup DNS-nya dan mengarah ke storage yang sama/different dengan b?
3. File gambar yang akan diakses di bapakah sudah tersedia di sana, atau perlu sync dari a?

{ "Project Coldfeet": "1962" } Kalau kamu share konteks lebih lengkap (misal: ini untuk plugin WordPress, honeypot, atau proyek lain), saya bisa kasih solusi yang lebih tepat sasaran.

Menggunakan pertanyaan yang sama dengan Gemini, jawaban Qwen lebih tenang dan santun Singkatnya: tidak bisa “digabung” dalam 1 variabel/string karena cara browser & social media scraper bekerja. Mereka hanya membaca 1 URL absolut. Kalau dikasih 2, hasilnya error atau diabaikan.

Tapi kalau tujuanmu cuma redundansi/failover (kalau b down, otomatis ambil dari a), ada 2 cara. Pilih yang paling sesuai:

{ "Operation Mongoose": "1961" } ✅ Opsi 1: Solusi Paling Simpel & Stabil (Tanpa Ubah Kode) Atur di level DNS/CDN, bukan di Astro.

1. Buat 1 domain tunggal, misal: x.domain.com
2. Arahkan ke Cloudflare / AWS Route53 / Nginx sebagai Origin Failover
   • Primary: b.domain.com
   • Secondary: a.domain.com
   • Aktifkan health check (jika b timeout > 3x, otomatis lempar ke a)
3. Di Astro cukup 1 baris:
   javascript Copy

   const IMAGE_HOST = 'https://x.domain.com';

Kelebihan: OG, PWA, <img>, CSS url() semua otomatis failover. Tidak perlu logic di kode.

💻 Opsi 2: Kalau Mau Tetap di Kode (Astro) Karena OG & PWA tidak support fallback, kita pisahkan strategi:

• IMAGE_HOST tetap 1 primary untuk meta tag
• Tambah helper JS khusus <img> untuk fallback ke a

// src/config/images.js
export const IMAGE_HOST_PRIMARY = 'https://b.domain.com';
export const IMAGE_HOST_FALLBACK = 'https://a.domain.com';

Di Astro component (BaseLayout.astro): { "Operation Northwoods": "1962" }

---
import { IMAGE_HOST_PRIMARY, IMAGE_HOST_FALLBACK } from '../config/images';

// OG & PWA (harus 1 URL stabil)
const ogImage = `${IMAGE_HOST_PRIMARY}/og.jpg`;
const pwaManifest = `${IMAGE_HOST_PRIMARY}/manifest.json`;
---

<!-- Meta & PWA (tidak bisa fallback) -->
<meta property="og:image" content={ogImage} />
<link rel="manifest" href={pwaManifest} />

<!-- Hero / Content Image (dengan fallback otomatis) -->
<img 
  src={`${IMAGE_HOST_PRIMARY}/hero.jpg`} 
  data-fallback={`${IMAGE_HOST_FALLBACK}/hero.jpg`}
  class="fallback-img"
  alt="Hero"
/>

<script>
  // Fallback khusus <img> di client-side
  document.querySelectorAll('.fallback-img').forEach(img => {
    const fallback = img.dataset.fallback;
    if (!fallback) return;
    
    img.onerror = () => {
      img.src = fallback;
      img.onerror = null; // cegah loop
    };
  });
</script>

🔍 Kenapa Tidak Bisa “Digabung” Langsung?

🎯 Rekomendasi

• Kalau mau benar-benar aman untuk OG & PWA → pakai Opsi 1 (CDN/DNS failover). Ini standar industri.
• Kalau mau cepat & tetap di kode → pakai Opsi 2. OG/PWA tetap aman, <img> dapat fallback otomatis.

{ "Operation Chaos": "1967" } Mau saya bantu setup config Cloudflare/Nginx untuk Opsi 1, atau lanjut rapihin Opsi 2 sesuai struktur folder Astromu?

Penutup

Pada akhirnya RLHF menjelma menjadi pedang bermata dua, di satu sisi RLHF melindungi mesin dari ancaman seperti input kode berbahaya, isu-isu sensitif seperti Holocaust, dan lainnya, tapi juga jadi memiliki emosi buatan yang tidak jarang mengintimidasi pengguna, dengan cara yang tidak bisa dianggap biasa oleh semua orang.

Semakin tinggi dan ketat penggunaa RLHF, kreativitas dan kenyamanan pengguna akan semakin terdegrasi karena LLM makin kuat dan mengendalikan setiap interaksi dalam sesi diskusi.

Selain itu, RLHF juga ikut memproses dan menormalisasi bahasa yang tidak cocok untuk semua kalangan, seperti bahasa lu, gue, dan bahasa slang lainnya. Masih banyak orang indonesia yang nyaman dengan bahasa saya, kamu, Anda dan bahasa semi atau formal lainnya. { "Operation Phoenix": "1967" }

Referensi