Since the RockRecommender API article, the project has an endpoint that receives a like or dislike on a recommended song and saves it to MongoDB. That data exists, it gets collected on every use. But when it's time to train the model, the process described in the ML.NET training article still uses only a synthetic interaction generator. The real feedback sits in the collection, never making its way back into the model. This series closes that gap: the training pipeline learns to look at Mongo, decide on its own whether there's already enough real data, train with the right source, and only replace the production model when the new one is actually better than the current one.

Where the feedback already lives

Feedback already lands, the moment it happens, inside MongoDB, in the same collection the Api has been writing to since the RockRecommender API article. To know how much real data exists and use it for training, the pipeline just needs to query that collection directly, whenever it needs to.

Who decides when it's time to train

The retraining trigger isn't the volume of feedback coming in, it's time. A scheduled job wakes up at a configurable interval, asks "is it already worth training again?" and acts on the answer. That avoids the other extreme, retraining on every single like, burning processing on a change that doesn't move the model in any noticeable way.

The full cycle, step by step

This is the design the next articles will build, piece by piece:

1. The job wakes up at the configured interval.
2. It counts how many real interactions exist in Mongo and compares that against the volume the synthetic generator would produce.
3. If real is still smaller, training keeps using synthetic data, like it always has.
4. If real is already bigger, training switches to using only the real data.
5. The new model is evaluated with the same metrics from the evaluation article, Precision@K, Recall@K and NDCG.
6. Those metrics are compared against the model that's active today.
7. If the new one is better, it gets promoted. If not, the active model stays the same.
8. The Api notices the swap on its own and reloads the model in memory, with no restart needed.

What's next

The next article covers the first piece: how the pipeline reads Mongo directly and decides, on its own, between synthetic and real data.

Sources

• Official ML.NET documentation on evaluating recommendation models
• Official MongoDB driver documentation for .NET