WebScan — асинхронный CLI-сканер безопасности на чистом Python. За неделю вырос до 15 плагинов: XSS, SQL инъекции, CORS, Path Traversal, SSRF, утечки API ключей и многое другое. Safe Mode, proxy, SOCKS5, пять форматов отчётов включая SARIF.
В статье разбираю архитектуру и сравниваю с Nikto.
Взяли автоэнкодер из свежей работы CALM (Continuous Autoregressive Language Models), который учится упаковывать чанк из K=4 токенов в один непрерывный вектор и разворачивать обратно, и обучили его не на 15 миллиардах токенов Pile на 8 GPU, как в оригинале, а на 18 тысячах коротких строк с требованиями из IT-вакансий - на обычной машине без видеокарты. По дороге выгребли три классических грабли (flash-attn без CUDA, deepspeed, который не импортируется под NumPy 2.x, и тихий OOM на 33 ГБ логитов). Ниже - подробный разбор архитектуры, конфигов и честные результаты round-trip-реконструкции.
На третий день в проде мой support-агент на LangGraph и GPT-4o слил email одного клиента в переписку с другим. Причина банальна: модель вставила сырой контекст из базы прямо в ответ, и ничто в пайплайне это не проверяло. Фреймворки для агентов дают оркестрацию, вызов инструментов и память — но не безопасность. В этой статье разбираю стек из четырёх guardrails (валидация входа, валидация выхода, circuit breaker по расходам и проверка вызова инструментов), который умещается в ~200 строк Python и добавляет менее 40 мс latency. С рабочим кодом, схемой пайплайна и честным разбором того, что эти guardrails ловят, а что — нет.
Наверняка вы видели портреты, собранные из одной нити, натянутой между сотнями гвоздей. Я решил проверить: можно ли научить нейросеть генерировать не готовую картинку, а инструкцию, по которой такая картинка строится?
Я провел простой эксперимент и превратил цифры MNIST в последовательности переходов между 256 гвоздями и обучил небольшой Transformer продолжать путь нити. В результате модель выдаёт не PNG, а JSON-траекторию, которую можно отрисовать в любом разрешении - или потенциально передать физической string-art установке.
Код выложил на GitHub
Миллион асинхронных задач на Rust спокойно живёт в нескольких сотнях мегабайт. Сто тысяч корутин на Python нередко упираются в память раньше. Дело не в том, что “Rust быстрый, а Python медленный” - дело в том, ГДЕ физически лежит состояние приостановленной задачи.
Разбираю, во что превращается ваш async fn после компиляции: стейт-машина на стеке против объекта в куче. Сравниваю модели Rust (Tokio), Python (asyncio), C# и JavaScript - кто аллоцирует на каждый await, а кто нет, и почему это видно на счётчике RAM при 100k задач.
Внутри: что генерирует компилятор, куда уезжает состояние между await, stackful против stackless, и что с этим делать сегодня.
Всем привет!
Telegram меня наконец-то услышал! Ну ладно, не только меня, а может, и не слышал вовсе, но недавний апдейт клиента и вчерашнее обновление Telegram Bot API 10.1 попали прямо в меня.
Дуров и команда ввели Rich Messages — полноценную альтернативу обычным сообщениям, в которых можно конструировать сложную структуру контента с помощью Rich Markdown или HTML-разметки. Кроме того, теперь появилась возможность явно использовать бота в роли полноценного модератора (гварда) на стыке с Mini Apps. Но обо всём по порядку.
Если вам интересны подобные материалы и разработка в целом, подписывайтесь на Telegram-канал «Код на салфетке».
Последнее время я всё чаще встречаю одну и ту же мысль: бизнес никогда не даст ИИ‑агенту доступ к базе клиентов, заявкам, платежам, CRM или внутренним документам. На первый взгляд звучит логично. Если агент ошибётся, перепутает контекст или выполнит не то действие, ущерб может быть вполне реальным. Но мне кажется, что здесь часто путают две разные вещи.
Давать агенту прямой доступ к базе действительно нельзя. А вот давать ему возможность работать через ограниченный, проверяемый и журналируемый контур действий вполне можно. Примерно так же мы не даём пользователю прямой доступ к PostgreSQL, но разрешаем ему нажимать кнопки в интерфейсе, которые вызывают заранее описанную бизнес‑логику.
В этой статье я хочу как раз таки разобрать, как может выглядеть такой контур на практике: без магии, без «агент всё сам решит», без сырого SQL от модели и без веры в то, что хороший prompt заменяет нормальную архитектуру.
В этой статье мы рассмотрим цепочку радиоактивного распада урана-238 и определим, сколько образуется конечного продукта - стабильного свинца через время t.
Property‑тесты умеют находить ошибки на самых неожиданных входных данных. Но настоящая магия начинается после падения теста: вместо списка из сотен случайных значений Hypothesis часто показывает один короткий и предельно понятный контрпример.
Разбираемся, как работает shrinking, почему ручные shrinker'ы плохо масштабируются и за счёт чего Hypothesis умеет минимизировать ошибки практически автоматически.
Здравствуйте, дорогие читатели! Сегодня - ещё одна статья из рубрики джангологии.
Раньше я уже писал о своих идеях (1 и 2) о том, как сделать django асинхронным. Они основывались, вслед за sqlalchemy, на использовании гринлетов. Несмотря на то, что proof-of-concept был успешно получен, а трудностей - встречено меньше, чем ожидалось, я всё-таки отказался от этого подхода: во-первых, он уже применяется в sqlalchemy. Во-вторых, это ведёт к усложнению, и растёт так называемая test matrix - потому что поддерживается как синхронный случай, так и асинхронный. А simple, как мы знаем, is better than complex.
Так вот, я решил возобновить эти свои попытки, изменив подход на более радикальный. А именно, необратимо переписать django на async-only, сломав совместимость полностью. Для этого потребуется заменить в половине функций def на async def и добавив await при их вызове. Я уверен, что такой подход лучше.
Не то, чтобы асинхронный django был очень кому-нибудь нужен, особенно теперь, или от этого будет какой-то фантастический выигрыш в производительности - дело в том, что я хочу попробовать на практике агентное программирование, а это, как раз подходящий проект: есть чёткий план и много кода, который нужно менять.
Современная физика удивительно успешна в описании природы, но до сих пор опирается на набор фундаментальных констант, происхождение которых остаётся неизвестным. Почему именно такие значения имеют скорость света, постоянная Планка или гравитационная постоянная? Можно ли вывести их из более глубокого принципа?
В этой статье рассматривается теория эмерджентной физики на квантовом графе - исследовательская модель, в которой физическая реальность описывается как грандиозный информационный граф. Геометрия пространства-времени, спектр масс частиц и фундаментальные константы возникают как следствия структуры этого графа и его спектральных свойств. Мы разберём основные идеи теории, математический аппарат, вычислительные эксперименты и результаты, полученные в рамках открытого репозитория проекта.
Привет, Хабр! В прошлых статьях я описала, как через нововведенный параметр TSI теоретически можно определить грейд разработчика.
В данной статье я хочу пройтись по двум самым популярным алгоритмам векторного поиска, используемым на практике. Попробуем понять, почему точный поиск не работает в высоких размерностях и почему мы в итоге приходим к приближенному поиску.
Заодно мы затронем тему метрик, чтобы понять, как вообще сравнивают эмбеддинги. Рассмотрим вспомогательный и очень простой алгоритм k-means из классического ML’а, лежащий в основе IVF.
И наконец, подробно разберем два самых главных алгоритма IVF и HNSW с примерами их реализации на Python’е.
В Heroes of Might and Magic III у каждого игрока есть своё мнение о том, какие юниты сильнее. Обычно такие сравнения строятся на характеристиках, способностях, личном опыте или ручных дуэлях на специальных картах.
В этой статье я попробую подойти к вопросу немного иначе: через симуляцию боёв. Я сделал упрощенную модель боевой системы HoMM3, которая позволяет сталкивать отряды юнитов друг с другом много раз при заданных условиях и смотреть, кто побеждает чаще. Дальше разберём, как устроена такая симуляция, какие допущения в ней есть и что можно узнать из результатов.
Привет, Хабр! Я Миша Онянов, Python-разработчик и платформенный инженер в крупнейшем проекте MAGNIT TECH – F&R. Из статьи вы узнаете, как с помощью механизма Cluster Policies в Apache Airflow вынести требования к DAG’ам в исполняемый код:
- Поговорим о том, когда и зачем нужен отдельный слой Policies.
- Посмотрим на примеры требований в больших data-инженерных проектах и способ их реализации с помощью политик.
- Покажу нашу архитектуру, примеры кода и способы внедрения.
- Сделаем выводы из моих ошибок, допущенных при разработке и внедрении.
- В конце посмотрим, в каких ещё системах используется аналогичный механизм.
Материал будет полезен всем, кто собирается внедрять или уже работает с Apache Airflow ✌️🥸
Когда Docker-образ backend-приложения начинает весить 1,5 GB, это уже хороший повод хотя бы посмотреть, что вообще лежит внутри. Пока все работает, мало кто задумывается, сколько мусора, dev-зависимостей и ненужных файлов уезжает в production вместе с приложением. Но на самом деле от «лишнего веса» нужно избавляться, потому что каждый лишний мегабайт — это более долгие сборки и дополнительные сложности.
Можно ли построить шифрование, если под рукой есть только SHA-256 и Blake3? В этой статье разберем рабочую и надежную схему построения такого алгоритма.
У нас есть форма, куда пользователь вводит ИНН контрагента, а мы по нему идём за данными в ЕГРЮЛ. Если заглянуть в логи этой формы, видно сколько туда прилетает мусора. ИНН из одиннадцати цифр (кто‑то добавил лишнюю), номера со срезанными ведущими нулями, ОГРН в поле для ИНН, и классика жанра — две соседние цифры переставлены местами. Каждый такой ввод это поход в чужой API, таймаут, ожидание, и в конце честное «ничего не найдено». А пользователь в этот момент уверен, что сломались мы.
Всем привет! Я Дмитрий Милов, Python-разработчик компании МУЛЬТИФАКТОР в команде продукта MULTIDIRECTORY, мы разрабатываем собственную службу каталогов.
Как это обычно бывает в процессе развития продукта, код постепенно перестает помещаться в привычные рамки. Мы начали обсуждать, какое архитектурное решение лучше подходит нашей системе. Спор об определениях затянулся: у каждого были аргументы, почему одно решение лучше другого.
Почему продолжается путаница в концепциях, которые давно описаны и формализованы?
Держите LLM подальше от тестов чат-бота
Кто тестировал чат-бота, знает: на одной реплике всё просто, а на третьей-четвёртой начинается боль. Бот должен помнить имя, которое вы назвали два хода назад, держать слоты и не сваливаться в «уточните ваш запрос» на ровном месте. И как только садишься это проверять, упираешься в развилку: чем, собственно, проверять ответы многоходового диалога.
