Bangun Agen AI yang Jawab Pertanyaan Data Internal

Agen AI untuk data internal adalah asisten yang nerima pertanyaan dalam bahasa sehari-hari, nulis query ke database kantor, lalu balikin jawabannya lengkap sama sumber angkanya.

Yang bikin agen kayak gini berhasil atau gagal bukan pilihan modelnya. Yang nentuin adalah konteks yang kamu kasih dan batasan akses yang kamu pasang.

Aku bakal jalanin komponennya, tujuh langkah bikin versi pertama, guardrail yang wajib ada, dan cara ngukur akurasinya sebelum dibuka ke seluruh tim.

Apa itu agen AI untuk data internal?

Agen ini punya tiga bagian: model bahasa yang ngerti pertanyaan, kumpulan alat yang bisa dia panggil, dan konteks tentang data kamu. Alurnya sederhana. Pertanyaan masuk, agen milih alat, alat jalanin query, hasilnya dirangkum jadi jawaban.

Bedanya sama chatbot biasa: agen ini punya akses baca ke database sungguhan. Jawabannya berasal dari angka hari ini, bukan dari pengetahuan model yang berhenti di tanggal tertentu.

Bedanya sama dashboard: kamu nggak perlu tau di mana angkanya ditaruh. Cukup nanya "omzet Bandung minggu lalu berapa" dan agennya yang nyari.

Komponen apa aja yang harus ada?

Komponen	Isinya	Kenapa perlu
Katalog tabel	Nama tabel, kolom, tipe data, contoh isi	Agen nggak bisa nebak isi kolom dari namanya doang
Definisi metrik	Rumus resmi dan filter wajib tiap metrik	Nutup celah paling sering bikin angka salah
Contoh query	10 sampai 15 pasangan pertanyaan dan query benar	Ngajarin pola query khas bisnis kamu
Alat eksekusi	Fungsi yang jalanin SQL dan balikin hasil	Jembatan antara agen dan database
Guardrail	Akses baca saja, batas baris, daftar tabel yang boleh	Nyegah kerusakan dan kebocoran
Catatan	Log pertanyaan, query, hasil, dan umpan balik	Bahan perbaikan dan penelusuran kalau ada angka aneh

Definisi metrik itu komponen yang paling sering dilewat, dan paling besar dampaknya. Cara nyusunnya aku bahas terpisah di tulisan soal semantic layer.

Gimana langkah bikin versi pertamanya?

1. Pilih lima pertanyaan yang paling sering ditanya. Buka riwayat permintaan data tiga bulan terakhir. Ambil lima yang paling sering muncul, bukan lima yang paling menarik.
2. Bikin view khusus untuk agen. Jangan kasih akses ke tabel mentah. Bikin view yang udah bersih, udah kefilter status, dan udah nyembunyiin kolom pribadi.
3. Buat peran database yang cuma bisa baca. Ini langkah yang paling nggak boleh dilewat.

CREATE ROLE agen_baca LOGIN PASSWORD 'ganti_ini';
GRANT CONNECT ON DATABASE analitik TO agen_baca;
GRANT USAGE ON SCHEMA laporan TO agen_baca;
GRANT SELECT ON ALL TABLES IN SCHEMA laporan TO agen_baca;
ALTER DEFAULT PRIVILEGES IN SCHEMA laporan
  GRANT SELECT ON TABLES TO agen_baca;

Perintah GRANT di atas pakai sintaks PostgreSQL, rinciannya ada di dokumentasi resmi PostgreSQL.

4. Tulis konteks sistemnya. Isinya katalog tabel, definisi metrik, dan aturan main. Contoh kerangkanya begini.

Kamu asisten data untuk tim penjualan toko_berkah.

TABEL YANG BOLEH DIPAKAI
- laporan.v_transaksi (kolom: tanggal, kota, produk,
  qty, harga_satuan, diskon, status, channel)
- laporan.v_pelanggan (kolom: id_pelanggan, kota,
  tanggal_pertama_beli, segmen)

DEFINISI METRIK RESMI
- omzet_bersih = SUM(qty * harga_satuan - diskon)
  filter wajib: status = 'selesai'
- pelanggan_aktif = COUNT(DISTINCT id_pelanggan)
  filter wajib: transaksi dalam 90 hari terakhir

ATURAN
1. Selalu pakai definisi metrik di atas, jangan bikin rumus sendiri.
2. Tampilkan query yang kamu jalankan di bawah jawaban.
3. Kalau pertanyaannya ambigu, tanya balik sebelum menjalankan query.
4. Kalau metrik yang diminta tidak ada di daftar, bilang tidak tahu.

5. Definisikan alatnya. Satu alat buat jalanin query, satu buat lihat struktur tabel.

{
  "name": "jalankan_query",
  "description": "Jalankan SELECT read-only ke schema laporan",
  "input_schema": {
    "type": "object",
    "properties": {
      "sql": { "type": "string" },
      "alasan": { "type": "string" }
    },
    "required": ["sql", "alasan"]
  }
}

Kolom alasan itu bukan hiasan. Waktu ada jawaban aneh, isi kolom ini yang paling cepat nunjukin di mana logikanya melenceng.

6. Tambahin contoh pertanyaan dan query benar. Sepuluh sampai lima belas pasangan cukup buat ngajarin pola khas bisnis kamu, misalnya cara ngitung minggu berjalan atau cara nyaring channel.
7. Uji sebelum dibuka. Susun 30 sampai 40 pertanyaan yang jawabannya udah kamu tau, lalu jalankan semuanya. Catat berapa yang benar.

Kalau kamu mau agen yang sama nyambung ke lebih dari satu sumber data, spesifikasi Model Context Protocol bisa jadi acuan penyambungannya. Dokumentasinya terbuka di modelcontextprotocol.io.

Guardrail apa yang wajib dipasang?

• Akses baca saja. Peran database terpisah, nggak boleh punya hak INSERT, UPDATE, atau DELETE.
• Daftar putih tabel. Agen cuma boleh nyentuh schema laporan. Tolak query yang nyebut tabel di luar itu sebelum dijalankan.
• Batas baris dan waktu. Tambahkan LIMIT otomatis dan batas waktu eksekusi, misalnya 30 detik. Query berat yang lolos bisa bikin database lambat buat semua orang.
• Sembunyikan kolom pribadi. Nomor telepon, alamat lengkap, dan email jangan masuk ke view yang diakses agen.
• Tampilkan query di jawaban. Ini yang bikin orang bisa ngoreksi. Jawaban tanpa query itu jawaban yang nggak bisa diperiksa.
• Tolak pertanyaan di luar daftar metrik. Lebih baik agen bilang nggak tau daripada ngarang rumus baru.

Contoh kasus: agen untuk data toko_berkah

Aku nyusun 40 pertanyaan uji dari riwayat permintaan data toko_berkah. Contohnya "omzet Bandung bulan lalu berapa", "produk apa yang paling laku di channel marketplace minggu ini", dan "berapa pelanggan yang belum beli lagi dalam 60 hari".

Tiga putaran pengujian, tiga hasil yang beda jauh.

Putaran	Yang ditambahkan	Jawaban benar
1	Cuma katalog tabel	22 dari 40 (55%)
2	Ditambah definisi metrik resmi	33 dari 40 (82,5%)
3	Ditambah 12 contoh query	37 dari 40 (92,5%)

Lompatan terbesar terjadi di putaran kedua, dan itu nggak nyentuh kode sama sekali. Cuma nulis rumus resmi tujuh metrik dalam bentuk teks.

Tiga pertanyaan yang tetap salah di putaran ketiga semuanya soal periode. Agen bingung waktu ditanya "minggu ini" di hari Senin, dan bingung soal batas kuartal fiskal yang di toko ini mulai Juli.

Perbaikannya bukan di prompt, tapi di data. Aku bikin tabel kalender kecil berisi tanggal, nomor minggu, bulan, dan kuartal fiskal, lalu masukin ke daftar tabel yang boleh diakses. Setelah itu tiga pertanyaan tadi benar semua.

Soal waktu, permintaan data sederhana di tim ini sebelumnya nunggu balasan analis 1 sampai 2 hari kerja. Lewat agen, jawaban buat pertanyaan yang ada di daftar metrik keluar di bawah 20 detik.

Gimana ngukur agennya beneran berguna?

1. Akurasi terhadap daftar uji. Jalankan 40 pertanyaan yang sama tiap kali kamu ubah konteks. Angka ini yang jadi rapor.
2. Porsi pertanyaan yang dijawab tanpa bantuan analis. Kalau orang tetap nanya ke analis setelah dapat jawaban agen, berarti kepercayaannya belum kebangun.
3. Jumlah jawaban yang dikoreksi. Sediakan tombol laporkan. Koreksi yang masuk itu bahan perbaikan paling berharga.
4. Sebaran pertanyaan. Kalau 80% pertanyaan cuma nyentuh dua metrik, kamu tau metrik mana yang layak dibikin dashboard tetap.

Buat nyusun metrik mana yang layak masuk pantauan rutin, struktur di tulisan metric tree bisa langsung dipakai.

Kesalahan umum waktu bangun agen data

• Nyambungin langsung ke tabel mentah. Agen bakal ketemu kolom bekas, kolom duplikat, dan status yang nggak jelas. Bikin view dulu.
• Nambal kesalahan lewat prompt terus. Kalau salahnya soal definisi metrik, perbaiki di definisi. Prompt yang makin panjang malah bikin agen makin nggak konsisten.
• Nggak nyimpen log query. Waktu ada angka aneh dipakai di rapat, kamu nggak punya cara nelusuri.
• Buka ke semua orang di hari pertama. Uji dulu ke lima orang selama dua minggu. Kepercayaan susah dibangun ulang setelah orang dapat angka salah.
• Ngabaikan kesehatan data sumbernya. Agen yang sempurna tetap kasih angka salah kalau pipeline-nya rusak. Pasang pemantauan seperti di tulisan data observability.
• Nggak nentuin siapa yang ngurus. Agen butuh perawatan rutin. Tanpa pemilik, konteksnya basi dalam tiga bulan.

Satu catatan tambahan soal istilah. Pastikan definisi metric dan KPI di dokumen kamu konsisten, karena agen bakal nurut apa pun yang kamu tulis di situ.

FAQ

Model AI mana yang paling cocok buat agen data internal?

Pilihan modelnya jauh kurang menentukan dibanding konteks yang kamu kasih. Model mana pun yang lumayan jago nulis SQL bakal bagus kalau dikasih definisi metrik dan contoh query yang benar. Mulai dari model yang udah kamu punya aksesnya, ukur akurasinya pakai daftar pertanyaan uji, baru pertimbangkan ganti kalau hasilnya mentok.

Apa agen ini bisa lihat data pribadi pelanggan?

Jangan sampai bisa. Bikin view khusus yang udah nyembunyiin nomor telepon, alamat lengkap, dan email, lalu kasih akses agen cuma ke view itu. Kalau ada yang butuh data pribadi buat kerjaan, itu lewat jalur permintaan biasa dengan persetujuan, bukan lewat chat agen yang riwayatnya tersimpan di banyak tempat.

Berapa lama waktu yang dibutuhkan buat bikin versi pertama?

Kalau definisi metrik kamu udah tertulis, versi pertama yang jalan buat lima sampai delapan metrik bisa selesai dalam dua sampai tiga hari kerja. Bagian yang makan waktu bukan kodenya, tapi nyepakatin rumus resmi tiap metrik sama pemiliknya. Itu bagian yang jangan dipercepat.

Gimana kalau agennya kasih jawaban yang salah?

Catat pertanyaannya, query yang dia jalankan, dan jawaban yang benar. Tambahkan pasangan itu sebagai contoh di konteks agen. Dari yang aku lihat, sebagian besar kesalahan berulang hilang setelah sepuluh sampai lima belas contoh perbaikan masuk. Kalau kesalahannya soal definisi, perbaiki di semantic layer, bukan di prompt.

Perlu pakai MCP atau cukup panggil API biasa?

Untuk satu database dan satu aplikasi, panggilan API biasa dengan definisi tool sendiri udah cukup. MCP mulai berguna waktu kamu mau agen yang sama nyambung ke beberapa sumber sekaligus, misalnya database, penyimpanan dokumen, dan sistem tiket, tanpa nulis penyambung baru tiap kali. Spesifikasinya terbuka dan bisa dibaca gratis.

Penutup

Tiga hal yang paling menentukan hasilnya. Definisi metrik tertulis ngangkat akurasi dari 55% ke 82,5% di pengujian tadi, dan itu nggak butuh satu baris kode pun. Peran database yang cuma bisa baca itu syarat, bukan pilihan. Dan daftar pertanyaan uji yang jawabannya udah kamu tau adalah satu-satunya cara jujur ngukur agennya siap atau belum.

Coba mulai dari yang paling kecil minggu ini. Tulis rumus resmi lima metrik yang paling sering ditanya di kantor kamu, dan susun 20 pertanyaan uji beserta jawaban benarnya. Dua bahan itu yang nentuin sisanya.

Mau nguatin dulu kemampuan nulis query yang bakal kamu pakai sebagai contoh di konteks agen? Kulik latihan SQL di NgulikSQL, langsung praktek di browser.