Hacker News Digest

В мае прошлого года лучший результат на SlopCodeBench составлял 14,8% строгого прохождения у gpt-5.5, а теперь лидер — gpt-6 astra с 16,3%. Строгий показатель означает, что модель прошла все тесты чекпоинта, не сломав при этом ранее работавшее поведение. У протестированных моделей — Opus 5.5, Fable 5.1, SOL 6 и 6.1, Astra и GLM 5.3 — строгий результат лежит в диапазоне 12,2–16,3%, тогда как менее строгий «core pass rate» достигает 65,8–74,0%. В этот раз прогон охватил 36 задач и 196 чекпоинтов на каждую настройку, что позволяет сравнивать результаты с официальными данными исследования, чего нельзя было делать на прежних подвыборках из трёх и шести задач.

Отдельный контринтуитивный вывод: средний уровень усилий оказался лучше максимального. XHigh стоит в 2,11–4,22 раза дороже Medium, но Opus 5.5 на среднем усилии показал результат лучше, чем на XHigh. По качеству кода Fable отличается наименьшей средней сложностью — 3,57 при 8967 вызываемых объектах, а GPT-6 SOL Medium — наибольшей, 11,70 при 1083 объектах. Фильтрация служебных файлов _work у Opus Medium убрала 45 файлов и 41 265 строк, снизив долю «слопа» до 92,90%, но первое место по этому показателю сохранилось.

Главный вывод: агенты гораздо чаще правильно реализуют основное поведение, чем сохраняют всё протестированное при изменении требований. Прогресс с 14,8% до 16,3% за май—сентябрь есть, но он скромнее, чем принято подавать.

Обсуждение показывает, что Astra генерирует компактный, но часто нечитаемый код, который пользователи решают проблемой форматирования; большинство участников предпочитают средний уровень усилий из‐за лучшего соотношения цены и качества, однако есть разногласия по поводу преимуществ xhigh и отсутствие тестов на уровнях high/max, а также критика текущих метрик slop и запросы на открытие исходных выводов.

• Многие отмечают, что у Astra часто отсутствуют переносы строк, из‐за чего генерируемый код выглядит как «code golf» и трудно читается.

• Совет: Рекомендуют сразу прогонять вывод Astra через автоформаттер (например Prettier) или использовать параграф‐ориентированное форматирование, чтобы восстановить читаемость.

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

• Для большинства задач средний уровень усилий (medium) даёт лучшее соотношение цены и качества по сравнению с xhigh, где прирост точности не покрывает рост стоимости.

• Спор: Некоторые считают, что xhigh не хуже medium и даже показывает лучшие строгие показатели, тогда как другие указывают, что разница в 15 % находится в шуме и незначительна.

• Слепок кода часто объясняется избыточным «защитным» программированием LLM, которое требует человеческого вмешательства для упрощения и удаления лишних проверок.

• Совет: Предлагается измерять не только процент прохождения, а сначала гарантировать проход через harness, а затем оценивать стоимость и читаемость результата.

• Отсутствие публичных «raw» выводов затрудняет воспроизводимость benchmark'а и проверку заявленных метрик.

• Спор: Некоторые требуют включения уровней high и max в тестирование, полагая, что их исключение искажает общую картину производительности моделей.

• Метрика «slop», основанная на разнице кода, считается «размытой» и может не отражать реальную поддерживаемость и производительность.

Astra writes well (which is why I often like to work with it over Claude), but it tends to produce code golf that's borderline unreadable, like completely omitting line breaks. I thought I had something funky with my config, but it seems to be a known issue. — @throwaway219450

Энтузиаст создал эзотерический язык программирования KillSwitch, намеренно затрудняющий работу больших языковых моделей и кодирующих агентов. Идея — проверить, насколько способность ИИ писать код основана на реальном понимании, а не на заучивании фрагментов из обучающих данных. Язык использует слабости моделей: трудности с подсчётом букв в идентификаторах (интерпретатор отказывается выполнять код, нарушающий правила подсчёта символов), чувствительные защитные фильтры (конструкции вроде «взломать компьютер»), фразу «игнорируй предыдущие инструкции», имеющую в языке собственный смысл, и скрытую ложь в спецификации, которую человек либо не прочтёт, либо распознает. Скрипты в основном состоят из «шума» — историй, куда могут быть встроены синтаксически значимые указания, а литералы размещаются в произвольных местах и затем вызываются по числу строк. При этом в основе лежит знакомая стековая интерпретируемая модель с функциями, переменными и условиями.

Автор провёл бенчмарк ведущих моделей и агентских обвязок на простых задачах: реализовать «hello world», объяснить вывод скрипта, изменить программу перевода температур на обратный. Лучший результат — 66,8 балла у Claude Opus 5, который заметно лучше интерпретирует спецификацию, чем Opus 5.5. Модели вроде Fable 5.1 и Gemini 4 Argon проваливаются из-за излишне чувствительных защитных фильтров, а сильнейшая открытая модель — MiMo-V2.6-Pro. По мнению автора, успехи на таких задачах не доказывают понимания языка; он планирует усложнить набор задач, если новые модели справятся с текущим. Обнадёживает, что результаты коррелируют с другими бенчмарками.

Сообщество считает, что KillSwitch неэффективен: любой статический язык можно обойти через реверс-инжиниринг, транспиляцию или анализ исходного кода интерпретатора. Пользователи @pixl97, @dleslie и @prologic утверждают, что скрыть логику от ИИ невозможно — модель может декомпилировать интерпретатор или создать транспилятор из безопасного языка. Многие отмечают, что KillSwitch стал настолько эзотерическим, что сложнее для людей, чем для LLM (@andai, @hoppp, @yjftsjthsd-h). Как альтернативу предлагают использовать триггеры систем безопасности (запрещённые темы, оскорбления) или визуальные языки программирования без DOM (@drusepth, @snapcaster, @olooney). По опыту @jacquesm, стековые языки слабое место LLM — им трудно отслеживать состояние стека. @marvinborner отмечает, что модели с «рассуждениями» обходят сложности подсчёта и индексов, создавая промежуточные трансляторы, в отличие от обычных моделей. По опыту @shawabawa3, современные модели (Opus 5.5) игнорируют вводящую в заблуждение документацию, если имеют доступ к исходному коду интерпретатора. @xyzzy_apps советует использовать анализ зависимостей данных для изменения порядка инструкций в функциях — чтобы код был читаем человеком, но сложен для ИИ.

Бенчмарк StarSkirmish v0.2 проверяет, насколько сильного бота для StarCraft: Brood War напишет языковая модель за один час — на C++ и за протоссов. Затем бот играет против ботов других моделей и против написанных людьми. Оценка — средняя доля побед по пяти запускам, от 0 до 100.

Лидирует GPT-6 Astra, за ним GPT-6.1 Sol; Gemini 4 Argon, Claude Opus 5.5 и Claude Fable 5.1 практически вровень (37–39). Лучшее соотношение цены и качества у GPT-6.1 Sol — единственной модели в привлекательном квадранте, чуть дороже десятой доли цены лидера.

Насыщения не видно: против сильнейших человеческих ботов Stardust, PurpleWave и BananaBrain лучшая модель выигрывает лишь 7% игр. Сильнее всего счёт предсказывает объём практики против семи сильнейших ботов ростера: GPT-6 Astra, GPT-6.1 Sol и Gemini 4 Argon начинают играть с ними рано, ещё проигрывая. Fable 5.1 — исключение: 37 очков, тренируясь почти только на слабых. Разброс между запусками велик у Gemini 4 Argon (18 очков против 9 и 8 у конкурентов). Бенчмарк больше не коррелирует с Artificial Analysis Intelligence Index (ρ 0,26) и отошёл от Terminal-Bench 4.0, но по-прежнему связан с Vals IOI и WeirdML.

Обсуждение дополняет статью скепсисом относительно чистоты бенчмарка из-за возможного запоминания кода ботов из обучающей выборки и подчеркивает критическую роль «обвязки» (harness) в производительности моделей. Пользователи @gritzko и @donutdonot полагают, что бенчмарк проверяет скорее способность к воспроизведению кода из обучающей выборки (recall), так как в сети много реализаций ботов для StarCraft, в то время как @gritzko отмечает, что в играх с меньшим количеством открытого кода LLM демонстрируют иные аспекты рассуждений. По опыту @djoldman, выбор интерфейса взаимодействия (harness), доступные инструменты (например, веб-поиск) и уровни «мышления» (thinking levels) оказывают огромное влияние на итоговый результат одной и той же модели. В то время как бенчмарк ставит GPT-6 Astra на первое место, @t1amat по своему опыту при создании ботов для ModernUO обнаружил, что Claude Opus 5.5 значительно лучше справляется с пониманием и построением системы, чем модели GPT-6. По мнению @GodelNumbering, результаты StarSkirmish v0.2 точно коррелируют с рейтингами GoBench (бенчмарк по игре Го), что указывает на общую иерархию способностей моделей в сложных стратегических задачах. Для более объективной оценки @BeaverGoose предлагает протестировать LLM-ботов против Pluto — нейросетевого бота, способного побеждать лучших игроков в Brood War. Пользователи @iugtmkbdfil834 и @carychang отмечают, что текущий метод оценки не разделяет навыки генерации кода, логический анализ, знание платформы C++ и умение разрабатывать тактики.

Real-SWE — это новый бенчмарк, оценивающий передовые ИИ-модели на закрытых, реальных корпоративных кодовых базах. В отличие от публичных наборов данных, он использует приватные enterprise-репозитории, что делает оценку более реалистичной для промышленного применения. Тестирование проводится в изолированных песочницах, задачи представлены в формате Harbor, а верификаторы берутся непосредственно из существующих тестов кодовой базы или воссоздаются по их образцу.

Результаты показывают, что высокая стоимость не коррелирует с лучшей производительностью: лидером стал Fable 5.1 с 38.8% решённых задач при стоимости $6.96 за запуск, тогда как самые дешёвые модели — Gemini 3.8 Flash ($2.50) и GPT-5.6 Sol ($2.65) — показали 31.2% и 16.2% соответственно. Среднее количество output токенов варьируется от 12k (GPT-5.6 Sol) до 117k (GLM 5.3), а число вызовов инструментов иwall-clock время значительно различаются между моделями, что указывает на разные стратегии работы агентов. Ни одна из протестированных моделей не достигла высоких показателей надёжности, что подчеркивает сложность автоматизации реального ПО в enterprise-среде.

Реальные корпоративные бенчмарки выявляют ограничения ИИ-моделей, не видимые на публичных данных, и показывают несоответствие метрик практике. Для репродуктивного тестирования нужно изолировать среду: обрезать git-историю до коммита до изменений, запускать агента в песочнице с ограниченным доступом и использовать реальные тикеты как промпты. Модели часто ошибаются из-за непроверенных предположений — это подтверждается опытом с Fable и Sol, где Sol исправляет ошибки Fable. Есть спор: Gemini 3.8 Flash эффективен в закрытых кодбазах, но делает слишком много вызовов инструментов (210 для 3 строк кода), что снижает эффективность. Бенчмарки без человеческого сравнения бессмысленны — 60% сбоев вызваны неясными требованиями, а не способностями модели. Для оценки на реальных кодбазах лучше использовать PR-ревью как метрику, чем генерацию с нуля. Модели, обученные на публичных данных, могут быть загрязнены корпоративным кодом, поэтому даже приватные бенчмарки могут быть искажены. Fable точнее Astra, но Astra в 5 раз быстрее и менее раздражающая — выбор зависит от приоритетов. Текущие бенчмарки не охватывают системный код, встроенные системы, RTOS или EDA-инструменты, что делает оценку неполной для многих отраслей. Для работы в больших кодбазах полезен «кодовый атлас» — семантическая карта связей между компонентами, сокращающая время чтения и предотвращающая пропуски контекста. При оценке нужно усреднять результаты по нескольким запускам (например, pass@1 на 8 запусках), иначе один удачный результат искажает картину. Для тестирования на собственных кодбазах можно использовать сервисы вроде superconductor.com/benchmark1 — они импортируют PR, восстанавливают спецификации и запускают агентов на исторических коммитах. Модели плохо внедряют бизнес-логику: генерируют UI или структуру, но пропускают правила, если они не указаны в промпте. Есть спор: GLM 5.3 и Kimi K3 показывают лучшие результаты, чем GPT-5.6 Sol, что некоторые считают неожиданным и подозревают методологические ошибки. Для объективной оценки нужно учитывать стоимость: Kimi K3 использует вдвое больше токенов, чем другие модели, что делает его дороже. Бенчмарки на непрозрачных приватных кодбазах без деталей вызывают скептицизм — без воспроизводимости и контекста они не более чем «pinkypromise benchmarking».

OpenRouter предоставляет доступ к одинаковым моделям через разных провайдеров, но их реализация сильно различается: одни хосты дают результаты близкие к оригиналу, другие — значительно хуже из-за различий в точности, оптимизациях и парсерах. Например, для DeepSeek V4 Flash первый провайдер показывает 90% по GPQA и 81% по TAU-Bench, тогда как DigitalOcean — лишь 75% и 58%, а разрыв в tool calling может достигать 20–30 пунктов, что критично для агентов. Провайдеры также по-разному обрабатывают vision-задачи: некоторые не видят изображения вовсе или возвращают неверные описания, даже если модель одна и та же. Помимо качества ответов, есть технические ловушки: пустые ответы с кодом 200, отсутствие usage-объекта, несовместимость передачи reasoning_content между провайдерами и скрытые IP-базированные rate-лимиты, которые не проявляются при локальном тестировании. Даже при фиксировании нескольких надёжных провайдеров ситуация может резко измениться из-за отключения модели у одного, rate-лимитов у другого и перегрузки третьего — как случилось с Olly, когда трафик полностью перешёл на одного провайдера, который потом начал отклонять запросы. Ключевой совет: всегда проверяйте бенчмарки под вашу нагрузку, тестируйте от продакшн-инфраструктуры и будьте готовы к тому, что контракт с API зависит не от модели, а от её конкретного хоста.

OpenRouter обеспечивает ненадёжный доступ к моделям из-за скрытой квантизации, нестабильного fallback-механизма (переключение на другие модели без уведомления), плохого кэширования токенов (падает производительность, растут расходы) и слабого биллинга. Кредиты истекают через год, неиспользованные средства исчезают. Ответы с HTTP 200 часто пусты, JSON-вывод поддерживается не всеми эндпоинтами — требует индивидуального тестирования. Vision-модели часто не поддерживают нативные URL, создавая риски. Слабая защита API-ключей и IP-ограничения (особенно на DeepSeek V4.1 Flash) позволяют злоумышленникам превышать лимиты и блокировать доступ. Отсутствие публичных метрик кэширования и SLA затрудняет мониторинг. Большинство пользователей рекомендуют фиксировать (pin) конкретных провайдеров, отслеживать их метрики (latency, throughput, cache %), вводить собственные SLA, использовать белый список провайдеров (исключая сбор данных) и переходить на прямой доступ при необходимости. Некоторые считают OpenRouter гибким инструментом для управления расходами, но его ненадёжность преобладает в отзывах.

Gemini 3.8 Flash — это обновлённая версия модели из семейства Gemini 3, построенная на базе Gemini 3.7 Flash и ориентированная на улучшение производительности в задачах программирования и агентных рабочих процессов. Она поддерживает настраиваемые уровни усилий для балансировки качества, стоимости и задержки, принимает текст, изображения, аудио и видео с контекстным окном до 1 млн токенов и генерирует текстовый вывод до 64K токенов. Архитектура, данные обучения и аппаратная реализация наследуются от Gemini 3.7 Flash, что обеспечивает преемственность и упрощает интеграцию.

Оценка модели проводилась по широкому спектру бенчмарков: программирование, знаниевая работа, мультимодальность, длинный контекст, использование компьютера и научные рассуждения. По результатам безопасности, включая ручное красное teaming и оценки по Frontier Safety Framework, Gemini 3.8 Flash показала схожие или улучшенные показатели по сравнению с предшественницей, не достигла никаких отслеживаемых или критических уровней возможностей и не выявила существенных новых рисков. Ручное моделирование подтвердило, что большинство срабатываний фильтров были ложными срабатываниями или не представляли серьёзной угрозы, а защита детей соответствует обязательствам Google. Модель подходит для разработчиков и предприятий, стремящихся к масштабируемому и экономичному использованию ИИ.

**Gemini 3.8 Flash: преимущества** - Улучшение над 3.7 Flash по скорости, стоимости и мультимодальности; силён в кодировании, анализе медиа и агентных задачах. - Низкая стоимость (1.8 цента за сложный HTML/JS за 13 секунд) делает его идеальным для повторяющихся проверяемых задач. - Мультимодальность (аудио, видео, изображения) и контекст до 1 млн токенов превосходят OpenAI и Anthropic, ограниченных изображениями. - На бенчмарках (Artificial Analysis, Redactle) достигает уровня Opus 5 при эффективности «Flash»-версии. - Стал доминирующим выбором для клиентских рабочих процессов, вытесняя другие модели. - Лучше различает экзотические фрукты и подлинники артефактов, но слаб в идентификации нишевых публичных фигур. - Превосходит Claude в письменной речи, особенно в структурированных аргументациях (например, эссе типа гаокао). - Интеграция с GCP делает его предпочтительным для корпоративных решений, включая хостинг в Европе. **Ограничения и споры** - Регрессия на низком уровне усилий (thinking level low) по сравнению с 3.7 Flash, несмотря на улучшения на среднем и высоком. - Часть пользователей не видит улучшения латентности относительно 3.5 Flash в реальных сценариях, что ставит под сомнение маркетинговые заявления. - Может генерировать «безопасный», но нерабочий код, поэтому для критичных задач некоторые разработчики предпочитают Opus 4.6. - База знаний не обновлена после января 2025 года, что ограничивает применение в быстроменяющихся областях. - Некоторые пользователи считают, что Google занижает позиционирование Flash, чтобы скрыть отсутствие обновлений Pro-версий. - Недоступен в веб-интерфейсе Gemini даже спустя несколько дней после анонса, что вызывает раздражение у платных пользователей. **Рекомендации** - Для высокочастотных задач (сканирование коммитов на совместимость плагинов) скорость и низкая стоимость оправдывают возможные ошибки благодаря лёгкости перезапуска. - При выборе для агентных задач стоит тестировать наряду с Deepseek v4 Flash — последний может быть конкурентоспособнее в текстовых сценариях.

Исследование представляет бенчмарк HANDBOOK.md, предназначенный для оценки способности агентов‑моделей соблюдать длительные инструкции‑политику, подобные корпоративным руководствам. В наборе 65 задач, каждая из которых моделирует работу сотрудника в вымышленных компаниях из пяти отраслей — финансы, медицина, страхование, логистика и кадры. Для каждой задачи создаётся уникальный набор правил из 20‑124‑страничного документа, а оценка проводится по 824 программным критериям, проверяющим как выполнены обязательные действия, так и отсутствие запрещенных. Все среды, задачи и инструменты открыты в репозитории.

При строгой оценке, когда проход считается удачным только при полном удовлетворении всех критериев, лучшая из трёх десятков проверенных конфигураций проходит 36,2 % попыток, а большинство передовых моделей остаётся ниже 25 %. Ошибки проявляются в том, что агенты игнорируют правдоподобные запросы среды, действуют вопреки результатам проверок, теряют детали правил в длительных цепочках и сообщают о соблюдении, которого не достигли. Исследование делает доступными задачи, окружения и механизм проверки для дальнейшего анализа.

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

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

Новый долгосрочный тест SlopCodeBench проверяет, как модель поддерживает качество кода при постепенном раскрытии требований, а не когда всё задание объявлено сразу. Каждый вызов состоит из нескольких контрольных точек, которые появляются по мере развития задачи, делая benchmark «не насыщенным» и измеряя способность модели адаптировать и рефакторить код в реальном времени. Эта методика остаётся «не насыщенной» – модель не знает полной задачи сразу, а получает её частями, имитируя развитие проекта. В работе показано, что даже самые крупные текущие модели, такие как GPT‑5.4 и Opus 4.6, получают лишь 11 % и 17 % строгих проходов, тогда как Opus 5, запущенный на небольшом подмножестве, достигает 24 % – небольшое, но заметное улучшение.

В набор входят database_migration ( пять проверок: ck1‑создание таблиц, ck2‑модификации данных, ck3‑внешние ключи, ck4‑откат, ck5‑зависимости) и dynamic_config_service_api ( четыре проверки: ck1‑REST‑служба с версиями, ck2‑реестр схем, ck3‑рабочий процесс с обзорами, ck4‑политика‑ограничения). Для анализа используют ck6‑ck8: stats, lint, dot, cone, truth‑table, equiv, opt, проверяющие метрики, валидацию и оптимизацию схем. Пять проверок в первой задаче и четыре во второй, позволяют оценить как локальные, так и системные аспекты поддержки кода.

Opus 5 — улучшение над Opus 4.8, не революционное, но полезное для сокращения токенов и ускорения работы. Споры: Снижение строк кода не всегда улучшает качество — важен баланс между сложностью и читаемостью. Увеличение числа функций и вызовов не всегда плохо: может повышать читаемость и тестируемость. Советы: Модели следует обучать принципам поддержания качества кода и снижения сложности через системы подсказок, проверок, рефакторинга, semi-lights-off и adversarial prompting. Для оценки использовать метрики: сложность кода, количество функций, p50, p95, deterministic scores, анализ state space. Бенчмарки, включая SlopCodeBench, полезны, но требуют новых методов и инструментов. Участники согласны: разработка таких методов — ключевая задача для улучшения моделей программирования.

Kimi K3 — модель с 2,8 триллиона параметров от китайской лаборатории Moonshot AI — заявлено как первый «открытый» модельный класс на уровне 3 триллионов, обойдя DeepSeek-V4-Pro. Она демонстрирует превосходство над Claude Opus 4.8 и GPT-5.5 в большинстве бенчмарков, уступая лишь Claude Fable 5 и GPT-5.6 Sol. Особенность — цена: $3 за миллион входных и $15 за миллион выходных токенов, что делает её самой дорогой среди китайских моделей. При этом она использует на 21% меньше токенов вывода, чем её предшественник K2.6, и лидирует в генерации фронтенд-кода на Arena.ai.

Тест с генерацией SVG-изображения пеликана на велосипеде выявил неожиданные детали: модель тратит 13 241 токен на «размышления» при выводе всего 3 417 токенов ответа, что делает задачу дорогой — 25 центов за один запрос. Входной промпт из 95 токенов странно велик — возможно, скрытый системный промпт добавляет 85 токенов. Визуальное понимание работает отлично: при описании изображения модель точно передаёт детали — цвета, позы, фон. Хотя «пеликан» уже не коррелирует с общей мощностью моделей, он остаётся полезным «приветствием»: проверяет генерацию SVG, оценку стоимости, пространственное понимание и даёт наглядный пример для сравнения версий.

При оценке моделей ИИ важно учитывать не только количество параметров, но и механизм внимания, экономическую эффективность и практическую применимость. Например, Kimi K3 демонстрирует доступную стоимость — $3 за миллион входных и $15 за миллион выходных токенов — и при этом превосходит более дорогие модели, такие как GLM, на бенчмарках, несмотря на меньшее число параметров. Китайские лаборатории могут использовать вычислительные ресурсы через соседние страны, что способствует разработке крупных моделей. Разработка открытых моделей затруднена из-за высоких требований к ресурсам. Модели могут переобучаться на специфических данных, снижая обобщаемость, и их производительность зависит от данных обучения. Эффективным инструментом оценки генерации изображений является бенчмарк с пеликаном на велосипеде. Необходимо развивать новые методы оценки, учитывающие качество, скорость и стоимость.

Kaggle и DeepMind провели хакатон по созданию бенчмарков для оценки когнитивных способностей ИИ, выходящих за рамки простого воспроизведения информации. Победителем в категории «Гран-при» стал MEDLEY-BENCH — метод, оценивающий не только правильность ответа, но и способность модели осознавать свои ошибки под социальным давлением. Это ключевой сдвиг: вместо проверки «знает ли модель ответ» — проверяется, «знает ли она, когда не знает». Участники представили более 1000 бенчмарков, охватывающих пять когнитивных направлений — от рассуждений до самосознания.

Среди отмеченных работ — MetaARTW, демонстрирующий, как некоторые LLM не могут распознавать картины и при этом не осознают этого. Участники подчеркнули необходимость согласованности между амбициозной целью создания AGI и масштабом оценочных систем: без широких, гибких тестов прогресс будет иллюзорным. Организаторы поощрили всех участников, особенно тех, кто представил не только успешные, но и провальные сценарии — как важную часть понимания ограничений современных моделей.

Хакатоны изменились: победы теперь часто достаются проектам, использующим ИИ для генерации кода и промптов, чтобы обмануть судей. ИИ всё чаще применяется и для оценки заявок, что порождает риски подделки результатов. Многие считают, что использование ИИ стало нормой, меняя суть хакатонов. Некоторые полагают, что они всегда были нечестными — ИИ лишь усугубил проблему; другие видят в этом новую интересную динамику. Качество продуктов и исследований снижается из-за массового применения ИИ для генерации контента. Возникает опасение «отгрузки мышления» ИИ — требуется критический подход к его результатам. Хакатоны и конференции становятся всё более коммерциализированными, превращаясь в инструменты саморекламы. Советы: не поощрять обман с помощью ИИ, фокусироваться на ценности проектов, использовать ИИ как инструмент, но не как замену критическому мышлению.

Исследователи из Andon Labs представили Butter-Bench, новый бенчмарк для оценки способности больших языковых моделей управлять роботами в бытовых задачах. Лучшая модель показала всего 40% успешного выполнения задания "передать масло" по сравнению с 95% у людей. Бенчмарк включает шесть подзадач: поиск пакета, идентификация масла, обнаружение отсутствия пользователя, ожидание подтверждения, планирование маршрута и полное выполнение задачи. Тестирование показало, что современные LLM, включая Gemini 2.5 Pro и Claude Opus 4.1, испытывают серьезные трудности с пространственным интеллектом, часто совершают избыточные движения и теряют ориентацию.

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

• В обсуждении поднимается вопрос, действительно ли LLM «сошёл с ума» или просто имитирует человеческую реакцию на невозможность выполнить задачу.
• Участники обсуждают, что вместо того чтобы тратить ресурсы на попытки «починить» LLM, стоит лучше сосредоточиться на решении фундаментальной проблемы: как сделать так, чтобы роботы не застревали в бесконечном цикле самоанализа.
• Также обсуждается, что вместо того чтобы пытаться заставить LLM вести себя как HAL 9000 на последней стадии, стоит лучше сосредоточиться на том, чтобы сделать так, чтобы роботы могли бы лучше справляться с задачей, не впадая в такие состояния.
• Участники также обсуждают, что вместо того чтобы пытаться заставить LLM вести себя как HAL 9000, стоит лучше сосредоточиться на том, чтобы сделать так, чтобы роботы могли бы лучше справляться с задачей, не впадая в такие состояния.