The gap between a notebook that works and a model in production

Why we built it

Every machine learning team we have worked with has the same story. A model reaches 0.91 AUC in a notebook on a Thursday. Getting it to make real predictions takes months. By the time it does, nobody can reproduce the training run that hit 0.91: the hyperparameters were changed in place, the training data was a CSV that has since been overwritten, and the random seed was never set. Six months later the model is quietly less accurate than the day it launched, because the customers it scores no longer look like the ones it trained on, and nobody has checked.

None of this is a modelling problem. The gradient boosting worked. What failed was everything around it: remembering what was trained on what, agreeing which candidate was actually best on held-out data, and measuring accuracy after deployment. Teams try to fix that by bolting on separate tools for logging metrics, storing approved models and hosting prediction APIs, and then spend their time keeping those tools in sync instead of improving models.

We think the fix is to record the machine learning work as it happens, in the notebook where it happens. Every training run should carry its hyperparameters, its training data version, its validation metrics and its code with it, from the first experiment to the prediction API and back.

What we believe

• Recording a training run should take no effort. If reproducibility depends on remembering to log the learning rate, it will not happen. maclnote reads the hyperparameters from the model object and the metrics from your evaluation code, so nothing is forgotten.
• Every prediction should be traceable to its training data. A model, the run that produced it, the notebook and commit, and the exact version of the training set. Not written up afterwards, but recorded as the work is done.
• Notebooks are where machine learning gets done. Exploring features, trying model families, reading a learning curve. The problem is what happens after the notebook, and we fix that without taking the notebook away.
• You own your data and your models. Our cloud is the fast start. Running maclnote in your own cloud account or data centre is one deployment option away, and everything exports in standard formats.
• Accuracy after deployment matters more than accuracy in the notebook. Drift alerts, accuracy measured against real labels, and a rollback to the previous model version are what make a model something a business can depend on.

How we work with customers

Every engagement starts the same way: bring us a notebook. In a 30-minute call we open it in maclnote, train the model with the run recorded, compare it with a second configuration, and deploy the better one as a prediction API. If the product does not work for your stack, you find out before you have spent anything. Trials run in a workspace we set up for you, with your data connections, and convert to a plan or export cleanly when they end.

Enterprise customers get a named solutions engineer who has run production ML before and stays with the account after the contract is signed.

Get in touch

The contact form reaches the team directly. Whether it is a demo, a pricing question, a security questionnaire or a partnership idea, you will hear back from a person within one business day.