# Почему LLM теряют нить по мере удлинения диалога? При работе с диалоговым ИИ, например ChatGPT, можно заметить, что модель, поначалу точно следовавшая указаниям, начинает отклоняться от задачи по мере добавления новых условий. Она повторяет уже исправленные ошибки или сохраняет первоначальные предположения. Хотя вся переписка доступна, некоторые важные условия словно теряются. Source: https://www.iplexlaw.co.kr/ru/blog/1530608 ГЛАВНАЯ / Новости и аналитика Новости и аналитика Почему LLM теряют нить по мере удлинения диалога? При работе с диалоговым ИИ, например ChatGPT, можно заметить, что модель, поначалу точно следовавшая указаниям, начинает отклоняться от задачи по мере добавления новых условий. Она повторяет уже исправленные ошибки или сохраняет первоначальные предположения. Хотя вся переписка доступна, некоторые важные условия словно теряются. ИИ и программное обеспечение Опубликовано: 2026.09.01 IPLEX Время чтения: 13 мин. https://arxiv.org/pdf/2505.06120 Автор: Ким Ёндок, патентный поверенный IPLEX IP Law Firm Есть странные моменты при использовании разговорного ИИ, например, ChatGPT. Модель, которая первоначально следовала довольно точно, идет в неправильном направлении, поскольку условия добавляются один за другим. Иногда вы снова совершаете ошибки в том, что вы только что исправили, а иногда придерживаетесь предположений, которые вы сделали в начале. Несмотря на то, что все записи разговоров остаются, они ведут себя так, как будто пропустили несколько важных терминов. Простое объяснение этого явления как «Я не могу вспомнить, потому что контекст длинный» упускает смысл. «LLMs Get Lost in Multi-Turn Conversation», опубликованная исследователями из Microsoft Research и Salesforce Research, сравнивалась, когда одна и та же задача была проинструктирована полностью сразу и когда инструкции были разделены на несколько поворотов разговора. Изменился не объем информации, а способ ее раскрытия. Результаты были довольно ясными. Средняя производительность снизилась с примерно 90 пунктов в одиночном развороте до примерно 65 пунктов в многооборотном. В статье это суммируется как среднее относительное снижение производительности на 39%. С другой стороны, способность, которая указывает на потенциал модели, когда она хорошо решена, снизилась в среднем всего на 16%, а надежность, которая показывает, насколько нестабильны результаты, когда повторяется та же проблема, увеличилась в среднем на 112%. Другими словами, вместо того, чтобы сказать, что «модель внезапно стала глупой», точнее сказать, что «модель больше не могла надежно использовать ту же способность». 1. Проблема не в «памяти», а в том, как справляться с неполными запросами. В действительности, пользователи не вводят свои требования полностью с самого начала. Начните со слов «Написать отчет», затем укажите длину в следующем сообщении, затем попросите голоса и добавьте аудиторию и цель в конце. Тем не менее, многие существующие оценки LLM оценивают модель со всеми необходимыми условиями, включенными в первую подсказку. Эта статья изолировала этот пробел в экспериментах. Первое условие, отличающееся исследователями, полностью определено. Поскольку цель использования, ограничения, входные данные и выходной формат включены в первое сообщение, модель может сразу же дать окончательный ответ. И наоборот, при заданном многообороте в первом сообщении дается только основная цель, а в последующих поворотах последовательно выявляются подробные условия. В это время модель должна оставлять пустые или задавать вопросы о частях, которые еще не известны, но на самом деле она часто угадывала пустые места и завершала ответ слишком рано. Важно то, что сам по себе формат мультиповорота не всегда плох. В задачах, где результаты каждого поворота могут быть связаны независимо, например, в переводе, падение производительности было относительно небольшим. С другой стороны, проблемы возникли значительно в задачах, где весь существующий код, SQL, формула вычисления и резюме должны были перередактироваться каждый раз, когда вводилось новое условие. В конце концов, сложность заключалась в том, следует ли реинтегрировать весь предыдущий диалог в соответствии с новыми условиями. 2. Исследователи разбили разговор на мелкие кусочки и заставили их снова решить ту же проблему. Исследователи разделили полную инструкцию на атомные части информации, а затем поместили цель высокого уровня в первую часть и подробные условия в оставшиеся части. Пользовательский симулятор выдал максимум одно условие, которое еще не было выявлено на каждом повороте, и оцениваемая модель ответила, как если бы разговаривала с обычным пользователем, не зная структуры эксперимента. Этот метод называется Sharded Conversation. Ответы модели были разделены на вопросы, дебаты, отклонения, гипотетические кандидаты и фактические попытки ответа. Когда модель попыталась ответить, она была оценена с помощью оценщика, соответствующего задаче, включая выполнение кода, выполнение SQL, точное соответствие, BLEU и сводные оценки с цитатами. Если ответ был неверным, выявлялось следующее условие, а если давался правильный ответ или не выявлялись дальнейшие условия, разговор заканчивался. Условия сравнения также были тщательно разработаны. FULL является базовым условием для предоставления первоначальной полной директивы в первом повороте. SHARDED раскрывает условия в несколько поворотов. CONCAT объединяет предложения, разделенные в SHARDED, в один оборот и проверяет, связано ли это с простым повторным выражением предложения или потерей информации. RECAP перестраивает все условия в конце разговора SHARDED, и SNOWBALL в совокупности повторяет условия до сих пор каждый поворот. Сравнивая эти пять условий, мы можем в какой-то степени отделить «акт обмена информацией» и «неспособность интегрироваться в течение нескольких оборотов». 3. Это же явление повторялось с 15 моделями и 200 000 разговоров. Объем эксперимента не ограничивается одной или двумя моделями. Исследователи использовали шесть типов задач, включая генерацию кода, задачи базы данных, которые преобразуют естественный язык в SQL, генерацию вызовов API, элементарную математику, задачи, которые объясняют таблицы в предложениях, и задачи, которые цитируют и обобщают несколько документов. Для каждой задачи было создано от 90 до 120 раздельных инструкций, что составило в общей сложности 600 инструкций. Цель сравнения включала 15 репрезентативных моделей в то время, включая GPT-4.1, GPT-4o, o3, Gemini 2.5 Pro и Flash, Claude 3.7 Sonnet, DeepSeek-R1, серию Llama, Phi-4, OLMo 2 и Command-A. Повторяя несколько раз комбинацию модели, директивы и условий разговора, общее количество разговоров превысило 200 000. Причина, по которой одна и та же проблема повторяется, также важна. Поскольку LLM генерирует предложения вероятностно, трудно судить о стабильности только с одним успехом или неудачей. Запустив одну и ту же проблему несколько раз, вы можете увидеть не только среднюю производительность, но и разрыв между тем, когда она работала хорошо и когда она потерпела неудачу. Ключевой момент этой статьи заключается в том, что она представляет «разрыв» в качестве отдельной проблемы надежности. 4. Число, на которое следует обратить больше внимания, чем падение на 39%, — это «рост на 112%». В статье рассматривались не только средние показатели производительности, но и способности и ненадежность отдельно. Способность относится к 10-процентному уровню производительности при повторном выполнении. Проще говоря, он показывает, как далеко может зайти модель, когда она решает проблему в хороших условиях. Надежность — это разница между показателями топ 10% и нижних 10% по одной и той же инструкции. Чем больше это значение, тем больше результаты будут варьироваться в зависимости от пути разговора, даже для одного и того же запроса. Все модели показали более низкую производительность в SHARDED, чем FULL во всех задачах. Средняя производительность упала на 25 пунктов с примерно 90 до 65, что в среднем на 39% в относительном выражении. Тем не менее, способности снизились в среднем только на 16%. С другой стороны, надежность выросла в среднем на 112%, более чем в два раза. Даже в рамках одной инструкции была средняя разница примерно в 50 баллов между лучшим и худшим исполнением. Результаты КОНКАТ укрепляют эту интерпретацию. Когда разделенные условия были объединены снова, производительность сохранялась на уровне около 95,1% от полной. Другими словами, трудно сказать, что производительность ухудшилась, потому что информация была потеряна или выражения были изменены, когда предложения были разбиты на более мелкие части. В ситуации, когда одна и та же информация должна была быть получена в течение нескольких оборотов, процесс интеграции модели разговорного состояния сам по себе был проблемой. Таким образом, сообщение этой статьи не «Даже последний LLM не может делать многообороты». Более точным выражением является «Вы можете сделать это хорошо, но вы не можете надежно воспроизвести эту способность каждый раз». С точки зрения продукта важно смотреть на то, как результаты колеблются, когда одни и те же требования представлены в разных порядках и путях разговора, а не на самом высоком эталонном балле. 5. Почему модели теряются в разговорах? Выполните свой ответ слишком рано В заданиях по коду и математике, когда первая попытка ответа происходила в течение первых 20% разговора, средний балл составлял 30,9. И наоборот, если вы ждали до последних 20%, средний балл составлял 64,4. Если модель сначала создает ответ, даже если необходимые условия еще не были полностью раскрыты, существует большая вероятность того, что ответ будет содержать предположения, которые пользователь не слышал. В ранних предпосылках В LLM наблюдается тенденция к завершению ответов путем заполнения правдоподобных значений из контекста, а не оставления неизвестных частей как есть. Проблема в том, что сзади появляются новые условия. Модели часто изменяют только часть структуры, которую они уже создали, а не отбрасывают и пересчитывают весь ответ. Первоначальная некорректная предпосылка становится основой для разговора, и последующие исправления продолжают строиться на ней. Чем больше вы редактируете, тем больше становится ответ. Окончательный ответ был на 20-300% длиннее, чем полный или полный ответ. Если посмотреть только на правильные ответы, ответы на код в среднем на 27% длиннее, а ответы на SQL в среднем на 14% длиннее. Исследователи называют этот ответ «плохим». Это связано с тем, что модель реагирует, добавляя исключения и исправления, а не удаляя предыдущий ответ и вычисляя заново. Средний поворот становится слабее, а первый и последний повороты сильнее. В задаче длинного резюме восьмого поворота приводилось 20% документов, опубликованных в последнем повороте, в то время как документы, опубликованные во втором и третьем поворотах, приводили только 8% каждый. Это явление, при котором информация в начале и конце разговора отражается относительно сильно, а условия, вводимые посередине, ослабевают. Исследователи назвали это «потерей в центре». Длинные, дружелюбные ответы могут стать шумом. В пяти из шести заданий группа с самым коротким ответом выполняла от 10 до 50 процентов лучше, чем группа с самым длинным ответом. Чем дольше описание создается в ранних поворотах, тем больше предположений и обходных путей пользователь может оставить незаявленными, которые становятся частью нового ввода в более поздних поворотах. В ситуации с несколькими поворотами способность определять «то, что мы еще не знаем» и задавать короткие вопросы подтверждения может быть более важной, чем способность выдавать длинные ответы в начале. 6. Более длинного контекста и большего количества выводов было недостаточно. Самое простое средство — повторить разговор снова. Если все условия перегруппированы в конце, как RECAP, производительность улучшается. Однако в реальных сервисах сложно узнать, когда пользователь заявил последнее условие. Как и SNOWBALL, повторение предыдущих условий на каждом повороте смягчило примерно 15-20% ухудшения производительности, но подсказка быстро стала длиннее и не восстановилась до полного уровня. Методы снижения случайности генерации также были ограничены. Понижение температуры значительно снижало надежность в одинарных оборотах, но улучшение было небольшим в многооборотных. Даже при нулевой температуре оставалось примерно 30% ненадежности. В разговорах небольшие различия в одну очередь изменяют сам вход в следующую очередь, поэтому устранить кумулятивные ошибки просто за счет уменьшения случайности одного поколения сложно. Модели, использующие более производные вычисления, также не могут быть решены автоматически. Выводные модели, такие как o3 и DeepSeek-R1, также показали ухудшение производительности с несколькими поворотами, аналогичное невыводным моделям. Исследователи отмечают, что модели вывода, как правило, дают более длинные ответы в среднем. Чем длиннее ответ, тем больше предположений делает модель о себе, и тем сложнее может быть провести различие между потребностями пользователя и оценками модели в следующем повороте. 7. Разговорные продукты ИИ должны быть разработаны для «управления государством», а не для «генерации ответов». Если вы читаете эти результаты с точки зрения дизайна продукта, направление становится довольно ясным. Во-первых, нам нужны ворота окончательного ответа, которые не дают полного ответа до тех пор, пока не будут выполнены предпосылки. Это означает, что вместо простой подсказки «если вы не знаете, спросите», необходима логика управления, чтобы определить, разрешено ли окончательное создание в текущем состоянии. Во-вторых, важно не смешивать пользовательские условия и модельные предположения в одной и той же записи разговора. Требования, подтвержденные пользователем, элементы, еще не подтвержденные, значения, временно оцененные моделью, и условия, впоследствии снятые, должны храниться отдельно в структурированном состоянии. Таким образом, когда появляются новые условия, вы можете решить, что оставить и что отбросить. В-третьих, необходима процедура проверки того, противоречит ли новая информация существующим предположениям, и, если да, то признания недействительными соответствующих промежуточных результатов и составления ответов. Простое указание модели «Модифицировать» может создать «Блоат ответа», который добавляет к существующей структуре, сохраняя ее. При необходимости более надежно начать новую ветвь вывода, принимая только проверенные условия, а не изменяя предыдущий ответ. В-четвертых, вместо того, чтобы обобщать весь разговор в определенных моментах, может быть полезно реорганизовать «только проверенные пользовательские условия» в полностью явные директивы. Использование таких сигналов, как количество витков, количество токенов, количество конфликтов состояний и количество модификаций ответов для определения сроков повторного использования или перезапуска, также является точкой проектирования на уровне продукта. Наконец, оценка не должна заканчиваться только средним процентом правильных ответов. Те же самые требования должны выполняться неоднократно в различных последовательностях раскрытия информации для измерения дисперсии производительности, скорости вывода допущения, скорости восстановления после неправильного ответа и самого худшего разрыва. Вопрос надежности, который рассматривается в этом документе, в конечном итоге не является вопросом «Можете ли вы сделать это хорошо один раз?», а «Можете ли вы сделать его надежно несколькими способами?» 8. В патентной практике ключевым моментом является «структура управления диалогом». Вместо того, чтобы предлагать новую архитектуру базовой модели, этот документ ближе к исследованию, в котором представлены рамки оценки и показатели надежности, которые воспроизводят и количественно оценивают уязвимости разговорного ИИ. Поэтому при изучении технической дифференциации на уровне продукта или услуги конкретная структура управления состоянием и процедуры контроля, которые реализуют эту цель, более важны, чем абстрактная цель «LLM обрабатывает многооборотный колодец». Например, обнаружение неопределенного состояния, которое определяет, может ли окончательный ответ быть создан только с текущим входом, реестр требований, который хранит подтвержденные условия, неподтвержденные условия, модельные предположения и условия вывода отдельно, признание недействительным предположения, которое обнаруживает конфликты между новыми утверждениями и существующими предположениями и выборочно отбрасывает промежуточные выходы, спусковой механизм резюме, который реорганизует состояние разговора в полностью явную подсказку при определенных условиях, разветвление разговора, которое начинает новый вывод, наследуя только проверенные условия, и система оценки надежности, которая измеряет скорость восстановления и волатильность, повторяя различные последовательности раскрытия информации и т. Д. Его можно обозначить как техническую конфигурацию. Однако дифференциация непростая с абстрактными идеями, такими как «обобщение предыдущих разговоров», «задавать вопросы при необходимости» и «запоминать разговоры». Становится легче объяснить технические особенности и эффекты, указав, какая информация хранится в какой структуре данных, какие сигналы используются для оценки неопределенных состояний, с какими единицами связаны и недействительны предположения, когда окончательный вызов модели заблокирован или разрешен, и как частота ошибок, скорость восстановления, использование токенов и задержка варьируются в результате. Исследование опубликовано 9 мая 2025 года. При последующей оценке новизны и изобретательского уровня будет недостаточно ссылаться лишь на Sharded Simulation, сравнение FULL, CONCAT и SHARDED, подходы RECAP и SNOWBALL или определения способности и надёжности. Для патентования могут иметь значение дополнительные технические решения: управление состоянием конкретного продукта, проверка конфликтов, маршрутизация между моделями, экономия ресурсов и механизмы безопасности. 9. Пользователи также могут уменьшить вероятность неудачи, немного изменив свой стиль разговора. Есть уроки, которые можно применить и к обычным пользователям. Это не означает, что все условия должны быть написаны идеально в первом запросе. Скорее, если условия менее определены, лучше указать «Если информации недостаточно, задайте сначала вопрос подтверждения», чтобы модель не заполнила его произвольно. При добавлении условий целесообразно четко указать, какие из существующих условий сохранить, а какие изменить или удалить. Если разговор длинный, можно спросить один раз посередине: «Пожалуйста, переставьте только те условия, которые я подтвердил до сих пор, и укажите отдельно то, что вы оценили». Если модель уже кажется глубоко закорененной в неправильную структуру, может быть более стабильным вставить только подтвержденные условия в новый диалог сразу и начать все сначала, а не непрерывно модифицировать его. Для важных задач реалистичный метод проверки заключается в том, чтобы снова запустить одну и ту же явную подсказку и сравнить результаты. Заключение. Хороший разговорный ИИ ближе к «системе, которая возвращается с неправильного пути», а не к «модели, которая делает все правильно с самого начала». В этой статье показано, что модели с высокими однооборотными эталонами не обязательно обеспечивают одинаковое качество в реальных интерактивных услугах. Когда требования выпускаются в течение нескольких оборотов, модель может колебаться, создавая ответы слишком рано, сохраняя свои предположения в качестве фактов, слабо отражая условия в середине поворотов и продолжая добавлять к существующим ответам. Таким образом, конкурентоспособность следующего поколения разговорного ИИ, скорее всего, не будет определяться только большим количеством знаний или более длинными ответами. Способность ждать, когда информация недостаточна, способность различать потребности пользователей и оценки моделей, способность отменять существующие суждения, когда появляются новые условия, и способность начинать все сначала только с проверенного состояния, когда идет неправильный путь, являются основой надежности продукта. Прочитать корейский оригинал Материал отражает ситуацию на дату публикации. Обратитесь в IPLEX, чтобы обсудить обстоятельства вашего дела. Обсудить этот вопрос ↗ Все статьи ОБРАТИТЕСЬ В IPLEX Обсудите с нами вопросы интеллектуальной собственности Мы рассматриваем ваши технологические и бизнес-потребности вместе. ↗ Связаться с нами Новее Передача патентов, товарных знаков и прав на промышленный образец ↗ Ранее Колонка: патент Google на генеративное рассуждение ИИ — обучение процессу мышления ↗ Материалы по теме ИИ и программное обеспечение 2026.10.01 FiX: избирательное забывание признаков в softmax-внимании Патентный поверенный Ким Ёндок рассматривает векторные затворы FiX, устойчивость вычислений и страничный кэш, отделяя результаты экспериментов от открытых вопросов. ↗ Читать статью ИИ и программное обеспечение 2026.09.30 MHAR: выбор информации из предыдущих слоёв по подпространствам признаков Корейский патентный поверенный Ким Ёндок разбирает Multi-Head Attention Residuals: маршрутизацию по глубине, результаты экспериментов, затраты реализации и технические эффекты. ↗ Читать статью ИИ и программное обеспечение 2026.09.28 Колонка в AI Times: как ИИ учится работать с компьютером — анализ патента на обучение агентов В новой колонке для AI Times управляющий партнёр IPLEX Ким Ёндок рассматривает Claude Computer Use и обучение ИИ-агентов на примере патента США № 12 585 862. ↗ Читать статью - https://www.iplexlaw.co.kr/ru - https://www.iplexlaw.co.kr/ru/blog/category/ai - https://arxiv.org/pdf/2505.06120 - https://www.iplexlaw.co.kr/forum/view/1530608 - https://www.iplexlaw.co.kr/ru/contact - https://www.iplexlaw.co.kr/ru/blog - https://www.iplexlaw.co.kr/ru/contact - https://www.iplexlaw.co.kr/ru/blog/1531646 - https://www.iplexlaw.co.kr/ru/blog/1530376 - https://www.iplexlaw.co.kr/ru/blog/fix-fine-grained-forgetting-attention - https://www.iplexlaw.co.kr/ru/blog/fix-fine-grained-forgetting-attention - https://www.iplexlaw.co.kr/ru/blog/mhar-multi-head-attention-residuals - https://www.iplexlaw.co.kr/ru/blog/mhar-multi-head-attention-residuals - https://www.iplexlaw.co.kr/ru/blog/claude-computer-use-agent-patent - https://www.iplexlaw.co.kr/ru/blog/claude-computer-use-agent-patent