Nikolay Nikitinтекст ещё не в индексе
Это спорное утверждение. Качество архитектуры сатновится куда важнее. Но это качество никто мерить не умеет. А вот сам код не особо важен
Сейчас все бенчмарки завязаны на выполнение определенных маленьких прикладных задач. Такая вещь как техдолг вообще не меряется. Так-то в принципе там работает базовая теория информации. Чем более информативная модель зашита в фреймворк, тем меньше галюцинаций будет у агента (поскольку своей модели у него нет. Но опять, не понятно, какая цель - сделать типовое приложение, чтобы оно проходило тесты, сделать нетиповое приложение или сделать что-то, что поддерживать можно
Видео
IMG_1912.MP4 · 3.8 МБ · нажмите — покажем
IMG_1912.MP4 · 3.8 МБ · нажмите — покажем
Ребята из команды Антона Конушина и лаборатории Fusion Brain опубликовали крутое обновление в нашей линейке моделей для реверс-инжиниринга!
CADENA: Stepwise CAD Reverse Engineering
Перешли на пошаговое предсказание — модель стала гибче, качество выросло, и чем сложнее датасет, тем больше отрыв. Плюс собрали CADENA-Bench: 3396 реальных механических деталей, разбитых по категориям ЕСКД, чтобы можно было оценивать готовность к практике для отдельных типов деталей.
О постановке задачи для тех, кто пока про нее не слышал: по скану физической детали восстановить её CAD-модель — дерево построений, которое инженер может править и по которому деталь можно произвести. Последовательность CAD-операций пишется питоновским кодом, так что фактически это mesh2code.
Наши прошлые модели предсказывали всю последовательность разом и потому наследовали статистику трейна: если операция B в обучении всегда стоит между A и C, на инференсе она встанет туда же. На сложных и редких деталях это ломалось. В CADENA мы предсказываем по одной операции за раз — модель исполняет то, что уже написала, смотрит на разницу с целью и решает, что делать дальше. Плюс новый генератор, дающий длинные последовательности операций.
Результат: заметный отрыв на всех датасетах, где мы замеряемся. На CADENA-Bench мы лучше в 5 категориях из 6 и в среднем. На BenchCAD, где свои модели меряет в том числе Claude, восстановление объёма 91% против 71% у фронтирных моделей и 75% у специализированных.
На гифке — как модель собирает деталь по операциям.
Paper: https://arxiv.org/abs/2608.00799 · https://huggingface.co/papers/2608.00799
GitHub: https://github.com/zhemdi/cadena
Dataset: https://huggingface.co/datasets/kulibinai/cadena-bench
Model: https://huggingface.co/kulibinai/cadena
Заапвоутить: https://huggingface.co/papers/2608.00799
8.4K · Александр МещеряковА что это за "центр технологий для общества"?
Ссылка
нажмите — покажем
нажмите — покажем
люди из подразделения яндекс клауда, они помогают развивать общественно значимые проекты, много вкладываются в науку и образование, очень крутые
Ссылка
нажмите — покажем
нажмите — покажем
#зоопарк_одобряет #конференции
Вернее, не конференция, а интересный (и бесплатный) вебинар от girafe.ai "Рабочее окружение ML-инженера: делегируем рутину ИИ-агентам"
Почему интересно: хотя бы по той причине, что у girafe.ai есть совместная онлайн-мага с МФТИ, что, на наш взгляд, уже знак качества (Физтех очень разборчив в выборе таких партнеров)
Темы:
• организация удобного рабочего окружения ML-инженера с нуля
• настройка безопасного состояния удалённого сервера для любых нужд
• автоматизация всех рутинных процессов агентами
• формирование скиллов агентов для однокнопочного воспроизводства операций
• кастомизация под свои вкусы и нужды
Когда: 5 августа (среда), в 19:00 (МСК)
Спикер: Владислав Гончаренко - основатель girafe.ai и автор курса MLOps онлайн-магистратуры MSAI (girafe.ai × МФТИ)
Язык русский, участие, повторяем, бесплатное, но нужна предварительная регистрация - вот тут
10.6K · Фотография
нажмите — покажем
нажмите — покажем
Коллеги из Sber AI Lab опубликовали новый открытый репозиторий https://github.com/sb-ai-lab/SIRIN (Semantic Inconsistency Recognition and Inspection Nexus) - инструмент для поиска смысловых ошибок в ответах языковых моделей.
Что умеет SIRIN:
- Проверяет соответствие ответа исходному контексту на уровне токенов, последовательностей и отдельных утверждений.
- Поддерживает детекцию галлюцинаций и оценку answerability - достаточности данных для ответа.
- Объединяет несколько классов детекторов: llm-as-a-judge, uncertainty, probing с использованием метамоделей.
- Позволяет сравнивать и комбинировать разные методы детекции - работает как инструмент для исследований и разработки.
Ссылки:
🔗GitHub
🔗GitVerse
🔗Демо на Hugging Face
🔗Статья на arxiv
Поддержать традационно можно звездочками.
515 · Фотография
нажмите — покажем
нажмите — покажем
👣 Google внезапно объяснила, почему Go может стать главным языком эпохи AI-кодинга
Код теперь пишется слишком быстро. Агент за несколько секунд может выдать сотни строк, переписать пакет или собрать целый сервис.
Проблема сместилась туда, где автоматизация пока не спасает: всё это нужно прочитать, проверить и потом годами поддерживать. Именно на этом Google строит свежий аргумент в пользу Go.
Go изначально проектировали для больших команд и долгоживущих кодовых баз. Поэтому здесь почти невозможно устроить соревнование по синтаксическим фокусам.
gofmt приводит код к одному виду, стандартная библиотека закрывает огромный пласт задач, а компилятор быстро ловит выдуманные методы, неправильные типы и другие типичные ошибки LLM.
Сгенерировал код, запустил компилятор и тесты, получил ошибку, исправил, повторил.
Рядом уже лежат fuzzing, govulncheck, gopls, go fix, профилирование и tracing. Агенту не приходится каждый раз собирать собственный зоопарк инструментов.
Есть и менее очевидный бонус. Go-код в разных проектах обычно выглядит похоже.
Меньше вариантов выразить одну и ту же конструкцию, меньше сюрпризов при ревью, проще заметить галлюцинацию модели или странную зависимость.
Для мира, где код начинают генерировать в огромных объёмах, такая предсказуемость становится очень дорогим преимуществом.
Получается забавно: Go долго критиковали за синтаксис, жёсткие правила и отсутствие лишней магии. А теперь именно эти качества неожиданно делают его одним из самых удобных языков для работы с coding agents.
https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/
#Golang #Go #AI #Programming #AIAgents
@Golang_google
13.8K · Nikolay Nikitin👣 Google внезапно объяснила, почему Go может стать главным языком эпохи AI-кодинга
Код теперь пишется слишком быстро. Агент за несколько секунд может выдать сотни строк, переписать пакет или собрать целый сервис.
Проблема сместилась туда, где автоматизация пока не спасает: всё это нужно прочитать,
Отсутствие альтернативных синтаксисов хорошо только для тех кто остановился в развитии.
Порядок нужен посредственностям, гении повеливают хаусом.
id 2166621782Коллеги из Sber AI Lab опубликовали новый открытый репозиторий https://github.com/sb-ai-lab/SIRIN (Semantic Inconsistency Recognition and Inspection Nexus) - инструмент для поиска смысловых ошибок в ответах языковых моделей.
Что умеет SIRIN:
- Проверяет соответствие ответа исходному контексту на ур
В контексте SIRIN особенно полезна проверка не только “похож ли ответ на правду”, а на каких фактах он держится. У @ML_GPT была похожая формулировка про агентов: “конфликт нельзя решать молча”. Для рабочих сценариев я бы добавлял к каждому важному утверждению паспорт факта: источник, дату, статус данных и место, где ответу не хватает evidence.
Евгений КривошлыковОтсутствие альтернативных синтаксисов хорошо только для тех кто остановился в развитии.
Порядок нужен посредственностям, гении повеливают хаусом.
Код для дэбилов. Ручной кодинг уже активно мрёт
Nikolay Nikitin👣 Google внезапно объяснила, почему Go может стать главным языком эпохи AI-кодинга
Код теперь пишется слишком быстро. Агент за несколько секунд может выдать сотни строк, переписать пакет или собрать целый сервис.
Проблема сместилась туда, где автоматизация пока не спасает: всё это нужно прочитать,
Обсуждали много это на прошлом JPoint. На самом деле аргумент вески. Го очень тупой и однотипный язык (в этом его сильная сторона). Он сделан для того, чтобы низко квалифицированные программисты делали меньше ошибок. Казалось бы он должен снизить количество ошибок в сгенерированном коде. С другой стороны, генераторы не делают особо много тупых ошибок, они делают ошибки в смысле, а для того, чтобы меньше ошибок в смысле, фреймворк (не язык), должен сам подсказывать модель, по которой делать код (у самой ЛЛМ модели нет). И тут выигрывают более модельно-емкие фреймворки, которые возникают на более выразительных языках.
По моему опыту, ЛЛМ хорошо понимает модель, заложенную во фреймворке и достаточно легко реплицирует нужные поведения. Кроме того, есть еще аргумент экономии токенов. На более выразительных языках, приложения очень компактные.
Про отсутствие альтернативы - это тоже не факт, что хорошо. Это хорошо для людей, когда идет большая текучка в команде. Но ЛЛМке пофигу, она адаптируется к любому стилю и копирует его. Иногда слишком, например я задолбался вычищать runCatching, который наши джуны/мидлы везде понаставили ллмками. Подсмотрели где-то в статьях. С другой стороны разные варианты сделать то же самое - это тоже модль поведения, которая может быть актуальна для того или иного конкретного приложения.
Ivan LitvakКод для дэбилов. Ручной кодинг уже активно мрёт
Думаю это как играть на инструменте и слушать музыку в плеере. Слушают больше но все равно останутся те, кто играет и ходит на живые концерты. В этом мире ничего не умирает только становится меньше.
Ссылка
нажмите — покажем
нажмите — покажем
https://huggingface.co/blog/icml-2026-open-reproductions
хороший отчет по хаккатону направленному на анализ воспроизводимости подаваемых работ
из интересного: например, ожидаемое наблюдение о том, что теперь заметно больше подается работ, отчасти от того, что с агентынми системами доступнее проводить эксперименты и реализовывать методы; однако, несмотря на повышаемую нагрузку на ревьюверов, сами проверки также стало более возможно делать
Фотография
нажмите — покажем
нажмите — покажем
Попался интересный лонгрид про конкурентоспособность людей и ИИ-агентов: https://t.me/vgcourse/560
Разбираются различные модели продуктивности, методики её оценки, статьи по теме и т.п.
Цитируя основные выводы автора:
- Большинство студентов не понимает, почему они могут быть конкурентоспособны в век агентов и как двигаться к этой конкурентоспособности.
- В свежем исследовании METR рассматривается Expenditure Horizon — момент, начиная с которого агент становится менее эффективен, чем квалифицированный человек, что будет использоваться как для измерения эффективности агентов, так и для повышения эффективности использования агентов человеком.
- Наиболее перспективны в век ИИ AI-Amplifier задачи, когда использование ИИ существенно повышает производительность наиболее квалифицированных людей, увеличивая их отрыв от менее опытных. Доля таких задач будет с ближайшие годы расти просто потому, что в AI-Equalizer задачах ИИ будет все сильнее вытеснять людей, а их работа будет использоваться в первую очередь как разметка для ИИ.
- В ваших руках увеличение доли AI-Amplifier задач в вашей работе/учебе. Если она мала — дружеский совет — меняйте работу/учебу.
182 ·