TL;DR
Исследование показало: традиционные метрики сложности кода (цикломатическая сложность, структура дерева синтаксиса, количество ветвлений) почти не предсказывают, справится ли LLM с пониманием кода. Единственная метрика с заметной корреляцией — длина кода: чем длиннее программа, тем выше шанс ошибки модели. При этом модели с похожей общей точностью (93% vs 92%) могут пересекаться только в 75% решённых задач — каждая сильна в своём.
Команда обучила два предиктора успеха LLM: классификатор на 300 человеческих метриках кода (размер, сложность, структура) дал точность предсказания AUROC 0.63 — чуть лучше случайного угадывания. "Shadow model" (обученная предсказывать успех напрямую из сырого кода) достигла AUROC 0.86 — лучше, но всё равно 14% ошибок остаются необъяснимыми. Из 300 метрик значение имели только 17 (5.8%), и все они так или иначе связаны с длиной.
Вывод: LLM "видят" сложность иначе, чем люди. То, что кажется человеку сложным (много вложенных циклов, запутанная логика), может быть простым для модели. А длинный, но структурно простой код — сломать её. Кроме того, разные модели ломаются на разных задачах по непредсказуемым причинам — даже самые продвинутые предикторы не могут объяснить все паттерны.
Ключевые находки для работы в чате
1. Длина кода — главный предиктор ошибок
Что обнаружили: Единственная традиционная метрика с заметной корреляцией — количество символов/строк кода. Цикломатическая сложность, глубина вложенности, количество переменных — всё это почти не влияет на шанс ошибки LLM.
Для тебя это значит: - 200-строчный линейный скрипт опаснее 50-строчной функции с тремя вложенными циклами - При работе с длинным кодом — разбивай на фрагменты по 20-30 строк - Не полагайся на интуицию "этот код простой" — для LLM важнее длина контекста
2. Разные модели сильны в разном
Что обнаружили: Две модели с похожей общей точностью (93.1% vs 92.2%) решили по 230-234 задачи, но пересеклись только в 175 из них. Каждая уникально справилась с ~55-59 задачами, где другая провалилась.
Для тебя это значит: - Если GPT-4 дала странный ответ на важную задачу — проверь в Claude - Модели специализируются по-разному, хотя бенчмарки показывают похожие цифры - Для критичных задач (код в продакшн, важное решение) — перепроверка разными моделями снижает риск
3. LLM ломаются не там, где сложно людям
Что обнаружили: Традиционные метрики сложности (ветвления, циклы, граф зависимостей) не предсказывают провалы LLM. Shadow model нашла паттерны, но они model-specific — у UniXcoder свои слабости, у GPT-4 свои, и предсказать их человеческими понятиями не получается.
Для тебя это значит: - "Простая задача" может сломать модель, "сложная" — пройти легко - Не расслабляйся на простых запросах — проверяй вывод - При ошибке не пытайся "упростить логику" — попробуй укоротить контекст или сменить модель
Практические техники
Техника 1: Дробление длинного кода
Проблема: LLM чаще ошибается на длинном коде, независимо от его сложности.
Решение:
Задача: Проанализировать 150-строчный скрипт парсинга данных
❌ Плохо:
"Вот 150 строк кода, найди баги"
✅ Хорошо:
"Вот функция parse_header (строки 1-25). Что она делает?"
→ Разобрался
"Вот функция validate_data (строки 26-60). Как она проверяет входные данные?"
→ Разобрался
"Вот основной цикл (строки 61-120). Как он связан с предыдущими функциями?"
Рычаги: - Размер фрагмента: 20-30 строк — безопасно, 50+ — риск растёт - Перекрытие: дай 5 строк контекста из предыдущего фрагмента для связности - Явные связи: в каждом запросе напомни "это часть скрипта для парсинга логов"
Техника 2: Перепроверка разными моделями
Проблема: Модели с похожей точностью сильны в разном — ошибка в GPT не значит ошибку в Claude.
Решение:
Критичная задача: Код для обработки платежей, нужно проверить логику
1. GPT-4:
"Вот функция process_payment. Есть ли в ней логические ошибки или edge cases, которые не обработаны?"
2. Claude:
[Тот же запрос]
3. Сравни выводы:
- Где выводы совпадают → скорее всего верно
- Где расходятся → копай глубже, это зона риска
Когда применять: - Код для продакшна - Важные бизнес-решения - Анализ безопасности - Когда цена ошибки высока
Техника 3: Сброс контекста при странных ответах
Проблема: Длинный диалог = длинный контекст = выше шанс ошибки.
Решение:
Ситуация: В длинном чате с анализом кода модель вдруг дала странный ответ
❌ Плохо:
Продолжать в том же чате: "Нет, ты ошибся, посмотри ещё раз"
✅ Хорошо:
1. Открой НОВЫЙ чат
2. Скопируй только нужный фрагмент кода (не всю историю)
3. Задай вопрос с нуля
Принцип: Сбрасывай накопленный контекст, возвращайся к короткому запросу
Почему это работает
Слабость LLM: Модели обрабатывают код не как люди — они видят поток токенов, не абстрактную логику. Длинный контекст усложняет attention mechanism (механизм внимания к разным частям ввода), даже если логика проста. Исследование показало: из 300 метрик сложности кода только длина имеет значение.
Сильная сторона LLM: Модели отлично справляются с локальными паттернами в коротких фрагментах. 20-30 строк — в зоне уверенности, 100+ — в зоне риска. При этом разные модели обучены на разных данных с разными приоритетами, поэтому их слабости не совпадают.
Как техники используют это: Дробление кода снижает нагрузку на attention, фрагменты попадают в "безопасную зону" длины. Перепроверка разными моделями использует разницу в специализации — вероятность что обе ошибутся одинаково низка. Сброс контекста убирает накопленный "шум" из истории диалога.
Ментальная модель: Представь, что LLM — это студент, который лучше решает 10 коротких задач, чем одну длинную, даже если длинная проще по логике. И у каждого студента (модели) свои слепые зоны, которые не предсказать заранее — поэтому перепроверка работает.
Ограничения
⚠️ Непредсказуемость остаётся: Даже лучший предиктор (shadow model с точностью 86%) оставляет ~14% ошибок необъяснёнными. LLM могут "сломаться" на неожиданных местах, которые не предсказать ни длиной, ни сложностью, ни другими метриками.
⚠️ Только код: Исследование фокусировалось на понимании кода. Неясно, насколько выводы про длину vs сложность переносятся на другие домены (анализ текста, данных, изображений).
⚠️ Разбиение требует понимания: Дробить код на осмысленные фрагменты — нужно самому понимать структуру. Если ты не знаешь Python, разбить скрипт правильно сложно.
Как исследовали
Команда из University of Luebeck взяла 800 тысяч троек (программа, вход, выход) из CodeNet — массивного датасета с миллионами решений алгоритмических задач на Python. Для каждой тройки проверяли: правильно ли модель определяет, соответствует ли выход входу для данной программы — бинарная классификация вместо генерации кода.
Ключевая идея: если модель понимает код, она должна предсказать его поведение. Это работает и для классификационных моделей (UniXcoder), и для генеративных (GPT-4, Claude) — универсальный тест.
Затем обучили два предиктора успеха: 1. Классификатор на человеческих метриках — экстрактили 300 фичей: размер (строки, символы, токены), опкоды байткода Python, структура AST (дерево синтаксиса), цикломатическая сложность, граф зависимостей. Обучили XGBoost предсказывать: справится ли модель с этой задачей? 2. Shadow model — файн-тюн UniXcoder на сыром коде без фичей. Задача: предсказать успех модели напрямую из текста программы, входа и выхода.
Результат удивил: человеческие метрики дали AUROC 0.63 (едва лучше случайного 0.5), shadow model — 0.86 (хорошо, но не идеально). Применили SAGE (метод из теории игр для оценки важности фичей) — выяснилось, что из 300 метрик значимы только ~17 (5.8%), и все они коррелируют с длиной кода.
Ещё интереснее: топ-фичи различаются между моделями. UniXcoder смотрит на лексику (количество токенов, идентификаторов), GPT-OSS-120B — на опкоды и плотность графа. Это объясняет, почему модели с похожей точностью решают разные наборы задач.
Финальный инсайт: shadow model предсказывает лучше, но 14% ошибок остаются необъяснимыми. LLM имеют model-specific паттерны провалов, которые не сводятся ни к человеческим метрикам, ни к простым learned features. Это означает фундаментальную непредсказуемость — даже продвинутые методы не дают гарантий.
Ресурсы
"Beyond Accuracy: Characterizing Code Comprehension Capabilities in (Large) Language Models"
Felix Mächtle, Jan-Niclas Serr, Nils Loose, Thomas Eisenbarth
ITS, University of Luebeck, Germany
GitHub репозиторий: https://github.com/UzL-ITS/code-comprehension-capabilities-llms