DIN-SQL: یادگیری در-متن تجزیه شده برای تبدیل متن به SQL

هفته گذشته BIRD را بررسی کردم، بنچمارکی که نشان داد مدل‌های زبانی بزرگ (LLMها) وقتی تبدیل متن به SQL از پایگاه‌های داده اسباب‌بازی دست‌چین شده به سمت شمای‌های دنیای واقعی با نام‌گذاری‌های نامنظم، دانش دامنه و محدودیت‌های کارایی می‌رود، چقدر به مشکل می‌خورند. DIN-SQL مقاله‌ای است که باید زودتر می‌خواندم: این مقاله تعریف کرد که یک خط لوله پرامپت‌نویسی LLM که به دقت تجزیه شده است، واقعاً چه دستاوردهایی می‌تواند در Spider و BIRD داشته باشد؛ این مقاله درست زمانی که GPT-4 به طور گسترده در دسترس قرار گرفت، از سوی محمدرضا پوررضا و داوود رفیعی در NeurIPS 2023 ارائه شد. خواندن آن در حال حاضر — پس از آنکه BIRD سقف توانایی‌ها را آشکار کرد — تشخیص نقاط قوت و محدودیت‌ها را بسیار آسان‌تر می‌کند.

مقاله

مقاله DIN-SQL (arXiv:2304.11015) به یک شکاف عملکردی فاحش می‌پردازد. در اوایل سال ۲۰۲۳، بهترین مدل‌های تنظیم‌دقیق شده (fine-tuned) — مانند RESDSQL-3B+NatSQL — به دقت اجرای ۷۹.۹٪ در مجموعه تست Spider رسیدند، در حالی که GPT-4 با پرامپت‌نویسی چند-نمونه‌ای (few-shot) ساده تنها توانست ۶۷.۴٪ را در مجموعه توسعه کسب کند. فرضیه پوررضا و رفیعی این است که این شکاف عمدتاً یک مشکل رابط کاربری است: LLMها به اندازه کافی توانا هستند، اما تولید SQL در یک مرحله واحد از آن‌ها می‌خواهد که پیوند شما (schema linking)، طبقه‌بندی پیچیدگی و سنتز پرس‌وجو را هم‌زمان حل کنند. با تجزیه این موارد به زیر-وظایف متوالی و ارائه هر راه حل به عنوان متن (context) برای مرحله بعد، داستان تغییر می‌کند.

خط لوله آن‌ها دارای چهار مرحله است: (۱) یک ماژول پیوند شما که از پرامپت‌نویسی زنجیره افکار (chain-of-thought) برای نگاشت پرسش زبان طبیعی به ستون‌ها و مقادیر خاص در شما استفاده می‌کند؛ (۲) یک ماژول طبقه‌بندی و تجزیه که پرس‌وجو را به دسته‌های ساده (تک جدولی، بدون join)، پیچیده غیر-تودرتو (دارای join اما بدون زیر-پرس‌وجو)، یا پیچیده تودرتو (join، زیر-پرس‌وجو، عملیات مجموعه‌ای) تقسیم می‌کند و برای پرس‌وجوهای تودرتو، مسئله را به زیر-پرس‌وجوها تجزیه می‌کند؛ (۳) یک ماژول تولید SQL که استراتژی پرامپت‌نویسی را با کلاس پیچیدگی مطابقت می‌دهد — چند-نمونه‌ای ساده برای موارد آسان، نمایش میانی NatSQL برای موارد غیر-تودرتو، و زنجیره افکار چند مرحله‌ای برای موارد تودرتو؛ و (۴) یک ماژول خود-اصلاحی که از مدل می‌خواهد خروجی خود را برای خطاهای جزئی مانند DISTINCT فراموش شده یا DESC اشتباه بررسی کند.

ایده‌های کلیدی

• ترکیب GPT-4 + DIN-SQL به دقت اجرای ۸۵.۳٪ در مجموعه تست مخفی Spider می‌رسد که یک جهش ۵.۴ امتیازی نسبت به بهترین مدل تنظیم‌دقیق شده آن زمان یعنی RESDSQL-3B+NatSQL (۷۹.۹٪) است، آن هم بدون هیچ داده آموزشی اختصاصی برای وظیفه.
• در مجموعه توسعه Spider، خط لوله تجزیه، GPT-4 را از ۶۷.۴٪ (خط پایه چند-نمونه‌ای) به ۷۴.۲٪ می‌رساند — یک سود خالص ۶.۸ امتیازی. مدل CodeX Davinci نیز از ۶۱.۵٪ به ۶۹.۹٪ ارتقا می‌یابد.
• آزمایش‌های حذف (Ablation) تایید می‌کنند که هر مرحله در موفقیت نقش دارد: حذف پیوند شما به تنهایی عملکرد CodeX را از ۶۹.۹٪ به ۶۵.۹٪ کاهش می‌دهد؛ حذف طبقه‌بندی آن را تا ۶۳.۱٪ پایین می‌برد.
• دستاوردها در پرس‌وجوهای ساده و متوسط متمرکز شده‌اند. در پرس‌وجوهای "بسیار دشوار"، حتی خط لوله کامل DIN-SQL + GPT-4 تنها به ۴۳.۴٪ در مجموعه توسعه Spider می‌رسد — تجزیه، پیچیدگی را حل نمی‌کند، بلکه فقط خطاهای قابل اجتناب در پرس‌وجوهای قابل حل را کاهش می‌دهد.
• خود-اصلاحی به مدل حساس است: GPT-4 به پرامپت‌های "ملایم" که خواستار بهبودهای احتمالی هستند پاسخ می‌دهد؛ CodeX به پرامپت‌های "عمومی" که فرض می‌کنند SQL اشتباه است، بهتر واکنش نشان می‌دهد. این نشان می‌دهد که ماژول در حال انجام اصلاحات سبکی است، نه تایید معنایی واقعی.
• در مجموعه توسعه BIRD، ترکیب DIN-SQL + GPT-4 امتیاز ۵۰.۷۲٪ را در مقابل خط پایه GPT-4 ساده (۴۶.۳۵٪) کسب می‌کند — یک بهبود ۴.۴ امتیازی که به طور قابل توجهی کمتر از دستاوردهای Spider است و بعداً به آن خواهم پرداخت.

چه چیزی پابرجاست — و چه چیزی نه

نتیجه اصلی واقعی است. تجزیه تبدیل متن به SQL به زیر-وظایف صریح باعث بهبود عملکرد می‌شود و مطالعات حذف به اندازه کافی شفاف هستند که بتوان سهم هر ماژول را باور کرد. پیوند شما برای پرس‌وجوهای دشوار بیشترین اهمیت را دارد، که منطقی است: مدل نمی‌تواند JOINهای صحیح ایجاد کند اگر ابتدا به درستی تشخیص نداده باشد که پرسش به کدام جداول و ستون‌ها اشاره دارد.

اما چندین مورد باعث تردید من می‌شود. اختلاف ۷۴.۲٪ در مجموعه توسعه در مقابل ۸۵.۳٪ در مجموعه تست مشکوک است. مجموعه‌های توسعه معمولاً سخت‌تر یا حداقل به اندازه مجموعه تست سخت هستند، زیرا مدل‌ها به طور ضمنی با آن‌ها تنظیم می‌شوند؛ جهش ۱۱ امتیازی از توسعه به تست غیرمعمول است. نویسندگان این موضوع را توضیح نمی‌دهند و این باعث می‌شود فکر کنم که آیا مجموعه تست توزیع متفاوتی از دشواری پرس‌وجوها دارد، یا در نحوه ارزیابی تست مخفی (از طریق سرور رسمی لیدربورد Spider) چیزی متفاوت از ارزیابی مجموعه توسعه آن‌ها وجود دارد. من بدون این ملاحظه به عدد ۸۵.۳٪ استناد نمی‌کنم.

شکاف در BIRD (۵۰.۷۲٪ توسعه) به طور قابل توجهی کمتر از دستاوردهای Spider است. پایگاه‌های داده BIRD دارای شماهای دنیای واقعی نامنظم با نام ستون‌های اختصاری، اصطلاحات خاص دامنه و مقادیر مبهم هستند. ماژول پیوند شما در DIN-SQL با در نظر گرفتن شماهای نسبتاً تمیز Spider طراحی شده است؛ وقتی شماها کثیف‌تر می‌شوند، دقت پیوند کاهش می‌یابد و بقیه خط لوله نیز همراه با آن افت می‌کند. این دقیقاً همان چیزی است که مقاله BIRD اندازه‌گیری کرد و DIN-SQL آن را حل نمی‌کند.

اعداد هزینه و تاخیر برای هر سیستم تولیدی یک مشکل هستند: تقریباً ۰.۵۰ دلار و ۶۰ ثانیه برای هر پرسش با GPT-4. این برای یک تحلیلگر داده که ده پرس‌وجو در روز اجرا می‌کند مناسب است اما برای استفاده تعاملی کاملاً غیرعملی است. مقاله این را به عنوان یک محدودیت شناخته شده ارائه می‌دهد اما راهی برای کاهش آن پیشنهاد نمی‌کند. مقاله DAIL-SQL (arXiv:2308.15363) که چند ماه بعد منتشر شد، نشان داد که انتخاب بهتر نمونه‌ها به جای تجزیه صریح ساختاری می‌تواند به ۸۶.۶٪ در Spider برسد — و با هزینه‌ای به مراتب کمتر از DIN-SQL پیشی بگیرد.

ماژول خود-اصلاحی ضعیف‌ترین بخش است. نویسندگان اعتراف می‌کنند که این بخش خطاهای "جزئی" را شناسایی می‌کند. آنچه نمی‌تواند انجام دهد، تشخیص خطاهای معنایی است — مواردی که SQL تولید شده از نظر سینتکس معتبر است و حتی اجرا می‌شود، اما به پرسش اشتباهی پاسخ می‌دهد. این حالت شکست سخت‌تری برای کاربران واقعی است.

چرا این برای هوش مصنوعی مالی اهمیت دارد

Beanquery (BQL) یک زبان پرس‌وجوی شبیه SQL بر روی داده‌های دفتر کل Beancount است. این زبان ساختار جدول خاص خود را دارد — transactions (تراکنش‌ها)، postings (ثبت‌ها)، balance (تراز)، prices (قیمت‌ها) — با سلسله‌مراتب حساب‌ها، تگ‌ها و فیلدهای متاداده که هیچ شباهتی به شماهای عمومی پایگاه داده ندارند. یک رابط زبان طبیعی برای BQL ابزاری واقعی و مفید است (در حال حاضر یک سرور آزمایشی beanquery-mcp وجود دارد که دقیقاً همین کار را از طریق MCP پیاده‌سازی می‌کند) و استراتژی تجزیه DIN-SQL نقطه شروع مناسبی است.

پیوند شما در BQL مسئله‌ای مشابه پیوند شما در جداول رابطه‌ای است، اما با دو چالش اضافی: نام حساب‌ها مسیرهای سلسله‌مراتبی مانند Assets:US:Checking:Bank هستند و شمای مرتبط بستگی به این دارد که کاربر چه نوع پرس‌وجویی می‌پرسد (صورت سود و زیان، ترازنامه، جریان وجوه نقد). ماژول طبقه‌بندی DIN-SQL یک انطباق مستقیم را پیشنهاد می‌کند: ابتدا قصد پرس‌وجو (تراز در مقابل جریان در مقابل جستجوی قیمت) را طبقه‌بندی کنید، سپس به الگوهای پرامپت متفاوت هدایت کنید.

یافته بنچمارک BIRD مبنی بر اینکه بی‌نظمی دنیای واقعی به تبدیل متن به SQL توسط LLM آسیب می‌زند، مستقیماً مرتبط است. یک دفتر کل Beancount نیز "نامنظم" است — نام حساب‌های تعریف شده توسط کاربر، نمادهای کالای ناسازگار، کلیدهای متاداده سفارشی. بهبود ۴.۴ امتیازی در BIRD در مقابل بهبود ۶.۸ امتیازی در Spider به من می‌گوید که رژیم ساختاریافته و شما-تمیز، میزان کمک تجزیه به پرس‌وجوهای واقعی BQL را بیش از حد برآورد می‌کند. در عمل انتظار دستاوردهای کمتری داشته باشید.

محدودیت هزینه در اینجا واقعی اما کمتر محدودکننده است. یک کاربر امور مالی شخصی که ۱۰ تا ۲۰ پرس‌وجو در روز اجرا می‌کند، اگر رابط کاربری واقعاً مفید باشد، می‌تواند هزینه ۵ تا ۱۰ دلاری API در روز را تحمل کند. تاخیر (۶۰ ثانیه) برای استفاده تعاملی مشکل‌سازتر است؛ دسته‌بندی پرس‌وجوهای تحلیلی ممکن است راهی برای دور زدن آن باشد.

چه چیزی را در ادامه بخوانیم

• DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) — مطالعه سیستماتیک استراتژی‌های مهندسی پرامپت؛ با تمرکز بر انتخاب نمونه به جای تجزیه معماری به ۸۶.۶٪ در Spider می‌رسد که نقطه مقابل مفیدی برای DIN-SQL است.
• RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) — خط پایه تنظیم‌دقیق شده‌ای که DIN-SQL آن را شکست داد؛ درک نقاط قوت رویکرد تنظیم‌دقیق شده، نقاط ضعف فعلی پرامپت‌نویسی را روشن می‌کند.
• MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) — ایده تجزیه چند مرحله‌ای را به یک خط لوله صریح چند-عاملی (Multi-agent) با بخش‌های انتخاب‌گر، تجزیه‌گر و اصلاح‌گر گسترش می‌دهد؛ با GPT-4 به ۵۹.۵۹٪ در BIRD می‌رسد و عامل‌محورترین رویکرد در این حوزه است.