Перейти к содержанию
Публикация AiManual

Mica v0.5 4B: как компактная модель превращает фразу в цепочку решений для Minecraft-бота

Автор Mica v0.5 4B показал, как 4B-модель разбирает одну фразу «добудь 3 свиные отбивные и сделай слиток незерита» на цели, категории и количества, а затем ведё

Коротко

Что будет в материале

  1. 01

    Что такое Mica v0.5 4B и в чём суть подхода

  2. 02

    Почему нельзя решить задачу одним запросом к LLM

  3. 03

    Как фраза разбирается на цели и количества: цепочка вопросов Mica

  4. 04

    Как Mica ведёт бота от пустых рук до слитка незерита

Что такое Mica v0.5 4B и в чём суть подхода

Mica v0.5 4B - компактная модель на 4 млрд параметров, которая превращает одну фразу на естественном языке в цепочку небольших решений с вариантами ответа. Автор проекта показал это на запросе «я голоден, добудь минимум 3 свиные отбивные и сделай слиток незерита»: модель выделяет две цели, определяет количество для каждой и запускает выполнение с пустых рук (разбор автора на Reddit).

Главная идея в отказе от одного большого шага. Модель не пытается понять всю фразу целиком. Запрос режется на цепочку маленьких вопросов с готовыми вариантами, и каждый ответ сужает следующий: сколько целей в сообщении, к какой категории относится предмет, какая подкатегория, какой именно предмет из списка игры, для кого и сколько.

Роли разделены жёстко. Код поставляет варианты из данных игры. Mica делает выбор и показывает вероятность по каждому ответу. Бот выполняет работу рук и ног: ходит, добывает, крафтит. Содержательные решения остаются за моделью. Агент как готовый продукт пока не выпущен, но код и веса выложены на GitHub и Hugging Face.

Это принципиально иная схема, чем привычный LLM-агент с текстовым рассуждением. Здесь модель не пишет план словами и не вызывает инструменты по описанию, она отвечает на узкий вопрос выбором из ограниченного списка. Отсюда и низкая задержка, и наблюдаемость: каждое решение видно отдельно вместе с уверенностью.

Почему нельзя решить задачу одним запросом к LLM

В исходной фразе два разных предмета, два разных количества и две несвязанные производственные цепочки. Свиные отбивные требуют одного набора действий, слиток незерита тянет за собой Нижний мир, обсидиан и портал. Если попросить модель разобрать всё за один проход, ей придётся одновременно определить число целей, категории, точные предметы, адресата и количество. Ошибка в любом звене ломает весь дальнейший план: бот уйдёт добывать не то или не в том объёме.

Декомпозиция переводит задачу в набор проверяемых шагов. Вопрос «сколько разных предметов в сообщении» имеет короткий ответ. Вопрос «какой именно предмет из игрового списка» тоже. Каждый ответ можно посмотреть отдельно и увидеть вероятность. Принцип автор формулирует так: если что-то слишком сложно решить за один запрос, разбей это на меньшие суждения и сужай шаг за шагом.

Это инженерный приём, он не зависит от конкретной архитектуры модели. Держать в голове весь план не нужно: достаточно уверенно отвечать на один узкий вопрос за раз. Для агентов на компактных локальных моделях свойство критичное, потому что 4B-сеть плохо тянет длинные многофакторные рассуждения в одном проходе.

Как фраза разбирается на цели и количества: цепочка вопросов Mica

Порядок вопросов идёт от общего к частному. Сначала сообщение целиком, потом каждый предмет в том порядке, в котором он назван.

ШагВопрос, который решает MicaОтвет на исходной фразе
1Сколько разных предметов просит сообщение и есть ли действие вроде «подойди сюда»Два предмета, отдельного действия нет
2Категория предмета: еда, инструменты, руды и материалыСвиные отбивные: еда. Слиток незерита: руды и материалы
3Подкатегория, для руд: обычный мир или Нижний мирНезерит: линия Нижнего мира
4Точный предмет из игрового списка, без keyword matchingКонкретный предмет из списка игры, без подбора по слову «отбивная»
5Для кого предмет и сколькоДля игрока: минимум 3 отбивные и 1 слиток

Код только поставляет варианты из игровых данных. Выбор делает Mica, и каждый её ответ сопровождается вероятностью. Панель показывает вопрос, увиденные варианты и уверенность по каждому, поэтому разбор фразы перестаёт быть чёрным ящиком.

Почему выбор из вариантов, а не свободная генерация

Свободная генерация даёт модели возможность назвать предмет, которого в игре нет, или смешать два похожих названия. Варианты приходят из данных игры, и пространство ответов ограничено реальными предметами. Точный предмет выбирается из игрового списка, keyword matching не используется: код не ищет совпадение по слову, модель сама указывает нужный элемент списка.

Это сужает класс ошибок. Полностью их не убирает: выбор делает вероятностная модель, и промах остаётся возможным. Разница в том, что такой промах видно сразу, по низкой вероятности и по несоответствию шагу выше.

Роль вероятностей в панели решений

Ответ модели перестаёт быть бинарным фактом и превращается в оценку уверенности. Можно глазами проследить, на каком шаге Mica колебалась, и понять, где цепочка пошла не туда. Для отладки агента это полезнее, чем один длинный текстовый план, который непонятно как проверять.

Время решений в панели - оценки для RTX 3090, а паузы вырезаны из видео. Ролик показывает логику работы. Реальный темп на слабом железе он не отражает.

Как Mica ведёт бота от пустых рук до слитка незерита

Цепочка выполнения длинная. Бот начинает без инструментов и проходит путь: дерево, инструменты, железо, алмазы, обсидиан, портал, Нижний мир, древний мусор, золото и в конце слиток незерита. После этого он возвращается и отдаёт добытое (описание и видео у автора). Каждый переход - отдельная небольшая задача, которую кто-то должен выбрать.

Планировщик рецептов: откуда берутся допустимые действия

Во время выполнения планировщик рецептов перечисляет действия, допустимые в текущий момент. Mica выбирает из этого списка следующее. Логика та же, что и при разборе фразы: сузить пространство вариантов до валидных и дать модели принять небольшое решение.

Планировщик отвечает за корректность опций, модель за приоритет. Недоступное действие в список не попадёт, поэтому «пойти в Нижний мир» до постройки портала в вариантах не появится. Это архитектурное решение автора, а не функция готовой библиотеки: конкретные фреймворки в описании не участвуют.

Где заканчивается суждение модели и начинается работа бота

Бот ходит, добывает и крафтит. Почти все содержательные решения принимает Mica: что делать дальше, какой предмет нужен, сколько единиц. Автор формулирует разделение прямо: бот - руки и ноги, суждение в основном за моделью.

Такая граница упрощает перенос. Среда исполнения может быть любой: игра, браузер, файловая система, внутренняя система компании. Меняется код, который поставляет варианты, модель остаётся.

Ограничения Mica v0.5 4B: что автор говорит прямо

Автор не прячет слабые места. По его собственным словам, Mica v0.5 4B далека от того, чтобы оценивать все переменные от А до Я так, как это делает человек. Он также оговаривает, чего не заявляет: модель не принимает каждый кадр как непрерывный поток, не реагирует со сверхчеловеческой скоростью и не обобщает на любые ситуации, которые могут возникнуть.

  • Глубина анализа переменных ниже человеческой.
  • Нет непрерывной обработки видеопотока кадр за кадром.
  • Нет гарантии переноса на любые незнакомые ситуации.
  • Агент как продукт не выпущен: доступны код и веса.

Практический вывод: перед нами исследовательский прототип с открытыми весами. Ждать от 4B-модели человеческого уровня разбора контекста не стоит. Ценность в другом: прототип показывает, что цепочка маленьких выборов с вероятностями доводит до результата задачу, которую тяжело взять одним запросом.

Скорость: почему Mica быстрее API-моделей и что значат цифры

По измерениям автора, API-only модели принятия решений Jev, Clef и Ms Decision оказались в среднем примерно в 60 раз медленнее Mica (цифры и оговорки автора). Он же отмечает: локальная модель обычно в 10+ раз быстрее, если у неё не десятки миллиардов активных параметров. Это измерения в его условиях на его задачах, а не независимый бенчмарк. Экстраполировать их на другие модели, железо и сценарии нельзя.

Разница объясняется механикой. Решение здесь - один короткий проход по списку вариантов. Генерации текста с планированием на этом шаге нет. Чем меньше модель и чем короче ответ, тем заметнее выигрыш, а в агентном цикле таких решений набегают сотни. Подробнее о замерах и архитектуре Mica v0.5 мы разбирали в отдельном материале с таймингами на одной GPU.

Почему AMD-GPU - не лучший тестовый стенд для Mica

Локальная видеокарта автора - AMD, и аппаратные ускорения Mica ей мало помогают. Решения на этом стенде шли медленнее, чем шли бы на NVIDIA. Ориентир по времени в панели - оценки для RTX 3090, это не замеры с его машины. Конкретных цифр по отдельным AMD-картам в источнике нет, обещать на них производительность не на чем.

С чем сравнивали: API-only модели принятия решений

Jev, Clef и Ms Decision - модели принятия решений, доступные только через API. Автор сравнивал с ними Mica и получил среднюю разницу около 60 раз. Архитектурных деталей этих моделей он не разбирает, так что сравнение стоит читать как оценку задержки в одном сценарии. Рейтинга качества решений из него не следует.

Где взять код и веса и что уже доступно

Код и веса Mica v0.5 4B доступны на GitHub и Hugging Face. Агент как готовый продукт пока не выпущен, установочного пакета нет. Практическая рамка такая: это исследовательский проект. Готовой сборки «поставил и играешь» тоже нет.

Перед запуском стоит заложить время на собственные эксперименты: разобраться с форматами весов и запуском на своём железе. О вариантах вроде INT8 и GGUF, а также о работе на картах от 8 ГБ мы писали в разборе запуска Mica v0.5 на потребительской GPU.

Можно ли перенести подход за пределы Minecraft

Автор считает, что модель принятия решений пригодится далеко за пределами Minecraft-агента. Принцип он описывает просто: если что-то слишком сложно решить за один запрос, разбей на меньшие суждения и сужай шаг за шагом. Независимых подтверждений переносимости в источнике нет, это заявленная позиция автора.

Паттерн раскладывается на четыре переносимых элемента:

  1. Код поставляет валидные варианты из данных предметной области.
  2. Модель делает небольшой выбор и возвращает вероятность.
  3. Планировщик перечисляет действия, допустимые прямо сейчас.
  4. Исполнитель выполняет выбранное действие.

Как гипотезы переноса можно назвать маршрутизацию заявок в поддержке, выбор инструмента терминальным агентом, разбор заказа на позиции во внутренней системе. Похожие схемы строят и другие команды: Aplomb 1 от EmpirioLabs выбирает действие и возвращает вероятность по каждому инструменту и аргументу, о ней мы писали в обзоре открытой 5.3B decision-модели. Подтверждением подхода Mica это не служит, но показывает, что выбор из вариантов с вероятностью становится отдельным классом моделей.

Итог: кому и зачем разбираться с Mica v0.5 4B

Материал полезен тем, кто строит агентов на компактных локальных моделях и ищет способ срезать задержку и стоимость решений. Схема «код даёт варианты, модель выбирает, исполнитель делает» переносится на любую область, где есть список допустимых действий и понятная цель.

Ограничения держим в голове: это прототип, агент не выпущен, автор сам оговаривает глубину анализа и отсутствие обобщения на любые ситуации, а цифры скорости получены в его условиях, с AMD-картой на его машине и оценками для RTX 3090 в панели. Нужен готовый продукт под ключ - это не тот случай. Интересен рабочий паттерн декомпозиции решений - код и веса открыты, гипотезы можно проверять на своём железе.

Подписаться на канал