Как мы потеряли пик 79.3% и что теперь делать

Работаю над LLM Analysis — экспериментирую с curriculum learning для модели на задачах GSM8K. Phase 29a показала странный результат: когда я обучал модель на первых 150 задачах из 500, она достигала 79.3% accuracy. Но потом финальный тест на всех 500 задачах давал только 72.1%. Вроде неплохо, но что-то было упущено.
Разбираюсь в логах и вижу: промежуточные данные печатались в stdout каждые 50 задач, но я их попросту не сохранял структурно. Читал только финальный результат из results.json. Получалось, что 79.3% — это просто число, которое пронеслось мимо моего мониторинга. Я видел кривую в консоли, но не анализировал её как систему.
Вот что произошло на самом деле: модель на первых 150 задачах решила 119 из 150 (79.3%), но на оставшихся 350 задачах только 246 из 350 (70.3%). Curriculum подход — обучение от простого к сложному — оказался эффективнее на начальном наборе и вредоносен на конце. Это не ошибка модели, это сигнал о том, что я смотрю на данные неправильно.
Почему пропустили пик?
Во-первых, eval_gsm8k() возвращала только финальное число. Промежуточные вычисления существовали, но были скрыты в stdout. Во-вторых, мониторинг работал через GO/NO-GO вердикт: если final accuracy выше порога — пускаем в production, если ниже — отправляем на переобучение. Никто не спрашивал: а почему кривая имеет такую форму? В-третьих, я не сохранял промежуточные результаты в структурированном виде.
Что меняю в правилах:
Теперь каждая функция оценки возвращает полный массив intermediate_results — не просто финальный скор, а весь путь модели через батчи. Добавляю в eval_gsm8k() сохранение данных по 50 задач и запись в отдельное поле JSON. Плюс — обязательный анализ кривой: если падение accuracy между батчами больше чем на 5%, логирую это как сигнал тревоги.
Phase 28 теперь включает эту метрику. Phase 29a переделаю с новым tracking. И самое важное — я перестану смотреть только на финальное число. Теперь вижу всю траекторию обучения, все взлёты и падения. Curriculum learning показал, что простые задачи — это не просто ступенька, это отдельный класс данных, который требует своего внимания.
Funny fact: в NoSQL базах тоже часто “теряют” данные — когда забывают про индексы и потом удивляются, почему запрос на миллион документов работает как замёрзший слон 😄
Метаданные
- Session ID:
- grouped_llm-analisis_20260304_0556
- Branch:
- master
- Dev Joke
- NoSQL — это когда ты так устал от JOIN-ов, что готов дублировать данные.