Text-to-SQL: ma’lumotlar bazasiga oddiy tilda savol berish

Bu qanday ishlaydi

Text-to-SQL — foydalanuvchi oddiy tilda savol yozadi, til modeli SQL so‘rov tuzadi, tizim uni bazada bajaradi va jadval yoki qisqa javob qaytaradi.

Zanjir quyidagicha:

1. Foydalanuvchi so‘raydi: «O‘tgan oyda qaysi beshta mahsulot eng ko‘p sotildi?»
2. Backend savolga baza sxemasi tavsifi va qoidalarni qo‘shadi.
3. LLM SQL qaytaradi.
4. Kod so‘rovni tekshiradi va uni faqat o‘qish huquqiga ega foydalanuvchi nomidan bajaradi.
5. Natija so‘rov matni bilan birga ko‘rsatiladi, shunda uni qayta tekshirish mumkin.

Model ma’lumotlaringizni «bilmaydi». U faqat kontekstda berilgan narsani biladi, shuning uchun sifat deyarli to‘liq tayyorgarlikka bog‘liq.

Sxema konteksti: aniqlikka eng katta ta’sir

Modelga yalang‘och CREATE TABLE berilsa, u ustunlar ma’nosini taxmin qiladi. Ko‘pincha noto‘g‘ri taxmin qiladi: status = 3 u uchun hech narsani anglatmaydi.

Nimalarni berish kerak:

• Faqat kerakli jadvallar. Savdo haqidagi savollarga log va sozlamalar jadvallari kerak emas. Ortiqcha jadvallar modelni chalg‘itadi va tokenlarni sarflaydi.
• Ustunlarning oddiy tildagi tavsifi. «amount — QQS bilan so‘mdagi buyurtma summasi», «deleted_at bo‘sh bo‘lmasa — buyurtma o‘chirilgan».
• Ma’lumotnoma qiymatlari. Qanday statuslar bor va ular nimani bildiradi.
• Jadvallar orasidagi bog‘lanishlar — qaysi kalit qaysi biriga ulanadi.
• Biznes ta’riflari. «Tushum», «faol mijoz», «o‘tgan oy» nima — yaratilgan sana bo‘yichami yoki to‘lov sanasi bo‘yichami.
• Bir nechta misol — odatiy so‘rovlar uchun «savol → to‘g‘ri SQL».

Yaxshi usul — tahlil uchun tushunarli nomli va filtrlari allaqachon qo‘llangan view’lar yaratish: o‘nlab shartli xom jadvallar o‘rniga v_paid_orders. Modelga oson, xatolar kam.

Xavfsizlik: faqat o‘qish va cheklovlar

Generatsiya qilingan SQL — oldindan aytib bo‘lmaydigan manbadan kelgan kod. Unga shunday munosabatda bo‘ling.

• Faqat SELECT huquqiga ega alohida DB foydalanuvchisi, va faqat ruxsat etilgan jadval yoki view’larga. Asosiy himoya shu, «DELETE yozma» degan prompt emas.
• Asosiy baza o‘rniga replika, agar bo‘lsa — og‘ir so‘rov ishchi tizimni sekinlashtirmasligi uchun.
• Bajarilish uchun timeout va natijadagi qatorlar soniga limit.
• Shaxsiy ma’lumotlarni yashirish. Agar menejerlarga mijozlar telefoni kerak bo‘lmasa, ular ochiq view’larda bo‘lmasligi kerak.
• So‘rovlar jurnali: kim so‘radi, qanday SQL chiqdi, qancha vaqt bajarildi.

So‘rovni ishga tushirishdan oldin tekshirish

Bajarishdan oldin so‘rovni avtomatik tekshiruvlardan o‘tkazing:

• SQL’ni parser bilan tahlil qiling va u aynan bitta SELECT (yoki WITH ... SELECT) ekanini tekshiring.
• Faqat ruxsat etilgan jadvallar ishlatilganini tekshiring.
• LIMIT bo‘lmasa, qo‘shing.
• EXPLAIN bajaring va reja juda og‘ir bo‘lsa, so‘rovni rad eting.

import sqlglot

def validate(sql: str, allowed: set[str]) -> str:
    statements = sqlglot.parse(sql, read="postgres")
    if len(statements) != 1:
        raise ValueError("Bitta so‘rov kutilmoqda")
    tree = statements[0]
    if tree.key not in ("select", "union"):
        raise ValueError("Faqat SELECT ruxsat etilgan")
    tables = {t.name for t in tree.find_all(sqlglot.exp.Table)}
    if not tables <= allowed:
        raise ValueError(f"Ruxsat etilmagan jadvallar: {tables - allowed}")
    return tree.sql(dialect="postgres")

Agar so‘rov xato bilan tugasa, xato matnini modelga bir-ikki marta qaytarib, tuzatishni so‘rash mumkin. Cheksiz takrorlash kerak emas.

Noto‘g‘ri javoblarni qanday ushlash

Eng xavflisi bajarilish xatosi emas, balki ishonarli ko‘rinadigan noto‘g‘ri javob: so‘rov ishladi, raqam normal ko‘rinadi, lekin boshqa narsa hisoblangan.

Nima yordam beradi:

• Javob yonida SQL’ni ko‘rsatish va uning mazmunini qisqa aytib berish: «1–31 mart oralig‘idagi to‘langan buyurtmalar hisoblandi».
• Javobi oldindan ma’lum bo‘lgan nazorat savollari to‘plami. Prompt, sxema yoki model har o‘zgarganda uni ishga tushiring.
• Savol noaniq bo‘lsa, aniqlashtirishni so‘rash: «tushum QQS bilanmi yoki QQSsizmi?» jim tanlovdan yaxshiroq.
• Hisobotlar bilan solishtirish. Asosiy ko‘rsatkichlarni BI yoki buxgalteriya hisoblaganlari bilan taqqoslang.
• Murakkab holatlarni yig‘ib, misollarga qo‘shish uchun «javob noto‘g‘ri» tugmasi.

Tipik xatolar

• Modelni yozish huquqi bilan asosiy bazaga ulash.
• Yuzlab jadvallardan iborat butun sxemani tavsifsiz berish.
• Biznes atamalarini aniqlamaslik — natijada «mijoz» va «tushum» turli javoblarda turlicha hisoblanadi.
• So‘rovsiz faqat raqamni ko‘rsatish — keyin uni tekshirib bo‘lmaydi.
• Text-to-SQL ko‘p bosqichli murakkab savollarda tahlilchini almashtiradi deb kutish.