Hermione grew from repeated problems with inconsistent code, manual work, weak testing, and the gap between experiments and production.
2
The open-source Python framework gives ML projects a shared structure for data access, preprocessing, visualization, training, testing, and model handling.
3
Hermione uses MLflow to track experiments, metrics, artifacts, and models while leaving teams free to adapt the project structure to their needs.
Summary
Neylson Crepalde describes the problems A3Data saw when moving machine learning work from an individual or academic setting into professional teams. Different Python versions, libraries, code styles, and undocumented project knowledge made handoffs difficult. One deployment effort took three months to understand and never reached production. Manual infrastructure work, missing tests, poor reproducibility, and the gap between notebook experiments and production code created more failure points. Hermione grew from the team's attempts to address these problems. It provides a Python project structure with defined places for data sources, preprocessing, visualizations, models, tests, configuration, and outputs. Its model wrapper keeps the model, preprocessing object, metrics, and input columns together. Hermione also integrates with MLflow for experiment tracking and model logging. The demo shows project creation, a Titanic example, unit tests, training several scikit-learn models, and comparison of MLflow runs. Neylson is candid that Hermione is young and still needs community feedback.
Hermione came from repeated failures in team-based ML projects
Neylson says A3Data repeatedly saw problems when moving from casual machine learning work to a professional environment. Teams used different Python versions, libraries, and coding styles. Projects often depended on one person, so a departure, illness, or vacation could leave others unable to continue. Hermione grew from the team's mistakes and the tools they built to make work more automated and consistent. The goal was to package those lessons into a Python library that could help teams pick up projects where someone else stopped.
Undocumented project inputs can make deployment take months
Neylson describes a team that received an almost-ready model and had to put it into production. The handoff included notebooks, code, configuration files, and many CSV files, but no database information. Understanding the project and debugging it took three months, and the model never reached production. A bug near production led the team back into the ETL process, which exposed another problem when the code that worked on one machine failed on the server. The example shows how inconsistent project conventions turn a handoff into a reconstruction effort.
Testing and reproducibility need to be part of data science work
Neylson says many data science teams do not test their code because people enter the field from backgrounds such as economics, mathematics, sociology, and music rather than software engineering. Without automated tests, teams discover one failure while preparing a project for production, fix it, then find another. He also describes manual cloud setup, artifacts sent by email, code that cannot be reproduced or reused, and processes that must be rebuilt when something goes wrong. Shared conventions and tests make it easier to find failures earlier and debug them.
The framework connects experimentation with production code
Hermione gives teams a structure for building code that can be reused and unit tested. It includes data analysis utilities and uses MLflow to track experiments, metrics, and artifacts. Neylson explains that the framework is designed to be flexible because teams may choose different tools. A structure that forces everyone to adapt to it would make work harder, so Hermione aims to let users reshape it and add their own integrations. He describes Hermione as a young tool that still needs testing, contributions, and feedback.
Hermione organizes an ML project around explicit modules
The framework has a data source base class with spreadsheet and database implementations. Preprocessing has its own class, with existing normalization and text vectorization components. Visualization contains reusable methods for regression analysis, plots, and residual checks. Training is assembled through a train script and trainer classes, with examples for scikit-learn and room for other algorithms. A model wrapper stores the trained model, preprocessing object, metrics from test runs, and the columns used to build the model. This helps avoid errors caused by different columns or column ordering.
The model wrapper can work with MLflow without hiding its behavior
Neylson says Hermione's model wrapper is compatible with the MLflow API. Users can treat the wrapper as an MLflow model, log it, and use MLflow deployment options. Hermione does not automatically perform every logging step, so the project code still needs to specify what is logged. In the demo, the training script sets the experiment name, logs algorithms and metrics, and logs the model to an MLflow server running in AWS. The framework can also package a model in a Docker container for deployment to a cloud platform.
The generated project structure makes ownership and handoffs clearer
Creating a project with Hermione generates folders for raw and processed data, outputs, source code, configuration, tests, notebooks, and ML components. The source directory contains the main train script and helper functions. The configuration includes items such as the project name and paths. The ML directory contains data source, preprocessing, visualization, model, trainer, wrapper, and metrics components. Hermione also creates requirements, a README, and a gitignore file. In the demo, a generated Titanic project is filled in with spreadsheet loading, preprocessing, category encoding, training, and tests.
The demo uses tests and MLflow runs to compare models
The Titanic example includes tests for reading data, cleaning it, checking category encoding, and confirming that the project is correctly built. Neylson runs the tests with pytest and gets four passing tests, along with dependency deprecation warnings. The training script reads the data, performs preprocessing, trains a random forest classifier, gradient boosting, and logistic regression, then logs the runs and metrics to MLflow. The MLflow interface allows the team to compare runs and register a model. Neylson says he prefers metrics such as F1 or AUC over accuracy for classification.
"The main question is not that if it's gonna fail, it's where it's gonna fail, when is it going to fail and when it does am I ready to deal with it?"Neylson Crepalde25:43
Who should watch
You maintain ML projects where the original author is the only person who knows how the data, notebooks, and deployment code fit together.
Your team is moving models from experimentation into production and needs a project layout with tests, configuration, and reusable components.
You want an open-source structure built around MLflow, while keeping the option to adapt the framework or add your own integrations.
