Comments 6
У glm для подписчиков уже есть vision MCP - https://docs.z.ai/devpack/mcp/vision-mcp-server
Прогнал те же тесты на этом облачном MCP и вот что думает Опус:
Главный вывод (4-way сравнение, kombo dataset, 10 скриншотов):
Локальная модель после тюнинга слегка обходит zai по агрегату — за счёт более надёжной схемы (100% валидного JSON), лучшей детекции клиппинга (9/10 vs 7/10) и стабильного extract_table (4×3 каждый раз).
Зато zai лучше на двух нишевых вещах: пер-карточные пастельные цвета step-карточек (shot 09 — фронтир-уровень, единственный кто поймал все 4 оттенка отдельно) и точная разбивка mobile H1 на wrap-строки (shot 07 — ровно 4 строки, как у Opus).
Остаточный разрыв до фронтира одинаков у обоих VLM и сидит в трёх местах: тонкая цветовая дискриминация (eyebrow "FOR TEACHERS" — серый, не фиолетовый; текст "Start playing" — почти чёрный, не белый), точный подсчёт wrap-строк на mobile, и инференс design-intent (понимание, что "FOR TEACHERS" — намеренно приглушённая "coming soon" карточка). Это территория, где пока нужен только фронтир.
Практический вывод: для batch-извлечения текста и таблиц со скриншотов локальная после тюнинга — рациональный default. Cloud-VLM (zai/GLM) — разумный fallback с похожей точностью; фронтир (Opus) — когда критичны цветовые нюансы, точная типографика wrap или комментарий о замысле дизайнера.
Вы не видеть ее научили, а озвучили скриншоты для по прежнему слепой модели...
Но задача, несомненно, полезная и интересная, плюсую)
Могу ошибаться, но насколько я представляю, vision у того же Opus устроен примерно так: vision encoder (ViT) обрабатывает пиксели, превращает их в visual tokens, projection module маппит их в embedding space языковой модели, и дальше LLM работает с ними как с обычными текстовыми токенами. Сама языковая модель пиксели не видит, она тоже «слепая», за неё видит encoder.
Вот хороший survey на эту тему: jina.ai/vision-encoder-survey.pdf (Jina AI / Elastic, Feb 2026, 70+ моделей) — на первой странице покана эта в общем-то каноническая архитектура. Кстати, Anthropic не раскрывает детали своего vision encoder, но авторы survey прямо намекают: архитектура у всех одна.
Я этот процесс повторил в приближении, вынеся encoder в отдельный сервис через MCP. Да, не без компромиссов — JSON-описание беднее чем сырые embeddings, есть потери в bandwidth. Но принцип тот же :)
Поэтому соглашусь с вами лишь частично. Модель как была слепа, так и осталась - да. НО! у неё появился вполне зрячий поводырь. Но это уже детали, не сильно интересные более широкой аудитории)
Спасибо за плюс и за комментарий!
Бонусный факт из статьи: qwen3-vl (та самая модель что у меня в sidecar) использует SigLIP 2 SO400M как vision encoder - 400M параметров. То есть из 8B параметров qwen3-vl только 400M — это «глаза», остальные 7.6B - «мозги». В общем вполне себе академичный подход даже оказывается :)
получилось что-то типа читалки экрана для слепых людей. мне тоже понравилось, пусть решение и нишевое, но в принципе определенные потребности может закрыть.
Оказывается у вендора ровно такой же родной, еще и по качеству он оказалось не сильно превосходит мою самоделку https://habr.com/ru/articles/1029682/#comment_29906338
У glm для подписчиков уже есть vision MCP - https://docs.z.ai/devpack/mcp/vision-mcp-server
О, спасибо, я пропустил совершенно! Если честно, я даже рад что переизборел велосипед в некотором смысле. Во-первых, гам взята как поулярная модель, если и другие аналоги на том же free-tier без вожена. Это отличное подтверждение и валидация подхода, Во-вторых, остается ценность и применимость эксперимента на локальной модели. Ключи и подписка на ГЛМ есть не всех. Потестирую еще и против родного MCP.
Прогнал те же тесты на этом облачном MCP и вот что думает Опус:
Главный вывод (4-way сравнение, kombo dataset, 10 скриншотов):
Локальная модель после тюнинга слегка обходит zai по агрегату — за счёт более надёжной схемы (100% валидного JSON), лучшей детекции клиппинга (9/10 vs 7/10) и стабильного extract_table (4×3 каждый раз).
Зато zai лучше на двух нишевых вещах: пер-карточные пастельные цвета step-карточек (shot 09 — фронтир-уровень, единственный кто поймал все 4 оттенка отдельно) и точная разбивка mobile H1 на wrap-строки (shot 07 — ровно 4 строки, как у Opus).
Остаточный разрыв до фронтира одинаков у обоих VLM и сидит в трёх местах: тонкая цветовая дискриминация (eyebrow "FOR TEACHERS" — серый, не фиолетовый; текст "Start playing" — почти чёрный, не белый), точный подсчёт wrap-строк на mobile, и инференс design-intent (понимание, что "FOR TEACHERS" — намеренно приглушённая "coming soon" карточка). Это территория, где пока нужен только фронтир.
Практический вывод: для batch-извлечения текста и таблиц со скриншотов локальная после тюнинга — рациональный default. Cloud-VLM (zai/GLM) — разумный fallback с похожей точностью; фронтир (Opus) — когда критичны цветовые нюансы, точная типографика wrap или комментарий о замысле дизайнера.
z.ai GLM 5.1: Как я научил слепую модель видеть