- Fitur text-to-SQL berbasis Gemini dimanfaatkan di seluruh Google Cloud untuk meningkatkan produktivitas developer dan pengguna nonteknis
- Di lingkungan nyata, pembuatan SQL yang akurat sulit dilakukan karena kurangnya konteks bisnis, sulitnya menafsirkan niat pengguna, dan perbedaan dialek SQL
- Untuk mengatasinya, Google memperkenalkan teknik seperti pencarian data cerdas, pembelajaran berbasis konteks, dan pelapisan semantik
- Keterbatasan model itu sendiri diatasi dengan pembuatan multi-output lalu memilih yang terbaik (self-consistency), validasi lalu re-prompt, serta pelatihan per dialek SQL
- Untuk evaluasi dan pengukuran peningkatan, Google memanfaatkan benchmark internal dan teknik menggunakan LLM sebagai penilai agar lebih siap diterapkan di lingkungan nyata
Techniques for improving text-to-SQL
Dari teks ke SQL: kondisi saat ini di Google Cloud
- Organisasi memanfaatkan SQL untuk mendapatkan insight data yang cepat dan akurat
- Gemini menyediakan fitur text-to-SQL yang menghasilkan SQL langsung dari bahasa alami
- Fitur ini berguna bukan hanya bagi developer, tetapi juga bagi pengguna nonteknis
- Saat ini fitur tersebut tersedia di BigQuery Studio, Cloud SQL Studio, AlloyDB Studio, Vertex AI, dan lainnya
Tantangan utama teknologi Text-to-SQL
1. Sulitnya menyediakan konteks bisnis
- Untuk menulis SQL yang akurat, LLM perlu diberi konteks yang memadai seperti struktur database, makna kolom, dan isi data aktual
- Konteks mencakup informasi eksplisit (seperti skema dan informasi kolom) serta informasi implisit (seperti makna bisnis dari data tertentu)
- Terus melatih ulang (fine-tuning) LLM agar mengikuti struktur database, perubahan dataset, dan perubahan skema bukanlah pendekatan yang realistis karena biayanya tinggi
- Pengetahuan bisnis atau informasi semantik sering kali tidak terdokumentasi dengan baik, dan mengubahnya menjadi data pelatihan juga sulit
- Contoh: jika DBA tidak mengetahui arti
cat_id2 = 'Footwear' pada tabel pcat_extension, maka ia juga tidak bisa menulis SQL untuk menelusuri penjualan sepatu — hal yang sama berlaku pada LLM; jika konteks kurang, ada risiko menghasilkan kueri yang tidak akurat
2. Masalah penafsiran niat pengguna
- Kueri bahasa alami sering kurang jelas dibandingkan SQL
- Dalam praktiknya, analis data atau engineer bisa memperjelas pertanyaan yang ambigu dengan pertanyaan lanjutan, tetapi LLM cenderung langsung mencoba menjawab pertanyaan yang diberikan sehingga berisiko menghasilkan informasi keliru (hallucination)
- Pada pertanyaan seperti “sepatu yang paling banyak terjual?”, detail seperti definisi “paling banyak terjual” (jumlah pesanan, pendapatan, dan sebagainya) atau jumlah hasil yang diinginkan masih ambigu
- Pengguna yang punya kemampuan teknis bisa memakai SQL perkiraan sebagai titik awal, tetapi bagi nonspesialis, SQL yang benar-benar berjalan dengan tepat jauh lebih penting
- Agar dapat bekerja efektif, LLM perlu mendukung pertanyaan lanjutan, penjelasan penalaran, dan panduan pengguna untuk memahami niat pengguna dengan lebih jelas
3. Keterbatasan generasi oleh LLM
- LLM unggul dalam hal seperti merangkum dokumen dan mengekstrak informasi, tetapi masih punya kelemahan pada sintaks SQL yang presisi atau fitur SQL yang jarang digunakan
- Sintaks berbeda untuk tiap dialek SQL, dan perbedaan kecil pun menuntut akurasi tinggi
- Contoh: di BigQuery digunakan
EXTRACT(MONTH FROM timestamp_column), sedangkan di MySQL harus memakai MONTH(timestamp_column)
- Menghasilkan SQL yang secara konsisten mematuhi spesifikasi yang kompleks bukanlah tugas mudah bagi LLM
Teknik Google Cloud untuk meningkatkan Text-to-SQL
Masalah: skema dan konteks bisnis
- Pencarian dan pemeringkatan berbasis semantik
- Pembelajaran in-context
- Sampling dan pengaitan data
- Membangun lapisan semantik
- Analisis pola penggunaan dan riwayat
Masalah: penafsiran niat pengguna
- Klarifikasi melalui LLM
- Mengidentifikasi entitas, memeriksa informasi terkait, lalu mengarahkan pertanyaan lanjutan yang sesuai
Masalah: mengatasi keterbatasan LLM
- Self-consistency untuk menghasilkan banyak kueri lalu memilih yang terbaik
- Validasi dan re-prompt
- Pembelajaran berbasis konteks dengan contoh dialek SQL
- Fine-tuning model
Contoh penerapan teknologi utama
Model yang sadar SQL
- Gemini menggunakan berbagai versi fine-tuning untuk menghasilkan SQL berkualitas tinggi
- Untuk memastikan akurasi per dialek SQL, dilakukan kombinasi versi model dan penyesuaian khusus
Klarifikasi pertanyaan pengguna (Disambiguation)
- Jika pertanyaan ambigu, sistem akan menghasilkan pertanyaan klarifikasi
- Contoh: "sepatu yang paling laris?" → diarahkan menjadi “berdasarkan jumlah pesanan atau berdasarkan pendapatan?”
Pencarian berbasis semantik dan pembangunan konteks
- Pencarian vektor berbasis pencocokan semantik bertahap untuk mengidentifikasi tabel dan kolom yang relevan
- Prompt disusun dengan memasukkan riwayat kueri pengguna, contoh aturan bisnis, dan lainnya
- Dukungan jendela konteks yang panjang memungkinkan penanganan skema berskala besar
Validasi dan regenerasi
- Kesalahan eksplisit dideteksi melalui parsing, dry-run, dan lainnya pada kueri yang dihasilkan LLM
- Jika kesalahan terdeteksi, perbaikan diarahkan lewat re-prompt
Self-consistency
- Alih-alih satu kueri, sistem menghasilkan banyak kueri dengan berbagai pendekatan
- Jika beberapa model merekomendasikan kueri yang sama, akurasi meningkat
Evaluasi dan pengukuran performa
- Benchmark yang ada (seperti BIRD-bench) memang berguna, tetapi memiliki keterbatasan dalam merefleksikan skema dunia nyata
- Google membangun kumpulan benchmark sintetis miliknya sendiri
Strategi evaluasi
- Mencakup dialek SQL dan fitur per engine: termasuk bukan hanya kueri, tetapi juga DDL, DML, dan tugas administrasi
- Metrik evaluasi: respons pengguna, metrik offline, LLM-as-a-judge
- Evaluasi berkelanjutan: memungkinkan validasi cepat atas efektivitas model baru dan teknik prompt baru
Penutup
1 komentar
Komentar Hacker News
Ada pemikiran tentang tujuan akhir dari konversi teks ke SQL: apakah tujuannya membuat alat bantu untuk analis data, atau memperoleh insight bisnis tanpa melalui analis; jika yang kedua, maka seberapa pun canggihnya, tetap ada masalah bahwa orang nonspesialis mustahil menilai akurasi dan kecukupan SQL, dan pertanyaan seperti "mengapa transaksi e-commerce kemarin hanya mencapai 80%?", "mengapa biaya akuisisi pelanggan meningkat?", "mengapa kampanye New York berkinerja lebih buruk dibanding San Francisco?" berada di luar cakupan text2sql
Dalam praktiknya tampaknya lebih dekat ke tujuan kedua, tetapi hasilnya belum memenuhi harapan; di bisnis, orang ingin bisa mengubah laporan di tahap akhir, tetapi karena kekurangan analis mereka tidak bisa mendapatkan informasi yang diinginkan tepat waktu; orang mencoba menyelesaikannya dengan "kecepatan tak terbatas", padahal masalah sebenarnya muncul karena kurang memikirkan metrik dengan cukup matang; data itu kompleks, pengetahuan bisnis tersimpan secara implisit di luar sistem, dan infrastruktur data kurang memadai sehingga analisis memakan waktu lama; para pemimpin analitik yang cerdas memanfaatkan hype AI untuk berinvestasi pada infrastruktur dasar
Menurut saya pertanyaan-pertanyaan di atas sejak awal memang bukan masalah yang bisa diselesaikan dengan SQL; SQL pada dasarnya menjawab "apa (what)", bukan "mengapa (why)"; tujuan text2sql adalah menghemat waktu agar analis bisa lebih cepat menyelesaikan pertanyaan "apa", sehingga mereka bisa fokus pada "mengapa"
Itu benar, tetapi menurut saya teks natural language bisa menjadi input universal bagi sistem LLM; text2sql bisa berperan sebagai fondasi pengambilan informasi untuk menyusun jawaban atas pertanyaan yang lebih kompleks; dalam jangka pendek ini adalah fitur pendamping kerja, tetapi dalam jangka panjang tujuannya adalah membangun dasar untuk otomatisasi, perbandingan hasil, dan integrasi ke workflow yang lebih besar; yang penting adalah menyiapkan fondasi untuk menjawab pertanyaan-pertanyaan seperti itu; masih banyak yang harus dikerjakan
Algoritme apa pun bisa dibuat dan diuji jika manusia bisa melakukannya; jika ada 10 analis, maka pemahaman mereka tentang database dan bisnis, serta tingkat keahliannya, semuanya berbeda; otomatisasi setidaknya menyediakan standar yang menjamin tingkat kemampuan dan pengetahuan minimum; analis baru pun bisa langsung menghasilkan kinerja yang lebih baik; mengembangkan sistem sambil berkolaborasi dengan pakar, lalu mengujinya, dan membuat AI menafsirkan trade-off, bug, serta membandingkan dengan hasil yang diharapkan adalah tujuan yang berguna; insight atau ‘taste’ sulit diotomatisasi, tetapi pakar domain bisa melangkah sangat jauh jika memiliki otomatisasi yang dirancang dengan baik dan intuisi terhadap hasil yang masuk akal; ini tidak sempurna, tetapi itulah tujuan saya
Berbagi pengalaman memakai model OpenAI 4o; prompt diberi panduan bisnis, istilah industri, serta penjelasan tabel dan foreign key; lalu model dapat menghasilkan query join yang kompleks dan mengembalikan hasilnya; tujuannya adalah memberikan hasil bagi pengguna yang tidak tahu SQL, tetapi SQL-nya sendiri juga ditampilkan sebagai referensi
AI tidak harus menghasilkan SQL yang sempurna; dalam kasus saya, meskipun output-nya bisa divalidasi dengan kode, saya tidak akan menyalin dan memakainya begitu saja karena risiko perbedaan makna yang halus; sebagai gantinya, AI memberi pendekatan, lalu saya menjadikannya referensi untuk menulis SQL sendiri dari awal
Berbagi pengalaman memakai Gemini terbaru di Google AI Studio; benar-benar sangat mengesankan dan revolusioner; hasil coding dari Claude dan ChatGPT terasa seperti datang dari abad yang berbeda; baru sebulan lalu saya menganggap Claude luar biasa, tetapi sekarang saya tidak tahu bagaimana bisa terus coding tanpa Google Gemini; Gemini AI Studio adalah lompatan besar dalam pemrograman
Saya heran lebih banyak orang belum menyadari perubahan ini; Claude juga bagus untuk tugas kecil, tetapi ketika berkembang menjadi masalah kompleks, Gemini jauh lebih unggul; kemampuan menangani konteksnya sangat mengesankan; saya tidak hanya memakainya sebagai coding agent, tetapi juga untuk beta reading naskah 85.000 kata, dan menerima laporan umpan balik setingkat pakar hampir secara real-time
Minggu ini saya merasa mode penalaran di Gemini Pro gratis seperti dinonaktifkan; kalau dihentikan tepat sebelum mulai menulis kode, atau dijaga agar tidak terlalu menggeneralisasi, model ini cukup berguna; hanya saja Gemini cenderung menulis kode secara berlebihan; cara utama saya memakainya adalah untuk eksplorasi desain melalui Gemini tanpa terikat pada implementasi kode; misalnya saat membuat layanan berlangganan dengan Stripe, saya bisa menerima data yang sudah ada sesuai konteks tech stack dan use case saya, dan bahkan mengubah arah desain sebelum menulis satu baris kode pun
Jawabannya adalah “gunakan semantic layer”; ini yang paling efektif untuk menyampaikan konteks yang benar dan merupakan titik optimal untuk campur tangan manusia; jika manusia mendefinisikan semua metrik inti dengan jelas, LLM bisa memanfaatkannya kapan saja; misalnya jika MAU sudah didefinisikan, LLM akan membuat query berdasarkan definisi itu; jika query ditulis dalam JSON alih-alih SQL, LLM menghasilkan hasil yang jauh lebih konsisten; kami memakai cube, semantic layer open source terbaik; ada juga opsi closed-source dari Naver; perusahaan saya dulu pernah menulis blog terkait, tetapi sekarang perusahaan pemiliknya sudah berhenti meng-hosting-nya
Berbahaya memakai AI untuk membuat SQL di pekerjaan nyata; orang yang tidak tahu SQL bisa menulis query yang salah dan memberi dampak serius pada server; di tim kami, database-nya besar menurut kebanyakan developer, meski tidak benar-benar raksasa; kadang kami meminta AI memperbaiki query yang sudah dioptimalkan, tetapi AI tidak pernah memberi jawaban yang lebih baik; terkadang AI mengigau atau memberi saran yang sebenarnya tidak berguna; rasanya seperti burung beo bodoh yang mengulang cerita yang pernah didengarnya
Rasanya fitur AI untuk mengubah teks menjadi regular expression akan sangat praktis
Dari semua alat AI yang pernah saya coba, yang paling mengecewakan adalah Gemini bawaan BigQuery; nama kolomnya sudah jelas dan deskripsinya juga bagus, tetapi tetap tidak mendekati penyelesaian masalah sama sekali
Bahasa yang paling banyak saya pakai untuk menulis query sejauh ini adalah SQL; meskipun saya meminta AI menulis query, waktu yang dibutuhkan untuk merapikan hasilnya jauh lebih lama dibanding jika saya menulisnya sendiri; secara terpisah, akan menyenangkan jika ada satu fitur yang benar-benar membuat penulisan SQL jauh lebih cepat; DSL di perusahaan kami punya operator untuk auto-join berdasarkan foreign key dan itu sangat nyaman; bagian paling merepotkan saat menulis SQL adalah harus menuliskan 10, 20, atau lebih klausa join satu per satu; bagian lain tidak terlalu sulit dibanding itu
Dari pengalaman saya, kalau constraint yang jelas dan foreign key tertata dengan baik, hampir semuanya terselesaikan; setiap tabel harus punya constraint yang jelas agar AI bisa memahami seluruh struktur koneksi secara akurat; SQL punya spesifikasi yang sangat presisi, tetapi justru karena itu, jika constraint dan foreign key tidak terdefinisi dengan baik, AI tidak bisa memberi jawaban yang akurat
Di semua foundation model, ini sudah menjadi cukup sederhana; kalau komentar pada schema tabel ditulis dengan baik, permintaan pembuatan query jadi mudah
Kalau membuat scaffolding di sekitar model dengan library smolagents, ini cukup praktis; ada juga tulisan yang mengatakan bahwa text2sql terlihat sederhana sebagai demo, tetapi sangat sulit diterapkan pada kasus nyata yang kompleks
Step 1: schema punya ribuan tabel dan hampir tidak ada komentar, Step 2...
Saya benar-benar setuju; sekarang ini sudah tidak terlalu terasa ajaib; DDL pembuatan tabel sebenarnya hampir merupakan deskripsi tabel yang akurat sehingga nyaris tidak perlu tambahan lagi; kalau hanya menjelaskan query yang dibutuhkan secara rinci, kebanyakan LLM dapat dengan mudah menghasilkan query
Ada referensi yang sangat bagus seperti awesome-Text2SQL dan Awesome-code-llm > Benchmarks > Text to SQL, yang disebut dalam tulisan "Show HN: We open sourced our entire text-to-SQL product" (2024)