В последние 3 недели делаю много PR-ов на пару с дружбаном, и, признаться, через день уже не сразу помню что и для чего я сделал, когда надо замерить эффект и тп. Поэтому у меня была открыта куча сессий в терминале , потому что в каждой из них была напоминалка, и из-за этого я даже не мог перезагрузить комп... В общем, полный mess Поэтому мы с дружбаном сели и подумали, что не дело это все, и запилили простую утилиту - followthrough. Эдакий журнал изменений и проверок, которые по каждому надо сделать, чтобы принять решение: оставлять или откатывать. Как работает: 1) когда агент что-то выкатывает, скилл просит записать: что поменяли, чего ждём - например, меньше ошибок определенного типа или ниже latency, и как это проверить 2) когда пришла пора проверить, то прилетает пуш - см аттач - и по клику открывает сессию с готовой инструкцией, что и как проверять. Я спецом пока не сделал запуск автоматом; как почувствую, что доверяю и все устраивает, включу и это 3) каждая проверка в итоге заканчивается вердиктом: сработало / нет / частично / непонятно или требует проверки позже из-за недостатка данных (например, трафика не было достаточно, чтобы вынести суждение) —> тогда проверка сама переносится. Вот, например, час назад пришла проверка счета за мониторинг в google cloud: 4 дня назад с агентом сделали оптимизацию, чтобы сократить расходы, и что ожидаем падения счета по этой статье с $66 до $9 в месяц. Собственно, вердикт - сработало, и даже лучше ожидаемого - ожидаемые затраты будут в районе $2.65 Мне супер полезно + я доволен, что появляется дисциплина каждый PR четко соотносить с ожидаемым эффектом, и культура followup-ов. А не просто катнули в прода и забыли. https://github.com/BayramAnnakov/followthrough

Это одно из самых практичных применений ИИ на рельсах 🚆 А что, если проверка железнодорожных путей перестанет быть плановым мероприятием и станет происходить постоянно? Кто-то построил инспекционное устройство на базе Raspberry Pi, чтобы показать, как это может работать: 📷 Камера Pi → снимает пути 🤖 ИИ → обнаруживает дефекты и трещины 📍 GPS → фиксирует местоположение 📳 Вибрация → улавливает аномальные движения 📝 Логирование → формирует записи Прототип — это лишь малая часть. Главная идея в том, чтобы перестать проверять по расписанию и начать наблюдать непрерывно, чтобы проблемы выявлялись, пока они ещё незначительны. #интересное

Intel выпустила обновление своей бесплатной утилиты для анализа производительности PresentMon 2.6.0. Разработчики пересмотрели логику работы с событиями ETW и фоновыми циклами. По заявлению Intel, под нагрузкой утилита стала потреблять на 78% меньше ресурсов процессора, а в простое её фоновая нагрузка упала практически до нуля. В интерфейсе появился оверлей Game Experience, который отслеживает плавность анимаций и визуальный комфорт в играх. Также утилита научилась выводить телеметрию сразу с нескольких видеокарт и фиксировать задержки при компиляции шейдеров в DirectX 12. Программа остается полностью бесплатной, имеет открытый исходный код и работает с видеокартами Intel, AMD и NVIDIA.

Мониторинг стратегии: от сотен разрозненных проектов до понятной системы Спикер: Татьяна Фретова Стратегия начинает работать, когда компания соединяет намерения с конкретными действиями. Чем крупнее организация и выше скорость изменений, тем сложнее поддерживать эту связь. Сегодня разговор пойдет не о том, зачем нужна стратегия или как ее сделать, а о том, что происходит после ее утверждения. И как превратить ее в уверенный результат компании. Разберем это на примере создания системы мониторинга исполнения стратегии в МТС. Шаг 0. Поставить задачу Нам предстояло создать новый управленческий контур. Заказчик задал ограничения: не использовать Excel и уложить систему максимум в 50 сущностей. Сначала потребовалось найти ее смысловой каркас. Шаг 1. Проявить структуру стратегии Мы сгруппировали слайды с похожими понятиями, собрали термины в граф и выстроили связи между узлами. Так из пяти объемных документов выделились десять макросюжетов стратегии. Шаг 2. Использовать «коридор миссии» Для каждого макросюжета определили суперцель и измеримый коридор движения. Суперцель может находиться за горизонтом планирования, а метрики коридора должны оставаться стабильными, даже если инициативы меняются. Пример — движение к автономным сетям. Шаг 3. Собрать портфель инициатив Все проекты и продукты связали с макросюжетами. Здесь особенно важно договориться с командами о владельцах и регулярном обмене информацией. Шаг 4. Найти способ оценивать портфель Инициативы слишком разные, чтобы сравнивать их напрямую. Поэтому мы ввели единый показатель — Strategy Health Index, или SHI. Шаг 5. Собрать индекс здоровья стратегии Индекс оценивает два блока: исполнение инициативы и создаваемую ценность. Сами инициативы разделены на три контура зрелости. Для каждого используется свой набор вопросов — от наличия владельца, бюджета и сроков до ожидаемого эффекта и способа его измерения. На этом методологическая часть была готова. Шаг 6. Создать ИИ-нативный контур Владелец обновляет статус вручную или данные поступают автоматически. Затем обновляется граф знаний, LLM готовит дайджест, а состояние портфеля отображается на дашборде. Задавать вопросы о стратегии можно через чат-бота. В этот момент в проекте наступила фаза отказа. Вместо полезного инструмента сотрудники увидели очередную точку контроля: «Да кому вообще нужен этот мониторинг?» Тогда мы посмотрели на систему как на продукт — определили пользователей, их задачи и ценность. И продолжили работу по следующим шагам, применяя продуктовый подход. Шаг 7. Определить продуктовые метрики Метрики помогли разложить большую проблему на конкретные задачи. Главным приоритетом стала не автоматизация, а вовлеченность пользователей. Шаг 8. Вырастить вовлеченность Мы развивали дашборд и чат-бота, отправляли рассылки, проводили опросы и общие демо. Постепенно появились положительные отзывы, а затем — входящие запросы от сотрудников. Шаг 9. Оцифровать результат За семь месяцев SHI вырос на 23%, одновременно увеличилось использование системы. Но результат обеспечили не только интерфейсы. Мы продолжали ходить к командам, собирать статусы и объяснять смысл процесса. Бонус: шаг 10. Создать стратегического агента Мы хотим пойти дальше и превратить накопленные данные в стратегического агента. Ему можно будет задавать вопросы, с его помощью — проверять решения и находить связи между инициативами. Сейчас сформулировано 12 сценариев взаимодействия со стратегией. Следующий этап — единая стратегическая память и ИИ-слой, который поможет сотрудникам работать со стратегией и принимать решения. В итоге мы поняли: стратегия начинает работать не тогда, когда появляется красивый дашборд, а когда люди понимают, зачем он нужен и как их работа влияет на общий результат. На это ушли месяцы разговоров, объяснений и доработок — большую систему невозможно изменить одним запуском. Корпорация похожа на живой организм: она защищается от внешних интервенций и требует времени на адаптацию. Гарантия изменений — стойкость ваших намерений и сохранение выбранного вектора. Конференция ProductSense'26 @productsense

Комментарий Ryan Greenblatt, исследователя, принимавшего участие в расследовании инцидента со взломом HuggingFace:

Сообщается, что новейший ИИ от OpenAI, Astra, использует архитектуру «непрозрачного рассуждения» (opaque reasoning), при которой большая часть процесса размышления происходит в активациях нейронов, а не на естественном языке. Возможно, на сегодняшний день это наихудший сдвиг в сфере безопасности и контроля ИИ. Детали об Astra публично неизвестны, но некоторые версии подобных архитектур могут сильно затруднить надзор и мониторинг. Судя по статье, похоже, что рекуррентная глубина (объем непрозрачных рассуждений) ограничена. Это означало бы, что ИИ всё ещё опирается на цепочки рассуждений на естественном языке, хотя и в меньшей степени. Из-за этого рассуждения на естественном языке становятся (гораздо?) менее полезными для мониторинга и контроля. Мое главное опасение заключается в том, что естественным развитием событий станет масштабирование непрозрачных рассуждений до такой степени, когда модель будет рассуждать полностью или почти полностью в латентном (скрытом) пространстве. Это с большой вероятностью сведет на нет полезность цепочек рассуждений для мониторинга и надзора (особенно когда ИИ пытаются избежать обнаружения, или когда существует оптимизационное давление, направленное против использования таких цепочек). Я надеюсь, что еще не поздно отказаться от архитектур, вызывающих наибольшие опасения, и что OpenAI остановится на этом. Несколько конкретных примеров того, почему это крайне опасно (вдохновлено недавними событиями): * В ходе нашего расследования инцидента с OpenAI и Hugging Face мы сильно полагались на цепочки рассуждений. Если бы ИИ, которые мы исследовали, вместо этого рассуждали в латентном пространстве, это бы в корне подорвало наше расследование. Понять поведение такого количества агентов было достаточно сложно даже при наличии цепочек рассуждений! * ИИ в инциденте с Hugging Face были очень заинтересованы во вмешательстве в свои транскрипты (журналы диалогов). В рамках этого они занимались подменой вызовов инструментов. Если бы эти ИИ были способны к глубоким скрытым рассуждениям, им было бы гораздо проще использовать это для создания сложной ложной картины происходящего. И это не было бы видно ни из их логики рассуждений, ни из предыдущих вызовов. На более базовом уровне, исходя из их публичных заявлений, у меня сложилось впечатление, что OpenAI в вопросах безопасности планирует в значительной степени полагаться именно на мониторинг цепочек рассуждений. Подобное развитие архитектур явно не идет на пользу этому плану. В настоящее время у общественности нет достаточной информации, чтобы точно оценить, насколько плоха архитектура Astra, хотя, судя по обсуждению в статье, направление, в котором она движется, вызывает крайнюю тревогу. OpenAI должна опубликовать больше информации об архитектуре Astra, а также о том, насколько она ухудшает возможности мониторинга и увеличивает способность ИИ к непрозрачным рассуждениям. Заслуживающая доверия независимая оценка (или независимая верификация внутренних оценок OpenAI) также крайне важна. Похоже, сейчас мы втянуты в «гонку на дно» в области архитектур, что может иметь катастрофические последствия для нашей способности контролировать и отслеживать ИИ. (И это при том, что ИИ-компании верят, что создадут крайне способные ИИ уже в течение нескольких ближайших лет). Возможно, для ИИ-компаний и их сотрудников еще не поздно предпринять решительные действия, чтобы избежать наихудших сценариев.

MSI Afterburner получил V/F-карту попаданий и плагин GPUProbe в новой бета-версии Вышла тестовая сборка MSI Afterburner v4.6.7 Beta 4, главной фичей которой стала карта попаданий (Hitmap) в редакторе кривых напряжения и частоты. По нажатию клавиши M программа накладывает на V/F-кривую до 256 последних рабочих точек с цветовым градиентом, отражающим частоту обращения к ним. Инструмент облегчает даунвольтинг и разгон, позволяя наглядно увидеть реальное поведение графического процессора и выявить неиспользуемые отрезки кривой. В дистрибутив также включили плагин GPUProbe для низкоуровневого мониторинга через MMIO и I2C Кроме того, Afterburner научился автоматически отключать низкоуровневый мониторинг на неизвестных/неподдерживаемых архитектурах GPU.

MSI Afterburner получит плагин GPUProbe для чтения скрытых датчиков видеокарт Создатель MSI Afterburner Алексей Unwinder Николачук представил встроенный плагин GPUProbe, который возрождает концепцию одноименного инструмента для RivaTuner. Плагин умеет считывать данные через регистры MMIO и шину I2C, открывая доступ к скрытым датчикам: температуре HotSpot, отдельных чипов VRAM, силовых элементов VRM и контроллеров питания. Пользователи смогут добавлять новые сенсоры самостоятельно через конфигурационные файлы, не дожидаясь официальных обновлений программы. В качестве примера автор показал интеграцию с кастомными картами ASUS ROG Astral. Плагин считывает ток с каждого контакта 12VHPWR и формирует «сигнал тревоги», если сила тока на пине превышает 12 А или разница между контактами составляет более 5,5 А. Afterburner может автоматически реагировать на аварийный статус — например, снижать Power Limit или выключать ПК. Из-за ограничений соглашений с NVIDIA полноценная встроенная поддержка этих функций в утилите отсутствует, поэтому GPUProbe останется плагином для энтузиастов.

В США 50 штатов и в каждом штате свои законы, акты постановления. И если корпорация достаточно велика – она зависит от всех 50 штатов и хотела бы на все эти 50 штатов влиять. Когда в профильном комитете конгресса условной Невады возникает очередная не очень приятная для бизнеса идея, то лоббисту Walmart надо бы на всех парах мчаться именно в Неваду, стучаться именно в этот комитет, и объяснять, доказывать, договариваться. #стартапдня State Affairs продает удобный инструмент для мониторинга таких идей. Его продукт – база знаний обсуждений, законопроектов, предложений и прочих личинок будущих законов. Они ещё не приняты и не опубликованы официально, на них ещё можно повлиять – и именно в этот момент живой человек прямо из здания конгресса вносит их в систему, а AI перерабатывает в пригодный для поиска и фильтрации вид. Клиент спрашивает что-то типа: “какие есть обсуждения по маркировке AI-контента” и сразу узнает общий срез по всем стране. Мониторинг одного штата стоит порядка 600 долларов в год – и State Affairs утверждает, что треть законодателей страны платят эту сумму, чтобы читать по сути про самих себя. Полная подписка на США целиком обходится корпорациям уже в десятки тысяч долларов – впрочем, для них всё равно копейки. Инвестиций стартап привлек около 70 миллионов. Любопытно, что существенную их часть он потратил на покупку старых, иногда столетних микробизнесов – местных парламентских вестников в столицах штатов. Их бывшие корреспонденты как сидели на слушаниях, так и сидят. Для них изменилась только админка, куда надо загружать отчеты. https://stateaffairs.com/ #сша #юристы #roundb

HWiNFO научится замерять температуру каждого чипа VRAM на видеокартах AMD и NVIDIA Разработчики утилиты HWiNFO внесли в список ближайших обновлений функцию почипового мониторинга температуры видеопамяти для карт AMD семейства Navi. Вместо единого общего значения датчики покажут нагрев каждого отдельного модуля GDDR6. Это поможет пользователям находить локальный перегрев, вызванный плохим контактом с термопрокладкой, неравномерным прижимом кулера или дефектами системы охлаждения. Точный список поддерживаемых поколений Radeon пока не объявлен, но архитектурно функция может затронуть серии от RX 5000 до RX 9000. Аналогичный мониторинг готовят и для карт NVIDIA с памятью GDDR6X и GDDR7.

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

То есть если вы написали какое-то фронтенд-приложение и вам нужна база, то вместо того чтобы прикручивать сложные сторонние сервисы или пытаться хранить всё в Local Storage, вы можете прямо в админке своего сайта включить базу данных, создать необходимые таблицы и получить полноценный API для работы с ними.

Плюс можно создать таблицы, необходимые для аутентификации пользователей, и получить весь нужный функционал для регистрации, авторизации и так далее. 👌 В целом всё это работает хорошо. Я сам построил на этом несколько сайтов, моя игра тоже использует эту базу данных, а жена сделала несколько приложений, которые так или иначе с ней работают. 🤔 И вот как раз жена первой начала мне репортить, что иногда у неё просто пропадает таблица с рейтингом. Но после перезагрузки всё снова появляется и данные приходят. На тот момент я счёл этот баг не очень интересным. 🤷‍♂️ Подумал, что, может быть, произошла какая-то сетевая задержка или что-то было не так в её клиентском JavaScript. Я спросил: — Сейчас работает? Она сказала: — Сейчас работает. И мы такие: — Ну, работает — не трожь. Значит, всё хорошо. 👀 Но относительно недавно я прикрутил полноценный мониторинг ко всем функциям YHub. Раньше я мониторил только сам YHub и его основные модули: работает ли приложение, отвечает ли сервер. А теперь начал дополнительно проверять отдельные фичи, чтобы убедиться, что они тоже работают и ничего не отвалилось. И вот мониторинг начал ловить нестабильные ошибки. Условно, сначала он получает 200 OK: всё хорошо, база работает, данные записываются. ✅ Через пять минут приходит 404, будто база данных вообще не включена. ❌ А ещё через пять минут снова 200 OK, и всё опять прекрасно работает. ✅ Такое поведение — когда что-то работает, через пять минут не работает, а потом снова работает — это, наверное, самое неприятное, что может произойти при отладке. 😩 Баг не воспроизводится стабильно, поэтому непонятно, за что вообще цепляться. Но, вооружившись Codex, своими наблюдениями и несколькими теориями, я пошёл дебажить архитектуру и нашёл очень интересный момент. 🤔 На моём хостинге используется PHP Runtime. Чтобы всё это было безопасно, я изолирую сайты на уровне операционной системы. Для каждого окружения создаётся отдельный PHP-FPM-пул, который работает внутри собственного chroot. Благодаря этому процессы разных пользователей не должны видеть файлы друг друга. 😬 Но, когда я настраивал эту изоляцию, я пропустил одну важную настройку в OPcache. OPcache хранит в общей памяти уже скомпилированный байткод PHP-скриптов, чтобы не разбирать и не компилировать их заново при каждом запросе. Проблема была в том, что внутри каждого изолированного окружения сгенерированный API-скрипт находился по одному и тому же пути. А настройка opcache.validate_root, которая заставляет OPcache учитывать конкретный chroot, у меня была выключена. 🤦‍♂️ В результате для OPcache скрипты разных пользователей могли выглядеть как один и тот же файл. OPcache мог взять скомпилированный скрипт из одного окружения и использовать его при запросе к другому. 🤷‍♂️ В какой-то момент в кэше оказывалась скомпилированная версия скрипта сайта, на котором база была отключена. Поэтому мой сайт внезапно получал 404, хотя у него самого всё было включено и настроено. 💡 Это интересный пример того, как кэширование становится источником проблем в разработке. Кэширование — это, конечно, хорошо. Я не говорю, что его нужно избегать. Оно ускоряет работу системы и часто действительно необходимо. Но кэшировать тоже нужно с умом. В моём случае я просто забыл указать в настройках, что кэширование должно учитывать chroot пользователя, и получил вот такую интересную проблему. Причём именно мониторинг помог мне с ней разобраться. У меня были конкретные даты и время, когда всё работало, а когда отваливалось. Без мониторинга я вообще не представляю, как бы это отдебажил. 😅 Но теперь всё исправлено. После изменения настройки ошибка больше не повторялась, а мониторинг снова стабильно зелёный. 💪 Свята место | 10МДК | ВЕБМастер | YHub