During the last months, Yields Team has been working hard to improve Chiron. Working remote or the high summer temperatures did not stop them to release a new and big product update. Curious? Scroll down to read more about the new features and enhancements.
New Features
Data set audit trail
As already done for the model objects in a previous release, you will now also be able to see an audit trail for the data set objects. This audit trail shall contain the main events that impacted the state of the data set object since its creation. Each event contains a time, author and hideable description. The same audit trail shall appear in the coming releases for the mapping and stage instance objects. This audit trail allows you to keep track of any modification that may have impacted your validation results.
Stage specifications and instances
The Chiron frontend now makes the distinction between stage specification and stage instance clearer for you. Both concepts appear as distinct menu items on the main page left pane. (see below screenshot) The specification button shall directly lead you inside the JupyterLab directory where all templates are saved. From there, you may inspect existing templates and/or create new ones.
The instance view consists of an inventory of all existing stage instances you have created inside the platform along with their already produced session outputs (reports, trained model, derived data, etc.).
The meta-representation of stage specification has been made more generic so that you may now create many more customized specifications and instances with
- any number of input datasets and/or input model artifacts
- any number of output datasets and/or output model artifacts
- all IO objects being ‘taggable’ (for reference in code) and ‘documentable’ (for future reference)
Finally and in order to ensure results reproducibility, instances code need to be committed before it can be run to produce session results.
Stage instance organization
Based on the feedback of several early adopters we have reviewed the way we organize stage instances. These instances are now gathered into the new ‘Instance’ view (see previous ‘Stage specifications and instances’ section) independently of their purpose(s): model training, data derivation, metrics production, metric monitoring, etc. It is now up to you to organize them as you wish, instead of relying on some arbitrary Yields choice.
To do so, a folder tree organization has been implemented. It allows you to:
- create or delete folders and subfolders
- move instances from one folder location to another
- share folder with other teams
- have both instances and subfolders under any given folder
Session interactive replay
This new feature allows you to open (black-highlighted button in below screenshot) for any already existing session report an interactive JupyterLab environment where you will be able to reproduce interactively and at will the exact same results in order to investigate them further with additional intermediary/complementary code.
To do so, the interactive environment is provided with the exact same context as the one that was used to generate the original output in the first place.
Session report edition
The session output service has been improved to allow you to adapt the documentation (purple-highlighted button in below screenshot) to the latest produced results before exporting the report under HTML or PDF format, with or without code.
Note that here again, and for the same reproducibility reason as above for instance run, the adapted text needs to be committed before the corresponding report can be downloaded from the platform.
Enhancements
Audit trail states detailed view
The details view of each audit trail event has been made more dynamic to ease your browsing through the possibly very long audit trail. You are now able to expand or collapse details as you wish so.
Dataset derivation organization
Along the same threads or work as the above mentioned ‘Stage instance organization’ and ‘Stage specifications and instances’ sections, we now make a clearer distinction between the derived data set and the instance that produces and/or augments it.
A single link (black-highlighted button in below screenshot) is now made between the derived data set that you may still find in the the ‘Data’ section and the stage instance that produces it. This stage instance now lies under the new ‘Instance’ section along with all other instances, whatever their purpose(s).
Data model mapping management
The data model mapping object represents the data signature of our model objects. Its behaviour has been evolved to help you manage it more efficiently. Most notably,
- inference rules for continuous and categorical dimensions have been improved
- warning and error messages have been made more explicit when defining an invalid mapping and/or trying to attach an invalid data set to an existing mapping
- in order to ensure further results reproducibility, you may now decide to freeze the mapping when registering an instance that has been defined on it (see below screenshot). Once a mapping is frozen, you cannot modify it anymore in the mapping details view. You can only inspect it
UI/UX various
In order to keep improving UI/UX experience,
- several fields were renamed in order to align with our documentation and external posts that you may have already read
- the default was added when you are asked to make a choice
- links to our platform documentation have been added
Conclusion
This is it for now! If you want to share any feedback with us, contact us.
