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

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

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

Когда 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.

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

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

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

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

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

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

Именно поэтому в Manticore Search теперь встроены аутентификация и авторизация. Функциональность добавлена в версиях 27.x и описана в посте о релизе 27.1.5 : она позволяет Manticore проверять, кто подключается и что этому пользователю разрешено делать.

Новая функциональность работает через SQL, HTTP/HTTPS-клиентов, распределённых и удалённых агентов и поддерживает репликацию.

Лучшее по нейросетям за неделю: 5 инструментов для ИИ-агентов, 6 необычных проектов и 6 вирусных экспериментов.

Без долгих вступлений.

Начнем.

Привет! Я Саша Рыжов, MLOps-инженер в hh.ru, уже три года занимаюсь развитием инфраструктуры для искусственного интеллекта. Компании, которые развивают GenAI, рано или поздно приходят к задачам по запуску LLM на собственном железе. В статье я расскажу, как обстоят дела с движками инференса в 2026 году и как запустить on‑prem-прод и не изобрести при этом велосипед.

Модель A³: как связать постановку задачи, принятие решений и организационные изменения

ИИ‑проект можно технически завершить успешно и всё равно не получить бизнес‑результата.

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

Технически ИИ внедрён. Работа компании не изменилась.

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

В 2026 году Макс Чан, CIO компании Avnet, предложил A³ — управленческий фреймворк для переосмысления роли CIO в эпоху ИИ: Architect, Augment, Amplify.

Есть жанр статей про RAG, который выглядит так: подключаем векторную базу, берём эмбеддер, сверху реранкер, для верности — гибридный поиск с BM25, и вот у нас продакшн-ready система. Двадцать строк кода, стрелочки на схеме, всё летает.

Я прошёл этот путь до конца на реальных данных. И почти каждое «правильное» улучшение из этого списка на моих данных сделало хуже. BM25 уронил метрику. Реранкер уронил метрику. Дважды, в двух разных конфигурациях. Единственное, что реально помогло, — не код, а несколько дней возни с данными и замерами.

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

В прошлой статье я рассказывал, как мы делаем онлайн IDE для .NET — дизайн, компиляция и запуск приложений происходят прямо в браузере, без сервера. Проект живёт по адресу xaml.io. С тех пор мы много чего добавили, и в какой-то момент у нас стало получаться загружать в IDE довольно крупные .NET проекты — десятки XAML, сотни C# файлов, несколько референсных проектов и пакетов NuGet.

Одна из главных возможностей — это визуальный UI-дизайнер пользовательских приложений. И у него есть особенность: чтобы дизайнер вообще что-то показывал, приложение должно быть скомпилировано, причём в актуальном состоянии. Не «когда-нибудь», а после каждой правки.

Открыли как-то в IDE один реальный проект (FamilyShow — классическое демонстрационное WPF-приложение), поправили одну строку в .cs и 84 секунды наблюдали за анимацией прогресса. С таким UX никакой интерактивный дизайн невозможен.

Сейчас та же правка занимает 5 секунд, а правка XAML-разметки на типичной странице — меньше секунды. В этой статье — как мы к этому пришли, и какие сюрпризы нам приготовили по дороге Roslyn, OpenSilver, WASM и наш собственный код.

Привет, Хабр! Сегодня хочу поделиться опытом знакомства с одним интересным инструментом, который недавно попался мне на глаза. Называется он RunHouse. Если вкратце — это попытка ответить на извечный вопрос "как развернуть корпоративный софт, не став DevOps-инженером за неделю?".

Сразу скажу, никакого скрытого пиара, просто реально полезная находка для тех, кто устал от YAML-марафонов.

Последние год-два многие наверняка заметили одну и ту же картину. Очередной «бесплатный VPN» или прокси из Telegram сначала работает нормально, а спустя несколько дней начинаются проблемы. Reels зависают через несколько секунд после запуска, YouTube периодически перестает загружать видео, Telegram бесконечно показывает Connecting, а Google AI Studio или Gemini могут отвечать ошибкой даже при использовании VPN.

Причина уже не сводится только к блокировке IP-адресов. Современные системы фильтрации все чаще анализируют не содержимое трафика, а его поведение: размеры пакетов, интервалы между ними, особенности TLS-соединения и другие косвенные признаки. Во многих случаях этого оказывается достаточно, чтобы распознать прокси или VPN без расшифровки передаваемых данных.

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