Restoring saved TensorFlow model to evaluate on test set
ML System Design practice on Codemia
Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.
Introduction
Evaluating on a test set is only useful if the restored model behaves exactly like the model that was trained. In TensorFlow that usually means loading the saved model, rebuilding the same input pipeline, and running evaluation without accidentally changing preprocessing or metric configuration.
Load the Saved Model Correctly
If the model was saved with Keras, the simplest path is tf.keras.models.load_model. A full saved model contains the architecture, weights, optimizer state, and compile configuration, so evaluation can often happen immediately after loading.
This works well when the model was saved with model.save(...). If the model contains custom layers, losses, or metrics, pass them through custom_objects during loading so TensorFlow can rebuild the graph.
Reuse the Same Test Input Pipeline
Loading the model is only half of the job. The test set must go through the same preprocessing used during training. If training normalized images to the range 0..1, tokenized text in a specific vocabulary, or one-hot encoded labels, the evaluation code must do the same.
Using tf.data keeps that logic explicit and reproducible:
The return_dict=True option is useful because it ties each metric value to its metric name. That matters when a model tracks more than just loss and accuracy.
If You Only Saved Weights
Some projects save checkpoints with model.save_weights(...) instead of a full model. In that case TensorFlow cannot infer the architecture for you. You must rebuild the model in code, compile it with the same loss and metrics, and then restore the weights.
This pattern is common in research code, but it is more fragile because the architecture and compile settings now live in two places.
Common Pitfalls
The most common failure is evaluating with different preprocessing than training. A model can look broken when the real problem is that the test features were not scaled, tokenized, padded, or ordered the same way.
Another frequent issue is loading weights into a model definition that has drifted. Renaming layers, changing input shape, or changing output units after training will cause load failures or, worse, silently wrong expectations about the restored model.
Custom objects are another trap. If the saved model used a custom layer, metric, or loss and you do not register it with custom_objects, loading will fail. Keep those definitions in importable modules instead of notebook cells.
Finally, be careful when interpreting metrics after load_weights. If you did not call compile, Keras has no loss or metrics configured for evaluation. Prediction can still work, but model.evaluate will not behave as expected until the model is compiled.
Summary
- Prefer
tf.keras.models.load_modelwhen you saved the full Keras model. - Recreate the exact preprocessing pipeline before running test evaluation.
- Use
return_dict=Trueto make metric output easier to read and less error-prone. - If you only saved weights, rebuild and compile the model before calling
evaluate. - Treat custom layers, metrics, and losses as part of the saved model contract.
Related reading
- Restoring TensorFlow model
- Results not reproducible with Keras and TensorFlow in Python
- Resume Training tf.keras Tensorboard
- Resume Training tf.keras Tensorboard
- Result of GridSearchCV as table
- result of rpart is a root, but data shows Information Gain
- Rethrowing exceptions in Java without losing the stack trace
- Retrieve list of tasks in a queue in Celery

DSA Fundamentals
Master algorithmic patterns and data structures through hands-on LeetCode-style problems - from arrays and hashing to dynamic programming and advanced graphs.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
ML System Design practice on Codemia
Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.