ترکیب Hugging Face و Streamlit برای تبدیل زبان طبیعی به کد SQL

«تمام کارکنان IT را بر اساس حقوق، از زیاد به کم نشان بده». این درخواست ساده اکنون جایگزین نیاز به نوشتن دستی دستورات پیچیده مانند SELECT name, salary FROM employees WHERE department = 'IT' ORDER BY salary DESC; شده است. در ۱۰ ژوئیه ۲۰۲۶، یک توسعه‌دهنده نقشه راهی را منتشر کرد که نشان می‌دهد چگونه ترکیب Hugging Face و Streamlit می‌تواند زبان طبیعی را به کدهای اجرایی تبدیل کند و نیاز کاربر به یادگیری SQL برای پرس‌وجو از پایگاه‌های داده را به‌طور مؤثر از بین ببرد.

این تغییر، گلوگاه بحرانی در حوزه هوش تجاری (Business Intelligence) را هدف قرار داده است. بسیاری از سازمان‌ها حجم عظیمی از داده‌های ساختاریافته را در پایگاه‌های داده رابطه‌ای ذخیره می‌کنند، اما تنها بخش کوچکی از کارکنان — که معمولاً تحلیلگران داده و مدیران پایگاه‌داده (DBA) هستند — قادر به استخراج این اطلاعات هستند.

زمینه: موارد استفاده در دنیای واقعی

هوش مصنوعی اکنون امکان استخراج اطلاعات را برای بخش‌های مختلف سازمان با استفاده از زبان طبیعی فراهم می‌کند:

• مدیران فروش: بررسی روندهای درآمد ماهانه.
• بخش‌های منابع انسانی: تحلیل پرونده‌های کارکنان.
• تیم‌های مالی: تولید گزارش‌های پیچیده.
• پشتیبانی مشتریان: جست‌وجو در تاریخچه سفارشات.
• بهداشت و درمان: استخراج پرونده‌های بیماران توسط پزشکان.
• بانکداری: خلاصه‌سازی تراکنش‌ها توسط تحلیلگران.
• تجارت الکترونیک: پاسخ به سوالاتی مانند «کدام محصولات ماه گذشته بیشترین فروش را داشتند؟»

طبق راهنمای منتشرشده در dev.to، معماری این سامانه از یک گردش‌ workflow پنج‌مرحله‌ای خطی پیروی می‌کند: دریافت ورودی کاربر، ترجمه توسط مدل زبانی بزرگ (LLM)، تولید کد SQL، اجرای کد در پایگاه‌داده و در نهایت نمایش نتایج در داشبورد. این زیرساخت بر پایه چندین کتابخانه کلیدی بنا شده است:

جزئیات: پشته فنی (Technical Stack)

• Hugging Face Transformers: به‌طور مشخص از مدل tscholak/1wnr382e استفاده شده است که بر پایه معماری T5 برای نگاشت توالی به توالی (sequence-to-sequence) طراحی شده است. این رویکرد یادآور تلاش‌های پیشین برای بهبود دقت تبدیل زبان طبیعی است، به‌ویژه زمانی که مدل T5-WikiSQL با استفاده از متدهای سفارشی تلاش کرد خطاهای رایج در تولید کوئری‌ها را کاهش دهد.
• Streamlit: مسئول مدیریت رابط کاربری برای دریافت پرس‌وجوهای کاربر و نمایش داده‌ها از طریق دستورات st.text_input و st.dataframe است.
• SQLAlchemy و SQLite: برای مدیریت اتصال به پایگاه‌داده نمونه به‌کار می‌روند. در این راهنما، برای مقداردهی اولیه سیستم از دستور create_engine("sqlite:///company.db") استفاده شده است.
• Pandas: برای خواندن نتایج SQL از طریق دستور pd.read_sql(sql, engine) و رندر کردن آن‌ها به صورت جداول (dataframe) در داخل اپلیکیشن استفاده می‌شود.

برای تضمین دقت، سیستم مدل را به یک طرح‌واره (Schema) مشخص متصل می‌کند؛ مثلاً جدولی از کارکنان که شامل شناسه‌ها (ID)، نام‌ها، دپارتمان‌ها و حقوق است. به عنوان مثال، داده‌های نمونه شامل «آلیس» (IT، ۷۵۰۰)، «باب» (فروش، ۵۲۰۰) و «کارول» (IT، ۸۹۰۰) است. وقتی کاربر می‌پرسد «بیشترین حقوق‌بگیر کیست؟»، مدل T5 کد SQL متناظر را تولید می‌کند و سپس SQLAlchemy آن را روی فایل SQLite اجرا می‌کند تا رکورد مورد نظر فوراً استخراج شود.

ادغام این ابزارها ثابت می‌کند که مدل‌های زبانی بزرگ (LLM) در حال عبور از محیط‌های چت ساده و ورود به نقش‌های فعال «استفاده از ابزار» هستند. این پیاده‌سازی نشان می‌دهد مدل‌های وزن‌های باز (Open Weights) — یعنی مدل‌هایی که ساختار آن‌ها علناً منتشر شده — اگر در یک خط لوله کنترل‌شده قرار بگیرند، می‌توانند وظایف داده‌های ساختاریافته را به‌خوبی مدیریت کنند.

با این حال، توسعه‌دهنده هشدار می‌دهد که اجرای SQL تولیدشده توسط هوش مصنوعی در محیط‌های عملیاتی (Production) خطرناک است. ریسک اصلی، نبودِ اعتبارسنجی است؛ یک مدل ممکن است در صورت عدم محدودسازی، دستوراتی مانند DROP TABLE (حذف کامل جدول) تولید کند.

امنیت و بهترین روش‌ها

برای کاهش مخاطرات، در این راهنما توصیه‌های زیر ارائه شده است:

• محدود کردن دسترسی‌ها: دسترسی به پایگاه‌داده باید در هر زمان که ممکن است، روی حالت «فقط خواندنی» (Read-only) تنظیم شود.
• مسدود کردن دستورات: اجازه اجرای دستورات DELETE ،UPDATE ،DROP یا ALTER بدون تأیید انسانی داده نشود.
• ارائه بستر (Context): طرح‌واره پایگاه‌داده باید به‌عنوان زمینه به هوش مصنوعی ارائه شود تا عملکرد و دقت مدل بهبود یابد.
• ثبت وقایع (Audit Trails): تمام پرس‌وجوهای تولیدشده باید ثبت شوند و نحو (Syntax) کد SQL پیش از اجرا اعتبارسنجی شود.

این چارچوب، فرض قدیمی را که استخراج داده نیازمند یک واسطه فنی است، تغییر می‌دهد. با پایین آوردن سد ورود، شرکت‌ها می‌توانند چرخه‌های تصمیم‌گیری را تسریع کنند. اثر ثانویه این روند، تغییر نقش تحلیلگر داده از «نویسنده پرس‌وجو» به «تأییدکننده داده» است.

برای کسانی که به دنبال جایگزین‌های آماده تولید (Production-ready) هستند، این راهنما به پروژه‌های تثبیت‌شده‌ای مانند Vanna AI، SQLCoder و عامل‌های SQL در LangChain اشاره می‌کند که درک قوی‌تری از طرح‌واره‌ها دارند.

نسخه‌های آینده این ابزارها احتمالاً شامل ادغام تولید بازیابی‌افزا (RAG)، حافظه محادثه‌ای، تولید نمودار و پشتیبانی از پایگاه‌های داده سازمانی مانند PostgreSQL، MySQL و SQL Server خواهد بود. توسعه‌دهندگان می‌توانند با استفاده از Ollama مدل‌های محلی را интегриه‌کنند تا حریم خصوصی داده‌ها حفظ شود و هزینه‌های API حذف گردد. بررسی تعامل بین «زمینه طرح‌واره» و «دقت مدل»، گام منطقی بعدی برای هر کسی است که ابزارهای داخلی داده می‌سازد.

گام بعدی شما

• اگر ابزارهای داخلی داده می‌سازید، تعامل بین «زمینه طرح‌واره» و «دقت مدل» را آزمایش کنید.
• برای شروع سریع، مدل‌های محلی را از طریق Ollama به سیستم خود متصل کنید.
• دسترسی‌های پایگاه‌داده خود را به حالت Read-only تغییر دهید تا ریسک اجرای کدهای مخرب حذف شود.

اما تأثیر این روند بر امنیت داده‌های سازمانی حتی پیچیده‌تر است؛ به بررسی ما درباره‌ی روش‌های جدید «حفاظ‌های لایه‌ای» در مدل‌های عامل‌محور مراجعه کنید.