ارسال هر درخواست SQL به یک مدل پیشرو (Frontier Model)، درست مثل این است که برای خرید یک بسته نان یا لیست خرید خردکس، موشک پرتاب کنید. این کار تا زمانی که صورت‌حساب سوخت نمی‌رسد هیجان‌انگیز است، اما بعد از آن مشخص می‌شود که کارهای ساده به موشک نیاز ندارند. Devart این ناکارآمدی را در محصول dbForge AI Assistant با اجرای یک روش «مسیریابی هوشمند» (Smart Query Routing) حل کرده است. طبق گزارش unite.ai، این متد هزینه استنتاج (Inference) — که در واقع همان لحظه تولید جواب توسط مدل است و شبیه به مرحله آشپزی بعد از یادگیری دستور پخت است — را بین ۴۰ تا ۷۰ درصد کاهش می‌دهد.
در اکثر دستیارهای AI SQL، بهره‌وری در ابتدا به‌دلیل حذف کدهای تکراری (Boilerplate) و سرعت بیشتر در تولید کوئری‌ها به‌شدت افزایش می‌یابد. اما با پذیرش ابزار توسط تیم‌های بیشتر، حجم درخواست‌ها به‌طور چشمگیری بالا می‌رود. از آنجایی که مدل‌های پیشرو برای استدلال در مورد نقشه‌های اجرا (Execution Plans)، اسکیماها و منطق‌های پیچیده گران‌قیمت هستند، در نهایت صورت‌حساب زیرساختی، معادله اقتصادی پروژه را به‌هم می‌زند.
اکثر کارهای SQL در سازمان‌ها روتین هستند؛ مثلاً جستجوهای ساده (Lookups)، خواندن داده‌ها از یک جدول واحد، عملیات درج (Insert) ابتدایی و اصلاح غلط‌های نوشتاری (Syntax Fixes). وقتی این کارهای کم‌پیچیدگی به یک مدل قدرتمند می‌رسند، سیستم منابع محاسباتی را هدر داده و صورت‌حساب‌ها را متورم می‌کند. این دقیقاً مانند استفاده از یک آسانسور باری برای جابجایی یک دفترچه یادداشت است. یک دستور ساده SELECT ممکن است در یک مدل پیشرو ۰.۰۳ دلار هزینه داشته باشد، اما در یک مدل سبک تنها ۰.۰۰۱ دلار است. در مقیاس ۱۰ هزار درخواست روزانه، این تصمیمِ مسیریابی به تنهایی، هزینه روزانه را از ۳۰۰ دلار به ۱۰ دلار می‌رساند؛ یعنی یک تفاوت ۳۰ برابری که صرفاً بر اساس تصمیم مسیریابی اتخاذ شده است.
همان‌طور که در تحلیل‌های قبلی ما درباره بهینه‌سازی هزینه‌های مدل‌های زبانی اشاره کردیم، کلید موفقیت در مقیاس بالا، عدم اتکا به یک مدل واحد است. این رویکرد همسو با راهکارهای مسیریابی پویا برای کاهش هزینه‌های مقیاس‌بندی (article:how-bifrost-cuts-llm-spend-via-dynamic-model-routing) است تا بهره‌وری مالی در کنار کیفیت فنی حفظ شود. برای حل این مشکل، Devart یک خط لوله چهارمرحله‌ای شامل «طبقه‌بندی» (Classify)، «مسیریابی» (Route)، «اجرا» (Execute) و «اعتبارسنجی» (Validate) طراحی کرد. هدف این است که نیاز استدلالی هر کوئری را با توانمندی سطح مدل مطابقت دهند تا قدرت پردازش دقیقاً متناسب با دشواری تکلیف باشد.
تعریف سطوح پیچیدگی
همه درخواست‌های SQL یکسان نیستند. یک کوئری که کاربری را از طریق کلید اصلی (Primary Key) می‌یابد، به استدلالی به‌کلی متفاوت از کوئری‌ای نیاز دارد که می‌خواهد قیف‌های نشست (Session Funnels) را در چندین اسکیما با استفاده از توابع پنجره‌ای (Window Functions) بازسازی کند. این سامانه تکالیف SQL را به سه سطح متمایز تقسیم می‌کند:
- سطح ۱ (روتین): شامل کارهای ساده و به‌خوبی تعریف‌شده است. نمونه‌ها عبارتند از: SELECTهای ساده، جستجوهای ابتدایی، عملیات CRUD پایه و اصلاحات سینتکسی. این‌ها توسط مدل‌های سریع و کم‌هزینه مدیریت می‌شوند.
- سطح ۲ (متوسط): نیاز به استدلال چندمرحله‌ای دارد. نمونه‌ها شامل JOINهای چندجدولی، زیرکوئری‌ها (Subqueries)، تجمیع داده‌ها (Aggregations) و راهنمای‌های بهینه‌سازی (Optimization Hints) است. این درخواست‌ها به مدل‌های میان‌رده مسیریابی می‌شوند.
- سطح ۳ (پیچیده): نیاز به آگاهی عمیق از اسکیما و استدلال سطح بالا دارد. نمونه‌ها شامل کوئری‌های بین‌دیتابازی (Cross-database)، توابع پنجره‌ای، تنظیم نقشه اجرا (Execution Plan Tuning) and بازسازی‌های کد (Refactoring) وابسته به اسکیما است. این‌ها تنها توسط مدل‌های پیشرو پاسخ داده می‌شوند.
درخواست‌های سطح ۳ فقط به قدرت پردازش بیشتر نیاز ندارند، بلکه نیازمند زمینه‌های (Context) خاصی هستند؛ مانند روابط جداول، کلیدهای خارجی، ایندکس‌ها و سینتکس‌های خاص هر دیتابیس. تزریق این حجم از اطلاعات به یک کوئری سطح ۱، فقط باعث مصرف بیشتر توکن (Token) — تکه‌های کوچک متن که مدل مثل برش‌های کیک می‌خورد — و افزایش تأخیر می‌شود، بدون اینکه کیفیت خروجی بهبود یابد.
مکانیزم طبقه‌بندی
مهم‌ترین مرحله، طبقه‌بندی است. طبقه‌بندی‌کننده یا کوئری خام SQL و یا پرامپت زبان طبیعی کاربر را دریافت کرده و آن را به یکی از سه سطح تخصیص می‌دهد. Devart از یک رویکرد ترکیبی برای بهینه‌سازی همزمان سرعت و دقت استفاده می‌کند:
- طبقه‌بندی قاعده‌مند (Rule-based): این روش بر الگوهای Regex و تحلیل درخت نحو انتزاعی (AST) برای شناسایی سیگنال‌های ساختاری تکیه دارد. سیستم به دنبال تعداد جداول، عمق تو در تو بودن، توابع پنجره‌ای، زیرکوئری‌ها یا عملگرهای تجمیع می‌گردد. این رویکرد سریع، قابل‌پیش‌بینی است و تقریباً هیچ سرباری (Overhead) ندارد.
- مدل‌های طبقه‌بندی سبک: در مواردی که قواعد ناکافی هستند، یک مدل زبانی کوچک (SLM) پیچیدگی را تخمین می‌زند. هزینه یک فراخوانی طبقه‌بندی‌کننده حدود ۰.۰۰۰۱ دلار است که در مقایسه با ۰.۰۳ دلار برای مدل پیشرو، سرمایه‌گذاری بسیار ناچیزی است تا از یک هزینه سنگین جلوگیری شود. این مدل‌ها می‌توانند به‌صورت محلی (Local) اجرا شوند و هزینه کوئری‌های ساده کاربران را کاملاً حذف کنند. این مدل‌ها به‌ویژه برای طبقه‌بندی پرامپت‌های زبان طبیعی، پیش از آنکه حتی SQL تولید شود، بسیار مفید هستند.
- ادغام ترکیبی: منطق قاعده‌مند موارد واضح را با هزینه صفر مدیریت می‌کند، در حالی که مدل طبقه‌بندی‌کننده موارد مبهم را بررسی می‌کند؛ یعنی کوئری‌هایی که در ظاهر متوسط به نظر می‌رسند اما ممکن است برای تولید صحیح، به استدلالی وابسته به اسکیما نیاز داشته باشند.
مسیریابی هوشمند و زمینه
مسیریابی بعد از طبقه‌بندی اتفاق می‌افتد، اما «سطح» تنها عامل تصمیم‌گیرنده نیست. سیستم متغیرهای دیگری را برای تعیین مقصد نهایی ارزیابی می‌کند:
- نیازمندی‌های زمینهٔ اسکیما: کوئری‌هایی که نیاز به درک روابط کلید خارجی یا جزئیات ساختاری دارند، حجم زمینه (Context) بیشتری را حمل می‌کنند و به مدل‌های با قابلیت بالاتر مسیریابی می‌شوند.
- تحمل تأخیر (Latency Tolerance): ویژگی‌های کاربر-محور مانند تکمیل خودکار (Autocomplete) یا پیشنهادهای درون‌خطی (Inline Suggestions)، بودجه زمانی بسیار محدودی دارند. اما تکالیف پس‌زمینه (Background Tasks) کمتر به زمان حساس هستند و می‌توانند به مدل‌های کندتر اما توانمندتر ارسال شوند.
- آستانه اطمینان (Confidence Thresholds): اگر طبقه‌بندی‌کننده در مورد سطح درخواست تردید داشته باشد، سیستم به‌طور پیش‌فرض از استراتژی «مسیریابی به بالا» (Routing Up) استفاده می‌کند. یک کاهش سطح اشتباه (Downgrade) می‌تواند منجر به تولید یک کوئری غلط و تحریک تکرار مجدد (Retry) شود که اغلب هزینه آن از استفاده اولیه از مدل قوی‌تر بیشتر است.
لایه اعتبارسنجی و ارتقاء
بعد از اجرا، یک لایه اعتبارسنجی خروجی را پیش از رسیدن به کاربر چک می‌کند. این لایه تضمین می‌کند که سینتکس درست است، اسکیما سازگار است و نتایج منطقی هستند (مثلاً بررسی می‌کند که آیا کوئری شکل صحیح ردیف‌ها را برگردانده است یا خیر). در این مرحله، تشخیص تفاوت میان درستی نحوی و صحت تجاری (article:your-ai-tool-s-sql-skills-may-hide-critical-business-logic-f) اهمیت می‌یابد تا از اجرای کوئری‌هایی که از نظر گرامری درست اما از نظر منطق کسب‌وکار غلط هستند، جلوگیری شود. اگر نتیجه در اعتبارسنجی شکست بخورد، سیستم یک «ارتقاء» (Escalation) را فعال می‌کند؛ یعنی کوئری را یک سطح بالا می‌برد و دوباره اجرا می‌کند.
Devart دریافت که گنجاندن زمینهٔ آگاه از اسکیما (Schema-aware context) در طبقه‌بندی‌کننده حیاتی است. بدون زمینهٔ اسکیما، کوئری‌هایی که از نام‌های نامشخص برای جداول استفاده می‌کردند یا بر روابط ضمنی تکیه داشتند، به‌طور سیستماتیک به‌عنوان «ساده» طبقه‌بندی می‌شدند و به مدل‌های ارزان می‌رفتند که توانایی حل آن‌ها را نداشتند. راه حل، ارائه هر دو موردِ «ساختار کوئری» و «متا-دیتای اسکیما» به طبقه‌بندی‌کننده بود.
سنجش موازنه هزینه و کیفیت
کاهش هزینه‌ای که منجر به افت کیفیت خروجی یا بی‌اعتمادی برنامه‌نویس شود، صرفه‌جویی نیست؛ بلکه انتقال هزینه از صورت‌حساب زیرساخت به زمان مهندسی است. موفقیت در اینجا با سه معیار اصلی سنجیده می‌شود:
- هزینه به ازای هر کوئری در هر سطح: این مورد خط پایه را تعیین می‌کند. هزینه‌ها در هر سطح به‌طور جداگانه ردیابی می‌شوند. از میانگین‌های ترکیبی (Blended Averages) اجتناب می‌شود زیرا می‌توانند شکست‌های مسیریابی را پنهان کنند؛ مثلاً سیستمی که ۵۰٪ کوئری‌ها را به سطح اشتباه می‌فرستد، ممکن است همچنان میانگین هزینه پایینی نشان دهد اما در سکوت نتایج بدتری تولید کند.
- امتیاز کیفیت (Quality Score): این شامل بازرسی نتایج برای صحت، کامل بودن و رعایت بهترین استانداردهای SQL است.
- نرخ ارتقاء (Escalation Rate): این مستقیم‌ترین سیگنال سلامت سیستم است. این معیار ردیابی می‌کند که هر چند وقت یک‌بار مدل‌های سطح ۱ یا ۲ خروجی‌هایی تولید می‌کنند که در اعتبارسنجی شکست می‌خورند. یک سیستم به‌خوبی تنظیم شده، این نرخ را زیر ۵ درصد نگه می‌دارد. اگر نرخ بالاتر برود، یعنی طبقه‌بندی‌کننده سیگنال‌های ساختاری را اشتباه می‌خواند یا زمینهٔ اسکیمای لازم را ندارد.
تأخیر نیز مانیتور می‌شود. کاربران باید تنها تأخیری بین ۵۰ تا ۱۰۰ میلی‌ثانیه در تعاملاتی که از لایه مسیریابی عبور می‌کنند، احساس کنند. اگر این لایه به یک گلوگاه تبدیل شود، رویکرد ترکیبی با بهره‌گیری از قواعد (Rules) برای واضح‌ترین موارد، آن را اصلاح می‌کند.
این معماری از «مالیات ارتقاء» جلوگیری می‌کند. مالیات ارتقاء زمانی رخ می‌دهد که مجموع هزینه‌های سربار — شامل فراخوانی طبقه‌بندی‌کننده، فراخوانی اولیه مدل، شکست در اعتبارسنجی، مسیریابی مجدد و فراخوانی دوم مدل — از هزینه ارسال مستقیم سوال به مدل پیشرو در همان ابتدا بیشتر شود. ردیابی نرخ ارتقاء در کنار هزینه هر فراخوانی، تنها راه شناسایی این ناکارآمدی است.
درس‌های راهبردی برای تیم‌های مهندسی
مسیریابی هوشمند، مشکل بودجه را از یک مسئله غیرقابل‌کنترل به یک چالش معماری قابل‌حل تبدیل می‌کند. با بهبود مدل‌های متن‌باز و کاهش هزینه استنتاج محلی، شکاف قیمتی بین سطوح بیشتر می‌شود و طبقه‌بندی دقیق، ارزشمندتر خواهد بود.
تیم‌ها تشویق می‌شوند که این الگوهای اولویت‌بندی را دنبال کنند:
۱. اولویت با طبقه‌بندی‌کننده است تا خودِ مدل‌ها: لایه مسیریابی تعیین می‌کند که آیا بقیه سیستم درست کار می‌کند یا خیر. یک طبقه‌بندی‌کننده ترکیبی، بخش عمده‌ای از صرفه‌جویی‌های هزینه را بدون پیچیدگی بیش از حد فراهم می‌کند.
۲. تزریق زمینهٔ اسکیما به طبقه‌بندی: برای حجم کارهایی که شامل روابط چندین جدول هستند، ساختار کوئری به‌تنهایی کافی نیست. متا-دیتای ناقص از اسکیما به‌طور قابل‌توجهی دقت سطح‌بندی را بالا می‌برد.
۳. استفاده از نرخ ارتقاء به‌عنوان سیگنال اصلی: این معیار سریع‌تر از هر معیار دیگری، طبقه‌بندی‌های اشتباه را شناسایی می‌کند.
۴. طراحی لایه اعتبارسنجی در گام اول: دانستن اینکه «شکست» چه شکلی دارد، منطق مسیریابی را شفاف‌تر کرده و سیستم را برای مدیریت موارد خاص (Edge Cases) آماده‌تر می‌کند.
گام بعدی شما
- اگر از مدل‌های گران‌قیمت برای کارهای تکراری استفاده می‌کنید، یک طبقه‌بندی ساده قاعده‌مند (Regex) را برای تفکیک درخواست‌ها امتحان کنید.
- یک لایه اعتبارسنجی (Validation) برای خروجی‌های AI تعریف کنید تا نرخ شکست مدل‌های ارزان را اندازه بگیرید.
- بررسی کنید آیا مدل‌های کوچک‌تر (SLM) می‌توانند نقش «ناظم» یا طبقه‌بندی‌کننده را برای مدل‌های بزرگ‌تر ایفا کنند؟
اما بهینه‌سازی فقط در سطح مدل نیست؛ تأثیر سخت‌افزارهای تخصصی بر هزینه استنتاج را در تحلیل ما درباره تراشه‌های جدید بررسی کنید.
گفتگو