Универсальность в кредит: от мозга мухи до ста строк кода

Универсальность в кредит: от мозга мухи до ста строк кода

В прошлой статье я разбирал коннектом мухи и работу FlyGM, где биологическая схема связей обыграла и MLP, и случайный граф, и пять стандартных GNN. Вывод был таким: сработала не графовость как таковая, а индуктивное смещение, то есть заранее известная структура задачи, встроенная в модель ещё до обучения.

Это красивая история про биологию, но у неё есть приземлённое продолжение. Тот же аргумент работает каждый раз, когда мы выбираем инструмент для задачи. Брать универсальную LLM или сто строк кода - это тот же выбор, что между трансформером и коннектомом, только в масштабе рабочего дня.

Эволюция не нанимала универсального специалиста

У мухи 166 700 нейронов. У больших языковых моделей - миллиарды и триллионы параметров. Муха при этом летает, охотится и уворачивается от хлопка тапком, имея память в тысячи раз меньше любой современной модели. Секрет не в волшебстве биологии, а в том, что её задача фиксирована. Отбор миллионы лет подгонял схему под одно тело и один набор поведений, и универсальность ей была просто не нужна.

Универсальность - это не бесплатный бонус, а покупка в кредит. Трансформер платит за неё датацентром на обучении и триллионами токенов. Коннектом платит тем, что умеет управлять только телом мухи. Ни один из них не получил обе крайности сразу.

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

Лестница инструментов вместо бинарного выбора

Спор "LLM против кода" обычно подают как выбор между двумя крайностями. Полезнее видеть лестницу из четырёх ступеней.

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

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

Третья ступень - узкие дешёвые LLM. Задача требует работы с текстом, но не глубокого рассуждения: черновая суммаризация, переформатирование, извлечение полей из полуструктурированного письма. Здесь достаточно бесплатного или почти бесплатного уровня вроде DeepSeek-V4-Flash, и платить за тяжёлую модель - значит покупать универсальность, которая не понадобится.

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

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

Один вопрос до выбора модели

Практическое правило простое. Прежде чем звать LLM, задать вопрос: какая структура уже есть в этой задаче?

DevOps-инженер смотрит на алертинг. Если триггер - это порог по метрике, то это одна строка в конфиге, и LLM здесь будет дорогим генератором случайных чисел. Если же нужен разбор свободного текста инцидента, место найдётся узкой модели.

QA-инженер готовит тест-данные. Таблички с граничными случаями генерируются циклом на сорок строк. LLM оправдана, когда надо писать тексты ошибок, которые читают люди, и само разнообразие формулировок ценно.

Разница между этими примерами не в сложности, а в том, сколько структуры известно заранее. Чем больше известно, тем ниже по лестнице надо стоять.

Цена универсальности

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

Есть и четвёртая цена, менее очевидная. Когда задачу решает универсальная модель, знание о её структуре остаётся в промпте, а не в системе. Промпт легко потерять, трудно версионировать и невозможно протестировать так же, как код. Сто строк кода - это сто строк, которые переживают смену модели, провайдера и моду.

Когда лестница работает в обратную сторону

Честности ради: правило действует в обе стороны. Есть задачи, где попытка обойтись кодом вместо модели дороже, чем модель. Свободный текст, незнакомые форматы, рассуждение над длинным контекстом - тут структура действительно неизвестна, и писать тысячи ветвлений вручную значит повторять путь модели, только хуже и без корпуса. Ошибка "не пущать LLM" зеркальна ошибке "пустить LLM везде": обе заменяют анализ задачи идеологией.

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

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