Почему LLM продолжают генерировать ошибки в коде — и это не исправить масштабированием

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

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

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

В реальных проектах, особенно с проприетарным кодом и внутренними библиотеками, модель регулярно предлагает решения, которые чуть-чуть не попадают в цель. Все эти примеры объединяет одно: такие ошибки не случайны — они системны. Модель ориентируется на статистические паттерны из общедоступных данных, а не на строгую логику вашей задачи и среды.

Бенчмарки подтверждают ту же картину. На SWE-bench Verified, где задачи взяты из реальных GitHub-репозиториев, лучшие модели в начале 2026 года достигают 70–80%. Цифры растут, но до полной надёжности создаваемого кода остаётся существенный разрыв.

Причина кроется не в объёме обучающих данных или числе параметров. Она глубже — в самой природе современных LLM: они аппроксимируют вероятности продолжений, а не строят логически непротиворечивые решения. Именно в математическом фундаменте скрыто объяснение, почему баги неизбежны — не из-за «глупости» модели, а из-за того, как она преобразует запрос в ответ. Ожидать, что следующие версии моделей радикально изменят ситуацию, не приходится.

LLM модель: что под капотом

Чтобы понять, откуда берутся эти системные ошибки, стоит отложить в сторону все внешние улучшения. Отбросим всё, что навешано поверх базовой модели: чат-интерфейсы, интеграции с редакторами, агенты с их цепочками рассуждений, дополнительные проверки. Останется голая нейросеть — именно она и есть сердце любой современной LLM.

В основе лежит архитектура трансформера, предложенная в 2017 году. Но если отвлечься от механизма внимания и прочих ухищрений, топологически трансформер эквивалентен многослойному перцептрону — конструкции, которая появилась ещё в 1960-х годах. История уходит глубже: первый искусственный нейрон, выполняющий взвешенную сумму входов с последующей нелинейной трансформацией, описали в 1943 году. В 1958 году Фрэнк Розенблатт представил однослойный перцептрон — сеть с одним вычислительным слоем. Позже добавили дополнительные слои, и появился многослойный перцептрон, где сигнал последовательно проходит от одного слоя к следующему, а выход одного слоя становится входом для другого. Веса связей между нейронами — это параметры сети, подстраивающиеся во время обучения для минимизации ошибки.

Важная особенность такой архитектуры: сигнал распространяется строго в одном направлении — от входа к выходу. В ней нет обратных связей, как в биологических нейронных сетях. Сеть не может «оглянуться» на свой вывод, не способна отрефлексировать промежуточный результат и скорректировать его до финального ответа. Она лишена возможности внутренней верификации — просто преобразует вход в выход, не проверяя осмысленность результата.

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

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

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

Возникает естественный вопрос: если сеть всего лишь аппроксимирует увиденные паттерны, то какие задачи ей подвластны, а где неизбежны ошибки? Ответ скрыт в математическом фундаменте — теореме универсальной аппроксимации.

Математический фундамент: теорема универсальной аппроксимации

Устройство глубоких нейронных сетей опирается на мощный математический результат, который объясняет, почему такие модели вообще способны генерировать осмысленный код. Речь о теореме универсальной аппроксимации, доказанной в конце 1980-х — начале 1990-х годов.

История этой теоремы уходит в глубину математики девятнадцатого века. Ещё в 1885 году Карл Вейерштрасс доказал, что любую непрерывную функцию на отрезке можно приблизить полиномами со сколь угодно высокой точностью. Эта идея — аппроксимация сложного простыми элементами — легла в основу многих последующих результатов. Прямым предшественником для нейросетей стала теорема, доказанная Джорджем Цыбенко в 1989 году: многослойная сеть с нелинейной сигмоидной активацией способна аппроксимировать любую непрерывную функцию на компактной области с произвольной точностью. Через пару лет Курт Хорник обобщил результат — универсальность обеспечивает сама многослойная архитектура, а не конкретный вид активационной функции. Последующие работы ослабили требования к функции активации, расширив применимость теоремы.

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

Это и есть то, что происходит на этапе обучения. Модель видит миллиарды примеров и подстраивает веса, чтобы её выход максимально соответствовал реальным распределениям в данных. В популярных сценариях — типичных конструкциях Python или использовании стандартных библиотек — код выходит почти идеальным. Миллионы примеров из открытых репозиториев образуют плотную область обучающих данных. В ней аппроксимация достигает высокой точности.

Но теорема говорит именно об аппроксимации, а не о точном равенстве. За этим скрываются три принципиальных ограничения, которые часто упускают из виду.

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

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

И в-третьих, теорема является теоремой существования: она ничего не говорит о том, как обучить сеть и сколько именно слоёв и нейронов потребуется для достижения заданной точности.

Эти ограничения напрямую проявляются при генерации кода. Сеть не «понимает» логику программы и не проверяет её корректность — она аппроксимирует статистическое распределение токенов, усвоенное из данных. Когда вы просите написать функцию на знакомом языке с типичными паттернами, сеть уверенно интерполирует внутри плотной области. Но стоит выйти за её пределы — использовать нишевую библиотеку, новый синтаксис или проприетарный фреймворк — как аппроксимация теряет надёжность. Сеть продолжает генерировать правдоподобные токены, но их комбинация уже не гарантирует логически корректный код. Она не может этого гарантировать по самой своей математической природе.

Верификация остаётся за человеком

Теорема универсальной аппроксимации не просто описывает возможности нейросети — она чётко очерчивает её пределы. Модель аппроксимирует статистику, но не верифицирует логику. Она генерирует токены, но не доказывает корректность алгоритма. И в этом нет недостатка конкретной реализации — это следствие самой математической природы аппроксимации.

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

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

Это не угроза профессии разработчика — напротив, это смещение её фокуса. Рутина автоматизируется, но ответственность за сложное возрастает. Будущее программирования — не в написании каждой строчки, а в управлении сложностью: проектировании архитектуры, верификации критичных участков, принятии решений в условиях неопределённости. Человек не заменяется моделью — он становится её верификатором, архитектором и судьёй корректности.

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