Привет! Это Степан Малькевич, руководитель группы рекомендаций ленты ВКонтакте (AI VK).
За прошедшие месяцы 2026 года время в ленте выросло на 11%. За этими цифрами — серия изменений, каждое из которых сделало свой вклад в рост метрик. Сейчас расскажу, что мы обновили и что из этого вышло.
Привет, Хабр! Мы — Александр Забурдаев, Ксения Золина, Даниил Марценюк, Илья Трофименко, Илья Кулешов — студенты мастерской по сервисам и платформам ИИ в Инженерно-математической школе НИУ ВШЭ и VK. Хотим поделиться опытом, который мы накопили, пытаясь перестать кормить весь речевой сигнал одной и той же нейросети целиком, и дать разным экспертам разбираться с разными типами шума.
Речь пойдёт о задаче улучшения качества речи (Speech Enhancement, SE) и о том, как получилось интегрировать в неё разреженную смесь экспертов (sparse Mixture of Experts, MoE). Это архитектура, которая в языковых моделях уже стала стандартом, а в обработке аудио до сих пор не прижилась.
Модель мы назвали SESAME — Speech Enhancement with Sparse Adaptive Mixture of Experts. Она построена на базе MP-SENet. В ней стандартные полносвязные блоки внутри трансформера заменены на разреженный MoE-модуль. Код проекта доступен на GitHub.
Зачем вообще понадобилась очередная модель шумоподавления, когда их и так десятки — расскажем ниже. А заодно разберём, какие трюки из мира LLM в аудио работают, а какие нет (например, Expert Choice) — и почему.
Привет! Меня зовут Михаил Трапезников, я руководитель группы рекомендательных технологий в AI VK.
В одной из прошлых статей мы рассказали, как устроен нейропрофиль пользователя в рекомендациях VK. Обновление стало фундаментом для нового подхода к ранжированию. Сегодня расскажем о том, как нам удалось перейти от бустинга к нейросетям и как устроена архитектура нейроранкера.
Привет, Хабр. Меня зовут Сергей Врулин, я Team Lead в команде агентов VK AI Space — корпоративной платформы для создания и запуска AI-агентов.
В июле 2026 года VK AI Space представила многоуровневую память для корпоративных AI‑агентов. Она позволяет агентам сохранять и переиспользовать информацию на всех этапах работы — в текущем диалоге и в рамках долгих проектов. Потенциально это позволит ускорить подготовку ответов и уменьшить число повторных задач.
В этой статье я во всех деталях расскажу, как именно мы проектировали память для агентов: от теории к реализации, с разбором ключевых решений и компромиссов.
Apache Kafka — популярная система потоковой обработки событий, предназначенная для сбора, хранения и передачи больших объемов данных в режиме реального времени. Она используется тысячами компаний и разработчиков для построения высокопроизводительных, отказоустойчивых и масштабируемых решений в области аналитики данных, IoT, микросервисов и многих других сфер.
Однако у Kafka есть один важный нюанс: «из коробки» у нее нет графического интерфейса (GUI), что затрудняет понимание текущего состояния кластера, диагностику неполадок и эффективное управление инфраструктурой и самим сервисом, особенно для начинающих пользователей или тех, кому сложно взаимодействовать с консольными инструментами.
Поэтому для комфортной работы с Apache Kafka активно используются специализированные UI-инструменты. Например, ранее для облачного сервиса Managed Kafka от VK Cloud мы использовали Provectus Kafka UI, но в рамках развития сервиса решили заменить UI на более современный и функциональный.
Меня зовут Никита Суровегин. Я продукт-менеджер в команде VK Data Platform, VK Tech. В этой статье я расскажу, с чего мы стартовали, какие инструменты проанализировали и что выбрали в итоге.
Однажды за один вечер мне пришлось разобрать двенадцать ошибок, и почти все прятались в конфигурации и связях между компонентами. Модель отвечала пустой строкой, хотя в логах не было ни одной явной ошибки. Агент не мог достучаться до Ollama, панель не проходила авторизацию, ключ отклонялся из-за прав доступа, а gateway показывал зелёный статус, но будто не замечал изменений в конфиге.
В этой статье хочу разобрать три случая, сопроводим их реальными репликами агента и выводами команд. Посмотрим, как модель имитирует выполненную работу, почему при переполнении лучше не увеличивать окно, а искать причину по логам, и как скилл по расписанию оказался удобнее панели управления.
Статья написана на основе моего вебинара, можно посмотреть его в записи.
Объектные хранилища, работающие по протоколу S3, уже давно стали де-факто стандартом для работы с неструктурированными данными — от бэкапов корпоративных систем до наполнения озёр данных (Data Lake) для аналитики. Однако переход от простого использования API к построению на базе S3 отказоустойчивой и безопасной инфраструктуры часто оказывается сложнее, чем кажется на первый взгляд, а многие встроенные механизмы остаются невостребованными. И связано не столько с отсутствием бизнес-потребности, сколько с недостаточным пониманием того, как именно эти функции работают.
Чтобы устранить подобные «слепые зоны», в статье разберём, как с помощью объектных хранилищ решаются ключевые задачи обеспечения безопасности, катастрофоустойчивости и эффективности хранения.
Привет! На связи Артём Матвеев из команды AI VK Research. Мы занимаемся фундаментальными и прикладными исследованиями в области рекомендательных систем, поиска и генеративного искусственного интеллекта.
Сегодня я расскажу про нашу работу, которая была принята на воркшоп End-to-End Customer Journey Optimization конференции KDD 2026. KDD — A*-конференция и одна из ведущих мировых площадок в области машинного обучения и искусственного интеллекта, где обсуждают развитие рекомендательных систем, поиска, рекламы и других AI-технологий.
Наша статья называется Session-Level Optimization for Large-Scale Retrieval using REINFORCE with Multi-Step Off-Policy Correction. Рассказываем, как мы научили модель рекомендаций сразу оптимизировать долгосрочную удовлетворённость пользователя (long-term user satisfaction).
Представьте себе баг-репорт: все шесть подов в статусе 1/1 Running, Readiness зелёный, kafka-agent на брокерах отдаёт 204. А кластер мёртв: оператор бесконечно крутит реконсайл и валится в TimeoutException: Timed out waiting for a node assignment. Call: describeMetadataQuorum. Если зайти на том контроллера, можно увидеть, что __cluster_metadata-0/quorum-state: leaderId выставлен, а appliedOffset в 0. Ни одна запись метаданных не применена. JVM живые, raft-лог на диске растёт, и при этом ни один под не написал в stdout ни строки следующие восемь часов. Это не выдумка, а реальный баг-репорт Strimzi от 25 мая 2026, и к нему мы ещё вернёмся.
В Kafka 4.x больше нет привычного «запасного выходa» в виде ZooKeeper: метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис.
Раньше чтобы с этим справиться в Kafka существовал ZooKeeper, отдельная система со своими инструментами, ансамблем и культурой восстановления. В версии 4.x его нет, и в документации от процедуры остался только линк на 3.9. Метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис.
В этой статье расскажем, что делать в такой ситуации и как восстанавливать этот кворум, чтобы не случилось ситуации, описанной выше.
Привет! Меня зовут Михаил Трапезников, я руководитель группы рекомендательных технологий в AI VK.
Одна из главных задач рекомендательных систем внутри крупных экосистем — найти взаимосвязь в разных паттернах потребления контента и применить в алгоритмах. Пользователь может смотреть длинные видео в VK Видео, короткие клипы в VK Клипах и листать ленту ВКонтакте, но каждый из этих сигналов описывает его интересы лишь частично. Для решения этой задачи мы разработали нейропрофиль пользователя, который формирует единое представление его интересов на основе всех типов взаимодействий с контентом внутри разных продуктов.
В этой статье я расскажу:
Как мы создали нейропрофиль — единую трансформерную модель, которая объединяет сигналы пользователя из разных сервисов VK и формирует целостное представление о его интересах.
Как устроена его архитектура, какие данные она использует и как обучается на миллиардах взаимодействий с контентом.
Как кросс-доменный подход помогает улучшать рекомендации в VK Видео, VK Клипах и других продуктах экосистемы.
База данных — бизнес-критический компонент любой ИТ-инфраструктуры, поэтому вопрос обеспечения ее доступности и отказоустойчивости обычно находится в центре внимания. Однако, фокусируясь на отказоустойчивости, компании нередко недооценивают риск переполнения диска. При этом подобные ситуации могут оставаться незамеченными до полной остановки записи БД, например при заполнении отдельного раздела, где хранятся данные или WAL.
Привет, Хабр. Меня зовут Александр Шмелёв. Я Team Lead команды разработки Databases, VK Tech. В этой статье я расскажу о рисках и причинах переполнения дисков, а также рассмотрю несколько способов предотвращения подобных проблем.
Security Gate — это наша внутренняя AppSec-платформа, объединяющая инструменты и практики для проверки безопасности кода, зависимостей и других компонентов разработки. Платформа помогает находить потенциальные проблемы безопасности, приоритизировать результаты сканирования и встраивать проверки в привычный процесс работы с кодом.
В статье разберём, из чего состоит Security Gate, как устроены приоритизация находок и интерфейс и какие возможности доступны разработчикам.
Демо нагрузки и реальная нагрузка различаются. Демо всегда быстрое — если поставить модель и прогнать пару запросов, то latency вас обрадует, а TTFT, вероятнее всего, будет приятным. Но когда сервис неделю живет под реальной нагрузкой, начинаются проблемы: p99 растет, память утекает, а однажды прилетает OOM на запросе, который вчера проходил без проблем.
Я Стас Погоржельский, технологический евангелист VK Cloud, неоднократно наблюдал этот сценарий в демонстрационных средах. Инференс редко выходит из строя сразу и явно; как правило, его работа постепенно ухудшается, оставаясь незаметной до достижения критического состояния.
Ниже я разберу четыре механизма, приводящие к деградации производственной среды на длительном интервале: фрагментацию KV-кэша, нехватку памяти (OOM) при работе с длинным контекстом, блокировку очереди (head-of-line blocking) внутри батча и расхождение метрик p50 и p99. Для каждого случая опишу внутреннее поведение системы, способы воспроизведения проблемы и метрики, сигнализирующие о надвигающемся инциденте.
В 2024 году была опубликована интересная статья, в которой описано, как за 54 дня обучения Llama 3 405B кластер Meta из 16 384 карт H100 пережил 419 внезапных прерываний, примерно по одному каждые три часа. 58,7% из них пришлись на GPU и их память. Процессоры за то же время отказали дважды. Свежее по такому масштабу никто ничего не публиковал, но тренд на Kubernetes с тех пор только усилился: по опросу CNCF за 2025 год, 82% пользователей контейнеров гоняют кубер в проде и 66% компаний с genAI-моделями держат на нем инференс.
Сам Kubernetes до сих пор как будто бы уверен, что отказы лечатся рестартами. Для stateless-сервиса это правда, а вот для пода с GPU нет: если контейнер упадет, то kubelet поднимет его заново на том же мертвом устройстве, и все пойдет по кругу.
Я Стас Погоржельский, технологический евангелист VK Cloud. Про то, как раздавать GPU через DRA, на Хабре уже писали, про отказоустойчивость кластеров в целом тоже. Эта статья про то, о чем обе умалчивают: что происходит после того, как выданное устройство умерло. Мы посмотрим на это наглядно: соберем отказный стенд, отберем у пода GPU и посмотрим глазами kubectl, кто и когда об этом узнает. А потом разберем механизмы 1.36, с которыми из этой ситуации впервые можно выйти без вечного Pending и без убийства ноды целиком.
В нашей компании исторически сложилась децентрализованная модель управления данными. Каждая из бизнес-вертикалей развивала собственные аналитические системы и хранилища, выбирая технологии и инфраструктуру независимо. В результате сформировался ландшафт из разрозненных решений с дублирующей функциональностью и растущим числом физических кластеров. На момент принятия решения о переходе в облако инфраструктура насчитывала более 10 отдельных железных кластеров под Airflow, Hadoop и смежные технологии. Совокупный объём аналитических данных достиг 0,5+ эксабайта (EB).
Такая архитектура создавала не только технические, но и бизнес-ограничения. Обмен данными между вертикалями был затруднён: мешали как различия в инфраструктуре, так и юридические тонкости, связанные с оформлением доступа. Поддерживать такой ландшафт становилось всё сложнее. Поэтому в компании решили построить единую платформу для работы с данными, чтобы увеличить скорость и качество принятия решений на основе данных как в runtime, так и в отчётности и А/Б-тестах.
Я Василий Ципиди, операционный руководитель OneDWH VK. Вместе с техническим руководителем OneDWH VK – Олегом Виноградовым расскажем сегодня о том, как мы подошли к миграции 0,5+ EB данных на единый облачный стек, какие архитектурные решения выбрали, чтобы обеспечить целостность данных и как перестроили процессы, чтобы гарантировать предсказуемость SLA на новых мощностях.
Управление десятками и сотнями Helm-релизов быстро перестает быть тривиальной задачей, особенно когда появляются зависимости между релизами, CRD, несколько окружений и своя логика деплоя.
Меня зовут Владимир Фидунин, я работаю в команде мессенджера VK WorkSpace. В статье расскажу, как мы прошли путь от Puppet + Helm до Helmwave и почему в итоге он стал для нас универсальным инструментом управления Helm-релизами.
Привет, Хабр! Меня зовут Михаил Рязанский, я руководитель группы технической аналитики в Дзене. Группа включает в себя команды DWH, антифрода, аналитики модерации и ML‑аналитики. Вместе с Марком Хабаровым, лидом команды ML‑аналитики, мы расскажем про наш инструмент для анализа результатов А/Б‑тестов и про интеграцию в него LLM. Получилось интересно, местами — больно. Но обо всём по порядку.
Привет, Хабр! Я Оля Шишенина, отвечаю за обучение и развитие сотрудников VK. Хочу рассказать про внутреннее мероприятие для инженеров, которое мы провели этой весной: Фиксатон VK — трёхдневный марафон по багфиксам, на котором разработчики чинили баги не только в своих командах, но и в смежных продуктах VK. Решения прошли многоэтапный фильтр от общего пула задач, через проверку кода, QA-ревью при подготовке к релизу.
Победители фиксатона получили Nintendo, Playstation, а главному победителю по баллам в индивидуальном зачёте мы подарили Niva Legend — это отличная машина для того, кто любит фиксить и тюнинговать.
Привет, Хабр! На связи Александр Сабко, Виктория Белявская и Сергей Павлухин, из мастерской по прикладному ИИ Инженерно-математической школы НИУ ВШЭ и VK.
Сейчас текстовые данные все чаще рассматриваются как источник информации о психологическом и эмоциональном состоянии человека (автора текста) — это особенно важно для задач, связанных с психологическим консультированием, анализом пользовательских коммуникаций и мониторингом эмоционального состояния. В тексте нам часто важна не просто тональность, а динамика эмоционального состояния автора.
При этом большинство существующих решений в анализе эмоций работают слишком обобщенно — одни определяют общую тональность текста, другие решают задачу бинарной или многоклассовой классификации эмоций на уровне всего текста. Такие подходы плохо подходят, например, для психологически-нагруженных текстов, так как эмоции могут быть динамическими и проявляться в разных фрагментах текста — агрегированная метка не может это показать.
Есть и другая проблема: для обучения моделей, которые смогут улавливать локальные эмоциональные признаки и выявлять динамику их смены, не хватает специализированных русскоязычных корпусов, формализованных схем разметки и воспроизводимых методик оценки качества работы модели. Без этого сложно понять, действительно ли модель научилась распознавать психо-эмоциональные признаки текста или просто угадывает общий эмоциональный фон.
В статье мы расскажем, как мы выстраивали схему разметки на интервью с практикующими психологами, какие источники текстов взяли, что внутри инструмента, и что получилось с дообучением Qwen-3.
ClickHouse — один из самых востребованных инструментов для хранения и анализа больших объемов данных, обеспечивающий высокую производительность и наблюдаемость сервисов и приложений. Благодаря этим параметрам многие компании внедряют его в свои ИТ-инфраструктуры для решения задач аналитики, логирования и мониторинга. Однако, несмотря на широкое распространение, практика показывает, что далеко не все команды до конца осознают все особенности и нюансы работы с этой системой, что может приводить к неэффективному использованию ресурсов, ошибкам в проектировании и снижению общей производительности.
Привет, Хабр. Меня зовут Александр Кривяков. Я пресейл-архитектор VK Data Platform, VK Tech. В этой статье я расскажу об основных принципах работы ClickHouse, а также покажу возможные архитектурные решения и типичные сценарии применения системы.
