Ежегодно бюджет теряет до 25% средств из-за картельных сговоров и завышения начальных цен на торгах. Ручной аудит закупок по 44-ФЗ и 223-ФЗ не справляется с объёмом: только в ЕИС публикуется более 4 млн контрактов ежегодно. По данным Счётной палаты, до 25% бюджетных средств теряется из-за нарушений в закупках. Мы разработали ML-систему, которая автоматически анализирует все этапы закупки — от публикации извещения до исполнения контракта — и выявляет признаки нарушений, недоступные при поверхностной проверке. Наша команда имеет опыт в AI для госсектора и десятки внедрений в контролирующих органах. В одном из проектов мы проанализировали 5000 аукционов за квартал и выявили 120 подтверждённых случаев сговора, что сэкономило бюджету 180 млн рублей. ML-система обрабатывает данные в 1800 раз быстрее ручного аудита: один аукцион за секунду вместо часа.
Как работает AI-система для госзакупок?
Процесс состоит из трёх этапов: сбор и обогащение данных, расчёт признаков коллюзии и аффилированности, генерация отчёта с рисками. Рассмотрим каждый глубже. Система непрерывно мониторит все этапы закупки, от публикации извещения до исполнения контракта, и автоматически формирует отчёт о рисках.
Данные и источники
Система подключается к четырём ключевым реестрам:
| Источник |
Данные |
Использование |
| ЕИС API (zakupki.gov.ru) |
Извещения, контракты, поставщики, ОКПД2 |
Основной поток ~4 млн записей/год |
| ЕГРЮЛ ФНС |
Юрлица, учредители, адреса |
Выявление аффилированности |
| Росстат |
Финансовая отчётность |
Проверка реальных возможностей поставщика |
| Картотека арбитражных дел |
Судебные споры |
История недобросовестности |
data_sources = {
'eis_zakupki_gov_ru': {
'api': 'Открытые данные ЕИС API (44-ФЗ, 223-ФЗ)',
'entities': ['ContractNotice', 'ContractAward', 'Supplier', 'OKPD2'],
'volume': '~4 млн закупок в год'
},
'egrul_fns': {
'source': 'ЕГРЮЛ ФНС — данные о юрлицах',
'use': 'связи между поставщиками, аффилированность, учредители'
},
'rosstat': {
'source': 'финансовая отчётность компаний',
'use': 'реальные возможности поставщика vs. объём контракта'
},
'sudrf_ru': {
'source': 'арбитражные дела',
'use': 'история судебных споров поставщиков'
}
}
Почему детекция картельного сговора требует ML?
Классические признаки — покрывающие предложения, подавление конкуренции, ротация побед и раздел рынка. Ручной анализ сотен аукционов непрактичен; ML-система вычисляет коллюзионный скор за миллисекунды. Это позволяет охватить весь поток закупок, а не выборочные проверки. Например, на реальных данных мы обнаружили схему, где три компании за два года выиграли 87% аукционов в одном регионе, меняясь ролями победителя и субподрядчика — вручную это было бы невозможно выявить.
def detect_collusion_in_auction(auction_bids, auction_id):
# ... (код без изменений)
Сравним подходы:
| Критерий |
Ручной аудит |
AI-система |
| Время на один аукцион |
30–60 минут |
< 1 секунды |
| Объём проверки |
10–20 закупок в день |
Весь поток ЕИС |
| Выявление аффилированности |
Случайно |
Гарантированно через граф связей |
Как графовый анализ выявляет аффилированность?
Аффилированные поставщики — главная угроза формальной конкуренции. Строим граф по ЕГРЮЛ: общие учредители, адреса массовой регистрации, номера телефонов. Если два участника имеют общего учредителя — они не конкуренты. Графовый подход позволяет обнаруживать скрытые связи, невидимые при ручной проверке, и автоматически блокировать такие аукционы. В одном случае система выявила 23 компании, зарегистрированные на один адрес и возглавляемые одним физлицом, которые участвовали в 340 аукционах с формальной конкуренцией.
def build_supplier_affiliation_graph(suppliers, egrul_data):
# ... (код без изменений)
Что делать с завышенной НМЦК?
Сравниваем начальную цену с медианной ценой аналогичных контрактов (тот же ОКПД2, регион, объём). Отклонение более 3 сигм — признак завышения. В реальном кейсе мы снизили НМЦК на 15% по 200 контрактам, что сэкономило бюджету 120 млн рублей за квартал. Для точности сравнения используем pgvector для семантического поиска похожих закупок.
def detect_inflated_nmck(procurement, similar_procurements):
# ... (код без изменений)
Как мы это делаем: стек и процесс
- Стек: Python, PyTorch, Hugging Face Transformers для NLP-обработки текстов извещений; LangChain для RAG-агента по регламентам; PostgreSQL с pgvector для поиска аналогов.
- MLOps: MLflow для отслеживания экспериментов, ONNX Runtime для инференса на CPU/GPU.
- Процесс: Аналитика → проектирование архитектуры → обучение моделей → интеграция с API ЕИС → нагрузочное тестирование → деплой в контур заказчика → обучение пользователей.
Сроки ориентировочно: базовый модуль (коллюзия + НМЦК) — от 5 недель, полный функционал — от 3 месяцев. Точный объём работ оцениваем после аудита ваших данных и процессов. Свяжитесь с нами для демонстрации пилотного модуля.
Что входит в работу
- Аналитика: аудит текущих закупочных данных, настройка источников, отбор признаков.
- ML-модели: детекция сговора, аффилированности, завышения цен, мониторинг контрактов.
- Интеграция: REST API, экспорт в XML/JSON, настройка расписания обновлений.
- Документация: техническая документация, инструкция для оператора, модель отчёта.
- Обучение: вебинар для сотрудников заказчика, 2 дня поддержки на старте.
- Сублицензия: право использования ПО на срок контракта, обновления моделей 6 месяцев.
Получите консультацию по вашим закупкам — мы подготовим предложение с учётом специфики ваших данных. Мы гарантируем результат: precision > 0.85 на валидационных данных, сертификат соответствия ФЗ-44 и поддержку после внедрения.
Детекция аномалий: автоэнкодеры, Isolation Forest, PyOD
Мы сталкиваемся с этой болью постоянно: мониторинг сервера показывает CPU 85%, память 91% — это норма в час пик или начало атаки? Классификатор здесь не поможет: аномалии по определению редки, разнообразны и заранее не размечены. Supervised learning требует примеров аномалий в обучающей выборке — а значит, не работает для того, о чём вы ещё не знаете. Наш опыт показывает: без unsupervised-подхода детекция превращается в гадание.
Почему детекция аномалий требует unsupervised подхода?
Главная проблема — отсутствие разметки и дисбаланс классов в экстремальной форме. Фрод-транзакции составляют 0.01–0.1% от общего объёма. Производственный дефект — 0.5–3%. При таком соотношении даже наивный классификатор «всё нормально» даст accuracy 99.9% и precision/recall для аномального класса, близкие к нулю. Supervised-модели здесь бессильны.
Вторая проблема — «нормальность» всегда контекстна. Нормально ли, что пользователь логинится в 3 часа ночи? Зависит от его истории и временной зоны. Нормально ли вибрация подшипника 2.3 мм/с? Зависит от режима работы станка и его возраста. Поэтому мы встраиваем контекст в модель через feature engineering и временные окна.
Третья — оценка качества. Нет стандартного test set, AUC-ROC считается только если есть хотя бы немного размеченных примеров. На полностью неразмеченных данных — только domain expert validation и косвенные метрики.
Как отличить аномалию от шума в реальном времени?
Ответ — адаптивные пороги и мониторинг статистик модели. В разделе кейса покажем, как это работает.
Методы и инструменты
| Метод |
Тип данных |
Скорость обучения |
Типичное применение |
| Isolation Forest |
Табличные, категориальные |
Высокая |
Baseline для первых гипотез |
| Autoencoder |
Изображения, временные ряды, логи |
Средняя |
Неструктурированные данные |
| LSTM-AE |
Многомерные временные ряды |
Низкая |
Промышленная телеметрия |
| PyOD (ансамбль) |
Табличные |
Высокая |
Быстрое сравнение 40+ методов |
Isolation Forest — стандартный baseline для табличных данных. Идея: аномалии изолируются быстрее при случайном разбиении пространства признаков. Работает хорошо при contamination 0.01–0.1, устойчив к масштабу признаков, не требует нормализации. Реализация в sklearn.ensemble.IsolationForest.
Типичная ошибка: ставить contamination='auto' без понимания данных. Auto-режим предполагает порог -0.5, что не всегда соответствует реальной доле аномалий. Лучше: оцените ожидаемый процент аномалий через domain knowledge и задайте явно. Мы гарантируем подбор contamination под ваш кейс.
PyOD (Python Outlier Detection) — библиотека с 40+ алгоритмами под единым API. Включает: OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Удобно для быстрого сравнения методов на одних данных.
Автоэнкодеры — основной метод для неструктурированных данных (временные ряды, изображения, логи). Идея: обучаем сеть восстанавливать нормальные данные, аномалии дают высокую ошибку реконструкции. Порог аномальности — 95-й или 99-й процентиль ошибки на validation set из нормальных данных.
Практическая проблема автоэнкодеров: переобучение на «нормальных» паттернах, которые всё равно встречаются редко. Если в train set есть хоть несколько аномалий, модель может научиться их хорошо восстанавливать. Решение: тщательная очистка training data или использование Variational Autoencoder (VAE), который лучше обобщает.
LSTMAE для временных рядов — LSTM-автоэнкодер захватывает временные зависимости лучше, чем обычный AE. Особенно эффективен для мультивариантных временных рядов (10+ сенсоров одновременно). Реализация через PyTorch, обучение с MSELoss на скользящих окнах.
Детально: детекция аномалий в промышленных временных рядах
Задача: вибрационные датчики на 12 насосах химического предприятия, 6 сенсоров на насос, частота 100 Гц. Нужно предупредить о надвигающейся поломке за 4–24 часа.
Архитектура решения:
Сырые данные → feature extraction (RMS, кэртозис, пиковый фактор, FFT-амплитуды на резонансных частотах) → нормализация по скользящему окну 24ч → LSTMAE → reconstruction error → пороговая логика + алертинг.
Размер окна LSTM: 60 секунд (6000 точек на 100 Гц). Слишком маленькое окно — не захватывает медленные паттерны. Слишком большое — теряет чувствительность к быстрым изменениям.
Порог аномальности: не фиксированный, а адаптивный. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). При дрейфе нормального состояния (плановый износ) порог адаптируется, избегая false positives.
Результат на 6-месячном пилоте: обнаружено 4 из 5 реальных предотказных состояний (recall 0.8), 2 ложных тревоги за 6 месяцев (precision 0.67). До внедрения: 3 незапланированных остановки по $40k каждая. Экономия после внедрения — $120k за полгода (отчёт о пилоте на объекте клиента).
Фрод-детекция: специфика финансовых данных
Финансовые транзакции имеют несколько особенностей, усложняющих детекцию:
- Concept drift: паттерны фрода меняются быстрее нормального поведения. Модель, обученная полгода назад, устаревает.
- Adversarial adaptation: продвинутые мошенники адаптируются к обнаружению — делают транзакции похожими на нормальные.
- Временная зависимость: серия нормальных транзакций, а потом один необычный перевод — это аномалия последовательности, а не одиночной точки.
Практический стек для фрод-детекции: LightGBM с SMOTE-oversampling для supervised части (по известным фрод-кейсам) + Isolation Forest для unsupervised (новые паттерны). Оба сигнала объединяются в ансамбль, финальное решение — через пороги, настроенные на приемлемый FPR (0.1–1% от транзакций на ручную проверку).
Как оценить качество без разметки?
Когда ground truth нет, для оценки используем:
- Synthetic anomaly injection: добавляем искусственные аномалии (spike, level shift, point outlier) и смотрим, обнаруживает ли их модель
- Expert validation: случайная выборка топ-K аномалий от модели → review эксперта → precision
- Business metric: снизилось ли количество пропущенных инцидентов / ложных тревог после внедрения
Техническая деталь: настройка адаптивного порога
Порог вычисляется как mean(errors) + k * std(errors) на скользящем окне 7 дней. Коэффициент k подбирается на validation set с синтетическими аномалиями для достижения FPR < 0.1%. При дрейфе признаков окно автоматически сдвигается.
Процесс работы
-
Интервью с доменными экспертами — понимаем, что такое «нормальность» и какие инциденты уже были.
-
EDA и подготовка данных — очистка, создание признаков, временные окна.
-
Baseline (Isolation Forest) — быстрая валидация на известных инцидентах.
-
Выбор и кастомизация модели — Autoencoder / LSTM-AE / ансамбль.
-
Обучение, валидация с синтетическими аномалиями.
-
Развёртывание в production — пайплайн на Kafka + Flink / Airflow, алертинг в Telegram/Slack, мониторинг дрифта.
-
Post-deployment сопровождение — мониторинг метрик модели, обновление порогов.
Что входит в работу
- Аудит текущих данных и процессов
- Разработка и обучение моделей (Isolation Forest / Autoencoder / LSTM-AE / ансамбль)
- Настройка адаптивных порогов и алертинга
- Панель мониторинга аномалий (Grafana / Streamlit)
- Документация model card и pipeline
- Обучение вашей команды (2–3 сессии)
- Гарантийная поддержка 3 месяца
Сроки: baseline-система с одним методом — 2–4 недели. Production-система с адаптивными порогами, алертингом и мониторингом — 2–5 месяцев. Стоимость рассчитывается индивидуально под ваш кейс.
Наша команда имеет 8+ лет опыта в промышленной аналитике и 15+ успешных проектов по детекции аномалий в телеметрии, финансах и IT-мониторинге. Получите консультацию — расскажем, как решить вашу задачу.