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

Привет, Хабр! Меня зовут Дмитрий, руковожу отделом рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

Команда обычно тратит месяцы на проектирование и запуск. А за неделю до релиза выясняется, что не работает форма оплаты, сайт не проходит по мобильной версии или у него нет обязательных документов. Типовой чеклист запуска ограничивается дизайном, а техническую приемку и новые требования РКН он не покрывает. Есть и отдельная тема: поисковая выдача.

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

Привет, коллеги. Я Евгений Пуляев, разработчик в группе компаний Далее. Имел дело с разными CMS/CMF, но MODX Revolution всегда занимал особое место в моем профессиональном опыте. 

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

Чтобы докопаться до правды, я проанализировал 7 млн доменов Рунета. В статье рассказываю, как проводил исследование и что оно показало.

Мне кажется когда мы начинаем обсуждать с ИИ какое-то более менее конкретное техническое решение, которое, очевидно, должно существовать, мы обычно ожидаем чтобы он фактически дал подтверждение и недостающие детали. Но мне при общении с ИИ-агентом, в первую очередь интересно, сможет ли агент в ответ на некоторый сложный вопрос заставить меня (спрашивающего) изменить точку зрения то есть фактически опровергнуть исходную посылку-гипотезу на которую, технический вопрос, так или иначе всегда опирается! По моему это основной признак интеллекта — свобода не только отстаивать свою точку зрения, но и пытаться «заразить» этим собеседника.

Так получилось, что у меня сложились практически идеальные обстоятельства для такого эксперимента. Я в принципе знал идеальное решение с самого начала, но в повседневной рутине оно было скрыто множественными наложениями от текущей работы. По той же причине занятости текущей работой я не мог в полной мере сосредоточиться (а главное не старался) чтобы достать и отряхнуть от наложений идеальное решение, а начал сессию с ИИ агентом чтобы в том числе посмотреть насколько эффективной является его помощь в сложных вопросах, по которым невозможно сформулировать какой-то простенький промт, но которые требуют итеративной сессии вопросов-ответов уточняющих вопросов, разъясняющих вопросов-исправляющих вопросов, …

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

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

Это отличный, глубокий вопрос, который бьет прямо в особенности того, как устроены большие языковые модели (LLM) и как у нас замыливается «цифровой глаз». ...

Дисклеймер: редактора, корректоров у меня нет, вычитать, нормально, столько текста я вряд ли в состоянии.

Но начать я хочу с более детальной формулировки задачи.

Kubernetes незаметно стал платформой по умолчанию для ИИ и машинного обучения. Запускаете ли вы серверы notebook-ов для дата-сайентистов, планируете распределённые задачи обучения, настраиваете гиперпараметры или оркестрируете многоэтапные ML-пайплайны. Эти нагрузки всё чаще оказываются в кластере Kubernetes. Kubeflow — один из самых популярных способов собрать этот стек, причём Kubernetes-нативным путём: каждая возможность описана как CRD (Custom Resource Definition, описание пользовательского типа ресурса Kubernetes).

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

Команда VK Cloud перевела статью о плагине Headlamp Kubeflow, который закрывает этот разрыв и выводит пользовательские ресурсы Kubeflow прямо внутри универсального Kubernetes UI. Это проработанный пример паттерна, которому может следовать любая насыщенная CRD платформа: встречать операторов там, где они уже работают, и показывать им истину на уровне кластера.

Сам Headlamp это расширяемый веб-UI для Kubernetes, поддерживаемый в рамках Kubernetes SIG UI и лицензированный под Apache 2.0. Он работает как десктопное приложение или внутри кластера, а через систему плагинов кто угодно может добавить полноценные представления для пользовательских ресурсов.

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

Управление знаниями на производстве часто вспоминают только тогда, когда что-то уже пошло не так: станок встал в разгар смены, ключевой технолог ушел к конкурентам, а единственный человек, который «знал, как это запустить», заболел. В этот момент внезапно выясняется, что у компании нет не только плана «Б», но и даже внятного описания плана «А» — все держится на памяти людей и разрозненных файлах в сетевых папках (если не вообще в бумажных талмудах, напечатанных на пишущей машинке ещё при Хрущёве).

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

Признавайтесь: вы пользуетесь std::collections::HashMap примерно каждый день и ни разу не задумывались, что под ним. А под ним, если коротко, сидит алгоритм от Google. С Rust 1.36 (это лето 2019-го) стандартный HashMap это порт SwissTable, той самой структуры из абсейловского flat_hash_map. До этого там был Robin Hood hashing, и если вы где-то ещё видите описание std-мапы как «linear probing and Robin Hood bucket stealing», знайте: оно протухло, актуальная документация уже пишет «quadratic probing and SIMD lookup».

И вот «SIMD lookup» это самое интересное. Весь фокус скорости SwissTable держится на одном байте служебных данных на элемент, который сканируется по 16 штук за одну инструкцию процессора.

В статье глянем, как это устроено внутри, почему ваша мапа по умолчанию устойчива к hash DoS и платит за это скоростью, когда в проде стоит переходить на FxHash, и почему низкоуровневый RawTable существует, но в публичном HashMap его спрятали.

Будет много кода и немного ассемблерной романтики.

Каждый день я использую qBittorrent. Это отличный торрент-клиент, стабильный и кроссплатформенный. Наверное, работает лучше чем любой другой торрент клиент. Но интерфейс у него на Qt Widgets, и на Windows 11 он выглядит не нативно(+ лично для меня не хватает некоторых вещей, о которых расскажу в статье)

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

Так, день за днём, через месяц получился WinBitTorrent

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

Есть несколько способов захвата ценных астероидов или их частей.

Когда Atlassian объявила о завершении продаж Opsgenie, я сначала отреагировал как нормальный инженер: решил ничего не переписывать. Потом календарь напомнил, что нормальность имеет срок действия. Продажи Opsgenie прекратились 4 июня 2025 года, а поддержка завершится 5 апреля 2027 года. После этого сервис станет недоступен, а немигрированные данные будут удалены. Это не слух из рабочего чата, а официальная позиция Atlassian (условия и даты завершения Opsgenie).

Предлагаемый путь ведёт прежде всего в Jira Service Management, причём Atlassian описывает автоматизированную миграцию данных и конфигурации (официальная страница миграции). Для многих компаний это разумный маршрут. В моём случае требование было другим: сохранить существующую self-hosted Jira, не превращать замену on-call инструмента в миграцию всей сервисной модели и получить контроль над данными, интеграциями и deployment.

Я посмотрел альтернативы. Ближе всего по общей идее оказался OpsKnight: проект позиционирует себя как open-source self-hosted платформу для incident response, on-call, routing и status pages (официальный сайт OpsKnight). На бумаге соседство было почти семейным. Но мой набор требований включал автоматическое создание задач именно в нашей Jira, Slack и eXpress, прозрачную передачу L2 в L3, русский и английский интерфейс, простое развёртывание и предсказуемое поведение в небольшом внутреннем контуре. В моём тестировании OpsKnight с этим набором не совпал и не дал нужной уверенности. Это не универсальный вердикт проекту, а описание моего опыта и моей планки риска.

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

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

Для меня главный вопрос звучит не так: «Может ли искусственный интеллект работать с 1С?»

Он уже работает.

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

Поэтому проблема часто заключается не в отсутствии информации. Проблема в том, что эту информацию долго вводить, сложно искать, необходимо постоянно проверять, а для ее анализа иногда приходится выгружать данные в Excel, строить дополнительные отчеты и обращаться к специалистам. Именно здесь искусственный интеллект может дать наиболее заметный результат. При этом я бы не стала противопоставлять искусственный интеллект и 1С.

У них разные роли.

1С отвечает за достоверные данные, учетные правила, права доступа и бизнес-процессы. Искусственный интеллект помогает работать с неструктурированной информацией: понимать обычный человеческий текст, распознавать документы и изображения, находить закономерности и формулировать подсказки.

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

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

Похоже, мое личное раздражение идет в русле массового тренда. Исследования Gartner показывают: половина потребителей в США выбирают бренды, которые полностью отказались от генеративного ИИ в коммуникациях. А 61% пользователей требуют от разработчиков софта, чтобы те добавили функцию принудительного отключения любых интеллектуальных ассистентов в интерфейсах. В индустрии все громче звучит запрос на категорию AI-Free. 

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

Профайлер показывает write() и worker файлового логгера среди верхних стеков. Однако системный профайлер не знает, какая из тысяч строк вывода в лог породила нагрузку. Отключать логирование совсем — ужасное решение. Как же связать файловый ввод-вывод с конкретными строками вывода в лог, каналами и backend?

Классическая сцена. Команда выкатывает релиз, деплой проходит зелёным, kubectl rollout status рапортует об успехе — а в графиках ингресса на минуту вырастает горка пятисотых. Не тысячи, обычно доли процента, но стабильно, каждый деплой.

Дальше начинается фольклор. «Ну это же рестарт, при рестарте всегда так». «Добавьте ретраи на клиенте». «Деплойтесь ночью». Самый частый вариант — на графики просто перестают смотреть в момент выката.

На самом деле rolling update умеет проходить вообще без потерь, и readiness-проба тут ни при чём — она отвечает за другую половину задачи. Потери происходят на выключении подов, и причина в том, что удаление пода — это не последовательность шагов, а гонка.

В Древнем Риме говорили: «Mens sana in corpore sano» — в здоровом теле здоровый дух. Два тысячелетия спустя мы, айтишники, превратили эту мудрость в её полную противоположность: здоровый дух, сидящий в нездоровом теле перед монитором. Наш позвоночник принимает форму вопросительного знака, а шея начинает напоминать ржавый механизм — повернуть голову можно только всем корпусом, издавая при этом характерный хруст.

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

— То, что мы создавали для идентификации личности, по сути готовый трекер движений. Дай ему только интерфейс и он превратится в игру. Осталось только придумать, во что играть…

Попробовать разминку с Джонни и Джулией

Бесплатно, без смс, без регистрации и без подвоха. Под музыку или без! Нам не жалко. Мы вообще-то хотим просто шею размять, а не бизнес на этом строить.

Сегодня всем известно, что создать прототип на базе LLM можно буквально за вечер. Но вот сделать этот прототип готовым к продакшену — задача совсем другого уровня сложности. Как научить модель работать с вашими данными? Как дать ей память и способность рассуждать? Как развернуть приложение так, чтобы оно не падало под нагрузкой и не разоряло вас на оплате API?

На эти вопросы отвечает новая книга «Изучаем LangChain»  Майо Ошина и Нуну Кампоса. Нуну Кампос — один из основателей LangChain, так что читатели получают материал из первых рук!

Хабр, привет! Меня зовут Дмитрий Тарасов, я исследователь в лаборатории FusionBrain AIRI. Мы недавно свозили нашу свежую работу — “Progressive Cramming: Reliable Token Compression and What It Reveals” —на ICML 2026, и здесь я хочу рассказать, о чём она.

Начнём с почти магического факта. Год назад в замечательной работе “Cramming 1568 Tokens into a Single Vector and Back Again” моего коллеги по AIRI Юры Куратова и его команды было показано, что в один‑единственный входной эмбеддинг замороженной LLM можно «упаковать» до 1568 токенов текста так, что модель потом слово в слово его восстанавливает. Полторы тысячи токенов — это несколько абзацев — в одном векторе размерности несколько тысяч, невероятная плотность памяти. Разбор этой статьи уже был на хабре.

У нас этот результат вызвал не только восторг, но и подозрение. Одно дело — восстановить текст, и совсем другое — понимать его. Что, если «идеальная» реконструкция на самом деле не хранит смысл? В нашей статье мы:

– покажем, что стандартный протокол token cramming скрывает катастрофические провалы, и предложим более честную процедуру — progressive cramming;

– исследуем траектории оптимизации сжатых последовательностей;

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

Поехали.

Привет, Хабр! Меня зовут Владимир, и это пятая часть цикла статей по написанию и обучению небольшой decoder-only LLM с нуля. В прошлых частях мы собрали и обучили модель LinguaLaboratoriumMechanicus — миниатюрную GPT-like LLM во вселенной Warhammer 40K. В этой части упакуем её в формат Hugging Face: сделаем конфиг и обёртку под transformers, сохраним и зальём модель на Hub.

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

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

Для тех, кто ищет способы побороть перегрев ультрабуков, но к жидкому металлу не готов.

Коротко суть проблемы: ультрабук это здорово, это всего кило весу. Но как и с любым ПК всегда хочется чтоб он был максимально быстр. А быстрый = горячий. Только жаль, что любая система охлаждения - это про габариты. Чем крупней радиаторы и вентиляторы, тем больше тепла она может отвести.

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