میخواستم ببینم آیا اجرای یک سوال یکسان به تعداد ۵۱ بار، پاسخ را قابلاعتمادتر میکند یا خیر. یک LLM محلی را برداشتم، تکهای از کد تولیدی (production code) را به آن دادم و از آن خواستم آن را بازبینی کند. سپس این کار را دوباره و دوباره انجام دادم. در مجموع ۵۱ بار، و از روش رأیگیری اکثریت (majority voting) برای انتخاب «بهترین» پاسخ استفاده کردم. ایده ساده بود: اگر مدل در یک اجرا دچار لغزش شود، شاید خرد جمعی حاصل از ۵۱ تولید، نویز را خنثی کند و تحلیل صحیح را آشکار سازد. اما این اتفاق نیفتاد. آزمایش نشان داد که رأیگیری اکثریت، پاسخ صحیح را انتخاب نمیکند؛ بلکه آنچه را که مدل بیش از همه بر آن پافشاری میکند، انتخاب میکند.
این تمایز از آن جهت اهمیت دارد که رأیگیری اکثریت به یک ترفند (hack) محبوب در خط لولههای (pipelines) LLM تبدیل شده است. الگو ساده است: مدل را چندین بار با یک پرامپت (prompt) یکسان اجرا میکنید، خروجیها را جمعآوری میکنید و پاسخی را که بیشترین تکرار را داشته است، نگه میدارید. در حوزههایی مانند تصویربرداری پزشکی یا تشخیص اسپم، روشهای گروهی (ensemble methods) کار میکنند، زیرا مدلهای مختلف یا دیدگاههای مختلف نسبت به دادهها، خطاهای مستقلی تولید میکنند که در واقع همدیگر را خنثی میکنند. مدلهای زبانی بزرگ، رأیدهندگان مستقلی نیستند. آنها یک سیستم واحد با یک تاریخچه آموزشی، یک مجموعه وزنها و یک جهان از سوگیریها هستند. وقتی از یک مدل یکسان، یک سوال یکسان را ۵۱ بار میپرسید، در واقع یک کمیته تشکیل نمیدهید؛ بلکه دارید از یک پاسخدهنده واحد، در شرایط روحیِ کمی متفاوت، نظرسنجی میکنید.
مشکل پافشاری
مسئله اصلی این است که خطاهای LLM بهندرت تصادفی هستند. آنها الگوهایی هستند که در دادههای آموزشی و معماری مدل نهادینه شدهاند. مدلی که در یک اجرا، یک دکوراتور (decorator) خاص در پایتون را اشتباه بخواند، احتمالاً در اجرای بعدی نیز همان اشتباه را تکرار خواهد کرد. مدلی که به دلیل شباهت نام یک متغیر به رمز عبور، یک آسیبپذیری امنیتی را توهم (hallucinate) میزند، احتمالاً در اجرای چهل و هفتم نیز دوباره همان توهم را خواهد داشت. نویزی که شما با میانگینگیری سعی در حذف آن دارید، معمولاً تغییرات سطحی در کلمات یا قالببندی است
هیچکدام از اینها به این معنا نیست که نباید یک مدل را بیش از یک بار اجرا کنید. رأیگیری اکثریت میتواند در موقعیتهای محدودی که وظیفه سطحی است و خطاها واقعاً تصادفی هستند، کمککننده باشد. از یک مدل خواستن برای انتخاب بین دو قالب نحوی، انتخاب یک قرارداد نامگذاری متغیر، یا استخراج یک رشته تاریخ از یک خط لاگ—این وظایف کمخطر گاهی اوقات از نمونهبرداری مکرر سود میبرند. این تغییرات، نویز واقعی هستند و یک رأیگیری سریع آنها را اصلاح میکند.
مشکل زمانی شروع میشود که وظیفه مستلزم استدلال درباره هدف باشد. آیا این بررسی احراز هویت باید اینجا باشد؟ آیا این فراخوانی async ایمن است؟ آیا این تداخل کلید کش واقعاً قابل سوءاستفاده است؟ این سوالات مستلزم درک بافتار (context) هستند، نه فقط الگویابی. الگویابِ یک مدل در سوگیری خود قطعی است. مدل به دنبال رایجترین پاسخ در دادههای آموزشی خود خواهد رفت، نه دقیقترین پاسخ برای کدبیس شما.
روشهای هوشمندانهتر برای صرف منابع پردازشی
پنجاه و یک بار اجرای یک مدل محلی، زمان و برق واقعی مصرف میکند. راههای بهتری برای سرمایهگذاری روی آن منابع پردازشی وجود دارد. اگر میخواهید قابلیت اطمینان را بهبود ببخشید، تنوع بر حجم برتری دارد. دو مدل متفاوت را با