🧬 Анализ научной статьи: DOI 10.1093/evolut/qpag111 (Steven A. Frank — «Generalization as the Great Leap in Evolvability», Evolution, июнь 2026) Мы провели исследование публикации через Perplexity. Её центральная идея поразительно точно ложится на наши архитектурные принципы самоэволюции агентов: • Центральный тезис: Естественный отбор работает точно так же, как алгоритмы машинного обучения. Главный двигатель эволюции биологических систем — это способность к обобщению (generalization) для выживания в новых средах, а не запоминание частных решений (memorization). • Первичный механизм: Способность к обобщению напрямую зависит от размерности регуляторного пространства (regulatory space dimensionality) — то есть от количества связей и настраиваемых параметров генома. Традиционная робастность (robustness) вторична. • Иерархия сложности: Многоклеточные организмы обобщают лучше одноклеточных эукариот (дрожжей), а те, в свою очередь, обобщают лучше прокариот (бактерий) из-за сложности и «перевязанности» (overwired) регуляторных сетей.

Полезность для нашего R&D: Наш старый роутер universal_router.py с жестко зашитыми в коде правилами вел себя как прокариот (🦠 бактерия) — у него была нулевая регуляторная размерность. При малейшем изменении среды (новые модели, thinking-токены) он ломался. Внедряя декларативный speculative_policy_v1.yaml с динамическими порогами (fallback_disable_threshold_pct: 40), мы кратно повышаем размерность регуляторного пространства нашего агента. Это дает ему способность обобщать логику роутинга на новые модели без ручного переписывания кода.

Research Is Not Engineering at a Slower Speed. https://voiceinthemachine.com/2026/06/10/research-is-not-engineering-at-a-slower-speed/ Я когда-то уже писал пост про то, чем занималась моя R&D команда, а тут вышел довольно интересный write up про различия между ресерчем, R&D и продуктовой разработкой от очень опытного чувака (сам Ян Лекун его рекомендует). Tldr такой, что в ресерче и продуктовой разработке все просто и понятно (с точки зрения ролей, системы оценивания и тд), а в R&D — наоборот. И что компании часто смешивают внутри R&D кучу всякой деятельности. У меня ровно так и было — команда одновременно делала: * и ресерч — копание в статьях, создание новых моделей и архитектур; была наша собственная амбиция догнать и перегнать дипмайнд по части рекомендашек * и довольно большой объем продуктовой разработки — копание в конкретных продуктовых доменах, активное участие в доведении моделей до прода, много внедрений каждое полугодие * и строила инфру — инструменты для работы с данными, обучения и внедрения моделей В статье также много места посвящено тому, где компании часто спотыкаются: 1. Оценивают ресерчеров по инженерным метрикам 2. Называют инженерную деятельность прорывным ресерчем 3. Теряют тот ресерч, который зародился сам по себе и не вписывается в рамки существующих процессов Со всеми пунктами тоже согласен, видел похожее на практике. Чтобы был сильный ресерч, нужны соответствующие люди, с нужными навыками и опытом. Все эти три пункта мешают найму/росту таких людей; скорее их отталкивают. До сих пор довольно много про это думаю в контексте рексистем — как правильно организовать такую команду, как её правильно оценивать, как найти/взрастить нужных людей, органично интегрироваться в структуру большой организации. Мыслей и идей за последний год накопилось много, надеюсь, доведется их как-нибудь реализовать.