تصور کنید برای پیدا کردن یک سوزن در انبار کاه، هر بار که کلمه‌ای خاص ظاهر می‌شود، سیستم به‌جای یک سوزن، سه سوزن کاملاً یکسان ببیند. در این حالت، هوش مصنوعی متوجه تکرار نمی‌شود و صرفاً تصور می‌کند آن سند سه برابرِ بقیه مرتبط است، حتی اگر پاسخ صحیح نباشد.
به گزارش یک توسعه‌دهنده، یک باگ شمارش سهگانه در خط لوله بازیابی، باعث شد افزایش عملکرد به یک شکست کامل تبدیل شود. هفته‌ی گذشته (در اواخر آوریل ۲۰۲۴)، این برنامه‌نویس اندازه‌گیری خاصی را منتشر کرد: او برای بهبود بازیابی، شرح‌هایی برای ۱۲۴۵ شیء پایگاه‌داده تولید کرده بود، اما در کمال تعجب، کیفیت بازیابی در واقع بدتر شده بود. این پست با واکنش زیادی روبرو شد و ۳۷ نفر دیگر نیز در بخش نظرات گزارش دادند که پدیده مشابهی را در سیستم‌های خود دیده‌اند. اندازه‌گیری‌ها واقعی و درست بود، اما نتیجه‌گیری استخراج شده از آن اشتباه بود.
زمینه و آزمایش‌ها
برای تشخیص دقیق مشکل، توسعه‌دهنده از Spider 2.0-lite استفاده کرد؛ یک محک تبدیل متن به SQL (text-to-SQL benchmark) که از پایگاه‌داده‌های واقعی BigQuery و Snowflake ساخته شده است. برخلاف محک‌های قدیمی، Spider 2.0-lite مستندات واقعی انبار داده‌ها را همراه خود دارد. این ویژگی روشی را فراهم می‌کند تا ادعاها روی متون حرفه‌ای (Professional Prose) آزمایش شوند، نه روی متونی که توسط یک تولیدکننده سفارشی (Custom Generator) ساخته شده‌اند. این رویکرد دقیق در ارزیابی، یادآور بررسی‌های سخت‌گیرانه در حسابرسی گراف‌های دانش است که در آن امتیازدهی‌های پایه برای بهبود تصمیم‌گیری‌ها تحلیل شدند.
توسعه‌دهنده با حذف شرح‌ها و اجرای مجدد تست‌ها متوجه شد که حذف متون در هر دو مدل بردار معنایی (Embedders) و در تمامی برش‌ها باعث پیروزی مدل می‌شود. از شش سلول تحلیل، پنج سلول دارای تغییرات معنادار بودند. در گسترده‌ترین سلول، ۱۳ پرسش اصلاح شد در حالی که تنها یک مورد خراب شد. اگرچه جدول نتایج پیشنهاد می‌کرد که شرح‌ها به‌طور کلی حذف شوند، اما همین‌جا «نشانه» اصلی بود: سیستمی که بر پایه این فرض طراحی شده که متن به بازیابی کمک می‌کند، نباید با حذف آن متن بهبود یابد.
مکانیسم شکست
بررسی‌های عمیق‌تر نشان داد که یک کامنت ستون (Column Comment) به‌طور مجزا سه بار در سیگنال‌های مختلف رتبه‌بندی ایندکس شده بود:
- کانال متنی (Prose Channel): تغذیه شده از
_prose_text. - کانال بدنه (Body Channel): تغذیه شده از
embed_text(). - کانال برداری (Vector Channel): باز هم تغذیه شده از
embed_text().
از آنجا که سه سیگنال از چهار سیگنال رتبه‌بندی، کلمات یکسانی را حمل می‌کردند، هر جدولی با ستون‌های زیاد، برای هر پرسشی که حتی یک کلمه مشترک با هر یک از ستون‌هایش داشت، در سه کانال از چهار کانال تطبیق می‌یافت. این جداول عریض مانند «آهنربا» عمل کرده و در پرسش پس از پرسش، جداول کوچک‌تر و صحیح را به حاشیه می‌راندند. حذف شرح‌ها فقط به‌این دلیل «کمک» کرد که دو-سومِ این شمارش سهگانه را حذف کرد؛ بنابراین این نتایج دلیلی بر خطای امتیازدهی (Scoring Errors) بود، نه دلیلی علیه استفاده از متن.
کالبدشکافی باگ
توسعه‌دهنده برای تحلیل دقیق‌تر، شمارش سهگانه را با استفاده از همان ۲۱۲ پرسش، کانال به کانال از هم جدا کرد:
- حذف کامنت‌های ستون فقط از کانال متنی: باعث بازیابی ۴ پرسش در k=10 شد.
- حذف آن‌ها فقط از
embed_text(): باعث بازیابی ۱۱ پرسش در k=10 شد.
۱۱ مورد از ۱۵ پرسش بازیابی‌شده در مسیر بردار معنایی (Embedding Path) قرار داشتند. این نشان داد که منبع اصلی آسیب در مسیر Embedding بود، هرچند کانال متنی به‌دلیل نامش، مظنون اول و بدیهی‌تر به نظر می‌رسید.
راهکار فنی
راهکار نهایی شامل حذف کامنت‌های ستون از کانال بدنه و کانال متنی بود، در حالی که embed_text() دست‌نخورده باقی ماند. این محدودیت ضروری بود زیرا بردارها یک تضمین منتشرشده و ثابت (Pinned Guarantee) هستند. تغییر در ورودی‌های آن‌ها به این معنا بود که هر ایندکس ذخیره‌شده توسط هر کاربری از این کتابخانه، به‌طور خاموش غلط شود و یک وصله ساده (Patch) به یک مهاجرت داده‌ای (Migration) اعلام‌نشده تبدیل گردد.
پس از اعمال این اصلاحات، جریمه عملکردی کاملاً از بین رفت. در اجرای مجدد روی ۲۱۲ پرسش، شکاف عملکرد بین حالت «با شرح» و «بدون شرح» از نسبت ۱۳ به ۱ به یک تساوی ۲ به ۲ رسید. در k=10، هر دو نسخه امتیاز ۱۷۷/۲۱۲ (۸۳.۵٪) را کسب کردند و در k=20، نتایج برای حالت با شرح ۱۸۸/۲۱۲ (۸۸.۷٪) و برای حالت بدون شرح ۱۸۷/۲۱۲ (۸۸.۲٪) بود.
یک نقص داده‌ای ثانویه
در حین نمونه‌برداری از فایل‌های خام، باگ دومی در اسکیمای JSON مدل Spider 2.0 پیدا شد. مشخص شد فیلد description در واقع شرح جدول نبود، بلکه لیستی از شرح‌های هر ستون بود که بر اساس ایندکس با nested_column_names (برای فیلدهای تو در تو) یا column_names تراز شده بود. در ۱۵۰ مورد از ۱۵۰ مورد نمونه‌برداری شده، ورودی‌ها گاهی null بودند و هرگز رشته (String) نبودند.
لودر سیستم، این لیست را به یک پاراگراف تبدیل و به‌عنوان شرح جدول ایندکس می‌کرد. این موضوع باعث شد جداول تو در تو — مانند v3_genomes__chr7 در gnomAD (با ۶۱ ستون سطح بالا و ۱۸۱ ستون تخت‌شده) — به‌گونه‌ای وارد سیستم شوند که دقیقاً همان ستون‌هایی که SQL مرجع (Gold SQL) می‌خواند، گم شوند. این چالش در مدیریت داده‌های حجیم و پیچیده، مشابه رویکردهای تفکیک ارزیابی برای تحلیل مسیرهای مشتری است که برای جلوگیری از سرریز اطلاعاتی و افزایش دقت در تحلیل‌های مقیاس‌پذیر به کار می‌رود.
اصلاح این باگ لودر اثرات زیر را داشت:
- تغییر مجموعه مقایسه‌ای قابل حل از ۲۰۳ به ۲۱۲ پرسش.
- افزایش صحت k=20 از ۶۷.۲٪ به ۷۱.۳٪ (با مخرج ۲۴۷ پرسش).
- کاهش صحت k=10 از ۷۷.۸٪ به ۷۷.۴٪، زیرا ۹ پرسش مربوط به Join سخت‌تر از میانگین ۲۰۳ پرسش قبلی بودند.
این مشکل فرمت به‌صورت یک درخواست مستندسازی (Spider2 issue #222) ثبت شد، زیرا فایل‌ها سازگار بودند، هرچند نام فیلد گمراه‌کننده بود.
درس‌هایی برای مهندسان هوش مصنوعی
این تجربه یک درس حیاتی دارد: یک اندازه‌گیری می‌تواند کاملاً درست باشد اما معنای مورد نظر شما را ندهد. اگر نتیجه‌ای علیه فرض اصلی طراحی شماست، قبل از زیر سؤال بردن فرض، پیاده‌سازی را بررسی کنید. بررسی کد یک بعدازظهر زمان می‌برد، اما رد کردن یک فرض، نیازمند یک برنامه پژوهشی است.
مراقب فیلدهایی باشید که به بیش از یک سیگنال رتبه‌بندی می‌روند. اگر یک فیلد هم به یک کانال لغت‌نامه‌ای (Lexical) و هم به متنی که تبدیل به بردار می‌شود برود، دو بار شمرده می‌شود. اگر کانال سومی هم از همان متن مشتق شود، سه بار شمرده می‌شود. در این حالت هیچ خطایی در کنسول ظاهر نمی‌شود و تست‌ها پاس می‌شوند، اما سیستم بازیابی به‌طور خاموش، اسنادی را ترجیح می‌دهد که بیشترین تکرار از آن فیلد را دارند.
هر اصلاحی که ایندکس‌های کاربر را باطل کند، باید با تغییر نسخه (Version Bump) و یادداشت همراه باشد، نه یک وصله ساده. این اصلاح در نسخه 0.1.57 منتشر شد. جزئیات کامل شامل شبکه McNemar، تجزیه کانال‌ها و اعداد اندازه‌گیری شده در فایل BENCHMARKS.md پروژه موجود است، جایی که ادعای withdrawn (پس گرفته شده) همچنان برای بررسی قابل مشاهده است.
گام بعدی شما
- تمام کانال‌های رتبه‌بندی (Lexical, Vector, Metadata) خود را بررسی کنید تا مطمئن شوید یک فیلد داده‌ای در بیش از یک مسیر اثر نمی‌گذارد.
- در صورت افت کیفیت پس از افزودن داده‌های غنی‌ساز، ابتدا اثر «آهنربایی» جداول عریض را تحلیل کنید.
- برای هر تغییر در ساختار Embedding، حتماً نسخه (Version) ایندکس‌های خود را به‌روزرسانی کنید تا از تداخل داده‌ها جلوگیری شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو