Kesenjangan antara demo AI yang mulus dan sistem produksi yang berjalan pada jam 2 pagi tanpa mengalami kegagalan fatal sangatlah besar. Kebanyakan orang yang membangun demo menyadari hal ini. Mereka hanya tidak selalu jujur saat menjual cetak birunya kepada Anda. Dalam produksi, pipeline Anda tidak gagal karena Anda memilih foundation model yang salah. Ia gagal karena desain sistem Anda memperlakukan prototipe layaknya sebuah produk.

Saat ini, semua orang menyebut segala hal sebagai agent. Sebuah skrip yang melakukan looping hingga suatu kondisi terpenuhi tiba-tiba disebut agent. Chatbot yang menyimpan tiga pesan terakhir dalam memori juga disebut agent. Kosakata yang sembrono ini menimbulkan kerusakan teknik yang nyata. Tim-tim menggunakan framework agent yang berat untuk mengotomatisasi alur kerja lima langkah yang sebenarnya bisa ditangani oleh cron job sederhana. Di saat yang sama, mereka kurang berinvestasi pada kompleksitas yang sesungguhnya karena label tersebut membuat seolah-olah large language model akan secara ajaib menyelesaikan edge cases. Kenyataannya tidak demikian.

Apa Itu Agent yang Sebenarnya

Agent adalah sistem dengan sebuah tujuan. Ia tidak sekadar mengikuti urutan instruksi yang diberikan oleh manusia. Ia memutuskan apa yang harus dilakukan selanjutnya berdasarkan kondisi dunia saat itu. Ia menangani kegagalan saat sebuah tool rusak atau data hilang. Ia tahu kapan tujuannya telah tercapai dan berhenti dengan sendirinya.

Gunakan tiga aturan ini untuk menilai apa pun yang sedang Anda bangun:

  • Jika manusia harus memberi tahu setiap langkahnya, itu adalah antarmuka chat. Anda yang menyetir. Sistem tersebut hanyalah setir yang sangat sopan.
  • Jika ia dapat pulih dari kegagalan pemanggilan tool, Anda berada di jalur yang benar. Search API yang mengalami timeout atau mengembalikan error 500 seharusnya tidak menghentikan pekerjaan. Sistem harus mencoba lagi (retry), melakukan back off, beralih ke sumber fallback, atau meminta bantuan.
  • Jika ia memecah tujuan menjadi subtask dan mendelegasikannya, itu adalah agent yang sesungguhnya. Berikan perintah seperti “siapkan laporan kepatuhan Q3,” dan ia akan mengidentifikasi sumber data, menjadwalkan ekstraksi, menyerahkan angka mentah ke modul kalkulasi, mengirim draf narasi untuk ditinjau, dan tahu kapan harus berhenti.

Jika sistem Anda tidak melakukan hal-hal ini, Anda tidak memiliki masalah agent. Anda memiliki masalah scripting atau masalah alur kerja. Mengakui hal tersebut sejak dini akan menyelamatkan Anda dari pemborosan penggunaan framework selama berminggu-minggu.

Apa yang Sebenarnya Diprioritaskan oleh Tim yang Berhasil

Tim yang merilis sistem andal tidak menghabiskan hari-hari mereka dengan mengganti model terbaru hanya untuk mengejar beberapa poin pada benchmark. Mereka fokus pada tiga area yang membosankan namun berdampak tinggi.

Desain tool. Agent Anda hanya akan sebagus tool yang Anda berikan kepadanya. Jika fungsi pencarian mengembalikan JSON mentah yang bersarang (nested) dengan nama field yang tidak konsisten, model akan membuang-buang context window yang berharga untuk memparsing struktur alih-alih melakukan penalaran terhadap konten. Jika deskripsi tool tidak jelas, model akan berhalusinasi dengan argumen yang salah. Perlakukan antarmuka tool seperti API untuk seorang junior developer yang sangat literal, yang membutuhkan input bersih, output yang dapat diprediksi, dan status error yang eksplisit.

Penanganan kegagalan. Apa yang terjadi ketika langkah retrieval tidak mengembalikan apa pun? Terlalu banyak pipeline yang secara diam-diam memasukkan konteks kosong ke dalam prompt dan membiarkan model berhalusinasi menjawab dari data pelatihannya. Itu bukan sebuah fitur; itu adalah insiden produksi yang tinggal menunggu waktu. Sistem yang tepat akan mendeteksi kekosongan tersebut. Ia akan mencoba lagi dengan kueri yang lebih luas. Ia akan meneruskannya ke manusia, atau berhenti dengan penjelasan yang jelas. Ia tidak pernah berpura-pura menemukan sesuatu padahal sebenarnya tidak.

Observability. Anda perlu melihat mengapa agent membuat keputusan tertentu. Bukan hanya output akhirnya—tetapi juga chain of thought, pemilihan tool, potongan data (chunks) yang diambil, dan log serah terima (handoff logs). Tanpa jejak tersebut, debugging hanyalah tebak-tebakan. Ketika pengguna mengeluhkan jawaban yang salah minggu depan, Anda harus dapat memutar ulang langkah retrieval mana yang menyajikan data sampah dan mengapa.

Pola Arsitektur yang Bertahan Lebih Lama daripada Framework

LangChain, CrewAI, dan framework populer berikutnya enam bulan dari sekarang hanyalah perancah (scaffolding). Arsitektur adalah bangunannya. Jika desain Anda rapuh, tidak ada framework yang dapat menyelamatkannya. Tetaplah pada pola yang telah terbukti tahan lama:

  • Rencanakan, lalu eksekusi. Jangan biarkan model melakukan penalaran dan tindakan dalam satu waktu yang sama. Pertama, buatlah rencana. Kemudian jalankan langkah-langkahnya. Saat terjadi kesalahan, Anda dapat memeriksa rencana tersebut secara terpisah dari eksekusinya. Anda akan menghabiskan jauh lebih sedikit waktu untuk mengurai kekacauan panggilan alat (tool calls) yang saling tumpang tindih dan penalaran arus kesadaran (stream-of-consciousness reasoning).
  • Pisahkan pengambilan (retrieval) dari penalaran (reasoning). Mengambil konteks adalah tugas I/O. Menggunakan konteks adalah tugas penalaran. Mencampurnya berarti pengambil (retriever) Anda dibatasi oleh batas token model, dan model Anda tercemar oleh kebisingan pengambilan mentah. Biarkan lapisan pengambilan mengambil data secara agresif. Biarkan lapisan penalaran mengevaluasi apa yang didapatnya secara skeptis.
  • Gunakan serah terima (handoff) yang eksplisit. Jika beberapa agen menangani suatu tugas, atur proses serah terimanya. Tentukan skema output, batasan kepemilikan, dan log serah terima yang jelas. Obrolan informal yang samar antar agen menyebabkan tugas terabaikan, loop melingkar, atau pekerjaan ganda. Perlakukan komunikasi antar agen seperti kontrak API yang terdefinisi dengan baik, bukan seperti obrolan grup.

Alasan Sebenarnya Mengapa RAG Anda Menghasilkan Sampah

Jika pipeline retrieval-augmented generation Anda terus memunculkan hasil yang tidak berguna, berhentilah menyetel model embedding dan periksalah strategi chunking Anda. Ini adalah titik kegagalan yang paling sering diabaikan dalam sistem RAG.

Saat Anda membagi dokumen menjadi chunk berukuran tetap yang kaku, Anda sering kali membuat ide-ide menjadi terisolasi. Sebuah paragraf yang dimulai dengan “Namun, pendekatan ini gagal memperhitungkan perubahan regulasi” tidak akan masuk akal tanpa paragraf sebelumnya yang menyebutkan pendekatan tersebut. Berikan fragmen terisolasi itu ke sebuah model, dan model tersebut akan mengarang konteks apa pun yang dibutuhkannya. Itu bukan pengambilan data; itu adalah pabrik halusinasi.

Cobalah perbaikan berikut:

  • Jendela tumpang tindih (Overlapping windows). Biarkan chunk yang berdekatan berbagi satu atau dua kalimat di bagian batasnya agar konsep tidak terhenti di tengah pemikiran.
  • Chunking semantik (Semantic chunking). Bagilah pada batas-batas alami—akhir paragraf, header bagian, atau pergeseran topik—alih-alih berdasarkan jumlah karakter.
  • Pengambilan dokumen induk (Parent-document retrieval). Ambil chunk kecil yang presisi untuk pencocokan semantik, tetapi berikan bagian induk atau dokumen lengkap ke model bahasa agar ia memiliki konteks sekitarnya saat melakukan generasi.
  • Simpan data terstruktur alih-alih teks mentah. Data tabular, pasangan kunci-nilai (key-value pairs), dan relasi sering kali sulit di-embed jika dalam bentuk prosa. Jika materi sumber Anda terstruktur, tetaplah simpan secara terstruktur dalam database graf atau penyimpanan relasional, dan biarkan agen melakukan kueri secara eksplisit daripada menebak-nebak dari fragmen teks yang di-embed.

Bangun Sistem yang Dapat Anda Percayai

Berhentilah mengejar benchmark. Skor papan peringkat adalah kondisi laboratorium. Produksi itu berantakan, bersifat adversarial, dan asinkron. Yang penting adalah apakah sistem Anda berperilaku dengan benar saat Anda sedang tidur, saat API upstream tidak stabil, dan saat pengguna menanyakan sesuatu yang tidak ada dalam data pelatihan.

Fokuslah pada desain sistem. Bangun batasan yang jelas antara pengambilan (retrieval) dan penalaran (reasoning). Rancang alat yang gagal secara eksplisit (fail loudly) dan pulih dengan bersih. Catat keputusan agar Anda dapat mengauditnya. Lakukan chunking pada dokumen Anda agar konteks tetap utuh. Lakukan itu, dan Anda akan membangun pipeline yang tidak hanya tampil baik saat demo, tetapi tetap andal saat menghadapi situasi nyata.

Sumber: The Overlooked Reason Your RAG Pipeline Keeps Returning Garbage

Bergabunglah dengan komunitas pembelajaran: GyaanSetu AI on Telegram