Anomalies Without Labels: Detecting Outliers Among 10 Million Records
When supervised models with 99.9% accuracy fail to find any anomalies, the issue is class imbalance. We build unsupervised pipelines using Isolation Forest, Autoencoder, and One-Class SVM that detect outliers without manual labeling. Such models train 10x faster than semi-supervised ones and require no pre-labeled data. However, choosing the right method is critical: an unsuitable algorithm can produce up to 80% false positives. That's why we start every project with a deep analysis of data structure and business context. Our MLOps experience in anomaly detection model training for unlabeled data ensures robust ML pipeline anomalies handling.
Unsupervised approaches enable detection without labeling costs: one engineer is enough for setup. In fintech, we used Isolation Forest for primary transaction screening (latency p99 < 10 ms) and Autoencoder for final verification. The detection rate increased by 40% compared to a rule-based system, and the false positive rate dropped 2x. Since anomalies make up less than 0.1% of data, accuracy is not informative — we focus on Precision/Recall/F1 and AUCPR. Clients typically achieve 30-50% reduction in incident analysis costs within the first quarter.
Choosing an Anomaly Detection Method
| Available Data |
Recommended Approach |
Example Training Time (100k records) |
| Labeled anomalies (< 1%) |
Imbalanced supervised (LightGBM with scale_pos_weight) |
2–5 minutes |
| Only normal data |
One-Class SVM / Autoencoder / Deep SVDD |
10–30 minutes |
| No labels at all |
Unsupervised: Isolation Forest, LOF |
< 1 minute |
| Time series with seasonality |
STL + residual detection |
5–10 minutes |
| Event sequences |
LSTM Autoencoder |
30–60 minutes |
Autoencoder vs Isolation Forest: Choosing the Right Method
Autoencoder is better for complex, high-dimensional data where anomalies manifest in nonlinear relationships. For example, in cybersecurity attack detection based on event logs — Isolation Forest shows low accuracy, while Autoencoder trains in 1–2 hours and achieves AUCPR > 0.9. For simple tabular data with clear outliers, Isolation Forest is faster and more interpretable. We often combine them: primary screening with Isolation Forest (low latency), then verification with Autoencoder.
How We Build a Production-Ready Pipeline
In practice, we combine multiple methods to improve robustness. For example, in a fintech project with 50 million transactions per day: Isolation Forest was used for primary filtering (latency p99 < 10 ms), Autoencoder for deep inspection of suspicious records. Result: detection rate increased 40% compared to rules, false positive rate dropped 2x.
Implementation of Key Methods
Example code for Isolation Forest and Autoencoder:
import numpy as np
from sklearn.ensemble import IsolationForest
from sklearn.metrics import average_precision_score
def train_isolation_forest(X, contamination=0.01):
"""Basic Isolation Forest with automatic threshold tuning"""
model = IsolationForest(contamination=contamination, random_state=42)
model.fit(X)
scores = model.score_samples(X) # lower = more anomalous
return model, scores
# Autoencoder in PyTorch
import torch.nn as nn
class AnomalyAutoencoder(nn.Module):
def __init__(self, input_dim, latent_dim=32):
super().__init__()
self.encoder = nn.Sequential(
nn.Linear(input_dim, 128),
nn.ReLU(),
nn.Linear(128, 64),
nn.ReLU(),
nn.Linear(64, latent_dim)
)
self.decoder = nn.Sequential(
nn.Linear(latent_dim, 64),
nn.ReLU(),
nn.Linear(64, 128),
nn.ReLU(),
nn.Linear(128, input_dim)
)
def anomaly_score(self, x, reduction='mean'):
with torch.no_grad():
z = self.encoder(x)
x_rec = self.decoder(z)
re = torch.mean((x - x_rec)**2, dim=1)
return re
For production, we package the model into ONNX Runtime and deploy on Triton Inference Server — this ensures minimal latency and high throughput.
Evaluation and Continuous Learning
Proper metrics for imbalanced classes:
def evaluate_aupr(y_true, y_scores):
return average_precision_score(y_true, y_scores)
Metric comparison for a dataset with 0.1% anomalies:
| Metric |
Typical Value |
Why Important |
| Accuracy |
99.9% |
Misleading – model finds no anomalies |
| AUCPR |
0.85–0.95 |
Shows ranking quality of anomalies |
| Fβ-score |
0.75–0.90 |
Accounts for imbalance, tuned to business priorities |
We use MLflow for experiment tracking: parameters (contamination, latent_dim), metrics (AUCPR, FPR), artifacts (models, PR curves). A feedback loop retrains the model every 1000 labels from engineers.
Example MLflow experiment setup
mlflow experiments create --experiment-name anomaly-detection
mlflow run . -P model=isolation_forest -P contamination=0.01
Project Workflow
- Analytics — study data, identify seasonality and anomaly types.
- Design — select stack and pipeline architecture.
- Implementation — train baseline and tune hyperparameters.
- Testing — validate on historical data with A/B test.
- Deployment — containerization, monitoring, CI/CD.
What's Included in the Work
- Trained model with detailed operation documentation.
- REST API for inference (FastAPI or Triton).
- MLflow dashboard with experiment history and access for your team.
- Feedback loop for retraining on operator labels.
- Engineer training: 2–3 hour workshop covering model usage and maintenance.
- Technical support for 30 days after deployment, including bug fixes and troubleshooting.
Estimated Timelines and Cost
Baseline model (Isolation Forest + evaluation) — 2 to 3 weeks. Full pipeline with Autoencoder, feedback loop, and production deployment — 6 to 8 weeks. Cost is calculated individually based on data volume and required accuracy. Typical baseline solution starts from $15,000. The solution typically pays for itself within 2–3 months by reducing incident analysis time. For a medium-scale project (100k records, full pipeline), the investment is around $40,000.
We guarantee quality: all models are validated on a hold-out set. We have over 5 years of experience in MLOps and 20+ implemented anomaly detection projects in fintech, telecom, and industry. To assess your case, contact us — we'll evaluate the task in 2 days and offer a turnkey solution. Get a consultation on anomaly detection on your data.
Anomaly Detection: Autoencoders, Isolation Forest, PyOD
Server monitoring shows CPU 85%, memory 91% — is this the start of an attack or normal peak load? A classifier won’t help: anomalies are by definition rare, diverse, and not pre-labeled. Supervised learning requires examples of anomalies in the training set — so it fails on what you haven’t seen yet. Without an unsupervised approach, detection turns into guesswork.
Why Does Anomaly Detection Require an Unsupervised Approach?
The main problem: no labels and extreme class imbalance. Fraud transactions account for 0.01–0.1% of total volume, production defects 0.5–3%. With such ratios, a naive “all normal” classifier gives 99.9% accuracy but recall for the anomalous class near zero. Supervised models are powerless.
Second: “normality” is always contextual. A login at 3 AM may be normal for a night‑shift user but suspicious for a day‑worker. Bearing vibration at 2.3 mm/s depends on operating mode and machine age. So we embed context via feature engineering and time windows.
Third: quality assessment without ground truth. No standard test set — AUC‑ROC is possible only if a few labeled examples exist. For fully unlabeled data, only domain expert validation and indirect metrics work.
How to Distinguish an Anomaly from Noise in Real Time?
With adaptive thresholds and continuous monitoring of model statistics. In the case section we show how.
| Method |
Data Type |
Training Speed |
Typical Application |
| Isolation Forest |
Tabular, categorical |
High |
Baseline for initial hypotheses |
| Autoencoder |
Images, time series, logs |
Medium |
Unstructured data |
| LSTM-AE |
Multivariate time series |
Low |
Industrial telemetry |
| PyOD (ensemble) |
Tabular |
High |
Quick comparison of 40+ methods |
Isolation Forest is the standard baseline for tabular data. Idea: anomalies are isolated faster by random partitioning of the feature space. Works well at contamination=0.01–0.1, robust to feature scale, no normalization required. Implementation in sklearn.ensemble.IsolationForest.
Typical mistake: setting contamination='auto' without understanding the data. Auto mode assumes a threshold of -0.5, which may not match the actual anomaly proportion. Better: estimate expected anomaly percentage through domain knowledge and set it explicitly. We guarantee contamination tuning for your case.
PyOD (Python Outlier Detection) is a library with 40+ algorithms under a unified API — OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Useful for quickly comparing methods on the same data.
Autoencoders are the main method for unstructured data (time series, images, logs). Train the network to reconstruct normal data; anomalies yield high reconstruction error. Anomaly threshold is the 95th or 99th percentile of error on a validation set of normal data.
Practical problem with autoencoders: overfitting on “normal” patterns that are still rare. If the training set contains even a few anomalies, the model may learn to reconstruct them well. Solution: thorough cleaning of training data or using a Variational Autoencoder (VAE), which generalizes better.
LSTM‑AE for time series captures temporal dependencies better than a regular AE. Especially effective for multivariate time series (10+ sensors simultaneously). Implementation via PyTorch, training with MSELoss on sliding windows.
In Detail: Anomaly Detection in Industrial Time Series
Problem: vibration sensors on 12 pumps at a chemical plant, 6 sensors per pump, frequency 100 Hz. Need to warn of impending failure 4–24 hours in advance.
Solution architecture: raw data → feature extraction (RMS, kurtosis, peak factor, FFT amplitudes at resonant frequencies) → normalization by 24‑hour sliding window → LSTM‑AE → reconstruction error → threshold logic + alerting.
LSTM window size: 60 seconds (6000 points at 100 Hz). Too small a window misses slow patterns, too large loses sensitivity to rapid changes.
Anomaly threshold: not fixed, but adaptive. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). As normal state drifts (planned wear), the threshold adapts, avoiding false positives.
Result over a 6‑month pilot: detected 4 out of 5 real pre‑failure conditions (recall 0.8), with 2 false alarms over 6 months (precision 0.67). Before implementation: 3 unplanned shutdowns. After implementation: cost savings verified in the pilot report.
What Specifics Does Fraud Detection Face?
Financial transactions have several features that complicate detection:
- Concept drift: fraud patterns change faster than normal behavior. A model trained six months ago becomes obsolete.
- Adversarial adaptation: advanced fraudsters adapt — making transactions resemble normal ones.
- Temporal dependency: a series of normal transactions followed by one unusual transfer is a sequence anomaly, not a single point.
Practical stack for fraud detection: LightGBM with SMOTE oversampling for the supervised part (known fraud cases) + Isolation Forest for unsupervised (new patterns). Both signals combined in an ensemble; final decision via thresholds tuned for acceptable FPR (0.1–1% of transactions sent to manual review).
How to Evaluate Quality Without Labels?
When ground truth is absent, we evaluate using:
- Synthetic anomaly injection: add artificial anomalies (spike, level shift, point outlier) and check if the model detects them.
- Expert validation: random sample of top‑K anomalies → expert review → precision.
- Business metric: did the number of missed incidents / false alarms decrease after deployment?
Technical detail: the adaptive threshold is computed as mean(errors) + k * std(errors) on a 7‑day sliding window. Coefficient k is tuned on a validation set with synthetic anomalies to achieve FPR < 0.1%. When features drift, the window automatically shifts.
Process
- Interview with domain experts — understand what “normality” means and what incidents have occurred.
- EDA and data preparation — cleaning, feature creation, time windows.
- Baseline (Isolation Forest) — fast validation on known incidents.
- Model selection and customization — Autoencoder / LSTM‑AE / ensemble.
- Training, validation with synthetic anomalies.
- Deployment to production — pipeline on Kafka + Flink / Airflow, alerting to Telegram/Slack, drift monitoring.
- Post‑deployment support — monitor model metrics, update thresholds.
What's Included
- Audit of current data and processes
- Development and training of models (Isolation Forest / Autoencoder / LSTM‑AE / ensemble)
- Configuration of adaptive thresholds and alerting
- Anomaly monitoring dashboard (Grafana / Streamlit)
- Model card and pipeline documentation
- Training for your team (2–3 sessions)
- 3‑month warranty support
Timeline: baseline system with one method — 2–4 weeks. Production system with adaptive thresholds, alerting, and monitoring — 2–5 months. Pricing is calculated individually for your case.
Our team has 8+ years of experience in industrial analytics and 15+ successful projects in anomaly detection for telemetry, finance, and IT monitoring. Get a consultation — we’ll tell you how to solve your problem. Contact us to discuss your data and receive a preliminary architecture proposal.