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

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

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

Так и родилась идея, которую я в итоге оформил в виде скилла DOF-Core (Degrees of Freedom - степени свободы). Базовый принцип даже не мой - я о нем читал лет 10 назад и он меня впечатлил. Ниже расскажу, как устроена эта идея и почему мне кажется, что математика тут важнее хороших намерений.

Как определить, на чём сфокусироваться, если в компании множество вызовов: техдолг, неоптимальная архитектура и проблемы надёжности?

Привет, Хабр! Я — Иван Нещадин, работаю тимлидом в компании Авито. Сейчас я руковожу двумя командами Arch и Bridge. В этой статье по мотивам доклада для TeamLeadConf я расскажу, как в Авито мы создали SWAT-команду, которая быстро решает самые проблемные задачи и живёт между миров платформы и продукта. Также подробно опишу, как снижаем хаос в архитектуре и улучшаем надёжность.

Это материал будет полезен всем, чья компания доросла до большой архитектуры и её качество стало сложно контролировать. Он основан на личном практическом опыте и описывает задачи, с которыми мы сталкивались и решали. 

Архитектура решений – мост между бизнесом и технологиями, и книга "Практическое руководство для архитекторов решений" дает практическую базу для успешного движения в данном направлении. Она предназначена для разработчиков и ИТ-специалистов, которые хотят сделать первые шаги в новой роли и уверенно закрепиться в профессии архитектора решений. Ее фокус - на той промежуточной области, которую часто путают либо с архитектурой приложений (код, фреймворки, внутреннее устройство системы), либо с корпоративной архитектурой (стратегия развития компании в целом). Это издание станет надежной базой для тех, кто переходит от разработки отдельных приложений к проектированию решений, приносящих пользу всему бизнесу.

До обновления API LLMCOD работал на Qwen 3.6. Модель справлялась, но по мере роста числа клиентов и усложнения промптов (длинные базы знаний, многошаговые диалоги, агенты) стало понятно: нужен более свежий бэкенд с лучшим качеством推理 и более эффективным использованием GPU.

Цель — получить максимум от имеющегося железа (Tesla V100-SXM2-32GB), не покупая новый GPU.

Генеративный ИИ демонстрирует знатный прогресс в последнее время — даже вроде как решил одну из задач тысячелетия, правда, с весьма существенными оговорками. Оставим в стороне вопросы финансовые, насколько устойчива вся схема финансирования этих компаний.

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

Данная статья о том, что если компании, эксплуатирующие ИИ, не ставят цели улучшения пользовательского ПО, то все усилия по строительству дата‑центров, производству чипов и памяти, совершенствованию моделей — не приведут к улучшению этого самого ПО. По факту эта статья является отсылкой к классической статье «Почему новый дизайн Gmail такой медленный?», написанной задолго до прихода генеративного ИИ в массы.

Представьте: на дне реки проложен трубопровод, по которому транспортируется сырьё широкая фракция легких углеводородов (ШФЛУ) от газоперерабатывающих заводов.

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

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

Способ рабочий, но долгий и опасный, а добрую половину года им вообще не воспользуешься. 

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

Холмс, я убрал 993 лишних IPC-вызова, и моё приложение стало тормозить в два с половиной раза сильнее. В логах было тихо. Бэкенд на Rust молчал. На границе с WebView творилось что-то необъяснимое…

Собрать бесплатный конвейер новостей на связке Google Таблицы + Gemini API + Telegram просто, пока не упрёшся в жесткий лимит Google Apps Script: 6 минут на запуск и долгое ожидание ответов LLM.

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

В статье покажу конкретный рабочий приём: как распараллелить независимые запросы к Gemini через UrlFetchApp.fetchAll(), уложить обработку 50 анонсов в 20 секунд вместо двух минут и при этом не сломать бесплатные квоты API.

QEMU — это не просто виртуализация с KVM. Его главная cуперсила — способность запускать программы, скомпилированные для одной архитектуры, на совершенно другом процессоре. Безо всякой поддержки со стороны хоста. Например, запустить прошивку для ARM-микроконтроллера на x86-ноутбуке.

Как это работает? Под капотом QEMU скрывается JIT-компилятор под названием TCG (Tiny Code Generator). В этой статье мы разберем его устройство на практических примерах для RISC-V и посмотрим, как инструкции превращаются из одного машинного кода в другой, как формируются блоки трансляции, и зачем там нужны longjmp и цепочки блоков.

В своей статье «Научная истина» я показал, что научная истина — это результат консенсуса научного сообщества, который сейчас формируется в научной прессе. Сейчас эта пресса образует закрытый клуб взаимопризнаваемых научных журналов, которые по некоторым ключевым вопросам имеют негласное, но единое мнение. Основу этого мнения составляет представление о том, что научная истина, как конечное знание, существует, и есть теории, в которых это знание представлено. По этой причине эти теории являются неприкасаемыми, а потому для любых статей, ставящих это под сомнение, доступ в официальную научную прессу закрыт. Этот запрет является интернациональным, в чем я убедился лично.

Короткий дисклеймер: Проект живой, ленту бот крутит дважды в сутки. Почитать готовый результат можно в моём Telegram-канале Bio_news, а покритиковать тут. А теперь к тому, как вся эта система устроена.

Те, кто работал в IntelliJ IDEA, PyCharm, GoLand или WebStorm, привыкли управлять Docker прямо из IDE: запускать и останавливать контейнеры, смотреть логи, работать с томами не выходя из редактора.

В 2022 году JetBrains приостановила продажи и поддержку для пользователей из России. IDE стали недоступны через официальные каналы, а плагины из JetBrains Marketplace (в том числе и Docker-плагин) вместе с ними.

Именно по этой причине консорциум OpenIDE принял решение реализовать поддержку Docker с нуля!

Про неё сегодня и поговорим.

Есть такое уютное заблуждение: выключил Wi-Fi и мобильные данные – и все, ты невидимка. Спокойно можно строить теории заговора. На деле всё немного иначе. Даже в полном офлайне встроенные датчики смартфона продолжают исправно работать и копить информацию о том, чем вы занимались. Разбираемся, как смартфоны на самом деле следят за нами без сети, чего стоит опасаться по-настоящему, а что — просто повод для паранойи.

Ретроград, лунный календарь и блуждающий час: собираем необычные усложнения из мира механических часов для Wear OS просто с помощью формул.

Vivaldi предоставляет вам все необходимые инструменты для работы в сети. С нашим последним обновлением Vivaldi 8.2 мы даём вам больше — с полной поддержкой расширений на Android, так что вы можете настроить свой мобильный браузер именно так, как вам нужно.

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

Тут возникает вопрос о способности формулировать управленческие запросы на уровне руководства. Но ещё более важный вопрос - к тому, кто запускает проектный офис: хочет ли он быть Head of PMO или им казаться?

Ответ зависит от того, будут ли им решаться формальные задачи или управленческие.

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

Клиент нажимает «Оплатить». Приложение отправляет POST /payments. Проходит пять секунд, и HTTP-клиент падает по таймауту. Ретрай-политика, которую кто-то настроил год назад по гайду, ждёт двести миллисекунд и отправляет запрос ещё раз. Через минуту клиент видит в выписке два списания.

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

Первый вывод: надо выключить retry на POST. Хорошо, выключили. Теперь у нас платежи, про которые никто не знает, прошли они или нет. Поддержка разбирает их руками. Ущерб никуда не делся, он просто переехал на другой счёт.

Второй вывод: надо добавить заголовок Idempotency-Key. Добавили. Дедупликацию сделали в middleware поверх Redis. Через полгода двойное списание случается снова. Потому что Redis пережил failover и потерял ключи. Или потому что повтор пришёл через сутки из файла клиринга, а в файле никакого HTTP-заголовка нет.

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

Retry сам по себе всего лишь тактика. Он работает там, где контракт уже есть. Без контракта retry не делает систему устойчивее. Он делает её быстрее ломающейся.

В 2013 году я купил книгу про то, как делать приложения, и загорелся. И вот спустя 13 лет, я все же выпустил свое первое приложение — дневник тренировок, от первого запроса в Claude Code до публикации в RuStore и Google Play. Рассказываю, как без навыков программирования я сделал свое первое рабочее приложение.

В Russian Business меня позвали, чтобы я наладила процессы внутри команды.

До перезапуска проект много лет существовал под брендом Rusbase. В сентябре 2024 года Альфа-Банк стал стратегическим партнёром RB.RU и приобрёл долю в компании, а 7 августа 2025 года медиа перезапустилось под новым брендом Russian Business.

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

Очень быстро у этой системы обнаружились четыре больных места.

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

— Никто не понимал, на каком этапе находится материал. Статья уже на вычитке? Ждёт визуалов? Зависла у автора? Чтобы выяснить это, снова приходилось поднимать переписки.

— Хорошие темы терялись. Редактор мог предложить сильную идею, начать собирать фактуру, отвлечься на срочную задачу — и через месяц тема оказывалась погребена под сообщениями.

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

Держать всё это в голове невозможно. А увидеть полную рабочую картину, если она разбросана по чатам, — тем более.

Называется Контур Оракул.