ML-разработчик дообучил модель под свой проект: месяц вместо трёх
ML-разработчик дообучил модель под свой проект: месяц вместо трёх ML-разработчик с ником ToxaBes описал свой подход, который он называет «имаго-кодинг»: вместо того чтобы каждый раз объяснять нейросети контекст проекта, он дообучает модель — то есть дополнительно тренирует её на материалах конкретного проекта, чтобы она знала его данные, договорённости и стиль кода. По его словам, на его проектах это даёт один месяц работы вместо трёх у команды из трёх человек, причём с более высоким качеством. Именно поэтому с ним стали работать интеграторы. Толчок к смене подхода дало разочарование в обычной схеме. Автор годами встраивал нейросети в привычный процесс: сначала чаты, потом плагины для среды разработки, затем «харнесс» — каркас из инструментов, тестов и циклов проверки, который превращает модель в агента, то есть самостоятельно действующего исполнителя. Но эти изменения лишь ускоряли отдельные этапы, а качество перестало расти. Тогда он решил поменять сам процесс разработки целиком, а не отдельные его шаги. Проблема больших моделей, по его наблюдению, не в глупости, а в незнании конкретного проекта: модель не знает, как устроены логи заказчика, какие договорённости приняты в команде, и каждый раз выдаёт «среднепопулярное» решение, а большую часть запроса автор тратил на объяснение контекста. Он приводит цифры бенчмарка MLE-bench (75 задач с Kaggle — платформы соревнований по машинному обучению): в 2024 году сильная модель решала на бронзовую медаль лишь около 17% задач, за два года специализированные агентные системы подняли результат до 65–70%. Но это публичные задачи с чистой постановкой — на закрытом проекте без готовых решений высокий балл мало что гарантирует. Вторая причина — правовая: автор работает с данными предприятий, где есть коммерческая тайна или персональные данные, и отправлять их в зарубежное облако чревато штрафами. Его система делает сотни запросов на одну задачу, поэтому он перевёл всё на локальные модели — код, схемы, логи и обучающие выборки остаются на его машинах или в контуре заказчика. Как это устроено: модель-«строитель» внутри харнесса получает знания проекта двумя способами. RAG — поиск по базе фактов проекта — приносит конкретные сведения, а LoRA — лёгкое дообучение модели на примерах — приносит «привычки»: она пишет код с бизнес-сущностями проекта, а не усреднённую лапшу, поэтому код быстрее проходит проверку и создаёт меньше технического долга. Модели заказчиков — от небольшой 9B до полноценной 35B (размер в миллиардах параметров) — обучаются обычным способом. Главная сложность, по словам автора, не в обучении, а в датасете — наборе обучающих примеров: больше не значит лучше, выборку приходится собирать и чистить как продукт. Автор честно оговаривает: такой строитель не станет умнее больших моделей вообще, он полезнее на узкой группе задач, где важно знать версию, схему данных и договорённости проекта. Сейчас он проверяет, как дообучение работает вместе со спецификациями — описаниями требований к задаче. Источник: https://habr.com/ru/articles/1086430/