AI генерирует тесты, но 95% из них не работают — галлюцинирует классы,
путает поля, использует несуществующие API. Знакомо? Мы в отделе RAPID прошли через
это на проекте с биржевым протоколом TWIME. Делимся итеративным подходом:
как за 3 шага превратить хаос из 307 тестов в 109 работающих.
С конкретными промптами, метриками и выводами.
Всем привет! Меня зовут Алексей Архипов. Я работаю начальником отдела тестирования в Национальном клиринговом центре (НКЦ), входящем в состав Группы «Московская биржа». За последние годы мы столкнулись с множеством вызовов в оценке качества программного обеспечения (ПО), особенно в условиях высокой нагрузки и сложности критических систем. В начале работы с QA-командой меня заинтересовал ключевой вопрос — каким образом можно точно измерить качество тестирования? Ответ оказался неочевидным.
В современных условиях тестирование ПО — это не просто процесс проверки функциональности, а ключевой элемент управления качеством. Однако популярная метрика Defect Leakage (DL), которую часто используют для оценки работы QA-инженеров, не всегда отражает реальную картину. В НКЦ мы столкнулись с этой проблемой и разработали для себя более точный подход — Коэффициент эффективности тестирования (КЭТ). В этой статье я расскажу, почему DL не работает, как мы внедрили КЭТ и какие результаты получили.
Всем привет! Меня зовут Андрей Бугаенко, и в этой статье я расскажу, почему мы в Московской бирже считаем, что AutoML-подход, основанный на интеллектуальном выборе моделей и признаков (на примере MOEX_AutoML), эффективнее современных LLM в задачах численного прогнозирования.
Актуальной задачей любой компании является прогнозирование бизнес-метрик. Прогнозирование используется для различных финансовых задач, в том числе, например, для бизнес-планирования или финансовой аналитической отчетности. Эмпирические данные и практика ранее всегда показывали непосредственное превосходство специализированных ML-моделей над любыми LLM (Large Language Models) при решении задач прогнозирования количественных показателей. Но за последнее время были выпущены ChatGPT-5, Claude Sonnet 4, GLM 4.5, GROK-4, Gemmini 2.5 Pro и, возможно современные LLM уже превзошли качество прогнозирования ML-моделями, полученными, например, с помощью ML.
Правда у LLM есть определённые архитектурные ограничения в обработке числовых данных. Ведь превосходство определялось не только фундаментальными различиями в архитектурных подходах, а в первую очередь, тем, что у ML (и как результатов работы AutoML) веса целевым видом оптимизированы под конкретные метрики качества прогноза — такие, как RMSE, MAE, MAPE и т.д. На каждом этапе AutoML-конвейера — от первичного выбора типа модели до фичеселекшена и финальной тонкой настройки гиперпараметров — методы целенаправленно формируют аппроксимационную функцию, строго ориентированную на минимизацию целевой бизнес-ошибки, именно той, которую мы выбрали для решаемой задачи.
Всем привет! Меня зовут Ренат Дасаев, и я продолжаю рассказ о развитии E2E‑тестирования в Московской Бирже. За два года после публикации первой статьи многое изменилось: мы переупаковали процессы, расширили команду и существенно обновили технический стек. Хотите узнать, как нам удалось масштабироваться и какие инструменты сегодня ускоряют работу? Тогда - эта статья для вас!
Привет! Мы – команда сопровождения банковских телекоммуникаций Национального Расчетного Депозитария (Группа «Московская биржа»). В НРД мы отвечаем за сопровождение критичных информационных сервисов, которые используются на ежедневной основе при отправке платежей/финансовых сообщений через каналы платежной системы Банка России (ПС БР), SWIFT, системы передачи финансовой сообщений (СПФС), сдачи отчетности, взаимодействии с Федеральными органами исполнительной власти.
В этой статье расскажем об успешном кейсе по импортозамещению такого значимого программного продукта, как Дельта (ПП Дельта).
Система раннего предупреждения импульсивных торговых решений
🚨 Как машинное обучение помогает предотвратить эмоциональные ошибки в трейдинге
Импульсивные решения — главный враг трейдера. Эмоциональные сделки, увеличение позиций после потерь, торговля в ночное время — все это приводит к убыткам даже у опытных участников рынка.
В этой статье я расскажу, как с помощью анализа данных и машинного обучения создать систему, которая заранее предупреждает о высоком риске принятия импульсивного решения.
Что вы узнаете:
• Какие поведенческие паттерны выдают склонность к импульсивным решениям
• Как XGBoost и логистическая регрессия помогают выявить "группы риска"
• Практические рекомендации по внедрению системы предупреждений
• Реальные результаты анализа данных 1000+ трейдеров
Ключевые находки:
88% точность предсказания импульсивных решений
5 основных факторов риска, которые можно отслеживать автоматически
Снижение убыточных сделок на 23% при использовании системы
Статья будет полезна как начинающим трейдерам, так и разработчикам торговых систем. Все графики, код и методология — в открытом доступе.
#машинноеобучение #трейдинг #анализданных #финтех #python #xgboost
Друзья, привет! Меня зовут Ларионов Александр. Я работаю системным аналитиком. Совместно с Лабораторией инноваций Московской биржи мы изучали вопрос применения AI в системном анализе.
Когда я впервые столкнулся с задачей внедрения AI-ассистентов в процессы работы системного аналитика, то отреагировал скептически. Поводов было немало: большинство материалов на эту тему представляли собой восторженные отзывы вроде «AI автоматизирует рутину» или «machine learning улучшает принятие решений». Однако, при ближайшем рассмотрении, эти фразы распадались на абстрактные утверждения. Попытки уточнить у авторов конкретные кейсы или сценарии применения их инструментов для системного анализа сводились к общим фразам: «Обучите модель на ваших данных — и она всё поймёт».
Скептицизма добавляло и то, что сама роль системного аналитика строится на работе в условиях высокой неопределенности. В этой специальности регулярно сталкиваются с неоднозначными требованиями, непонятной бизнес-логикой, конфликтующими приоритетами, быстро меняющимися требованиями. Это противоречит глубинному принципу современных AI-моделей — обучению на конкретных, четко структурированных данных. Машине сложно оперировать «чувством здравого смысла» или «интуитивным пониманием бизнес-процессов», которые так важны для аналитика.
Как же убедиться, что AI полезен для нашей профессии, когда в поиске реальных кейсов находишь информационный вакуум? Я решил переосмыслить подход и начать экспериментировать самостоятельно. За основу я взял самые распространённые задачи, с которыми сталкиваются системные аналитики, в том числе и мы в Лаборатории инноваций Московской биржи.
Спросил свою 3070ti «Как думаешь, что важнее – процесс или результат?», а он мне отвечает, чтобы я сам выбирал. И зачем эти нейросети, если они даже не могут выбрать, что для меня важнее и лучше…
Всем привет! Меня зовут Александр Чуркин, и я руковожу Управлением корпоративной инфраструктуры Национального клирингового центра (НКЦ).
НКЦ входит в Группу «Московская Биржа». Напомню, мы выполняем функции клиринговой организации и центрального контрагента на финансовом рынке. То есть, берем на себя риски по заключаемым участниками в ходе биржевых торгов сделкам, выступая посредником между сторонами: продавцом для каждого покупателя и покупателем для каждого продавца.
В середине прошлого года мы объявили о квалификационном отборе поставщиков лицензий коммерческой версии СУБД на основе PostgreSQL, а в конце февраля этого года завершили тестирование и определились с выбором в пользу решения – Digital Q.DataBase от компании «Диасофт».
Теперь расскажем о том, как мы проводили предварительный отбор, тестировали отобранные решения, сделали свой выбор и готовимся к переходу на опенсорсную СУБД. Надеемся, что наш опыт поможет и вам!
Добрый день! Мы – команда сопровождения банковских телекоммуникаций Национального Расчетного Депозитария (Группа «Московская Биржа»). В НРД мы отвечаем за сопровождение информационных сервисов, которые используются на ежедневной основе при отправке платежей/сообщений через каналы SWIFT и СПФС, сдачи отчетности, взаимодействию со Федеральными органами исполнительной власти и других не менее важных направлений.
В этой статье расскажем о тех изменениях, которые затронули все банки, работающие через Транспортный Шлюз Банка России (ТШ БР), и как удалось найти альтернативное решение там, где это казалось невозможным.
Мы планируем переезд! Новый офис будет современнее, удобнее, красивее и больше. Хорошая новость для сотрудников, но непростая – для айтишников.
В этой статье решили разобрать ключевые вопросы переезда со стороны ИТ-оборудования и ПО: какие миграции бывают, на что нужно обратить внимание и как справляться с некоторыми трудностями. Причём предлагаем расширить тему: переезд не всегда связан с перемещением именно пользователей, персонал может остаться в том же офисе, но оборудование и системы по каким-то причинам мигрировать нужно. Вот об этом поговорим.
В конце 2023го года в рамках работ по импортозамещению основным корпоративным мессенджером Московской Биржи вместо MS Teams стал eXpress.
На корпоративный мессенджер завязано множество интеграций и рабочих процессов, в частности - интеграция системы мониторинга Zabbix Ситуационного Центра. С помощью этой интеграции мы имели возможность оповещать инженеров в чатах о возникновении и устранении событий с помощью бота.
Перед командой Ситуационного Центра Московской Биржи встала задача: перенести все настроенные интеграции, рабочие процессы и оповещения Zabbix в eXpress
Всем привет! Меня зовут Ренат Дасаев и в прошлой статье Автоматизация Е2Е-тестирования сквозных БП интеграционных проектов Операционного блока было рассказано о том, как устроено e2e-автотестирование. Сегодня хочу рассказать о том, как используется camunda в автотестировании бизнес-процессов (далее БП). На практических примерах рассмотрим, что и как мы делаем в своих тестах.
Всем привет! На связи Срочный рынок Московской биржи. Будем вместе исследовать увлекательный мир на стыке финансов и технологий. Независимо от того, являетесь ли вы профессионалом в области финансов, энтузиастом технологий или хотите быть в "модной" теме инвестиций, знакомство с новым сервисом Московской биржи будет полезно.
Опцион — инструмент, который дает покупателю право купить или продать базовый актив по заранее установленной цене в будущем. Как он работает и для чего нужен – читайте в нашей статье.
Опционный калькулятор помогает рассчитать прибыль / убыток, комиссию от торговли опционами и даже моделировать собственные торговые стратегии.
Что умеет калькулятор?
Как управляют лицензиями на софт в Группе MOEX и получают уверенность в том, что расходы на них эффективны?
Всем привет!
Меня зовут Сергей Максимов и я руковожу разработкой в Центре Управления Процессами (ЦУП) Московской Биржи. В статье я хочу рассказать о нашем опыте автоматизации бизнес-процессов (БП), когда система должна быть не только удобной бизнес-пользователям снаружи, но и надежной внутри.
Бизнес Биржи, с одной стороны, похож на обычный банковский финтех, но имеет ряд важных особенностей. Чтобы лучше представить специфику нашей работы, я приведу метафору. Представьте, что каждое утро с вашего корпоративного космодрома в космос отправляется ракета. В течение дня космический корабль автономно выполняет работу на орбите, а вечером возвращается на базу. В полёте связь с кораблем очень ограничена и успех его полёта на 99% определяется качественной подготовкой. Всё должно отработать точно и в срок. Досрочный спуск корабля с орбиты технически возможен, но влечет за собой огромные репутационные потери с отчетом регулятору и новостями в федеральных СМИ.
Мы — SQL команда Срочного рынка Московской Биржи, занимаемся разработкой и сопровождением бэкофиса торгово-клиринговой системы Spectra с момента ее возникновения. Срочный рынок Московской Биржи — это более 500 фьючерсных и 30000 опционных инструментов, несколько миллионов сделок в день.
Торгово-клиринговая система Срочного рынка (ТКС Spectra) изначально строилась на основе MS SQL, и за пару десятков лет прошла сложный путь от нескольких серверов БД до огромной системы с сервис-ориентированной архитектурой. Долгое время вся бизнес-логика системы разрабатывалась в программном слое на серверах MS SQL: и матчинг заявок, и расчет обеспечения, и управление клиентами были реализованы на T-SQL.
На сегодняшний день весь высоконагруженный функционал вынесен в отдельные сервисы, но в базах данных остаются сотни таблиц и тысячи программных объектов. Особенностью кода является высокая когнитивная и цикломатическая сложность. Управлять этим кодом с учетом всех требований по надежности и быстродействию – очень интересная задача.
В этой статье мы хотим рассказать об эволюции нашей системы разработки на SQL.
Привет, уважаемые читатели Хабра!
На связи Лаборатория инноваций Московской биржи
Хотим поделиться с вами нашим опытом разработки чат-бота для 1-й линии поддержки на базе корпоративного мессенджера eXpress.
Расскажем о нашем опыте, ошибках, сделанных выводах и поделимся полезными ссылками для желающих заняться разработкой ботов для eXpress.
Клиенты и пользователи ожидают быстрых, интуитивных и персонализированных взаимодействий с цифровыми каналами, будь то приложения, сайты, телефония, почта или мессенджеры. Пользователи могут в любой момент переключаться между ними, при этом бизнес через оператора или автоматизацию должен находиться всегда в контексте и знать весь накопленный клиентский путь и потребности.
Для оперативной адаптации приложений в таких каналах нам нужны подходящие инструменты. Если их множество и функциональность может стать базовой для прикладных задач, неизбежна платформизация.
В данной статье я расскажу про платформу цифрового опыта (Digital Experience Platform, DXP), ее состав и роль в производстве ценностей для компании.
Всем привет! Решили рассказать вам, уважаемые читатели Хабра, историю процесса внедрения E2E-автотестов в бизнес-процессы Московской Биржи.
Для начала вкратце разберемся, что такое E2E-автотест. Это вид тестов, который проверяет бизнес функционал от момента его начала до завершения.
Похожие тесты уже, безусловно, существовали в нашей компании, но они, как правило, покрывали функционал, который не выходил за пределы одного департамента (подразделения). У нас же была задача покрыть автотестами функционал, проходящий через несколько департаментов. Теперь поговорим, откуда взялась такая потребность.