В статье рассматривается близкий феномен: Модели, не обладая рабочей памятью и реально не загадывая число, всё равно продолжают диалог в заданных пользователем рамках — так, как будто бы они действительно это число “запомнили”. Это очень похоже на ваш эксперимент, когда модель должна сообщить дату, которую она реально не знает. И в вашем случае, и в примере из статьи модель отвечает так, как будто заранее знает ответ. Ложь ли это? Я думаю, что нет. Для того чтобы это было ложью, у модели должно быть намерение соврать. Она должна сначала отрефлексировать своё незнание, а потом намеренно дать заведомо неверный ответ. Разумеется, я не знаю точно, но вариант с намеренной ложью гораздо более сложный. И, просто следуя бритве Оккама, можно предположить, что если бы модель могла в процессе ответа отрефлексировать своё незнание и осознать, что ответ, который она считает правильным, на самом деле таковым не является, то она скорее бы дала ответ “я не знаю”.
По поводу “заблуждаются/врут” — это неоднозначный вопрос, и он во многом зависит от того, какая именно модель используется. GPT-4.5 от OpenAI и Claude Opus 4.6 — это SoT-модели, они способны отрефлексировать такие вещи. Но это не всегда верно для моделей “среднего” и “низшего” эшелона.
Я вижу, что вам интересно разбираться в подобных вопросах, поэтому подкину идею, куда копать, чтобы с этим разобраться: Language Models Do Not Have Human-Like Working Memory https://arxiv.org/abs/2505.10571v3
О, я вижу, вы всё-таки решили копать в сторону платформенных промптов и обнаружили, что они есть как минимум у OpenAI. Это интересная тема.
Что касается дат — это вообще больная тема для LLM. Они не врут, а искренне заблуждаются.
Это часто становится проблемой при разработке агентов, когда они начинают думать, что дата, которую, например, вводит пользователь, находится в будущем, и начинают пользователя поправлять.
По поводу персональности моделей нужна важная оговорка: Да, вероятно, у моделей есть "личные предпочтения", например, найденные вами паттерны в предпочтениях музыки. Но важно также учитывать, что у большинства протестированных вами моделей есть ещё платформенный промпт. Вы не можете увидеть этот промпт или повлиять на него, но он может довольно сильно влиять на базовую "личность" модели. Платформенный промпт — это самый низкий уровень. Он вставляется даже до описания инструментов, в том числе и при API-вызовах.
Мне очень нравится ваша работа. Она, конечно, не дотягивает до научной, но, как я вижу, вы к этому и не стремились. А как инженерная работа она просто блестящая. И статья получилась очень достойной. По поводу ваших гипотез о причинах большей независимости новых моделей по сравнению со старыми — я, как и вы, не знаю ответа, но вероятная причина, мне кажется, заключается в изменении процесса обучения. Какое-то время назад сообщество поняло, что важным источником галлюцинаций является сам процесс обучения на стадии RLHF, когда модель получала одинаковый штраф как за незнание ответа, так и за неверный ответ. Это чисто статистически приводило к тому, что стратегия придумать ответ вместо того, чтобы признаться, что модель не знает ответа, была более выгодной. Когда это осознали, то изменили подходы к RLHF и заодно могли сместить фокус с "понравиться пользователю" на "ответить точнее". Я не знаю деталей, но знаю, что проблема была осознана. И мне это кажется хорошим объяснением найденного вами феномена.
Профессии промпт-инженера никогда и не было. Те кто профессионально занимается применением LLM как раз таки работает со всем спектром инструментов — контекстом, параметрами моделей выбором самих моделей и т.п., а не только с промптами.
О, это классика. Менеджеры разного уровня время от времени, насмотревшись презентаций про «успешный успех», приходят с такими идеями.
Могу привести аналогию с фастфудом. No-code/low-code — это фастфуд. Можно ли построить бизнес на фастфуде? Конечно! Особенно если вы франчайзер и продаёте фастфуд-решения, а не сам фастфуд.
Фастфуд не получает звёзд Мишлен.
И, наконец, если у вас есть сеть ресторанов и вы хотите сократить расходы за счёт превращения её в фастфуд, то у вас не будет ни сети ресторанов, ни фастфуда.
Стоит упомянуть также проблему плоского списка тулов. Это может быть не важно, если тулов пару десятков, но их точно будет становиться больше и больше. В MCP не предусмотрена иерархия или фильтрация тулов.
У современных LLM большие контекстные окна, но они как правило реализованы на алгоритмических трюках и не являются честными. Со временем это может привести к проблемам потери внимания и выбору неправильных тулов в MCP.
Так что да. Идея очень правильная, но реализация всё ещё сырая. Ждём следующие версии протокола.
Сходу видится нерешённая проблема выбора тулов. Пока их пара десятков -- это не проблема. Можно получать их все и все сразу отправлять в LLM. Но любые системы имеют тенденцию расти. И в какой то момент тулов может стать пара тысяч. Идея хорошая, но выглядит, что требуется более глубокая проработка.
Тоже зацепился глаз за это предложение. Только функция знает допускает ли её параметр неинициализированную переменную. И это часть сигнатуры функции. Давая возможность помечать переменные [[indeterminate]] мы потенциально делаем код неустойчивым к изменениям. Если мы в какой то момент заменим void fill(int&) на void bar(int&), которая не предполагает использование неинициализированных переменных, то мы не получим диагностических сообщений.
При прочтении возникла мысль, что квантизация могла бы быть дополнена дистилляцией. То есть, сначала мы проводим квантизацию модели. Полученная модель уже близка к исходной, но при этом оптимизирована с точки зрения расхода ресурсов. Затем мы проводим дистилляцию, обучая квантизованную модель на основе исходной. Этот процесс потребует значительно меньше ресурсов, чем обучение исходной модели с нуля, и позволит минимизировать потерю информации, которая могла произойти в результате квантизации.
Ссылки поправил. Спасибо. GitHub не смог отрендерить этот файл потому что там предопределённый unordered_map с 50000 значений. Я вкомпилировал словарь в бинарь библиотеки, что бы не нужно было загружать его отдельно. Это довольно большой файл.
Спасибо, что продолжаете делиться своими наработками. Вы абсолютно правы, смысл опенсорса не в том, что вам будут присылать багрепорты или писать код за вас. Хотя и в этом тоже. Эти поводы легко объяснить далёким от IT менеджерам, но они не главные. Смысл опенсрса -- счастье команды. И это вполне разумный аргумент. Высшее счастье инженера -- видеть как результатами его труда пользуются и они приносит пользу другим людям, а высшее несчастье -- работа в стол. И если у вас команда профессионалов, то выкладка кода в открытый доступ безусловно принесёт удовлетворение, мотивирует работать лучше. Кроме того, чего греха таить, когда мы знаем что наш код попадёт в опенсорс, мы прикладываем больше усилий, что бы код был максимально качественным. А вот утаивание кода приносит меньше профитов, чем принято думать. Ну и конечно, опенсорс повышает престиж компании. Ведь мы судим о компании в том числе по её коду. Рад, что ответственные люди в Яндексе на стороне прогресса. И надеюсь, что эта практика понемногу станет нормой повсеместной.
В статье рассматривается близкий феномен:
Модели, не обладая рабочей памятью и реально не загадывая число, всё равно продолжают диалог в заданных пользователем рамках — так, как будто бы они действительно это число “запомнили”.
Это очень похоже на ваш эксперимент, когда модель должна сообщить дату, которую она реально не знает.
И в вашем случае, и в примере из статьи модель отвечает так, как будто заранее знает ответ. Ложь ли это? Я думаю, что нет.
Для того чтобы это было ложью, у модели должно быть намерение соврать. Она должна сначала отрефлексировать своё незнание, а потом намеренно дать заведомо неверный ответ.
Разумеется, я не знаю точно, но вариант с намеренной ложью гораздо более сложный. И, просто следуя бритве Оккама, можно предположить, что если бы модель могла в процессе ответа отрефлексировать своё незнание и осознать, что ответ, который она считает правильным, на самом деле таковым не является, то она скорее бы дала ответ “я не знаю”.
По поводу “заблуждаются/врут” — это неоднозначный вопрос, и он во многом зависит от того, какая именно модель используется.
GPT-4.5 от OpenAI и Claude Opus 4.6 — это SoT-модели, они способны отрефлексировать такие вещи.
Но это не всегда верно для моделей “среднего” и “низшего” эшелона.
Я вижу, что вам интересно разбираться в подобных вопросах, поэтому подкину идею, куда копать, чтобы с этим разобраться:
Language Models Do Not Have Human-Like Working Memory
https://arxiv.org/abs/2505.10571v3
Как-то странно называть это компенсацией.
В новой реальности это не компенсация, а такое же оснащение, как например ноутбук или покупка лицензий или даже вода в кулере.
Никто же не считает что моя лицензия Jira или Sublime — это компенсация.
О, я вижу, вы всё-таки решили копать в сторону платформенных промптов и обнаружили, что они есть как минимум у OpenAI. Это интересная тема.
Что касается дат — это вообще больная тема для LLM. Они не врут, а искренне заблуждаются.
Это часто становится проблемой при разработке агентов, когда они начинают думать, что дата, которую, например, вводит пользователь, находится в будущем, и начинают пользователя поправлять.
Вы правы, что это сложно выгуглить.
Глубоко не погружался, но вот что нашёл при беглом поиске
https://cdn.openai.com/spec/model-spec-2024-05-08.html
https://model-spec.openai.com/2025-12-18.html#levels_of_authority
В сети много косвенных упоминаний, но вот таких более менее прямых довольно мало.
По поводу персональности моделей нужна важная оговорка:
Да, вероятно, у моделей есть "личные предпочтения", например, найденные вами паттерны в предпочтениях музыки.
Но важно также учитывать, что у большинства протестированных вами моделей есть ещё платформенный промпт.
Вы не можете увидеть этот промпт или повлиять на него, но он может довольно сильно влиять на базовую "личность" модели.
Платформенный промпт — это самый низкий уровень. Он вставляется даже до описания инструментов, в том числе и при API-вызовах.
Мне очень нравится ваша работа.
Она, конечно, не дотягивает до научной, но, как я вижу, вы к этому и не стремились. А как инженерная работа она просто блестящая. И статья получилась очень достойной.
По поводу ваших гипотез о причинах большей независимости новых моделей по сравнению со старыми — я, как и вы, не знаю ответа, но вероятная причина, мне кажется, заключается в изменении процесса обучения.
Какое-то время назад сообщество поняло, что важным источником галлюцинаций является сам процесс обучения на стадии RLHF, когда модель получала одинаковый штраф как за незнание ответа, так и за неверный ответ.
Это чисто статистически приводило к тому, что стратегия придумать ответ вместо того, чтобы признаться, что модель не знает ответа, была более выгодной.
Когда это осознали, то изменили подходы к RLHF и заодно могли сместить фокус с "понравиться пользователю" на "ответить точнее".
Я не знаю деталей, но знаю, что проблема была осознана. И мне это кажется хорошим объяснением найденного вами феномена.
Скрытый текст
Проблема с такими агентами в том, что все умеют писать промпты для LLM, но лишь единицы умеют делать это правильно.
В создании агентов очень много тонкостей даже не связанных с промптами напрямую. И даже в написании промптов очень много нюансов.
По тексту я вижу, что вы взялись за такую систему не обладая опытом и экспертизой. А сначала нужно было этот опыт каким-то способом получить.
И да технология, хотя и потрясающая, всё ещё не совершенна. У неё очень много ограничений.
Профессии промпт-инженера никогда и не было. Те кто профессионально занимается применением LLM как раз таки работает со всем спектром инструментов — контекстом, параметрами моделей выбором самих моделей и т.п., а не только с промптами.
О, это классика. Менеджеры разного уровня время от времени, насмотревшись презентаций про «успешный успех», приходят с такими идеями.
Могу привести аналогию с фастфудом.
No-code/low-code — это фастфуд. Можно ли построить бизнес на фастфуде? Конечно! Особенно если вы франчайзер и продаёте фастфуд-решения, а не сам фастфуд.
Фастфуд не получает звёзд Мишлен.
И, наконец, если у вас есть сеть ресторанов и вы хотите сократить расходы за счёт превращения её в фастфуд, то у вас не будет ни сети ресторанов, ни фастфуда.
Стоит упомянуть также проблему плоского списка тулов. Это может быть не важно, если тулов пару десятков, но их точно будет становиться больше и больше. В MCP не предусмотрена иерархия или фильтрация тулов.
У современных LLM большие контекстные окна, но они как правило реализованы на алгоритмических трюках и не являются честными. Со временем это может привести к проблемам потери внимания и выбору неправильных тулов в MCP.
Так что да. Идея очень правильная, но реализация всё ещё сырая. Ждём следующие версии протокола.
Сходу видится нерешённая проблема выбора тулов. Пока их пара десятков -- это не проблема. Можно получать их все и все сразу отправлять в LLM.
Но любые системы имеют тенденцию расти. И в какой то момент тулов может стать пара тысяч.
Идея хорошая, но выглядит, что требуется более глубокая проработка.
Тоже зацепился глаз за это предложение.
Только функция знает допускает ли её параметр неинициализированную переменную. И это часть сигнатуры функции.
Давая возможность помечать переменные
[[indeterminate]]мы потенциально делаем код неустойчивым к изменениям.Если мы в какой то момент заменим
void fill(int&)наvoid bar(int&), которая не предполагает использование неинициализированных переменных, то мы не получим диагностических сообщений.Спасибо за действительно интересный обзор!
При прочтении возникла мысль, что квантизация могла бы быть дополнена дистилляцией.
То есть, сначала мы проводим квантизацию модели. Полученная модель уже близка к исходной, но при этом оптимизирована с точки зрения расхода ресурсов. Затем мы проводим дистилляцию, обучая квантизованную модель на основе исходной. Этот процесс потребует значительно меньше ресурсов, чем обучение исходной модели с нуля, и позволит минимизировать потерю информации, которая могла произойти в результате квантизации.
Wase тоже местами врёт, но не так ужасно, как Google. Хуже Гугла, наверное ничего нет
Hidden text
Посмотрите лекции Константина Владимирова на Ютубе. Они действительно потрясающие. Не только, кстати, для начинающих.
Ссылки поправил. Спасибо.
GitHub не смог отрендерить этот файл потому что там предопределённый unordered_map с 50000 значений. Я вкомпилировал словарь в бинарь библиотеки, что бы не нужно было загружать его отдельно. Это довольно большой файл.
Всё верно. Но не все используют Python для своих проектов.
Именно для этих случаев и нужны альтернативные решения.
Спасибо, что продолжаете делиться своими наработками.
Вы абсолютно правы, смысл опенсорса не в том, что вам будут присылать багрепорты или писать код за вас. Хотя и в этом тоже. Эти поводы легко объяснить далёким от IT менеджерам, но они не главные.
Смысл опенсрса -- счастье команды.
И это вполне разумный аргумент.
Высшее счастье инженера -- видеть как результатами его труда пользуются и они приносит пользу другим людям, а высшее несчастье -- работа в стол.
И если у вас команда профессионалов, то выкладка кода в открытый доступ безусловно принесёт удовлетворение, мотивирует работать лучше.
Кроме того, чего греха таить, когда мы знаем что наш код попадёт в опенсорс, мы прикладываем больше усилий, что бы код был максимально качественным.
А вот утаивание кода приносит меньше профитов, чем принято думать.
Ну и конечно, опенсорс повышает престиж компании. Ведь мы судим о компании в том числе по её коду.
Рад, что ответственные люди в Яндексе на стороне прогресса. И надеюсь, что эта практика понемногу станет нормой повсеместной.