Обновить

Системный и бизнес-анализ

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

22 преля состоялся TechCommPod Online Meetup, а сегодня уже можно посмотреть его в записи!

  • АРИНА БАЛЕРИНА рассказала, кто такие техписатели. Как понять, что это ваше. Как стать одним из них.

  • ЕКАТЕРИНА ПАВЛОВА провела мастер-класс по созданию сайта-визитки в Gramax.

  • ДМИТРИЙ РАЗВОЗЖАЕВ показал свой зоопарк из AI-агентов.

  • КОНСТАНТИН МАКУШЕВ порассуждал про паттерны и антипаттерны в документации.

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

Если пропустили эфир —  не страшно, мы все записали и уже залили на две площадки:

Если вы были в эфире (или после просмотра записи) — пожалуйста, заполните анкету обратной связи. Это позволит подготовить для вас другие интересные и полезные мероприятия: https://forms.gle/juvvvxPQEoVMZuz37

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

ИИ для бизнес-аналитика

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

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

Мы поговорили с Полиной, бизнес-аналитиком в команде Скорозвон, и задали ей несколько вопросов: где ИИ полезен на практике, какие результаты удалось получить и какие инструменты стоит попробовать.

1️⃣ Где ИИ помогает в работе аналитика?

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

Это как раз те вещи, которые можно частично или полностью поручить ИИ: он может собирать и структурировать данные, помогать с гипотезами, создавать черновики документов.

При этом ИИ — это не просто «нажал на кнопку и получил результат». Он ускоряет работу, но все равно результат нужно проверять и дорабатывать.

2️⃣ Где ИИ уже приносил заметный результат в вашей команде?

Один из ярких кейсов — анализ диалогов в колл-центре. Робот успешно находил «теплых» лидов, но конверсия в покупку оставалась низкой. 

Мы подключили анализ диалогов с помощью LLM и выяснили, что корректно работали только около 7% операторов.

Ошибки у них были довольно базовые, но их сложно заметить без детальной аналитики:

  • не знали о звонках робота

  • сбрасывали звонки клиентов или вызывали негатив

  • повторно проводили идентификацию

  • работали с плохим оборудованием

LLM помог быстро проанализировать большой объем диалогов и собрать это в понятную аналитику.

3️⃣ Что изменилось после этого?

После таких изменений корректность работы операторов выросла до 90%. Плюс мы закрыли скрытое ожидание клиента — он хотел качественную аналитику, а не только цифры.

А еще:

  • итоговая конверсия увеличилась примерно в 1,5 раза

  • выручка по проекту выросла в 2 раза

С точки зрения личной эффективности я теперь экономлю до 20 часов в месяц на прослушке диалогов и могу анализировать до 100 диалогов в час. 

То, что раньше требовало большой команды или долгой ручной работы, сейчас можно сделать гораздо быстрее.

4️⃣ Какие задачи еще можно отдать ИИ в работе аналитика?

Помимо анализа данных:

  • подготовка презентаций 

  • написание текстов

  • проведение исследований

  • сбор и структурирование данных

  • оформление документации

Это не заменяет аналитика, но сильно упрощает старт и ускоряет процесс.

5️⃣ Какие инструменты тебе показались полезными?

Из того, что я использовала в работе:

  1. GigaChat — хорошо справляется с исследованиями на российском рынке

  2. SkyWork.ai и Gamma — помогают быстро собрать презентацию и структуру доклада

  3. НейроЭксперт — удобно работать с файлами и базой знаний

  4. Ассистенты для генерации промптов от Naumen — чтобы не просто перефразировать промпт, а уточнить задачу через вопросы и сделать его точнее

  5. Кастомные агенты с использование Claude Code — чтобы автоматизировать процесс и сократить ручную работу

6️⃣ Есть ли риски или ограничения, о которых важно помнить?

Да, и об этом часто забывают. Перед использованием данных важно:

  • уточнять у клиента, что является конфиденциальной информацией

  • обезличивать данные

  • проверять результаты

ИИ может сильно ускорить работу, но ответственность за итог все равно остается на аналитике.

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

5 человек, 1 300 дашбордов, 2 200 пользователей в месяц. Как не сойти с ума

В Уралсибе self-service BI вышел на масштаб, который сложно представить: 12 000 датасетов, 200+ разработчиков в разных бизнес-блоках, 1 000 потоков данных обновляются каждый день. И всё это поддерживает команда из пяти человек.


При таком масштабе неизбежно появляются дубли, забытые дашборды, сломанные компоненты, разработчики, которые не знают о существовании друг друга, и пользователи, которые всё ещё спрашивают «а зачем BI, если есть Excel?».

Как с этим справляться? Семён Юников расскажет про систему, которую они выстроили: автоматические рассылки разработчикам с рекомендациями по их же объектам, кастомный каталог дашбордов с ИИ-поиском, геймифицированный марафон на 80 разработчиков, после которого количество сломанных компонентов сократилось вдвое. И да, заставки на корпоративных ноутбуках с надписью «Ты ещё в Excel? Переходи в FineBI» тоже часть стратегии.

📅 22 апреля | 15:00 МСК

Бесплатно, онлайн ~3 часа

→ Регистрация

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

Когда у тебя 50 отчётов в FineReport, 100+ дашбордов в FineBI, и никто не знает, откуда берутся данные 

Знакомая история: дашборды живут своей жизнью, новый сотрудник открывает отчёт и не понимает, что значит «ТО 5 руб.», а когда что-то ломается, полдня уходит на то, чтобы пройти по цепочке ETL и найти, где именно.

В Галамарте решили это системно: подключили дата-каталог DataHub к продуктам FanRuan. Как именно это сделали, какие стены пришлось пробить и чего не нашлось ни в одной документации, расскажет Дмитрий Конюхов на FineDay Online.

Что получили на выходе:

— бизнес-глоссарий, где каждый термин привязан к формуле, источнику и конкретным дашбордам

— lineage от витрины до сырых данных — в одном окне, за пределами FanRuan

— возможность за секунды найти, в каких из 100+ дашбордов используется нужнаяметрика

— базу для self-service: аналитики переиспользуют существующие датасеты вместо создания новых

📅 22 апреля | 15:00 МСК | FineDay Online 2026

Бесплатно, онлайн, ~3 часа

→ Регистрация

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

Встраивание вычислений в PostgreSQL: PL*, extensions, а теперь и WASM

В рамках выступления на PG BootCamp Russia 2026 Дмитрий Дорофеев, главный конструктор Luxms, рассказал о том, как сегодня развивается встраивание вычислений в PostgreSQL: от классических процедурных языков (PL/pgSQL, PL/Python и других) до новых возможностей с использованием WebAssembly (WASM).

В PostgreSQL исторически поддерживается несколько десятков языков программирования. Если этого недостаточно, можно воспользоваться готовым расширением из огромной экосистемы либо написать своё. Прогресс не стоит на месте, и теперь для выполнения стороннего кода в PostgreSQL можно использовать WASM. 

На примере Luxms BI я расскажу, как мы автоматически генерируем Swagger-документацию прямо внутри PostgreSQL с помощью open-source технологий и WASM.

Посмотреть видео выступления можно на нашем сайте.

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

Вебинар «BI + ETL + КХД за 1,5 млн: как Modus закрывает весь стек корпоративной аналитики»

21 апреля в 12 по МСК приглашаем на вебинар, на котором эксперты ИТ-интегратора «Белый код» расскажут, как малому и среднему бизнесу внедрить BI-систему за 1,5 миллиона рублей.

Одна из задач, с которой к интегратору приходит малый и средний бизнес, — внедрение BI в рамках ограниченного бюджета. При этом есть жесткие требования, например, единая экосистема BI + ETL, без «зоопарка» инструментов, а также нативная работа с 1С как основным источником данных. 

На вебинаре специалисты поделятся практикой внедрения в сегменте МСБ, а также ответят на вопросы. 

Вы узнаете:

  • Почему BI сам по себе не решает проблему разночтений в данных

  • Какие организационные изменения нужны, чтобы аналитика начала работать

  • Modus ETL: как устроена загрузка и обработка данных

  • Modus BI: аналитический портал без лишней сложности

  • Структура проекта за 1,5 млн рублей: стоимость лицензий, этапы проекта и результат

Спикеры вебинара

  • Андрей Рыжик, product owner BI-направления компании «Белый код»

  • Наталья Лобанова, коммерческий директор компании «Белый код»

📌Дата и время: 21 апреля 12:00 МСК (онлайн)

Участие бесплатное, требуется предварительная регистрация.

Принять участие

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

Почему “лучший курс” часто оказывается самой дорогой ошибкой

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

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

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

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

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

Иногда «лучший курс» ломается на комиссии, которая появляется позже. Иногда на спреде между заявленным и финальным расчётом. Иногда на том, что деньги приходят дольше, чем ожидалось, и пользователь теряет не на цифре, а на времени.

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

С точки зрения интерфейса всё выглядит честно: цифра показана. Но с точки зрения пользователя это часто превращается в когнитивную ловушку. Он уже увидел «выгоднее» и перестал смотреть на остальное.

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

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

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

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

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

Данные есть – чуда нет...

Приходите на онлайн-конференцию GlowByte и FanRuan разбираться, куда делось чудо

Дашборды построены, хранилища заполнены, лицензии куплены, а решения по-прежнему принимаются «на ощущениях». Это не ваша уникальная проблема – это системный разрыв между потенциалом BI и его реальным применением.

22 апреля в 15:00 (МСК) приглашаем вас на Fine Day Online 2026 – ежегодную онлайн-конференцию от GlowByte и FanRuan, где мы разберем, как этот разрыв закрыть.

Что в программе:

●     От данных к ИИ-инсайтам – как превращать сырые данные в умные решения, а не просто красивые графики (Вилл Ченг, ведущий эксперт по отраслевым решениям, руководитель направлений пресейл и внедрение CIS, FanRuan);

●     Интеграция FanRuan + DataHub – реальный опыт построения связной экосистемы данных (Дмитрий Конюхов, ведущий инженер отдела управления данными, “Галамарт”);

●     1 500 дашбордов для 2 500 пользователей – как сделать BI удобным и востребованным в масштабе (Семён Юников, главный эксперт Дирекции BI, Уралсиб);

●     Shadow DWH – тёмная сторона self-service аналитики и как с ней справляться (Пётр Гордиенко, Lead BI, ОТП);

●     Миграция FineBI с 6.0 на 7.0 – практический опыт и подводные камни (Евгений Иванов, DevOps BI-платформы, ОТП).

Для кого:

Руководители и специалисты в области BI, Data & Analytics, CDO, продуктовые и бизнес-аналитики – все, кто хочет, чтобы данные наконец работали на результат.

Формат:

Онлайн, бесплатно, ~3 часа концентрированной пользы. Нужна только регистрация

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

Почему KYC воспринимается как препятствие, а не как защита

KYC это одна из самых раздражающих частей любого финтех- или криптосервиса.

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

С точки зрения пользователя это выглядит просто: «Я хочу сделать операцию, почему вы тормозите процесс?»

С точки зрения сервиса всё выглядит иначе. Если не проверять пользователей, не отслеживать аномальные операции и не фильтровать очевидный риск, сервис очень быстро начинает получать не рост, а проблемы: блокировки, претензии, давление со стороны платёжной инфраструктуры, рост мошеннических кейсов и постоянные ручные разборы.

И в какой-то момент вопрос уже не в удобстве. Вопрос в выживании.

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

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

Отсюда и главный конфликт: сервис считает, что защищает процесс, а пользователь считает, что его просто остановили на финише.

На практике раздражает не только сам факт проверки, а четыре вещи.

Первая – внезапность. Если KYC появляется слишком поздно, это почти всегда вызывает негатив.

Вторая – неопределённость. Пользователь не понимает, зачем это нужно именно сейчас, сколько это займёт времени и что будет дальше.

Третья – ощущение недоверия. Особенно если интерфейс подаёт проверку сухо, без нормального объяснения.

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

Именно поэтому один и тот же KYC может восприниматься по-разному в разных сервисах. Где-то пользователь проходит его спокойно, а где-то уходит с раздражением ещё до завершения.

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

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

Поэтому KYC сегодня – это уже не только юридическая или антифрод-задача. Это ещё и продуктовая задача. Сервису недостаточно просто «включить проверку». Ему нужно встроить её так, чтобы она не ломала доверие быстрее, чем защищала бы бизнес.

На практике пользователей раздражает не сам факт проверки, а то, как и в какой момент она появляется. Поэтому KYC давно перестал быть только задачей безопасности: теперь это ещё и вопрос интерфейса, коммуникации и доверия.

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

7 вещей, которые нужно проверить перед любым крипто-переводом

Криптопереводы давно стали обычной частью цифровых финансов. Но, в отличие от банковских приложений, здесь одна ошибка может стоить не комиссии, а всей суммы. Проблема в том, что деньги часто теряются не из-за взломов, не из-за блокчейна и не из-за “скама”, а из-за вполне бытовых вещей: не ту сеть выбрали, не заметили важное поле, поспешили, не сверили адрес. Вот что действительно стоит проверить перед отправкой.

Первое — сеть. Один и тот же актив может существовать в нескольких сетях. Например, USDT можно отправить через ERC-20, TRC-20, BEP-20 и другие варианты. На экране это выглядит как тот же токен, но по факту это разные маршруты. Ошибка здесь — одна из самых дорогих.

Второе — адрес. Недостаточно просто скопировать его и вставить. Стоит хотя бы сверить первые и последние символы. Ошибки в буфере, невнимательность или банальная спешка — классика.

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

Четвёртое — комиссия и итоговая сумма. Особенно если перевод идёт “впритык”. Иногда пользователь уверен, что отправляет нужную сумму, а после комиссии оказывается ниже минимального порога.

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

Шестое — memo, tag или дополнительный идентификатор, если он нужен. Для некоторых активов одного адреса недостаточно. Если забыть это поле, перевод может пройти, но деньги не будут привязаны к аккаунту без ручной поддержки.

Седьмое — тестовый перевод. Самый скучный совет, но самый дешёвый способ не потерять крупную сумму. Если сервис новый, сеть новая или сумма чувствительная — сначала лучше отправить небольшую часть.

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

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

Очередные HR-*******чебурашки из NEWHR провели якобы «исследование» рынка аналитиков в России

В исследовании заявлены даже:
— финансовые аналитики
— маркетинговые аналитики

Но никаких деталей по финансовым аналитикам вы в исследовании найдёте.

Также непонятно, почему в «исследование» не попали:
— антифрод-аналитики
— SOC-аналитики
— фармтех-аналитики
— аналитики-химики
— аналитики логистики и т.д. — ну вы поняли.

По тематике бизнес- и системного анализа всё как мы любим:
— аналитики бизнес-процессов не отделены от тех, кто делает требования
— разница между бизнес-аналитиками и BI-аналитиками не объяснена (а её часто нет)
— в зарплатах СА есть грейд Principal, но нет ведущих, а только тимлиды — это никак не объяснено
— в зарплатах БА 0 данных по Principal (лидов тоже нет)
— это никак не объяснено — в топе блогов, которые читают БА-СА — 20 экспертов по ДА, ну-ну

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

— Штурман, приборы!
— Сто пятьдесят!
— Что сто пятьдесят?
— А что приборы?

С чего эти люди на скриншотах решили, что они могут что-то понимать в других профессиях — непонятно
С чего эти люди на скриншотах решили, что они могут что-то понимать в других профессиях — непонятно

Найти профильных лидов по БА-СА для консультаций не составляет никакого труда в наше время.

https://newhr.org/data/research-analysts-2025

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

Функции сортировки

Функция SORT (СОРТ) позволяет упорядочить исходную таблицу и вставить результат в другое место. По умолчанию таблица сортируется по первому столбцу в порядке возрастания:

  • Sheets: =SORT(A:C)

  • Excel: =СОРТ(A:C)

Для сортировки по другому столбцу можно передать его номер и направление сортировки: по возрастанию или по убыванию. В Google Sheets это TRUE и FALSE, в Excel — 1 и -1. Следующая формула сортирует таблицу по второму столбцу в порядке убывания:

  • Sheets: =SORT(A:C;2;FALSE)

  • Excel: =СОРТ(A:C;2;-1)

Недостаток такого подхода: при добавлении/удалении столбцов формула может сломаться, придётся вручную обновлять номер столбца. Поэтому гораздо удобнее передавать не номер, а сам столбец для сортировки. В Google Sheets для этого используется та же функция SORT, в Excel — отдельная функция СОРТПО:

  • Sheets: =SORT(A:C;B:B;FALSE)

  • Excel: =СОРТПО(A:C;B:B;-1)

Можно задавать несколько столбцов сортировки. Следующая формула сортирует таблицу по второму столбцу в порядке убывания, одинаковые значения сортируются по третьему столбцу в порядке возрастания:

  • Sheets: =SORT(A:C;B:B;FALSE;C:C;TRUE)

  • Excel: =СОРТПО(A:C;B:B;-1;C:C;1)

Наконец, лайфхак, про который не рассказывают в документации. Если нужно упорядочить данные по разнице столбцов B и C (пример: доходы минус расходы или цена минус себестоимость), то можно использовать формулу массива. В Google Sheets понадобится ARRAYFORMULA или MAP, в Excel всё работает и без них:

  • Sheets: =SORT(A:C;ARRAYFORMULA(B:B-C:C);TRUE)

  • Excel: =СОРТПО(A:C;B:B-C:C;1)

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

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

Ссылка на 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

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

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

Ссылка на 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

Конец микросервисного угара: как Amazon, Uber и Netflix внедряли монолиты

Весной 2023 года Prime Video (Amazon) выкатил кейс, который для многих стал страшным сном: они слили красивую микросервисную оркестрацию и снизили стоимость инфраструктуры более чем на 90%.

Что они сделали? Перестали гонять данные через S3 между десятком серверлесс-функций ради банальной обработки видео. Они собрали те же самые компоненты (медиаконвертер, детекторы) в один контейнер. Вызов функции в памяти оказался быстрее и на порядок дешевле, чем "облачная магия".

Шок-контент? Только для тех, кто перечитал умных книг. Остальные просто кивнули.

Скрытый налог, о котором не пишут в книжках

Мы все прочитали «Чистую архитектуру» и умеем рисовать квадратики. Мы научились резать монолиты вдоль и поперек. Но в лучших практиках почему-то обходят главный вопрос: во что это реально обходится бизнесу?

Распределенные системы — это не бесплатный апгрейд. Это класс расходов, которого физически нет в монолите.

Вы платите за:

  1. Пересылку данных по сети вместо вызова method() в памяти.

  2. Отладку ада, когда для исследования бага нужно поднять логи 7 разных сервисов.

  3. Синхронизацию команд, когда чтобы решить ночной критический баг на проде вам нужно разбудить 5 тимлидов соседних команд.

В итоге мы получаем внешне технически совершенную систему, которую никто не может окупить. Бывает, что переход в микросервисы — это не инженерное решение, а следование вере.

Опыт Uber

У тебя 5 сервисов — ты держишь их в голове. У тебя 500 сервисов — ты не инженер, ты -- смотритель в зоопарке.

В 2016 году в компании Uber поймать баг означало пройти по 50 сервисам из 12 разных команд. Инженеры тратили больше времени на синхронизацию в слаке, чем на написание кода.

Решение Uber (DOMA) для многих стало интересным: они не стали переписывать код в монолит. Они сгруппировали этот зоопарк по реальным доменам и прикрыли их общими шлюзами.

Монолит 2.0: как было в Netflix

В 2012-м Netflix тушил каскадные отказы через Hystrix. Но для длинных бизнес-процессов (прием контента, кодирование, раскатка по CDN) это было как пластырь на переломе. Инженеры собирали логи руками.

В 2016-м они выкатили решение Conductor — оркестратор. По сути, это монолитный движок с UI для визуализации потоков своих микросервисов. В Netflix не побороли сложность, а переупаковали её. Теперь им нужна отдельная команда, чтобы поддерживать монолит который оркестрирует микросервисы.

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

  • Может ли одна команда выкатить фичу без согласования с пятью другими? Если для баг-фикса нужна координация 10+ команд — границы проведены неверно. Вы строите самый худший в мире архитектурный паттерн: распределенный монолит. Вы получите все минусы микросервисов и все минусы монолита одновременно.

  • Какая доля бюджета уходит на бизнес-логику, а какая — на то, чтобы сервисы могли просто "договориться"? Готовы ли вы содержать сложный слой оркестрации (как Prime Video) только ради того, чтобы система технически работала?

  • Есть ли у вас цифры, по которым вы поймете, что архитектура перестала окупаться? Prime Video начали с серверлесса и слепили всё в один процесс под реальной нагрузкой.

Выводов не будет, вы сделаете их сами.
Послушать расширенную версию статьи как сказку на ночь без донатов и рекламы можно на Яндекс.Музыке, Звуке и Apple Podcasts.

tg https://t.me/i_am_analyst

Теги:
Всего голосов 24: ↑23 и ↓1+26
Комментарии17

Сравнение локальных embedding-моделей

Провел тесты, чтобы узнать, что лучше всего использовать в контексте PKM.

Кратко:

⦿ Топ модель

     ⦾ snowflake-arctic-embed2

⦿ Баланс

     ⦾ embeddinggemma

⦿ Бюджет

     ⦾ multilingual-e5-small

     ⦾ база для гибридного поиска

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

Plugin: Obsidian Hybrid Search

В дополнение к гибридному поиску я сделал плагин для Obsidian. Он закрывает сценарии встроенного поиска, быстрого переключателя, OmniSearch, Recent Files, Similar Notes (или любого другого плагина, который ищет по эмбеддингам).

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

Интересная библиотека символьной регрессии PhySO. Оптимизатор берет на вход набор данных из многомерных аргументов X и одномерных значений функции Y в предположении, что это некие физические измерения. Пользователь добавляет информацию о единицах измерения компонент аргумента и целевого значения функции в виде наборов степеней [L, T, M] для каждой. Например, [ 1, -2, 0 ] соответствует ускорению, м/с^2. Также можно добавить свободных констант с указанием их физических размерностей в том же виде.

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

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

Пример в доках - здесь.

Это просто красиво. Разработчики хвалятся наилучшими показателями в бенчмарке подобных библиотек - особенно на высоких уровнях специально добавленного шума, до 10% от значений. Тренировали модель на большом количестве физических функций с экспериментальными данными, в том числе и на т.н. коллекции Фейнмана.

Следующий шаг в будущем для таких инструментов, наверное, будет добавление многомерности и в функцию. То есть сейчас R_n -> R_1, а будет еще R_n  ->  R_m

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

Выбор BI — стратегическое решение, которое определяет развитие ИТ-архитектуры, команды и бюджета. Как учесть стоимость лицензий, инфраструктуру, зрелость команды и перспективы? На бесплатном вебинаре «Чек-лист выбора BI-системы: Как не ошибиться в 2026 году» дадим чек-лист для тестирования любой BI-платформы.

Программа:

  • Почему старые подходы к выбору больше не работают. Основные ловушки при выборе.

  • Обзор актуального ландшафта BI-инструментов. Западные вендоры, российские платформы, Open Source, облачные и on-premise решения.

  • Работа с чек-листом выбора BI: экономика, инфраструктура, требования к команде, функциональность, безопасность и compliance, риски.

Спикер ответит на ваши вопросы в прямом эфире.

🕓 Когда: 24 марта, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Дробинская Мария — эксперт в области внедрения BI-систем и цифровизации.

➡️ Записаться

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

Стать системным аналитиком в YADRO — дело трех дней

До 29 марта открыта программа быстрого найма для системных аналитиков. Таких специалистов ищут сразу две команды:

— Телеком. С нуля создают телекоммуникационные решения для беспроводных мобильных сетей и сопутствующих услуг. Разрабатывает первые российские базовые станции стандартов GSM/LTE.

BIOS/BMC. Инженеры занимаются разработкой и сопровождением собственных программных реализаций ПО UEFI/BIOS и BMC, используемых в различных продуктах YADRO.

Подать заявку → 

Формат быстрого найма подразумевает ускоренные прохождение технического и менеджерского интервью и возможность получить оффер в компанию за три дня.

Направления, где нужны аналитики:

  • OAM (Operations, administration and maintenance). Специалисты тут работают с системой, обеспечивающей эксплуатационную управляемость и устойчивость операторского уровня. Отвечают за сквозные сценарии эксплуатации — от конфигурирования и мониторинга до инцидентов, SLA и масштабирования.

  • GSM. Здесь разрабатывают GSM Controller (BSC) и компоненты базовой станции (BTS) стандарта GSM с поддержкой GPRS и основного функционала для операторов большой тройки.

  • LTE. Инженеры здесь создают базовую станцию LTE (4G), реализуя полный стек телекоммуникационных протоколов «с нуля».

  • BIOS/BMC. Как уже писали выше, здесь занимаются разработкой и поддержкой UEFI/BIOS для продуктов компании, кода BMC для мониторинга и управления серверами, а также прошивками для MCU- и FPGA-модулей серверов (материнские платы, экспандеры и так далее).

Подробнее об ожиданиях к кандидатам — на лендинге SPRINT OFFER. Успейте оставить заявку до 29 марта.

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