Чому мовні моделі «загублюються» в розмові

Нова робота від Microsoft Research і Salesforce показує, що навіть найкращі великі мовні моделі (LLM) розпадаються, коли інструкції подаються не одразу, а поетапно. Автори виявили, що продуктивність падає в середньому на 39 відсотків за шість завдань, коли підказка розділена на кілька частин:

Одна поворотна розмова (ліворуч) дає найкращі результати, але є ненатуральною для кінцевого користувача. Багатоповоротна розмова (праворуч) показує, що навіть найкращі моделі втрачають ефективний імпульс у розмові. Джерело: https://arxiv.org/pdf/2505.06120

Більш того, надійність відповідей різко падає, а престижні моделі, такі як ChatGPT-4.1 і Gemini 2.5 Pro, коливаються між майже ідеальними відповідями та явними невдачами, залежно від того, як задано одне й те саме завдання; крім того, консистентність виходу може впасти більш ніж наполовину під час цього процесу.

Для вивчення цього поведінки робота вводить метод, названий шардінг*, який розбиває повністю визначені підказки на менші фрагменти та випускає їх один за одним у розмові.

У найосновнішому сенсі це еквівалентно тому, щоб дати цілісний та повний наказ у ресторані, залишивши офіціанта з нічого не робити, окрім як підтвердити запит; або вирішити проблему спільно:

Дві крайні версії розмови в ресторані (не з нової роботи, для ілюстрації).

Для наголосу приклад вище, можливо, показує клієнта у негативному світлі. Але основна ідея, зображена у другому стовпчику, полягає у транзакційному обміні, який уточнює проблему до того, як звернутися до неї – очевидно раціональний і розумний спосіб підходу до завдання.

Ця установка відображається у новій роботі з підходом до взаємодії з LLM, який називається шардінг. Автори відзначають, що LLM часто генерують надто довгі відповіді та продовжують покладатися на свої власні ідеї навіть після того, як ці ідеї були визнані неправильними чи неважливими. Ця тенденція, у поєднанні з іншими факторами, може призвести до того, що система втрачає слід розмови зовсім.

Насправді дослідники відзначають те, що багато з нас виявили анекдотично – що найкращий спосіб повернути розмову на правильний шлях полягає у тому, щоб розпочати нову розмову з LLM.

‘Якщо розмова з LLM не привела до очікуваних результатів, розпочинання нової розмови, яка повторює одну й ту ж інформацію, може привести до значно кращих результатів, ніж продовження тривалої розмови.’

‘Це відбувається тому, що поточні LLM можуть загубитися в розмові, а наші експерименти показують, що продовження розмови з моделлю неефективне. Крім того, оскільки LLM генерують текст з випадковістю, нова розмова може привести до покращення результатів.’

Автори визнають, що агентні системи, такі як Autogen або LangChain, потенційно можуть покращити результати, діючи як інтерпретативні шари між кінцевим користувачем та LLM, спілкуючись з LLM лише тоді, коли вони зібрали достатньо «шардених» відповідей, щоб сформувати єдину цілісну запит (який кінцевий користувач не побачить).

Однак автори стверджують, що окремий абстрактний шар не повинен бути необхідним, або повинен бути побудований безпосередньо в джерельній LLM:

‘Можна сказати, що багаторозмовні можливості не є необхідною функцією LLM, оскільки її можна передати до агентської структури. Інакше кажучи, чи потрібно нам рідна багаторозмовна підтримка в LLM, коли агентська структура може оркеструвати взаємодію з користувачами та використовувати LLM лише як одноповоротні оператори?…’

Але після того, як вони протестували цю пропозицію через свій масив прикладів, вони дійшли висновку:

‘[Покладатися] на агентську структуру для обробки інформації може бути обмежувальним, і ми стверджуємо, що LLM повинні рідно підтримувати багаторозмовну взаємодію’

Ця цікава нова робота називається LLM Get Lost In Multi-Turn Conversation і походить від чотирьох дослідників з MS Research і Salesforce,

Фрагментовані розмови

Новий метод спочатку розбиває звичайні одноповоротні інструкції на менші шарди, призначені для введення в ключові моменти під час взаємодії з LLM, структура, яка відображає дослідницький, зворотний стиль взаємодії, спостережуваний у системах, таких як ChatGPT або Google Gemini.

Кожна оригінальна інструкція являє собою єдину, самодостатню підказку, яка доставляє все завдання одразу, поєднуючи високорівневе питання, підтримуючий контекст та будь-які відповідні умови. Шардова версія розбиває це на кілька менших частин, з кожним шардом, який додає лише одну частину інформації:

<img class=" wp-image-217458" src="https://www.unite.ai/wp-content/uploads/2025/05/sharded-and-unsharded.jpg" alt="Парні інструкції, що показують (а) повну підказку, доставлену в одному повороті, і (б) її шардову версію, використану для симуляції недовизначеної багаторозмовної взаємодії. Семантично кожна версія доставляє одну й ту ж інформаційну вантаж.

Перший шард завжди вводить основну мету завдання, тоді як інші надають уточнюючі деталі. Разом вони доставляють той самий вміст, що й оригінальна підказка, але розподілені природно по кілька поворотів у розмові.

Кожна симульована розмова розгортається між трьома компонентами: асистентом, моделлю, що оцінюється; користувачем, симульованим агентом з доступом до повної інструкції у шардовій формі; і системою, яка наглядає та оцінює обмін.

Розмова починається з того, що користувач розкриває перший шард, і асистент відповідає вільно. Система потім класифікує цю відповідь у одну з кількох категорій, таких як кларифікаційна запит, або повна спроба відповіді.

Якщо модель спробує відповісти, окремий компонент витягує лише відповідну частину для оцінки, ігноруючи будь-який оточуючий текст. На кожному новому повороті користувач розкриває одну додаткову шарду, спонукаючи до іншої відповіді. Обмін триває до тих пір, поки модель не дасть правильну відповідь або не закінчаться шарди, які потрібно розкрити:

Діаграма симуляції шардової розмови, з оцінюваною моделлю, виділеною червоним.

Ранні тести показали, що моделі часто запитували про інформацію, яка ще не була подана, тому автори відмовилися від ідеї розкривати шарди у фіксованому порядку. Замість цього був використаний симулятор для вирішення, яку шарду розкрити далі, залежно від того, як розгорталася розмова.

Симулятор користувача, реалізований за допомогою GPT-4o-mini, був наданий повний доступ до всієї інструкції та історії розмови, завдання якого полягало у вирішенні, яку шарду розкрити далі на кожному повороті, залежно від того, як розгорталася розмова.

Симулятор користувача також перефразував кожну шарду для підтримки розмовного потоку, не змінюючи значення. Це дозволило симуляції відображати «віддання та прийняття» реальної діалогу, зберігаючи при цьому контроль над структурою завдання.

Перед початком розмови асистенту надається лише базова інформація, необхідна для виконання завдання, така як схема бази даних або посилання на API. Йому не кажуть, що інструкції будуть розбиті, і його не спрямовують до якогось конкретного способу обробки розмови. Це робиться навмисно: у реальному використанні моделі майже ніколи не кажуть, що підказка буде неповною або оновленою з часом, і відсутність цього контексту допомагає симуляції відображати поведінку моделі у більш реальному контексті.

GPT-4o-mini також використовувався для вирішення того, як класифікувати відповіді моделі, і для витягання будь-яких остаточних відповідей з цих відповідей. Це допомогло симуляції зберегти гнучкість, але також ввело періодичні помилки: однак після перевірки кількох сотень розмов вручну автори виявили, що менше п’яти відсотків мали будь-які проблеми, і менше двох відсотків показали зміну результату через них, і вони вважали це низьким рівнем помилок у межах проекту.

Симуляційні сценарії

Автори використали п’ять типів симуляції для тестування поведінки моделі під різними умовами, кожен з яких є варіацією того, як і коли частини інструкції розкриваються.

У Повному режимі модель отримує всю інструкцію в одному повороті. Це представляє стандартний формат бенчмарку і служить базовим рівнем продуктивності.

Шардова установка розбиває інструкцію на кілька частин і доставляє їх одну за однією, симулюючи більш реалістичну недовизначену розмову. Це основний режим, який використовується для тестування того, як добре моделі обробляють багаторозмовний вхід.

У Конкат режимі шарди зшиваються назад у єдиний список, зберігаючи їх формулювання, але видаляючи поворотну структуру. Це допомагає ізолювати ефекти розмовної фрагментації від перефразування чи втрати вмісту.

Резюме режим працює як Шардова, але додає остатній поворот, де всі попередні шарди повторюються перед тим, як модель дає остаточну відповідь. Це тестиє, чи може резюмуюча підказка допомогти відновити втрачений контекст.

Нарешті, Сніжкова куля йде далі, повторюючи всі попередні шарди на кожному повороті, зберігаючи повну інструкцію видимою, поки розмова розгортається – і пропонуючи більш поблажливий тест багаторозмовної здатності.

Типи симуляції на основі шардових інструкцій. Повністю визначена підказка розбивається на менші частини, які можна використовувати для симуляції або одноповоротної (Повна, Конкат), або багаторозмовної (Шардова, Резюме, Сніжкова куля) розмови, залежно від того, як швидко інформація розкривається.

Завдання та метрики

Було вибрано шість завдань генерації, щоб охопити як програмування, так і природно-мовні домени: підказки генерації коду були взяті з HumanEval і LiveCodeBench; запитів Text-to-SQL були взяті з Spider; API-дзвінки були побудовані за допомогою даних з Berkeley Function Calling Leaderboard; елементарні математичні завдання були надані GSM8K; завдання табличного підпису були засновані на ToTTo; і багатодокументні резюме були взяті з набору даних Summary of a Haystack.

Продуктивність моделі була виміряна за допомогою трьох основних метрик: середньої продуктивності, здатності і ненадійності.

Середня продуктивність показала, як добре модель працювала в цілому за кілька спроб; здатність відображала найкращі результати, яких могла досягти модель, засновані на її найкращих виходах; і ненадійність вимірювала, наскільки ці результати варіювалися, з більшим розривом між найкращими та найгіршими результатами, вказуючи на менш стабільну поведінку.

Усі оцінки були розміщені на шкалі від 0 до 100, щоб забезпечити узгодженість через завдання, і метрики були обчислені для кожної інструкції – а потім усереднені, щоб надати загальне уявлення про продуктивність моделі.

Шість шардових завдань, використаних у експериментах, які охоплюють як програмування, так і генерацію природної мови. Кожне завдання показано з повною інструкцією та її шардовою версією. Між 90 і 120 інструкцій були адаптовані з встановлених бенчмарків для кожного завдання.

Претенденти та тести

У початкових симуляціях (з оціненою вартістю 5000 доларів) 600 інструкцій, що охоплюють шість завдань, були шардовані та використані для симуляції трьох типів розмови: повної, конкат і шардової. Для кожної комбінації моделі, інструкції та типу симуляції було проведено десять розмов, що дало понад 200 000 симуляцій загалом – схема, яка дозволила захопити як загальну продуктивність, так і глибші міри здатності та надійності.

Було протестовано 15 моделей, що охоплюють широкий спектр постачальників та архітектур: моделі OpenAI GPT-4o (версія 2024-11-20), GPT-4o-mini (2024-07-18), GPT-4.1 (2025-04-14) і модель мислення o3 (2025-04-16).

Моделі Anthropic були Claude 3 Haiku (2024-03-07) і Claude 3.7 Sonnet (2025-02-19), доступні через Amazon Bedrock.

Google внесли Gemini 2.5 Flash (попередній перегляд-04-17) і Gemini 2.5 Pro (попередній перегляд-03-25). Моделі Meta були Llama 3.1-8B-Instruct і Llama 3.3-70B-Instruct, а також Llama 4 Scout-17B-16E, через Together AI.

Інші учасники були OLMo 2 13B, Phi-4 і Command-A, всі доступні локально через Ollama або Cohere API; і Deepseek-R1, доступний через Amazon Bedrock.

Для двох ‘мислячих’ моделей (o3 і R1) ліміт токенів був підвищений до 10 000, щоб розмістити довші ланцюги мислення:

Середні оцінки продуктивності для кожної моделі за шість завдань: код, база даних, дії, дані-у-текст, математика та резюме. Результати показані для трьох типів симуляції: повної, конкат та шардової. Моделі впорядковані за їхнім середнім оцінками у повному режимі. Затінювання відображає ступінь зниження продуктивності з повного режиму, з двома останніми колонками, які повідомляють про середнє зниження для конкат та шардових відносно повної.

Відносно цих результатів автори заявляють^†:

‘На високому рівні кожна модель бачить зниження продуктивності на кожному завданні, коли порівнюються повна та шардова продуктивність, з середнім зниженням на 39%. Ми називаємо це явище Загублені у розмові: моделі, які досягають видатної (90%+) продуктивності у лабораторному режимі повністю визначеної одноповоротної розмови, борються на тих самих завданнях у більш реальному режимі, коли розмова недовизначена та багаторозмовна.’

Конкат оцінки у середньому становили 95 відсотків повної, вказуючи на те, що зниження продуктивності у шардовому режимі не можна пояснити втратою інформації. Менші моделі, такі як Llama3.1-8B-Instruct, OLMo-2-13B і Claude 3 Haiku, показали більш виражене зниження під час конкат, що свідчить про те, що менші моделі загалом менш стійкі до перефразування, ніж більші.

Автори відзначають^†:

‘Дивно, що більш продуктивні моделі (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) однаково загублені в розмові порівняно з меншими моделями (Llama3.1-8B-Instruct, Phi-4), з середнім зниженням на 30-40%. Це частково пояснюється визначеннями метрик. Оскільки менші моделі досягають нижчих абсолютних оцінок у Повному, вони мають менше можливостей для зниження, ніж кращі моделі.

‘У короткому, незалежно від того, наскільки сильна одноповоротна продуктивність LLM, ми спостерігаємо великі зниження продуктивності у багаторозмовному режимі.’

Початковий тест показує, що деякі моделі витримували краще у певних завданнях: Command-A на діях, Claude 3.7 Sonnet і GPT-4.1 на коді; і Gemini 2.5 Pro на даних-у-текст, вказуючи на те, що багаторозмовна здатність варіюється за доменом. Моделі мислення, такі як o3 і Deepseek-R1, не показали загального покращення, можливо, через те, що їхні довші відповіді вводили більше припущень, які мали тенденцію плутати розмову.

Надійність

Відношення між здатністю та надійністю, ясне у одноповоротних симуляціях, здавалося, розпадалося під багаторозмовними умовами. Хоча здатність знизилася лише помірно, ненадійність подвоїлася у середньому. Моделі, які були стабільними у повних підказках, такі як GPT-4.1 і Gemini 2.5 Pro, стали такими самими непередбачуваними, як і слабші моделі, такі як Llama3.1-8B-Instruct або OLMo-2-13B, як тільки інструкція була фрагментована.

Огляд здатності та ненадійності, показаний у коробковому графіку (а), за яким слідують результати надійності з експериментів з 15 моделями (б), і результати з тесту поступового шардування, де інструкції були розділені на одну до восьми шард (в).

Відповіді моделі часто варіювалися на 50 пунктів на одному й тому ж завданні, навіть коли нічого нового не було додано, вказуючи на те, що зниження продуктивності не було спричинене браком навичок, а тим, що модель ставала дедалі більш нестабільною протягом поворотів.

Папера заявляє^†:

‘[Хоча] кращі моделі мають трохи вищу багаторозмовну здатність, всі моделі мають схожі рівні ненадійності. Інакше кажучи, у багаторозмовному, недовизначеному режимі всі моделі, які ми тестируємо, демонструють дуже високу ненадійність, з продуктивністю, що погіршується на 50 пунктів у середньому між найкращим і найгіршим симульованим запуском для фіксованої інструкції.’

Для перевірки того, чи пов’язане зниження продуктивності з кількістю поворотів, автори провели експеримент поступового шардування, розділивши кожну інструкцію на одну до восьми шард (див. правий стовпчик у зображенні вище).

Як тільки кількість шард збільшувалася, ненадійність зростала поступово, підтверджуючи, що навіть незначне збільшення кількості поворотів робило моделі більш нестабільними. Здатність залишилася переважно незмінною, підкріплюючи той факт, що проблема лежить у консистентності, а не у можливостях.

Контроль температури

Відділений набір експериментів перевірив, чи є ненадійність просто побічним продуктом випадковості. Для цього автори варіювали налаштування температури як для асистента, так і для симулятора користувача через три значення: 1,0, 0,5 і 0,0.

У одноповоротних форматах, таких як повна і конкат, зниження температури асистента значно покращило надійність, скорочуючи варіацію до 80 відсотків; однак у шардовому режимі таке втручання мало мало ефекту:

Оцінки ненадійності для різних комбінацій температури асистента та користувача через повні, конкат та шардові режими, з нижчими значеннями, які вказують на більшу консистентність відповідей.

Навіть коли температура як асистента, так і користувача була встановлена на нуль, ненадійність залишилася високою, з GPT-4o, який показував варіацію близько 30 відсотків, вказуючи на те, що нестабільність, спостережувана у багаторозмовних розмовах, не є просто стохастичним шумом, а структурною слабкістю у тому, як моделі обробляють фрагментований вхід.

Імплікації

Автори пишуть про наслідки своїх висновків у нечуваному довжанні наприкінці статті, стверджуючи, що сильна одноповоротна продуктивність не гарантує багаторозмовну надійність, і застерігають проти надмірної залежності від повністю визначених бенчмарків при оцінці реальної готовності (оскільки такі бенчмарки маскують нестабільність у більш природних, фрагментованих взаємодіях).

Вони також пропонують, що ненадійність не є просто артефактом вибірки, а фундаментальною обмеженням у тому, як поточні моделі обробляють еволюційний вхід, і вони стверджують, що це викликає занепокоєння щодо агентських структур, які залежать від тривалого мислення протягом поворотів.

Нарешті, вони стверджують, що багаторозмовна здатність повинна бути основною можливістю LLM, а не тим, що передано зовнішнім системам.

Автори відзначають, що їхні результати, ймовірно, занижують справжній масштаб проблеми, і звертають увагу на ідеальні умови тесту: симулятор користувача у їхньому режимі мав повний доступ до інструкції та міг розкривати шарди в оптимальному порядку, що давало асистенту нереалістично сприятливий контекст (у реальному використанні користувачі часто надають фрагментовані або двозначні підказки без знання того, що модель повинна чути далі).

Крім того, асистент оцінювався одразу після кожного повороту, до того, як повна розмова розгорталася, що запобігало пізнішому плутанню чи самопротиріччю, яке інакше погіршило б продуктивність. Ці вибори, хоча й необхідні для експериментального контролю, означають, що розриви надійності, спостережувані на практиці, ймовірно, будуть ще більшими, ніж ті, що повідомляються.

Вони роблять висновок:

‘[Ми] вважаємо, що проведені симуляції представляють доброзичливий тестовий майданчик для багаторозмовних можливостей LLM. Через надмірно спрощені умови симуляції ми вважаємо, що спостережуване зниження у експериментах, ймовірно, є заниженою оцінкою ненадійності LLM, і того, як часто LLM загублюються у розмові в реальних умовах.’

Висновок

Хто б не провів значну кількість часу з LLM, ймовірно, розпізнає проблеми, сформульовані тут, з практичного досвіду; і більшість з нас, я уявляю, інтуїтивно відмовилися від «загублених» розмов LLM за новими, сподіваючись, що LLM «перезапустить» і перестане одержимуватися матеріалом, який виник у довгій, звивистій і дедалі більш розлютуючій розмові.

Цікаво відзначити, що кидання більшого контексту на проблему може не обов’язково її вирішити; і справді, спостерігати, що стаття піднімає більше питань, ніж дає відповідей (окрім способів обійти проблему).

* Збиваючи з пантелику, це не пов’язано з конвенціональним значенням ‘шардування’ у AI.

† Власні виділені авторами.

Перша публікація понеділка, 12 травня 2025