Evaluating an AI’s understanding of radio requires a rigorous framework. This framework was established to compare different segmentation methods (LLM vs. Machine Learning vs. Audio).
Before performance analysis, each detection model must produce a results file in a standardized JSON format. This file serves as an interface contract between the AI engines and the evaluator. It lists detected chronicles with the following properties:
[
{
"label": "The 7am News",
"start": 120.5, // Start of the chronicle (in seconds)
"end": 240.0, // End of the chronicle (in seconds)
"detected_at": 135.2, // Precise moment of AI confirmation
"confidence": 0.95 // Model confidence index
}
]
The evaluator then compares this file to a Ground Truth, containing actual timestamps validated by a human, to calculate precision and latency scores.
Evaluating an algorithm is not limited to simple chronicle detection. Two critical dimensions are measured:
The IoU (Intersection over Union) metric is used. It mathematically measures the overlap between the AI’s prediction and the “Ground Truth” established by a human.

For a live application, responsiveness is crucial. The delay between the actual start of the chronicle and the emission of the confirmation notification by the AI is therefore measured.
Models are ranked using a weighted formula:
Bonus points are awarded for a reaction in less than 5 seconds, while a delay exceeding 60 seconds cancels the “latency” component of the score.
An “Agnostic” option allows checking if the system detects a change on air, even if the chronicle name identification is wrong. A detection is validated if it temporally corresponds to a real chronicle, regardless of its label. This mode is particularly suitable for testing silence detection algorithms or generic jingles.
A visual diagnostic module allows visualizing the performance of radio chronicle detection models.
It transforms complex data files (JSON/TXT) into a timeline, allowing at-a-glance comparison of the actual location of chronicles versus model detections.

Using this testbed has allowed observing certain trade-offs:
This framework allows guiding GroovyMorning development through data, by selecting the most suitable model for each use case.