Машинное обучение *

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

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

Мы собрали подборку из семи нейросетей, которые подойдут для генерации кода. Они просты, удобны и работают без привязки карты.

Каждый, кто работает с AI, рано или поздно сталкивается с его ограничениями. Недавно я столкнулся с такой ситуацией: Perplexity успешно проанализировал сайт и собрал все ссылки, но отказался их обработать, сославшись на «превышение лимитов ресурсов». Что это за «лимиты» в облачной системе, обладающей, казалось бы, бесконечными мощностями? Этот, на первый взгляд, рядовой сбой стал отправной точкой для технического исследования: я решил заглянуть «под капот» AI-песочницы, чтобы понять, как она на самом деле устроена и почему знание ее архитектуры помогает работать с ней гораздо эффективнее

Искусственный интеллект — это уже не только чат-боты и генераторы изображений. Еще он помогает машинам анализировать обстановку, строить планы и справляться с новыми обстоятельствами. Недавно Google DeepMind представила демонстрацию thinking robotics AI — интеграцию моделей Gemini 1.5 в робототехнические сценарии.

Две экспериментальные версии Gemini 1.5 — VLA (vision-language-action) и ER (embodied reasoning) — работают вместе, чтобы машины могли действовать в реальном мире. Это не просто очередной шаг в развитии автоматизации, а попытка научить роботов понимать, что они делают и зачем. Чем интересен этот подход, где его можно применить и какие вопросы он вызывает? Давайте разберемся.

ИИ-код сегодня выглядит все изящнее — но стоит попытаться его запустить, как начинаются сюрпризы: сбои, ошибки и несоответствия задаче. Почему же модели, которые так уверенно “говорят” на языке программирования, на практике регулярно сбоят? Возникает ощущение, что между красивым ответом и рабочим решением все еще большая пропасть.

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

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

Мультимодальные модели блестяще «понимают» сцены, но промахиваются там, где тестировщику важно точное соответствие: в сравнении двух версий одного экрана. Случайный сдвиг на несколько пикселей ломает пиксельные diff’ы и маскирует реальные проблемы — вроде исчезнувшей кнопки. Разбираем, почему так происходит, как компенсировать искажения многоуровневым сопоставлением и как простая CNN по окнам 9×9 помогает выявлять именно релевантные отличия.

В гонке за следующей волной «умных» систем большие языковые модели (LLM) берут на себя неожиданные роли. Одна из самых интересных — использовать такие модели как «судей» для оценки других моделей. Подход уже экономит командам массу ручной работы, но остаются вопросы: способен ли LLM уловить каждую тонкую ошибку? Что происходит в ситуациях, где критичны человеческая интуиция или глубокая предметная экспертиза?

Реальность такова: человеческие ревьюеры по-прежнему обеспечивают уровень контекстного понимания, которому ИИ пока не соответствует. Поэтому вместо того чтобы противопоставлять методы, многие в индустрии приходят к связке «LLM-судья + человеческая оценка» как к наиболее эффективной комбинации. В этой статье разберём, что такое LLM-судья, как он соотносится с человеческой оценкой и почему гибридный подход имеет наибольший смысл.

Работая в области машинного перевода в компании Lingvanex, я постоянно читаю статьи в которых сравнивается качество разных переводчиков. Иногда отличие между ними составляет от 0.3 до 1% по какой-либо из метрик, но и это уже повод заявить, что их переводчик - лучший.

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

В данной статье рассматриваются две наиболее распространенные метрики для оценки качества перевода — BLEU и COMET. Также проводится анализ того, как проверить статистическую значимость различий между двумя системами перевода, используя эти метрики.

Всем привет! Меня зовут Наталья Бруй, я промпт-инженер в MWS AI. Вместе с моей коллегой  Анастасией Тищенковой мы решили ответить на вопрос, который мучает нашего пиарщика многих – почему больше токенов не равно лучше и  как заставить LLM работать адекватно на длинном контексте. 

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

Оговорочка: эта статья для тех, кто находится на первых этапах освоения темы работы с длинным контекстом и вовлечен в создание каких-нибудь новых ИИ-продуктов на основе языковых моделей. Если вы уже две диссертации об этом написали, тогда можете сразу в комментариях ссылки оставить – мы почитаем. 

... или может ли ИИ заменить программиста? Сейчас со всех сторон долбят про то, как ИИ помогает в жизни и вообще, если ты не используешь ИИ, то ты в отстающих и лузер. Я к этому отношусь спокойно, ибо мои занятия совершенно не допускают использование ИИ из-за очень большой цены ошибки, но долбежка все-таки делает свое дело. Плюс как-то внезапно обнаружил, что у (не реклама) cloud.ru доступны Foundation Models (они же БЯМ, они же LLM) без оплаты. Понятное дело, тестовый период и прочее, но использовать можно. Но просто мучать модельки вопросами уровня «сколько цифр в слове» смысла мало, поэтому решил попробовать сделать что-то хоть капельку полезного и получить собственный ответ на вопрос пригодности БЯМ. Результат для нетерпеливых тут https://github.com/kiltum/zxgo

Далее несколько абзацев истории, чтобы просто было понятно, каким путем я шел до результата. Скажу честно, выбор места приложения сил БЯМки был сделан довольно быстро: напиши мне много кода. Раз пока все бесплатно, выбрал самый большой Qwen и предложил ему написать эмулятор КР580ВМ80А (он же Intel 8080), причем на питоне. И внезапно, он с первой попытки сгенерил что-то очень похожее на правду. Хмыкнув, я нашел образ ПЗУ от Радио-86 и зарядил еще пару десятков запросов. Вскоре я с глубоким удовлетворением увидел в окошке заветное «РАДИО 86-РК» и следом «-->». 

Немного порадовавшись результату, я преисполнился энтузиазма и решил поднять ставки. Z80 и ZX Spectrum! Культовая машина, все нюансы которой разложены по полочкам и по которой документации на порядки больше, чем для «радио»,«микроши» и «специалиста» вместе взятых. А чтобы было совсем хардкорно, основным языком я выбрал С++.

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

Для ускорения сходимости широко применяются методы с механизмом импульса (momentum): классический метод Поляка — Heavy Ball (HB) — и метод Нестерова (ускоренный градиент). Оба эти метода используют идею накапливать «инерцию» градиента, благодаря чему могут двигаться по направлению оптимума быстрее обычного градиентного спуска. 

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

Всем привет! Меня зовут Степан Трифонов, я аналитик‑разработчик в Яндекс Пэй. Недавно мы с коллегами, Леонидом Левиным и Савелием Чежеговым, опубликовали научную статью Incorporating Preconditioning into Accelerated Approaches: Theoretical Guarantees and Practical Improvement, где ввели предобусловленные версии классических ускоренных методов — Preconditioned Heavy Ball (PHB) и Preconditioned Nesterov (PN) — и доказали для них оценки сходимости при весьма общих допущениях на предобусловливающую матрицу. Также мы провели численные эксперименты, которые продемонстрировали практический выигрыш новых алгоритмов по сравнению с обычными (непредобусловленными) методами HB и Нестерова.

Чтобы понять, какие технологии будут определять рынок завтра, компании опираются на прогнозы/отчёты аналитиков или анализируют патенты. Но есть источник, который часто опережает и патенты – научные публикации. Далее о том, как я проанализировала 134195 научных статей 2025 года, чтобы ответить на вопрос, на какие технологии делать ставку прямо сейчас.

AI генерирует тесты, но 95% из них не работают — галлюцинирует классы,
путает поля, использует несуществующие API. Знакомо? Мы в отделе RAPID прошли через
это на проекте с биржевым протоколом TWIME. Делимся итеративным подходом:
как за 3 шага превратить хаос из 307 тестов в 109 работающих.
С конкретными промптами, метриками и выводами.

Привет, чемпионы! Мы детально разобрали природу проблемы и изучили арсенал методов. Теперь перейдем к самому важному — практическим результатам. Я протестировал каждый подход на реальной задаче создания инфографики "Agentic AI Explained" и готов показать, что действительно работает.

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

Идея была такая: а что, если научить искусственный интеллект понимать этот язык? Не подавать модели сырые числа, а переводить бары и объёмы в текстовые описания наблюдаемых паттернов и кормить ими языковую модель. Гипотеза была что в тексте уже будет содержатся достаточно данных, чтобы модель научилась связывать недавнюю торговую историю с тем, пойдёт ли цена вверх на следующий день.

Инструмент эксперимента — модель distilbert‑base‑uncased с Hugging Face и это облегчённая, быстрая версия BERT для понимания языка. Мне показалось это практичным выбором для прототипа — позволяет быстро проверять разные способы текстовой разметки без гигантских ресурсов. Цель была чёткая: по текстовому описанию недавней истории торгов предсказать рост цены на следующий день.

Но это исследование моя попытка представления рыночных данных как языка, а не попытка сразу создать алгоритм для автотрейдинга. Ещё важно: это мой личный эксперимент, проведённый одним человеком и выполненный однократно. Результаты дали интересные наблюдения.

Расскажу, как происходила разметка графиков в текст, какие шаблоны сработали лучше и какие метрики использовались. Также отмечу ограничения подхода и идеи для повторных экспериментов.

А ещё весь код уже на GitHub.

ИИ-агенты с каждым годом решают всё более сложные задачи — кажется, что до автомобиля без водителя или сверхумного личного ассистента рукой подать. Но как только доходит до настоящей работы — где действий сотни, приложения переключаются туда-сюда и всё зависит от прошлого опыта — они удивительно часто спотыкаются. Модели становятся мощнее, но забывают вчерашние ошибки, не учатся на них и снова наступают на те же грабли.

Новое исследование меняет привычный подход: оказывается, чтобы агент стал умнее, дело не столько в дообучении или размерах модели. Гораздо важнее — встроенная память, которая сохраняет удачные решения, учит быстро находить выход из тупиков и, главное, формирует привычку рефлексировать. Такой подход уже позволил простой модели обогнать продвинутых конкурентов в длинных офисных задачах и находить неожиданные, а порой даже очень “человеческие” решения.

Здесь разбираемся, как агенты учатся использовать свой опыт на лету, почему память и рефлексия меняют всё для ИИ — и чем это грозит (или радует) тем, кто ждет настоящих самостоятельных цифровых помощников.

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

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

Поводом написания этой статьи послужил подслушанный диалог:

— А на чем у вас агенты написаны?

— У нас на MCP!

Для меня MCP всегда был просто протоколом, то есть именно способом отправки и обработки запросов. А когда я слушал выступления или читал некоторые статьи о том, как плох/хорош MCP, меня не покидало ощущение чего-то странного. Но все же решил, что это от незнания, и я чего-то не понимаю. А когда не понимаешь, но очень хочешь понимать, то самый лучший способ — это взять и разобраться.

Именно это предлагаю и сделать в статье, а также замерить MCP, чтобы ответить на вечный вопрос: сколько сжирает MCP, подключать ли его вообще или и так сойдет?

Побывал на Oxford Machine Learning Summer School 2025 — одной из крупнейших летних школ, посвящённых искусственному интеллекту, проходившей в самом центре Оксфорда. В течение четырёх дней мы слушали лекции исследователей из DeepMind, Hugging Face, Amazon, Google, ученых топовых европейских вузов. Обсуждали foundation models, reinforcement learning, generative AI и on-device ML. В статье делюсь своими впечатлениями и кратким пересказом программы, отражающей мировые тренды в развитии современного машинного обучения.

Эта статья - пример того как можно с помощью публичных Python библиотек обогатить тестовый датасет новыми внешними полезными данными и значимо улучшить качество ML модели.

На сегодня машинное зрение – это либо просто синоним компьютерного зрения, либо компьютерное зрение, используемое в промышленности, либо более общее понятие - технология и методы, которые используются для визуального автоматического контроля, управления промышленными процессами, роботами и т.д., то есть инструмент системной инженерии. Словом, если стояла бы цель запутать человека, желающего узнать, что такое машинное зрение, то она выполнена. Но так или иначе, даже в последнем случае машинное зрение так переплетено с IT-технологиями, что иначе как компьютерным зрением это назвать трудно. Вероятно, поэтому историю машинного зрения традиционно отсчитывают от публикации в 1955 году статьи Оливера Селфриджа из Массачусетского технологического института (MIT) «Распознавание образов и современные компьютеры», а сам он провозглашен «отцом машинного восприятия».