Преминете към основното съдържание

LLM все още не могат да коригират сами логическите си разсъждения — изводи от ICLR 2024 и последици за финансовия ИИ

· 7 минути четене
Mike Thrift
Mike Thrift
Marketing Manager

Тази статия е прекият противовес на работите по CRITIC и Reflexion, които четох напоследък. Huang и др. (ICLR 2024) излагат прост и неудобен аргумент: когато LLM се опитват да коригират сами разсъжденията си без външен сигнал, те не се подобряват — те се влошават. Веднага след LOG-013 за CRITIC, където критикуването, основано на инструменти, действително помогна, тази статия изяснява точно какъв вид „самокорекция“ е реална и какво е артефакт на експерименталната постановка.

Статията

2026-04-28-llms-cannot-self-correct-reasoning-yet

„Large Language Models Cannot Self-Correct Reasoning Yet“ от Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song и Denny Zhou (Google DeepMind / UIUC) беше публикувана на ICLR 2024. Основното твърдение е тясно дефинирано, но съкрушително за определен клас проекти на агенти: вътрешната самокорекция — изискването LLM да прегледа и ревизира собствения си отговор, използвайки само собствената си преценка, без сигнал за действителна истинност (ground-truth) — постоянно влошава представянето при бенчмарковете за разсъждение. Авторите твърдят, че подобренията, отчетени в няколко предходни статии за самокорекция, са резултат от фин методологичен дефект: тези статии са използвали етикети от „оракул“, за да решат кога да спрат корекцията, което означава, че моделът коригира само вече грешните отговори. Това не е самокорекция; това е филтриране, насочвано от оракул.

Ключови идеи

  • При GSM8K, GPT-4 започва с 95,5% точност. След един кръг на вътрешна самокорекция тя пада на 91,5%, а след втори кръг — на 89,0%. GPT-3.5 пада от 75,9% на 74,7% за два кръга.
  • Спадът е по-драматичен при CommonSenseQA: GPT-3.5 пада от 75,8% на 38,1% след един единствен кръг на самокорекция, възстановявайки се леко до 41,8% във втори кръг — но все още катастрофално под базовото ниво.
  • Анализът на промените в отговорите при GSM8K показва, че моделът променя верни отговори в грешни по-често, отколкото грешни в верни. Нетната посока на промяната е вредна.
  • Самокорекцията, насочвана от оракул, действително подобрява нещата: GPT-4 при GSM8K с етикети от оракул преминава от 95,5% на 97,5%, а GPT-3.5 при CommonSenseQA от 75,8% на 89,7%. Но това изисква знание кои отговори са грешни — нещо, което не можете да знаете в реална среда.
  • Дебатът между множество агенти (multi-agent debate), друга популярна идея, се представя по-зле от простата самосъгласуваност (self-consistency), когато се изравни бюджетът за извод (inference budget). С общо 9 отговора, самосъгласуваността достига 88,2% при GSM8K; дебатът между множество агенти достига едва 83,0%.
  • Генерирането с ограничения (CommonGen-Hard) изглежда като победа за самокорекцията в началото (44% → 67%), но този принос се изпарява, ако просто подобрите първоначалната подкана (81,8%). Когато началната подкана е вече добра, самокорекцията вреди, намалявайки точността до 75,1%.

Какво се потвърждава — и какво не

Основният извод е солиден: цифрите са такива, каквито са. Ако подканите GPT-4 да преразгледа своите математически отговори, без да му казвате кои са грешни, отговорите стават по-лоши средно. Интуицията, която статията предлага, също е правилна — LLM не могат надеждно да съдят за коректността на собствените си разсъждения, така че когато решат да променят отговор, те гадаят и гадаят грешно поне толкова често, колкото гадаят вярно.

Статията е по-малко убедителна в твърденията си за обобщение. Тя тества изключително задачи за разсъждение и знания. Има области — стил на писане, спазване на ограниченията на формата, намаляване на токсичността — където итеративната ревизия вероятно помага, и статията до голяма степен заобикаля тези теми. Авторите признават това мимоходом, отбелязвайки, че „самокорекцията може да бъде по-ефективна за задачи, при които оценката е по-проста“, но не го тестват внимателно. Експериментът с генериране с ограничения CommonGen е показателен, но използването на неадекватна първоначална подкана като база и наричането на последвалото подобрение „самокорекция“ е същият методологичен дефект, който статията критикува в други работи.

Статията също така не засяга въпроса за обучената самокорекция. Последващо проучване от 2025 г. (SCoRe, ICLR 2025, arXiv:2409.12917) показва, че самокорекцията, обучена чрез RL върху собствените резултати на модела, постига +15,6% при MATH и +9,1% при HumanEval — истинско вътрешно подобряване. Така че заглавието „не могат да се самокоригират все още“ е остаряло по-добре, отколкото едно по-категорично твърдение би позволило; правилната интерпретация е „не могат да бъдат подтикнати към самокорекция само чрез подкани“, а не „не могат да се научат да се самокоригират“.

Защо това е важно за финансовия ИИ

Последиците за агентите за обратно записване в счетоводната книга са конкретни. Агент, който генерира Beancount запис в дневника, а след това се пита „това изглежда ли правилно?“ и го ревизира, не получава второ мнение — той внася шум. Данните тук казват, че ако първият отговор е бил грешен, самопрегледът е толкова вероятно да развали правилен отговор, колкото и да поправи грешен.

Това, което тази статия потвърждава, е ограничението в дизайна, което извлякох от CRITIC: самовалидацията без външен оракул е ненадеждна. Специално за Beancount, външният оракул е наличен и евтин — проверките на баланса (balance assertions) се изпълняват за милисекунди, имената на сметките се валидират спрямо известен сметкоплан, сумите трябва да се изравняват до цент. Архитектура на агент, която изпраща пробен запис, изпълнява bean-check и връща всяка грешка като конкретна структурирана обратна връзка, е фундаментално различна от тази, която иска от модела да „прегледа своя запис в дневника“. Първата използва счетоводния двигател като оракул. Втората разчита на същия механизъм за разсъждение, който е произвел грешката на първо място.

Тук има и един по-фин урок за дизайна на подканите (prompt design). Експериментът CommonGen показва, че когато подканата е вече прецизна и експлицитна, самокорекцията влошава представянето. Това означава, че ако инвестираме усилия в писането на много ясни подкани за парсване на трансакции — такива, които заявяват изрично всички синтактични правила на Beancount — добавянето на цикъл за самопреглед върху тях може активно да навреди на точността. Правилната архитектура вероятно задейства самопрегледа при неуспешна външна проверка, а не при всяко генериране.

Какво да прочетете след това

  • SCoRe: Training Language Models to Self-Correct via Reinforcement Learning (arXiv:2409.12917, ICLR 2025) — базиран на RL подход, който постига първите истински вътрешни печалби от самокорекция; необходим контекст за разбиране на това какво текущата статия включва или изключва.
  • When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs (TACL 2024) — систематична таксономия на това кога самокорекцията работи, разграничаваща вътрешни, базирани на обучение и подпомагани от инструменти варианти.
  • Self-Refine: Iterative Refinement with Self-Feedback (NeurIPS 2023) — основната статия, която Huang и др. критикуват; четенето ѝ веднага след това изяснява точно къде е вградено предположението за етикети от оракул.