Дисклеймер: Я думаю, что любой человек понимает и чувствует на кончиках пальцев разницу между «заучить» и «набить руку». Каждый это проживал много раз, каждый знает, как это происходит и почему именно так и никак иначе прививаются «навыки и экспертиза». В этой статье я попытаюсь:
1) поднять вопрос о том, почему текущие подходы к обучению LLM заставляют модель «заучивать ответ»
2) объясню со своей точки зрения, где и в каком виде я вижу разницу между «декларативной» и «процедурной» памятью у LLM
3) предложу подход, как пересмотреть и переструктурировать обучение LLM, чтобы натренировать именно «навык» программированию

Сразу отмечу... Что наши разработчики (дрессировщики) LLM в лице Сбера и Яндекса, сейчас вполне могут прислушаться к наблюдениям и взять их на вооружение. Кто первый научит модели программированию «по-новому» может получить существенно более качественную модель для разработки. Модель, которая... а что она будет уметь и чем она будет отличаться, читайте далее в статье. Самая сложная и трудоемкая задача, это подготовить дата-сет, и она вполне автоматизируемая. Кто первый встал, того и тапки.

О какой проблеме я говорю? (знать финальный код ≠ уметь к нему прийти)

Сначала давайте вспомним, что это за виды памяти в нейронауке:

  • Декларативная - это знание «о чём-то». Знание фактов, теорий, концепций. Можно вспомнить и рассказать. Позволяет вспомнить конкретный результат. Когда мы говорим «я выучил томик стихов Пушкина» - мы говорим про декларативную память.

  • Процедурная - это знание «как делать». Навык, который прошит в «мышечной памяти» и позволяет воспроизвести процесс. Зачастую мы можем это воспроизвести, но сложно передать словами «как». Когда мы говорим «я научился писать стихи» - мы говорим про процедурную память.

Уже на этом этапе, скорее всего, большинство вспомнило или поняло о чем я говорю. И большинство от этого большинства сейчас закатило глаза... Как же это применимо в LLM?

Позиционируемся: Я утверждаю, что весь мир сейчас учит LLM программированию в декларативном формате. Точнее заставляет «заучивать результат». LLM может с пол пинка воспроизвести готовый программный модуль на любую функцию, готовый текст любой статьи, пересказать любую книгу и научную работу, воссоздать готовую формулу. И все это проявления «декларативной памяти». (примечание: давайте не будем тут заострять внимание на качестве воспроизведения готового результата и галлюцинациях, статья не про это)

Механика обучения: модель учат в режиме «предсказание следующего токена», и учат их на скармливании просто результирующих файлов с Github. Дают все коды, какие есть сейчас в репозиториях, и прогоняют, пока модель не научится отлично предсказывать «среднее по больнице». И среднее тут получается просто как данность, нельзя заучить все на свете и не прийти к выдаче среднего от всего заученного. С горем пополам люди научились копаться в знаниях этого «библиотекаря». Вот только... как же это мешает кайфовать от вайб-кодинга...

Углубленное отступление: В результате каких мыслей и бесед я удостоверился в этом понимании? Я тут, на досуге, описываю, насколько это возможно, «формулу инсайта» (Aha-moment) и вышел на долгое обсуждение, знает ли модель все то, о чем я ей пишу. И ответ был неоднозначным. Если попросить модель «вспомнить ТРИЗ (Теория решения изобретательских задач)», то модель отлично его процитирует. Но будет ли она его применять в ответе? Точно нет. А сможет ли применить, если об этом явно попросить в запросе? Скорее нет, чем да. У нее нет дата-сета, где человек подробно расписал бы, как шаг за шагом он размышляет, чтобы применить это в процессе предсказания следующего токена.

Когда я закончил этот диалог, я провел параллели с навыком программирования... И словил тот самый Aha-moment, который и послужил импульсом для написания данной статьи.

А не заблуждаюсь ли я в том, что в LLM есть «место» для этих двух видов памяти?

Давайте начнем с того, что вообще есть в LLM. Опишу на простом уровне:

  • Базовые веса модели (слои MLP / Feed-Forward слои). Это матрица весов, в которой закодирована вся библиотека знаний человечества. Они формируются базовым пред-обучением, когда через модель прогоняют готовые тексты и заставляют предсказывать следующий токен.

  • Головы внимания (Attention heads). Это динамические механизмы, которые оперируют матрицами запросов, ключей и значений. Они определяют, как модель связывает токены между собой в контексте конкретной задачи, на что она обращает внимание в тот или иной момент. Хотя они закладываются еще на пред-обучении, их тонкая калибровка происходит на последующих этапах «до-обучение по инструкциям» и «дрессировка с обратной связью».

Именно эти две компоненты LLM и являются местом реализации тех самых двух видов памяти. Думаю, что вы уже сами поняли аналогию:

  • Декларативная память - это базовые веса модели в чистом и незатейливом виде. Модель через эти веса вспоминает все то, что мы попросили ее выучить, и законы юриспруденции, и структуру открытых библиотек python, и письма критиков Ван Гога, и археологические тексты древних народов. Эта компонента позволяет «продолжить текст», пересказать.

  • Процедурная память - это откалиброванные головы внимания. Именно тут хранится умение строить причинно-следственные связи (отдельные виды голов). Именно тут хранится умение строить грамматически корректные предложения (структура подлежащее + сказуемое + прилагательное и т.п.). Именно тут хранится умение извиняться и вообще выдрессированная привычка «быть полезным».

И да... именно тут «должен храниться» навык программирования, а точнее разработки приложений. Сейчас весь мир и ИИ-сообщество научились заставлять LLM заучивать код. Но...

Блин, как же это наивно... Ждать, что тот, кто помнит все стихи мира, умеет их писать... Хотя нет, так нельзя говорить, я сам к этой мысли пришел лишь сегодня. Так что... Давайте считать, что это потенциальное место, в котором у нас есть возможность догнать или обогнать мировое ИИ-сообщество (да, я тут опять обращаюсь к разработчикам Яндекса и Сбера, вы единственные, кто обладает мощностями и финансами, чтобы это сделать)

Критикуешь? Предлагай!

Дальше я буду писать, обозначая свое личное отношение к написанному.
Утверждаю - это ИМХО (истинное мнение хрен оспоришь).
Предполагаю - это мои умозаключения и ожидания.

Во-первых, нужно учить не по результату, а учить на цепочках «исходный код» + «ошибка» + «разбор ошибки» + «патч». И все составляющие тут важны.

Я утверждаю, что учить подобным правкам - единственный способ привить «навыки» аккуратных правок. Тут важно различать «привитый нативный навык» и «выстроенный оркестрацией и промптами процесс». В первом случае модель будет самостоятельно ждать и формулировать разбор ошибки и применять точечный патч, во втором это регулируется промптом и больше схоже с «работой в режиме сверки с регламентом».

Я предполагаю, что можно взять цепочку «исходный код» + «ошибка» + «разбор ошибки» + «патч». Это уже пространство для творчества. Каждый разработчик LLM соберет свой дата-сет в своей структуре. Кто-то это все увяжет в предопределенные названия тулзов и ответы тулзов, кто-то соберет через ТЗ и его согласование.

Во-вторых, все данные для обучения нам доступны. Все модели учатся на репозиториях Github / Gitlab / HuggingFace и что там еще существует подобного рода. Вся идея в том, что нужно не только брать все репозитории на пред-обучение. А нужно собрать из тех же репозиториев нарезку взаимоувязанных Issue + Discussion + Pull Request + Merge.

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

Я предполагаю, что все датасеты можно собрать автоматически. Не нужно брать весь гитхаб и все репозитории, достаточно выбрать и составить дата-сет на несколько млн/млрд примеров, и это можно сделать ботами.

Я предполагаю, что нехватку семантической обвязки (обоснования, текста ошибок, дискуссий) можно дозаполнить даже простенькой моделью Haiku и т.п. При помощи этих же моделей можно провести первичный разбор примеров на «показательные» и «вредные».

Дальше мысли и идеи предлагаю обсуждать в комментариях. Все мои утверждения и предложения критикуемы, но это не значит, что вы сможете меня переубедить =)

P.S. А что же мы получим на выходе? Потенциально? Модели, обученные на таких примерах, будут стремиться сначала уточнить и обсудить ошибку, перед внесением правок. Модели, у которых будет развита процедурная память и в ней будет навык разработки, будут предлагать «заплатки» к конкретному программному коду и модулю, вместо стремления переписать все под ноль. А самое главное... Если таким моделям дать в руки тулзы для работы с git репозиториями, они начнут «нативно» следовать процессам разработки.

P.P.S. Ну и для скептиков, которые все еще считают, что я все придумал и это блажь.

  • https://arxiv.org/abs/2411.12580 Procedural Knowledge in Pretraining Drives Reasoning in Large Language Models (Ruis et al., ноябрь 2024) - авторы прямо обозначают наличие процедурной памяти у LLM

  • https://arxiv.org/abs/2403.09750 Meta-Cognitive Analysis: Evaluating Declarative and Procedural Knowledge in Datasets and Large Language Models (Wang et al., 2024) - еще одна работа, разделяющая процедурную и декларативную память у LLM

  • https://arxiv.org/abs/2502.18449 Advancing LLM Reasoning via Reinforcement Learning on Open Software Evolution (Wei et al., февраль 2025) - пример исследования, как влияет обучение на процессах Issue-Patch на результативность и качество решения задач по программированию

P.P.P.S. Если все уже ранее известно, то что же «Нового» в моей статье и моих утверждениях? Мир знает ≠ мир применяет. Есть исследования, которые подтверждают мои умозаключения. Я же предложил алгоритмический подход к созданию дата-сета и предлагаю... И просто подкидываю эти идеи «нашим» разработчикам / дрессировщикам LLM первым. Через пару недель я закину эту статью еще и в англ. инфо-пространство.

Комментарии (13)


  1. Kamil_GR
    27.05.2026 14:58

    Фактически вы предлагаете перейти к обучению на хард негативз. В случае с программированием это существенно проще. Генерировать правильный и почти правильной код легче. Это логично и правильно. Обучение процедурам, как таковым, я полагаю, приведет лишь к тому, что ЛЛМ выучится форме разбора ошибок но не более. Паттерны правильного программирования проявляются у нейросети через именно хард негативз.

    Ну и вынужден поправить, нейросеть не запоминает, вы не найдете в LLM текст Войны и Мира, а если найдете - это плохо обученная нейросеть. Главная задача нейросети во время обучения - генерализация, выстраивание границ.


    1. Real_Egor Автор
      27.05.2026 14:58

      Обучение процедурам, как таковым, я полагаю, приведет лишь к тому, что ЛЛМ выучится форме разбора ошибок но не более

      Она выучится процессу. (1) взять ошибку (2) посмотреть на исходный модуль (3) обсудить ее и уточнить (4) сделать патч в нотации патчинга. Это главное в моей мысли.


      1. Spyman
        27.05.2026 14:58

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


  1. SER_26
    27.05.2026 14:58

    В том, что описанный Вами путь рабочий, особых сомнений нет. И описание хорошее и интересное.
    Только вопрос, так как статья Ваша не просто описательная, а с фокусом на новизну: Вы не проверяли, действительно ли предложенное Вами содержит эту существенную новизну?

    На мой взгляд, основная проблема не в отсутствии алгоритмического подхода к созданию дата-сета (достаточно простого подхода в Вашем вполне логичном описании), а в экономической эффективности обеспечения вычислительной сложности этого процесса и контроле качества данных из Git-Hub (что является задачей сложной и, веротяно, дорогой).



    1. Real_Egor Автор
      27.05.2026 14:58

      1) То, что модели сейчас не обучены таким образом я вывожу эмпирически. По тому, как они работают и разрабатывают.

      2) То, что так учить можно, это точно. Я привел статьи. Проводили прям схожие эксперименты, и это давало результат

      Тут, в моем понимании, только времязатратно собрать датасет. Ну или этим еще всерьез никто не озаботился... Авторы статей прогоняли такую дрессировку на обучающих выборках (таймлайнах) программных модулей. А всерьез выбрать из гитхаба существенно большую выборку ошибка-разбор-патч (не пару тыс, и даже не пару млн, а прям сотни млн и млрд примеров)... Нужно немного его прошерстить, прочекать хотя бы слабенькой моделью и где-то выправить текст и его дополнить... А в идеале еще чекнуть человеку потом.

      И я уверен, что этим займутся. Не сейчас, так в этом-следующем году максимум. Первый, кто сделает это и обгонит конкурентов, создаст прецедент, и остальные нагонят в течении года. Китайцы так вообще вручную могут перебрать весь гитхаб или создать новые, качественно описанные репозитории. Просто скинувшись заметками -)

      Кроме того... Сейчас репозиториев с детальным описанием ошибок и трека решений очень много. Это все наполняется клодами и т.п. Возьми репозиторий OpenClaw или IronClaw, там уже несколько тыс Issue в готовом виде лежит.


      1. marchrap
        27.05.2026 14:58

        Мне кажется OpenAI уже собирают такой датасет через Codex.


        1. Real_Egor Автор
          27.05.2026 14:58

          вполне может быть. хотя статьи, которые я нашел, от 24-25 годов. Так что если бы всерьез взялись, то давно собрали бы такой датасет.


          1. SER_26
            27.05.2026 14:58

            Я к тому, что, судя по всему, это очень дорого пока получается - и вычислительная сложность высока и очистка "мусора" сложна и нетривиальна. Скорее, именно поэтому и не собрали.


            1. Real_Egor Автор
              27.05.2026 14:58

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


  1. zakarov
    27.05.2026 14:58

    Мне кажется, главный вопрос не в том, брать ли issue/PR, а в том, как из этого сделать нормальную обучающую траекторию. PR может чинить сразу несколько вещей, issue уже может содержать решение, тесты бывают плохими, патч может проходить CI и всё равно быть нерабочим (классика для тестов, написанных агентами).

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


    1. Real_Egor Автор
      27.05.2026 14:58

      использовать модели для выравивания примеров. да модели можно даже чередой промптов конкретных натравить на репо и нагенерировать примеры нужного качества и размера.... ну то есть у нас есть вайб-кодинг 1.0, он может помочь сделать датасет для вайб-кодинга 2.0


  1. LsdMax
    27.05.2026 14:58

    Я переводил LLM во фрактальность... Они делают откат в линейность...


    1. Real_Egor Автор
      27.05.2026 14:58

      нипонял... С моей статьей пересекается только слово LLM