К нашему очередному холивару в чате насчёт TDD хотел бы ещё раз пояснить, как устроено классическое SFT-обучение LLM на базовую генерацию кода, почему там тесты не используются в самом обучении, хотя при подготовке dataset применяются. Также я бы хотел пояснить, в чём разница с классикой и если вы используете контрактное программирование на манер моего GRACE, что стоит уже менять с учётом прогресса развития последнего поколения LLM. Короче говоря, как сделать контекст кода совместимым не с кожаными разработчиками, а с ИИ-ботами, чтобы попасть в их обучение. 🧠
Классический SFT-пайплайн обучения Coder-моделей описан в работе «Code Llama: Open Foundation Models for Code». Иногда эта работа путает непрофессионалов, т.к. они видят там использование тестов и наивно думают, что они в цикле обучения LLM, а тесты на деле применяются только при генерации dataset, а при самом обучении тесты выкидываются в помойку.
Классический процесс не только у Meta, а у всех примерно такой:
• берём seed-идею алгоритма, не сам алгоритм с кривизной от кожаных, а «идею» с того же GitHub;
• далее пишем агентом на предыдущей LLM для него код по seed-идее;
• чтобы проверить, что этот код работает, LLM задаёт вопросы к коду, а потом на базе них делаются тесты как «ответы на вопросы»;
• рабочие примеры идут в dataset, а сбойные выбрасываются.
В результате получаются пары «Описание задачи на языке людей — Код». На самом SFT-обучении тесты выкидываются и не включаются даже в описание задачи, т.к. сразу же вызовут у ИИ подгонку ответа под тест.
Для многих разработчиков, и особенно адептов TDD, создание кода ИИ — это итеративный процесс, но базовые знания ИИ, как писать код, скорее имеют связь совсем не с текущим программированием, а с… ПЕРЕВОДОМ С ЯЗЫКА НА ЯЗЫК. Фактически как модель обучают на SFT переводить с русского на английский, так потом учат переводить с русского на «питоновский». Поэтому для модели Python или JS — не какая-то абстракция, как для людей, а такой же язык со своей семантикой, как русский или английский, на котором можно выражать смысл.
Теперь какие тут приёмы семантической разметки под это и что поменялось недавно у LLM. Далее, если вы хотите активировать такой SFT «в лоб», то оптимально писать у функции контракт — и тогда для ИИ это почти такая же задача, как на SFT. Примерно 1–2 года назад обучение LLM велось практически всё в Full Attention, поэтому примеры для обучения были маленькие, реально ИИ умел надёжно превращать какое-то описание в код на 100–200 строк. Поэтому были целесообразны контракты мелкие, прямо на функциях.
В 2026 году вендоры сильно усовершенствовали пайплайны обучения, чтобы драматически расширить этот квант. Для этого активно применяется обучение специализированных моделей, а потом дистилляции в целевую, а также обучение уже крупными блоками. По факту это привело к тому, что блок «задача — код» по размеру драматически вырос где-то до 32 тысяч токенов. Как минимум последний fine-tuning ведётся примерно на такой размер. Это поменяло потребность модели относительно встроенной семантики в код примерно так:
• моделям почти не нужны контракты на функции, а нужны контракты на модули;
• большие модули стали модели секционировать, фактически вводя субконтракты на «секции» как группы функций.
Если вы посмотрите внимательно, как модели пишут даже сами сейчас без вашего вмешательства, то очень часто делают маленькую шапку модуля как контракт на модуль, а потом прошивают секционное разделение кода описанием, что значит секция. Описание, что делает функция, пишут только для 10 % самых сложных.
Вот за это естественное поведение моделей я вам и рекомендую цепляться, т.е. окультуривать шапки и секции. Строго говоря, для линейного кода я думаю, что такая проблема, как ошибки кодирования в нём, всё меньше будет актуальна, а будет всё больше важен дрейф моделей от первоначальных требований, что пользователь хотел получить. Это уже другая история, о которой я писал в предыдущих постах.
Однако, как видите, модели изначально учились быть компиляторами языка людей в код, а тестов в этом контексте на SFT-обучении даже не видели.
https://arxiv.org/abs/2308.12950
