پرش به محتوای اصلی

CRITIC: چرا خوداصلاحی مدل‌های زبانی بزرگ نیازمند بازخورد ابزارهای خارجی است

· زمان مطالعه 7 دقیقه
Mike Thrift
Mike Thrift
Marketing Manager

خواندن مقاله CRITIC (Gou و همکاران، ICLR 2024) مرا به این فکر واداشت که پس از اشتباه یک عامل مالی چه اتفاقی می‌افتد. روش Reflexion به ما آموخت که عامل‌ها می‌توانند از شکست‌های خود در طول دوره‌های مختلف درس بگیرند. اما CRITIC پرسش دقیق‌تری را مطرح می‌کند: آیا یک مدل زبانی بزرگ (LLM) می‌تواند خطاهای خود را در یک مرحله تولید شناسایی و اصلاح کند؟ و اگر بله، واقعاً به چه چیزی برای انجام این کار نیاز دارد؟

مقاله

2026-04-26-نقد-تعاملی-ابزار-خوداصلاحی-مدل-زبانی-CRITIC

سیستم CRITIC چارچوبی را معرفی می‌کند که در آن یک مدل زبانی ابتدا یک خروجی اولیه تولید می‌کند، سپس از طریق یک حلقه «تایید و سپس اصلاح» با استفاده از ابزارهای خارجی پیمایش می‌کند؛ این ابزارها شامل یک API جستجو برای ادعاهای مبتنی بر واقعیت، یک مفسر پایتون برای کدنویسی و محاسبات، و یک طبقه‌بندی‌کننده سمیت برای نظارت بر محتوا است. این حلقه برای تعداد دفعات مشخصی اجرا می‌شود (مقاله نتایج موثری را در حدود سه مرحله اصلاح گزارش می‌دهد) و خروجی نهایی پالایش‌شده‌ای تولید می‌کند که نویسندگان آن را در پاسخگویی به سوالات فرم آزاد (TriviaQA، AmbigNQ، HotpotQA)، سنتز برنامه‌های ریاضی و کاهش سمیت ارزیابی کرده‌اند.

ادعای اصلی این نیست که مدل‌های زبانی بزرگ می‌توانند به تنهایی خود را اصلاح کنند. در واقع موضوع تقریباً برعکس است: ارزش CRITIC دقیقاً از استوار کردن نقد بر یک سیگنال خارجی ناشی می‌شود که مدل نمی‌تواند آن را جعل کند. بدون API جستجو، بهبودهای بخش پاسخگویی به سوالات به نزدیکی صفر می‌رسد یا حتی معکوس می‌شود. این چارچوب به این دلیل کار می‌کند که ابزار چیزی را به مدل می‌گوید که واقعاً نمی‌دانسته است، نه به این دلیل که مدل به یک حسابرسِ خودکارِ قابل اعتماد تبدیل شده است.

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

  • سیستم CRITIC که بر روی ChatGPT اعمال شده، به بهبود میانگین ۷.۷ در نمره F1 در سه وظیفه پاسخگویی به سوالات دامنه آزاد و ۷.۰ واحد درصد رشد مطلق در سه بنچمارک استدلال ریاضی دست یافته است.
  • کاهش سمیت برجسته‌ترین نتیجه منفرد است: کاهش ۷۹.۲ درصدی در احتمال سمیت در مجموعه داده ارزیابی شده.
  • حذف API جستجو باعث می‌شود عملکرد پاسخگویی به سوالات یا متوقف شود یا کاهش یابد؛ توانایی نقدِ خودِ ذاتی مدل برای وظایف مبتنی بر واقعیت تقریباً بی‌فایده است.
  • حلقه به سرعت همگرا می‌شود: سه دور اصلاح، بخش عمده‌ای از دستاوردها را ثبت می‌کند و پس از آن بازدهی کاهش می‌یابد.
  • این چارچوب مستقل از مدل است و نیازی به پیش‌تولید (Fine-tuning) ندارد؛ روی APIهای جعبه‌سیاه از جمله Text-Davinci-003 و ChatGPT کار می‌کند.
  • سیستم CRITIC در اکثر وظایف از روش خودسازگاری (رای‌گیری اکثریت روی نمونه‌های متعدد) بهتر عمل می‌کند، که از این جهت حائز اهمیت است که خودسازگاری هزینه ابزار در هر مرحله را ندارد.

چه چیزی تایید می‌شود — و چه چیزی نه

نتیجه تجربی اصلی محکم است: بازخورد ابزار خارجی به طور معناداری خروجی‌ها را بهبود می‌بخشد، و آزمایش حذف (Ablation) که API جستجو را حذف می‌کند، برای حامیان خوداصلاحیِ ساده‌انگارانه کوبنده است. مقاله همچنین در مورد مکانیسم صادق است؛ دستاوردها از ابزار ناشی می‌شوند، نه از یک ظرفیت فراشناختی نوظهور.

چیزی که به نظرم کمتر بررسی شده، طبقه‌بندی حالت‌های شکست است. چه زمانی مدل یک نقد اشتباه تولید می‌کند که باعث می‌شود از پاسخ درست دورتر شود؟ مقاله عملکرد میانگین را گزارش می‌دهد، اما واریانس در وظایف و انواع سوالات مختلف برای استقرار واقعی بسیار مهم است. در یک بستر مالی، بدترین نتیجه «عدم بهبود» نیست، بلکه یک اصلاحِ به ظاهر درست است که خطای جدیدی را وارد می‌کند.

انتخاب سقف سه تکرار نیز بیشتر به عنوان یک سهولت عملی ارائه شده تا یک معیار توقف اصولی. سه دور ممکن است برای TriviaQA که در آن یک پاسخ مرجع برای همگرایی وجود دارد کارساز باشد. اما در دامنه‌ای مانند تطبیق دفتر کل (Ledger Reconciliation)، جایی که پاسخ «درست» نیازمند استدلال بر روی چندین سند و دانش تخصصی دامنه است، بدیهی نیست که سه فراخوانی ابزار کافی باشد — یا اینکه یک API جستجوی عمومی اصلاً سیگنال تایید مناسبی ارائه دهد.

مقاله همراه در ICLR 2024 با عنوان "مدل‌های زبانی بزرگ هنوز نمی‌توانند استدلال را خوداصلاحی کنند" (Huang et al., arXiv:2310.01798) یافته‌های CRITIC را از جهت دیگر تایید می‌کند: بدون بازخورد خارجی، خوداصلاحی به طور قابل اعتمادی دقت استدلال را کاهش می‌دهد. این دو مقاله با هم تصویری منسجم می‌سازند؛ ظرفیتی که مردم آن را «خوداصلاحی» می‌نامیدند، عمدتاً پالایشی است که توسط بازخورد خارجی هدایت می‌شود، و این تمایز اهمیت زیادی دارد.

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

حلقه CRITIC به طور طبیعی با مسئله امنیت بازنویسی در عامل‌های Beancount مطابقت دارد. در حال حاضر، وقتی یک عامل مدل زبانی بزرگ یک ثبت دفتر روزنامه را پیشنهاد می‌کند — مثلاً دسته‌بندی یک تراکنش یا تقسیم یک هزینه — هیچ راه اصولی برای تایید خروجی خود قبل از ثبت روی دیسک ندارد. معماری CRITIC یک الگوی ملموس را پیشنهاد می‌دهد: تولید یک ورودی کاندید، سپس اجرای تایید در برابر یک ابزار (یک تابع بررسی تراز، یک موتور قوانین، یا یک شناساگر تراکنش تکراری) و استفاده از خروجی ابزار برای درخواست بازنگری قبل از نهایی شدن ثبت.

نتیجه کاهش سمیت، آنالوژی مفیدی است که دوباره بیان شود: کاهش ۷۹.۲ درصدی در نقض قوانین ناشی از درونی‌سازی قوانین توسط مدل نیست، بلکه ناشی از طبقه‌بندی‌کننده‌ای است که تخلفات را به مدل گزارش می‌دهد. برای یک دفتر کل Beancount، معادل آن یک بررسی‌کننده قوانین (Rule-checker) است که تراکنش‌های دوبار محاسبه شده یا نقض دسته‌بندی‌ها را علامت‌گذاری کرده و آن سیگنال را به مرحله بازنگری عامل می‌فرستد. عامل نیازی ندارد مستقلاً بداند که قوانین نقض شده‌اند؛ او به سیگنال ابزار نیاز دارد.

محدودیت بحرانی برای بخش مالی، وابستگی به API جستجو است. عامل‌های مالی به ابزارهای تاییدی نیاز دارند که مختص دامنه باشند: بررسی‌های یکپارچگی تراز حساب، تاییدکننده‌های سرفصل حساب‌ها (Chart-of-accounts)، و جستجوی قوانین مالیاتی. یک جستجوی وب عمومی بعید است که یک هزینه با دسته‌بندی اشتباه را شناسایی کند. ساختن لایه ابزار مناسب برای اصلاح به سبک CRITIC در حسابداری، جایی است که کار مهندسی واقعی نهفته است و مقاله اصلاً به طراحی ابزارهای مختص دامنه نمی‌پردازد.

مطالعه پیشنهادی بعدی

  • "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., 2023, arXiv:2310.01798) — استدلال تجربی مستقیم مبنی بر اینکه خوداصلاحیِ ذاتی شکست می‌خورد؛ باید در کنار CRITIC خوانده شود زیرا هر دو یک مکانیسم را از جهت‌های مخالف بررسی می‌کنند.
  • "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" (Yao et al., NeurIPS 2023, arXiv:2305.10601) — ایده نقد و اصلاح تک‌مسیره را به یک درخت جستجو در مراحل میانی گسترش می‌دهد؛ برای تطبیق‌های چند مرحله‌ای که در آن عامل نیاز به کاوش و بازگشت به عقب (Backtrack) دارد، مرتبط است.
  • "ToolBench: Facilitating Large Language Models in Mastering 16000+ Real-world APIs" (Qin et al., 2023, arXiv:2307.16789) — بررسی می‌کند که عامل‌ها چگونه انتخاب و زنجیره‌سازی فراخوانی ابزارها را یاد می‌گیرند، که مسئله‌ای است که در CRITIC به عنوان پیش‌فرض در نظر گرفته شده است.