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

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

Привет, Хаброжители! Вы когда-нибудь отлаживали такой компонент пользовательского интерфейса, где достаточно нажать в неверном порядке несколько кнопок – и приложение валится? А не доводилось ли вам ломать голову, пытаясь отследить, почему в некоторых случаях форма отправляется нормально, а в других — отказывает? Такие неприятные сценарии зачастую возникают по одной базовой причине: непредсказуемое управление состоянием. Мы привыкли полагаться на булевы флаги, рассеянные по коду инструкции if-else, тем временем надеясь, что наше приложение будет правильно работать, чего бы пользователь ни делал в интерфейсе.

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

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

Дэн Кеннеди — тот самый автор, чьи книги всегда имеют в названии приписку No B.S. (Без соплей). Его стиль узнаваем с первых страниц: никаких теорий про команду-семью, никакого «сотрудники — наше главное достояние». Только железные рецепты, проверенные на деле, и полное отсутствие желания кому-либо понравиться.

Когда я впервые увидел backtrace паники в Rust, я решил, что это просто аналог исключения. Вызвал panic!, стек раскрутился, деструкторы вызвались, поток умер. Примерно как throw в C++ или raise в Python. Потом я попытался передать панику через FFI-границу, и программа молча упала без backtrace. Потом обнаружил, что catch_unwind перестаёт работать, если в Cargo.toml поменять panic = "unwind" на panic = "abort". Потом выяснил, что двойная паника (когда деструктор паникует во время раскрутки) убивает процесс безусловно, и это не баг, а так задумано.

Оказалось, что за простым panic!("oops") стоит сложная система из сменных runtime-ов, платформозависимой раскрутки стека и кучи граничных случаев...

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

Но иногда бывает совсем наоборот. В начале рабочего дня вы беретесь за дело, а к обеду даже не успели въехать в контекст. Три сообщения, небольшой созвон буквально на 10-15 минут — и вот уже ваш мозг судорожно переключает процессы.

В этой статье попробуем разобраться:

— существует ли на самом деле то самое состояние потока или это просто красивый термин?

— почему разработчики так легко его теряют и сколько реально времени уходит на возвращение к задаче после отвлечения?

— какие простые организационные и технические практики помогают удерживать фокус и погружение?

Привет, Хабр! Меня зовут Виктор Шумилов, я ведущий сетевой инженер РТК-Сервис. В повседневной практике эксплуатации и технической поддержки телекоммуникационных сетей мы регулярно сталкиваемся с широким спектром инцидентов, напрямую влияющих на доступность сервисов, от единичных сбоев до массовых отказов. В данной статье мы рассмотрим практические подходы к локализации неисправностей в сетях доступа GPON FTTH на примере оборудования Huawei линейки MA58xx.

Весь мир — театр, а люди в нем актеры. Какой бы долгой или краткой не была пьеса, рано или поздно наступает финальный акт, поклон и занавес. Жизнь человека подобна вышеизложенному, и смертность присуща всем, независимо от образа жизни, состояния здоровья или гастрономических предпочтений. Помимо попыток отдалить неминуемый конец, важную роль играет то, как, а точнее в каком состоянии, его встречать. Одним из основных негативных эффектов старения является потенциальная потеря когнитивных функций, что разительно влияет на качество жизни человека. Научное сообщество многие годы пытается найти рецепт молодости, если не для всего тела, то хотя бы для мозга. Ученые из Техасского университета A&M (Колледж-Стейшен, Техас, США) кажется нашли его. Они создали назальный спрей, которой снижает воспалительные процессы и восстанавливает энергетические системы мозга, тем самым продлевая его «качественную» работу в рамках когнитивных функций. Из чего состоит чудо-спрей, как именно он работает, и каковы его перспективы в клиническом применении? Ответы на эти вопросы мы найдем в докладе ученых.

Привет, Хабр! Примерно полтора года назад я решил обновить наш рабочий Nexus Repository OSS — и был «приятно» удивлён: Sonatype отказались от OSS-версии и перешли на Community Edition с лимитами на количество репозиториев и компонентов. Платить за Pro я не хотел, переходить на Artifactory тоже — JFrog ушёл из России ещё в 2022-м. Так что пообещал себе разобраться с этим «на следующих выходных» и написать что-то своё. Выходные закончились, а я всё ещё пишу код

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

Последние полгода я активно применяю LLM в своей работе. Автокомплитом от Github Copilot я пользуюсь с момента начала бесплатного бета-тестирования, а с выходом Opus 4.5 стало возможно отдавать железяке на реализацию целые блоки логики. Нужно только организовать виртуальную клетку, внутри которой он будет вынужден писать работающий код.

Агентные системы ломаются не на сложных задачах и не на плохих моделях. Главная причина — недетерминизм LLM: температура, апдейты моделей, дрейф мира. Как отлаживать то, что не воспроизводится? Как перезапустить упавший пайплайн не с нуля? Как вообще понять поведение системы, если каждый запуск чуть-чуть другой?

Event Sourcing — паттерн, где состояние не снапшот, а иммутабельный лог событий. Недетерминизм он не убирает, но даёт инструменты для работы с ним.

Нижеприведенный блог был написан в 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 в процессе ужасен. Кажется, что ПО сломано, а ИИ-модели взбесились и вместо «качественного апскейла» портят картинку.

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