Road accident prediction with ML: where models break
Road accidents are a rare event, and this is the first thing that breaks the problem setup. A segment records only a few incidents per year, while the share of accident trips is fractions of a percent of total traffic.
A model that always answers “calm” is correct in 95% of cases: the metric looks excellent, but the output is garbage — such a forecast does not distinguish a dangerous intersection from a safe one.
The second trap is feature leakage from the future. The training sample quietly includes fields known only after an incident: crew arrival time, formal report, injury severity.
During training, quality is almost perfect; in operation, it is random guessing, because this data does not yet exist at prediction time.
The third cause is a biased and imbalanced sample. Accidents are recorded where cameras are installed and patrols are on duty, so the model learns enforcement density, not risk.
Aggregation by city blocks and administrative districts finishes the job: accident hotspots are blurred, and an intersection with a concentration of accidents hides inside a large polygon.
We segment areas by road geometry — boundaries are taken from OpenStreetMap — and calculate risk at intersections and road segments separately.
We explain how this is addressed: time-based cross-validation instead of random, balancing the rare class, auditing features for availability at prediction time, and tying the forecast to real hotspots rather than to a grid.
What changes after implementing accident risk forecasting
After implementing accident risk forecasting, hotspot management stops being reactive.
The model recalculates risk by segment regularly and produces a list of places where incident concentration will increase in the coming weeks: engineers receive not a report about the past but a queue of preventive tasks.
The share of confirmed hotspots in this list remains at a level where most dispatches go to genuinely dangerous points.
Incident response time decreases: an anomaly signal reaches dispatch at the moment of detection, not after shift review, so crews reach the site before the situation repeats at the same intersection or exit ramp.
Accumulated accident reduction comes specifically from the speed of closing repeat incidents, not a one-off dispatch.
We cut off false positives with a confidence threshold and context checks — weather, time of day, roadworks, traffic profile. False calls decrease, the duty shift stops checking noise, and trust in the system grows faster than formal accuracy.
Manual review of records is replaced by a ready set of labeled episodes: an analyst tests hypotheses instead of scrolling through a shift’s archive.
The freed-up time goes to planning repairs — hotspot forecasts are tied to seasonality and the work cycle, so markings, lighting, and pavement are placed where they will remove risk. The effect of each repair becomes measurable on the same segment.
Options for building a forecasting model: batch, streaming, hybrid
The choice of mode is determined by two things: where the data comes from and what horizon needs to be influenced.
Batch computation recalculates the risk matrix on a schedule from a historical snapshot; streaming forecasting updates the estimate as telemetry arrives; the hybrid scheme combines both loops.
The difference between them is in forecast update frequency and infrastructure requirements: the shorter the reaction window, the more data must be available continuously rather than at launch time.
We compare options by data source composition and by the delay the decision-making process itself allows.
| Option | When it fits | Limitations |
|---|---|---|
| Batch computation | Disparate sources: incident history, weather archive, road passports. Forecast for a day and beyond, route and repair planning | Estimate becomes outdated between runs; a sharp risk spike is visible with delay |
| Streaming forecast | Telemetry from vehicles and city cameras, reaction needed within a shift | Depends on channel stability; if data disappears, the estimate degrades, backup source needed |
| Hybrid scheme | Baseline risk model on a schedule plus a fast correction layer for fresh events | More expensive to maintain: two loops, feature alignment, and a shared point of failure at the junction |
In practice, they start with the batch loop: it is verifiable on history and does not require a continuous stream.
A hybrid scheme becomes justified when a stable telemetry channel appears and there is a requirement to react faster than within a day — then the baseline model sets the background and the streaming layer corrects it based on actual events.
We make the transition so both loops can run independently: if the data stream disappears, the system stays on batch estimates instead of returning an empty forecast.
Stages of developing an accident risk forecasting system
The stages are arranged iteratively: road accident prediction relies on the verified result of the previous step, not on assumptions about the data.
We start with a source audit and finish with handover of the system to operation together with the client’s team — the output is a working forecast and people who understand how to read and update it.
- Data audit. We bring together road accident and hard-braking history, vehicle telemetry, weather series, and repair data. We check completeness, coordinate discrepancies, and gaps: otherwise the model learns from record-keeping defects.
- Feature scheme. We calculate features at the segment and time-window level: traffic intensity, speed variance, share of hard braking, visibility, pavement condition, interchange type. Every feature must be available at prediction time, not only in historical exports.
- Model training and validation. We validate over time: train on past periods, test on subsequent ones. We look at recall at a given precision, false positive rate, and stability across seasons.
- Pilot segment. We launch forecasting on a limited set of segments with different traffic patterns, compare with actuals, and tune alert thresholds.
- Backtesting on historical snapshots. We run the model across past seasons: how many events would have been caught in advance and how many signals turned out false.
- Handover to operation. We deploy the service, set up quality monitoring and a retraining procedure, and train the team to read the forecast and update data.
Delivery scope: model artifacts, data schemas, procedures
We hand over not a set of files but a working system: each item has an owner on the client side and a document by which it can be checked and reproduced. Below is what remains with you after acceptance.
- Trained model artifacts. Weights, preprocessing steps, and alert thresholds in a form that deploys on your infrastructure without ours, plus a reproducible training scenario.
- Feature description. For each: source, calculation formula, aggregation window, acceptable range, and behavior when missing — so the logic is not reconstructed from code.
- Data flow diagram. Where telemetry, weather, and road conditions come from, where raw and aggregated layers are stored, who reads them and with what rights.
- Retraining procedure. Triggers — calendar, quality drop, fleet or route network change; the procedure for validation on a holdout sample and conditions under which a version does not go into operation.
- Operator instructions. How to read the risk estimate, which thresholds lead to a notification, how to record false positives and pass them to retraining.
- Audit log. Version history, metrics at each check, who and when approved the release — with the ability to roll back to a previous version.
The package is designed so that your team will maintain the system further: everything done during the project is documented so it can be handed over and checked without us.
Describe the task — we will come back with an estimate and a plan in which the delivery scope is fixed in advance.
Case study: forecasting accident hotspots on an urban network — numbers before and after
Before implementation, the accident hotspot summary was compiled once a quarter: an engineer manually merged exports from different agencies, addresses were matched by eye, and some records were lost to duplicates and typos.
By the time it was handed to road crews, the list was outdated, and repair decisions were made based on last year’s picture. We started the model not with an algorithm but with analyzing this data.
Hotspots were determined according to the Methodology for classifying accident hotspots, so the forecast spoke the client’s language.
We separately fixed the mapping: 18% of records did not map to the road graph — exit ramps, interchanges, bridges, and courtyard driveways were described by address rather than by segment.
Duplicates were collapsed by a spatiotemporal window, and features were rebuilt per segment: intensity, traffic pattern, lighting, markings, repair history, and seasonality. Without this, any forecast would capture noise.
After the rebuild, the forecast is recalculated daily rather than quarterly. The share of confirmed hotspots in the top twenty segments grew from 31% to 69%, hotspot detection recall rose from 62% to 88%, and false positives became one in eight instead of one in three. Analyzing exactly where the model erred takes hours, not weeks.
What disappeared from the failure classes: “sticking” to historical hotspots — after repair or a change in traffic pattern, a segment no longer stays in the top; mapping errors at multi-level interchanges; seasonal gaps, when winter accident rates were underestimated because of summer statistics.
Residual risk is new traffic patterns for which there is not a single record: we mark such segments as an uncertainty zone and show them separately.
What to do if a video analytics system is already deployed
If video analytics is already deployed, in most cases the loop is not rebuilt but extended with a forecasting layer.
The key question is whether the current system separates detection from storage: if camera events are recorded with a timestamp, frame zone, and track ID, they directly become input for the road accident prediction model. Only what video does not provide has to be rebuilt — trajectory dynamics and external factors.
Cameras and their calibration, ready object detectors, the event stream, and historical labeling are reused — this saves months of collecting the initial sample.
The feature layer is built anew: speed and acceleration by track, intervals between participants, congestion, and weather-related friction. Integration with sensors is also connected here — traffic light phases, weather stations, road controllers. We exchange models between loops via ONNX so as not to retrain what already works.
| Option | When it fits | Limitations |
|---|---|---|
| Upgrading the existing loop | Detectors and event storage already send data to a common bus | The forecasting model falls into the same release cycle, increasing the risk of regressions in video analytics |
| Separate forecasting layer above the loop | A horizon in minutes and its own quality metrics are needed | Requires time synchronization and end-to-end event tracing between systems |
| Hybrid: shared event stream plus forecasting service | Multiple sites and different camera vendors | More expensive to maintain: two data schemas, two monitoring loops |
The system layers are the same either way: event collection and normalization, features, model, output, and reconciliation with actual incidents.
Layering provides the main benefit — the forecasting layer can be disabled or retrained without stopping video analytics and without losing the accumulated existing infrastructure.
Technical concerns: data, false positives, privacy
Objections to predicting accident situations almost always concern not the choice of algorithm but data and operating mode.
Labeling arrives incomplete: confirmed cases are few, some incidents are closed without a report, and segment features change by season — in winter the same road geometry produces completely different dynamics than in summer.
Therefore we check data quality before training: we calculate the share of missed labels, look at distribution shift between periods, and record which features the model uses to make a decision.
Below is a breakdown of concerns that most often come up during assessment: cold start, false alarms, overfitting control, and handling personal data.
What to do if labeling is incomplete?
We train on weak labels: confirmed incidents as the positive class, everything else as background with reduced weight.
We additionally check the share of missed detections on a holdout period and calibrate the threshold so the model does not output confidence where data is insufficient.
How does the model work during cold start while there is no history of its own?
For the first weeks, the system runs in shadow mode: predictions are calculated but no one is notified. We rely on knowledge transfer from similar segments and physical features — traffic speed, braking distance, density.
As confirmed cases accumulate, the transfer weight decreases, and the model switches to the segment’s own statistics.
How is the number of false positives reduced?
We set the threshold not as a single value but based on the cost of error: for a dangerous intersection, it is better to miss fewer events; for a calm segment, not to disturb services unnecessarily.
Notifications are reviewed by the duty officer, and feedback labeling returns to training, so the share of false alarms decreases from iteration to iteration.
How do you control model overfitting?
Validation is time-based, not random split: we train on past periods and test on subsequent ones. This immediately shows whether the model learned a pattern or memorized specific incidents.
We additionally monitor drift in input features — when there is a discrepancy with the training distribution, a retraining signal is triggered.
What about personal data?
At the input, data is anonymized: vehicle and person identifiers do not enter the features. The model works with aggregates by segment and time window.
Access to raw records is role-restricted, requests are logged, and the retention period is set by policy and enforced automatically rather than manually.
Let’s discuss the task: what data is available and what forecast is needed
To make the task assessment substantive rather than “by eye,” a minimal set of inputs is needed: the more detailed the client’s source data, the more accurate the scope of work and pilot timeline.
It is not necessary to send everything at once — we will start with what already exists and clarify the rest on a call.
- An export of historical events: where and when road accidents and emergency situations occurred, and how each record is described in your system.
- A scheme of segments and routes: road geometry, intersections, and mapping of incidents to coordinates.
- Data on traffic flow and conditions: traffic intensity, time of day, weather, seasonality, pavement condition.
- A list of sources: which sensors, cameras, or external services already provide data and at what frequency.
- Data restrictions: requirements for anonymization, access control, and retention.
- Target forecast: prediction horizon (next hours or a day) and unit — segment, time, risk type.
- Integration point: who will receive the warning and in what interface, and what they do with it next.
On the first call, we will align on the forecast horizon and unit, discuss the quality metric, and check whether there is enough history for road accident prediction using machine learning or whether some data will have to be collected.
Based on the results, we will come back with an implementation plan: stages, scope of work, what will be needed on your side, pilot timeline, and the criteria by which we will consider it successful.
Describe the task in free form and attach what you have — we will come back with an estimate and a plan.
