Искусственный интеллект

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

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

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

DeepEval - фреймворк для оценки работы AI с открытым исходным кодом.

Содержит в себе множество метрик и бенчмарков для оценки качества работы AI моделей, а также предоставляет инструменты для аналитики изменений качества работы в течение разных периодов времени.

В предыдущей статье мы уже частично осветили имеющиеся у DeepEval метрики (метрики для оценки RAG).

В этой статье постараемся объяснить, какой еще функционал предлагается DeepEval для работы с AI.

Всем привет! Я потратил на ии кодинг 500 долларов за 10 дней работы с Девином, и в результате у меня получился онлайн редактор для АИ видео с открытым исходным кодом. Кто такой Девин, зачем я это делал и что в итоге получилось. Разбираемся ниже.

Периодически почитываю местные статьи про использование LLM в разработке, в комментариях обычно возникают дискуссии относительно эффективности такого подхода. Как я заметил, как правило и статьи, и уж тем более комментарии ограничены общими рассуждениями без конкретики, поэтому решил на собственном примере понять — можно ли с нуля и без опыта написать мобильное приложение используя LLM?

Мы продолжаем адаптированный перевод статьи “The Prompt Report: A Systematic Survey of Prompt Engineering Techniques” (первую часть можно найти здесь). С переводом мне по-прежнему помогает коллега – Анастасия Тарабакина. 

В этой части мы обсудим такие техники промптинга, как Chain-of-Thought и декомпозиция. Начнем с техник промптинга, которые заставляют модель демонстрировать пользователю внутренний процесс “рассуждения” над задачей (Thought Generation).

Аналитический центр red_mad_robot продолжает разбирать ключевые исследования в сфере интеллектуальных систем и генеративного поиска. На этот раз рассказываем про архитектуру AI Search Paradigm от Baidu — новой системы интеллектуального поиска, построенной на LLM и мультиагентных методах.

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

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

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

Это перевод моей статьи в LinkedIn

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

На мой взгляд это уже вполне достижимая цель, которая достижима с текущим уровнем технологий.

Приведу пример на близкой мне области - программирование (но вообще применим к большинству digital профессий). Сделаем автономного ИИ middle backend разработчика.

Сделаем мы его на локальной серверной машине, внутри контура компании.

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

Всем привет! Меня зовут Алёна Лагойкина, я дизайнер в AGIMA. Последний год я много экспериментировала с нейронками: пробовала создавать и редактировать самые разные артефакты — по работе и для себя. За это время у меня полетела видеокарта, я завела себе китайскую симку, достала китайский VPN и в целом начала учить китайский язык. И всё это — чтобы освоить искусство промтинга.

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

ИИ всё чаще обещает «заменить дизайнеров». Я решила проверить, насколько это правда. Не на красивых лендингах, а на честных B2B‑интерфейсах, где таблицы, фильтры и кнопки, а не эмоции и котики.

Взяла три инструмента Wireframe Designer, UX Pilot и Uizard и дала им одинаковый промт: создать страницу контрактного модуля для выдуманной корпоративной системы. Сравнила, кто из них действительно понимает, что такое интерфейс, а кто просто красиво рисует прямоугольники.

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

Решил попробовать вайб-кодинг и заодно сделать полезное дело — создать HR-сайт для компании, в которой я руковожу ИТ-департаментом. Рассказываю, что меня впечатлило, а с чем пришлось повозиться.

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

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

(спойлер: в конце будет ссылка на GitHub)

Таск-менеджеры вроде Jira — хороший инструмент для ведения проектов. Вот только есть одна проблема — на них очень быстро забивают. В первую очередь — проектные менеджеры (на всякий случай: я тоже забиваю). Когда проект стартует, менеджер с командой, как правило, делают волевую попытку декомпозировать его на эпики и задачи. Каждая задача получает красивое описание, а иногда даже назначенных исполнителей и дедлайны.

Потом проект стартует…

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

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

Работая в области машинного перевода в компании 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 и Нестерова.