Text-to-SQL: Janji dan Batasnya

Coba tunjukkan ke audiens demo bahwa "tinggal arahkan AI ke database dan biarkan ia menulis SQL sendiri," dan biasanya berhasil di percobaan pertama. Seseorang mengetik "berapa penjualan bulan lalu," model menghasilkan SELECT SUM(amount) FROM orders WHERE date BETWEEN ... yang rapi, dan ruangan pun terkesan. Lalu seseorang mencobanya di produksi, dan semuanya berantakan di pertanyaan nyata pertama.

Bukan karena modelnya tiba-tiba menulis SQL yang lebih buruk. SQL-nya sering kali tetap sempurna secara sintaks. Ia gagal karena pertanyaan yang terdengar sederhana ("berapa penjualan kita bulan lalu") tidak punya satu query benar tunggal di balik sistem perusahaan sungguhan. Ada tiga kolom yang sama-sama bisa disebut revenue, dua tabel yang bisa di-join dengan lebih dari satu cara yang masuk akal, dan penanya yang seharusnya tidak melihat sebagian baris yang akan dikembalikan jawaban itu.

Text-to-SQL adalah kemampuan yang mengubah pertanyaan bahasa sehari-hari menjadi query SQL yang bisa dijalankan ke database, sehingga seseorang bisa bertanya "berapa penjualan bulan lalu" dan menerima query yang menjawabnya tanpa menulis SQL sendiri. Kemampuannya nyata. Yang memisahkan demo yang mulus dari peluncuran produksi yang rapuh adalah konteks bisnis, dan tidak ada jumlah prompting yang menyediakannya sendirian.

Kenapa demonya berhasil

Kebanyakan demo text-to-SQL berjalan di atas satu tabel, atau segelintir tabel yang rapi dan namanya jelas: orders, customers, products. Nama kolom menjelaskan artinya sendiri. Hanya ada satu field tanggal, satu field jumlah, dan satu cara yang jelas untuk memfilter. Model yang diberi skema seperti itu dan pertanyaan bahasa sehari-hari nyaris tidak punya ruang untuk salah. Ambiguitas yang menjegal sistem sungguhan sudah direkayasa hilang sebelum demo dimulai.

Skema produksi tidak seperti itu sama sekali. Satu sistem enterprise resource planning saja bisa membawa kolom revenue, kolom net_revenue, dan kolom amt_2 sisa migrasi tiga tahun lalu, dan bedanya bisa jadi soal perlakuan diskon, perlakuan pajak, atau wilayah mana yang angkanya pernah salah di-backfill. Model tidak punya cara tahu mana dari ketiganya yang jadi angka yang dilaporkan CFO Anda ke direksi. Ia akan memilih satu, dengan percaya diri dan diam-diam. Jarak antara skema demo dan skema produksi itu persis jarak yang coba diungkap kerja kesiapan data: bukan soal apakah data bersih, tapi apakah ada yang sepakat soal artinya.

Jaraknya terlihat di angka. Di BIRD, benchmark text-to-SQL yang dibangun di atas 95 database besar dunia nyata, sistem terkuat mencapai sekitar 82% akurasi eksekusi sementara data engineer manusia mencapai kira-kira 93%, dan itu bahkan sebelum satu soal izin akses atau definisi metrik yang diperdebatkan pun masuk hitungan.

Kolom revenue mana yang benar-benar revenue?

Inilah versi paling tajam dari masalahnya: ambiguitas yang tidak terlihat seperti ambiguitas. Join yang salah menghasilkan hasil yang jelas rusak: jumlah baris yang absurd, null di tempat yang seharusnya tidak ada. Definisi metrik yang salah menghasilkan angka yang masuk akal. Tidak ada yang mengecek ulang angka yang terlihat benar, jadi definisi yang salah itu bertahan, terus dipakai, dan akhirnya dipertanyakan di rapat ketika dua orang menjalankan "query yang sama" dan mendapat jawaban berbeda.

Ambiguitas yang sama muncul di join. "Tunjukkan penjualan per distributor" mengasumsikan jalur tertentu lewat skema: tabel mana yang memegang relasi distributor, apakah satu distributor bisa masuk ke lebih dari satu wilayah, apakah order yang diretur masih dihitung sebagai penjualan. Tidak ada dari itu yang tertulis di skema. Semuanya ada di kepala orang yang membangun sistemnya, dan model yang hanya membaca nama tabel dan kolom tidak punya akses ke situ.

Orang ini boleh melihat apa?

Kegagalan ketiga sama sekali bukan soal kebenaran. Ini soal paparan data. Model yang bisa menulis SQL apa pun ke database yang berjalan, pada prinsipnya, bisa menulis query yang mengembalikan baris yang tidak seharusnya dilihat penanya: margin wilayah lain, biaya headcount departemen lain, daftar pelanggan pengguna lain. Text-to-SQL naif mengeksekusi query apa pun yang ia hasilkan dengan akses apa pun yang dimiliki koneksi di baliknya — yang dalam praktiknya biasanya jauh lebih luas dari izin sebenarnya pengguna itu.

Ini bukan kasus tepi yang hipotetis; ini perilaku default dari setup naif. Seorang staf yang bertanya hal biasa seharusnya mendapat jawaban yang dibatasi sesuai apa yang boleh ia lihat, sama seperti dashboard atau laporan membatasinya — dan pembatasan itu harus terjadi terlepas dari apakah cara orang itu memfrasakan pertanyaannya menunjukkan ia sedang mencoba melihat lebih dari yang seharusnya.

Dialect drift dan target yang terus bergerak

Ada kegagalan lain yang lebih senyap: skema berubah. Kolom diganti nama, tabel dipecah, bisnis menambah wilayah baru dengan keunikannya sendiri. Dialek SQL berbeda antar database dengan cara yang berpengaruh untuk aritmetika tanggal, penanganan string, dan paginasi. Model yang meregenerasi SQL segar setiap kali terhadap skema yang dibacanya ulang, cepat atau lambat akan menghasilkan query yang jalan, mengembalikan hasil, dan salah dengan cara yang tidak disadari siapa pun sampai angkanya tidak cocok. Regenerasi tanpa lapisan makna yang stabil di baliknya cuma memindahkan titik kegagalannya — bukan menghilangkannya.

Apa yang sebenarnya membuat text-to-SQL bisa diandalkan?

Semua ini bukan berarti text-to-SQL harus ditinggalkan. Artinya, model butuh sesuatu di baliknya yang tidak bisa disediakan koneksi database polos: lapisan yang sudah tahu kolom revenue mana yang benar-benar revenue, bagaimana tabel di-join dalam istilah bisnis Anda, dan apa yang boleh dilihat penanya spesifik ini — sebelum satu query pun ditulis. Pendekatan riset untuk masalah ini bertumpu pada schema-linking, yaitu langkah memetakan entitas yang disebut dalam pertanyaan ke tabel dan kolom persis yang menyimpannya. Pemetaan itu jauh lebih bisa diandalkan begitu semantic layer sudah menetapkan definisinya daripada saat model harus menebaknya lagi dari nol di setiap query.

Itulah tugas semantic layer: kamus bersama berisi definisi metrik, hubungan entitas, dan aturan sistem-mana-yang-menang yang menyelesaikan ambiguitas yang tidak bisa dipecahkan model sendirian. Dengan itu di tempatnya, tugas model menyempit dari "menebak maksud bisnis" menjadi "menerjemahkan pertanyaan jadi query terhadap makna yang sudah didefinisikan" — pekerjaan yang jauh lebih kecil dan jauh lebih bisa diandalkan. Ini alasan yang sama di balik perbandingan jujur RAG, fine-tuning, dan intelligence layer: menjangkarkan jawaban ke sesuatu yang sudah didefinisikan lebih dulu lebih baik daripada berharap model menebaknya dengan benar saat itu juga.

Eksekusi yang terkontrol sama pentingnya dengan definisinya. Setiap query yang dihasilkan seharusnya melewati pemeriksaan izin yang sama dengan laporan yang dibaca manusia, dibatasi sesuai peran penanya, sebelum menyentuh database sama sekali. Dan jawaban yang bisa dipercaya menunjukkan cara kerjanya: tabel mana yang di-query, definisi mana yang dipakai, sehingga CFO yang skeptis bisa memverifikasi, bukan sekadar percaya. Kombinasi ini (definisi, eksekusi terkontrol, sumber yang terlihat) adalah yang coba disediakan AI intelligence layer, dengan text-to-SQL sebagai satu kemampuan di dalamnya, bukan seluruh arsitekturnya.

Text-to-SQL naif vs. pembuatan query yang terkontrol

Kapan metrik tersimpan mengalahkan regenerasi

Ini catatan jujurnya: bahkan text-to-SQL yang terkontrol pun tidak selalu jadi alat yang tepat. Kalau satu pertanyaan ditanyakan setiap minggu dengan bentuk yang sama ("berapa net revenue per wilayah bulan lalu"), meregenerasi query untuk itu tiap kali adalah kerja yang sebenarnya bisa dihindari, dan memperkenalkan kembali sedikit peluang melenceng setiap kali dijalankan. Untuk pertanyaan yang sudah terdefinisi jelas dan berulang, metrik tersimpan yang menjalankan query yang sama dan sudah teruji lebih unggul daripada meminta model menyusunnya ulang dari nol setiap kali. Text-to-SQL layak dipakai justru untuk pertanyaan yang tidak sempat didefinisikan lebih dulu — yang mendadak, yang eksploratif, follow-up "tunggu, kenapa angka ini bergerak". Pelaporan yang berulang lebih pantas dapat metrik, bukan regenerasi.

Di mana posisi Nalar

Nalar memperlakukan text-to-SQL sebagai satu alat di dalam intelligence layer yang terkontrol, bukan trik yang berdiri sendiri. Agennya menghasilkan query terhadap model semantik yang sudah mendefinisikan metrik dan hubungan entitas Anda, mengeksekusinya di bawah izin yang sama dengan yang ditegakkan dashboard Anda, dan menunjukkan sumber serta definisi mana yang menghasilkan sebuah jawaban, dengan pertanyaan berulang dilayani sebagai metrik tersimpan, bukan diregenerasi dari nol setiap kali.

Kalau Anda ingin melihat bagaimana ini berjalan di atas perusahaan tiruan yang realistis, demo interaktifnya terbuka untuk dicoba. Kalau Anda belum yakin apakah data dan definisi Anda sendiri sudah siap untuk ini, BARI, diagnostik kesiapan AI kami, akan menjawab dengan jujur — termasuk saat jawabannya "belum."