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

Когда в 2019 году я начинал размышлять о проблемах обучения кодингу, нашим врагом номер один был «ад туториалов». Признаки попадания в этот ад:

• Вы успешно завершили кучу туториалов, но не можете создать ничего своего.

• Вы тратили больше времени на просмотр видео о кодинге, чем на само программирование.

• У вас имелось знание о многих технологиях на уровне флеш-карточек, но их внутреннее устройство было вам совершенно непонятно.

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

• Глубокий курс обучения. Основы CS нужно преподавать не только в традиционных учебных заведениях.

• Практическое освоение всего. Необходимо писать код; не только в проектах, но и интерактивно, в процессе изучения каждой концепции.

• Меньше видео, больше текста. Видео слишком легко потреблять бездумно.

Повторюсь, что в 2019 году ад туториалов был повсеместным. Многочасовые курсы на YouTube собирали миллионы просмотров. Однако сегодня те же самые каналы с трудом набирают по пятьдесят тысяч просмотров нового контента. Посмотрите на FreeCodeCamp, Traversy Media и Web Dev Simplified. Я не пытаюсь бросить тень на эти каналы, они помогли куче людей, но их показатели сейчас именно таковы.

Я уже некоторое время работаю в компании Scalehost, где мы исследуем возможности внедрения AI и ML в нашу инфраструктуру. В процессе поиска материалов, я наткнулся на данную статью, которая показалась мне интересной. В ней рассматривается как объединение подходов DevOps и MLOps помогает компаниям создавать более устойчивые и эффективные процессы разработки, снижать риски и повышать качество продуктов. 

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

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

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

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

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

Искусственный интеллект — это уже не только чат-боты и генераторы изображений. Еще он помогает машинам анализировать обстановку, строить планы и справляться с новыми обстоятельствами. Недавно 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. Также проводится анализ того, как проверить статистическую значимость различий между двумя системами перевода, используя эти метрики.