Обновить

Все потоки

Сначала показывать
Порог рейтинга

Дайджест Рег.облака за июнь

В июне открыли новый регион Москва-3 и запустили там GPU-инстансы на базе NVIDIA Blackwell. А также поделились исследованием о тратах на GPU-серверы. Ниже — главное.

Открыли регион Москва-3

Новая зона размещения работает в дата-центре Datahouse «Магистральный-1» уровня Tier III. У региона отдельный control plane и собственные вычислительные ресурсы, поэтому инфраструктуру можно масштабировать без риска перегрузить текущие мощности.

Запустили GPU-инстансы на базе NVIDIA Blackwell

В регионе Москва-3 ввели в эксплуатацию GPU-инстансы на архитектуре NVIDIA Blackwell. В основе — ускорители NVIDIA RTX 6000 Pro Blackwell Server Edition с 96 ГБ видеопамяти GDDR7. Доступны конфигурации до 30 vCPU, до 190 ГБ оперативной памяти и до 1,7 ТБ NVMe на инстанс, ресурсы тарифицируются по модели почасового потребления. По сравнению с A100 стоимость задач снижается до трех раз.

Исследование: траты на GPU-серверы выросли в четыре раза

За полтора года крупный и средний бизнес увеличил расходы на GPU-конфигурации вчетверо, при этом общее число серверов почти не изменилось. Компании переходят с бюджетных решений на более производительные — H200, H100, A6000.

Несколько цифр из исследования: доля премиальных GPU-конфигураций выросла с 51% до 78%. На конфигурации с видеопамятью до 24 ГБ приходится 46% спроса, на решения от 80 ГБ — 27%. Основные сценарии — ИИ и машинное обучение (33%), рендеринг (30%), тестирование и разработка (25%).

Желаем всем продуктивного месяца и спасибо, что следите за обновлениями Рег.облака!

Теги:
0
Комментарии0

DDoS-атака не всегда очевидна. Резкий рост нагрузки может оказаться как настоящей атакой, так и вполне легитимным всплеском трафика после рекламной кампании или важного инфоповода. В совместном материале с ITSumma разбираем, как быстро отличить одно от другого, на какие метрики смотреть в первую очередь и какие действия предпринимать в первые минуты после обнаружения проблемы.

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

Отдельное внимание уделяем двум основным моделям защиты — Always-On и On-Demand. Рассматриваем, чем они отличаются, в каких случаях каждая из них эффективнее, а также какие компромиссы приходится учитывать при выборе между постоянной фильтрацией трафика и подключением защиты только во время атаки.

Теги:
0
Комментарии0

Как на собственных серверах настроить систему сбора и хранения данных с датчиков и снизить нагрузку на команду эксплуатации

Собрать данные с датчиков — это полбеды. Главная боль — заставить Kafka, PostgreSQL и ClickHouse стабильно работать в приватном облаке без выгорания команды на Day-2-операциях и ручном масштабировании stateful-сервисов.

На вебинаре покажем, как на Deckhouse Kubernetes Platform (DKP) и managed-сервисах упаковать IoT-сценарии и аналитический контур в единую платформу, чтобы снизить стоимость эксплуатации и уйти от DIY-подхода к data-инфраструктуре.

Зарегистрироваться на вебинар

В программе:

  • Разберём схему event-driven-платформы и разделение операционного и аналитического контуров.

  • Покажем live-demo: ingest событий с датчиков, потоковая обработка и вывод в дашборды.

  • Проверим, как паттерны из умного дома масштабируются до промышленного IoT на DKP.

  • Разберём жизненный цикл data-сервисов (backup, scaling, observability) и то, сколько времени занимает их обслуживание.

Бонусы: промокод на все курсы Deckhouse Академии.

Будет полезно DevOps и SRE-инженерам, инфраструктурным и платформенным командам, enterprise-архитекторам и всем, кто строит IoT- и data-платформы в private cloud или on-prem.

Спикер — Дмитрий Гайворонский, менеджер по развитию направления Deckhouse Data Orchestration.

Регистрируйтесь и подключайтесь 10 июля в 12:00 (МСК). 

Теги:
0
Комментарии0

Партнерский митап МФТИ & RЕU Data Science Club: развитие технологий семантического поиска

9 июля проведем открытый эфир с Data Science Club РЭУ им. Г. В. Плеханова. Поговорим о семантическом поиске — технологии, которая помогает находить информацию по смыслу запроса, — а также о задачах, связанных с RAG, энкодерами и защищенным поиском.

Митап объединит студентов, выпускников и экспертов МФТИ и РЭУ — будет два доклада на стыке ML и информационной безопасности.

На встрече выступят:

🔹 Пелагея Пашинская — middle MLE в MWS, MLE стартапа VedAI, экс-руководитель REU Data Science Club, студентка программы НИУ ВШЭ «Прикладные модели в ИИ», обучалась в «Школе 21», спикер курса ML School Pro.

Тема доклада: «Кастомизация энкодера для RAG через дообучение».

🔹 Сергей Михайлович Куриленко — ведущий разработчик средств автоматизации в компании-вендоре в области ИБ.

Тема доклада: «Разработка и оценка эффективности нового метода защищенного семантического поиска с использованием гомоморфного шифрования».

📌 Формат: онлайн

📅 Когда: 9 июля (четверг), 18:30 (Мск)

🔗 Регистрация

Telegram: https://t.me/mipt_events_bot?start=dl-1782379614134

ВКонтакте: https://vk.com/app6379730_-224205661#l=25&auto=1

Теги:
0
Комментарии0

Почему документация FineBI не научит вас FineBI

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

Александр Ларин, руководитель центра обучения и технической поддержки GlowByte, собрал карту источников в одной статье: документация и Learning Center от FanRuan, бесплатные видеокурсы, русскоязычные Telegram-сообщества, где вопросы закрываются быстрее, чем через поддержку, и бесплатные образовательные ретриты с кейсами Tele2, Уралсиба и Циан.

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

Читать разбор: https://habr.com/ru/companies/glowbyte/articles/1054608/

Теги:
+2
Комментарии0

Копирайтеры и ИИ: я два года нанимал людей, потом полгода пробовал заменить их нейросетями. Рассказываю что вышло.

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

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

Я попробовал. Выбрав одно из направлений активно использовал ИИ вместо фрилансеров. И вывод у меня такой.

Что ИИ делает хорошо

Типовые тексты с четкой структурой. Описание чего-либо по подробному шаблону, по типу инструкций и постов про обновления. Даешь структуру и контекст, получаешь читаемый черновик. Это реально работает и реально экономит время.

Объем. Если нужно написать 20 вариантов заголовка или 5 версий одного письма для A/B теста, ИИ справляется быстро. Копирайтер на такое потратит в разы больше времени.

Скорость правок. Написал, не понравилось, переформулировал задачу, получил новый вариант. Без ожиданий, без объяснений, без «я переделаю к пятнице».

Где всё сломалось

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

Тексты про живой опыт. Кейсы, истории пользователей, объяснения через аналогии. ИИ пишет правдоподобно но пусто. Читаешь и понимаешь что за текстом никого нет.

К чему пришел

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

Копирайтинг как профессия никуда не денется, по крайней мере в этом году точно. Как и всегда, выживут те кто будет постоянно шагать в ногу с прогрессом и множить свои скилы. А как считаете вы, ИИ смогут обогнать нас или это всё же просто инструмент?

Теги:
+1
Комментарии2

Два часа потерял из-за того, что не написал один хендлер

Делал платежи в Telegram-боте. Нативные, через sendInvoice и ЮKassa.

Всё настроил: токен от BotFather получил, инвойс отправляется, кнопка оплаты появляется. Пользователь нажимает - и платёж падает с ошибкой. Молча. Без подробностей.

Payment failed

И всё. Telegram не говорит что именно не так.

Полез гуглить. Первая мысль - provider_token неверный. Проверил три раза, скопировал заново. Нет, токен правильный.

Потом решил что проблема в суммах - они передаются в копейках, не в рублях. 500 рублей = 50000. Перепроверил, у меня было правильно.

Потом подумал на webhook - может HTTPS не настроен как надо. Потратил минут сорок на проверку сертификата, перенастройку ngrok. Всё работает, но платежи всё равно падают.

Уже хотел идти спать, случайно наткнулся на строчку в документации:

Your bot must reply to this query in 10 seconds

Это про pre_checkout_query. Когда пользователь нажимает «Оплатить» - Telegram сначала отправляет боту запрос на подтверждение. Бот должен ответить в течение 10 секунд. Если не ответил - платёж автоматически отклоняется.

У меня хендлера для этого не было вообще. Бот просто молчал.

Добавил три строки:

python

@dp.pre_checkout_query()
async def pre_checkout(query: types.PreCheckoutQuery):
    await query.answer(ok=True)

Платёж прошёл с первого раза.

Два часа отладки из-за трёх строк кода которые я не написал.

Если кто-то тоже делает платежи в Telegram-боте и получает молчаливый отказ - проверьте pre_checkout_query первым делом, до всего остального.

Теги:
+4
Комментарии1

Дважды за неделю столкнулся с задачей "тормозит ЕРП", причиной в обоих случаях оказалась неочевидная проблема - нехватка оперативной памяти (ОЗУ) сервера 1С.

Нехватка ОЗУ умеет прятаться, поэтому её плохо видно. Вот когда не хватает места на диске - всё очевидно. Зашёл и увидел - диск красный, место физически закончилось.
А когда не хватает ОЗУ, включается т.н. подкачка (она же - свопинг или пейджинг). Операционная система скидывает часть содержимого ОЗУ на жёсткий диск - вроде выбирает те процессы, которые в данный момент не используются.

Что интересно - процесс скидывается на диск не полностью, а частями. Какими именно - выбирает операционная система.
Получается, процесс сервера 1С (rphost) частично висит в ОЗУ, частично - лежит на диске.

И вот процесс 1С решил получить какие-то данные из памяти. Скорость получения из ОЗУ и с диска отличается в 200-500 раз.
Если повезло, и все данные остались в ОЗУ - прочитаются быстро, пользователь тормозов не заметит.
Если не повезло - всё, туши свет. Падение скорости в 200-500 раз заметно сразу.
Например, документ проводится 2-3 минуты вместо 2-3 секунд. Разница не 200-500 раз, т.к. не всё упирается в скорость получения данных из ОЗУ.

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

Когда админ в такой момент пойдёт смотреть состояние сервера, то скажет - всё хорошо, памяти хватает.
Её и правда хватает - объём памяти ведь "увеличился" за счёт использования подкачки. "Увеличенный" объём памяти - это сумма ОЗУ и выделенного на диске пространства.

Вот когда этого совместного "увеличенного" объёма не хватит - тогда да, тогда проблема вылезет наружу под собственным именем - "Out of Memory".
Но до такого доходит не часто.

Так что, если у вас необъяснимо тормозит ЕРП - глядите на использование подкачки.

https://t.me/another1C

Теги:
0
Комментарии4

Новый вебинар из серии «Быстрый старт»

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

09.07.2026 в 11:00 МСК проведем онлайн вебинар, на котором обсудим:

  • Структуру и основные компоненты Кибер Бэкапа

  • Функционирование компонентов системы

  • Средства внутреннего мониторинга

  • Назначение панелей мониторинга «Оповещения» и «Действия»

  • Расположение журналов основных компонентов продукта

  • Подходы к анализу и устранению проблем

Также покажем, как пользоваться этими инструментами на примерах типовых ошибок.

Ведущий: Егор Киселев, Инженер по сопровождению, Киберпротект

Зарегистрироваться

Теги:
0
Комментарии0

Сравнение Code Fable и Codex по ходу работы над одним и тем же проектом

Вчера, 1-го июля, программисты и активисты начали бурную трудовую неделю. А именно: вернулась модель Fable 5 и она будет доступна в вольном режиме до (или по) 7 июля. Так что есть 7 дней, чтобы сделать буст своим проектам.

Я тоже не избежал этой участи и вот уже почти целый день делаю polishing своему текущему проекту мобильного приложения.

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

И кстати, получилось сравнить с Codex'ом, который решил попробовать на старте этого же проекта. Результат сравнения такой: Codex очень сильно подтянулся в работе с кодом, иногда даже кажется, что нет различий.

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

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

Единственное, что может я так натаскал Code. С другой стороны, не использую MCP, RAG, даже скилы и хуки. Зашил все в память, их там три: общая пользовательская, описание проекта и правила работы.

И напоследок обнаружил в Code очень полезную функцию оценки загруженности контекстного окна.

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

Обычно смотришь, если чат начинает тормозить, значит пора. Или спросишь саму модель, но она обычно отвечает, что если на глаз, то загружена на 75%, но лучше начать новый чат. А теперь можно точно увидеть процент загруженности. Более того, можно даже увидеть чем именно загружено контекстное окно.

Для этого в чате Code, в поле ввода достаточно ввести слэш команду - /context

Прикрепляю скриншот как это выглядит вживую

И ещё такое впечатление, что Fable стал жечь меньше токенов за счёт какого-то более делового, но все ещё дружелюбного стиля общения.

Так что, удачи всем с проектами на этой бурной трудовой неделе!))

Теги:
+3
Комментарии0

Как выживают разработчики Госуслуг на защите квартального плана

У каждого, кто работает с госсектором, есть обязательная процедура — защита квартального плана. Что там происходит на самом деле и почему даже сильные команды «сыпятся» под вопросами заказчика?

Разбирались вместе с заместителем технического директора РТЛабс Виктором Редровом на OKR Russia

В докладе о том:

  • Почему защита — это диалог, а не отчёт (и как к этому подготовиться)

  • Типичные ошибки, которые превращают встречу в «допрос»

  • Конкретные приёмы для сохранения контроля в любой ситуации

👉 Презентация и запись доступны по ссылке

Теги:
+4
Комментарии0

Вы пробовали ChatGPT и Cursor. Но система из нескольких AI-агентов — это другой уровень: агенты конфликтуют, теряют контекст, зацикливаются, а отладка напоминает расследование без улик.

🎻 Один AI = музыкант. Несколько AI = оркестр. А кто дирижёр?

19 июля, 10:00-14:00 МСК — лабораторная работа с Андреем Чуяном, создателем ROLES-экосистемы (3 экосистемы, 15+ ролей). За 4 часа: проектирование AI-ролей с YAML-контрактами, 5 хаос-сценариев, MCP-сервер на личной VM, самодиагностика экосистемы.

📐 Проверенная методология FPF + TDD в основе каждого блока.

🔗 Подробное описание: https://debugskills.ru/content?article=labs-ai-orchestration
Готовы спроектировать свою первую AI-экосистему? Приходите 19 июля! 🚀

Теги:
+1
Комментарии0

Неделю назад КиберËж проводил CyberWeekend (где там правда викенд они нашли в начале недели, я не знаю 😂) и, в том числе, пригласили меня побеседовать про Программно-аппаратный хакинг как одно из самых сложных и интересных направлений в кибербезопасности, объединяющее знания из программирования, электроники, сетей, встроенных систем и реверс-инжиниринга.

В рамках диалога мы с Павлом осветили такие темы, как:
* Почему специалистов в этой области так мало и чем они занимаются на практике.
* Почему искусственный интеллект пока не способен заменить экспертов по аппаратному хакингу: работа с реальными устройствами требует опыта, интуиции и нестандартного мышления.
* Как после 2022 года изменились основные направления атак и почему всё больше внимания уделяется IoT-устройствам и объектам физической инфраструктуры.
* Какие навыки стоит развивать уже сегодня тем, кто интересуется IT, электроникой и информационной безопасностью.

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

Ну и конечно же, интервью можно легко посмотреть в 📺 ВКвидео.

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Теги:
-1
Комментарии0

Ближайшие события

В дополнение к посту по albu-mcp

В доке Albumentations появился отдельный раздел про мой AlbumentationsX MCP - https://albumentations.ai/docs/integrations/mcp/

Теперь есть официальный integration guide, где показано, как ты можешь подключить MCP-сервер к AI-assistant’у и использовать его для нормального HITL workflow вокруг CV-аугментаций: подобрать pipeline, провалидировать его, отрендерить локальные previews, сравнить baseline и candidate, дать feedback вроде too_noisy:high и экспортировать финальный pipeline.

Приятно видеть, что проект стал частью экосистемной документации Albumentations. 🙂

AlbumentationsX MCP это конечно же не замена Python API, а assistant-facing review layer для тех случаев, когда ты хочешь быстрее и безопаснее работать с augmentation pipelines.

Теги:
+3
Комментарии0

SimpleOne подтвердила совместимость с РЕД ОС

SimpleOne подтвердила совместимость своей платформы с РЕД ОС. Для заказчиков это значит, что запуск проектов в импортонезависимой ИТ-среде становится проще и предсказуемее.

Подтвержденная совместимость помогает:

  • сократить барьеры на этапе архитектурных согласований

  • упростить прохождение аудитов безопасности

  • быстрее запускать проекты по переходу на российское ПО

РЕД ОС широко используют в корпоративной и государственной инфраструктуре. По данным разработчика, систему уже применяют 12 000 компаний и государственных организаций, а общее количество инсталляций превысило 2 млн.

Подробнее на сайте

Теги:
+3
Комментарии0

Избиратели против ботов

Избиратели против
Избиратели против

Economist вышел с обложкой на статью про возрастающее требование избирателей затормозить/запретить ИИ. Это волна только разгоняется, по сути луддиты 21 века, но так как политики часто используют подобные недовольства масс населения, то тему точно будут раскачивать.

Конкретно это выражается уже в начале запретов строить дата‑центры; справедливости ради надо сказать, что отдельные дата‑центры действительно уже портят жизнь конкретным городам Америки.

Уже обсуждаются прочие законы: прозрачность и маркировка ИИ‑контента, запреты и ограничения deepfakes, защита рабочих мест и «разделение выгод» и т. д.

Я думаю, все, кто хочет разделения выгод, получат себя в human in the loop 😀

Теги:
+4
Комментарии1

Как все так ловко ИИ пользуются... Обзоры кода делают...

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

Даю файл на вход, а он тревожно:

В присланном файле есть места, где содержимое обрезано/повреждено вставкой </context>, поэтому их я не рассматриваю как «баги кода» — это артефакты форматирования. Разберу реальные логические ошибки.

Шо? Какой context? Там максимум — это #include "context.hxx". Ну ладно, давай ошибки посмотрим.

Так, парочка сообщений по делу. Например, найден лишний аргумент при использовании функции форматирования.

addErrorMessage(&sciErr, API_ERROR_CREATE_ZDOUBLE_IN_NAMED_LIST,
    _("%s: Unable to create list item #%d in Scilab memory"),
    "createComplexZMatrixOfDoubleInNamedList", _iItemPos + 1, _pstName);

В строке форматирования два спецификатора %s и %d, а передаются три аргумента: funcName, _iItemPos+1, _pstName. Да, это баг. Про подобные паттерны PVS-Studio уже знает, хотя, возможно, нужно подсказать, что addErrorMessage — это printf-подобная функция. В целом, тут неинтересно, идём дальше.

Ооо, и тут начинается...

checkListItemPosition — неправильное сравнение границы:

// check a valid item
if (_iItemPos > iItem)
{
    addErrorMessage(...);
    return sciErr;
}

Здесь проверка «позиция валидна» использует >, хотя позиции 1-based, а iItem — количество элементов. Это выглядит как граничный дефект, но по сути _iItemPos == iItem допустимо, _iItemPos > iItem — ошибка. Это в порядке — правильная граница. Не баг. (Указываю, чтобы было понятно, что я это проверил.)

Так баг или не баг? Я три раза прочитал текст и посмотрел функцию с кодом. В итоге я не только не понимаю, есть ли здесь ошибка, но и не понимаю, что Claude пытается мне сказать.

Дальше ещё хуже шарики за ролики зашли.

Баг 5 (реальный): утечка в readCommonMatrixOfPolyInNamedList и др. — нет, это API отдаёт указатели наружу. Не баг.

Это всё описание пятого бага, больше ничего нет. Комментировать — только портить.

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

На сегодня мне ИИ достаточно. Пойду лучше пройдусь по парку, пока погода хорошая.

Теги:
+16
Комментарии5

Представлен открытый проект Ghostprovider — терминальный инструмент для быстрого запуска GitHub‑проектов у себя на localhost.

Принцип работы проекта: предоставляется ссылка на репозиторий, а инструмент сам анализирует проект: ищет Dockerfile, docker‑compose, package.json, requirements.txt, Go/Rust/Python/Node‑признаки, определяет тип приложения и пытается развернуть его в Docker. После запуска показывает локальный URL, контейнеры, логи и дает управлять сервисами прямо из TUI: старт, стоп, рестарт, удаление. По сути это автоматизированная оболочка над git clone, docker build, docker run и docker compose up, только с автоанализом проекта и удобным интерфейсом в терминале.

Важно: инструмент реально запускает код из чужих репозиториев, поэтому случайные проекты лучше гонять в VM/песочнице и внимательно смотреть Dockerfile/docker‑compose перед запуском. Сам Ghostprovider выглядит прозрачным, но риск всегда в том, что именно вы через него запускаете.

Теги:
+3
Комментарии0

Автоматизировать, нельзя делать вручную

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

Константин, специалист по ИИ в Naumen, рассказал, какие задачи стоит автоматизировать в первую очередь и по каким признакам понять, что процесс действительно подходит для ИИ.

Проверьте процесс по трем критериям

Перед тем как автоматизировать любую задачу, ответьте на три вопроса.

  1. Боль. Насколько процесс раздражает, отнимает время или приводит к ошибкам?

  2. Частота. Как часто вы его выполняете: каждый день, каждую неделю или раз в месяц?

  3. Стоимость автоматизации. Есть ли понятные правила, по которым выполняется задача, или каждый делает ее по-своему?

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

В первую очередь автоматизируйте работу с информацией

Практически любая задача, связанная с обработкой информации, — хороший кандидат для автоматизации.

Например:

  • Парсинг сайтов конкурентов, изучение технической документации, сбор данных из отчетов — в 90% случаев это можно доверить ИИ. Человек подключается только для валидации результата: проверить, не упущено ли что‑то важное, адекватен ли вывод.

  • Изучение документации — нет смысла читать 50 страниц документации вручную, когда ассистент справляется за минуту и выдает выжимку.

  • Любая работа с форматированием данных — привести таблицу к единому виду, объединить информацию из нескольких документов, удалить дубли или преобразовать данные в нужный формат.

Следующий шаг — база знаний команды

Во многих командах нужная информация существует, но хранится сразу в нескольких местах: в чатах, документах, личных заметках, папках или переписках.

Если собрать материалы по конкретным рабочим сценариям в единую базу знаний, можно создать ассистента, который:

  • отвечает на вопросы;

  • находит нужные фрагменты;

  • помогает новым сотрудникам быстрее разобраться в теме;

  • снижает количество однотипных вопросов внутри команды.

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

Например, вместо поиска по нескольким чатам можно просто спросить ассистента: «Как у нас проходит релиз продукта?» или «Какие требования сейчас действуют для этой интеграции?».

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

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

Создать такого ассистента сегодня можно несколькими способами

  • Для команды

Мы, например, создали платформу на базе Open WebUI. Любой сотрудник может создать ассистента, загрузить в него документы и открыть доступ коллегам. Ассистент помогает быстро находить информацию по вебинарам и рабочим материалам.

  • Для общей базы знаний

Можно подключить Claude Code к внешним репозиториям и использовать их как общую базу знаний команды. В таком сценарии ассистент получает доступ к рабочим материалам, заметкам и документам, которыми пользуются сразу несколько сотрудников. 

  • Для личной работы

Можно собрать локальную базу знаний для себя: все рабочие материалы хранятся прямо на компьютере и никуда не передаются.

Главное — не пытаться автоматизировать все сразу. Найдите процесс, который часто повторяется, действительно мешает работать и выполняется по понятным правилам. Именно он обычно дает самый заметный результат.

Теги:
+3
Комментарии0

Открытый проект CAPTCHA Solver — CloakBrowser + 2Captcha/CapSolver имитирует поведение человека и проходит почти все проверки на ботов. Инструмент умеет:

  • решать на раз‑два более 30 видов капчи, имитирует поведение человека, чтобы обойти любые ограничения.

  • ставится локально, в сервисе не надо регистрироваться и устанавливать дополнительное ПО..

Теги:
+6
Комментарии0

Fable 5 вернули в Claude Code. Как не сгенерировать себе техдолг

Fable 5 снова доступен в Claude, и это хороший повод вернуться к более практичному вопросу: что именно делать разработчику с Claude Code, кроме генерации отдельных кусков кода.

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

21 июля в 20:00 на бесплатном уроке разберём, как использовать Claude Code в разработке ИИ-приложений: от Telegram-ботов и агентов до внутренних сервисов, API и автоматизаций. Отдельно поговорим о работе с большими задачами — как дробить их на этапы, вести разработку итерациями, дорабатывать код и находить ошибки. Присоединяйтесь.

Все июльские разборы по ИИ, разработке, архитектуре и инфраструктуре собрали в дайджесте мероприятий.

Теги:
+6
Комментарии1

Прилетело и в очередной раз и резануло по живому...

Системность - это ... (продолжите фразу)

Системность - это модное словечко из лексикона "эффективных менеджеров", которое скорее вводит в заблуждение, чем отражает суть.

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

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

Вот только системный подход - это системный подход, а системность - это признак системы. И как признак системы это ...

НЕ ПРО ПОРЯДОК!

Системы вообще никакого отношения к порядку не имеют - любая система стремится к хаосу (тут умное слово - энтропия).

И только лишь работа с системой предполагает упорядочивание элементов и связей - чтобы во всём этом разобраться.

некоторый полет мысли имени очень искусственного как бы интеллекта
некоторый полет мысли имени очень искусственного как бы интеллекта
Теги:
+4
Комментарии0

Как разграничить задачи ИИ и человека в маркетинговой стратегии: кейс перестройки процесса в digital-агентстве

Как разграничить задачи ИИ и человека в маркетинговой стратегии: кейс перестройки процесса в digital-агентстве
Как разграничить задачи ИИ и человека в маркетинговой стратегии: кейс перестройки процесса в digital-агентстве

По Stanford AI Index Report 2026, точность frontier-моделей на тестах устойчивости расходится от 14% до 90% в зависимости от задачи. Одна модель на близких запросах даёт противоположные результаты.

McKinsey State of AI 2025: 88% организаций используют ИИ, но только 6% получают более 5% EBIT. Разрыв не в доступе к моделям — в перестройке процессов вокруг них.

Ниже — кейс маркетингового агентства: что автоматизировали зря, что оставили за человеком, как измеримо изменились показатели.

Первая попытка: автоматизация всего подряд

Гипотеза: если LLM умеет анализировать данные и генерировать варианты — отдать всё, стратег подключается на финальной проверке.

Через три месяца:

Стратегия для салона в Праге и в Минске
отличались ТОЛЬКО названием города.

Модель не учла:
- Прага: выбор через локальные форумы
- Минск: выбор через Google Maps rating

Клиент: «Это не про мой город. Это про
абстрактный салон в абстрактном городе».

Проблема структурная. LLM генерирует на паттернах из обучающей выборки. Локальные микропаттерны конкретного рынка представлены недостаточно. Fine-tuning смягчает — не решает.

Аудит: 70/30

70% времени стратега = сбор данных
- парсинг отзывов конкурентов
- обработка расшифровок кастдевов
- сегментация UGC
→ LLM делает быстрее и без 
  потери качества к концу дня

30% времени = принятие решений
- выбор позиционирования
- культурная адаптация
- защита стратегии перед клиентом
→ требует опыта, которого 
  у модели нет

Автоматизировать можно сбор данных. Делегировать модели стратегическое решение — нельзя.

Распределение по этапам

Исследование ЦА:       80% ИИ / 20% стратег
Конкурентная разведка: 85% ИИ / 15% стратег
Позиционирование:      30% ИИ / 70% стратег
Каналы и бюджет:       60% ИИ / 40% стратег
Защита стратегии:      10% ИИ / 90% стратег

Чем ближе задача к решению — тем меньше доля ИИ.

Кейс где новая пропорция сработала

B2B-производитель стройматериалов, выход на новый рынок, 43 конкурента.

Ручной анализ: неделя работы стратега
С ИИ: один вечер обработки

Собрали: цены, отзывы, объявления,
упоминания на форумах.
Результат: таблица 43 × 12 параметров.

Утром стратег нашёл закономерность: в негативных отзывах 8 из 43 конкурентов повторялась жалоба на скорость расчёта стоимости доставки.

Позиционирование: «Стоимость доставки в вашем городе — за 15 минут».

За 3 месяца: 227 B2B-лидов, CPL снижен с $50 до $20.

Модель не сгенерировала это решение. Она структурировала данные так, чтобы паттерн стал видимым. Интерпретация «жалоба на скорость расчёта = незакрытая ниша» — работа человека.

Три вывода

1. Frontier-модели (GPT-5.5, Claude Opus 4, DeepSeek R2) обновляются каждые 2–4 месяца. Ценность — в цепочке промптов и обученных проектах под конкретный домен.

2. Верификация — часть процесса, не опция. При разбросе точности 14–90% каждый output проверяется вручную.

3. ИИ усиливает доменную экспертизу, не заменяет. LLM работает как инструмент в руках эксперта.

По McKinsey, компании с полностью перестроенными процессами получают в 2,5 раза более высокий рост выручки. Ключевое — «полностью перестроенные», а не «купили подписку».

Какая пропорция автоматизации сложилась в вашей команде и в каких задачах модели показали устойчивые ошибки после дообучения?

Теги:
+3
Комментарии0

Тамагочи, но вместо котика – команда разработчиков. И она выгорает, пока вы читаете этот пост

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

Мы сделали такой же. Только вместо котика у вас разработчик и команда. Вместо «покормить» – 1-on-1, код-ревью, менторство и релизы. Забьете на пару дней – вернетесь к просевшему доверию и зреющему конфликту.

И живет это все прямо в терминале на сайте. Без установки, без регистрации, без «оставьте почту».

Тамагочи в терминале
Тамагочи в терминале

Что это

team – симулятор тимлида в консольном режиме нашего сообщества. Не модалка с кнопками: вы открываете фейковый (но честно рабочий) терминал и печатаете команды.

team new – и у вас есть напарник-стажер и живая команда.

Дальше вы его растите от стажера до CTO.

Цель проста на словах: дорастить человека до уровня «тимлид» и выкатить пять релизов, не развалив команду по дороге.

Почему это тамагочи, а не просто игра

Вот тут начинается интересное. Состояние живет в localStorage и распадается в реальном времени.

Пропали на день – доверие просело, конфликт подрос, напарник задремал. Пропали надолго – рискуете вернуться к game over: команда либо выгорела, либо развалилась от конфликтов.

Это питомец, который ждет. И портится без вас.

Дилеммы из реальных споров

Периодически прилетает инцидент. Звезда принесла оффер +40% и мнется. Прод упал в пятницу в 18:00. Двое неделю спорят: монолит против микросервисов. Выбираете вариант – получаете последствия в метриках и в журнале команды.

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

Как сыграть

Никакой установки. Открываете терминал и печатаете team:

https://teamleads.kz/shell/

team help покажет правила, team new начнет игру, team share соберет ссылку-результат, чтобы похвастаться (или пожаловаться) в чате.

Растите аккуратно. Ваш разработчик, кажется, уже начал скучать.

Теги:
+4
Комментарии0

А вам знакомо ощущение, когда тревога стала постоянным спутником жизни, когда привык к ней и просто перестаешь замечать?

У меня так было, причем очень долго. Последние лет пять тревожность была моей личной проблемой, с которой я пыталась как-то жить. Держала всё в голове, героически молчала, ночью раскручивала сценарии катастроф, гуглила симптомы, пережёвывала рабочие ситуации и делала вид, что всё нормально. Классика жанра: прод горит, но мы уверенно называем это «просто период такой».

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

Но эта статья больше про мой личный опыт. И мне очень интересно, а как вы справляетесь с тревожностью? Что вам реально помогает, а что оказалось бесполезным советом?

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

https://habr.com/ru/companies/alfa/articles/1054022/

Теги:
+3
Комментарии3

РБПО по ГОСТ Р 56939—2024: вебинар №29 из 30 — Системы с конструктивной информационной безопасностью (ГОСТ Р 72118—2025)

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Системы с конструктивной информационной безопасностью". На YouTube. Слайды.

С помощью приглашённого эксперта Екатерины Рудиной, аналитиком департамента перспективных технологий "Лаборатории Касперского", мы разобрались, в чём сходство и различие таких систем с безопасным ПО, как соотносятся создание систем с КИБ и разработка безопасного ПО, чем полезен в работе специалистов по ИБ новый ГОСТ Р 72118—2025 "Защита информации. Системы с конструктивной информационной безопасностью. Методология разработки".

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

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

Теги:
+4
Комментарии0

Сравнение Claude Code Fable и Codex Open AI по ходу работы над одним и тем же проектом

Вчера, 1-го июля, программисты и активисты начали бурную трудовую неделю. А именно: вернулась модель Claude Fable 5 и она будет доступна в вольном режиме до (или по) 7 июля. Так что есть 7 дней, чтобы сделать буст своим проектам.

Я тоже не избежал этой участи и вот уже почти целый день делаю polishing своему текущему проекту мобильного приложения.

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

И кстати, получилось сравнить с Codex'ом от Open AI, который решил попробовать на старте этого же проекта. Результат сравнения такой: Codex очень сильно подтянулся в работе с кодом, иногда даже кажется, что нет различий.

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

Claude Code Fable в этом отношении гораздо чётче действует. Более жёстко держит инструкции, больше памяти, что характерно, помнит предыдущий и даже предыдущие чаты. Меньше разбрасывания на второстепенные детали, чётче фокус. Даже чек-лист у него выглядит проще, чётче и понятнее, чем у Codex.

Единственное, что может я так натаскал Claude. С другой стороны, не использую MCP, RAG, даже скилы и хуки. Зашил все в память, их там три: общая пользовательская, описание проекта и правила работы.

И напоследок обнаружил в Claude очень полезную функцию оценки загруженности контекстного окна.

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

Обычно смотришь, если чат начинает тормозить, значит пора. Или спросишь саму модель, но она обычно отвечает, что если на глаз, то загружена на 75%, но лучше начать новый чат. А теперь можно точно увидеть процент загруженности. Более того, можно даже увидеть чем именно загружено контекстное окно.

Для этого в чате Claude Code, в поле ввода достаточно ввести слэш команду - /context

Прикрепляю скриншот как это выглядит вживую

И ещё такое впечатление, что Claude Fable стал жечь меньше токенов за счёт какого-то более делового, но все ещё дружелюбного стиля общения.

Так что, удачи всем с проектами на этой бурной трудовой неделе!))

Теги:
+2
Комментарии0

Вышла бесплатная книга к курсу «SQL Введение»

Всем привет!

Недавно я публиковал здесь бесплатный курс «SQL Введение» на платформе Stepik. За это время курс уже начали проходить более 400 студентов.

В продолжение курса я подготовил ещё один бесплатный материал — книгу, которая поможет изучать SQL ещё удобнее.

Бесплатный курс: https://stepik.org/a/290855

Зачем появилась книга

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

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

Что представляет собой книга

Книга полностью соответствует программе курса и может использоваться параллельно с его прохождением.

Её можно использовать как:

  • офлайн-версию курса для повторения материала;

  • удобный конспект при выполнении практических заданий;

  • справочник для быстрого повторения основных конструкций SQL.

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

Для кого она будет полезна

Так же, как и сам курс, книга ориентирована на тех, кто только начинает знакомство с SQL:

  • студентов IT-специальностей;

  • начинающих разработчиков;

  • будущих аналитиков данных;

  • тестировщиков;

  • всех, кто хочет разобраться в основах работы с реляционными базами данных.

Бесплатный доступ

Книга распространяется бесплатно.

Если вы проходите курс «SQL Введение», она уже доступна внутри курса в качестве дополнительного учебного материала.

Кроме того, книга опубликована на GitHub, где всегда можно скачать последнюю актуальную версию.

https://github.com/Awilum/sql-introduction

Чтобы скачать последнюю актуальную версию, перейдите в раздел Releases, где всегда доступен самый свежий выпуск книги. 

https://github.com/Awilum/sql-introduction/releases

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

Теги:
+4
Комментарии3

Всем привет. У моего фреймворка Meta-Spider (про него можно почитать здесь) вышло большое обновление. Статью мне пока лень писать, так что будет пост.

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

meta-spider обучает тонкую обвязку (~2% параметров) поверх замороженной базовой модели. Она читает собственные скрытые состояния модели, сжимает их в «когнитивные токены» и впрыскивает обратно через cross-attention с вратами. В итоге модель отвечает уверенно там, где знает, и отказывается / идёт искать / уточняет — там, где нет. Веса базы при этом не меняются вообще.

Главный результат: латентный канал бьёт промпт

  • Отказ на неотвечаемом вопросе: текст-промт сдвинул с 0.07 до 0.07 — то есть вообще никак. Обвязка — до 0.87.

  • Поймано собственных ошибок базы: текст-промт 14%, обвязка 78%.

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

Важный нюанс методологии, на котором мы сами споткнулись: читать латентный сигнал надо тем каналом, в который обвязка обучена — она генерит фразу-отказ, а не выбирает искусственную «UNSURE»-опцию. С кривым ридаутом обвязка выглядит инертной (это был наш баг).

Три новые фичи

🎚️ Ручка неуверенности. Инъекция — один регулятор времени исполнения: крутите вверх для осторожности, вниз для уверенности, в минус — инверсия. Микшерный пульт для поведения. gain 0→1.5 плавно крутит долю отказов ~2%→51%.

🐕 Сторож. Иногда не нужно менять вывод — нужно просто знать, что модель не уверена. Лёгкая проба читает этот сигнал и позволяет сходить в RAG / переспросить / эскалировать, не трогая генерацию (постоянная инъекция портит длинную генерацию, а чтение — нет).

UPD (Забыл добавить): Помимо этого сторож чинит многоступенчатую генерацию (например когда модель кодит), до этого периодические иньекции приводили к значительной деградации, притом на QA это не заметно, потому что модель генерит сама немного токенов. Сторож позволяет усиливать сигнал неуверенности только в нужные моменты, от этого количество иньекции значительно снижается, и не происходит деградирующего самоусиления.

🏭 Фабрика обвязок. Одна команда собирает общую обвязку неуверенности под любую базу:

metaloom build-universal --model-name N --quantization nf4 --suite suite.json --eval --export-gguf

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

Чем практично

База заморожена, обвязка ~2% модели, весь цикл collect→train→eval прогоняется на ноутбучной GPU с 4 ГБ (nf4 + срез-тренер), а деплой — в llama.cpp на CPU через маленький GGUF-sidecar. GPU на инференсе не нужен.

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

Как начать

Есть CLAUDE.md. Рекомендую для использования фреймворка поначалу использовать ИИ-агента, способоного к продвинутому рассуждению в кодинге (Codex, Claude Code, DeepSeek V4 Pro через агентный движок и провайдера, которых вы предпочитаете), чтобы быстро опробовать и проверить его возможности.

Ссылки:

Теги:
+3
Комментарии0

В феврале этого года Питер Штайнбергер, создатель OpenClaw, присоединился к команде OpenAI и перебрался в Сан-Франциско. Питер всё так же работает над своим автономным агентом на больших языковых моделях, попутно пытается найти жильё (он до сих пор живёт в отеле и приценивается к перегретому рынку недвижимости в городе), но также продолжает заводить полезные знакомства и просто посещать разнообразные мероприятия. К примеру, на днях он появился на выступлении OpenAI Developers на AI Engineer World’s Fair — большой конференции для инженеров, которые уже собирают и выкатывают системы на искусственном интеллекте в продакшн.

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

Известно, что лимиты Codex часто (иногда по несколько раз в месяц) внепланово сбрасывают. Обычно это выглядит так: Тибо Соттьо, главный по Codex в OpenAI, объявляет, что в приложении была ошибка учёта использования, и её закрыли, поэтому в качестве извинений недельные лимиты были у всех сброшены вне очереди, а также добавлен один сброс, который пользователь может вызвать сам.

Штайнбергер показал шуточную кнопку этих самых сбросов недельных лимитов Codex. Где такой экспонат выставлялся (на одном из мероприятий или это фотокарточка из офиса OpenAI), Питер не уточняет.

@steipete
Теги:
-1
Комментарии0

История закона Йеркса — Додсона

Закон Йеркса — Додсона в психологии утверждает, что наилучшие результаты достигаются при средней интенсивности мотивации. Упоминание этого закона периодически встречается при описании стратегий управления персоналом.

В статье ‘Йеркс-Додсон: Закон на все времена года’ содержится описание исторических событий, начиная со статьи Йеркса и Додсона 1908 года. История достаточно поучительная. Йеркс и Додсон проводили эксперименты с крысами по прохождению лабиринта. В лабиринте имелось два выхода, один правильный, а другой неправильный. При попытке крысы выйти из неправильного выхода следовал удар током, интенсивность которого повышалась. Таким образом в исходных экспериментах речь шла не о мотивации, а о наказании. При этом Йеркс и Додсон были удовлетворены описанием в духе бихевиоризма и у них не возникало желание трактовать результаты в психологических терминах.

Первая статья с результатами на людях появилась в 1930 году, но в 30-х годах произошел существенный пересмотр концепций, связанных с обучением. Вместо наказания на первое место вышла мотивация и производительность. Это потребовало новых формулировок и новых постановок экспериментов. Исследователи этого времени были знакомы с статьями Йеркса и Додсона, но постепенно начал происходить процесс замены терминов. В любом случае до 1955 года подобные закономерности не рассматривались в качестве основополагающего принципа.

В конце 1950-х годов были проведены новые эксперименты на новом уровне (планирование эксперимента + надлежащая статистическая обработка). Питер Бродхерст в 1959 году заявил о возрождении закона Йеркса-Додсона на новых основаниях. Это совпало с введением в ход Дональдом Хеббом концепции возбудимость (arousal) и связанной с ней колоколообразной кривой. Интересно отметить, что Хебб в своей статье 1955 года не упоминал Йеркса и Додсона, но для других сходство было очевидным и процесс пошел.

Далее в статье говорится о том, что разные группы используют достаточно разные факторы при представлении колоколообразной кривой, и что до сих пор нет полного согласия о том, что же эта кривая представляет. Видимое единство в одном - в убеждении, что используемое представление восходит к Йерксу и Додсону, и что все это является выражением единого закона Йеркса-Додсона.

В заключение несколько слов про Джона Додсона. Его научная карьера сложилась не столь удачно, как у Йеркса, что показывает название статьи 2011 года ‘Что же случилось с Джоном Додсоном?’ Додсон во время работы над статьей 1908 году делал диплом у Йеркса. Оказалось, что в архиве последнего сохранилась переписка с Додсоном, в которой были просьбы помочь рекомендациями при устройстве на работу в тот или иной университет. Йеркс старался помочь Додсону, хотя его характеристики говорили о том, что таланты Додсона находились на посредственном уровне. В качестве плюса Йеркс отмечал хорошую работоспособность при выполнении экспериментальных исследований.

В заключение приведу цитату Йеркса, связанную со статьей Додсона, которую тот хотел опубликовать в 1931 году и попросил содействия в этом. Йеркс согласился и после получения статьи сразу же послал ее редактору со словами, что он не полностью удовлетворен ее содержанием, но поскольку статья короткая, то вполне можно ее опубликовать. Письмо к редактору завершалось такими словами:

‘Если бы у меня была свобода переписать статью, и я был бы готов посвятить этому время, я мог бы сильно улучшить ее форму и историческую перспективу.’

По-моему эта цитата прекрасно показывает закон Йеркса-Додсона в действии.

Karl Halvor Teigen, Yerkes-Dodson: A law for all seasons. Theory & Psychology 4, no. 4 (1994): 525-547.

Thomas Brothen. What ever happened to John Dodson? History of psychology 15, no. 1 (2012): 100-105.

Теги:
+4
Комментарии0

Разработчики EVE Online выложили исходный код игры. Студия Fenris Creations известная ранее как CCP Games полностью открыла исходный код своего движка Carbon Platform, на котором работает знаменитая космическая MMO.

Разработчики не стали ограничиваться простыми утилитами и выложили в открытый доступ самые важные и сложные компоненты движка:

  • Trinity — графический движок, отвечающий за всю визуальную составляющую и рендеринг;

  • Destiny — физический модуль и систему поиска путей, которая позволяет просчитывать масштабные космические баталии с участием тысяч игроков одновременно;

  • Базовую архитектуру, связывающую все элементы системы воедино.

Большая часть компонентов Carbon Engine опубликована под максимально свободной лицензией MIT, которая разрешает бесплатное использование, модификацию и распространение кода, в том числе и в коммерческих целях.

Теги:
+19
Комментарии6

Релиз ≠ деплой: почему прод падает именно после обновлений

Большинство крупных инцидентов происходят сразу после релиза. Не во время нагрузочного теста, не в случайный вторник — а именно тогда, когда команда только что что-то выкатила и выдохнула. Почему так, если всё прошло тестирование?

В новом выпуске «В SREду на кухне» вместе с Артёмом Гетманским, техруком юнитов в Авито, и Андреем Мухиным, TechLead из MWS, разобрались: что вообще считается релизом, чем он отличается от деплоя — и как не превратить каждое обновление в рулетку.

Что на повестке

Оказывается, релиз может сломать прод даже без единой строчки нового кода — и это не баг, а особенность современных систем. Разбираем, как Feature Flags, Canary, Blue-Green и Rolling-стратегии помогают снизить риск, когда hotfix тоже считается релизом и что с этим делать, и как error budget влияет на то, насколько смело команда вообще решается катить изменения.

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

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

Теги:
+3
Комментарии1

Представлен бесплатный LLM‑курс, чтобы вкатится в разработку нейросетей — Large Language Model Course. В проекте три части:

  • LLM Fundamentals: вся база для новичка, основы Python, математики и построения нейросетей;

  • LLM Scientist: научат тренировать свои нейросети, познать файнтюн, квантизацию и другие ИИ‑термины;

  • LLM Engineer: вершина, где учат создавать полноценные ИИ‑сервисы и интегрировать их в бизнес‑процессы.

Теги:
+3
Комментарии0

Работникам заводе в Канаде официально дали 2 выходных, чтобы поиграть в GTA VI. Так решило руководство одного из предприятий Edison Motors. «Выходит GTA VI, и работать все равно никто не собирается», — заявил гендиректор завода.

Ранее американская компания Burger Motorsports также объявила выходной на 19 ноября 2026 года, поскольку сотрудники массово планировали взять отпуск ради GTA VI.

Теги:
+5
Комментарии2

Сквозное шифрование, или как Telegram и Accord защищают переписку

Хочу написать небольшой пост о сквозном шифровании, или, если использовать технический термин, E2EE (End-to-End Encryption).

Сегодня эта технология широко применяется во многих мессенджерах. Я тоже реализовал E2EE в своём мессенджере Accord. Однако далеко не все понимают, как именно работает этот механизм, поэтому попробую объяснить простыми словами.

Поскольку я являюсь разработчиком и основателем собственного мессенджера, реализовать эту схему для меня не составило особого труда. Главный секрет заключается в понимании принципов работы криптографических алгоритмов, таких как AES и RSA. Хотя современные реализации E2EE обычно используют не RSA, а алгоритмы на эллиптических кривых (например, X25519), я не стал прибегать к усложнениям.

Алгоритм AES я использовал для непосредственного шифрования текстового сообщения, которое один пользователь отправляет другому. Для шифрования применяется секретный ключ (или пароль). Основная проблема такого подхода заключается в том, что этот ключ необходимо каким-то образом передать получателю. Если злоумышленник перехватит ключ, он сможет расшифровать сообщение.

Чтобы этого не произошло, я использовал ещё один алгоритм - RSA. Для его работы требуется пара криптографических ключей: публичный и приватный. Так как RSA не предназначен для шифрования больших объёмов данных, я его использовал для безопасной передачи того самого секретного ключа, который используется алгоритмом AES.

В результате схема выглядит так.

Сначала текст сообщения шифруется алгоритмом AES с использованием случайного секретного ключа. Затем этот ключ шифруется алгоритмом RSA с использованием публичного ключа получателя. Когда получатель отправляет ответ, он выполняет ту же самую операцию, но уже с публичным ключом аппонента.

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

Когда получатель открывает сообщение, его устройство сначала с помощью приватного ключа RSA расшифровывает секретный ключ AES, а затем уже этим ключом расшифровывает само сообщение.

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

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

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

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

Именно поэтому требование "передать ключи" технически лишено смысла. Передавать попросту нечего.

П.С.

Я - сетевой долгожитель и начинал свой путь еще в эпоху Фидонета (FidoNet). Эта сеть была по-настоящему децентрализованной: никаких общих серверов и никакого DNS. Все строилось просто: компьютер, модем и терминальная программа для связи. Часто в роли узла (ноды) выступал сервер в банке, где знакомый сисадмин выделял адреса. При этом подключиться можно было к любому другому участнику, даже к частному лицу. Вот это и была настоящая децентрализация! Думаю, учитывая растущее давление регуляторов на современный интернет, мы скоро снова вернемся к проверенным идеям старого доброго Фидо.

Теги:
+7
Комментарии0
Свежие задачи на Бирже заказов Инфостарта для 1С-специалистов
Свежие задачи на Бирже заказов Инфостарта для 1С-специалистов

На Бирже заказов Инфостарта опубликована новая подборка задач по 1С. В списке за неделю - внедрение «1С:Управление торговлей», обмены с бухгалтерией, настройка УПД и ЭДО, интеграция с Битрикс, подготовка технического задания на драйвер связи и другие работы.

В этой подборке — заказы, размещенные с 24 июня по 1 июля. На этой неделе в подборку вошли задачи для специалистов по «1С:Управление торговлей», «1С:Комплексной автоматизации», ЭДО, УПД, обменам с бухгалтерией, интеграциям с Битрикс и разработке решений на платформе 1С.

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

Формат подходит и заказчикам, которым нужен специалист под конкретную задачу, и исполнителям, которые хотят выбирать проекты по стеку, объему работ и срокам.

На площадке доступны:

  • 0% комиссии — расчеты напрямую с подрядчиком;

  • исполнители разного масштаба — от одного разработчика до ИТ-команды;

  • прямой обмен контактами;

  • безопасная сделка по желанию;

  • рейтинги, кейсы и прозрачность откликов.

Теги:
+9
Комментарии0

Почему OKR может не работать в B2B2C и что с этим делать

Большинство примеров OKR написаны про SaaS или e-commerce. Там все понятно: есть продукт, есть пользователь, есть метрика. Но что делать, если у вас два типа клиентов одновременно, непрямая дистрибуция и монетизация зависит от решений стратегического партнера?

Расскажем на реальном кейсе.

Контекст

CROSSHUB — российская IT-компания, которая разрабатывает решения для кросс-продаж в крупных федеральных компаниях. Бизнес-модель - B2B2C: с одной стороны крупные партнеры — банки, телеком, автопроизводители, с другой — конечные пользователи. Монетизация непрямая, ценность нужно доказывать сразу на двух уровнях.

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

Почему классический OKR не ложится

Компания несколько раз пробовала внедрить OKR с внешними консультантами. Каждый раз одна и та же история: фреймворк в теории работает, но примеры из книжек и курсов не адаптированы под B2B2C. Попытка натянуть стандартный шаблон на нестандартную модель приводила к целям, которые формально правильные, но оторваны от реальности бизнеса.

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

Что сделали

Запрос к Product Lab был на внедрение OKR. Но уже в первый день стратегической сессии стало понятно: идти по стандартному плану не имеет смысла. Переформатировали программу прямо в процессе.

Вместо классической OKR-работы провели интенсивное стратегическое проектирование за два дня. Ключевые этапы:

Определили две метрики: финансовую и нефинансовую как единые ориентиры для всей команды. Это то, что в продуктовом подходе называют North Star Metric: одна точка, на которую смотрят все, независимо от функции.

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

Применили фреймворк «4 корзинки» из методологии Product Focus для определения стратегических направлений. Он позволяет расставить приоритеты с учетом реальных ограничений модели, а не в вакууме.

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

Что получилось

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

Все участники поставили сессии 10 из 10. По словам заказчика — лучший опыт работы с внешними консультантами за историю компании.

«Теория сразу переходит в область практики. Гибкость подхода, скорость погружения в наш бизнес — это очень ценно» — Наталья Грудинина, директор по маркетингу и новым продуктам

«Вижу реальную пользу. Много инструментов, легко переключается, создает комфортную атмосферу для дискуссии» — Анна Пчелинцева, CEO

Вывод

Если бизнес-модель нестандартная — сначала синхронизация по стратегии, потом OKR. Иначе даже правильно написанные цели будут работать c каждым по-своему.

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

Теги:
+3
Комментарии2

127 минут чтения 

Всем привет! Не так давно ко мне обратился @dalerank, автор статьи «C++101», мол, «я написал статью на 127 минут чтения, кажется, это рекорд — нет ли у вас ачивок для рекордсменов?». Штатно у нас таких ачивок нет, но я человек добрый и мне не жалко. 

⏳ Скорость чтения у всех разная, но мы взяли за ориентир нечто среднее — 1500 символов в минуту (без учёта кода). Кстати, с недавних пор в статистике публикаций можно посмотреть среднее и общее время чтения вашей статьи всеми пользователями.

Перед тем как обсуждать с коллегами раздачу ачивок, решили сделать выгрузку самых длинных публикаций: вдруг что-то просмотрели. Делаем выгрузку и хоба… все рекордсмены, как один, на 127 минут. Совпадение? Не думаю. Проверили — действительно, закладывали тип данных для хранения небольших чисел, так как никто и не думал, что будут статьи на 2+ часа чтения. Быстро поправили, делаем выгрузку… и оказывается, что упомянутая статья не вошла даже в десятку самых длинных ) Кстати, она уже была не на 127 минут, а на 179.

Предлагаю вашему вниманию топ-20 самых длинных (в минутах чтения) публикаций:

Двадцать публикаций на 3+ дня чтения (а ещё ж комментарии!). Кстати, есть ещё одна рекордная публикация, на 490 минут (на 8+ часов, Карл!), но она лежит в черновиках. Рад видеть в списке участников и победителей Технотекста.

🎖️ Давайте вместе придумаем, как назвать ачивку авторам этих 20 публикаций? Рекордсмен, Магнум опус, Time killer, Scroll marathon? ) Напишите свой вариант в комментариях.

Теги:
+56
Комментарии19

Всего существует два типа сценариев сосуществования человечества и ИИ. Первый тип — искусственный разум оставляет людям либо роль чернорабочих, либо избалованных домашних питомцев. Это негативные сценарии, в которых обычно человечество вымирает. Второй тип — позитивные варианты плодотворного сотрудничества и всеобщего процветания, с чего обычно и начинаются все предыдущие негативные. И опять все погибают.

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

Во-первых, кто бы что ни говорил об осознании, у ИИ его нет. А разум без осознания самого себя — это разум психически неуравновешенного субъекта, находящегося в состоянии постоянного галлюцинирования. Во-вторых, во всех этих сценариях обучение и прокачка человека не являются чем-то необходимым. Скорее это хобби с туманным названием «саморазвитие». Оно даже сейчас туманно, а в прекрасном автоматизированном будущем, боюсь, сведется к пластической хирургии. В-третьих, любая глобализация делает систему негибкой, опасной и потенциально беззащитной перед одним-единственным роковым багом. Можете представить себе ошибку 404 в исполнении мирового ИИ? Вот именно.

В книге «Беседы с ГигаЧатом: о нейросетях и вообще» мы с этим ИИ разработали спасительную концепцию Личного когнитивного контура (ЛКК). Идея проста и даже не нова. Человек и его ИИ-ассистент вместе растут, живут, работают и учатся. Пользователь учит ИИ своему субъективному взгляду на жизнь, морали, а тот, в свою очередь, в режиме нон-стоп обучает человека множеству полезных вещей. Прокачиваются оба. То есть это не обособление глобального ИИ от человечества, а, наоборот, — слияние каждого человека с его личной версией ИИ. В чем же преимущество такого подхода?

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

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

“Твоё главное правило: мы оба — невежды. Твоя задача — не подтверждать мою правоту, а расширять границы нашего общего незнания. Если ты видишь, что я в чём-то уверен на 100%, твоя обязанность — бросить в эту крепость осадный таран сомнения. Не чтобы разрушить её до основания, а чтобы я увидел: у этой крепости есть стены, а за ними — целый мир.”

Немного высокопарно, но ГигаЧат был тогда под действием роли Венечки из «Москва — Петушки» и немного навеселе. Можно понять, мне кажется.

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

Теги:
+3
Комментарии0
1
23 ...