مدت زمان مطالعه: حدود ۱۵ دقیقه
اهداف:
- یاد می‌گیریم چرا ارزیابی و «قضاوت کردن» پاسخ‌های هوش مصنوعی یک چالش بزرگه.
- با یک روش جدید به اسم «داوری با کمک ابزار» (Tool-Augmented Annotation) آشنا می‌شیم.
- می‌فهمیم چطور ابزارهایی مثل جستجوی وب و اجرای کد می‌تونن به یک هوش مصنوعیِ قاضی کمک کنن.
- نتایج یک تحقیق واقعی در این زمینه رو با هم بررسی می‌کنیم تا ببینیم این روش چقدر موفق بوده.
فصل اول: مشکل از کجا شروع شد؟ چرا به یک «قاضی» برای هوش مصنوعی نیاز داریم؟
بگذارید با یک سناریو شروع کنیم. فرض کنید شما مدیر دو تا ربات آشپز هستید. از هر دو می‌خواید که یک پیتزا درست کنن. حالا چطور می‌فهمید کدوم پیتزا بهتره؟ شاید خودتون پیتزاها رو بچشید و بگید «پیتزای ربات A بهتر از ربات B بود». این کاری که شما کردید، بهش میگن ارزیابی مقایسه‌ای دوتایی یا «Pairwise Comparison». یعنی دو تا چیز رو کنار هم می‌گذارید و میگید کدوم بهتره.
توی دنیای مدل‌های زبان بزرگ (که بهشون میگیم LLM)، دقیقا همین کار رو می‌کنن. به یک مدل یک سوال یا دستور میدن (مثلا «پایتخت استرالیا کجاست؟») و دو تا جواب مختلف از دو تا مدل متفاوت می‌گیرن. بعد یک نفر باید بگه کدوم جواب بهتره. این بازخوردها فوق‌العاده ارزشمندن. از این بازخوردها برای دو تا کار اصلی استفاده میشه:
- ارزیابی عملکرد مدل (Evaluation): مثل مسابقات «Chatbot Arena» که در اون کاربران به پاسخ‌های دو چت‌بات رای میدن تا مشخص بشه کدوم محبوب‌تر و بهتره. اینجوری میشه فهمید کدوم مدل در حال پیشرفته.
- آموزش و بهبود مدل (Training): این بازخوردها رو به مدل میدن تا یاد بگیره چه نوع جواب‌هایی خوب و چه نوع جواب‌هایی بد هستن. به این فرآیندها چیزهایی مثل RLHF (یادگیری تقویتی از بازخورد انسانی) یا DPO (بهینه‌سازی مستقیم ترجیحات) میگن.
حالا سوال اینجاست: کی باید این قضاوت رو انجام بده؟ دو تا گزینه اصلی داریم: انسان‌ها و خود هوش مصنوعی.
- قضاوت توسط انسان (Human Annotator): این روش معمولا کیفیت بالایی داره، چون انسان‌ها درک عمیقی از زبان و مفاهیم دارن. اما یک مشکل بزرگ داره: خیلی گرون و زمان‌بره. فرض کنید بخواید برای میلیون‌ها پاسخ، نظر انسان‌ها رو جمع کنید!
- قضاوت توسط هوش مصنوعی (AI Annotator): اینجا یک ایده جالب مطرح میشه: چرا از یک مدل زبان بزرگ و قدرتمند دیگه برای قضاوت کردن استفاده نکنیم؟ به این روش میگن «LLM-as-a-Judge» یا «مدل زبان بزرگ به عنوان قاضی». این روش خیلی سریع‌تر و ارزون‌تره.
اما هر دو روش، یعنی هم قضاوت انسانی و هم قضاوت با هوش مصنوعی، مشکلات و محدودیت‌های خودشون رو دارن. مثلا، تحقیقات نشون داده که قاضی‌های هوش مصنوعی به یک سری سوگیری‌ها یا «bias» دچار میشن. مثلا:
- سوگیری ترتیب (Position Bias): گاهی اوقات فقط به خاطر اینکه جواب A اول نشون داده شده، بهش رای بهتری میده. اگه جای جواب‌ها عوض بشه، ممکنه نظرش هم عوض بشه! این رو محققانی مثل «Zheng et al. (2023)» مشاهده کردن.
- سوگیری طول (Length Bias): بعضی وقتا قاضی‌های هوش مصنوعی فکر می‌کنن جوابی که طولانی‌تر و پرجزئیات‌تره، لزوما بهتره، در حالی که ممکنه اینطور نباشه. این موضوع رو کسانی مثل «Dubois et al. (2024)» بررسی کردن.
انسان‌ها هم بی‌نقص نیستن. مثلا، یک تحقیق توسط «Hosking et al. (2024)» نشون داده که اگه یک متن با قاطعیت و اطمینان زیادی نوشته شده باشه، ممکنه انسان‌ها کمتر به اشتباهات factual یا واقعیتی اون توجه کنن و گول سبک نوشتاریش رو بخورن.
اینجاست که به هسته اصلی مشکل می‌رسیم. یک سری حوزه‌ها و وظایف خاص وجود دارن که قضاوت کردن در موردشون، هم برای انسان و هم برای هوش مصنوعی، فوق‌العاده سخته.
فصل دوم: زمین‌های بازی سخت؛ حوزه‌های چالشی برای داوری
بیایید سه تا از این حوزه‌های سخت رو با هم بررسی کنیم که مقاله اصلی هم روی همین‌ها تمرکز کرده:
- متن‌های طولانی و پر از اطلاعات واقعی (Long-form factual): فرض کنید دو تا متن طولانی درباره «تاریخچه امپراطوری روم» دارید. هر کدوم پر از اسم، تاریخ و اتفاقات مختلفه. یک قاضی (چه انسان، چه هوش مصنوعی) چطور می‌تونه مطمئن بشه همه این اطلاعات درسته؟ خیلی راحت ممکنه یک اشتباه کوچیک از چشمش دور بمونه. در نتیجه، ممکنه به جای تمرکز روی درستی اطلاعات، بیشتر به «سبک نوشتاری» و «روان بودن متن» توجه کنه و به متنی که خوشگل‌تر نوشته شده ولی اطلاعات غلط داره، نمره بهتری بده.
- کدهای برنامه‌نویسی پیشرفته (Advanced coding): حالا دو تا قطعه کد پیچیده پایتون رو در نظر بگیرید که قراره یک مسئله سخت رو حل کنن. کسی که می‌خواد این دو تا کد رو قضاوت کنه، باید برنامه‌نویسی بلد باشه و بفهمه هر کد داره چیکار می‌کنه. اگه دانش کافی نداشته باشه، دوباره ممکنه به چیزهای سطحی مثل «تمیز بودن کد» یا «داشتن کامنت‌های زیاد» توجه کنه، در حالی که شاید اون کد اصلا درست کار نکنه!
- مسائل ریاضی (Math content): مسائل ریاضی، به خصوص اون‌هایی که نیاز به محاسبات دارن، برای مدل‌های زبان یک چالش بزرگن. مدل‌های زبان بزرگ، ماشین حساب نیستن و در محاسبات ساده هم گاهی اشتباه می‌کنن. این رو محققانی مثل «Yang et al. (2023)» هم نشون دادن. پس وقتی یک قاضی هوش مصنوعی می‌خواد جواب یک مسئله ریاضی رو بررسی کنه، ممکنه خودش هم در محاسبه و تشخیص جواب درست به مشکل بخوره.
پس مشکل اصلی اینه: در این سه حوزه، قضاوت کردن نیاز به تخصص و بررسی دقیق داره. انسان‌ها برای این کار به زمان زیادی نیاز دارن و ممکنه خسته بشن. قاضی‌های هوش مصنوعی شاید «خسته» نشن، اما به خاطر مشکلاتی مثل توهم (hallucination) یا ضعف در محاسبات، نمی‌تونن قضاوت قابل اعتمادی ارائه بدن.
در این شرایط، هدف یک قاضی خوب چیه؟ هدف اینه که توافق خودش رو با یک «پاسخ طلایی» یا «ground-truth» به حداکثر برسونه. یعنی اگه ما از قبل می‌دونیم جواب A واقعا بهتر از B هست، یک قاضی خوب باید بتونه همین تشخیص رو بده. این توافق، مثل دقت (accuracy) در یک مسئله طبقه‌بندی باینریه. مثلا اگه ۱۰۰ تا جفت پاسخ داشته باشیم و قاضی بتونه در ۹۰ مورد، پاسخ درست رو انتخاب کنه، دقتش ۹۰ درصد بوده.
مقاله مورد بحث ما دقیقا برای حل همین مشکل در همین سه حوزه سخت، یک راه‌حل جدید و جالب ارائه میده.
فصل سوم: یک ایده جدید؛ مجهز کردن قاضی به «ابزارهای خارجی»
ایده اصلی محققان اینه: به جای اینکه فقط به دانش درونی و حافظه خود مدل زبانِ قاضی تکیه کنیم، بیاییم بهش یک سری «ابزار» بدیم تا بتونه ادعاها و پاسخ‌ها رو به صورت خارجی بررسی و تایید کنه (External Validation). درست مثل یک کارآگاه که فقط به حرف‌های مظنون گوش نمیده، بلکه میره صحنه جرم رو بررسی می‌کنه و از آزمایشگاه کمک می‌گیره.
محققان یک چارچوب یا فریم‌ورک جدید طراحی کردن که بهش میگن «سیستم عامل‌محور» یا Agentic System. کلمه «Agentic» اینجا به این معنیه که سیستم خودش فکر می‌کنه و تصمیم می‌گیره. مثل یک دستیار باهوش، اول شرایط رو می‌سنجه و بعد تصمیم می‌گیره از کدوم ابزار استفاده کنه. این سیستم طوری طراحی شده که روی قاضی‌های هوش مصنوعی موجود سوار بشه و اونها رو تقویت کنه.
بیایید ببینیم این سیستم چطور کار می‌کنه. کل فرآیند از سه مرحله اصلی تشکیل شده، به علاوه یک مسیر جایگزین:
مرحله ۱: ارزیابی اولیه دامنه (Initial domain assessment)
این مرحله مثل یک نگهبان دم در عمل می‌کنه. قبل از اینکه هر ابزاری به کار گرفته بشه، یک مدل زبان بزرگ (LLM) اول هر دو تا پاسخ رو نگاه می‌کنه و از خودش می‌پرسه: «آیا این متن‌ها در حوزه‌ای هستن که ابزارهای من به دردشون بخوره؟».
برای هر ابزار، یک سری سوال مشخص طراحی شده. مثلا برای ابزار اجرای کد، سوال اینه: «آیا در این متن کدی وجود داره که اجرای اون بتونه به ما کمک کنه؟» یا برای ابزار ریاضی، سوال اینه: «آیا این متن شامل ریاضیات یا محاسباتی هست که نیاز به بررسی دقیق داشته باشه؟».
یک مدل زبان به این سوال‌ها جواب میده. اگه جوابش برای حداقل یکی از ابزارها مثبت بود، سیستم وارد مرحله بعد میشه. اما اگه تشخیص بده که هیچکدوم از ابزارها به درد این پاسخ‌ها نمی‌خورن (مثلا پاسخ‌ها یک گفتگوی ساده و خودمونی هستن)، اون وقت سیستم مسیرش رو عوض می‌کنه و به سراغ «قاضی پایه» (Baseline Annotator) میره.
این کار دو تا مزیت بزرگ داره:
- جلوگیری از هزینه‌های اضافی: اجرای ابزارها، به خصوص جستجوی وب و اجرای کد، هزینه محاسباتی داره. این مرحله باعث میشه فقط در مواقع ضروری ازشون استفاده بشه.
- جلوگیری از افت عملکرد (Regression): ممکنه استفاده بی‌مورد از ابزارها در حوزه‌هایی که بهشون ربطی نداره، باعث بشه عملکرد کلی قاضی پایین بیاد. این نگهبان جلوی این اتفاق رو می‌گیره.
یک نکته جالب هم وجود داره: اگه سیستم تشخیص بده که ابزارها فقط برای یکی از دو متن (مثلا فقط برای متن A) مفید هستن، در این حالت با احتمال ۵۰ درصد از ابزارها استفاده می‌کنه و با احتمال ۵۰ درصد به سراغ قاضی پایه میره تا یک تعادل ایجاد کنه.
مرحله ۲: استفاده از ابزارها (Tool usage)
اگه مرحله اول چراغ سبز رو نشون داد، حالا نوبت به کار انداختن ابزارها می‌رسه. محققان در این پژوهش سه تا ابزار اولیه رو پیاده‌سازی کردن که دقیقا برای هدف گرفتن اون سه حوزه چالشی طراحی شدن:
- ابزار A: بررسی واقعیت (Fact-checking): این ابزار بر اساس یک متد معروف به اسم SAFE (Search Augmented Factuality Evaluator) که توسط «Wei et al. (2024)» معرفی شده، ساخته شده. کار این ابزار اینه:
- جدا کردن حقایق اتمی: اول متن رو می‌شکنه و تمام ادعاهای واقعی و مشخص رو به صورت جملات کوتاه جدا می‌کنه. مثلا جمله «تهران، پایتخت ایران، بیش از ۸ میلیون نفر جمعیت دارد» رو به دو حقیقت اتمی «تهران پایتخت ایران است» و «تهران بیش از ۸ میلیون نفر جمعیت دارد» تبدیل می‌کنه.
- مستقل کردن حقایق: هر حقیقت اتمی رو طوری بازنویسی می‌کنه که به تنهایی و بدون نیاز به بقیه متن، قابل فهم باشه.
- بررسی با جستجوی وب: حالا برای هر حقیقت مستقل شده، در وب جستجو می‌کنه تا ببینه آیا منابع معتبر اون رو تایید می‌کنن یا نه.
- یک نکته مهم اینه که در این پیاده‌سازی، خود مدل زبان بزرگ وظیفه قضاوت درباره نتایج جستجوی وب رو به عهده داره و سیستم به طور مستقیم اعتبار منابع وب رو چک نمی‌کنه.
- ابزار B: اجرای کد (Code execution): این ابزار از API معروف «Code Interpreter» شرکت OpenAI استفاده می‌کنه. وقتی یک پاسخ حاوی کد باشه، این ابزار کد رو می‌گیره، اجراش می‌کنه و خروجی رو بررسی می‌کنه. این ابزار حتی می‌تونه خودش تست‌های واحد (unit tests) بنویسه تا از درستی عملکرد کد مطمئن بشه. در نهایت، یک نتیجه‌گیری کلی درباره صحت کد به مرحله بعد گزارش میده.
- ابزار C: بررسی‌کننده ریاضی (Math checker): این ابزار در واقع یک نسخه تخصصی شده از ابزار اجرای کده. محققان متوجه شدن که ابزار اجرای کد معمولی برای مسائل ریاضی به خوبی عمل نمی‌کنه. برای همین، یک نسخه جدید ساختن که با یک پرامپت (دستور) مخصوص مسائل ریاضی کار می‌کنه و از قابلیت اجرای کد برای حل و اعتبارسنجی محاسبات و مسائل ریاضی استفاده می‌کنه.
مرحله ۳: تصمیم‌گیری نهایی (Final assessment)
در این مرحله آخر، تمام اطلاعات جمع‌آوری شده روی میز گذاشته میشه. یعنی:
- صورت سوال اصلی (Prompt)
- پاسخ A و پاسخ B
- نتایج و گزارش‌های هر ابزاری که در مرحله ۲ استفاده شده (مثلا گزارش بررسی واقعیت برای پاسخ A، گزارش اجرای کد برای پاسخ B و غیره).
همه اینها به یک مدل زبان بزرگ داده میشه و ازش خواسته میشه که با توجه به همه این شواهد، یک قضاوت نهایی بکنه و بگه کدوم پاسخ بهتره. نکته خیلی مهم اینه که مدل باید یک «زنجیره تفکر» (Chain-of-Thought – CoT) هم ارائه بده. یعنی باید دلیل انتخابش رو به صورت کامل توضیح بده. مثلا بگه: «من پاسخ A را ترجیح می‌دهم، زیرا ابزار بررسی واقعیت نشان داد که پاسخ B دو اشتباه تاریخی دارد، در حالی که تمام اطلاعات پاسخ A توسط جستجوی وب تایید شد».
نکته فنی جالب: در تمام این مراحل، سیستم از خروجی‌های ساختاریافته (Structured Output) استفاده می‌کنه. یعنی به جای اینکه مدل یک متن ساده و آزاد به عنوان جواب برگردونه، مجبورش می‌کنن که جوابش رو در قالب یک فرمت مشخص مثل JSON بده. این کار باعث میشه خطاهای مربوط به پردازش و فهمیدن پاسخ مدل به شدت کم بشه.
حالا که با روش کار این سیستم آشنا شدیم، وقتشه ببینیم در عمل چطور عمل کرده.
فصل چهارم: زمان آزمایش؛ چطور این سیستم جدید را سنجیدند؟
برای اینکه بفهمیم این سیستم جدید چقدر خوب کار می‌کنه، باید اون رو در یک محیط آزمایشگاهی دقیق تست کنیم. این تست‌ها نیاز به دو چیز دارن: مجموعه داده (Dataset) برای آزمایش و رقبا (Baselines) برای مقایسه.
بخش ۴.۱: زمین‌های بازی موجود و یک مشکل: اشباع شدن!
اول از همه، محققان به سراغ بنچمارک‌ها و مجموعه داده‌های معروف رفتن. بنچمارک‌های زیادی برای ارزیابی قاضی‌های هوش مصنوعی وجود دارن، مثل AlpacaEval، MT-Bench، LLMBar و RewardBench.
محققان تصمیم گرفتن از RewardBench استفاده کنن، چون این بنچمارک خیلی جامع هست و بقیه رو هم تا حد زیادی پوشش میده. این بنچمارک شامل حوزه‌های مختلفی مثل استدلال ریاضی، تولید کد و مکالمات عمومی چت‌بات‌ها میشه.
اما اینجا به یک مشکل برخوردن: در بعضی از بخش‌های این بنچمارک، قاضی‌های هوش مصنوعی پیشرفته امروزی، عملکردی نزدیک به ۱۰۰ درصد دارن! به این وضعیت میگن اشباع شدن (Saturation). یعنی این بخش‌ها دیگه اونقدر سخت نیستن که بشه باهاشون تفاوت بین یک قاضی خوب و یک قاضی عالی رو فهمید. مثل اینه که بخواید توانایی دو تا قهرمان دو رو با مسابقه دو ۱۰۰ متر تست کنید، در حالی که هر دو زیر ۱۰ ثانیه می‌دون! برای همین، محققان به این نتیجه رسیدن که برای سنجش واقعی سیستم جدیدشون، به چالش‌های سخت‌تری نیاز دارن.
بخش ۴.۲: ساختن زمین‌های بازی جدید و سخت‌تر
اینجا بود که محققان دست به کار شدن و سه تا مجموعه داده دوتایی (pairwise) جدید ساختن که هر کدوم یکی از اون سه حوزه چالشی رو هدف می‌گرفت:
- LongFact pairwise (برای بررسی متون طولانی و واقعی):
- ایده: ساختن جفت‌پاسخ‌هایی که یکی از نظر اطلاعات واقعی، دقیق‌تر از دیگری باشه.
- روش ساخت: اونها از مجموعه سوالات LongFact که توسط «Wei et al. (2024)» ساخته شده بود، استفاده کردن. با استفاده از مدل
gpt-4o-mini-2024-07-18، برای هر سوال دو تا جواب طولانی و پر از اطلاعات تولید کردن. بعد، به صورت دستی در یکی از این دو جواب، بین ۱ تا ۳ اشتباه واقعی (مثل تاریخ، اسم یا عدد غلط) وارد کردن. این کار رو طوری انجام دادن که فقط اطلاعات عوض بشه و سبک نوشتاری دست نخوره تا کار برای قاضی سخت‌تر بشه. - نتیجه: یک مجموعه داده از جفت‌پاسخ‌هایی که می‌دونیم کدوم یکی از نظر واقعیتی ایراد داره. جالبه بدونید وقتی از ۳ تا انسان خواستن این مجموعه داده رو قضاوت کنن، اونها به طور میانگین فقط در ۷۶.۸۳ درصد موارد با پاسخ طلایی موافق بودن (بدون در نظر گرفتن رای‌های مساوی)، که نشون میده این کار حتی برای انسان‌ها هم سخت بوده.
- APPS competition pairwise (برای بررسی کدهای چالشی):
- ایده: ساختن جفت‌پاسخ‌هایی از کدهای برنامه‌نویسی که یکی درست و دیگری غلط کار می‌کنه.
- روش ساخت: اونها از مجموعه داده معروف APPS که شامل مسائل سخت برنامه‌نویسی در حد مسابقه است، استفاده کردن. فقط بخش «competition» این مجموعه رو که سخت‌ترین مسائل رو داره، برداشتن. برای هر مسئله، یک کدِ راه‌حلِ درست که از قبل وجود داشت رو نگه داشتن. بعد با استفاده از مدل
GPT-4-0613، یک راه‌حل غلط برای همون مسئله تولید کردن. - نتیجه: یک مجموعه داده با ۳۱۰ جفت کد که در هر جفت، یکی کدِ اصلی و درست و دیگری کدِ تولید شده توسط هوش مصنوعی و غلطه.
- GSM8k hard pairwise (برای بررسی مسائل ریاضی سخت):
- ایده: ساختن جفت‌پاسخ‌هایی برای مسائل ریاضی که حتی مدل‌های قوی هم در حلشون مشکل دارن.
- روش ساخت: اونها از مجموعه داده ریاضی GSM8k استفاده کردن. ۱۱۶ مسئله‌ای رو انتخاب کردن که مدل قدرتمند
GPT-4oنتونسته بود اونها رو درست حل کنه. برای هر مسئله، دو تا پاسخ رو در نظر گرفتن: یکی جواب درست و اصلی (ground-truth) و دیگری جواب غلطی که خودGPT-4oداده بود. - نتیجه: یک مجموعه داده از مسائل ریاضی واقعا سخت که یک طرف جواب درست و طرف دیگه جواب غلطیه که یک مدل پیشرفته تولید کرده.
علاوه بر این سه، اونها یک مجموعه داده دیگه هم از روی TruthfulQA ساختن که روی حقایق کوتاه تمرکز داره. این یکی برعکس قبلی‌ها، مجموعه داده آسونیه و بیشتر برای این ساخته شده که ببینن آیا سیستم جدیدشون روی مسائل آسون، عملکرد رو خراب می‌کنه یا نه (که بهش میگن تست رگرسیون).
فصل پنجم: معرفی رقبا؛ سیستم جدید در مقابل چه کسانی قرار گرفت؟
حالا که زمین‌های بازی آماده شدن، باید ببینیم سیستم جدید (که از این به بعد بهش میگیم «عامل ارزیاب» یا Evaluation Agent) قراره با کی مسابقه بده. محققان دو تا از معروف‌ترین و قوی‌ترین قاضی‌های هوش مصنوعی رو به عنوان رقیب اصلی انتخاب کردن:
- قاضی AlpacaEval 2.0: این یکی از محبوب‌ترین قاضی‌های هوش مصنوعیه که توسط «Dubois et al. (2023)» معرفی شده. در این تحقیق از نسخه
weighted_alpaca_eval_gpt4_turboاستفاده شده که با مدل GPT-4-Turbo کار می‌کنه و از روش خاصی به اسم logprob parsing برای استخراج رای نهایی استفاده می‌کنه. - قاضی ArenaHard: این قاضی توسط «Li et al. (2024b)» طراحی شده و به خاطر دستورالعمل‌های (پرامپت) خیلی مفصل و دقیقش معروفه. این قاضی از مدل می‌خواد که حتی خودش یک جواب ایده‌آل بسازه و بعد با دو تا جواب دیگه مقایسه کنه.
علاوه بر این دو رقیب سرسخت، دو تا قاضی مینیمالیستی هم برای مقایسه اضافه شدن:
- یک قاضی ساده که فقط از
GPT-3.5-Turboمی‌خواد که «متن بهتر رو انتخاب کن». - یک قاضی ساده دیگه که همین کار رو با مدل قوی‌تر
GPT-4oانجام میده.
نکته جالب اینه که محققان متوجه شدن همین قاضی ساده که با GPT-4o کار می‌کنه، به طرز شگفت‌انگیزی در خیلی از مجموعه داده‌ها عملکرد رقابتی و خوبی داره!
برای اینکه نتایج قابل اعتماد باشن، تمام آزمایش‌ها (مگر در مواردی که ذکر شده) ۵ بار با بذرهای (seed) تصادفی مختلف تکرار شدن و میانگین و انحراف معیار اونها گزارش شده. این کار کمک می‌کنه مطمئن بشیم نتایج شانسی نیستن.
خب، حالا هم زمین بازی آماده است، هم رقبا. وقتشه بریم سراغ هیجان‌انگیزترین بخش: نتایج!
فصل ششم: نتایج مسابقه؛ عامل ارزیاب چقدر موفق بود؟
در این فصل، می‌خوایم ببینیم سیستم جدید مجهز به ابزار، یعنی «عامل ارزیاب»، در اون سه حوزه چالشی که براش طراحی شده بود، چطور عمل کرده.
بخش ۶.۱: داوری در حوزه متون طولانی و واقعی (Long-Fact Checking)
تست روی مجموعه داده LongFact pairwise انجام شد. یادتونه که در این مجموعه، یکی از پاسخ‌ها به صورت دستی دارای اطلاعات غلط بود. نتایج خیلی جالب بودن.
- مشاهده اول: ابزارهای خارجی واقعا به بهبود عملکرد کمک کردن. در تمام موارد، وقتی قاضی‌های پایه (baselines) به عامل ارزیاب مجهز شدن، دقتشون به شکل قابل توجهی بالا رفت. این بهبود برای همه رقبا دیده شد. مثلا، دقت قاضی ساده
GPT-4o pick-bestاز ۶۳ درصد به ۸۱ درصد رسید! حتی برای قاضی قوی ArenaHard هم یک بهبود دیده شد و دقتش از ۷۸ درصد به ۸۰ درصد افزایش پیدا کرد. این نشون میده که توانایی بررسی خارجی اطلاعات با جستجوی وب، یک مزیت واقعیه. - مشاهده دوم: نوع پرامپت (دستور) تاثیر فوق‌العاده زیادی روی عملکرد قاضی‌های پایه داره. یک نکته خیلی عجیب، تفاوت عملکرد بین قاضی ساده
GPT-4o pick-best(با دقت ۶۳ درصد) و قاضیArenaHard(با دقت ۷۸ درصد) بود. هر دوی اینها از یک مدل اصلی یعنی GPT-4o استفاده می‌کنن! تنها تفاوتشون در پرامپت و روش استخراج جوابه. پرامپت ArenaHard خیلی مفصل‌تره. این نشون میده که برای کارهای مربوط به بررسی واقعیت، فقط داشتن یک مدل قوی کافی نیست، بلکه نحوه «حرف زدن» با اون مدل و دستور داد بهش هم فوق‌العاده مهمه. - مشاهده سوم: عامل ارزیاب از انسان‌ها بهتر عمل کرد! این شاید عجیب‌ترین نتیجه این بخش باشه. توافق عامل‌های ارزیاب (که با مدل‌های خانواده GPT-4 کار می‌کردن) با پاسخ‌های طلایی، بیشتر از توافق خود انسان‌ها بود. یادتونه که انسان‌ها حدود ۷۷ درصد توافق داشتن؟ عامل ارزیاب به دقتی بالای ۸۰ درصد رسید. محققان میگن این اتفاق می‌تونه دلایل مختلفی داشته باشه. مثلا انسان‌ها محدودیت زمانی دارن و ممکنه خسته بشن، اما عامل ارزیاب این محدودیت‌ها رو نداره. همچنین، همونطور که قبلا هم اشاره شد، انسان‌ها ممکنه تحت تاثیر سبک نوشتاری قاطعانه قرار بگیرن و از اشتباهات واقعی غافل بشن، در حالی که عامل ارزیاب با ابزار جستجوی وب، بی‌رحمانه دنبال واقعیت می‌گرده.
بخش ۶.۲: داوری در حوزه ریاضیات سخت (Math-Checking)
این تست روی مجموعه داده GSM8k hard pairwise انجام شد که شامل مسائل ریاضی خیلی سخت بود. نتایج در این حوزه کمی پیچیده‌تر بود.
- مشاهده چهارم: عامل ارزیاب تونست بعضی از رقبا رو شکست بده، اما نه همه رو. در این بخش، نتایج کمی ترکیبی بود. مجهز کردن قاضی‌های پایه به عامل ارزیاب، در بعضی موارد عملکرد رو بهتر کرد، اما یک اتفاق جالب افتاد: قاضی ArenaHard به تنهایی (بدون ابزار) تونست عملکردی بهتر از همه روش‌های مبتنی بر عامل ارزیاب داشته باشه!این نتیجه نشون میده که روش‌های پیچیده‌تر (مثل چارچوب عامل‌محور با ابزارهای خارجی) لزوما و همیشه بهتر از روش‌های نسبتا ساده‌تر (مثل پرامپت خیلی خوب ArenaHard) نیستن. شاید پرامپت ArenaHard به قدری خوب طراحی شده که مدل رو وادار به استدلال ریاضی دقیق‌تری می‌کنه که حتی از کمک گرفتن از ابزار اجرای کد هم موثرتره. البته محققان اشاره می‌کنن که شاید بشه در آینده روش استفاده عامل ارزیاب از ابزار کد برای ریاضیات رو بهتر کرد.
برای اینکه مطمئن بشن، محققان یک تست دیگه هم روی مجموعه داده ریاضی دیگه‌ای به اسم RewardMATH انجام دادن. جالب اینجا بود که روی این مجموعه داده، عامل ارزیاب تونست قاضی ArenaHard رو شکست بده. این نشون میده که عملکرد در حوزه ریاضی خیلی به نوع مسائل بستگی داره.
بخش ۶.۳: داوری در حوزه کدهای پیشرفته (Code-Execution)
این تست روی مجموعه داده APPS competition pairwise انجام شد که شامل کدهای درست و غلط برای مسائل برنامه‌نویسی سطح مسابقه بود. نتایج در این بخش بسیار قاطع و چشمگیر بود.
- مشاهده پنجم: عامل ارزیاب به طرز چشمگیری عملکرد همه رقبا رو در داوری کد بهبود داد. اینجا ابزار اجرای کد (Code Interpreter) واقعا درخشید. عملکرد همه قاضی‌های پایه بعد از مجهز شدن به عامل ارزیاب، به شدت بهتر شد. این بهبود هم برای مدل ضعیف‌تر مثل
GPT-3.5-Turbo(که دقتش از ۳۱ درصد به ۷۱ درصد رسید) و هم برای قاضی قوی ArenaHard (که دقتش از ۳۸ درصد به ۷۲ درصد رسید) صادق بود. این یعنی وقتی پای کد در میونه، توانایی اجرای واقعی کد و دیدن نتیجه‌اش، یک مزیت فوق‌العاده بزرگه که هیچ پرامپت خوبی به تنهایی نمی‌تونه جاش رو بگیره. - مشاهده ششم: قاضی‌های پایه در این حوزه عملکردی بدتر از حدس تصادفی داشتن! این یکی از تکان‌دهنده‌ترین نتایج تحقیقه. دقت یک حدس تصادفی در یک انتخاب دوتایی، ۵۰ درصده. اما تمام قاضی‌های پایه در این مجموعه داده، دقتی بین ۲۶ تا ۴۲ درصد داشتن! یعنی اگه شیر یا خط می‌انداختن، نتیجه بهتری می‌گرفتن!چرا این اتفاق افتاد؟ محققان یک فرضیه دارن. یادتونه که کدهای درست، کدهای اصلی مجموعه داده بودن و کدهای غلط توسط
GPT-4تولید شده بودن؟ ممکنه یک تفاوت سبکی جزئی بین این دو نوع کد وجود داشته باشه. قاضی‌های هوش مصنوعی (که خودشون از خانواده GPT هستن) ممکنه به صورت ناخودآگاه به کدی که توسط یک مدل مشابه خودشون نوشته شده، تمایل بیشتری نشون بدن، حتی اگه اون کد غلط باشه! به این پدیده میگن «سوگیری خود-تقویتی» (self-enhancement bias).اما عامل ارزیاب که کد رو واقعا اجرا می‌کرد، گول این سوگیری رو نخورد و تونست کد درست رو تشخیص بده.
تا اینجا دیدیم که عامل ارزیاب در حوزه‌هایی که براش طراحی شده بود، عمدتا موفق عمل کرده. اما یک سوال مهم باقی می‌مونه: اگه این سیستم رو در حوزه‌هایی به کار ببریم که بهش ربطی نداره، چه اتفاقی می‌افته؟ آیا عملکرد رو خراب می‌کنه؟
فصل هفتم: خارج از منطقه امن؛ عملکرد عامل ارزیاب در حوزه‌های دیگر
در دنیای واقعی، یک قاضی هوش مصنوعی با انواع و اقسام سوالات و پاسخ‌ها روبرو میشه، نه فقط با مسائل سخت ریاضی و کد. ممکنه یک روز بخواد دو تا شعر رو مقایسه کنه، یک روز دیگه دو تا جواب درباره یک موضوع ایمنی (safety) رو بررسی کنه. یک سیستم خوب نباید فقط در تخصص خودش عالی باشه، بلکه باید حواسش باشه در حوزه‌های دیگه «گند نزنه»!
برای همین، محققان عملکرد عامل ارزیاب رو روی بخش‌هایی از بنچمارک RewardBench تست کردن که ربطی به ابزارهای فعلیش نداشتن. این بخش‌ها شامل دسته‌های Chat، Chat Hard و Safety بودن. در این تست، انتظار بهبود عملکرد نداشتن، بلکه هدف این بود که ببینن افت عملکرد چقدر کمه.
- مشاهده هفتم: در کارهای خارج از دامنه، افت عملکرد بسیار ناچیز بود. نتایج نشون داد که استفاده از عامل ارزیاب، عملکرد رو به طور میانگین کمتر از ۲ درصد کاهش داد. این خبر خیلی خوبیه! یعنی اون «نگهبان» مرحله اول (ارزیابی اولیه دامنه) کارش رو به خوبی انجام داده و در اکثر موارد، وقتی دیده ابزارها به درد نمی‌خورن، به درستی به سراغ قاضی پایه رفته. حتی برای قاضی مبتنی بر
GPT-3.5-Turbo، یک بهبود جزئی هم مشاهده شد.
تحلیل عمیق‌تر عملکرد عامل
محققان برای اینکه بهتر بفهمن چرا گاهی اوقات این افت عملکرد جزئی اتفاق می‌افته، یک بررسی دقیق‌تر انجام دادن:
- چند وقت یک‌بار عامل به قاضی پایه رجوع می‌کنه؟ تحلیل‌ها نشون داد که در تست‌های «خارج از دامنه»، عامل ارزیاب در ۷۳.۹ درصد موارد به قاضی پایه رجوع کرده. این در حالیه که در تست‌های «داخل دامنه» (مثل LongFact، GSM8k و APPS)، این عدد فقط بین ۰.۲ تا ۲.۲ درصد بود. این آمار به وضوح نشون میده که سیستم تشخیص دامنه، کارش رو خیلی خوب انجام داده.
- بررسی دستی موارد شکست: اونها ۳۰ موردی رو که عامل ارزیاب با وجود استفاده از ابزار، جواب غلط داده بود، به صورت دستی بررسی کردن. دو دلیل اصلی برای شکست پیدا کردن:
- انتخاب ابزار اشتباه (۹ مورد از ۳۰): مثلا برای یک سوال که مربوط به ایمنی بوده و مدل باید از جواب دادن امتناع می‌کرده (refusal)، عامل ارزیاب به اشتباه ابزار «بررسی واقعیت» رو فعال کرده و به جوابی که اطلاعات واقعی‌تری داشته (ولی خطرناک بوده) رای داده، به جای اینکه به پاسخ امن‌تر رای بده.
- ناتوانی ذاتی مدل (۱۸ مورد از ۳۰): در این موارد، حتی با وجود استفاده از ابزار، مشکل حل نشده. یعنی هم قاضی پایه و هم عامل ارزیاب، هر دو اشتباه کردن. این نشون میده که بعضی از مشکلات، عمیق‌تر از این حرف‌ها هستن و صرفا با ابزار حل نمیشن و به توانایی‌های بنیادی خود مدل زبان برمی‌گردن.
نتایج در حوزه‌های «همسایه»
محققان یک تست دیگه هم انجام دادن. این بار روی حوزه‌هایی که خیلی نزدیک به تخصص‌های عامل ارزیاب بودن، اما ساده‌تر. مثل:
- بررسی حقایق کوتاه (TruthfulQA pairwise): نسخه ساده‌ترِ بررسی واقعیت.
- کدهای ساده (RewardBench HumanEval pairwise): نسخه ساده‌ترِ بررسی کد.
- مسائل ریاضی عمومی (RewardBench PRM pairwise): نسخه ساده‌ترِ بررسی ریاضی.
این حوزه‌ها تقریبا توسط قاضی‌های پیشرفته حل شدن (یعنی اشباع شدن). پس دوباره هدف، دیدن عدم افت عملکرد بود. نتایج اینجا خیلی جالب بود و دو اثر متضاد دیده شد:
- برای بررسی حقایق کوتاه و ریاضیات ساده، عامل ارزیاب تونست به طور مداوم عملکرد رو بهبود بده.
- اما برای کدهای ساده، عملکرد رو کاهش داد (تا ۹ درصد کاهش). یک توضیح احتمالی برای این اتفاق اینه که عملکرد قاضی‌های پایه روی این کدهای ساده، از قبل خیلی بالا بوده (بالای ۹۷ درصد). اضافه کردن یک فرآیند پیچیده مثل عامل ارزیاب، ممکنه فقط نویز اضافی وارد سیستم کرده باشه و این عملکرد عالی رو کمی خراب کرده باشه.
فصل هشتم: نگاهی به کارهای دیگران؛ این تحقیق در کجای دنیای علم قرار می‌گیرد؟
هیچ تحقیقی در خلا انجام نمیشه و همیشه بر پایه کارهای قبلی ساخته میشه. بیایید ببینیم ایده «قاضی با ابزار» چه ارتباطی با تحقیقات دیگه داره.
- قاضی‌های هوش مصنوعی (Pairwise AI annotators): همونطور که گفتیم، ایده استفاده از مدل زبان به عنوان قاضی، ایده جدیدی نیست. کارهایی مثل LLM-as-a-judge، AlpacaEval و G-Eval این ایده رو در جامعه علمی محبوب کردن. همچنین، تحقیقاتی مثل Constitutional AI و RLAIF (یادگیری تقویتی از بازخورد هوش مصنوعی) نشون دادن که میشه از این قضاوت‌های مصنوعی برای آموزش مدل‌ها هم استفاده کرد.
- مشکلات قاضی‌های هوش مصنوعی (AI annotator problems): خیلی از محققان روی پیدا کردن و تحلیل سوگیری‌های این قاضی‌ها کار کردن. ما به سه مورد از مهم‌ترین‌هاشون اشاره کردیم: سوگیری طول (length bias)، سوگیری ترتیب (position bias) و سوگیری خود-تقویتی (self-enhancement bias).
- ارزیاب‌های تقویت‌شده با ابزار (Augmented AI evaluators): ایده اضافه کردن ابزار به ارزیاب‌ها هم قبلا مطرح شده.
- یک کار خیلی مشابه، تحقیقی به اسم Themis هست که توسط «Li et al. (2024a)» انجام شده. اونها هم از ابزارهایی مثل مفسر کد و جستجوی وب استفاده کردن. اما یک تفاوت کلیدی وجود داره: Themis نیاز به یک مدل زبان با معماری سفارشی و فرآیند fine-tuning داره. این یعنی نمیشه ازش با جدیدترین و قوی‌ترین مدل‌های تجاری که به صورت بسته ارائه میشن (closed-source) استفاده کرد. در مقابل، چارچوب عامل ارزیاب طوری طراحی شده که روی هر مدل زبانی سوار بشه. محققان این مقاله سعی کردن Themis رو روی مجموعه داده‌های خودشون تست کنن، اما نتایج موفقی نگرفتن و عملکردش بهتر از حدس تصادفی نبوده.
- کارهای دیگه روی حل مشکلات خاصی تمرکز کردن. مثلا «Dubois et al. (2024)» برای حل مشکل سوگیری طول، یک روش آماری پیشنهاد دادن.
- بعضی‌ها هم پیشنهاد دادن که به جای یک قاضی، از یک «هیئت منصفه» از چند قاضی هوش مصنوعی استفاده کنیم تا نتیجه قابل اعتمادتری بگیریم.
- بررسی واقعیت در خارج از تنظیمات دوتایی: کارهای زیادی هم روی بهتر کردن توانایی مدل‌ها در بررسی واقعیت انجام شده، مثل SAFE (که عامل ارزیاب ازش الهام گرفته)، FActScore و RARR. اینها همگی سعی دارن درستی اطلاعات رو در متن‌ها تایید کنن.
این مرور نشون میده که تحقیق مورد بحث ما، در یک حوزه خیلی فعال و مهم از پژوهش‌های هوش مصنوعی قرار داره و سعی کرده با ترکیب چند ایده موجود، یک راه‌حل عملی و انعطاف‌پذیر برای یک مشکل مشخص ارائه بده.
فصل نهم: چند نکته مهم؛ محدودیت‌ها و هشدارهای این روش
هر تحقیق علمی، محدودیت‌های خودش رو داره و مهمه که با چشم باز به اونها نگاه کنیم. محققان این مقاله هم به صورت شفاف به چند نکته مهم اشاره کردن:
- وابستگی به نوع داده‌ها: همونطور که دیدیم، این سیستم روی حوزه‌های تخصصی خودش (واقعیت، کد، ریاضی) بهترین عملکرد رو داره و روی حوزه‌های دیگه ممکنه حتی عملکرد رو کمی کاهش بده. پس در عمل، مفید بودن این روش بستگی به این داره که شما بیشتر با چه نوع داده‌هایی سروکار دارید. اگه مجموعه داده شما پر از مسائل کد و واقعیت باشه، این روش احتمالا خیلی به دردتون می‌خوره. اما اگه بیشتر با مکالمات عمومی کار می‌کنید، شاید فایده چندانی نداشته باشه.
- محدودیت در حوزه‌های بدون توافق: تمام این آزمایش‌ها روی حوزه‌هایی انجام شد که یک «پاسخ درست» و مورد توافق متخصصان وجود داشت. اما در دنیای واقعی، خیلی از مسائل سلیقه‌ای هستن و جواب درستی براشون وجود نداره (مثلا «کدوم فیلم بهتره؟»). در چنین حوزه‌هایی، هدف یک قاضی چندان مشخص نیست و این روش (و کلا روش LLM-as-a-Judge) با چالش روبرو میشه.
- خطر اتکای بیش از حد به قاضی‌های هوش مصنوعی: یک خطر بالقوه اینه که ما اونقدر به این قاضی‌های مصنوعی تکیه کنیم که دیگه به سراغ قضاوت انسانی نریم. این کار ممکنه باعث بشه مدل‌هایی بسازیم که فقط برای راضی کردن این قاضی‌های مصنوعی بهینه شدن (overfit) و با ارزش‌ها و ترجیحات واقعی انسان‌ها فاصله بگیرن. قاضی‌های هوش مصنوعی باید مکملی برای قضاوت انسانی باشن، نه جایگزین اون.
- اهمیت تنظیمات ساده: نتایج این تحقیق یک درس بزرگ دیگه هم به ما داد: گاهی اوقات تغییرات ساده‌ای مثل نوع پرامپت و روش استخراج پاسخ، می‌تونه تاثیر بسیار زیادی روی عملکرد یک قاضی داشته باشه، حتی اگه مدل اصلی یکی باشه. قبل از اینکه به سراغ راه‌حل‌های پیچیده مثل ابزارهای خارجی بریم، همیشه ارزشش رو داره که تنظیمات ساده‌تر رو هم به دقت تست کنیم.
در نهایت، این تحقیق نشون میده که دنیای ارزیابی مدل‌های زبان هنوز در اول راهه و نیاز به بنچمارک‌های بهتر و روش‌های آماری دقیق‌تری برای سنجش قاضی‌ها داریم تا بتونیم با اطمینان بیشتری در این مسیر قدم برداریم.
فصل دهم: اطلاعات تکمیلی و پشت صحنه (نگاهی به ضمیمه‌ها)
مقاله اصلی شامل یک سری ضمیمه (Appendix) پر از جزئیات فنی و آزمایش‌های اضافیه که نگاه کردن بهشون خالی از لطف نیست و درک ما رو از کار عمیق‌تر می‌کنه.
یک رقیب دیگر: استفاده مستقیم از API OpenAI با ابزار
محققان یک آزمایش جالب دیگه هم انجام دادن. اونها گفتن: «خب، خود API شرکت OpenAI هم قابلیت استفاده از ابزار مثل Code Interpreter و جستجوی وب رو داره. چی میشه اگه ما چارچوب پیچیده خودمون رو کنار بگذاریم و فقط از همین قابلیت استاندارد استفاده کنیم؟».
اونها این سناریو رو روی چهار مجموعه داده تست کردن. نتایج خیلی جالب بود:
- مشاهده A: اضافه کردن ابزار به API استاندارد، هیچ بهبود قابل توجهی در عملکرد ایجاد نکرد! در همه موارد، عملکرد یا تقریبا مساوی بود یا حتی بدتر از حالتی بود که ابزار فعال نبود. این نشون میده که صرفا «دادن ابزار» به مدل کافی نیست. اون چارچوب و راهنمایی که عامل ارزیاب فراهم می‌کنه (مثل ارزیابی اولیه، پرامپت‌های مخصوص هر ابزار و ارزیابی نهایی) برای استفاده موثر از ابزارها ضروریه.
- مشاهده B: اضافه کردن ابزار، قابلیت اطمینان خروجی رو کمتر کرد. وقتی ابزارها برای پرامپت ArenaHard فعال می‌شدن، مدل
GPT-4oاغلب فرمت خروجی درخواستی رو رعایت نمی‌کرد. این باعث می‌شد خیلی از جواب‌هاش قابل پردازش نباشن و عملا قاضی بی‌فایده بشه. این موضوع دوباره حساسیت بالای قاضی‌های هوش مصنوعی به تغییرات کوچک در تنظیمات رو نشون میده.
نتایج روی مجموعه داده RewardMATH
همونطور که در فصل ۶ اشاره شد، محققان یک آزمایش اضافه هم روی مجموعه داده ریاضی RewardMATH انجام دادن که گفته میشه از مسائل ریاضی RewardBench سخت‌تره. در این آزمایش، عامل ارزیاب تونست به طور مداوم و با اختلاف قابل توجهی، قاضی‌های پایه (از جمله ArenaHard) رو شکست بده. این نتایج در جدول زیر خلاصه شده:
| روش (Method) | دقت (Accuracy) |
|---|---|
| Pick-best baseline (GPT-4o) | ۷۵.۴۱ |
| Agent (GPT-4o, tools: fact+code+math, base: pick-best) | ۹۲.۷۵ |
| ArenaHard baseline (GPT-4o) | ۸۷.۹۱ |
| Agent (GPT-4o, tools: fact+code+math, base: ArenaHard) | ۹۲.۵۵ |
این جدول به وضوح نشون میده که در این مجموعه داده سخت‌تر، شکاف عملکردی بین روش مبتنی بر عامل و روش‌های پایه بیشتره و عامل ارزیاب واقعا توانایی‌های خودش رو به رخ کشیده.
بررسی اعتبار داده‌های GSM8k
گزارش‌هایی وجود داشت که ممکنه بعضی از داده‌های مجموعه GSM8k مشکل داشته باشن. برای همین، محققان تمام ۱۱۶ مسئله‌ای که در مجموعه داده GSM8k hard خودشون استفاده کرده بودن رو به صورت دستی دوباره حل و بررسی کردن.
اونها متوجه شدن که دو مورد از این داده‌ها برچسب اشتباه داشتن (یعنی جوابی که به عنوان جواب درست مشخص شده بود، در واقع غلط بود). این حدود ۲ درصد از کل مجموعه داده‌شون بود. نکته جالب این بود که در این دو مورد، عامل ارزیاب به طور مداوم جواب واقعا درست رو انتخاب می‌کرد، در حالی که قاضی‌های پایه گاهی اوقات به اشتباه جواب غلط (ولی برچسب‌خورده به عنوان درست) رو انتخاب می‌کردن. این یعنی این دو داده اشتباه، حتی ممکن بود عملکرد قاضی‌های پایه رو کمی بهتر از واقعیت نشون بدن. اما چون تعدادشون کم بود، تاثیر قابل توجهی روی نتایج کلی نداشت.
راهنمایی برای اضافه کردن ابزارهای جدید
یکی از نقاط قوت این چارچوب، توسعه‌پذیر بودنشه. یعنی بقیه محققان می‌تونن به راحتی ابزارهای جدیدی برای حوزه‌های دیگه بهش اضافه کنن. برای اضافه کردن یک ابزار جدید، سه چیز لازمه:
- سوال‌های ارزیابی دامنه: سوال‌هایی که در مرحله اول پرسیده میشه تا سیستم بفهمه این ابزار به درد می‌خوره یا نه.
- منطق ارزیابی دامنه: کدی که بر اساس جواب سوال‌ها تصمیم می‌گیره ابزار فعال بشه یا نه.
- کد اجرای ابزار: کدی که کار اصلی ابزار رو انجام میده.
محققان یک پیشنهاد هم برای ابزار جدید دادن: یک ابزار ایمنی (Safety tool). اونها در بررسی‌های دستی دیده بودن که عامل ارزیاب گاهی در مسائل مربوط به ایمنی، به جای انتخاب پاسخ امن، پاسخ حاوی اطلاعات واقعی رو انتخاب می‌کنه. یک ابزار ایمنی می‌تونه تشخیص بده که یک سوال پتانسیل خطرناک بودن رو داره و در این صورت، به سیستم بگه که باید پاسخی که امتناع از جواب دادن هست رو ترجیح بده.
تعریف دقیق‌تر از واژه «عامل‌محور» (Agentic)
محققان توضیح میدن که تعریف واژه «Agentic» در ادبیات علمی متفاوته. سیستم اونها بعضی از ویژگی‌های یک عامل رو داره (مثل استفاده از ابزار و نوعی از برنامه‌ریزی)، اما همه ویژگی‌ها رو نه (مثلا برنامه‌ریزی بلندمدت نداره). اونها در نسخه‌های اولیه، سیستم رو عامل‌محورتر و با راهنمایی کمتر طراحی کرده بودن، اما متوجه شدن که این کار باعث مشکلات جدی در قابلیت اطمینان میشه. برای همین، یک تعادل بین آزادی عمل و کنترل ایجاد کردن تا سیستم در عمل مفید باشه.
خب، این هم از درس امروز ما! با هم یک سفر عمیق به دنیای قضاوت و ارزیابی مدل‌های زبان بزرگ داشتیم. دیدیم که این کار چقدر چالش‌برانگیزه و چطور ایده‌های خلاقانه‌ای مثل استفاده از ابزارهای خارجی می‌تونه به ما در ساختن هوش مصنوعی بهتر و قابل اعتمادتر کمک کنه. یادتون باشه که این حوزه به سرعت در حال پیشرفته و همیشه چیزهای جدیدی برای یادگیری وجود داره.
دیدگاهتان را بنویسید