Forwarded from Нейроканал
Вот уж не думал, что этот бенчмарк реально будет обновляться. Ждём GPT-5.6 и Fable 5, вроде говорят есть шанс, что на этой неделе откроют для всех.
@neuro_channel
@neuro_channel
Forwarded from AI-Driven Development. Родион Мостовой
1М контекстное окно - прорыв или фикция?
Context Arena забенчмаркали стойкость контекста для GLM 5.2 и Opus 4.8 - значит, это хороший повод нам вспомнить про контекстную инженерию.
На бенчмарке отчетливо видна существенная просадка внимательности моделей на 512к контексте: в среднем, почти в 2 раза в сравнении с 64к контекстом и примерно в 1.5 раз в сравнении с 128к контекстом - грубо говоря, для нас с вами это означает то, что на 512к контексте агент будет терять в полтора раза больше деталей, чем на при 128к заполненности. Для открытых моделей проблема потери контекста особенно актуальна, поэтому практический вывод такой, что по-хорошему, с ними стоит держать заполненность контекстного окна не выше 128к, а лучше даже меньше - ни о каком 1М, конечно, и речи не идет, там просадка будет колоссальной. Кстати, у моделей Kimi K2.6 и, тем более, Minimax M3 дела обстоят еще хуже.
Что еще? Открыв закрытых моделей на большом контексте от открытых все еще впечатляет, хоть уже и не такой драматичный - спасибо DeepSeek за DeepSeek Sparse Attention, которую в GLM-5.2 развили через IndexShare. Кстати, о GLM 5.2 - как видно, моделька действительно на удивление успешная в т. ч. на больших контекстах. Opus 4.8 идет рядышком с GPT 5.5, но последняя все равно сильнее, особенно на совсем больших контекстах. На этом месте вспоминаем интересную деталь - в Codex App по дефолту контекстное окно для GPT 5.5 все еще 256к - то есть, по сути, точность всегда остается где-то на уровне 75%+- (по MRCRv2), а благодаря превосходному алгоритму компактизации, команде Codex удается сохранить все действительно важное так, что эти компактизации обычно и не заметны вовсе - то есть, конкретно в случае с Codex проблему контекстной инженерии ребята здорово решили на уровне модели и на уровне Harness (обвязки), в то время, как Claude Code в этом аспекте требует чуть больше ручной работы - модель на 1M контекста там включается прямо в выпадающем списке (велик соблазн ее включить), но кажется, что простой обыватель зачастую не очень понимает, что переключение на эту модель потребует от него ручного управления контекстом - как только контекст переваливает за условные 200к, начинается зона риска, в которой нужно либо переходить в новый чат, либо, хотя бы, вызывать компактизацию - что и приходилось делать. Что уж говорить, что пользователям открытых моделей за загрузкой контекста все еще стоит следить куда пристальнее. Короче, в 2026-м контекстную инженерию (в которую входит контроль % заполнения контекстного окна) пока никто не отменял - чем больше забит контекст, тем сильнее приходится надеятся на удачу.
И, конечно, не забываем про контроль AGENTS.md, скиллов, MCP, progressive disclosure и т. д. - тоже все составляющие context engineering, с открытыми моделями все это становится еще важнее.
Кстати, современная версия Context Arena прогоняет бенчмарк MRCRv2 от Google DeepMind (GDM-MRCRv2).
Paper про MRCRv2 (Michelangelo)
Датасет MRCRv2
А как вы менеджите контекст? Обращаете ли внимание на % заполнения? Наблюдаете ли просадки в качестве output модели на больших контекстах?
@ai_driven
Context Arena забенчмаркали стойкость контекста для GLM 5.2 и Opus 4.8 - значит, это хороший повод нам вспомнить про контекстную инженерию.
На бенчмарке отчетливо видна существенная просадка внимательности моделей на 512к контексте: в среднем, почти в 2 раза в сравнении с 64к контекстом и примерно в 1.5 раз в сравнении с 128к контекстом - грубо говоря, для нас с вами это означает то, что на 512к контексте агент будет терять в полтора раза больше деталей, чем на при 128к заполненности. Для открытых моделей проблема потери контекста особенно актуальна, поэтому практический вывод такой, что по-хорошему, с ними стоит держать заполненность контекстного окна не выше 128к, а лучше даже меньше - ни о каком 1М, конечно, и речи не идет, там просадка будет колоссальной. Кстати, у моделей Kimi K2.6 и, тем более, Minimax M3 дела обстоят еще хуже.
Что еще? Открыв закрытых моделей на большом контексте от открытых все еще впечатляет, хоть уже и не такой драматичный - спасибо DeepSeek за DeepSeek Sparse Attention, которую в GLM-5.2 развили через IndexShare. Кстати, о GLM 5.2 - как видно, моделька действительно на удивление успешная в т. ч. на больших контекстах. Opus 4.8 идет рядышком с GPT 5.5, но последняя все равно сильнее, особенно на совсем больших контекстах. На этом месте вспоминаем интересную деталь - в Codex App по дефолту контекстное окно для GPT 5.5 все еще 256к - то есть, по сути, точность всегда остается где-то на уровне 75%+- (по MRCRv2), а благодаря превосходному алгоритму компактизации, команде Codex удается сохранить все действительно важное так, что эти компактизации обычно и не заметны вовсе - то есть, конкретно в случае с Codex проблему контекстной инженерии ребята здорово решили на уровне модели и на уровне Harness (обвязки), в то время, как Claude Code в этом аспекте требует чуть больше ручной работы - модель на 1M контекста там включается прямо в выпадающем списке (велик соблазн ее включить), но кажется, что простой обыватель зачастую не очень понимает, что переключение на эту модель потребует от него ручного управления контекстом - как только контекст переваливает за условные 200к, начинается зона риска, в которой нужно либо переходить в новый чат, либо, хотя бы, вызывать компактизацию - что и приходилось делать. Что уж говорить, что пользователям открытых моделей за загрузкой контекста все еще стоит следить куда пристальнее. Короче, в 2026-м контекстную инженерию (в которую входит контроль % заполнения контекстного окна) пока никто не отменял - чем больше забит контекст, тем сильнее приходится надеятся на удачу.
И, конечно, не забываем про контроль AGENTS.md, скиллов, MCP, progressive disclosure и т. д. - тоже все составляющие context engineering, с открытыми моделями все это становится еще важнее.
Кстати, современная версия Context Arena прогоняет бенчмарк MRCRv2 от Google DeepMind (GDM-MRCRv2).
Paper про MRCRv2 (Michelangelo)
Датасет MRCRv2
А как вы менеджите контекст? Обращаете ли внимание на % заполнения? Наблюдаете ли просадки в качестве output модели на больших контекстах?
@ai_driven
Там уже пару часов идёт стрим Константина Доронина и EvilFreelancer-а. Смотрю немного в прошлом на x1.25 )
Forwarded from Константин Доронин
Мы начинаем наш стрим "Что же такое Harness?"
Подключайтесь по ссылке: https://youtube.com/live/IvTYyABCQxo?feature=share
Подключайтесь по ссылке: https://youtube.com/live/IvTYyABCQxo?feature=share
Youtube
- YouTube
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
Forwarded from AI for Devs
⚡️ Grok 4.5 вышел в приватную бету в SpaceX и Tesla
В основе Grok 4.5 лежит V9: новая модель, которую xAI обучали с нуля вместе с инженерами из Cursor на их данных.
Модель втрое больше предыдущей: 1.5 триллиона параметров против 0.5T у v8-small (Grok 4.3), которая сейчас обслуживает весь продакшен трафик.
Илон обещает по одной новой модели в месяц от SpaceX. То есть в паблик Grok 4.5 должен выйти уже в июле!
Параллельно xAI развивает Grok Build (собственный инструмент для кодинга), конкурент того же Cursor. Маск говорит, что он становится лучше с каждым днём. Делаем ставки, кого из них в итоге принесут в жертву?
@ai_for_devs
В основе Grok 4.5 лежит V9: новая модель, которую xAI обучали с нуля вместе с инженерами из Cursor на их данных.
Модель втрое больше предыдущей: 1.5 триллиона параметров против 0.5T у v8-small (Grok 4.3), которая сейчас обслуживает весь продакшен трафик.
Макс отметил, что данные Cursor добавили уже после основного этапа (это менее эффективно, чем с нуля). В следующей версии на 2T параметров они войдут с самого начала.
Илон обещает по одной новой модели в месяц от SpaceX. То есть в паблик Grok 4.5 должен выйти уже в июле!
Параллельно xAI развивает Grok Build (собственный инструмент для кодинга), конкурент того же Cursor. Маск говорит, что он становится лучше с каждым днём. Делаем ставки, кого из них в итоге принесут в жертву?
@ai_for_devs
Forwarded from Технозаметки Малышева
DeepSeek напомнил, что мы используем Preview версию, а полноценный Дипсик мы еще даже не видели, - он выйдет в середине июля и в нем будет еще больше крутых фич и улучшенная производительность.
И это повлияет на цену.
Обычная цена останется $0.87 за 1 млн в Про версии, а вот в час пик цена вырастет до $1.74
#DeepSeek #цены
———
@tsingular
И это повлияет на цену.
Обычная цена останется $0.87 за 1 млн в Про версии, а вот в час пик цена вырастет до $1.74
#DeepSeek #цены
———
@tsingular
Forwarded from Технозаметки Малышева
Akrites: крупнейшая коалиция в истории для защиты открытого кода
📋 Что произошло
25 июня Linux Foundation запустила Akrites — крупнейшую в истории программу скоординированного поиска, исправления и ответственного раскрытия уязвимостей в критическом открытом ПО. Участники: Amazon, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft и GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone, Zscaler — плюс CNCF, LF Energy, OpenInfra, OpenJS, OpenSSF и PyTorch Foundation.
💡 Почему это важно
Появление сильных ИИ-моделей изменило цикл поиска уязвимостей в открытом коде. То, на что раньше уходили недели работы эксперта, теперь делается за минуты, причём модель часто находит несколько уязвимостей одновременно.
Цикл «обнаружение → исправление» ускорился настолько, что мейнтейнеры физически не успевают закрывать дыры.
Anthropic в этой коалиции занимает особое место, - их модель Claude Mythos в рамках Project Glasswing просканировала более тысячи открытых проектов и нашла 23 019 проблем, из которых 6 202 — высокой и критической тяжести.
Разработчикам передано 1 596 отчётов, а исправлено всего 97!!!
Именно этот разрыв между скоростью обнаружения и скоростью устранения стал отправной точкой для запуска Akrites.
💼 Как это работает
Во-первых у альянса будет единое конфиденциальное пространство: уязвимости не раскрываются публично до появления исправления.
Во-вторых, принцип upstream-first: все правки вносятся в исходные репозитории. Специализированная группа реагирования работает как единый партнёр для мейнтейнеров.
В третьих, - ключевая метрика безопасности оупенсорс репозитория станет не публикация патча, а его развёртывание у потребителей.
Для пакетов без активного сопровождения Akrites выполняет роль «последней надежды».
📎 Ссылки
https://akrites.org/letter/
https://www.anthropic.com/news/project-glasswing-may-2026
#Akrites #OpenSource #CyberSecurity
———
@tsingular
📋 Что произошло
25 июня Linux Foundation запустила Akrites — крупнейшую в истории программу скоординированного поиска, исправления и ответственного раскрытия уязвимостей в критическом открытом ПО. Участники: Amazon, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft и GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone, Zscaler — плюс CNCF, LF Energy, OpenInfra, OpenJS, OpenSSF и PyTorch Foundation.
💡 Почему это важно
Появление сильных ИИ-моделей изменило цикл поиска уязвимостей в открытом коде. То, на что раньше уходили недели работы эксперта, теперь делается за минуты, причём модель часто находит несколько уязвимостей одновременно.
Цикл «обнаружение → исправление» ускорился настолько, что мейнтейнеры физически не успевают закрывать дыры.
Anthropic в этой коалиции занимает особое место, - их модель Claude Mythos в рамках Project Glasswing просканировала более тысячи открытых проектов и нашла 23 019 проблем, из которых 6 202 — высокой и критической тяжести.
Разработчикам передано 1 596 отчётов, а исправлено всего 97!!!
Именно этот разрыв между скоростью обнаружения и скоростью устранения стал отправной точкой для запуска Akrites.
💼 Как это работает
Во-первых у альянса будет единое конфиденциальное пространство: уязвимости не раскрываются публично до появления исправления.
Во-вторых, принцип upstream-first: все правки вносятся в исходные репозитории. Специализированная группа реагирования работает как единый партнёр для мейнтейнеров.
В третьих, - ключевая метрика безопасности оупенсорс репозитория станет не публикация патча, а его развёртывание у потребителей.
Для пакетов без активного сопровождения Akrites выполняет роль «последней надежды».
📎 Ссылки
https://akrites.org/letter/
https://www.anthropic.com/news/project-glasswing-may-2026
#Akrites #OpenSource #CyberSecurity
———
@tsingular
Про мета-репозитории
Когда один человек работает с кодинг-агентом над одним проектом, никаких проблем с контекстом нет: накидал
Хочется это всё централизовать.
С начала марта пробую подход, который назвал мета-репозиторий. Фактически, это просто отдельный git-репозиторий, в котором лежат:
- .gitignore, который не даёт закоммитить ничего лишнего (
-
-
-
-
OpenCode умеет в конфиге указать дополнительные файлы с инструкциями, и я прописал туда
Про MCP тут нечего добавить, во внутреннем контуре компании у нас развёрнуты несколько внешних и самописных MCP-серверов, они прячут за собой токены к разным сервисам (Jira, Confluence, GitLab, мессенджеры), чтобы они никогда не попадали в модели. При этом в каких-то сервисах может быть сделано наоборот – токен от очень ограниченной в правах учётки зашит в конфиг мета-репозитория. А про самописные MCP-сервера будут попозже отдельные посты.
Когда один человек работает с кодинг-агентом над одним проектом, никаких проблем с контекстом нет: накидал
AGENTS.md, какие-то rules, project-specific конфиги, и работаешь. Когда людей больше одного, проблем тоже нет – ведь есть git и удалённый GitHub/GitLab. Когда людей и репозиториев в команде много, начинают подсвечиваться узкие места: немного разное окружение (ОС, расположение разных версий JDK), разные версии навыков, разные MCP.Хочется это всё централизовать.
С начала марта пробую подход, который назвал мета-репозиторий. Фактически, это просто отдельный git-репозиторий, в котором лежат:
- .gitignore, который не даёт закоммитить ничего лишнего (
/* ). Всё, что должно быть в него добавлено, добавляется принудительно руками.-
AGENTS.md с кратким описанием всего проекта и верхнеуровневой навигацией.-
REPOSITORIES.md – сопоставление названий микросервисов, url в GitLab и имён локальных клонов (они все клонируются для работы прямо в мета-репо).-
TEAM_MEMBERS.md – потому что если сценарии, где агенту полезно понимать, с кем он работает. ФИО, должность, почта, ники в GitLab и мессенджерах.-
.opencode/ – настройки MCP, навыки и субагенты, специфичные для этого проекта. О том, почему мы держим вектор на opencode, а не Claude Code / Codex, как-нибудь в следующих постах.OpenCode умеет в конфиге указать дополнительные файлы с инструкциями, и я прописал туда
ENVIRONMENT.md – файл, который не коммитится в git. В AGENTS.md агенту явно сказано, что если файла нет, перед выполнением задачи пользователя нужно прочитать отдельный файл с инструкциями по его составлению и заполнить, а потом вернутся к задаче. Шаблон помогает агенту сразу понять, в какой ОС он работает, какой shell доступен, где лежат разные рантаймы и каких они версий, наработанные нюансы (многие модели запинаются на правильном вызове сложных команд в PowerShell). Также я добавил туда описание сценария, при котором агент понимает, что мой ввод – это результат голосового распознавания, и должен сперва подбить выжимку из того, что я сказал, и переспросить, верно ли он меня понял. А ещё туда скопирована строчка из TEAM_MEMBERS.md, и агент понимает, кто его пользователь, что это мои треды он видит в MR, который мы вместе ревьюим.Про MCP тут нечего добавить, во внутреннем контуре компании у нас развёрнуты несколько внешних и самописных MCP-серверов, они прячут за собой токены к разным сервисам (Jira, Confluence, GitLab, мессенджеры), чтобы они никогда не попадали в модели. При этом в каких-то сервисах может быть сделано наоборот – токен от очень ограниченной в правах учётки зашит в конфиг мета-репозитория. А про самописные MCP-сервера будут попозже отдельные посты.
Reality_AI
Про мета-репозитории Когда один человек работает с кодинг-агентом над одним проектом, никаких проблем с контекстом нет: накидал AGENTS.md, какие-то rules, project-specific конфиги, и работаешь. Когда людей больше одного, проблем тоже нет – ведь есть git и…
Да, ещё забыл добавить, модельки не всегда следуют командам к действию из инструкции, стараются сразу перейти к тому, о чём попросил пользователь. Но время от времени всё-таки это срабатывает. Перебирая разные варианты хочется всегда последний отдать сразу команде, и поначалу я просто просил всех подпулливать мета-репо.
Но потом просто дописал команду агенту делать git pull, так что ещё одним ручным действием меньше.
Но потом просто дописал команду агенту делать git pull, так что ещё одним ручным действием меньше.
Forwarded from Этихлид
Перевёл документ от Google, который описывает текущую ситуацию по переходу от "бессистемных промптов к агентной инженерии":
➡️ Новый SDLC с вайб-кодингом
Это первый, самый общий и концептуальный, из пяти whitepaper'ов бесплатного курса 5-Day AI Agents: Intensive Vibe Coding Course от Google и Kaggle.
Бонусом там ещё и глоссарий терминов/переводов получился.
Это база
В нём качественно суммируется то, что разработка ПО прошла за последние 2-3 года, описываются появившиеся концепции и систематизируются основные рабочие подходы.
Даётся, к примеру, разделение вайб-кодинга и агентной инженерии, фиксируются определения агента / харнесса / дирижера / оркестратора и показывается, как устроена capex/opex-экономика разных подходов к ИИ-разработке.
Для разработчиков и лидов может быть полезным почитать, чтобы понять, на каком этапе развития находятся они сами или команда, и как переходить на следующий.
Документ лайтовый, без лишнего хайпа и думеризма.
Ну и картинки интересные :)
Замечания
● eсли вы уже по уши в мультиагентных воркфлоу, бандлах скиллов и прочих гермесах, то нового вы в нём вряд ли почерпнёте - коммьюнити стабильно на шаг-другой впереди :)
● это всё-таки Google с его собственным зоопарком (Jules, ADK, Agents CLI, Gemini, A2A), хотя авторы проделали хорошую работу по абстракции от него
● местами чутка оптимистичнее, чем стоило бы: мультиагентность как "естественный следующий шаг" - тут можно спорить об эффективности, да модели пока что не готовы
—
Ссылки на оригиналы всех пяти документов с конкретикой для тех, кто хочет углубиться:
● The New SDLC With Vibe Coding (переведён)
● Agent Tools & Interoperability
● Agent Skills
● Vibe Coding Agent Security and Evaluation
● Spec-Driven Production Grade Development in the Age of Vibe Coding
#article #translation #sdlc #ai
Это первый, самый общий и концептуальный, из пяти whitepaper'ов бесплатного курса 5-Day AI Agents: Intensive Vibe Coding Course от Google и Kaggle.
Бонусом там ещё и глоссарий терминов/переводов получился.
Это база
В нём качественно суммируется то, что разработка ПО прошла за последние 2-3 года, описываются появившиеся концепции и систематизируются основные рабочие подходы.
Даётся, к примеру, разделение вайб-кодинга и агентной инженерии, фиксируются определения агента / харнесса / дирижера / оркестратора и показывается, как устроена capex/opex-экономика разных подходов к ИИ-разработке.
Для разработчиков и лидов может быть полезным почитать, чтобы понять, на каком этапе развития находятся они сами или команда, и как переходить на следующий.
Документ лайтовый, без лишнего хайпа и думеризма.
Ну и картинки интересные :)
Замечания
● eсли вы уже по уши в мультиагентных воркфлоу, бандлах скиллов и прочих гермесах, то нового вы в нём вряд ли почерпнёте - коммьюнити стабильно на шаг-другой впереди :)
● это всё-таки Google с его собственным зоопарком (Jules, ADK, Agents CLI, Gemini, A2A), хотя авторы проделали хорошую работу по абстракции от него
● местами чутка оптимистичнее, чем стоило бы: мультиагентность как "естественный следующий шаг" - тут можно спорить об эффективности, да модели пока что не готовы
—
Ссылки на оригиналы всех пяти документов с конкретикой для тех, кто хочет углубиться:
● The New SDLC With Vibe Coding (переведён)
● Agent Tools & Interoperability
● Agent Skills
● Vibe Coding Agent Security and Evaluation
● Spec-Driven Production Grade Development in the Age of Vibe Coding
#article #translation #sdlc #ai
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Ссылка на папку с каналами и чатами про ИИ, которые я сам почитываю. Последние месяцы добавлений в неё мало, но если случаются, ссылка остаётся прежней.
https://t.me/addlist/6_Forw9aLD0zYmY6
Можете не добавлять, всё самое сочное будет здесь :)
https://t.me/addlist/6_Forw9aLD0zYmY6
Можете не добавлять, всё самое сочное будет здесь :)
Telegram
ИИ 🤖
You’ve been invited to add the folder “ИИ 🤖”, which includes 38 chats.
Сначала мэрия Рио-де-Жанейро, теперь сервис доставки еды...
Telegram
Технозаметки Малышева
🇧🇷 Мэрия Рио-де-Жанейро (через свою муниципальную ит-компанию IplanRIO) только что выпустила модель под названием Rio 3.5 Open 397B
Модель с 397 миллиардами параметров (MoE), основанная на Qwen 3.5, с полностью открытой лицензией MIT, которая превосходит…
Модель с 397 миллиардами параметров (MoE), основанная на Qwen 3.5, с полностью открытой лицензией MIT, которая превосходит…
Forwarded from Нейроканал
Meituan (крупнейший в Китае сервис доставки еды и услуг, у которого есть и собственное ИИ-подразделение) выложила в открытый доступ LongCat-2.0 — MoE-модель на 1,6 триллиона параметров, из которых на каждый токен работают около 48 миллиардов. Веса уже на Hugging Face, а саму модель обучили целиком на китайских ASIC-ускорителях, без единого отката за 35 триллионов токенов обучения.
Модель заточена под программирование и работу агентов, окно контекста в 1 миллион токенов. Её можно подключить к агентским средам Claude Code, OpenClaw и Hermes вместо закрытых моделей.
На задачах по коду LongCat идёт вровень с закрытыми флагманами: 59,5 на SWE-bench Pro, 77,3 на многоязычном SWE-bench, 70,8 на Terminal-Bench. Ещё до релиза модель успела возглавить рейтинг OpenRouter под кодовым именем «Owl Alpha».
Под капотом два приёма ради скорости на длинном контексте: LongCat Sparse Attention (развитие разреженного внимания из DeepSeek с более лёгким индексатором) и N-gram Embedding, который кодирует не только отдельные токены, но и короткие сочетания соседних токенов — так модель лучше улавливает локальный контекст.
@neuro_channel
Модель заточена под программирование и работу агентов, окно контекста в 1 миллион токенов. Её можно подключить к агентским средам Claude Code, OpenClaw и Hermes вместо закрытых моделей.
На задачах по коду LongCat идёт вровень с закрытыми флагманами: 59,5 на SWE-bench Pro, 77,3 на многоязычном SWE-bench, 70,8 на Terminal-Bench. Ещё до релиза модель успела возглавить рейтинг OpenRouter под кодовым именем «Owl Alpha».
Под капотом два приёма ради скорости на длинном контексте: LongCat Sparse Attention (развитие разреженного внимания из DeepSeek с более лёгким индексатором) и N-gram Embedding, который кодирует не только отдельные токены, но и короткие сочетания соседних токенов — так модель лучше улавливает локальный контекст.
@neuro_channel