Pencarian AI untuk AI Agent: Grounded Search vs RAG Tradisional — Mana yang Benar-Benar Berfungsi?

AI agent Anda bisa bernalar dengan brilian — tapi tanyakan harga pesaing terkini dan langsung kacau. Inilah mengapa RAG bukan jawabannya, dan apa yang diubah oleh grounded search untuk alur kerja agentic.

by AnyCap

Anda mungkin pernah mengalami momen ini: coding agent Anda baru saja menulis refactor yang indah, menghasilkan diagram arsitektur yang sempurna, lalu Anda bertanya "berapa sih harga pesaing utama kita sekarang?" — dan agent itu entah mengarang jawaban, atau memberi tahu bahwa data pelatihannya terhenti enam bulan lalu.

Ini bukan salah modelnya. Claude, GPT, Gemini — semuanya brilian dalam bernalar. Tapi tidak satu pun yang bisa melihat web secara langsung. Akibatnya, developer akhirnya menyambung-nyambungkan kunci API Google, database vektor, dan panggilan LLM, mencoba membangun sesuatu yang seharusnya cukup satu perintah.

Masalah ini punya nama: kesenjangan pencarian dalam infrastruktur AI agent. Dan solusinya bukan menambah pipeline RAG. Melainkan pendekatan yang sepenuhnya berbeda.

RAG dibangun untuk dokumen internal, bukan internet

Retrieval-Augmented Generation bekerja dengan indah ketika data Anda tinggal di database vektor dan berubah sekali per kuartal. Buku pegangan karyawan. Spesifikasi produk. Data historis. Indeks, kueri, selesai.

Masalah mulai muncul ketika Anda membutuhkan sesuatu yang tidak ada di indeks Anda.

Pesaing meluncurkan tier harga baru. Sebuah regulasi berubah. Library yang Anda andalkan memiliki bug kritis yang sedang ramai dibicarakan di Hacker News. Pipeline RAG Anda tidak tahu semua ini. Tidak mungkin — ia hanya melihat apa yang Anda berikan saat terakhir kali membangun ulang indeks.

Saya telah melihat tim mencoba memperbaikinya dengan jadwal rebuild yang lebih cepat. Lalu dengan hybrid search. Lalu dengan pipeline terpisah untuk data internal dan eksternal. Setiap lapisan membuat sistem lebih mumpuni — dan lebih rapuh. Setiap sumber data baru adalah integrasi baru. Setiap integrasi adalah hal lain yang bisa rusak jam 2 pagi.

Masalah sebenarnya bukan karena RAG buruk. Tapi karena RAG dirancang untuk menjawab "apa kata kebijakan kita tentang X" — bukan "apa yang sedang terjadi di dunia saat ini."

Grounded search mengambil informasi langsung dari web pada saat Anda bertanya. Bukan dari indeks. Bukan dari snapshot. Dari apa pun yang tersedia secara publik saat ini, dengan URL sumber terlampir pada setiap klaim.

Ini lebih mirip cara Anda meneliti sendiri: mencari, memindai beberapa sumber, menyintesis jawaban, dan menyebutkan dari mana setiap bagian berasal. Bedanya, agent Anda melakukannya dalam hitungan detik, bukan menit.

Perbandingan singkat untuk memperjelas perbedaannya:

Aspek RAG Tradisional Grounded Search
Sumber data Dokumen yang Anda indeks Web langsung, saat ini juga
Cakupan pengetahuan Apa pun yang Anda indeks Apa pun yang bisa diakses publik
Kapan menjadi basi Begitu sumber berubah Tidak basi — mengambil data baru setiap kali
Setup Pipeline indeks, vector DB, chunking Satu perintah CLI

RAG tetap unggul untuk data privat — catatan pelanggan, keuangan internal, apa pun yang tidak boleh menyentuh internet publik. Arsitektur praktis yang akhirnya dipakai kebanyakan tim: RAG untuk pengetahuan internal, grounded search untuk konteks eksternal. Agent memilih berdasarkan pertanyaan yang diajukan.

Bagaimana agent benar-benar menggunakannya

CLI sengaja dibuat sederhana karena agent tidak mengimpor library — mereka menjalankan perintah.

anycap search "Acme Corp enterprise pricing Q2 2026" \
  --citations \
  --output acme-pricing.json

Agent menerima jawaban terstruktur dengan kutipan. Agent bisa meneruskan jawaban ke pengguna, memasukkannya ke langkah workflow berikutnya, atau menyimpannya untuk nanti. Tanpa repot API key. Tanpa perlu membungkus Python SDK. Hanya sebuah alat yang bisa dipanggil agent seperti memanggil ls atau git diff.

Yang membuat ini powerful bukanlah pencariannya saja. Tapi pencarian menjadi salah satu dari banyak alat yang bisa dirantai agent. Cari harga pesaing. Riset mendalam tentang lanskap pasar. Hasilkan visual perbandingan. Kompilasi semuanya menjadi laporan. Publikasikan.

Satu CLI. Satu autentikasi. Agent berpindah antar kapabilitas tanpa kode integrasi kustom untuk setiap langkah.

Saya telah melihat pola ini bekerja sangat baik untuk pemantauan kompetitif. Agent memeriksa harga pesaing setiap minggu, membandingkannya dengan minggu sebelumnya, menandai perubahan, dan mengirim ringkasan ke Slack. Satu cron job, nol middleware.

Hal-hal yang benar-benar penting saat memilih alat pencarian

Lupakan matriks fitur sejenak. Inilah yang akan saya uji jika saya mengevaluasi alat grounded search:

Apakah kutipannya akurat? Uji 20 kueri yang Anda tahu jawaban benarnya. Untuk setiap kueri, klik kutipannya dan verifikasi bahwa sumbernya benar-benar mendukung klaim alat tersebut. Alat yang mengembalikan jawaban benar dengan kutipan salah lebih berbahaya daripada alat yang mengakui tidak tahu. Saya pernah membuang setengah hari mengejar "fakta" dari alat pencarian yang mengutip sumber yang justru mengatakan sebaliknya.

Seberapa cepat sebenarnya? Bukan latensi pemasaran. Tapi latensi P99 saat 50 agent mengaksesnya secara bersamaan. Pipeline agent yang menunggu 8 detik per langkah pencarian akan membuat semua orang frustrasi.

Apakah menangani kasus ekstrem dengan baik? Tanyakan sesuatu yang tidak umum. Sesuatu yang baru terjadi. Sesuatu di mana sumber-sumber tidak sepakat. Alat yang baik akan menampilkan konfliknya, bukan merata-ratakan ketidaksepakatan menjadi omong kosong.

CLI atau SDK? Ini lebih penting dari kedengarannya. Agent tidak melakukan from x import y. Mereka menjalankan perintah. Alat yang berada di balik library Python adalah alat yang tidak bisa digunakan agent Anda tanpa Anda menulis wrapper dulu.

Mengapa ini lebih penting dari kedengarannya

Kesenjangan pencarian bukanlah ketidaknyamanan kecil. Ini adalah hambatan terbesar yang membuat agent tidak bisa menangani workflow riset sungguhan. Agent yang bisa bernalar tapi tidak bisa mencari seperti developer yang diblokir Stack Overflow — mampu, tapi terputus dari informasi yang benar-benar mereka butuhkan.

Solusinya tidak rumit. Hanya saja bukan hal yang pertama dipilih kebanyakan tim, karena RAG sudah familiar dan kesenjangan pencarian baru terlihat jelas ketika agent Anda dengan percaya diri memberikan informasi salah kepada seseorang yang memercayainya.

Jika agent Anda menabrak tembok itu — bekerja sempurna pada data internal tapi langsung berantakan begitu butuh sesuatu dari luar — mungkin bukan modelnya. Mungkin bukan prompt-nya. Tapi arsitektur pencariannya yang memang dibangun untuk masalah yang berbeda.

Bacaan lebih lanjut: