Grad-CAM explainability output
Screenshot from the Chest X-Ray MLOps project showing the model interface with a Grad-CAM visualization used to inspect which image regions influenced the prediction.
Medical Computer Vision · MLOpsDeployed
Chest X-Ray MLOps System
Analyze chest X-rays for abnormalities through a deployable medical computer vision workflow.
DenseNet121Grad-CAMFastAPI APIStreamlit UIDockerizedAzure delivery pathGitHub Actions
Local project explainer
Ask about this system
A local, predefined assistant for the documented details in Chest X-Ray MLOps System.
Problem
What this project had to solve
Most medical-CV repos stop at notebook inference. This project turns chest X-ray abnormality detection into a system with a model service, a usable front end, explainability output, and a repeatable deployment path.
Role / contribution
What I owned in the system
Project author responsible for the inference service, Grad-CAM integration, containerization strategy, frontend/backend separation, and the CI/CD path described in the repository.
Technical implementation
How the system is built
DenseNet121 runs behind a FastAPI service that handles image upload, preprocessing, prediction, and Grad-CAM generation.
A Streamlit interface acts as the user-facing layer so the app can expose predictions and visual explanations without coupling UI concerns to the backend service.
The runtime is containerized with Docker, and GitHub Actions builds and deploys the system through the repository's automated delivery path.
Architecture flow
System flow from input to output
Step 01
Image upload
What happens
A user submits a chest X-ray through the Streamlit interface.
Why it matters
This is the entry point that turns the model into a usable product flow instead of a notebook-only inference script.
Related tools
Streamlit
Engineering decisions
Tradeoffs that shaped the build
Separate frontend and backend
Decoupling the Streamlit UI from the FastAPI service keeps inference and presentation concerns independent.
Keep explainability in the response path
Grad-CAM is treated as part of the product behavior rather than an optional offline analysis step.
Automate deployment instead of shipping a notebook
CI/CD and Docker make the repo a deployable system rather than a one-off experiment.
Stack
Core tools and system layers
PyTorchDenseNet121FastAPIStreamlitDockerAzureGitHub ActionsGrad-CAM
What I would improve next
Next technical upgrades
- Add stronger smoke tests around model artifact changes and image validation failure cases.
- Expand operational monitoring around prediction latency and malformed upload behavior.
- Document rollback and model-version promotion more explicitly.
Evidence
Grounded project proof