Технологические задачи
Модуль Технологические задачи - это задачи, связанные с разработкой, внедрением и совершенствованием новых технологий, продуктов и процессов.
Если у вас есть потребность по разработке, внедрению и другие спросы вы можете разместить информацию ниже.
ИИ-модуль выявления аномалий и прогнозирования потребления электроэнергии для бизнес-центров
Цель — создать аналитический ИИ-модуль для платформы мониторинга коммунальных ресурсов бизнес-центров и складов, который по данным импульсных электросчётчиков (поминутные значения, 16 каналов на пилотном объекте) автоматически выявляет аномалии потребления, разделяет нагрузку по типам оборудования, прогнозирует потребление и сумму счёта на 7/30 дней и объясняет причины отклонений на русском и казахском языках. Инфраструктура сбора данных уже работает: счётчики Saiman → модуль ОВЕН МВ210-204 → MQTT → база данных → веб-дашборд. Требуется: детекция аномалий (ночное/выходное потребление, скачки, потери между вводным и субсчётчиками) с долей ложных срабатываний ≤10 %; прогноз с ошибкой ≤8 % MAPE; REST API; хранение данных на территории РК; открытый стек. Формат: пилот на реальном объекте в Алматы с предоставлением данных → лицензия, партнёрство или подряд. Подробности — в прикреплённом ТЗ.
Прием решений до
10.11.26 (включительно)
Область задачи
Системы технического учета электроэнергииКоличество заявок
8
Разработка системы внутристанционной диспетчеризации
Цель — сократить простой вагонов и непроизводительную работу локомотивов, перевести учёт и документы в единый цифровой контур. Базовые значения замеряются на этапе обследования; целевые ниже — ориентиры для согласования.
Прием решений до
03.11.26 (включительно)
Область задачи
Интеллектуальные системы управленияКоличество заявок
4
Раздел статистики использования AI-токенов в панели управления AI-платформой
Дать руководителям данные о расходе токенов и стоимости по неделям, отделам и сотрудникам, чтобы отслеживать динамику и аномальные отклонения
Прием решений до
10.11.26 (включительно)
Область задачи
Интеллектуальные системы управленияКоличество заявок
9
Спящий режим кампаний: автоматическое возобновление при поступлении контактов
Сохранить экономию ресурсов за счёт остановки неактивных кампаний и исключить потерю контактов, которые поступают в кампанию после остановки
Прием решений до
10.11.26 (включительно)
Область задачи
Технологии в телекоммуникацияхКоличество заявок
4
Блокировка запуска кампании без биллинг-аккаунта и тарифного плана
Не допускать запуск кампании, для которой тарификация заведомо невозможна, и сообщать пользователю точную причину отказа
Прием решений до
10.11.26 (включительно)
Область задачи
Технологии в телекоммуникацияхКоличество заявок
5
Валидация переходов между бизнес-процессами
Предотвратить сохранение переходов без существующего и доступного целевого БП
Прием решений до
10.11.26 (включительно)
Область задачи
Технологии в телекоммуникацияхКоличество заявок
7
Инженерное управление качеством решений, которые неинженерные роли создают с помощью ИИ-агентов: защитные ограничители и рабочие процессы
Спроектировать общекорпоративную модель, при которой неинженеры продолжают создавать решения с помощью ИИ-агентов (Claude Code, Codex, OpenCode), а результаты соответствуют стандартам качества, безопасности и сопровождаемости при минимальном участии инженеров. Что спроектировать: 1. Классификация по риску – правила отнесения по измеримым признакам (чувствительность данных, доступность извне, уровень привилегий, влияние на бизнес), кто и когда присваивает класс. Для каждого класса свой режим ограничителей и свой уровень участия инженеров. Граничный случай: внутренний инструмент с правом записи в платежи. 2. Целевые рабочие процессы – путь решения от идеи до вывода в эксплуатацию и снятия с неё; где неинженер идёт один, а где подключается инженер. 3. Конкретные ограничители – механизмы, а не лозунги: эталонные шаблоны проектов; автоматические проверки в конвейере сборки (анализ стиля кода, тесты, статический анализ безопасности, поиск ключей и паролей, проверка сторонних библиотек, правила в виде кода); политики хранилищ кода (защита основных веток, обязательная проверка изменений назначенными ответственными, изоляция сред); платформенные границы (белый список разрешённых сервисов, песочница, управляемый доступ к данным); встроенный сбор метрик и оповещения. Для каждого ограничителя – где он срабатывает и что происходит при срабатывании. 4. Модель ответственности – кто отвечает за сервис, роли, правила передачи вопроса инженеру, судьба брошенных сервисов без хозяина. 5. План распространения – на всю компанию с низкой стоимостью тиражирования: самообслуживание и шаблоны, а не ручное сопровождение каждого создателя. 6. Мотивация – ограничители разрешают, а не блокируют; трение соразмерно риску; быстрый легальный путь вместо обхода правил. 7. Нагрузка на инженеров и метрики – упрощённая оценка трудозатрат инженеров (первоначальные вложения в платформу, регулярные проверки, исключения, разбор сбоев) с явными допущениями; метрики успеха с определениями; компромиссы – чем модель жертвует. Рамки и вводные Решение не привязано к конкретному агенту: поддерживаются любые (Claude Code, Codex, OpenCode), без зависимости от поставщика. Опирается на уже имеющиеся систему контроля версий, конвейер сборки и доставки, средства сбора метрик и контроля состояния, а не заменяет их. Неинженеры создают что угодно: веб- и мобильные приложения, внутренние инструменты, доработки существующих продуктов. Отрасль Freedom Афиша – продажа билетов через интернет: персональные данные и платёжный контур. Масштаб качественный: десятки создателей на единицы инженеров. Точные цифры не задаются. Возможности имеющихся инструментов и допустимый доступ к персональным данным и платёжному контуру не детализированы: участник задаёт минимальный базовый уровень или явно фиксирует свои допущения. Формат сдачи Только проектный документ (в формате Markdown или PDF). Код и прототипы не требуются. Схемы – по желанию. Критерии оценки (для жюри) Обязательные условия (без них работа не засчитывается): решение не привязано к конкретному агенту и опирается на уже имеющиеся инструменты; есть классификация по риску с явными правилами отнесения; формат – проектный документ. Оцениваемые качества (0 – нет, 1 – частично, 2 – полно): Строгость контроля зависит от риска, класс присваивается по измеримым признакам. Ограничители – конкретные механизмы с указанием места и поведения при срабатывании (отдельно от вопросов безопасности ниже). Участие инженеров сведено к минимуму и подтверждено оценкой трудозатрат с допущениями. Низкая стоимость распространения (самообслуживание, шаблоны). Мотивация сохранена: быстрый легальный путь, трение соразмерно риску. Модель ответственности полна: кто отвечает за сервис, передача вопроса инженеру, брошенные сервисы, вывод из эксплуатации. Безопасность: ключи и пароли, сторонние библиотеки, доступ к данным (персональные данные, платежи), риски цепочки зависимостей. Метрики с определениями и способом сбора; честные компромиссы.
Прием решений до
10.11.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
8
Разработка высокопроизводительной мультиязычной системы выявления и идентификации объектов информационного поля с определением контекстной тональности по отношению к ним
Создать высокопроизводительную мультиязычную систему из двух самостоятельных этапов: (1) автоматическое выявление и идентификация организаций, персон, брендов, продуктов и других объектов в публикациях СМИ и социальных сетей, включая неоднозначные названия; (2) определение контекстной тональности отдельно по отношению к каждому выявленному объекту. Поддержать семь языков Центральной Азии, API и массовую обработку. Результат — работающий прототип, независимые испытания и план интеграции.
Прием решений до
10.11.26 (включительно)
Область задачи
Нейротехнологии и искусственный интеллектКоличество заявок
4
Система мониторинга транзакций и выявления мошенничества в реальном времени для мобильного платёжного приложения
Monexsol разрабатывает мобильное платёжное приложение для рынка СНГ: P2P-переводы, оплата услуг, электронный кошелёк, QR-платежи и приём платежей для бизнеса. Продукт находится на стадии MVP и готовится к коммерческому запуску. Цель - внедрить систему мониторинга транзакций и выявления мошенничества в реальном времени, которая защитит клиентов и компанию от финансовых потерь и обеспечит соответствие требованиям регуляторов стран присутствия и банков-партнёров в сфере ПОД/ФТ. Ключевые требования: оценка риска операции до её проведения (не более 200 мс для 95% операций), сочетание правил и моделей машинного обучения, работа без исторических данных заказчика на старте, анализ устройства и сессии, выявление дропперских схем, модуль разбора инцидентов, поддержка нескольких юрисдикций и валют, обработка до 100 событий в секунду с масштабированием до 500, доступность не ниже 99,9%. Предполагаемый формат взаимодействия: архитектурная консультация и PoC на тестовых сценариях, затем пилот на реальных операциях после запуска. Модель сотрудничества, сроки и стоимость определяются по итогам рассмотрения предложений. Подробные требования, разграничение ответственности, критерии приёмки и оценки предложений - в приложенном техническом задании. Публикация задачи является сбором предложений и не является офертой.
Прием решений до
10.11.26 (включительно)
Область задачи
Технологии цифровой безопасностиКоличество заявок
3
Антифрод платежей и управление чарджбэками при онлайн-оплате билетов
Цель и описание задачи (проекта) Цель — спроектировать систему выявления мошеннических платежей (кардинг, подбор реквизитов краденых карт, чарджбэк-фрод) при онлайн-оплате билетов, минимизируя финансовые потери и блокировки платёжного аккаунта Ticketon у эквайера, при этом не снижая конверсию оплаты для добросовестных покупателей. Участник проектирует риск-контур на этапе оплаты: сигналы риска до/во время транзакции, правила маршрутизации платежа (пропустить, запросить 3-D Secure/доп. подтверждение, отклонить), работу с эквайером и платёжными провайдерами, процесс реагирования на чарджбэки. Существующий процесс оплаты может быть перепроектирован полностью. Результат — проектный документ: архитектура антифрод-контура на этапе оплаты, правила принятия решений, процесс работы с чарджбэками, обоснование trade-offs. Код не требуется.
Прием решений до
10.11.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
7
