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

Что может быть проще, чем сгенерировать голосовую подсказку для навигатора? Считаем угол поворота — озвучиваем манёвр. Именно так наша система и работала годами, пока не обросла таким количеством эвристик и региональных «костылей», что её поддержка стала дороже разработки. Добавление нового правила для одной страны ломало логику в другой, а простая задача «отличить плавный изгиб от поворота» превращалась в детектив.

Меня зовут Дмитрий, и я руковожу ML‑разработкой в команде автонавигации Яндекс Карт. Вместе с моим коллегой Альбертом Юсуповым (@al‑iusupov) в этой статье мы поделимся историей полного переосмысления системы генерации дорожных аннотаций. Расскажем, почему решили отказаться от десятков хитрых условий в коде, а также почему заманчивая идея отдать всё на откуп большим нейросетям (VLM, LLM) провалилась. И, наконец, как пришли к элегантному решению: создали уникальный датасет с помощью сотен водителей‑экспертов и обучили быструю и точную ML‑модель, которая работает по принципу «меньше, но лучше».

Решая соревнования на Kaggle начинаешь замечать паттерн. Baseline сделать просто: загрузить данные, запустить CatBoost или LightGBM, получить baseline метрику. Это занимает полчаса. Но чтобы попасть в топ решений, нужно перепробовать десятки вариантов препроцессинга, сотни комбинаций фичей и тысячи наборов гиперпараметров.

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

Главная проблема в том, что эти системы не рассуждают. Они не анализируют почему конкретный подход сработал или провалился. Они не адаптируются к специфике задачи. Они не накапливают опыт между запусками. Каждая новая задача для них как первая.

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

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

Бывало ли такое, что вы ведете долгий проект вместе с агентом, ставите задачи ИИшке, а она только и делает, что топчется на месте, создавая выдуманные переменные и плодя кучу дубляжей файлов с приставками _fix, _final, _corrected?

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

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

Я собрал Laravel-репозиторий, в котором GitHub Copilot работает не как один «волшебный ИИ», а как команда кастомных агентов: одни оформляют ТЗ и архитектуру, другие пишут и проверяют код, третьи обновляют документацию и собирают релизы. В статье показываю, как устроен этот workspace и как его можно использовать в своих проектах.

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

В данной статье описан совсем короткий путь в 6 недель, от простого наивного MVP для бота — администратора, до полноценного инструмента, который закрыл ряд рутинных вопросов администрирования Музыкального Театра.

40 реинкарнаций, 8 AI Агентов — на мой взгляд интересная прикладная история о том, как в мире современных технологий можно собрать вполне работающую вещь не имея, на входе, навыков в используемых инструментах.

Привет, Хабр! Меня зовут Валентин Малых, я - и.о. руководителя направления фундаментальных исследований в MWS AI. Сегодня я расскажу об одном нашем исследовании по сжатию LLM. Если простыми словами, то это про то, как сделать большую модель чуть-чуть менее требовательной в плане памяти и времени выполнения. Для это придумано три базовых техники: квантизация (загрубление весов модели), дистилляция (обучение уменьшенной копии) и прунинг (удаление части сети). Этот пост как раз будет про третий способ, точнее – недавно разработанный нами в сотрудничестве с зарубежными коллегами метод структурного прунинга по глубине без дообучения, который мы назвали ReplaceMe. Например, модель LLaMA-2 после нашего сжатия на 25% сохраняет 92,5% качества. Ниже – о том, как это работает.

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

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

Здесь будет про Langfuse, Phoenix, OpenLIT, Langtrace, LangWatch и Lunary. Про оценку (evaluations или evals) здесь не будет, но обязательно скоро будет отдельная статья и про это.

Поехали!

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

Со временем стало очевидно: проблема не в модели, а в том, как мы ее онбордим в проект. Один и тот же Claude в одном репозитории ведет себя как сильный мидл, а в другом как растерянный стажер. Разница почти всегда в том, что написано (или не написано) в CLAUDE.md и его аналогах для агентов.

Я перепробовал кучу подходов: от огромных "библий" с правилами до минималистичных заметок и автогенерации. Что-то работало, что-то категорически нет. В итоге вырисовались простые, но хорошо проверенные на практике принципы того, каким должен быть CLAUDE.md, чтобы не было мучительно больно ни вам, ни агенту.

Ранее я уже рассказывал про разработку AI чатов на языке R. А в этой статье мы более подробно разберёмся как из AI чата сделать полноценного AI ассистента, который умеет не только отвечать на вопросы, но и выполнять какие то действия, например взаимодействовать с файловой системой, API различных сервисов и так далее.

Команда AI for Devs подготовила перевод большого гайда о скрытых возможностях и продвинутых техниках работы с Gemini CLI. Если для вас терминал — рабочий дом, то этот материал покажет, как превратить Gemini CLI в полноценного ИИ-агента, который автоматизирует рутину, подключается к внешним сервисам и расширяется под любые задачи.

Иногда кажется, что у Сэма Альтмана, Сундара Пичаи и Дарио Амодея есть общий чат в Telegram, где они договариваются, чем занять AI-энтузиастам выходные. Выбирают одну неделю месяца и выстреливают всё разом. Не успели мы привыкнуть к предыдущим версиям, как индустрия синхронно шагнула в следующее поколение. GPT-5.1 с адаптивным мышлением, Gemini 3.0 с интерактивным режимом, Grok 4.1 с эмоциональным интеллектом и просто долгожданный Claude Opus 4.5 — всё это свалилось на нас практически одновременно.

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

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

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

Инициатива OpenAI, которые адаптировали MCP для своей платформы приложений внутри ChatGPT, произвела на меня определенное впечатление, и я проделал довольно основательный эксперимент (на трех облачных H200 и DeepSeek V3.2-Exp), показавший, что основной функционал такой платформы можно воспроизвести усилиями одного разработчика.

Сам эксперимент - в этом видео:

Снимки межзвездного объекта 3I/ATLAS, сделанные в течение ноября 2025 года (уже после прохождения им перигелия), продемонстрировали каплевидную форму его комы, которая вытянута примерно на одну угловую минуту в сторону Солнца.

В этот же период система отслеживания JPL Horizons зафиксировала у 3I/ATLAS наличие негравитационного ускорения. Его величина составляет малую долю (порядка Δ=0,0002) от гравитационного ускорения, создаваемого Солнцем.

Согласно последним данным JPL Horizons, это негравитационное ускорение изменяется обратно пропорционально квадрату гелиоцентрического расстояния (расстояния между объектом и Солнцем) - в точности так же, как и само солнечное притяжение. Это означает, что соотношение между этими двумя ускорениями остается неизменным на всем протяжении орбиты 3I/ATLAS. При этом основная составляющая негравитационного ускорения направлена радиально, прочь от Солнца.

"Claude, создай мне воркфлоу в n8n" — работает или хайп?

Я настроил Claude Desktop для работы с n8n. Две недели тестил. YouTube обещает магию. Реальность оказалась сложнее: он теперь джун, а я слежу, чтобы не накосячил.

Что работает: анализ воркфлоу, поиск узких мест. Что не работает: создание сложных процессов, редактирование без глюков.

В статье — инструкция по настройке + честные выводы.

Классические AI-агенты общаются текстом — это дорого и медленно. LatentMAS раскрывает секрет "безмолвного" общения: агенты обмениваются "мыслями" напрямую через общую латентную память (KV-кэш). Разбираемся, как эта архитектура позволяет добиться двузначного прироста точности и радикально сократить расходы на токены.

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

Меня зовут Андрей Шумаков, я scrum-мастер, а также куратор по розничному бизнесу в центре развития гибких практик разработки и внедрения продуктового подхода в ПСБ. Мой интерес к настолкам в том числе рабочий: я создаю бизнес-игры. В этой статье расскажу, как создал бизнес-игру с помощью искусственного интеллекта. Scrum-мастера, берите на заметку! Под катом объясню в деталях, как составить хороший промпт и какие именно задачи поручить ИИшке, чтобы она не галлюцинировала излишне, не путалась в контексте и выдавала результат, который потом можно итерировать своими руками. Поехали!

В 2025 году рынок моделей продолжает стремительно развиваться. Достаточно вспомнить недавний выход новой модели от Microsoft или обновление Nano Banana. Российские разработки также не стоят на месте.

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

Пока бедолаги из NANDA жалуются, что 95% их ИИ-проектов не выгорают, мы, как взрослые люди, считаем финансовый эффект от ИИ, ML и LLM в банке без магии — с калькулятором.

Меня зовут Михаил Войтко, я работаю в Альфа Банке руководителем по внедрению решений продвинутой аналитики в Дирекции ботов и виртуальных ассистентов. И я не люблю, когда на вопрос «Ну как там с деньгами в вашем ИИ-проекте?» говорят: «Мы улучшим пользовательский опыт, а там как пойдёт».

Не-не-не. Утром деньги, а вечером проекты. 

TL;DR

Мы собрали рабочего ИИ‑агента‑разработчика, который сам анализирует задачи в Jira, уточняет детали, пишет код, запускает сборку, фиксит ошибки, создаёт MR в GitLab и отправляет его человеку на ревью. Он работает параллельно на нескольких задачах, благодаря чему суммарное время выполнения пачки задач падает почти втрое. Команда избавилась от рутины, а скорость разработки выросла без расширения штата.

Использовали: Ollama + Qwen3 Coder, PostgreSQL, Docker, GitLab/Jira API, систему строгих JSON‑действий.

Столкнулись с контекстом, «галлюцинациями», GPU и самовольными правками кода — всё решаемо архитектурой.

ИИ не заменяет разработчиков, он снимает тупую монотонную работу и экономит деньги.

Недавно купил книгу «Кванты. Как волшебники от математики заработали миллиарды и чуть не обрушили фондовый рынок», которую её автор Скотт Паттерсон написал ещё в 2010 году. Книга издана на русском языке в 2014, но я познакомился с ней только недавно и понял что в книге очень хорошо расписана хронология развития алгоритмической торговли и чем она заканчивалась. Спойлер: ничем хорошим в итоге, но в моменте очень выгодно для участников.

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

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