Про route.yaml, авторство в пайплайнах и почему open source без экономики рискует снова стать кормом для платформ

ИИ меняет масштаб возможного для одиночки не теоретически, а практически.

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

Сейчас эта граница размывается. Один человек с нормальным стеком — LLM, генерация изображений/видео/звука, Blender, compositing, локальные пайплайны, немного скриптинга — может делать вещи, которые недавно требовали цеха.

Я это ощущаю руками: работаю с визуальным искусством, купольными фильмами, мэппингом, генеративной графикой, 3D, монтажом. ИИ не «заменяет художника» — он убирает часть производственного трения: рутину, перебор вариантов, черновую сборку, перевод между форматами и часть инфраструктурных издержек.

Плохая новость: эта свобода арендованная.

Кто владеет этой студией?

Новый контроль выглядит не как старый индустриальный. Он аккуратнее, мягче и неприятнее.

Раньше хозяин говорил: работай на меня.
Теперь: твори свободно. Вот подписка, лимит, кредит, API, правила.

Если ты делаешь серьёзную работу, ты завязан на чужой слой.

Новый феод эпохи ИИ — это не земля, не фабрика и даже не социальная сеть. Это связка из весов модели, доступа к inference, API, датасетов и политики использования.

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

Это глубже, чем контроль дистрибуции.

Раньше корпорации владели каналом: площадкой, трафиком, лентой, поиском, рекламой. Теперь есть шанс, что они будут владеть самим языком производства — не тем, как ты распространяешь результат, а тем, как ты его формулируешь и получаешь.

Кто контролирует этот слой, тот контролирует:

• какие запросы вообще имеют шанс на хороший ответ,

• какие темы режутся фильтрами,

• какие стили поощряются, а какие становятся дорогими или невозможными.

Это уже не просто платформа. Это инфраструктурный уровень ниже — контроль над языком производства.

Почему open source пока не закрывает проблему

Первый рефлекс понятен: есть open source, локальные модели, ComfyUI, Hugging Face. Зачем драматизировать?

Потому что open source сейчас закрывает только часть задачи.

ComfyUI — отличная штука для локальных визуальных пайплайнов. Но это рабочий стол, не универсальный протокол взаимодействия между независимыми участниками. Он не решает вопрос авторства, provenance, лицензирования и распределения ценности между участниками цепочки.

n8n автоматизирует процессы. Прекрасно. Но он не решает вопрос: кто создал маршрут, кто внёс вклад, как это учесть, как перенести между средами.

Hugging Face действительно близок к этой области: Hub уже стал одной из главных точек сборки моделей, датасетов, Spaces и API. Но это ещё не открытый протокол маршрутов. Там есть хранилище и интерфейсы доступа, но нет стандарта, который описывает, как результат одной модели структурно и воспроизводимо передаётся следующей — с provenance, авторством и экономикой. И главное: это всё ещё центральная платформа, а не нейтральный слой.

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

Open source сейчас решает доступ к инструментам, но не решает совместимость между ними:

• нет общего формата маршрута, который можно передать от одной модели к другой;

• нет единого слоя provenance;

• нет стандартного способа описать, кто внёс вклад;

• нет общего механизма для обнаружения и повторного использования маршрутов.

Open source сегодня — это скорее набор мастерских, чем сеть производства.

Георгий, который убил дракона, и потом стал им

В истории это повторялось много раз: структуры, созданные как защита от старой власти, со временем сами становились центрами контроля.

Венеция — вольная коммуна, убившая феодального дракона. Через двести лет — торговая империя, эксплуатирующая Средиземноморье. Амстердам — бунт против Габсбургов. Через поколение — VOC, первая корпорация с правом вести войну. Буквально дракон с акционерным капиталом. City of London — вольный город внутри монархии. Сегодня — один из центров глобального финансового контроля.

Это не морализаторство, а обычная гравитация власти. Ганза работала, пока была нужна как форма сопротивления. Потом превращалась в систему собственных интересов.

Вывод: союз как организация почти неизбежно начинает производить центр.

Именно поэтому идея «давайте создадим мощную платформу для независимых творцов» меня не убеждает. Через некоторое время вы просто построите ещё одну платформу — с более приятным интерфейсом, но той же структурой подчинения.

Поэтому вопрос не в том, как построить "добрую платформу", а в том, как не строить центр там, где можно обойтись протоколом.

Протокол против платформы

Если не хотим строить очередного дракона, надо смотреть не на платформу, а на протокол.

Платформа — это центр. У неё есть владелец, правила, модерация, API, доступ, бан, тариф, лимит, политика.

Протокол — это язык взаимодействия. У него может быть спецификация, но не обязан быть хозяин.

Примеры: email, HTTP, RSS, ActivityPub, Bitcoin.

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

Протокол — это система, которая может работать без единого владельца, если у неё есть:

• открытая спецификация,

• несколько независимых реализаций,

• нет единственного обязательного узла,

• есть возможность локального исполнения,

• есть право на форк без потери совместимости.

Если без одной компании вся система умирает — это не протокол, а централизованная платформа с хорошим маркетингом.

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

Если у системы нет хотя бы такого формата, она остаётся метафорой, а не инфраструктурой.

Единица ценности — не модель, а маршрут

Полезное слово: маршрут.

Не модель сама по себе, а маршрут между моделями и инструментами — это будущая единица ценности.

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

Маршрут — это не абстрактная "цепочка мышления", а формализованный объект, который можно передать между системами.

Допустим, у тебя пайплайн для купольного фильма: LLM превращает бриф в структурированную сцену, image model генерирует ключевые кадры, video model анимирует, локальный скрипт приводит всё к нужной геометрии купола, а человек вручную чистит артефакты.

В этом случае ценность — не в одной модели. Ценность — в воспроизводимой последовательности решений, параметров, проверок и ручных вмешательств. Это и есть маршрут.

Минимальный маршрут должен описывать:

• что было на входе,

• какая модель это обработала,

• какой был тип выхода,

• какие параметры использовались,

• кто автор маршрута,

• как фиксируется provenance,

• как задаётся лицензия и, при необходимости, распределение вознаграждения.

Без этого "маршрут" остаётся красивым словом для workflow.

Черновой формат маршрута

Примерно так это может выглядеть на первом приближении:

yaml

route:
  id: route-id-v1
  author: did:example:creator123
  license: CC-BY-4.0
  
  provenance:
    created_at: 2025-04-24T10:00:00Z
    version: 0.1.0
    
  economics:
    enabled: false
    author_share: 0.05
    model_shares:
      - model: model-id-text-gen
        share: 0.02
      - model: model-id-image-gen
        share: 0.02
        
  steps:
    - id: step-1
      model: model-id-text-gen
      input_schema: 
        type: text
        format: prompt
      output_schema:
        type: text
        format: structured_description
      parameters:
        temperature: 0.7
        max_tokens: 500
        
    - id: step-2
      model: model-id-image-gen
      input_schema:
        type: text
        format: structured_description
      output_schema:
        type: image
        format: png
      parameters:
        resolution: 1024x1024
        seed: optional

Важно: это не готовый стандарт, а минимальный скетч структуры для обсуждения.

Здесь пока нет:

• механики разрешения конфликтов,

• модели исполнения,

• security layer,

• стратегии версионирования,

• механизма валидации,

• способа обработки ошибок.

Но даже этот скелет уже лучше, чем обсуждать "протокол" без полей, по которым можно спорить и дополнять предложение.

Что можно собрать уже сейчас

Минимальный MVP такого протокола — это не новая платформа, а набор очень скучных вещей:

1. JSON/YAML-схема маршрута
Чтобы можно было описать цепочку обработки формально.

2. CLI-валидатор
Чтобы проверять маршрут на соответствие схеме.

3. Reference converter
Например, импорт из ComfyUI workflow в route.yaml.

4. Manifest результата
Чтобы вместе с итоговым артефактом сохранялись:

• author,

• model chain,

• provenance,

• license,

• параметры запуска.

5. Публичный репозиторий спецификации
С примерами, тестами и обратной связью от людей, которые реально строят пайплайны.

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

Экономика должна быть в ДНК формата

Самая неприятная ошибка интернета была не техническая, а архитектурная.

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

Из-за этого позже пришлось наращивать поверх протокола авторское право, платформенные комиссии и DRM.

С ИИ есть риск повторить ту же ошибку.

Если в протоколе маршрута с самого начала нет полей для автора, лицензии, attribution, распределения долей, провенанса и возможной оплаты, потом это будет почти невозможно добавить без боли, потерь и сломанной совместимости.

Важно: я не говорю про web3-евангелизм и не предлагаю спасать всё блокчейном. Тут не нужен культ. Нужна архитектурная трезвость.

Можно использовать:

• DID (Decentralized Identifiers),

• кошельки,

• подписи,

• provenance chains,

• optional payments,

• любые аккуратные механизмы атрибуции.

Но это должно быть подчинено протоколу, а не наоборот.

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

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

Что конкретно не хватает Hugging Face

Hugging Face действительно близок: Hub стал одной из главных точек сборки моделей, датасетов, Spaces и API, недавно добавили MCP-интеграцию.

Но не хватает трёх вещей:

1. Экономического слоя
У Hugging Face есть бесплатные и open слои, но это не экономика маршрутов. Создатель workflow или маршрута не получает встроенного механизма attribution и распределения ценности просто потому, что его цепочка оказалась полезной. Протокол без экономики — это RSS. Работает, пока кто-то добровольно поддерживает. Потом умирает или поглощается.

2. Децентрализованного управления
Hugging Face — центральная платформа. Они решают что остаётся, что удаляется. Это очень добрый феодал. Добрый феодал всё равно феодал.

3. Стандарта на маршруты
Hugging Face хранит модели и даёт к ним доступ. Но как одна модель передаёт результат другой, в каком формате, с каким контекстом, как фиксируется provenance, как учитывается вклад — этого стандарта нет. Каждый строит свои трубы сам.

Лакуна конкретная: не хранилище моделей, а открытый стандарт на маршруты между ними с встроенной экономикой и без центра.

Одиночка может создать мир, но не может удержать его жизнь

Одиночки всегда создавали миры: Толкин, Лавкрафт, Герберт, Лем.

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

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

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

Но управлять живым миром — миром, в котором тысячи людей живут, генерируют, обсуждают — одиночка не может.

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

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

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

Дракон не смог колонизировать этот мир полностью именно потому, что протокол был открыт до того, как дракон успел.

Мы сейчас в окне возможностей

Прямо сейчас инструменты доступны, платформы конкурируют, open source существует, контроль не консолидирован.

Классическая ситуация: пока старый дракон судится с новым, есть время строить инфраструктуру, которая не принадлежит ни одному из них. Параллельно идут иски со стороны крупных медиакомпаний против ИИ-сервисов по поводу авторских прав и использования персонажей и франшиз. Это может ускорять интерес к локальным и open source-инструментам, но это не автоматический закон истории.

Судебные войны копирайта объективно толкают в сторону open source. ComfyUI, Stable Diffusion, локальные LLM — это не просто технический выбор, это политический жест. Люди строят гаражи, которые не арендованы.

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

Может ли один человек показать фильм миллиону людей, не отдав копеечку дракону? Сегодня — пока нет.

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

Что строить практически

Нам нужен не союз творцов (который быстро станет платформой), а открытый стандарт маршрутов между моделями, с provenance, лицензированием и встроенной, но опциональной экономикой.

Не платформа.
Не новый «маркетплейс для креаторов».
Не союз, который через год сам станет драконьей администрацией.

А протокол.

Минимальный набор того, что должен описывать маршрут:

• input schema,

• output schema,

• model id,

• parameters,

• provenance chain,

• license,

• author (DID или кошелёк),

• cost / credits (опционально),

• validation status.

Что это не решает:

• модерацию,

• discovery,

• adoption,

• монополию на вычисления,

• гарантию качества.

Это не магия, а инфраструктурный слой.

Вопрос к сообществу

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

Вопросы:

• кто уже делает что-то близкое?

• какие проекты ближе всего к этой идее?

• где я ошибаюсь архитектурно?

• что здесь уже решено, а что я по инерции считаю нерешённым?

• существует ли вообще шанс сделать маршрут между моделями открытым протоколом, а не очередной платформой?

Если у вас есть примеры, ссылки, возражения или уже готовые куски такой инфраструктуры — покажите. Это как раз тот случай, когда карта важнее красивого тезиса.