Записал короткое видео про свой небольшой инструмент, который помогает превращать интернет-статьи в аккуратные PDF и массово прикреплять их к источникам в Zotero.
Мне этот инструмент понадобился, так как я полюбил читать с планшета. Но в мобильном Zotero по сути только PDF хорошо работает и нормально поддерживает аннотации.
Под капотом это работает следующим образом.
Страница скачивается по URL, Defuddle от Kepano вытаскивает из неё основное содержимое без меню, рекламы и прочего мусора, а далее Playwright рендерит это в нормальный PDF.
MLOps и прод: Docker, Kubernetes, CI/CD, monitoring, serving
Специализация: CV, NLP, RecSys, RL, Safety
Roadmap не продаёт иллюзию “обучил модель - стал ML-инженером”.
В реальной работе много времени уходит на данные, метрики, деплой, мониторинг, воспроизводимость и разбор ошибок. Модель - только часть системы.
Хорошая мысль из roadmap: LLM не делает джуна сеньором. Она ускоряет того, кто уже понимает базу. Без базы человек просто становится оператором Copilot, который не может объяснить, почему всё сломалось.
📡 Точное позиционирование как новая функция космической индустрии
Мы совсем не про GPS. Космическая индустрия стремительно развивается и предлагает для ИТ новые услуги. Starlink популяризировал быструю спутниковую связь и потряс мир (и конкурентов) 10 000 аппаратами на орбите. Но Iridium не собирается сдаваться и анонсировал решение Project Authentic, которое сочетает защищённые точное позиционирование, навигацию и точные сигналы времени — PNT.
Спутники глобальных навигационных систем — такие как ГЛОНАСС и GPS — работают на средней околоземной орбите — на высоте порядка 20 000 км. Это накладывает ограничения на точность определения координат и безопасность. Они поддаются спуфингу (выдаче пользователям в определённой локации ложного местоположения), а если сигнал зашифрован и его нельзя подделать, то его сравнительно легко заглушить.
Космические аппараты на низкой околоземной орбите (до 2000 км) имеют меньшую задержку и часто могут выдавать более высокую мощность сигнала. При точном учёте их положения и минимальном апгрейде начинки низкоорбитальные группировки позволяют более точно определять местоположение и передавать сигналы точного времени.
Iridium купила компанию Satelles и доработала её инструмент для работы с наземной инфраструктурой, который позволяет шифровать сигнал и аутентифицировать пользователя. В результате Iridium разрабатывает решение, которое позволит определять точные координаты и получать точные сигналы времени только авторизованным пользователям. Эти сигналы будет сложнее заглушить и нереально заспуфить (за счёт шифрования). Спутниковый оператор считает, что оно будет востребовано у тех клиентов, которые не могут позволить себе атомные часы, но требуют более надёжных решений, чем GPS. В частности, это могут быть операторы ЦОДов, которые используют сигналы точного времени, например, для шифрования (смена кодов происходит в строго определённый промежуток времени).
В результате космическая индустрия предлагает важные продукты для ИТ-компаний, и эти две отрасли всё больше сращиваются. У ИТ-компаний, которые не исследуют космические технологии, нет будущего.
Стартап Cheffy выпустил робота по имени E.G.O.R. (Egg, Go, On, Robot), который умеет жарить яичницу 7 разными способами. Просто закидываем яйца в специальный отсек, выбираем тип яичницы и время, к которому хотите получить завтрак — робот сделает всё далее сам.
Как отключить звуковое уведомление для SMS которые рассылает RSCHS (МЧС)
Я не знаю как отписаться от рассылки SMS которые шлёт RSCHS.
RSCHS давно шлёт мне уведомления о разнообразных стихийных бедствиях, хотя я не просил его об этом, и не давал согласия включать меня в эту рассылку. Раньше я эту рассылку терпел, потому что она не была такой частой и назойливой. Но в последнее время RSCHS, душка такая, решил, что совершенно необходимо в два часа ночи сообщить мне о беспилотной опасности. Причём на каждую из моих SIM карт. А звук на входящие SMS у меня громкий. Беспилотники летают почти каждую ночь. Отключать смартфоны на ночь я не хочу. И вот здесь моё терпение лопнуло, и я стал искать способ решить эту проблему. Если у Вас на смартфоне нет возможности занести RSCHS в спам-лист, то есть другой способ.
Идея состоит в том, чтобы создать в адресной книге на смартфоне отдельный контакт для телефона сервисного центра RSCHS и назначить ему специальный файл не содержащий звука.
Для Android. На смартфоне открываем сообщения от RSCHS, выбираем любое, тапаем по нему коротко, открывается окно Message details, или нажать длинно на сообщении - View details. В открывшемся окне в поле Service Center номер +7 921 6000088. Возможно для Вашего сотового оператора и региона номер будет другим. Создаём новый контакт «RSCHS Service Center», в поле mobile number указываем +7 921 6000088. Сохраняем этот новый контакт. Назначаем для этого контакта звук тишины - Set ringtone выбрать рингтон None.
Если на смартфоне по какой-то причине нет рингтона None. Надо создать файл mp3 содержащий тишину. Можно засунуть смартфон микрофоном под подушку и запустить на нём стандартное приложение Sound Recorder. Я использовал звуковой редактор - Audacity. Он умеет Generate Silence. На выходе получился файл silence.mp3 размером один килобайт, содержащий тишину длительностью три секунды. Копируем его на смартфон, в папку со звуками, назначаем для контакта RSCHS.
Теперь SMS от RSCHS будут продолжать поступать на Ваш смартфон, но уже молча.
Обычно при выборе области для применения ИИ все берут одну из core-функций компании. Ну типа, если компания делает анкеты для маркетинговых исследований, то автоматизируем это. Либо, если компания, как большинство, имеет много общения с клиентами, то автоматизируем саппорт в чатах или даже продажи в чатах.
Подход вроде логичный, ведь core-задача компании обычно — это то, на что тратится большая часть времени, так ведь?
А вот нет: если вы думаете, что сотрудник банка тратит львиную долю своего времени на банковские дела, на создание ценности для клиента, то вы сильно ошибаетесь. Если вы думаете, что разработчик игры в большой компании тратит большую часть своего времени на разработку игры, то вы опять ошиблись.
Закон больших компаний гласит: 40% времени пожирают рутина и бюрократия. Но ведь остаются 60% для реальной работы?
А вот нет, потому что человеческая психика воспринимает всё по-другому, и сходить на созвон на час не означает, что выпал только час.
Иначе говоря, когда вы потратили 40% своего времени на рутину, вы потратите ещё 40% на переключение между рутиной и реальными задачами (чтобы вернуть себе фокус внимания) и чтобы просто восстановиться.
Когнитивная нагрузка сжирает вашу ману (способность делать дела) независимо от реальной важности задачи.
Банально забронировать себе отпуск в некоторых компаниях может означать не нажатие одной кнопки, а контакты с 3–5 людьми, погоню за ними и волны волнений.
Что все это значит для автоматизации именно через ИИ? ИИ — это первый вид автоматизации, который условно может все. Раньше, если есть тул для автоматизации тестирования, то, по сути, только ее и то с определенными ограничениями он и может делать. А вот ИИ может делать очень разные задачи.
Вывод прост — начинайте автоматизацию с рутины, а не с core-задач компании/команды. Если вы сможете забрать половину рутины у людей, то высока вероятность, что на core-задачу у них выделится не просто больше времени, а больше когнитивной энергии (той самой маны), что даст больше реальной ценности клиенту.
Puppet 8 for DevOps Engineers — книга, после которой лучше понимаешь инструмент
Puppet - мой основной рабочий инструмент. Сейчас он обслуживает нашу офисную и торговую сеть, а это более 9000 хостов на Linux под самые разные нужды. На русском языке актуальных материалов по нему практически нет, поэтому я взялся за англоязычную «Puppet 8 for DevOps Engineers». Читалось не быстро, но, как говорится, дорогу осилит идущий.
И книга оказалась просто 10 из 10.
Больше всего понравилось, что это не просто сборник синтаксиса и примеров, а разбор Puppet как полноценного инженерного инструмента.
Что внутри:
Сначала автор рассказывает историю создания Puppet и задачи, ради которых он создавался. Потом переходит к философии: почему он устроен именно так, как работает декларативный подход, зачем нужна идемпотентность и почему это важно для управления инфраструктурой.
Большой блок посвящён коду. Код описан через примеры и советы, но так же описаны типовые ошибки, подводные камни и наследие старых версий, которое всё ещё можно встретить в живых инфраструктурах, но лучше заменить. Не всегда код из книги отрабатывал корректно, нужны были мелкие правки, может это из за версий, а может задумка автора, чтобы ты немного прикладывал голову.
Отдельно понравилось, что есть главы про архитектуру использования Puppet, серверную часть, конфигурирование, тонкую настройку, логирование, мониторинг и эксплуатацию. То есть это не только книга для тех, кто пишет Puppet-код, но и для тех, кто потом будет держать всю эту систему в работоспособном состоянии.
Последняя небольшая часть посвящена сравнению с платной версией. Автор честно говорит, что многие возможности можно собрать и в бесплатной версии, если готовы вложить время и поддерживать всё самостоятельно.
Так же в этих главах становится понятно что автор не просто пользуется Puppet, а является частью его команды разработки. Отсюда и такой уровень погружения в разные аспекты инструмента.
По итогу:
Книга оказалась полезной со всех сторон: и для написания нормального Puppet-кода, и для понимания архитектуры, и для эксплуатации серверов Puppet в реальной инфраструктуре.
Хочется, чтобы по другим DevOps-инструментам чаще попадались книги такого уровня.
Есть, правда, грустный контекст: Puppet 8 стал последней open source-веткой. После изменений со стороны Perforce новые пакеты и бинарные сборки Puppet начали уходить в закрытую модель распространения. Сообщество в ответ развивает форк OpenVox. По командам, структуре и общей логике он во многом продолжает привычный Puppet-подход, так что история инструмента, похоже, не закончилась.
Почему зелёный CI не гарантирует, что система работает
Кейс из QA automation: как миграция на TypeScript привела к скрытому удвоению тестов без единого падения в CI
CI зелёный.
Тесты проходят.
Pull request’ы мерджатся.
Но система уже сломана.
И самое опасное — это не видно ни в логах, ни в отчётах CI.
В большинстве команд CI воспринимается как индикатор здоровья системы:
зелёный CI → всё работает
красный CI → есть проблема
Это удобная модель. Но она не всегда верна.
Контекст кейса
После миграции проекта с JavaScript на TypeScript мы заметили странное поведение:
CI стал выполняться почти в 2 раза дольше
тесты не падали
ошибок не было
метрики оставались “нормальными”
На первый взгляд — ничего критичного.
Что происходило на самом деле
Playwright начал подхватывать одновременно два набора тестов:
.spec.js
.spec.ts
В результате один и тот же тестовый набор запускался дважды.
Самое неприятное — CI не просто не показывал проблему. Он создавал иллюзию, что всё становится лучше: время выполнения росло постепенно, и это воспринималось как “нормальная деградация после миграции”.
Почему это было незаметно
Проблема усугублялась полным отсутствием сигналов:
CI оставался зелёным
тесты не фейлились
никаких warning’ов
никаких алертов
Единственный симптом — увеличение времени выполнения. Которое списали на “ну TypeScript, наверное тяжелее”.
Как проблема была обнаружена
Случайно. Ближе к завершению миграции, при удалении .js файлов, количество тестов внезапно сократилось примерно в два раза:
было ~240
стало ~120
До этого момента CI фактически выполнял двойную работу — без каких-либо признаков аномалии.
Root cause
Root cause оказался банальным — и именно поэтому его так долго не замечали.
В playwright.config.ts отсутствовал явный testMatch. Playwright по умолчанию подхватывает все файлы, соответствующие glob-паттерну — и .js, и .ts одновременно.
Фикс — одна строка:
testMatch: [‘**/*.spec.ts’]
Но чтобы до неё дойти, нужно было сначала понять, что вообще происходит.
Архитектурный вывод
Большинство проблем в тестовых системах не проявляются как падения.
Они проявляются как:
дублирование выполнения
скрытая деградация производительности
изменения в поведении runner’а без изменений в тестах
И у них нет алертов — потому что мы их не проектируем.
Например, в нашем случае проблему можно было бы поймать простым счётчиком discovered tests в CI.
Финальный вывод
CI — это не инструмент контроля качества системы. Это инструмент контроля того, что тесты не упали.
И если вы используете его как индикатор качества — вы просто получаете ложную уверенность быстрее.
CI отражает только одно: тесты выполнились без явных ошибок.
CI не отражает: тесты запустились правильно, в правильном количестве, с правильными предположениями об окружении.
Если система может быть “зелёной” и при этом работать некорректно — значит у вас есть статус выполнения, но нет наблюдаемости.
Как это выглядит в реальной системе
Именно этот кейс лёг в основу проекта, который я собирала как QA portfolio. В pipeline добавлен счётчик discovered tests: если количество отклоняется от ожидаемого, CI падает явно, а не молчит. Рядом — buggy branch с намеренно сломанной конфигурацией, чтобы можно было воспроизвести и починить самостоятельно.
Если собираешь QA портфолио или готовишься к техническому собеседованию — в Telegram-канале Тесты как система (https://t.me/qa_as_a_system) разбираю такие кейсы с кодом и объяснением: что показывать, как объяснять решения, какие находки работают на собеседовании.
РБПО по ГОСТ Р 56939—2024: вебинар №15 из 30 – Обеспечение безопасности используемых секретов
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Примечание — В данном подразделе под секретами понимаются данные в любом виде, которые могут использоваться для обеспечения аутентификации и/или целостности и/или конфиденциальности информации (пароли, цифровые сертификаты и т. п.), в том числе путём применения в соответствии с законодательством Российской Федерации средств криптографической защиты информации или иными методами.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
🔥SEO умерло? Добро пожаловать в эпоху нейропоиска и AEO!
Классические «синие ссылки» уходят в прошлое. AI-ответы от Яндекса, Google и ИИ-ассистентов меняют правила игры. Трафик падает, воронки рушатся. Что делать? Оптимизировать под нейросети или уходить в AEO (Answer Engine Optimization)?
Приходите разбираться с ведущими экспертами рынка.
21 мая | 18:00 Лофт «Атмосфера» (ссылка на регистрацию)
Кто выступает: Михаил Сливинский (Яндекс), Денис Шубенок (CEO «Ашманов и партнеры»), Иван Макаров (Дзен), Роман Троицкий (Сбер), Павел Пряников («Блог Толкователя») и другие топ-специалисты из «Финама», SmartCare, Shkulev Media.
О чём поговорим: — Почему нейропоиск обнуляет старые воронки трафика. — Как «Алиса» ранжирует ответы на информационные запросы. — Как превратить LLM из генератора текста в инструмент роста конверсий. — Переход от SEO к AEO: новые KPI для медиа.
Программа: 18:00 – Нетворкинг 18:30 – Дискуссия «Угроза и адаптация» 19:30 – Разбор факторов ранжирования «Алисы» от Дениса Шубенка 19:45 – Дискуссия и кейсы «Как ИИ меняет маркетинг»
Приходите на вебинар — покажем, как выстроить резервное копирование, которому можно доверять
Бэкап есть почти у всех. Но одно дело — хранить копии, другое — быть уверенным, что при сбое инфраструктура поднимется в нужные сроки и без потерь. Как перейти от «копии существуют» к «восстановление работает»?
Разберем это на совместном вебинаре с экспертами Cloud.ru и оператором ИТ-решений ОБИТ. Будет полезно ИТ-директорам, директорам по ИБ, системным архитекторам, инженерам и администраторам — всем, кто отвечает за сохранность данных в облаке.
Что расскажем и покажем:
какие практики резервного копирования актуальны сейчас и в чем их различия;
почему классическая стратегия 3-2-1 на практике может не выполнять свою функцию;
почему сторонний бэкап становится стандартом, а не опцией;
как опыт интегратора влияет на результат — и что меняется, когда интегратор и вендор работают в связке;
реальные кейсы: что именно это дает бизнесу.
В практической части пройдемся по интерфейсу SaaS-решения Cloud.ru. В прямом эфире покажем процесс восстановления машины из резервной копии через агента и разберем, как встроить решение в существующую инфраструктуру без глобальных переделок.
📅 Когда? 26 мая в 11:00 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам в прямом эфире.
Новости законодательства: биометрия в аэропортах, сверхурочные до 240 часов и перенос номера в другой регион
Подобрала для вас несколько интересных новостей
Эксперимент по допуску авиапассажиров на борт по биометрии начнётся с 1 июня 2026 года
С помощью единой биометрической системы будут по желанию пассажиров регистрировать их на рейс, пропускать в перевозочный сектор аэропорта и организовывать выход на посадку. Эксперимент продлится до 1 апреля 2027 года. Сначала его проведут в Шереметьево и Пулково.
Добровольно и бесплатно присоединиться смогут авиаперевозчики и владельцы аэропортов. Для этого надо подать в Минтранс заявку. Ряд компаний задействованы в пилотном проекте по умолчанию.
Если заявку одобрят, нужно будет доработать информсистемы для взаимодействия с аналогичными ресурсами. Использование биометрии не отменит обязанность пассажира предъявить при досмотре документ, удостоверяющий личность.
Обратите внимание: владельцы аэропортов и перевозчики (из числа участников эксперимента) смогут получать из ЕСИА ряд сведений о пассажирах. Речь идёт о Ф.И.О., реквизитах документа, контактных данных и т.д.
Сейчас по биометрии можно посещать бизнес-залы ряда аэропортов.
Документ: Постановление Правительства РФ от 10.05.2026 N 541
Увеличение годовой нормы сверхурочной работы: поправки к ТК РФ прошли третье чтение
Планируют установить, что продолжительность сверхурочной работы для каждого сотрудника можно увеличить со 120 до 240 часов в год, если это зафиксировать в коллективном договоре или отраслевом соглашении. Изменение не затронет тех, кто работает во вредных условиях труда 3 и 4 степеней.
Предпенсионеров, пенсионеров и сотрудников с вредными условиями 1 и 2 степеней разрешат привлекать к сверхурочной работе свыше 120 часов в год только с их письменного согласия и при отсутствии медицинских противопоказаний, также необходимо их письменно ознакомить с правом на отказ.
Оплата: ⦁ в пределах 120 часов - как сейчас: первые 2 часа не менее чем в полуторном размере, последующие - не менее чем в двойном; ⦁ с 121-го часа - не менее двойного размера за каждый час.
Право работника на дополнительный отдых вместо повышенной оплаты (по его желанию) сохранится.
Новое: те, кто работал сверхурочно больше 120 часов в год, смогут брать 1 выходной в год для диспансеризации. На это время за сотрудником сохранится место и средний заработок.
Напомню, норма о том, что сверхурочная работа не должна превышать 4 часов в день - сохраняется. Правило привлечения работника к такой работе с его письменного согласия (за исключением чрезвычайных обстоятельств- например, для предотвращения аварии или катастрофы) - также продолжает действовать.
Планируется, что поправки заработают с 1 сентября 2026 года.
Документ: Проект Федерального закона N 1103297-8
Перенести номер мобильного телефона в другой регион можно будет с 1 сентября 2026 года
Абоненты смогут переносить номер телефона между операторами связи по всей территории страны, а не только в пределах одного региона, как сейчас. Для этого в заявлении потребуется указать субъект РФ, куда надо переместить номер.
Также можно будет попросить своего оператора закрепить номер за другим регионом. В таком случае клиент обязан выбрать тарифный план из тех, что действуют в субъекте назначения, и при необходимости получить там неактивированную сим-карту.
Хорошая возможность для тех, кто переезжает, но не хочет менять номер.
Документ: Постановление Правительства РФ от 30.04.2026 N 510
А что вы думаете об этих изменениях? Пойдёте на эксперимент с биометрией или будете предъявлять паспорт? Как вам увеличение сверхурочных до 240 часов? Делитесь мнением в комментариях 👇
Как мы сократили маркетинговый аудит с 30 часов до 4: конкретные промпты и стек инструментов
Маркетинговый аудит — задача которую большинство агентств делают руками. У нас это занимало 30 часов на проект. Сейчас занимает 4.
Конкретный стек и промпты — без абстракций про «ИИ ускоряет работу».
Стек: разные модели под разные задачи
Claude Sonnet → анализ текстов ЦА, паттерны в кастдевах
ChatGPT-4o → юнит-экономика, таблицы, структуры
DeepSeek → конкурентная разведка, анализ рекламы
Perplexity → сбор актуальных данных с источниками
Использование одного ChatGPT «на всё» даёт 30–40% от возможного выигрыша. Ключевое — каждый инструмент на своей задаче.
Этап 1: анализ кастдевов
Было: аналитик читает расшифровки интервью вручную — 6–8 часов на 10 интервью.
Стало: загружаем в Claude.
Ты маркетолог-аналитик. Расшифровки интервью
с покупателями [ниша].
Задача:
1. Выдели боли и страхи — дословными цитатами
2. Сгруппируй по паттернам
3. Для каждой группы: частота,
эмоциональный вес (1-5),
этап принятия решения
4. Выдели фразы для рекламных текстов
Формат: таблица + цитаты по каждому паттерну.
Расшифровки: [вставить]
Результат: структурированная карта болей за 40 минут.
Анализ конкурентов, ниша [X], регион [Y].
Для топ-10 определи:
- Позиционирование (одно предложение)
- Основной канал привлечения
- Главное УТП
- Слабые места из публичных данных
Источник для каждого факта — обязательно.
Шаг 2 — синтез через ChatGPT:
Данные по 10 конкурентам: [таблица]
1. Найди незанятые ниши позиционирования
2. УТП которые никто не использует,
но актуальны для ЦА
3. Каналы которые конкуренты недоиспользуют
4. Гипотезы для A/B тестирования
Только конкретные формулировки.
Время: 1.5–2 часа вместо 8–10.
Что не автоматизируется
- Тайный покупатель (пройти воронку конкурента)
- Оценка «зайдёт ли креатив аудитории»
- Данные которых нет в открытом доступе
- Ответственность за результат перед клиентом
Примерно 70% аудита автоматизируется, 30% остаётся за человеком. Эти 30% — интерпретация и решения — и есть основная ценность аналитика.
Итог
Этап Было Стало
────────────────────────────────────
Анализ кастдевов (10) 7ч 40мин
Конкурентная разведка 9ч 2ч
Анализ рекламы 5ч 1ч
Юнит-экономика 4ч 30мин
Синтез и оформление 5ч 2ч
────────────────────────────────────
Итого 30ч ~6ч
Реальная цифра — 4–6 часов в зависимости от ниши. 4 в заголовке — минимум для простых ниш с хорошими открытыми данными.
Какие этапы аналитики вы уже автоматизировали через LLM — и где попытки не дали результата?
В Minecraft теперь можно создать идеальный мир — игроки нашли способ создать карту, на который вообще все биомы, ресурсы и ключевые структуры расположены в 1000 блоков от спавна. Магия реализуется с помощью сида — это специальный номер, который всегда будет генерировать один и тот же мир. Идеальную структуру искали почти 15 лет. При создании мира пишем сид: 8500081009970950196.
Когда архитектору нечего делать, а гибкость у спины уже не та, что раньше - он начинает разговаривать сам с собой или с ИИ. Проблема, которую хотелось решить достаточно редко встречается - как бы сохранить преимущественно пустые массивы данных для аудита и не разориться при этом спустя несколько месяцев. Чтобы обуздать неуёмные галлюцинации - ИИ сразу был ограничен широко распространёнными архиваторами, результат работы которых желательно открывается из под win систем также как и из под *nix .
С позволения читателей я не буду пересказывать процесс, и перейду к тому, до чего ИИ дошёл - до 7z с рядом флажков. В прилагаемом ниже архиве вместо реальных данных - тестовые и совсем-совсем пустые. Но что ИИ пока не сумел придумать, и что внушает надежду на будущее людей в программировании и вокруг - полученный архив логично было архивировать ещё раз, тем-же 7z . Результат лично мне кажется интересным. Все желающие могут попробовать скачать почти 2 килобайта архива и предположить - какова же ёмкость исходных данных? А потом проверить себя, думаю результат вас удивит.
Архив можно Скачать с SendSpace повторюсь - в нём внутри лежит ещё один 7z архив, а уже в том - тестовые файлы числом менее 20.
Чтобы случайное разархивирование не испортило сюрприз - внешний архив закрыт паролем
Galantereyshik_i_Kardinal_eto_sila
Логически, при ещё большем количестве данных - рекурсию можно будет повторить, но в ближайшем будущем мне кажется и так неплохо вышло. Во всяком случае совсем не каждый ssd сумеет в себя вместить разархивированные из этих 1841 байтов исходные данные.
Предполагаю, что с теорией предмета знакомы все, попробуйте сами получить небольшой архив любым из широко распространённых архиваторов из скажем sparse файла в 5 гигабайт. Спорим он у вас получится больше прилагаемого к посту архива, в котором лежат терабайты.
В Anthropic есть два основных режима: 5 минут и 1 час
5m TTL — это не 5 минут от записи кэша
Это 5 минут с последнего cache hit. Пока вы активно работаете, таймер продлевается. Но если отошли на 6 минут, следующий запрос может снова записывать весь кэш
1h TTL дороже на запись, зато переживает длинные паузы
Множители такие 🔽🔽
• cache write 5m — 1.25× от обычного input • cache write 1h — 2× • cache read — 0.1×, то есть примерно 90% скидка
Поэтому кэш окупается почти сразу. По дефолту в Claude Code кэш пишется на час, но можно записывать и на 5 минут в настройках config
Подписка не делает кэш бесплатным
Если вы не API-пользователь, а сидите на Claude Pro / Max, механика всё равно та же
Просто вместо долларов вы тратите квоту 5h / 7d лимитов
И поэтому старая сессия на 300K токенов утром после истёкшего TTL может сжечь ощутимый кусок лимита одним «привет»
Как ощутить кэш
1. Откройте длинную сессию Claude Code, которая больше часа была неактивна 2. Напишите короткое сообщение, например «привет», и засеките Time to First Token — время до первого символа ответа 3. Потом сделайте /rewind и напишите это же сообщение ещё раз
Во второй раз ответ должен появиться примерно в 5 раз быстрее
А если хочется посмотреть цифры — можно пройтись по JSONL-логам Claude Code и посмотреть долю cache_read_input_tokens
Если в длинных агентных сессиях cache reads сильно ниже 80%, вы, скорее всего, что-то делаете не так
Главный вывод
Prompt caching — это причина, почему современные агентные LLM вообще можно использовать в длинных сессиях: с инструментами, историей, файлами, планами, правками и сотнями тысяч токенов контекста
Без кэша каждый новый шаг агента был бы полным перечитыванием прошлого
Небольшой пост по кэшированию в современных LLM и почему это важно понимать ⭐
Это один из тех механизмов, который на прямую влияет на ваши пятичасовые и недельные окна. Ну и, конечно, на прямые расходы, если вы платите через API
-------------------
Вся архитектура Claude Code и других агентных LLM построена вокруг prompt caching
Без него работа современных агентных систем была бы на порядок дороже
И при этом про кэширование почти никто не знает. Давайте разбираться ⤵️
Сначала: что такое вообще это ваше кэширование
Кэш — это когда система не пересчитывает одно и то же заново, а сохраняет уже готовый результат и переиспользует его
С его помощью становится возможным эффективное переиспользование ранее просчитанных данных
Например, браузеры не скачивают логотип сайта при каждом открытии страницы. А берут его из локального кэша. Поэтому страница открывается быстрее, а серверу не надо отдавать один и тот же файл тысячу раз 🥰
С LLM логика похожая, только вместо картинок и файлов кэшируется часть вычислений внутри модели
Почему это критично для LLM
Модель STATELESS
КАЖДЫЙ РАЗ, когда вы отправляете сообщение в модель — не важно, Codex, Claude Code или Gemini CLI — в модель отправляется ВСЁ КОНТЕКСТНОЕ ОКНО, а не только ваше последнее сообщение
system prompt + tools + история диалога + новое сообщение
Она ничего не помнит и не знает о вас между запросами
А спустя час Claude Code пишет вам:
new task? /clear to save 161.5k tokens
Это значит, что сохранённый кэш длинного контекста уже не стоит считать надёжно доступным, и следующий запрос может потребовать полного пересчёта
Без кэша это дорого и медленно
Как работает prompt caching
У моделей бОльшая часть контекста не меняется от запроса к запросу
System prompt тот же. Описание инструментов то же. Большая часть истории та же. Меняется только новое сообщение в конце 🙏
Поэтому модель не пересчитывает весь этот повторяющийся префикс заново, а читает уже подготовленный кэш
Что именно кэшируется внутри
Под капотом трансформера для каждого токена считаются специальные Q/K/V-представления: Query, Key и Value
Для нового токена Query считается заново. А вот Key и Value для прошлых токенов уже были посчитаны раньше и не меняются, если префикс тот же
Модель уже прочитала старый контекст и держит его в готовом виде. И если префикс совпал, можно не пересчитывать его заново
Почему кэш легко сломать
Prompt caching работает только при точном совпадении префикса
Один лишний пробел, другой system prompt, изменившийся список tools — и совпадение ломается
В Claude Code порядок примерно такой:
System Prompt → Tool Definitions → Chat History → Current Input
И инвалидация каскадная: если поменялось что-то сверху, слетает всё ниже 💀
Например, если подключить или отключить MCP-сервер в середине большой сессии, то весь кэш слетит
Изменились tool definitions → сломался кэш tools, system и messages → следующий запрос перечитывает всё заново
Что ломает кэш
• Подключили или отключили MCP-сервер — слетает почти всё • Включили web search — слетает system + messages • Поменяли tool_choice — слетают messages • Сделали compact — изменилась история, старый кэш уже не совпадает • Поменяли reasoning / effort level — история перечитывается заново • Сменили модель — кэш физически остаётся, но у другой модели свой namespace, поэтому он не работает
Эхо из прошлого: ошибки архитектуры могут "выстрелить" спустя годы (благодаря WebArchive)
Представьте: 8 лет назад была небезопасная архитектура с IDOR. Т.е. можно было получить доступ к документу просто зная его ссылку. А ссылки чудным образом попали в WebArchive (он же - Wayback Machine). Спустя время архитектуру поменяли и проблема ушла. Но, WebArchive всё помнит: ссылки уже успели сохраниться. И кто-то, спустя многие годы, публикует статью с указанием ссылок на WebArchive, где указаны персональные данные и платёжки клиентов. Внимание, вопрос: успокоит ли общественность реакция в стиле: "да это давно было, сервиса уж нет"?
Вот один из сохранённых по ссылке документа: он сохранился в Wayback Machine в 2018 и до сих пор доступен.
С этой книгой у меня вышла совершенно удивительная история.
Лет 10 назад собственник проводил обучение руководителей, в т.ч. меня. Рассказывал о методах, книгах, практиках. В том числе – упомянул Кена Уилбера.
Теперь внимание. Из всего Кена Уилбера было упомянуто: имя, фамилия, название книги и одна фраза: чтобы перейти на новый уровень, надо на нём побывать.
Фразу я запомнил. И потихоньку стал применять. Года через три, очутившись в среде, где мне надо было массово выращивать программистов, тимлидов, руководителей, я без этой неточной цитаты Уилбера сдался бы через месяц.
Потому что я работал с зумерами 😊. Они отличные ребята, но есть у них забавная особенность – другое отношение к ответственности, если сравнивать с миллениалами. Для нас ответственность – это возможность, для них – непонятный, ненужный геморрой. Мне же очень надо было делегировать этим ребятам часть ответственности.
Традиционный подход в управлении – создавать Должности, вроде Руководителей, и позволять/предлагать людям эти Должности Занимать. Уже страшно звучит 😊. Занятие должности, опять же традиционно – это игра ва-банк. Был спецом, стал Начальником, и если не справился – даунгрейд почти невозможен, ибо позорище.
Потому спецы не хотят быть начальниками. Даже не смотрят в эту сторону. Зумеры – тем более.
Следуя цитате Уилбера, я заменил Должности на роли. Роль можно играть день, два, месяц, год – а потом перестать. Роли можно совмещать – быть одновременно программистом и тимлидом. Роль – это безопасная возможность попробовать, не влезая на пьедестал и не падая в лужу.
И в роль можно входить несколько раз, делая любые перерывы между попытками. Всё как у Уилбера – побывать на уровне. Разок, другой, потом перестать бояться и, если роль нравится – остаться в ней надолго.
В итоге всё получилось. Зумеры стали ответственнее миллениалов. Я делегировал всё, что было на мне. Теперь у меня зумеры учат зумеров ответственности 😊.
И вот решил я воздать должное Кену Уилберу – купил и прочитал его книгу. И что бы вы думали?
Я не понял НИ ХРЕНА ВООБЩЕ.
Я не нашёл своей любимой цитаты, не понял ни одной таблицы и схемы, не уловил замысла и цели ни книги, ни автора. Полный ноль.
Я оказался в странной, непривычной ситуации. Обычно есть автор и я. Он написал, я прочитал и применил. Но с Уилбером мне помогли – тот человек, что сформулировал смысл в одной короткой фразе. Он сделал за меня всю работу. В этот раз герой – он.
Была в древности наука алхимия – изыскивали, как создать философский камень, превращающий любой предмет в золото. Написали множество книг – говорят, мудрёных и запутанных.
Но есть легенда, что секрет философского камня очень прост, и умещается на небольшой табличке – изумрудной скрижали. Только вот не написали её.
