Как я написал радар межбиржевых спредов на Python и понял, почему 90% публичных ботов считают прибыль неправильно

Как я написал радар межбиржевых спредов на Python и понял, почему 90% публичных ботов считают прибыль неправильно

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

Как я написал радар межбиржевых спредов на Python и понял, почему 90% публичных ботов считают прибыль неправильно

Привет! Меня зовут Егор Лукьянов, я старший аналитик данных в Ozon Tech. В своей работе я часто сталкиваюсь с проблемой масштабируемости в pandas. Код, который быстро работает на гигабайте данных, начинает невыносимо тормозить на десяти. Уверен, эта боль знакома многим.
Сейчас есть быстрые альтернативы, например, Polars. Я сам пробовал переводить на него свои проекты. Скорость действительно впечатляет, но как в анекдоте есть нюанс: приходится переписывать чуть ли не весь код и привыкать к новому синтаксису. А это большая работа, на которую не всегда есть время.
И вот здесь я наткнулся на FireDucks — библиотеку, которая обещает решить эту проблему, просто заменив одну строку импорта. Звучало слишком хорошо, чтобы быть правдой. После опыта с Polars я был уверен, что где-то должен быть подвох.
Я решил проверить FireDucks на нескольких типичных задачах. В этой статье я хочу без лишнего хайпа поделиться тем, что у меня получилось. Мы посмотрим на реальные примеры кода, сравним скорость и разберёмся, где эта библиотека действительно хороша, а где могут быть проблемы.

Реализуем сервис семантического поиска на базе PostgreSQL с расширением PGVector. В статье: настройка БД через Docker, миграции Alembic, асинхронный слой на SQLAlchemy и API на FastAPI. Иллюстрация на обложке - нейрослоп для привлечения внимания

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

Привет! Меня зовут Николай Олигеров, я работаю продуктовым аналитиком в Яндекс Путешествиях. В этой статье я расскажу, как мы применяли PSM (Propensity Score Matching) — статистический метод, который позволяет корректно сравнивать группы, уменьшая систематические различия между ними. Подробно разберу, как выровнять группы теста и контроля с помощью PSM, расскажу о типичных ошибках (например, утечке признаков), дам практические рекомендации по сбору и выбору фич для мэтчинга, а также покажу, как валидировать полученные результаты и оценить их достоверность.

Как запустить AI code review по git diff на своей машине через Ollama - без облака и API-ключей? Установка, конфиг и пример отчёта.
Замысел в том, чтобы написать цикл о 10 программистах, чьи имена не особо примелькались, но чьи заслуги невозможно переоценить. Начну я этот цикл с Эндрю Кучлинга (A.M. Kuchling). Я всегда знал его как автора официального туториала по регуляркам в питоне, пожалуй, лучшего по теме. Но масштаб этого человека куда больше.

ASR-системы в проде - это тяжёлые, специализированные решения под конкретные сценарии. Но что делать, если нужен универсальный инструмент, который умеет распознать длинное аудио, диаризовать спикеров, обработать пачку файлов и при этом не требует целого GPU кластера?
В этой серии статей я разбираю, как собрать «швейцарский ножик» для распознавания речи на базе Whisper: выбрать модель, победить галлюцинации, стабилизировать обработку длинных аудио и выжать максимум из обычной видеокарты.
Первая часть - про выбор ASR, оптимизацию инференса и практические грабли, с которыми сталкиваешься, когда пытаешься превратить open-source модель в рабочий инструмент.

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

Всем привет!
На связи София из команды применения больших языковых моделей ecom.tech. Сегодня хочу поделиться одной малоизвестной библиотекой, которую мы волей судьбы откопали на просторах github, попробовали использовать для поиска по нашей кодовой базе, и, о чудо! Это ощутимо помогло нам. Казалось бы, такой маленький шаг для человечества, но такой полезный для нашего проекта.

Когда я только начинал свой путь в автоматизации, мне отчаянно не хватало толкового и структурированного материала по паттернам проектирования именно для автотестов. Хороших статей про паттерны в целом — вагон, а вот с привязкой к тестированию — днём с огнём не сыщешь.
Паттерны — это та вещь, которая моментально выдает уровень культуры кода и понимание инженерных практик. Неудивительно, что на собеседованиях на позицию Automation QA любят покопаться в этой теме.
В этой статье я решил закрыть этот пробел. Вы найдете не только продуманную классификацию основных паттернов автоматизации, но и самый подробный, на мой взгляд, разбор каждого из них с примерами. А в конце поговорим про антипаттерны.
Добро пожаловать в обсуждение! Буду рад конструктивной критике и дополнениям.

История о том, как я создал свою соцсеть. И у меня даже получилось что-то. Видеохостинг, мессенджер, короткие ролики, стена и многое другое

Сидячая работа — профессиональное проклятие разработчиков. Проводя по 10 часов за кодом, мы часто игнорируем «звоночки» от поясницы, пока они не превращаются в полноценные прострелы. После очередного визита к врачу я задался вопросом: а можно ли использовать современные LLM, чтобы упростить жизнь пациенту и наглядно отслеживать динамику лечения?
Так появился Spine Advisor — десктопное приложение на Python, которое использует мультимодальную модель Gemini 3 Flash для «чтения» МРТ и ведения цифрового дневника спины.
Привет! Меня зовут Фаина, я системный аналитик с опытом более 5 лет. В последнее время все чаще стала задумываться как системному аналитику в текущих реалиях применять в работе ИИ. Так началось мое погружение в увлекательный мир LangChain, ИИ, RAG и векторные БД.
Для начального исследования я решила попробовать что-то достаточно простое и базовое. Так в мою голову пришла идея создать ТГ бота, который напоминает о запланированных делах

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

Большинство AI-инструментов — либо облако, либо код под каждую задачу. Coreness Flow строится вокруг событий: пришло сообщение, сработал cron, прилетел webhook — агент находит сценарий по триггеру и выполняет цепочку шагов.
Плагины декларируют вклад в интерфейс через config.json — фронт собирает вкладки и настройки по этим данным, без правки React-кода. Новый плагин — новая вкладка, без хирургии во фронтенде. RAG полностью локальный: BGE-M3 ONNX INT8 + Qdrant embedded в процессе приложения, гибридный поиск офлайн. Разбор архитектуры — API Bus, lifecycle, система сценариев с триггерами и переходами.

Даже беглый анализ некоторых текстов группы "Кино" наталкивает на мысль о довольно сильных символических значениях их стихотворных строк. Мне стало интересно провести сравнительный анализ текста песни Виктора Цоя и драмы Уильяма Шекспира "Гамлет" и найти пересечения, аллюзии и реминисценции в творчестве двух авторов помощью инструментов NLP на Python.

def get_features_all(y, sr):
"""
Получаем различные параметры аудио которые в сумме дадут уникальный набор признаков
"""
# Частота цветности
chst = librosa.feature.chroma_stft(y=y, sr=sr)
# Среднеквадратичные колебания (энергия сигнала)
rmse = librosa.feature.rms(y=y)
# Пересечения нуля (частота смены знака сигнала)
zcr = librosa.feature.zero_crossing_rate(y)
# Центр масс звука (спектральный центр)
spe_c = librosa.feature.spectral_centroid(y=y, sr=sr)
# Ширина полосы частот
spe_b = librosa.feature.spectral_bandwidth(y=y, sr=sr)
# Спектральный спад частоты
rol = librosa.feature.spectral_rolloff(y=y, sr=sr)
# Значимые для обработки частоты (MFCC)
mfcc = librosa.feature.mfcc(y=y, sr=SR, n_mfcc=50,
n_mels=50, hop_length=1024)
return chst, rmse, zcr, spe_c, spe_b, rol, mfcc

У нас в «Лаборатории Касперского» есть команда анализа защищенности, занимающаяся поиском уязвимостей в самых разнообразных системах. В ней работают эксперты, способные исследовать практически любое устройство (и публикующие технические заметки о своих находках). Но в жизни практически каждого исследователя безопасности прошивок однажды наступает момент, когда он или она сталкивается с новым или не особо известным микроконтроллером или свежей процессорной архитектурой с кастомными расширениями. В последнее время такие моменты наступают все чаще — за прошедшие несколько лет рынок наполнился огромным количеством новых чипов из Поднебесной, в частности, на базе RISC-V, со своими собственными расширениями и реализациями ядер. И вот не так давно на анализ нашим исследователям попало устройство c таким чипом на базе RISC-V, c базовым набором инструкций RV32I и расширением P (причем еще и не последней версии), добавляющим короткие SIMD-операции (Packed-SIMD Instructions).
То, что наши эксперты видели его впервые — абсолютно нормально. Но, по всей видимости, его впервые видел и IDA Pro — инструмент, которым пользуются наши исследователи. Поэтому им пришлось не только изучить ранний черновик расширения P (оно же Packed-SIMD Extension), но также реализовать поддержку IDA Pro ряда инструкций из него и произвести лифтинг, то есть трансляцию инструкций в промежуточное представление или язык, понятные декомпилятору. Именно этим опытом они и решили поделиться в данной статье.
Но прежде чем переходить к описанию решения этих задач, стоит понять, с чем мы имеем дело, поэтому начать следует со знакомства с документацией по архитектуре RISC-V.

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