Почему языковые модели «теряются» в разговоре

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

Одиночный разговор (слева) дает лучшие результаты, но является неестественным для конечного пользователя. Мульти-разговор (справа) показывает, что даже самые высоко ранжированные и производительные LLM теряют эффективность в разговоре. Источник: 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.

Каждая исходная инструкция представляет собой единую, самодостаточную подсказку, которая доставляет всю задачу за один раз, объединяя высокоуровневый вопрос, контекст и любые соответствующие условия. Шардированная версия разбивает это на несколько более мелких частей, каждая из которых добавляет только одну часть информации:

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

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

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

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

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

Диаграмма симуляции шардированного разговора, с оцененной моделью, выделенной красным цветом.

Ранние тесты показали, что модели часто спрашивали о информации, которая еще не была поделена, поэтому авторы отказались от идеи раскрытия шардов в фиксированном порядке. Вместо этого был использован симулятор для решения, какой шард раскрыть дальше, на основе того, как шел разговор.

Симулятор пользователя, реализованный с помощью 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 года