Если вы когда-нибудь задумывались о том, на сколько лет хватит ваших накоплений после выхода на пенсию — эта статья для вас. Мы разберём, как с помощью open-source библиотеки okama для Python можно моделировать и тестировать различные стратегии снятия денег с инвестиционного портфеля. От классического «правила 4%» до продвинутых адаптивных стратегий — всё с примерами кода.
Если вы когда-нибудь пытались натравить классическую LSTM на минутные свечи волатильных активов, вы знаете эту боль. Сначала Loss красиво падает на трейне, вы предвкушаете покупку острова, а на тесте модель превращается в тыкву. Она либо предсказывает скользящую среднюю со сдвигом на один шаг, либо упирается в «стену» Loss = 0.693 (то есть −ln(0.5)), сводя всё к подбрасыванию монетки.
Проблема не в вас. Проблема в том, что рекуррентные сети (RNN, LSTM, GRU) живут в дискретном времени. Для них шаг между 10:00 и 10:01 абсолютно идентичен шагу между пятницей и утром понедельника. Они не умеют сжимать и растягивать восприятие времени, когда волатильность взрывается.
В этой статье мы отойдем от мейнстримных архитектур и напишем с нуля Liquid Neural Network (Жидкую Нейронную Сеть). Мы заставим время течь непрерывно, используя численные методы дифференциальных уравнений прямо внутри PyTorch-графа, и посмотрим, как она вытаскивает скрытый макро-тренд из абсолютного рыночного хаоса.
Теория без воды: Что делает сеть «жидкой»?
Концепция Liquid Time-Constant Networks была представлена исследователями из Лаборатории искусственного интеллекта MIT (CSAIL). Их изначальная цель — управление дронами и автопилотами в непредсказуемой среде. Но финансовые рынки — это та же турбулентность, только выраженная в долларах , рублях и других валютах.
В классической RNN скрытое состояние $h_t$ обновляется по дискретным шагам:
$$h_t = \tanh(W_{in} x_t + W_h h_{t-1} + b)$$
В Liquid Network мы отказываемся от дискретности. Состояние нейрона $h(t)$ — это непрерывная переменная, описываемая обыкновенным дифференциальным уравнением (ОДУ):
Механизм внимания (Attention) - это метод в искусственном интеллекте, который позволяет нейросети динамически определять, какие части входных данных наиболее важны для текущей задачи. Он работает через вычисление весов важности для разных элементов входа: более важные элементы получают больший вес, а менее важные - меньший. Затем модель формирует взвешенную сумму представлений, создавая новый контекстный вектор.
Self-attention, в свою очередь, помогает модели понимать, как разные элементы входных данных связаны между собой. Например, как разные части информации взаимодействуют и влияют друг на друга в общем контексте. Этот механизм обеспечивает логическую связность и целостное понимание всей структуры данных
Когда аугментации в детекции «не работают», проблема часто не в модели, а в bbox после преобразований.
Неверный coord_format, перепутанные нормализованные и абсолютные координаты, агрессивные кропы, пустые боксы после фильтрации — всё это не ломает код, но quietly ломает обучение.
В статье разбираю:
— какие форматы bbox поддерживает Albumentations — как правильно настраивать A.BboxParams — когда использовать min_area и min_visibility — почему обычный RandomCrop часто плохая идея для detection — и где пайплайн чаще всего ломается на практике
Если вы работаете с COCO, YOLO, pascal_voc или просто хотите перестать обучать модель на испорченной разметке — этот материал для вас.
Спойлер: Никаких банальных ИИ-оберток, где текст конвертируется в звук через API. Только хардкорная хирургия нейросетей, кросс-модальные мосты и перехват мыслей LLM в реальном времени.
За последний год Hugging Face превратился в конвейер одинаковых проектов: берем Llama/Gemma, прикручиваем к ней интерфейс на Gradio, называем это стартапом. Мы для нашего виртуального музыкального артиста Livadies решили пойти другим путем. Мы задались вопросом: как звучит чистая мысль нейросети, если не переводить ее в текст? И как звучит математическая геометрия доисторического камня или кожи рептилии?
Чтобы это выяснить, нам пришлось вскрывать архитектуры SOTA-моделей и сшивать их напрямую на уровне тензоров. Вот два наших главных инженерных эксперимента.
Здравствуйте.
Думаю многие видели, что буквально только что, claude решили резко поменять политику и отключить работу своего решения в сторонних приложениях. То есть даже подписчики их платной подписки за 100 usd, среди которых был и я, теперь не могут использовать удобные безлимитные(в рамках лимитов) решения.
В основном это было сделано из-за безумно популярного агентского решения openclaw, которое в связке с claude sonnet/opus просто идеально. Работало это так. Подключаешься через oauth токен, для claude code и используешь все возможности подписки.
Теперь же claude выдает ошибку LLM request rejected. Они конечно на сайте выложили 100 usd, как компенсацию всем тем людям, что теперь будут вынуждены платить огромные суммы за extra usage, но это все равно не решение.
Идея
Так как работать, так невозможно, мною было решено реализовать прокси сервер для подключения к апи claude через браузерную сессию и сделать для него апи в совместимом openai формате. Чтобы легко можно было интегрировать, как сторонний провайдер в openclaw.
Реализация была поручена одному из лучших моих агентов, по имени Гарри c наибольшим кол-вом накопленного опыта по мере множества моих проектов и работ. Да пока что за их 100 usd бонусный лимит extra-usage.
Max запустили как полноценную альтернативу Telegram для российского рынка, с открытым Bot API. Разработчики оказались перед классической дилеммой: поддерживать двойную кодовую базу или выбрать одну платформу, теряя аудиторию второй.
Типичная ситуация выглядит так: есть готовый Telegram-бот на aiogram, и нужно запустить его ещё в Max. Варианты неприятные — либо дублировать код, либо писать тонну адаптеров вручную, либо мириться с расхождением фич между платформами.
Библиотека obabot предлагает другой путь: один код — два мессенджера.
С завидным постоянством в тематических каналах возникают вопросы про 429 и 50x HTTP ошибки при получении данных из API WB или OZ. Коллеги интересуются, нет ли особого параметра, секретного метода или «золотого» часа, когда гарантированно можно получить данные без ошибок.
Увы, нет. Поэтому надо искать пути решения. Самый очевидный из них — относиться к 429 и 50x как к штатной ситуация и соответственно ее обрабатывать программной логикой.
Пример функции опроса API может выглядеть как‑то так:
Возможность делать скриншот — это базовый минимум, который есть во всех современных смартфонах. Даже у героев вечных споров, iOS и Android используются похожие комбинации «Громкость + Кнопка питания». Разве что на iOS используется «+», а в Android — «-».
Пятнадцать лет назад все было иначе. На устройствах было больше кнопок, но возможность сделать скриншот была роскошью. Задача осложнялась тем, что бюджетные телефоны на платформе S40 не имели многозадачности, так что написать универсальное приложение-скриншотер на телефон было невозможно.
Тем не менее, решения были. В этой статье я проведу небольшой экскурс в историю программ для скриншотов с телефона, кратко расскажу про протокол Phonet и, возможно, вызову легкие приступы ностальгии.
У меня был Nokia 6303 classic — стильный телефон с металлической крышкой на платформе Nokia Series 40 (S40). Мой путь с этим телефоном разошелся, но спустя почти полтора десятка лет я решил, что хочу разобраться в технологиях, которые использовал, будучи школьником.
Я нашел в продаже б/у Nokia 6303 classic и погрузился в тему.
Сейчас каждый второй стартап пилит ИИ-агентов. Мы оборачиваем LLM в цикл Промпт -> Вызов инструмента -> Ответ и ждем, что нейросеть сама расследует инцидент, найдет баг или напишет фичу. Но на практике автономные агенты часто ходят по кругу, игнорируют явные ошибки и «влюбляются» в свою первую догадку.
Индустрия пытается лечить это костылями: наращивает контекст до миллионов токенов или заставляет модель «подумать шаг за шагом» (Chain-of-Thought). Я решил проверить эту архитектуру на прочность. Собрал локальный измерительный стенд LOCK-R, вооружился Теоремой Байеса и поймал современные LLM за руку.
В этой статье я математически докажу, почему одиночные агенты структурно уязвимы, как токены размышлений заставляют их врать самим себе еще искуснее, и почему паттерн «Слепого Судьи» - это единственный способ вылечить AI от предвзятости. Тестируем на локальной Qwen-9B и фронтирной GPT-5.4.
Каждый, кто льет трафик с Директа, рано или поздно сталкивается с одной и той же шизой: интерфейс Директа показывает одни конверсии, Метрика совершенно другие, и хрен поймешь, кому из них верить. Плюс всегда хочется видеть общую картину: расходы, отказы, реальные лиды и качество трафика по кампаниям в одной нормальной таблице, а не скакать по десятку вкладок.
В этой статье я покажу, как собрать связку простых Python-скриптов, которые стягивают данные из обоих API и сводят их в единый дашборд. Никаких громоздких BI-систем и баз данных только хардкор, requests и pandas.
Заодно подсвечу несколько неочевидных грабель Яндекса, о которые сам успел разбить лоб.
Привет, Хабр и читатели!
Сегодня я попытаюсь сделать с вами диалект LISP.
Я думаю, что я достаточно хорошо понимаю как его сделать.
Мы реализуем там TCO, FEXPR функции и dynamic scoping.
Во многих fullstack-проектах на Next.js и Django авторизация разваливается в одном и том же месте. На фронте удобно использовать NextAuth, потому что он закрывает формы входа, OAuth, серверную сессию и клиентские хуки. На бэкенде хочется иметь обычный JWT-контур на Django REST Framework, чтобы защищать API, работать с access и refresh токенами и не привязывать бизнес-логику к фронту. В итоге часто получается неприятная схема: пользователь логинится через NextAuth, потом отдельно логинится в Django, потом где-то вручную перекладываются токены, а через пару недель вся эта связка начинает ломаться на refresh, logout и OAuth.
Что делаем. Пользователь проходит один вход на фронте, а дальше фронт уже работает с токенами Django как с единственным источником доступа к API. Без второй формы входа, без ручного хранения access token в localStorage, без отдельного костыля под Google OAuth.
Разберем рабочую схему, в которой NextAuth отвечает за пользовательскую сессию на фронте, а Django остается владельцем API-авторизации и выдает JWT. На credentials-входе NextAuth сразу получает access и refresh от Django. На Google OAuth фронт сначала пускает пользователя через провайдера, потом синхронизирует его с Django и тоже получает пару токенов. После этого все запросы идут через один axios-клиент, который сам подставляет access token, сам обновляет его через refresh и сам завершает сессию, если refresh уже недействителен.
Последние пару месяцев у меня случилось много разных созвонов на английском. В целом, я обычно нормально все понимаю, но боюсь упустить что-то важное. Даже субтитры помогают лишь частично. То есть нужен костыль (или аугментация).
Поискал, что есть из того, что может пригодиться.
...
Так в итоге появился мой опенсорсный проектик
Зощенко умел писать точно, коротко и смешно. Попробовал с помощью Python математически установить лексические средства, которые делают язык писателя столь особенным и смешным.
Привет, Хабр! Меня зовут Андрей Горлов, я CEO IT-компании «Альтеркод» и программный эксперт курса «Python-разработчик» в Яндекс Практикуме. Недавно мы провели рефакторинг программы: добавили больше практики, обновили версии фреймворков и сделали обучение более сбалансированным для студентов.
В этом материале мы с продуктовым лидом Александром Скугаревым кратко расскажем об изменениях. Текст будет полезен тем, кто хочет узнать больше о том, как устроено онлайн-образование в IT, и всем, кто думает об обучении Python в Практикуме.
Полгода назад написал первую статью про RBACX — RBAC/ABAC-движок авторизации для Python. С тех пор вышло 25+ релизов, и библиотека стала заметно мощнее: добавил ReBAC с поддержкой OpenFGA и SpiceDB, пакетную проверку прав, ИИ-генерацию политик из OpenAPI-схемы, Redis-кэш, async Django, шортхэнд для ролей и закрыл три security-бага. Рассказываю что, зачем и как это вообще делается в одного.
Вы уверены, что ваш “случайный” пароль действительно случайный?
Я тоже так думал — пока не полез разбираться, как Python на самом деле генерирует случайные значения. Оказалось, что привычный random — это не про безопасность вообще. Это генератор, который только выглядит случайным, но при определённых условиях может быть воспроизведён. Что даст нам возможность предсказать все будущие пароли и прошлые.
В статье я последовательно разбираю:
• почему классическая “энтропия пароля” часто вводит в заблуждение;
• как устроен Mersenne Twister и в чём его фундаментальная проблема;
• почему даже хороший seed (через os.urandom) не делает random безопасным;
• и что на практике можно (и нельзя) восстановить, имея время генерации, код и несколько паролей.
Я попытался воспроизвести реальную атаку: восстановить seed по временной метке и набору сгенерированных паролей. Спойлер — всё оказалось сложнее, чем кажется.
Отдельно показываю, где проходит граница между «кажется надёжным» и «действительно криптостойким», и почему secrets — это не просто «рекомендованный модуль», а принципиально другой класс генерации.
В этой статье рассмотрены две недавние атаки на цепочку поставок, направленные на пользователей популярных пакетов PyPI — litellm и telnyx. Также авторы предоставили рекомендации для разработчиков и сопровождающих проекты на Python о том, как подготовиться и избежать подобных инцидентов в будущем.
Пришёл в проект, там легаси погоняет легаси. Спагетти такие что уже в рот лезут. Отчёты по филиалам открывались 30 секунд. Команда реально боялась нажать кнопку в рабочее время, а вдруг база ляжет.
Это была система управления розничной сетью: несколько филиалов, сотни тысяч записей о заказах, ежедневные отчёты по выручке и остаткам. На бумаге ничего страшного. На практике монолит на Django где бизнес-логика размазана по контроллерам так, что поменяй что-то одно и сломается три другого.
Первое, что я сделал: открыл EXPLAIN ANALYZE.
