В этом материале
Переход с 30B на 480B показателен, когда обе новые попытки получают одинаковые конкретные доказательства ошибки.
Передача задачи более крупной модели полезна, когда нерешённая проблема описана конкретно. Qwen3-Coder-480B-A35B-Instruct и Qwen3-Coder-30B-A3B-Instruct образуют проверяемую пару для оценки такого решения.
Разделите размер checkpoint и сложность задачи
Карточка модели 480B и карточка модели 30B описывают отдельные кодовые checkpoint. Названия обозначают разные общие и активированные масштабы. Ни одно название не доказывает, что любая ошибка меньшей модели исчезнет у более крупной.
Сначала проверьте, получила ли меньшая модель необходимые файлы, достоверные результаты инструментов и точное требование. Недостающие сведения не позволяют уверенно объяснить неудачу ограничением способностей. Более крупный checkpoint тоже способен сделать необоснованный вывод при неполной постановке задачи.
Опишите нерешённую ошибку
Предположим, изменение парсера проходит простые примеры, но нарушает крайний случай с экранированными разделителями. Сохраните падающий вход, ожидаемое дерево разбора, текущую реализацию и тесты. Объясните инвариант, который нарушил предыдущий патч.
Не передавайте следующей модели только утверждение, что предыдущая модель ошиблась. Такая формулировка скрывает инженерные доказательства и может вызывать согласие без исправления. Нужны первоначальная задача и конкретный протокол ошибки.
Сравните эскалацию с новой меньшей попыткой
| Попытка | Назначение |
|---|---|
| Первоначальная попытка 30B | Зафиксировать наблюдаемую нерешённую ошибку |
| Новая попытка 30B с доказательствами | Проверить достаточность улучшенной постановки |
| Попытка 480B с теми же материалами | Оценить влияние замены checkpoint |
| Окончательная приёмка | Выполнить одинаковые проверки парсера и регрессий |
Запишите допустимый вывод и количество повторов для каждой попытки. Иначе преимущество получит модель, которой предоставили больше возможностей поработать. Официальный кодовый репозиторий содержит примеры использования моделей, но не определяет критерии приёмки именно вашего парсера.
Проверяйте патч, а не только объяснение
Принятая эскалация должна исправлять случай экранированного разделителя и сохранять обычный разбор. Убедитесь, что модель не удалила падающий тест, не ослабила ожидаемый результат и не заменила сообщение об ошибке безусловным успехом.
Если обе новые попытки успешны, протокол ошибки мог оказаться полезнее замены модели. Если обе неудачны, проверьте внутреннюю согласованность эталонного поведения. Когда успешна только одна, сохраните точный патч и условия вместо обобщения по единственному примеру.
Постройте правило эскалации на доказательствах
Ведите небольшой журнал: тип задачи, категория первоначальной ошибки, переданные дополнительные сведения, принятый результат и незавершённые попытки. Определите момент передачи на ручную проверку вместо неограниченных повторов генерации.
Такой журнал помогает сформулировать правило перехода для определённых нерешённых зависимостей или крайних случаев после ограниченной первой попытки. Он не устанавливает гарантированного превосходства, универсальных требований к оборудованию или финансовой точки окупаемости. Полезное правило объясняет, когда проверяется дополнительная способность модели и какой подтверждённый результат оправдывает сохранение изменения.