Direktur bertanya, “Berapa penjualan bersih bulan lalu per cabang?” Model menghasilkan SQL yang berjalan tanpa error dan menampilkan tabel rapi. Namun, hasilnya dapat tetap salah jika invoice dihitung berulang karena join, retur tidak dikurangkan, atau periode memakai tanggal pembuatan pesanan. Text-to-SQL perlu dinilai dari kebenaran bisnis dan batas akses, bukan hanya keberhasilan menjalankan kueri.
Artikel ini ditujukan kepada BI lead, finance controller, dan kepala IT yang ingin membuka akses pertanyaan bahasa alami ke data ERP. Cakupannya adalah kueri baca dan verifikasi hasil; tidak mencakup izin bagi model untuk mengubah transaksi, menyetujui pembayaran, atau mengakses seluruh database.
Apa Itu Text-To-SQL?
Text-to-SQL menerjemahkan pertanyaan bahasa alami menjadi pernyataan SQL. Tutorial IBM menunjukkan bagaimana konteks tabel, kolom, dan hubungan data membantu model menyusun kueri. Contoh tutorial tidak otomatis membuktikan ketepatan pada struktur ERP, dialek database, atau definisi bisnis perusahaan lain.
SQL merupakan cara menanyakan data terstruktur. RAG dokumen membantu mengambil konteks dari sumber, tetapi pencarian paragraf bukan pengganti perhitungan agregasi transaksi. Keduanya dapat dipadukan untuk menjelaskan definisi metrik dan memilih struktur data yang relevan, dengan kontrol berbeda untuk pengambilan dokumen dan eksekusi kueri.
Alur pertanyaan, penyusunan kueri, validasi, eksekusi baca, dan tampilan hasil dapat dirancang sebagai workflow tetap. Jika AI agent memakai alat kueri secara dinamis, kewenangannya tetap harus dibatasi. Kemampuan memilih alat bukan alasan memberi akses tulis ke ERP.
Definisikan Pertanyaan Sebelum Memilih Model
Istilah “penjualan” dapat berarti pesanan masuk, invoice, nilai setelah retur, atau penerimaan kas. Pemilik metrik perlu menetapkan sumber transaksi, status yang dihitung, perlakuan pajak dan diskon, mata uang, periode, serta entitas yang termasuk. Nama kolom saja tidak cukup untuk menjelaskan semua itu.
Untuk pertanyaan yang belum jelas, sistem sebaiknya meminta klarifikasi atau menawarkan definisi yang sudah disetujui. Misalnya, “Gunakan nilai invoice bersih setelah retur, tanpa pajak, berdasarkan tanggal posting?” Jangan diam-diam memilih definisi berbeda setiap kali pengguna bertanya.
Mulai dari daftar pertanyaan berulang yang sudah memiliki laporan pembanding. Tim finance dapat menyediakan hasil acuan, sementara BI mendokumentasikan aturan agregasi. Pertanyaan yang belum memiliki definisi resmi menjadi pekerjaan pemetaan, bukan langsung bahan demonstrasi AI.
Gunakan Lapisan Data Yang Terkendali
Hindari membuka seluruh tabel operasional. Siapkan view atau model semantik yang menyederhanakan objek bisnis, menjaga granularitas, dan menjelaskan relasi. Contohnya, satu baris per invoice berbeda dari satu baris per item invoice. Ukuran yang berasal dari header dapat terhitung berulang ketika digabung dengan detail.
Katalog yang diberikan kepada model perlu mencakup arti kolom, tipe data, satuan, kunci, hubungan, nilai status, dan contoh pertanyaan yang telah disetujui. Jangan memasukkan data pribadi atau rahasia hanya agar prompt terasa lengkap. Batasi konteks pada struktur dan definisi yang dibutuhkan pengguna.
Pemetaan ke sistem ERP dan sumber lain perlu mempertimbangkan keterlambatan sinkronisasi. Replika atau data warehouse dapat mengurangi beban sistem transaksi, tetapi hasil perlu menampilkan waktu pembaruan. “Data terbaru” harus merujuk pada batas kesegaran yang benar-benar diketahui.
Cegah Kesalahan Hitung Yang Tampak Meyakinkan
Contoh ilustratif: invoice senilai Rp10 juta mempunyai dua baris barang. Jika kueri melakukan join header ke detail lalu menjumlahkan nilai header, hasilnya dapat menjadi Rp20 juta. Kueri itu sah secara sintaks dan mungkin berjalan cepat; kesalahannya terletak pada granularitas.
Kasus lain adalah menggabungkan dua tabel detail sekaligus, sehingga jumlah baris membesar. Uji contoh satu-ke-banyak dan banyak-ke-banyak secara sengaja. Periksa pula transaksi batal, retur sebagian, nilai negatif, duplikasi impor, serta kolom kosong. Kueri yang benar pada data sederhana belum tentu benar pada operasi nyata.
Periode perlu didefinisikan dengan zona waktu dan batas tanggal yang konsisten. “Bulan lalu” harus diselesaikan terhadap tanggal pengamatan, lalu ditampilkan sebagai rentang yang pasti. Untuk grup multi-entitas, jangan menjumlahkan mata uang berbeda tanpa aturan kurs dan tanggal konversi.
Otorisasi Berada Di Luar Prompt
Identitas pengguna harus menentukan entitas, cabang, baris, dan kolom yang boleh dibaca. Terapkan pembatasan pada database atau layanan eksekusi tepercaya. Perintah “jangan tampilkan data HR” di prompt tidak cukup untuk menggantikan kebijakan akses.
Akun eksekusi pilot sebaiknya hanya memiliki akses baca pada objek yang telah disetujui. Validasi struktur SQL dan izinkan operasi yang diperlukan saja. Larang perintah tulis, pemanggilan fungsi yang tidak diizinkan, dan akses objek di luar daftar. Pemeriksaan kata terlarang semata mudah melewatkan variasi sintaks; gunakan penguraian dan kontrol eksekusi yang sesuai.
Batasi waktu eksekusi, jumlah hasil, dan penggunaan sumber daya. Kueri SELECT sekalipun dapat sangat berat atau mengekstrak terlalu banyak data. Hasil kecil juga belum tentu aman: agregasi kelompok sangat kecil bisa mengungkap informasi individu. Kebijakan detail dan agregasi perlu disepakati sesuai sensitivitas data.
Alur Pilot Yang Dapat Diaudit
- Terima pertanyaan dan identitas pengguna dari kanal yang terverifikasi.
- Tentukan metrik, periode, dan cakupan; minta klarifikasi bila ambigu.
- Berikan konteks skema yang diizinkan kepada model.
- Validasi kueri, hak akses, perkiraan beban, dan objek yang digunakan.
- Jalankan melalui layanan baca yang dibatasi, lalu simpan jejak eksekusi.
- Tampilkan hasil bersama definisi, periode, filter, dan waktu pembaruan.
- Sediakan review atau eskalasi jika hasil menyimpang dari laporan acuan.
Untuk keputusan keuangan material, hasil perlu diverifikasi oleh PIC yang berwenang sebelum dipakai. Penjelasan model tentang alasan memilih SQL dapat membantu pembacaan, tetapi bukan bukti kebenaran kueri. Simpan kueri yang benar-benar dieksekusi, versi definisi, parameter, dan waktu, dengan retensi log yang sesuai kebijakan.
Evaluasi Kebenaran Hasil, Bukan Bentuk SQL Saja
Bangun kumpulan pertanyaan dengan jawaban acuan yang diverifikasi finance dan BI. Dua kueri berbeda dapat menghasilkan jawaban benar, sehingga kesamaan teks SQL bukan satu-satunya ukuran. Sebaliknya, SQL yang identik dapat memberi hasil berbeda bila data atau definisi berubah.
Nilai ketepatan angka dan dimensi, keberhasilan meminta klarifikasi, penolakan akses di luar cakupan, waktu respons, serta beban review manusia. Sertakan pertanyaan menyesatkan yang meminta seluruh cabang atau data pribadi di luar hak pengguna. Tidak ada hasil pada suatu pengujian akses harus disertai bukti bahwa kebijakan bekerja, bukan sekadar kueri kebetulan gagal.
Mulai dengan hasil yang wajib ditinjau sebelum dipakai. Perluasan penggunaan bergantung pada hasil per jenis pertanyaan dan risiko keputusan. Pertanyaan di luar cakupan sebaiknya diarahkan ke laporan resmi atau analis, alih-alih selalu dipaksakan menghasilkan angka.
TCO Dan Keputusan Implementasi
Perhitungan biaya mencakup pemodelan data, definisi metrik, layanan model, penyimpanan log, kontrol akses, komputasi database, evaluasi, dan perubahan skema. Waktu yang dihemat pengguna harus dibandingkan dengan waktu review serta pemeliharaan. Harga token saja tidak mewakili biaya implementasi.
Untuk memulai, bawa beberapa pertanyaan berulang, contoh laporan acuan, batas akses, dan diagram sumber data ke diskusi kebutuhan Layana.ID. Tim dapat memetakan pilot AI bisnis dan integrasi data dengan keluaran serta kriteria penerimaan yang jelas.
Referensi
IBM Developer: Generating SQL From Text With LLMs menjadi rujukan mekanisme penyusunan SQL dengan konteks skema. Contoh perhitungan, kontrol akses, dan rancangan evaluasi merupakan analisis penerapan artikel ini, bukan klaim kemampuan produk tertentu.
Gambar merupakan ilustrasi AI, bukan tampilan sistem atau laporan pelanggan Layana.ID.