Обновить
512K+

Python *

Высокоуровневый язык программирования

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

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.

Теги:
Всего голосов 6: ↑4 и ↓2+3
Комментарии5

Как я научил 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.

Теги:
Всего голосов 9: ↑0 и ↓9-9
Комментарии2

Написал небольшой микросервис на 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
Там будет подробное описание транзакции, включая все "входы" и "выходы", количество отправленных монет, комиссию сети, заплаченную отправителем и так далее.

На этом у меня всё, спасибо за внимание!

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Подключайся ко второму онлайн-митапу MWS для Python-разработчиков 🎙️

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

Будет интересно Python-разработчикам, аналитикам и другим ИТ-специалистам, кто интересуется применением ИИ в разработке.

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

Собери свой 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-канал 😊

Теги:
Всего голосов 4: ↑2 и ↓20
Комментарии0

Анализ истории сделок на предмет перекоса шортистов/лонгистов

Ссылка на GitHub

В 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 заточен именно под это: докупать не по расписанию или по сетке уровней, а только когда ордерфлоу показывает разворот агрессии.

Теги:
Всего голосов 4: ↑3 и ↓1+2
Комментарии0

Golem хамоватый кодинг агент в Telegram

Представьте: вы кидаете ему .zip с проектом, а он выдаёт разбор по архитектуре, находит говнокод, утечки ключей, отсутствие индексов и сообщает, что вся ваша система — «детский сад на колхозе».

Это и есть Golem 666 — мой Telegram-бот, который анализирует код жёстко, без соплей и политкорректности.

Сейчас он уже умеет:

  • Пожирать проекты в .zip и анализировать их

  • Искать баги, уязвимости и архитектурные косяки

  • Давать конкретные рекомендации по исправлению

  • Работать в стриминговом режиме (сообщения приходят по мере генерации)

  • Сам постить отчёты в свой Telegram-канал

  • Ну и конечно пишет скрипт по запросу

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

В ближайших планах:

  • Автоматическое создание репозитория на GitHub

  • Автодеплой после успешного ревью кода

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

Кто уже попробовал подобных агентов — поделитесь в комментариях, насколько они у вас живые и наглые. Интересно сравнить.

#python #ai #telegram #coding #golem

Теги:
Всего голосов 5: ↑0 и ↓5-5
Комментарии7

О прогнозе нейтрального тренда актива

Ссылка на GitHub

Две полоски - лучший и худший случай, его можно прогнозировать
Две полоски - лучший и худший случай, его можно прогнозировать

В 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 тест с синтетическими данными известной волатильности

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Краткая версия Интервью Гвидо ван Роуссума с 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")
Теги:
Всего голосов 5: ↑4 и ↓1+3
Комментарии1

Всем привет. Начал писать открытую книгу про архитектуру безопасных 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-агентов.

Теги:
Всего голосов 6: ↑6 и ↓0+9
Комментарии0

Как я писал софт для фрагментного анализа ДНК

Всем привет! Меня зовут Александр Дориф, я химик, молекулярный генетик и сисадмин-инфраструктурщик в компании 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.

FragalyseQt 0.5 - экспорт данных после применения панелей в формат CODIS XML: выбираются вкладки с данными для экспорта, назначаются роли в рамках дела (жертва, персонал, подозреваемый, предполагаемый родитель и т.д.), заполняются данные лаборатории и экспортируются. Экспортированные данные могут быть внесены в совместимую с CODIS систему (например, SmallPond).
FragalyseQt 0.5 - экспорт данных после применения панелей в формат CODIS XML: выбираются вкладки с данными для экспорта, назначаются роли в рамках дела (жертва, персонал, подозреваемый, предполагаемый родитель и т.д.), заполняются данные лаборатории и экспортируются. Экспортированные данные могут быть внесены в совместимую с CODIS систему (например, SmallPond).
Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии0

Зелёные тесты ≠ хорошие тесты

Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 80%, 90%, а то и вовсе 100%. И вот тут начинается проблема: зелёные тесты ≠ хорошие тесты.

Проблема в метрике, которой мы все привыкли доверять. Code coverage считает строку протестированной, если она выполнилась во время теста. Всё. Не «поймает ли тест баг в этой строке», не «проверяет ли он правильность результата» — просто выполнилась. Можно написать тест без единого assert, и покрытие вырастет. 500 тестов, 90% coverage, а пользы ноль.

Мутационное тестирование — это совершенно другой путь. В простейшей реализации этот инструмент тупо берёт твой код и намеренно ломает его: меняет > на >=, + на ‑, True на False. Каждая такая поломка — мутант. Если после мутации все тесты по‑прежнему зелёные — значит они ничего не проверяют. Покрытие есть, защиты нет.

Почему это важно именно сейчас?

Потому что нейронка любит зелёненькое. Чем больше зелёных тестов — тем субъективно лучше. 100 тестов внушают больше доверия, чем 10, правда? А внутри там assert response.status_code == 200. assert result is not None. assert len(items) > 0. Тест проверяет, что функция вернула хоть что‑то — и радостно зеленеет. Поменяй логику условия, перепутай знак, сломай граничный случай — тест всё равно зелёный. Потому что он проверяет не правильность, а наличие.

Мутационное тестирование — единственный автоматический способ это поймать. Метрика называется mutation score: процент убитых мутантов. 60% — плохо. 90%+ — тесты реально что‑то защищают.

Кое‑какие инструменты для такого тестирования уже есть: mutmut и cosmic‑ray для Python, Stryker для JS/TS, PIT для Java. Медленно? Да, значительно медленнее обычного тест‑рана. Но запускать его не нужно на каждый коммит — достаточно на PR в критические модули.

Но есть нюансы. А где их нет, правда?

Первый: мутации рандомные. Замена > на >= — это не баг, который кто‑то реально допустит. Это синтетическая поломка. Половина мутантов генерирует код, который в реальности никогда не появится. Ты тратишь время на убийство мутантов, которые не имеют отношения к настоящим ошибкам. Это как тестировать замок, ковыряя его вилкой — формально проверка, по факту мимо.

Второй — ещё хуже. Чтобы убить мутанта, тест должен зафиксировать конкретное поведение. Каждую ветку, каждое значение, каждый edge case. Доведи mutation score до 100% — и ты прибил гвоздями каждую строчку кода. Буквально. Теперь попробуй отрефакторить. Переименовал внутренний метод — 40 тестов красные. Поменял порядок полей в ответе — ещё 20. Тесты превращаются из страховки в кандалы: код работает правильно, но тесты падают, потому что они проверяют не поведение, а реализацию.

Это реально ловушка. Слишком гонишься за mutation score — получаешь хрупкие тесты. Не гонишься — получаешь видимость тестирования.

Перемены — впереди!

И вот тут становится по‑настоящему интересно. Представь, что мутации генерирует не тупой набор правил «замени плюс на минус», а нейронка, которая понимает контекст. Которая знает, какие баги реально встречаются в таком коде. Которая мутирует не синтаксис, а логику: меняет порядок проверок, путает граничные условия, забывает обработать edge case — ровно так, как ошибается человек. Или другая нейронка.

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

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

Ждём, когда мутанты станут умнее.

Теги:
Всего голосов 5: ↑5 и ↓0+7
Комментарии3

Два факта об int в Python

Один забавный факт привел меня к открытию другого :)

Читал Fluent Python и наткнулся на пример кода, который меня заинтересовал (помимо миллиона других, книга – топ). В главе про конкурентность и работу GIL была константа NUMBERS с необычным значением:

NUMBERS = 5_000_111_000_222_021

Нижние подчеркивания

Если не встречали в работе или документации, то вряд ли знаете (как и я): в числах можно использовать _ для читаемости. Интерпретатор их игнорирует:

>>> x = 1_2
>>> y = 12
>>> x == y
True
>>> x is y
True

Особенно удобно в высокоразрядных числах. Согласитесь 5_000_111_000_222_021 куда проще читать, чем 5000111000222021

Кеш малых чисел

Примеры ниже разбирал на домашнем ноуте с Cpython 3.13.11 и 3.14.3.

Пока игрался, меня заинтересовал один прикол. Я попробовал тот же пример с большими числами:

>>> x = 100_500
>>> y = 100500
>>> x == y
True
>>> x is y
False # Но ведь в примере выше было True..

Почему переменные больше не ссылаются на один объект?

В Cpython есть кеш для маленьких чисел, чтобы частые значения переменных не занимали много памяти и код был отзывчивее.

Ответ на вопрос: «где граница, до которой числа закешированы?» я решил не гуглить, проверил небольшим скриптом:

>>> x = 0
>>> y = 0
>>> for n in range(1000):
...     print(f'If {x=} and {y=}, x is y: {x is y}')
...     x += 1
...     y += 1

# Пропустим часть строк
If x=254 and y=254, x is y: True
If x=255 and y=255, x is y: True
If x=256 and y=256, x is y: True
If x=257 and y=257, x is y: False # Вот и граница
If x=258 and y=258, x is y: False 
...

Сначала я сделал эмпирически вывод, что закеширован диапазон 0 – 256. Но после самопроверки с гуглом узнал, что также в амортизированный диапазон входят числа от -5 до -1. Итого : от -5 до 256 включительно.

UPD 15.03.2026. Добрый дядя в комментах принес ссылку на pr в Cpython 3.15, где кеш малых чисел увеличен до 1024 :). Ух, заживем..

Для присвоения переменным чисел вне диапазона, интерпретатор начнет выделять уже раздельные области памяти и is станет возвращать False.

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

Теги:
Всего голосов 11: ↑10 и ↓1+9
Комментарии15

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

Как проверить HTTP-запросы на Backend

Разрабатываете VK Mini Apps и хотите быть уверены, что HTTP-запросы на backend приходят именно из приложения VK, а не откуда угодно? Для этого нужна корректная проверка Init Data.

Наш backend-разработчик @dmvasiliev выложил Open Source-проект, который упрощает эту задачу. Это Python-пакет с готовыми алгоритмами проверки подлинности данных, передаваемых из VK Mini Apps. Он помогает быстро и безопасно настроить авторизацию и аутентификацию на backend-стороне приложения.

👉 Репозиторий
📘
Документация с примерами интеграции для Django и FastAPI.

Когда мы только начинали работать с VK Mini Apps, информации было немного: редкие кейсы, почти не у кого было спросить совета. За это время мы запустили несколько приложений, разобрались в нюансах платформы и накопили собственную экспертизу. Теперь делимся ею с сообществом через Open Source-проекты и вносим вклад в развитие технологии.

Репозиторий открыт — берите в работу, делитесь постом с коллегами. 

А если вам нужен VK, Telegram Mini App или спецпроект на другой платформе — команда Doubletapp поможет пройти путь от идеи до работающего продукта.
Примеры наших проектов — на сайте.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

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

P.S. Все также бесплатно и таким останется, пока у меня есть деньги на поддержку и развитие ресурса.

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

Команда разработчиков языка программирования Python визуализировала изменение кодовой базы интерпретатора CPython в привязке к основным событиям, произошедшим за 36 лет существования проекта. За последние 10 лет объём кода на языках Python и Си в CPython практически удвоился. Для подсчёта числа строк кода использовалась утилита cloc.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

44 собеса за месяца Жив ли рынок QA/AQA на самом деле?

Календарь AQA собесов за декабрь
Календарь AQA собесов за декабрь

Последний год в IT регулярно обсуждают одну и ту же тему — рынок стал сложнее.
Вакансий меньше, требования выросли, конкуренция усилилась.

Особенно часто это можно услышать от специалистов из QA/AQA:
Мол, тестирование переполнено, вакансий мало, а найти новую работу стало почти нереально.

Я давно консультирую ребят в сфере QA и автоматизации тестирования (AQA) и регулярно наблюдаю, как специалисты выходят на рынок. Поэтому иногда вижу довольно наглядные примеры того, как ситуация выглядит на практике.

Как раз недавно один из ребят показал в нашем чатике свой календарь собеседований за декабрь — этот календарь приложил выше.

И, честно говоря, даже меня это немного удивило. За месяц у него набралось 44 собеседования.

Причём:
Во-первых, всё это происходило параллельно с основной работой.
Человек не уходил в отпуск и не ставил поиск работы на полный день — все интервью проходили между рабочими задачами.

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

Тем не менее календарь получился очень плотным.

Иногда у него было по несколько интервью в день:
HR, технички, финалки, снова HR.

А если представить его лицо 11го декабря — то лучше не надо)

P.S. Выходил на рынок он как Fullstack QA/AQA, если что. В ручном тестировании естественно ситуация похуже. Но наверное основной моей задачей и являлось помочь ему с этим переходом (QA->AQA), т.к. именно тут наилучшая конверсия для QA.

И что по итогу? Оправдались ли такие усилия?

Думаю, всем это тоже будет интересно. Стоило ли оно вообще того.

Вы реально думаете, что человек, который проходил по 6 собесов в день, мог не добиться своего?)

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

В итоге этот кандидат получил 6 офферов.

Один из них оказался особенно сильным — около 490 000 рублей gross для позиции в автоматизации тестирования.

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

Да, он действительно стал сложнее.
Да, требования выросли.

Но при этом рынок далеко не мёртв. Он просто стал требовательнее к кандидатам.

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

А те, кто не пытается, чаще находят объяснение, почему сейчас «не время».

Поэтому, когда в очередной раз услышите, что рынок QA/AQA окончательно умер, просто вспомните календарь из 44 собеседований за один месяц.

Спасибо, что дочитали пост до конца! Надеюсь, смог зарядить вас мотивацией, это была моя основная цель 🙂

В комментариях готов подискутировать на эту и смежные темы! Ну а в своем блоге Telegram также пишу про тестирование и автоматизацию, иногда затрагивая и общие темы развития в сфере IT. Всегда рад новым читателям!)

Теги:
Всего голосов 5: ↑1 и ↓4-3
Комментарии35

Война с алгоритмами как обойти шизу HRов.

Привет, Хабр.

Меня зовут Дима. Я разработчик и последние пару лет занимаюсь карьерным консультированием. Через меня прошло множество кейсов и за это время я чётко увидел одну вещь: поиск работы стал слишком выматывающим.

Не потому что люди слабые, а потому что процесс стал сложным, долгим и алгоритмическим.

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

В какой-то момент я понял: советов уже недостаточно. Нужен инструмент, который сам будет применять эти советы.

Так я решил заняться своим проектом — ИИ-ассистентом для поиска работы.

С чего всё начиналось

Идея была простой:
Находим вакансии → анализируем → генерируем письмо → отправляем отклик.

Технически всё работало.
По факту — конверсия почти не изменилась. (Кто бы мог ожидать)

Быстро стало понятно, что делать быстрее — не значит лучше.

Шаблон (даже написанный нейросетью) рекрутеры считывают мгновенно.

Что пришлось переосмыслить

То, что мы быстро поняли: ассистент должен работать как человек, а не как скрипт.

Это значит:

  • учитывать контекст, а не просто ключевые слова;

  • вытаскивать релевантные кейсы, а не перечислять стек;

  • писать живым языком, без «я обладаю навыками» и списков из пяти пунктов;

  • не создавать подозрительных паттернов поведения.

Как мы это переосмыслили

Засев на несколько недель мы перепилили всю инфраструктуру платформы и создали нечто новое.

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

1. Поиск релевантных вакансий

Ассистент анализирует требования и ваш опыт на уровне задач. Если компании важно «ускорить релизы», система поднимет ваш кейс про оптимизацию CI/CD.

2. Написание персонализированных сопроводительных писем

Это была самая сложная часть.

Базовая LLM пишет слишком «правильно»: канцеляризмы, одинаковая структура, списки.
Мы долго работали над стилистикой и вариативностью, чтобы письмо выглядело так, будто кандидат реально вчитался в вакансию.

3. Отчетность

У нас нет режима, который всё делает за спиной.

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

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

4. Работает аккуратно

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

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

Зачем это всё

Как карьерный консультант я вижу главное: люди тратят слишком много энергии на рутину.

Этот проект (он, кстати, называется OfferMate) не волшебная кнопка «оффер».
Это инструмент, который:

  • снимает техническую нагрузку,

  • ускоряет касание с рынком,

  • делает процесс управляемым.

Если интересен такой подход, то вот ссылки:

Блог проекта — здесь можно принять участие в тестировании и уточнить важные для себя моменты
Лэндинг проекта — тут базовая информация, можно почитать про функции и т.д.

Новую работу гарантировать не могу, но рутину из поиска точно уберет)

Буду рад критике. На Хабре без неё нельзя 🙂

Теги:
Всего голосов 7: ↑5 и ↓2+5
Комментарии4

Русский FAANG: карьерный буст или выгорание за 400к? Что выбрать QA/AQA

В русском IT регулярно всплывает формулировка «русский FAANG» и многие хотят туда попасть. В этом посте на основе своего опыта разберу, стоит ли оно того.

Начнем с того, что каждый под словосочетанием русский FAANG подразумевает разное. Есть как минимум:
1. ВАСЯ: ВК, Альфа, Сбер, Яндекс
2. МЯСОВАТА: Mail (VK), Яндекс, Сбер, Озон, Валдберрис, Авито, Теле2, Альфа
3. Мой любимый - ОБОСРАЛСЯ: Озон, Билайн, ОККО, Сбер, Рамблер, Атол, ЛамодаТех, Совкомбанк, Яндекс

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

Так стоит ли QA/AQA и другим стремится в ВАСЯ или можно ограничится ОБОСРАЛСЯ или даже обычными мелкими компаниями / стартапами?

Чего стоит попасть туда (насколько это сложно)

У многих есть ощущение, что российский бигтех - это нечто недосягаемое. Почти как западный FAANG.

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

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

Плюс последние годы усилили тренд на оптимизацию затрат.
Ручное тестирование постепенно сокращается, а автоматизация растет. Считается, что один AQA может закрывать задачи нескольких QA.

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

Где лучше и стоит ли оно того

Я поработал много где как AQA - Ozon, WB, VK, несколько российских и западных стартапов, бигтех US.
И могу с уверенностью сказать, что тут не угадаешь, везде всё по разному. Например, в одном из криптостартапов я встретил лучшие процессы, что видел в жизни, а в двух из бигтехов - миллион токсиков, невероятную бюрократию и в целом не очень классные процессы.

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

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

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

Те же самые "интересные задачи" есть везде, а в стартапах они часто даже круче и челленджовее.

Что в сухом остатке

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

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

Теги:
Всего голосов 8: ↑5 и ↓3+3
Комментарии0
Главная
Главная

Собрал и перевел на русский большой гайд из разных источников по ИИ.
P.S. это не реклама платного ресурса, будьте сдержаны.

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

https://ai.arckep.ru

ТРЕК 1 / NO-CODE
1.1 Введение в AI-агентов
1.2 Промпт-инжиниринг
1.3 Платформы и модели
1.4 Практика no-code
1.5 Безопасность и этика AI
1.6 Финальный проект
ТРЕК 2 / РАЗРАБОТЧИКИ
2.1 Введение в AI-кодинг
2.2 Claude Code
2.3 Gemini CLI
2.4 Codex CLI
2.5 Cursor и IDE-агенты
2.6 AGENTS.md и документация
2.7 MCP
2.8 Российские модели
2.9 Воркфлоу и OpenClaw
2.10 Финальный проект
ТРЕК 3 / OPENCLAW
3.1 Знакомство с OpenClaw
3.2 Подключение каналов
3.3 Настройка и автоматизация
3.4 Мультиагентная архитектура

Теги:
Всего голосов 8: ↑8 и ↓0+10
Комментарии15