Text-to-SQL: Kenapa Masih Sering Salah dan Cara Mengakalinya

Query yang dibikin AI jarang error. Itu justru bagian yang bikin repot.

Query yang error langsung ketahuan dan kamu perbaiki. Query yang jalan mulus dengan angka salah bakal lolos ke slide rapat, dan baru ketahuan pas ada yang bandingin sama catatan kasir.

Aku pernah lempar 40 pertanyaan ke asisten AI di skema toko_berkah. Semua balikin query yang jalan. Sebelas di antaranya ngasih angka yang salah. Berikut sumber kesalahannya dan cara nutupinnya.

Apa itu text-to-SQL?

Text-to-SQL adalah kemampuan model AI nerjemahin pertanyaan bahasa manusia jadi query SQL yang bisa dijalanin di database. Kamu ketik "omzet per kota bulan Oktober", model balikin SELECT kota, SUM(total) ... GROUP BY kota. Yang dia lakukan itu nebak maksudmu berdasarkan nama tabel dan nama kolom yang dia lihat.

Kata kuncinya nebak. Model nggak tau aturan bisnis yang nggak tertulis di skema. Dia juga nggak tau kolom total itu udah termasuk ongkir atau belum.

Kenapa text-to-SQL masih sering salah?

Ada enam sumber kesalahan yang paling sering muncul. Empat pertama yang bikin angka meleset diam-diam.

1. JOIN yang menggandakan baris

Ini penyebab nomor satu di catatanku. Kamu punya tabel transaksi dan transaksi_item. Satu transaksi bisa punya lima item. Waktu AI nge-JOIN keduanya terus jumlahin kolom total dari tabel transaksi, angkanya kehitung lima kali.

-- Salah: total transaksi kehitung sebanyak jumlah itemnya
SELECT t.kota, SUM(t.total) AS omzet
FROM transaksi t
JOIN transaksi_item i ON i.transaksi_id = t.id
GROUP BY t.kota;

-- Benar: agregasi di level yang tepat
SELECT kota, SUM(total) AS omzet
FROM transaksi
GROUP BY kota;

Query pertama jalan. Hasilnya cantik. Angkanya ngaco. Kalau kamu perlu penyegaran soal perilaku JOIN, artikel LEFT JOIN di SQL ngasih contoh pergerakan barisnya.

2. Filter bisnis yang nggak pernah ditulis

Di hampir setiap perusahaan ada aturan lisan. Transaksi berstatus batal nggak dihitung. Akun karyawan dikecualikan dari laporan. Toko cabang uji coba dibuang.

Aturan itu ada di kepala orang, bukan di skema. Model nggak punya cara nebaknya.

3. Nilai kategori yang nggak seragam

Model nulis WHERE status = 'batal'. Data aslinya nyimpen 'BATAL', 'Batal', dan 'cancelled' sekaligus, warisan tiga versi aplikasi. Query jalan, hasilnya nol baris, dan orang menyimpulkan nggak ada transaksi batal.

Ini pekerjaan data quality yang belum kelar, bukan salah modelnya.

4. Tanggal dan zona waktu

Kolom created_at disimpan dalam UTC. Bisnisnya jalan di WIB. Pertanyaan "penjualan hari ini" bikin transaksi jam 7 pagi WIB masuk ke tanggal kemarin. Selisihnya kecil per hari, tapi konsisten salah.

5. Definisi metrik yang beda-beda

"Pelanggan aktif" di tim marketing artinya pernah buka aplikasi 30 hari terakhir. Di tim keuangan artinya pernah bayar. Model bakal pilih salah satu tanpa nanya, dan pilihannya nggak selalu sama dengan maksudmu.

6. Skema yang namanya nggak jelas

Kolom bernama flag_1, tipe_2, atau amt nggak ngasih petunjuk apa-apa. Model nebak dari namanya, dan nama yang buruk ngasih tebakan yang buruk.

Gimana cara nurunin risikonya?

Lima langkah, urut dari yang paling murah.

1. Isi komentar kolom di database. PostgreSQL punya perintah COMMENT ON yang nyimpen deskripsi di katalog sistem. Banyak asisten AI ikut baca ini waktu nyusun query. Sintaksnya ada di dokumentasi PostgreSQL.

   COMMENT ON COLUMN transaksi.total IS
     'Total bayar dalam rupiah, sudah termasuk pajak, belum termasuk ongkir';
   
   COMMENT ON COLUMN transaksi.status IS
     'Isi: lunas, pending, batal. Laporan omzet hanya pakai status lunas';
   

2. Sediakan view yang udah bersih. Bikin v_transaksi_valid yang filter bisnisnya udah nempel, terus arahkan AI ke situ. Model nggak perlu nebak aturan yang udah kamu tulis sekali.
3. Minta asumsinya ditulis. Tambahin kalimat ini ke prompt: "Sebelum query, tulis dulu asumsi yang kamu pakai soal filter, definisi metrik, dan level agregasi." Sering kali salahnya kelihatan di daftar asumsi, sebelum kamu jalanin apa pun.
4. Cek jumlah baris. Kebiasaan paling murah yang paling sering nyelametin.

   SELECT COUNT(*) AS baris_sebelum FROM transaksi;
   
   SELECT COUNT(*) AS baris_sesudah
   FROM transaksi t
   JOIN transaksi_item i ON i.transaksi_id = t.id;
   

   Kalau angka kedua lebih besar, agregasimu bakal menggelembung. Perilaku aggregate function kayak SUM nggak peduli barisnya duplikat atau nggak.
5. Bandingin sama angka yang udah kamu tau. Simpan satu angka jangkar, misalnya omzet September yang udah diaudit. Setiap query baru yang nyentuh omzet harus bisa balikin angka itu.

Contoh kasus: 40 pertanyaan di skema toko_berkah

Skemanya empat tabel: transaksi, transaksi_item, produk, pelanggan. Isinya 12.400 transaksi selama enam bulan. Aku bikin 40 pertanyaan yang biasa dilempar pemilik toko, terus ngecek hasilnya satu per satu lawan hitungan manual.

Hasil	Jumlah	Penyebab utama
Benar	29	Pertanyaan satu tabel, tanpa filter tersembunyi
Jalan tapi angka salah	11	6 gara-gara JOIN menggandakan baris, 3 gara-gara status batal ikut kehitung, 2 gara-gara batas tanggal
Error	0	Nggak ada

Yang menarik, selisih paling besar datang dari pertanyaan yang kedengeran gampang: "produk apa yang paling banyak nyumbang omzet". Query-nya nge-JOIN ke tabel item terus jumlahin transaksi.total, jadi omzet produk paling laris kecatat Rp 218.700.000, padahal aslinya Rp 74.900.000. Hampir tiga kali lipat.

Setelah aku tambahin komentar kolom dan bikin dua view bersih, aku ulangi 40 pertanyaan yang sama. Yang salah turun dari 11 jadi 3. Ketiganya soal definisi metrik yang memang belum disepakati timnya.

Kalau kamu baru mulai pakai AI buat nulis query, artikel cara pakai AI buat bikin query SQL ngebahas alurnya dari awal.

Kesalahan umum waktu pakai text-to-SQL

• Nge-copy hasilnya tanpa baca. Baca query-nya selalu lebih cepat dari benerin laporan yang udah dikirim.
• Nanya banyak hal dalam satu kalimat. Pertanyaan yang isinya tiga metrik dan dua filter bikin model kompromi di tempat yang salah. Pecah jadi beberapa pertanyaan.
• Nggak nyebut level agregasi. "Per pelanggan" dan "per transaksi" bisa ngasih angka jauh beda. Sebutkan di pertanyaannya.
• Ngasih akses tulis. Akun buat AI cukup read-only. Nggak ada alasan dia perlu UPDATE atau DELETE.
• Nganggep hasil yang konsisten berarti benar. Query salah yang dijalanin lima kali bakal ngasih angka salah yang sama persis lima kali.

FAQ

Text-to-SQL itu apa dan bedanya sama query builder?

Text-to-SQL adalah fitur yang ngubah pertanyaan bahasa sehari-hari jadi query SQL, misalnya dari "omzet Oktober per kota" jadi SELECT lengkap dengan GROUP BY. Query builder beda, dia cuma ngerangkai pilihan yang kamu klik, jadi hasilnya bisa ditebak. Text-to-SQL nebak maksudmu, jadi dia bisa salah nebak walaupun query-nya jalan tanpa error.

Kesalahan text-to-SQL yang paling bahaya apa?

Query yang jalan mulus tapi angkanya salah. Penyebab paling sering JOIN yang menggandakan baris, jadi satu transaksi kehitung berkali-kali dan omzetnya membengkak. Nggak ada pesan error yang muncul. Kamu baru sadar kalau kebetulan bandingin sama rekap manual. Makanya cek jumlah baris sebelum dan sesudah JOIN itu kebiasaan yang murah dan menyelamatkan.

Gimana cara bikin AI lebih akurat baca skema database aku?

Isi komentar kolom di database pakai perintah COMMENT ON. Banyak asisten AI ikut baca deskripsi itu waktu nyusun query. Tulis artinya dalam kalimat pendek, sebut satuan dan nilai yang mungkin muncul. Contohnya kolom status transaksi, sebutkan isinya lunas, batal, atau pending. Ini langkah paling murah yang dampaknya paling kelihatan.

Apa AI bakal gantiin analis yang bisa nulis SQL?

Dari yang aku lihat, bagian ngetik query memang makin cepat dikerjain AI. Yang nggak ikut kepindah itu tanggung jawab mastiin angkanya benar dan tau filter bisnis apa yang harus dipasang. Analis yang paham datanya justru jadi lebih penting, soalnya dia satu-satunya yang bisa nangkep query yang jalan tapi salah sebelum masuk laporan.

Perlu nggak kasih AI akses langsung ke database produksi?

Kalau bisa jangan. Pakai akun read-only yang cuma bisa baca schema analitik, dan matikan izin ke tabel berisi data pribadi. Sediakan view yang udah bersih sebagai pintu masuknya. Ini nurunin dua risiko sekaligus: query yang nggak sengaja ngubah data, dan data sensitif yang kekirim ke layanan luar tanpa kamu sadari.

Penutup

Tiga hal yang perlu kamu bawa:

1. Query yang jalan bukan bukti angkanya benar. Yang bahaya justru yang nggak error.
2. Perbaikan paling murah ada di sisi database: komentar kolom dan view yang udah bersih.
3. Cek jumlah baris sebelum dan sesudah JOIN, tiap kali kamu jumlahin uang.

Coba hari ini: ambil satu query hasil AI yang kamu pakai minggu lalu, hitung jumlah barisnya sebelum dan sesudah JOIN. Kalau angkanya beda, kamu baru nemu satu laporan yang perlu dibetulin.

Lanjut baca panduan gaya nulis SQL supaya query buatanmu maupun buatan AI lebih gampang diperiksa, dan data lineage buat nelusurin angka yang kelanjur salah.