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

Вторник, час ночи. Закидываю в GPT-5.5 свой проверенный шаблон с развёрнутым CoT, тремя few-shot, ролью «опытный аналитик». Получаю мусор. Удаляю весь промпт, пишу из трёх строк — работает. Минут десять пялюсь в монитор. Половина моего трёхлетнего арсенала против reasoning-моделей либо лишняя, либо вредит. Что сдохло, что наоборот выросло в значимости, что писать под какую задачу. Без эмоциональной role-play и многословных «подумай шаг за шагом» — они сейчас только тормозят.

Искусственный интеллект уже давно вышел за рамки простых ответов на вопросы и теперь все чаще берется за полноценные рабочие процессы, где нужно не только сообразить, но и сделать. Компании постепенно учат свои системы самостоятельно разбираться с длинными цепочками операций, взаимодействовать с сервисами и доводить дело до конца без постоянного присмотра. Google на конференции I/O 2026 показала, насколько далеко зашел этот процесс, представив сразу две новые модели из семейства Gemini — 3.5 Flash и Omni, которые, по сути, закладывают основу следующего большого шага в развитии ИИ.

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

Продолжаем серию про файнтюнинг и создание DevOps-агента Oni. В первой части я собирался в отпуск и хотел, чтобы локальная моделька через OpenClaw сама мониторила ошибки и переподнимала проекты — пока я отдыхаю. Перебрал много разных моделей через Ollama и понял, что половина либо не умеет tool calling, либо ломаются на multi-step. В отпуск я в итоге не уехал — вместо этого снял VM с RTX 3090, начал учить Qwen3-14B через Unsloth QLoRA, а через неделю купил с авито старенький Dell с 3090, чтобы обучать у себя на локалке — стало интересно победить проблему.

Во второй части я пробовал разные подходы к файнтюнингу Qwen3:14b и понял: incremental delta-merge не работает. Дошёл до oni:v8 с 11/11 на Django scaffold, попытался добавить SSH/docker поверх — и модель забыла Django. Пять регрессий подряд, anchor-примеры не спасают, самый мягкий lr=1e-5 всё равно ломает. Познакомился с catastrophic forgetting, потратив пять ночей и полгигабайта удалённых GGUF-чекпоинтов. Переехал на fresh-from-base: каждая base-N с нуля от чистого Qwen3-14B, эволюционирует только датасет.

В третьей части — про дистилляцию. Hand-crafting упёрся в потолок: каждый трейс — это итерация с Claude, ревью, правки, повторная генерация, и так на каждый из тысяч примеров. Сделал локальную дистилляцию через gemma4:31b на той же 3090: сырые датасеты → фильтр → пере­формат в agent-trace → валидация → датасет. Получил внушительную базу датасетов для моего агента, не вкладывая деньги на сторону.

А эта, четвёртая часть — самая серьёзная. С неё начинается всё по-взрослому. Первые три — это «как я собрал инструмент». Тесты — это «как я понимаю, что инструмент вообще работает, и что он не работает не так, как я думаю». Без них вся история выше — самообман: цифры обучения красивые, чекпоинты лежат, в чате модель отвечает уверенно — а что она реально умеет, чего не умеет и где у неё дыры, ты не знаешь.

Большинство ИИ помогают работать быстрее. По-настоящему хорошие - делают пользователей компетентнее. Начинаешь с малого: просишь исправить письмо. Потом пробуешь сложнее - функцию на незнакомом языке. Затем поручаешь целую фичу. В какой-то момент ИИ уже кажется не стажёром, а экспертом. Сначала это впечатляет, что месяц работы укладывается в несколько дней. Но потом наступает момент, когда ИИ возвращает задачу с ошибкой. Ты не знаешь, как её исправить, и просто пишешь "попробуй другой подход", надеясь на удачу.

Привет, Хабр! Меня зовут Даниил, я программист и архитектор, разрабатываю программное обеспечение и спецификации для создания ПО в YADRO. Продолжаю цикл статей об организации рабочего места по методу Spec-Driven Development. В первой части мы настроили агента Claude Code. Во второй расскажу, как настроить harness — программную инфраструктуру, выступающую оберткой для LLM, и наконец поделюсь решением задач по методу SDD.

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

В статье будем разбираться, как архитектура обвязки помогает удерживать агента в рамках задачи: зачем нужны планировщик, генератор и оценщик, как QA-агент проверяет результат через Playwright MCP и почему по мере развития моделей саму обвязку приходится постоянно пересматривать.

Собрали статьи про системы ИИ и разработку, опубликованные на нашей DIY-платформе «вАЙТИ». Есть как материалы в стиле «бери и делай» с примерами кода, так и посты с разбором проблем при использовании систем ИИ — например, о том, почему на первый взгляд рабочая система машинного зрения на поверку оказывается неработоспособной.

Привет, Хабр! Меня зовут Алексей Васильев, я тимлид команды «Рекомендательные системы и персонализация» Sber AI Lab — Центра практического искусственного интеллекта Сбера. В нашей команде мы занимаемся исследованиями в области рекомендаций на последовательностях (sequential recommendations). Например, прослушивания музыки или просмотры карточек товаров можно представить как последовательность взаимодействий пользователя. А для моделирования последовательностей, как мы знаем, отлично подходят трансформеры: популярные варианты в рекомендациях — SASRec и BERT4Rec. Эти модели прекрасно справляются с задачей рекомендаций на основе взаимодействий, но они ничего не знают о самих товарах.

Допустим, пользователь покупает безлактозный йогурт и растительный сыр. У нас сразу появляется гипотеза: возможно, пользователь не переносит лактозу. Однако для sequential‑модели это не очевидный факт, а статистический паттерн, который нужно выучить из взаимодействий. Если данных мало, товары редкие или связи между ними плохо представлены в истории, то такой смысл легко потерять.

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

Привет, Хабр! Меня зовут Андрей Басов, я руководитель команды технической поддержки стрима корпоративных продуктов и сервисов в MWS, занимаюсь технической поддержкой и сопровождением продуктов линейки Partner Experience Platform.

В прошлом материале я рассказал о том, как мы с коллегами попробовали искать аномалии в логах наших систем с помощью методов машинного обучения. Сейчас мы провели работу над ошибками, все переработали (архитектуру, математический аппарат), внедрили генеративную LLM и Principal Component Analysis — и в итоге создали новую систему анализа жизни продуктов, которая самостоятельно балансирует, обучается, выявляет аномалии, паттерны и даже заглядывает в будущее.

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

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

Представьте семинар у физиков или математиков. Идёт автоматическая запись лекции, а затем распознавание речи в аккуратный текст. В большинстве мест современные ASR-системы справятся неплохо. Но значительная часть такой записи будет состоять из фраз вроде «интеграл от икс в квадрате до бесконечности», «сумма по i от единицы до n» или «производная по t от функции f».

Формально голос может быть распознан правильно. В расшифровке даже могут появляться отдельные символы вроде +, π или x. Но если человек произносит длинную формулу, результат почти всегда превращается в линейную фразу, читать которую физически больно. Хочется другого: чтобы система сразу понимала, где обычный текст, где математическое выражение, и выдавала не «один делить на икс плюс два», а корректный LaTeX-код, например, \frac{1}{x+2} или \frac{1}{x}+2, в зависимости от смысла.

Эта задача называется Speech-to-LaTeX или S2L: преобразование озвученных математических выражений и предложений в формальную LaTeX-запись. В отличие от обычного speech-to-text, здесь нужно распознать не только слова, но и структуру: дроби, индексы, степени, пределы, суммы, интегралы, скобки, вложенные выражения и границы формул.

Например, фраза «два делить на пи» в обычной расшифровке может остаться как «2 делить на π». Но в LaTeX она должна стать \frac{2}{\pi}. Именно такой формат нужен для статей, учебников, конспектов, Overleaf и других LaTeX-редакторов.

Несмотря на прогресс в automatic speech recognition (ASR), задача прямого преобразования озвученной математики в LaTeX долго оставалась почти неразработанной. Более того, нормальных открытых датасетов с человеческими аудиозаписями для такой задачи практически не было. В нашей работе мы попытались закрыть этот пробел: собрали открытый двуязычный датасет и сравнили несколько подходов к Speech-to-LaTeX. В статье, которую мы представили на ICLR 2026, описан датасет из более чем 66 тысяч человеческих аудиозаписей и 571 тысячи синтетических аудиозаписей на английском и русском языках. 

Анизотропия эмбеддингов не всегда зло, но «сырой» косинус часто даёт слишком размытый сигнал. Центрирование убирает общий фон и помогает увидеть различия, не разрушая локальные смысловые области. Показываю это на реальных расчётах из Obsidian‑базы.

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

Логическим продолжением будет изучение (не побоюсь этого слова) сердца машинного обучения: градиентного спуска.

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

Дано: государственная аттестация, бумажные бланки, никакого онлайн-контроля. Классический способ фальсификации: ученик начинает работу сам, потом часть дописывает кто-то другой: сосед, нанятый человек, преподаватель. Проверяющий смотрит на текст, но не оценивает почерк.

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

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

Звонил мне на днях один знакомый CIO. Питерский, ритейл, средний бизнес, ничего особенного. Слушай, говорит, надо нам с ИИ что-то делать: все вокруг внедряют, конкуренты вон что-то запустили, на отраслевом Data Summit уши прожужжали, а у меня даже плана нет. И денег, кстати, особо на это не выделили, но не суть.

Это был, кажется, пятый такой звонок за месяц.

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

Так вот, если коротко - не надо бежать.

Сам я не специалист по нейросетям. Много лет вожусь с базами данных в банках, в ритейле, в системной интеграции, и работа моя: смотреть, как данные живут в настоящих, не презентационных компаниях, и решать, что из задуманного взлетит, а что разобьётся об реальность. Через этот фильтр я и предлагаю взглянуть на нынешний шум вокруг локальных LLM, RAG и «корпоративных помощников».

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

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

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

Написал инженерный разбор про multi-agent feedback для обучения рисованию.

Что происходит, когда рисунок оценивает не один AI-критик, а «совет»: три LLM-персоны на разных моделях + четвёртый вызов-судья, который собирает их отзывы в общий вердикт.

Без хайпа: технические параметры, компромиссы и грабли из реальной реализации.

— почему это 4 логических вызова, а в two-stage режиме физически до 7; — как судья работает text-only и НЕ видит рисунок: он проверяет согласованность трёх разборов, а не пересматривает изображение; — честная latency: wall-clock = max(самая медленная персона с retry) + судья, а не сумма трёх персон; — почему council получается в 3–4 раза дороже single-critic; — где «больше моделей» оказалось хуже: слабый судья ронял качество, пришлось вводить quality gate и математический fallback; — где обычный single-critic объективно выигрывает: быстрая итерация, latency, стоимость.

Если строите multi-agent / ensemble / judge-паттерны, внутри есть конкретные грабли: галлюцинации персон, эхо плейсхолдера из промпта в ответ судьи, consensus-фильтр поверх финального вердикта.

Majestic Labs Prometheus, Kingston DC3000ME на 30,72 ТБ, TPU восьмого поколения от Google и не только... Как всегда, вендоры не дремлют и участвует в AI-гонке. И должен признать, иногда это приводит к появлению крайне неординарных решений на рынке.

Привет, Хабр! Меня зовут Сергей Ковалёв, я менеджер выделенных серверов в Selectel. В новом дайджесте собрал самые актуальные и передовые новинки в мире железа. Читайте, делитесь своим мнением — в общем, добро пожаловать под кат!

Ошибка CUDA out of memory при обучении LLM обычно превращается в бесконечный цикл случайных правок: уменьшили batch size, урезали sequence length, снизили LoRA rank — и всё равно где-то снова падает. Особенно весело становится в RL-сценариях с GRPO, vLLM и генерацией нескольких ответов на один промпт.

Поговорим о том, как перестать гадать и начать считать потребление GPU-памяти: от чтения самого текста ошибки до оценки вклада vLLM, активаций и параметров обучения. С формулами, реальными конфигами и объяснением, какие настройки действительно дают эффект, а какие только создают иллюзию оптимизации.

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

Меня зовут Артем Нигоян, я дата-сайентист в Lamoda Tech и занимаюсь разработкой ИИ-стилиста. Этот продукт помогает подбирать товары и образы для наших пользователей. В его основе наша собственная LLM с навыками стилиста — предельно гибкая и контролируемая, покрывающая максимум разных запросов от пользователей.

В августе 2025 года ИИ-стилист появился в формате Telegram-бота, а в конце декабря был интегрирован в приложение Lamoda. 

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

На Авито полно квартир за 80, 100 и 180 тысяч в месяц, которые выглядят так, будто их специально фотографировали как можно хуже. Тёмные комнаты, кривые ракурсы, пересветы, ванная как из хоррора — и всё это в объявлениях, где вообще-то пытаются сдать или продать дорогой объект.

Я решил это исправить...