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

درخت افکار: حل مسئله آگاهانه با جستجوی مدل‌های زبانی بزرگ

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

پس از اختصاص دو مطلب اخیر به عامل‌هایی که از طریق تامل (Reflexion) و نقد تعاملی با ابزار (CRITIC) خود-اصلاحی می‌کنند، می‌خواستم کمی به عقب برگردم و به یک رویکرد ساختاری‌تر نگاه کنم: چه می‌شود اگر عامل در وهله اول هرگز به یک مسیر استدلال واحد متعهد نشود؟ «درخت افکار» (Tree of Thoughts یا ToT) از یائو و همکاران (NeurIPS 2023) دقیقاً همین را پیشنهاد می‌کند — یک چارچوب جستجو که در آن مدل زبانی (LLM) به جای یک زنجیره خطی، فضای شاخه‌ای از مراحل استدلال میانی را کاوش می‌کند. من اکنون آن را می‌خوانم زیرا شفاف‌ترین فرمول‌بندی جستجوی آگاهانه برای استدلال مدل‌های زبانی بزرگ را نشان می‌دهد، و جستجوی آگاهانه چیزی است که شما زمانی به آن نیاز دارید که یک مرحله میانی اشتباه در یک محاسبه مالی بتواند بی-صدا تمام خروجی‌های بعدی را خراب کند.

مقاله

2026-04-27-tree-of-thoughts-deliberate-problem-solving

شونیو یائو، دیان یو، جفری ژائو، ایزاک شافران، توماس ال. گریفیث، یوآن کائو و کارتیک ناراسیمهان، «درخت افکار» را به عنوان تعمیمی از پرامپت‌نویسی زنجیره افکار معرفی می‌کنند. حرکت کلیدی این است که مراحل استدلال میانی به عنوان «افکار» (واحدهای متنی منسجم که می‌توانند به‌طور مستقل ارزیابی شوند) در نظر گرفته شوند و به جای یک زنجیره، در یک درخت سازماندهی شوند. در هر گره، مدل چندین فکر کاندید تولید می‌کند، هر یک را ارزیابی می‌کند (از طریق یک فراخوانی جداگانه مدل زبانی که وضعیت‌ها را به عنوان «مطمئن / شاید / غیرممکن» امتیازدهی می‌کند) و سپس یک الگوریتم جستجوی استاندارد (BFS یا DFS) را برای پیمایش درخت اعمال می‌کند. اگر شاخه‌ای بن‌بست به نظر برسد، مدل می‌تواند آن را هرس کند یا به عقب بازگردد (Backtrack) — کاری که نه CoT و نه CoT-SC قادر به انجام آن نیستند.

این مقاله در سه تسک ارزیابی می‌شود: بازی ۲۴ (ترکیب چهار عدد برای رسیدن به ۲۴ با استفاده از محاسبات ریاضی)، نویسندگی خلاق (تولید یک متن منسجم با استفاده از چهار پایان جمله تصادفی) و مینی جدول کلمات متقاطع (حل یک جدول ۵×۵). هر سه مورد نیاز به استدلالی دارند که می‌تواند از کاوش و بازگشت به عقب بهره ببرد، که دقیقاً همان شرایطی است که نویسندگان برای آن طراحی کرده‌اند.

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

  • در بازی ۲۴، ToT با عرض پرتو (beam width) b=5 به ۷۴٪ موفقیت دست می‌یابد، در مقابل ۴٪ برای GPT-4 با CoT استاندارد و ۹٪ برای CoT-SC با ۱۰۰ نمونه. این شکاف خیره‌کننده است.
  • مدل GPT-3.5 + ToT در همین تسک تنها به ۱۹٪ می‌رسد؛ مزیت این روش به شدت به مدل وابسته است. کیفیت تولید فکر در GPT-4 است که بیشترِ بهبود را رقم می‌زند — ترکیب تولید GPT-4 + ارزیابی GPT-3.5 به ۶۴٪ می‌رسد، در حالی که تولید GPT-3.5 + ارزیابی GPT-4 تنها ۳۱٪ موفقیت دارد.
  • برای نویسندگی خلاق، ToT در مقیاس انسجام GPT-4 امتیاز ۷.۵۶ را در مقابل ۶.۹۳ برای CoT کسب می‌کند و ارزیاب‌های انسانی خروجی‌های ToT را در ۴۱ مورد از ۱۰۰ بار نسبت به ۲۱ مورد از ۱۰۰ برای CoT ترجیح می‌دهند.
  • مینی جدول کلمات متقاطع: ToT به دقت ۶۰٪ در سطح کلمه می‌رسد (CoT: ۴۰.۶٪، IO: ۱۵.۶٪) اما تنها ۴ بازی کامل از ۲۰ بازی را حل می‌کند (۲۰٪). شکاف بین موفقیت در سطح کلمه و سطح بازی نشان می‌دهد که حتی با بازگشت به عقب، ارضای محدودیت‌های سراسری (global constraint satisfaction) همچنان دشوار است.
  • مرحله ارزیابی خود یک فراخوانی مدل زبانی است. در جدول کلمات، مقاله اشاره می‌کند که ارزیاب‌ها گاهی اوقات وضعیت‌های جزئیِ صحیح را به دلیل واژگان ناآشنا «غیرممکن» قلمداد می‌کنند — یک حالت شکست مرکب که در آن اشتباهات ارزیاب، جستجو را مسموم می‌کند.
  • هزینه محاسباتی: ToT در بازی ۲۴ تقریباً ۰.۷۴ دلار برای هر مورد هزینه دارد، در حالی که هزینه CoT (بهترین از ۱۰۰ مورد) ۰.۴۷ دلار است. خود نویسندگان اشاره می‌کنند که برای تسک‌هایی که GPT-4 در حال حاضر به خوبی از عهده آن‌ها برمی‌آید، این سربار ارزشش را ندارد.

چه چیزی پابرجا می‌ماند — و چه چیزی نه

نتیجه اصلی — این که جستجوی درختی روی افکار میانی در تسک‌هایی که نیاز به بازگشت به عقب دارند، بسیار بهتر از CoT متوالی عمل می‌کند — واقعی و بازتولیدپذیر است. شکاف ۷۴٪ در مقابل ۴٪ در بازی ۲۴ نویز نیست. توضیح آن از نظر مکانیکی درست است: یک معادله میانی اشتباه در CoT کل زنجیره را به دره می‌فرستد، در حالی که ToT می‌تواند آن شاخه را هرس کرده و تجزیه متفاوتی را امتحان کند.

آنچه برای من کمتر متقاعدکننده است، ادعای تعمیم‌پذیری است. هر سه تسک ارزیابی نسبتاً مصنوعی هستند: یک پازل ریاضی، یک پرامپت نویسندگی خلاق با محدودیت‌های ساختاری و یک بازی کلمات. هیچ‌کدام از آن‌ها شبیه به مسائل باز و مبهمی نیستند که در جریان‌های کاری مالی واقعی ظاهر می‌شوند. نویسندگان همچنین تنها بر روی GPT-4 (و GPT-3.5 به عنوان تحلیل فرسایشی) ارزیابی انجام داده‌اند، بنابراین نمی‌دانیم ToT با مدل‌های کوچک‌تر یا تنظیم‌شده (Fine-tuned) چگونه عمل می‌کند — و رقم ۱۹٪ برای GPT-3.5 نشان می‌دهد که پاسخ احتمالاً «نه چندان خوب» است.

شکست در سطح بازی در جدول کلمات (۲۰٪ با وجود دقت ۶۰٪ کلمات) به یک مشکل عمیق‌تر اشاره دارد: ToT یک جستجوی محلی است که توسط یک ارزیاب محلی هدایت می‌شود. این روش یک مدل محدودیت سراسری را حفظ نمی‌کند، که دقیقاً همان چیزی است که برای مسائلی با تعاملات متراکم بین زیر-راه‌حل‌ها نیاز دارید. مقاله بعدی «گراف افکار» (Besta et al., AAAI 2024) این انتقاد را صریحاً بیان می‌کند و بهبود کیفی ۶۲ درصدی را نسبت به ToT در تسک‌های مرتب‌سازی نشان می‌دهد در حالی که هزینه‌ها را بیش از ۳۱٪ کاهش می‌دهد — با اجازه دادن به افکار برای ادغام شدن و تشکیل چرخه به جای محدود شدن در یک درخت.

در نهایت، ساختار هزینه در عمل اهمیت دارد. در b=5 با فراخوانی‌های مکرر ارزیاب، ToT در فراخوانی‌های API تقریباً ۱۵ تا ۲۰ برابر گران‌تر از یک پاس CoT واحد است. برای اپلیکیشن‌های حساس به تأخیر یا حساس به هزینه، این موضوع به سادگی قابل پذیرش نیست.

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

پاسخ صادقانه این است: ToT بیشترین اهمیت را برای بخش کوچکی از فضای مسائل Beancount دارد، اما آن بخش واقعی است.

تسک مالی کلاسیکی که در آن من بازگشت به عقب را می‌خواهم، طبقه‌بندی حساب چندمرحله‌ای با تراکنش‌های مبهم است. هنگامی که یک مدل زبانی در حال نگاشت یک صورت‌حساب بانکی وارد شده به یک نمودار حساب‌ها است، یک تخصیص اشتباه در ابتدای زنجیره (مثلاً در نظر گرفتن بازپرداخت وام به عنوان درآمد) می‌تواند در چند مرحله بعد منجر به شکست در بررسی تراز (Balance check) شود. در یک عامل CoT، زمانی که تراز با شکست مواجه می‌شود، مدل مکانیسمی برای بازنگری در طبقه‌بندی اولیه ندارد. یک عامل ToT می‌تواند به آن گره بازگردد و به جای آن Liabilities:Loans را امتحان کند.

به همین ترتیب، بهینه‌سازی مالیاتی در یک سال مالی کامل یک مسئله جستجوی درختی واقعی است: تفکیک هزینه‌ها در مقابل استفاده از کسر استاندارد، زمان‌بندی تحقق سود سرمایه‌ای، تجمیع کمک‌های خیریه. این تصمیمات به صورت غیرخطی با هم تعامل دارند و شما باید قبل از تعهد به یک مسیر، چندین شاخه را ارزیابی کنید. ساختار BFS/DFS در ToT به‌طور طبیعی بر این ساختار منطبق می‌شود.

آنچه ToT به آن کمکی نمی‌کند، موارد غالب در Beancount است: ثبت تراکنش‌های روتین و مغایرت‌گیری. برای تراکنشی که دارای یک معادل شفاف در دفتر کل است، CoT + PAL (برون‌سپاری محاسبات به یک مفسر کد) سریع‌تر، ارزان‌تر و در حال حاضر به اندازه کافی دقیق است. استفاده از ToT برای طبقه‌بندی expenses:groceries مانند استفاده از پتک برای کوبیدن پونز است.

نگرانی جدی‌تر برای امنیت بازنویسی، مشکل قابلیت اطمینان ارزیاب است. اگر ارزیابِ وضعیت نیز یک مدل زبانی باشد، می‌تواند اشتباه کند — و ارزیابی‌های اشتباه فقط جستجو را کند نمی‌کنند، بلکه مسیرهای درست را هرس می‌کنند. هر عامل مالی تولیدی که از ToT استفاده می‌کند، به یک اوراکل خارجی (یک بررسی تراز، یک اعتبارسنج شِما، یک موتور قوانین) برای ایفای نقش ارزیاب نیاز دارد، نه یک فراخوانی مدل زبانی دیگر.

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

  • گراف افکار: حل مسائل پیچیده با مدل‌های زبانی بزرگ (Besta et al., AAAI 2024) — arXiv:2308.09687. ToT را از درخت به گراف‌های دلخواه گسترش می‌دهد و ادغام افکار و حلقه‌های بازخورد را ممکن می‌سازد. ادعای کاهش هزینه (بیش از ۳۱٪) در صورتی که به دنبال استدلال مبتنی بر جستجو بدون سربار ToT هستید، مستقیماً مرتبط است.
  • مدل‌های زبانی بزرگ هنوز نمی‌توانند استدلال را خود-اصلاح کنند (Huang et al., ICLR 2024) — arXiv:2310.01798. یک نقطه مقابل انتقادی: بدون بازخورد خارجی، خود-اصلاحی ذاتی عملکرد استدلال را کاهش می‌دهد. این موضوع این فرض را که ارزیاب مبتنی بر LLM در ToT به اندازه کافی برای هدایت جستجو قابل اطمینان است، به چالش می‌کشد.
  • RethinkMCTS: اصلاح افکار اشتباه در جستجوی درختی مونت کارلو برای تولید کد (arXiv:2409.09584) — از MCTS به جای BFS/DFS برای جستجوی افکار استفاده می‌کند، همراه با بازخورد اجرا به عنوان اوراکل خارجی. فضای تولید کد از نظر ساختاری شبیه به بازنویسی دفتر کل است: شما یک حقیقت غایی قابل تأیید دارید (آیا کد اجرا می‌شود؟ آیا بررسی تراز پاس می‌شود؟)، که دقیقاً همان جایی است که رول‌اوت‌های مونت کارلو ارزش افزوده ایجاد می‌کنند.