اگر امروز برای مدیریت دیتابیس‌های حجیم با تأخیرهای بالا دست‌وپنجه نرم می‌کنید، باید بدانید که یک مدل زبانی کوچک می‌تواند هزینه‌ی زمانی اجرای پرس‌وجوهای شما را تقریباً نصف کند. طبق یافته‌های منتشر شده در ۱۶ سپتامبر ۲۰۲۶ توسط پژوهشگر روهان بانسال (Rohan Bansal)، یک مدل با ۴ میلیارد پارامتر توانست تأخیر اجرای پرس‌وجوها را در مقایسه با بهینه‌ساز پیش‌فرض Postgres تا ۴۴.۷٪ کاهش دهد.
بهینه‌سازی پرس‌وجو — یا همان پیدا کردن سریع‌ترین راه برای استخراج داده — مسئله‌ای دشوار است. Postgres برای تخمین هزینه هر مسیر از آمار و قواعد کلی استفاده می‌کند، اما وقتی توزیع داده‌ها یکنواخت نباشد، این تخمین‌ها شکست می‌خورند. فرصت طلایی برای هوش مصنوعی زاینده (Generative AI) — مثل دستیاری که میلیاردها مثال از کدهای موفق را دیده و حالا الگوهای برنده را می‌شناسد — دقیقاً همین‌جاست؛ چون اگرچه پیدا کردن بهترین مسیر سخت است، اما تأیید سریع بودن آن ساده است: فقط کافی است آن را اجرا کنید و زمان بگیرید.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مدل‌های زبانی کوچک اشاره کردیم، تخصص‌یافته کردن مدل‌های کم‌حجم روی وظایف خاص، نتایجی فراتر از مدل‌های غول‌پیکر به دست می‌دهد. در اینجا هم مدل یاد می‌گیرد رفتارهایی را تقویت کند که منجر به کمترین زمان اجرا می‌شوند.
پیچیدگی ترتیب اتصال (Join Ordering)
برای درک دشواری این کار، پرس‌وجویی را روی مجموعه‌داده IMDb تصور کنید که ۵ جدول مختلف را به هم متصل می‌کند. اگر بخواهید بدانید «کدام شرکت‌های ژاپنی در دهه ۲۰۰۰ بیشترین آثار را تولید کرده‌اند»، Postgres باید تصمیم بگیرد ابتدا کدام جدول را با کدام متصل کند.
به نقل از مستندات این پژوهش، اگر سیستم ابتدا شرکت‌های ژاپنی (۵٪ از کل) را فیلتر کند و سپس با آثار متصل کند، حجم داده‌های میانی کم می‌شود. اما اگر ابتدا تمام آثار دهه ۲۰۰۰ را استخراج کند، حجم داده‌ها به شدت بالا می‌رود و سیستم ۴ برابر بیشتر تلاش می‌کند. مشکل اینجاست که Postgres نمی‌تواند بدون اجرای واقعی، تعداد دقیق ردیف‌ها را بشمارد و به فرض «توزیع یکنواخت» تکیه می‌کند. اگر این فرض غلط باشد، یک اشتباه کوچک در ابتدای مسیر، کل برنامه اجرا را به شدت کند می‌کند.
انفجار ترکیبی در فضای جست‌وجو
تعداد راه‌های اجرای یک پرس‌وجوی ساده خیره‌کننده است. برای اتصال سه جدول، بهینه‌ساز باید موارد زیر را بررسی کند:
- الگوریتم‌های اتصال: Hash join، Merge join یا Nested-loop join.
- جهت‌گیری‌ها: ۸ ترکیب مختلف از ترتیب اتصال.
- انواع اسکن: Sequential، Index، Index-only یا Bitmap.
برای یک پرس‌وجوی ابتدایی، ۴۶۰۸ راه مختلف برای اجرا وجود دارد. با افزایش تعداد جداول، این فضا به شدت منبسط می‌شود. به همین دلیل است که یک مدل آموزش‌دیده می‌تواند ارزشمند باشد؛ او می‌تواند «نقشه طلایی» را برای پرس‌وجوهایی که هزاران بار تکرار می‌شوند پیدا کند و هزینه محاسباتی خود را در طول زمان سرشکن کند. این رویکرد یادگیری الگوها برای بهینه‌سازی، تفاوت بنیادینی با نحوه پردازش الگوها در موتورهای جست‌وجوی سنتی دارد که بیشتر بر پایه بازیابی مستقیم هستند تا استنتاج بهینه.
چالش نویز در اندازه‌گیری
بزرگ‌ترین مانع در آموزش این مدل، «نویز» است. در محیط لینوکس، حافظه پنهان (Cache) باعث می‌شود یک پرس‌وجو یک‌بار در ۱۸۰ میلی‌ثانیه و بار بعد در ۲۳۰ میلی‌ثانیه اجرا شود. این نوسان برای یادگیری تقویتی (RL) خطرناک است، چون مدل ممکن است به اشتباه فکر کند یک مسیر بد، به دلیل شانس و نویز سیستم، سریع‌تر بوده است.
بانسال برای حذف این نویز، یک محیط سخت‌گیرانه ساخت:
- کانتینرسازی: اجرای چهار کانتینر Postgres مجزا با محدودیت ۴ هسته CPU و ۸ گیگابایت رم.
- پروتکل گرم کردن: اجرای مکرر پرس‌وجوها تا زمانی که نرخ برخورد با حافظه (Shared Hit Blocks) به ثبات برسد.
- تنظیم حافظه: افزایش
shared_buffersبه ۲ گیگابایت برای اینکه تمام داده‌های مورد نیاز در رم جای بگیرند و نرخ خطای ناشی از نویز تقریباً صفر شود. - استراتژی میانه: اجرای سه جفت (کاندید، پیش‌فرض) و مقایسه میانه‌ی آن‌ها برای جلوگیری از پیروزی‌های تصادفی.
ابزار qo-agent و مکانیزم کنترل
پژوهشگر ابزاری به نام qo-agent ساخت تا مدل بتواند با دیتابیس تعامل کند. این عامل ۶ ابزار در اختیار دارد: بررسی ستون‌ها، دریافت آمار، مشاهده برنامه پیش‌فرض، ارزیابی کاندید جدید، حفظ پیش‌فرض و نهایتاً انتخاب نهایی.
مدل به جای بازنویسی کد SQL، اشیایی به نام PlanAction تولید می‌کند که به دستورات pg_hint_plan تبدیل می‌شوند. این راهنماها دیتابیس را هل می‌دهند تا از روش‌های خاص اتصال یا اسکن استفاده کند، بدون اینکه نیاز باشد کد منبع دیتابیس تغییر کند.
خط لوله آموزش: از SFT تا RL
مدل مورد استفاده، Qwen 3.8 4B Distill بود. در ابتدا، این مدل تقریباً بی‌فایده بود و در ۹۹ مورد از ۱۱۳ پرس‌وجوی محک JOB شکست خورد. بانسال برای اصلاح آن از سه مرحله استفاده کرد:
۱. تقطیر خارج‌سیاستی (Off-Policy Distillation): استفاده از مدل GPT-6 Astra به عنوان معلم برای تولید مسیرهای موفق. سپس مدل ۴ میلیاردی از طریق تنظیم نظارت‌شده (SFT) — شبیه وقتی که به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — آموزش دید تا زبان ابزارها را یاد بگیرد.
۲. انطباق لورا (LoRA): برای اجرای آموزش روی سخت‌افزارهای معمولی (RTX 3090)، از لورا (LoRA) استفاده شد. به جای به‌روزرسانی تمام ۴.۶ میلیارد پارامتر، تنها یک لایه کوچک ۴۲.۵ مگابایتی آموزش دید.
۳. GRPO لنگرشده: پیاده‌سازی نسخه‌ای خاص از بهینه‌سازی سیاست نسبی گروهی. در این روش، مدل تنها زمانی پاداش می‌گیرد که برنامه پیشنهادی‌اش «واقعاً» از پیش‌فرض Postgres سریع‌تر باشد، نه اینکه فقط از هم‌کلاسی‌هایش بهتر باشد.
نتایج و زیرساخت
نتایج نشان داد که مدل اولیه تقریباً هیچ کاندید معتبری نداشت. پس از یک دوره SFT، سرعت اجرا حتی کاهش یافت (۰.۷۲ برابر). اما در نهایت، مدل RL توانست به کاهش ۴۴.۷ درصدی تأخیر در ۱۱۳ پرس‌وجوی سنگین دست یابد. این کاهش تأخیر در لایه دیتابیس، مکمل تکنیک‌هایی است که در لایه مدل‌های زبانی برای سرعت بخشیدن به پاسخ‌ها به کار می‌روند، مانند استفاده از رمزگشایی گمانه‌زنانه و حافظه KV برای بهینه‌سازی زمان استنتاج.
برای این کار از یک گره 2x H100 برای آموزش و یک سیستم محلی (FLOPper) با ۱۶ هسته و ۶۴ گیگابایت رم برای اجرای کانتینرهای Postgres استفاده شد تا محاسبات سنگین GPU روی زمان‌سنجی حساس دیتابیس اثر نگذارد.
گام بعدی شما
- اگر پرس‌وجوهای کندی در دیتابیس دارید، افزونه
pg_hint_planرا نصب کنید تا ببینید راهنماهای دستی چگونه سرعت اجرا را تغییر می‌دهند. - بررسی کنید کدام پرس‌وجوهای شما تکراری هستند و حجم داده‌های میانی در آن‌ها بالاست؛ این‌ها بهترین کاندیدها برای بهینه‌سازی با مدل‌های کوچک هستند.
- برای کاهش هزینه استنتاج در پروژه‌های خود، به جای مدل‌های غول‌پیکر، روی تقطیر (Distillation) مدل‌های ۴ میلیاردی تمرکز کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو