Kurgan-Telecom Ru | Информационные технологии

Нижеприведенный блог был написан в 2019 году. Через год мы с коллегой усовершенствовали нашу систему прогнозирования и выиграли промышленное соревнование весной 2020 — в период начала пандемии COVID-19. По итогам того эпопейного соревнования я написала статью The Short-term Electricity Consumption Forecast Competition Under COVID-19 Lockdown Conditions (английская и русская версии). В январе 2022, прямо накануне ..., подала эти тезисы на International Symposium on Forecasting 2022. В апреле они были приняты и вопреки всем прогнозам я доехала до Оксфорда в июле 2022 и выступила с докладом. Ниже история о том, как все это начиналось...

Привет, Хабр!

Задача многоагентного обучения с подкреплением (MARL) возникает всякий раз, когда несколько агентов взаимодействуют в одной среде, чтобы совместными усилиями решить общую задачу. Например, это могут быть футболисты, юниты в StarCraft или просто множество роботов, которым нужно дойти до своих целей в одном лабиринте. Очень часто агенты внутри сред не могут общаться и полагаются только на свои наблюдения. А вот что именно агенты наблюдают и как именно могут действовать — зависит и от среды, и даже от конкретного задания внутри неё.

В существующих работах по MARL модель, как правило, обучается под одну среду, и чтобы обучить её на новой среде, архитектуру нужно адаптировать. Мы же поставили перед собой грандиозную цель — создать единую модель (foundation model), которая сможет действовать в разных средах, переносить кооперативные стратегии между ними и легко адаптироваться к новым неизвестным заданиям. Но до этого ещё далеко, и начать нужно с более простого шага, а именно создать модель с единой архитектурой, которая не требует переделки под каждую среду и может обучаться на нескольких средах одновременно.

С вами Мария Нестерова из команды «RL агенты» Лаборатории когнитивных систем искусственного интеллекта AIRI. Мы с коллегами создали метод MARL‑GPT — единую модель, которая обучается на датасетах из трёх разных сред. Центральная идея — обрабатывать наблюдение агента как последовательность и использовать для этого архитектуру трансформер. Модель мы впервые представили на воркшопе WoMAPF'26 (Workshop on Multi‑Agent Path Finding, AAAI 2026), а расширенная версия статьи прошла отбор на AAMAS 2026.

Ниже краткий рассказ о проблеме, как мы её решали и много гифок.

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

Здравствуйте, уважаемые читатели Хабра!

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

Эволюция GTD и систем ведения заметок постепенно приводит к следующему шагу: локальному AI-ассистенту, который работает не с абстрактной “памятью”, а с вашей собственной базой знаний о проектах, бизнесе, документах, задачах и решениях.

Профилирование Java‑приложений в production часто упирается не в отсутствие инструментов, а в их ограничения: CPU горит в одном месте, latency копится в другом, аллокации давят на GC, а lock contention вообще не виден в обычном CPU‑профиле.

В статье разбираем, как использовать async‑profiler для диагностики реальных Java‑сервисов: снимать CPU, allocation, wall‑clock и lock‑профили, читать flame graph и понимать, где именно приложение тратит ресурсы.

Когда говорят про RAG, его часто описывают как простой способ улучшить LLM‑систему: добавить поиск по внешним данным, найти релевантный контекст, передать его модели и получить более точный ответ.

На уровне идеи это действительно выглядит логично.

Но в реальной системе RAG — это не только способ обогатить ответ. Это отдельный операционный слой, который влияет на задержку, размер prompt, количество input tokens, стоимость запроса, качество ответа, SLA и требования к наблюдаемости системы.

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

Это не промышленный benchmark и не попытка получить универсальные цифры. Скорее серия контролируемых экспериментов: посмотреть на механику RAG pipeline и компромиссы, которые часто остаются за кадром, когда RAG описывают просто как «поиск + LLM».

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

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

Как-то так случилось, что многие сервисы стали укрупняться и совмещать несколько инструментов в одном. Я задался вопросами: «Хорошо это ли плохо?» и «Насколько такие мегакомбайны будут востребованы через год, два, пять?» Порассуждал об этом в статье.

В своих прошлых статьях «Три пути к 4K» и «Нейросетевой апскейлинг дома» я рассказывал о выборе софта, базовых принципах нейросетевого апскейлинга и реставрации исходников уровня DVD и VHS. Но время идёт, навыки растут, и вот от простого (кусок дерева -> игрушка) мы переходим к сложному (игрушка -> коллекционная фигурка), а именно на территорию 720p–1080p исходников, Blu-ray и вебки.

И именно здесь для меня началось то, что я назвал «долиной отчаяния».

Вы берёте отличный исходник, выбираете крутую open-source модель, запускаете рендер… и всегда получаете что-то странное на выходе. Цвета поплыли, контраст упал, на градиентах неба появились какие-то искажённые линии, а ваш FPS в процессе ужасен. Кажется, что ПО сломано, а ИИ-модели взбесились и вместо «качественного апскейла» портят картинку.

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

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

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

В сегодняшней статье разберём, как на базе версии Apache Superset с поддержкой MCP и связки Foundation Models от Cloud.ru можно собрать рабочего AI-агента аналитика, который фразу «построй мне аналитику по продажам» за минуты превращает в полноценный дашборд с возможностью скейлинга в продакшене.

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

Рассказываю, как написал кроссплатформенную .NET-библиотеку для глобального перехвата клавиатуры и мыши. Под капотом: WH_KEYBOARD_LL на Windows, CGEventTap на macOS и polling через XQueryKeymap на Linux. Один интерфейс, три реализации, ноль внешних зависимостей.

Привет. В предыдущих статьях этого цикла мы разбирали, как Kubernetes-объекты читаются (первая — informer и кэш в controller-runtime) и записываются (вторая — Server-Side Apply, patch’и, managedFields). Сегодня — про их жизненный цикл.

Между kubectl apply и появлением объекта в etcd проходит целая цепочка: admission chain, мутирующие и валидирующие вебхуки, schema-валидация, встроенные плагины. Между kubectl delete и реальным исчезновением объекта может пройти от миллисекунд до часов — в зависимости от того, какие на нём финализаторы и какая стратегия каскадного удаления выбрана. Механизм при этом универсален для любого ресурса: Pod, Deployment, ваш CRD — жизненный цикл у всех один.

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

Как-то так получилось, что я NLP-инженер, который закончил Московский государственный лингвистический университет. Мне нравится ковыряться в коде и мозгах нейросетей, при этом я стараюсь не забывать, на каком фундаменте выросла трендовая ныне область под названием Natural Language Processing (NLP).

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

Представьте, что у вас есть многослойный пайплайн обработки данных.

Ширина слоя — 5000 узлов. Количество слоёв — 60. Общее число узлов — 300 000.

Каждую секунду приходит 10 новых событий (изменений на входе). Наивный подход — пересчитать всё с нуля — будет перебирать все 300 000 узлов на каждое обновление. При 10 обновлениях в секунду это 3 млн вычислений узлов в секунду. А если ширина слоя 100 000 и слоёв 100? Получаем 10 млн узлов на пересчёт. Компьютер не справляется.

Финансовые системы предъявляют жёсткие требования к производительности.

Риск-департамент запрашивает переоценку портфеля из 200 000 опционов. Маржинальная система требует пересчитать все позиции клиентов после сильного движения рынка. Алгоритмический трейдер хочет оценить Greeks для тысяч потенциальных сделок за миллисекунды.

Стандартные подходы на .NET дают сбой по трём причинам.

Причина 1: Объектная модель

Каждый опцион становится отдельным объектом в куче. Виртуальные методы, ссылки, разрозненное расположение в памяти. Для 200 000 объектов — миллионы байтов, GC-паузы на сборку, промахи кэша процессора.

Причина 2: Позлементные вычисления

Вызов функции ценообразования в цикле — плохо. Процессор не может векторизовать код, потому что не видит всю картину целиком. SIMD-инструкции простаивают.

Причина 3: Аллокации в горячем пути

Каждый вызов new double[100000] для хранения промежуточных результатов — это давление на GC. В 24/7 сервисе такие аллокации накапливаются и вызывают непредсказуемые паузы.

Требования к решению

Допустим, вы делаете симуляцию города. Или RTS. Или RPG с открытым миром. И у вас в сцене одновременно находится 5, 10, а то и 20 тысяч живых существ. У каждого свои цели, приоритеты, эмоции, социальные связи.

Ваша архитектура AI начинает трещать по швам.

Классический подход — дать каждому NPC компонент с методом Update() — перестаёт работать где-то после 500–1000 объектов. Дальше начинаются проблемы:

Краткая справка об основных действующих лицах:

Lia Montelongo - модель, инструктор по фитнесу и йоге, преподаватель танцев, эксперт в вопросе персональных тренировок. Всемирно извесна по ролям в серии Mortal Kombat - Синдел в Mortal Kombat 3 (1995), Тани в Mortal Kombat 4 (1997) и Сарины в Mortal Kombat Mythologies: Sub-Zero (1997).

Уже многие написали и рассказали о таком полезном инструменте для организации своих заметок как Obsidian.

Если кто еще не знает, Obsidian - это бесплатное Electron-приложение, доступное на всех основных платформах, созданное Эрикой Сю и Шидом Ли уже в далёком 2020 году. В этой программе итересным UI-решением, позволившим привлечь внимание аудитории, стало визуализация графа заметок, как некой общей карты,мозга, базы знаний, состоящией из md-документов. Для меня на приктике эта фича оказалась самой бесполезной по сравнению с другими возможностями платформы. Встроенные плагины для ежедневных заметок, тэги, мощный поиск, шаблоны, работа с изображениями и многое другое + больше колличество стороннних плагинов на любой вкус и возможность при необходимости написать их самому. Вот, что мне пригодилось на самом деле. Я действительно за короткое время перенес все свои заметки из разрозненных источников в одно место и программа стала моим ежедненвным инструментом. Поэтому я стал ее использовать на нескольких устройствах.

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

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

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

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