I think we should keep the getting started guide as concise as possible and with a limited amount of info.

IMO model persistence is more of a next step, sort of like model inspection, and thus doesn't really belong here.

It also doesn't really fit into the premise of the guide:

The purpose of this guide is to illustrate some of the main features that scikit-learn provides

So I'd suggest to write this instead in the UG.

I understand your point: I have removed model persistence from the getting started guide.
But I need a way to give more visibility to model persistence, which is not a subsection of the model selection and evaluation section, but the final step of the process before deployment in production (if I understand correctly this comment). Let me know if you agree more with 2d2581d. Thanks.

Also:

to represent data mining and models

I'm not sure what "to represent data mining" means?

Is that more understandable now? Thanks.

I am thinking that we could be explicit that the model will only use the prediction part without the possibility to be refitted once exported.

I have added a note at the beginning of the section: is that ok with you?

Actually it might make more sense to move this note here as you do not have this limitation when using pickle (you can refit the model if you wish as all the hyperparams are shipped in the pickled model).

Sorry, still puzzled about the necessity of retraining using a serialized model ... using the original python script seems a more transparent option to me especially if you look for architecture or environment dependencies...
I've modified the note as you suggested... but still not convinced to move it in the interoperable section....

Actually it might make more sense to move this note here as you do not have this limitation when using pickle (you can refit the model if you wish as all the hyperparams are shipped in the pickled model).

Phrasing "For production and quality control needs... PMML / ONNX would be a better approach than using pickle": I think that most people who use scikit-learn models in production typically deploy pickled models in docker containers. It's perfectly fine as long as you are aware of the limitations of the pickle format, namely treat the pickled model as a piece of executable software (as is typically the rest of the contents of the docker image) rather than a piece of data or self-decribing source code. For organizations that are used to deploying Python and docker in production this is probably the best approach.

To me the pros of using interoperable formats are:

• make it possible to deploy to platforms that do not have Python installed for any reason (e.g. java-oriented sysadmin culture and JVM-centric production & diagnosis tools),
• decouple the trained model from the specific runtime type and version used to train the model.

E.g. some organizations might decide to allow their datascientist to develop models using any technology (e.g. Python, R, spark) but then only deploy PMML or ONNX models on the inference servers of operational reasons.

I've added a line about pickle "containerisation". and reformulate a bit. Your two point are part of the definition of interoperability to me... should I go to this level of detail? Thanks.

Actually I'm not sure this sentence is correct #17644 (comment) As long as the Python version and the versions of dependencies are the same it should work. When it doesn't it could be a bug on our side, particularly given that pickle (+ docker) is still the primary method of deployment.

Also (sentence below) containers are architecture specific. They are a solution to reliable deployments and fixing the environment including the dependencies, but not to architecture portability.

Actually I'm not sure this sentence is correct #17644 (comment) As long as the Python version and the versions of dependencies are the same it should work. When it doesn't it could be a bug on our side, particularly given that pickle (+ docker) is still the primary method of deployment.

I've tried to mitigate the sentence: but the point here is more if scikit-learn developers are willing to guarantee pickle portability than about pickle portability itself.

Also (sentence below) containers are architecture specific. They are a solution to reliable deployments and fixing the environment including the dependencies, but not to architecture portability.

Again, I've tried to mitigate the sentence, but IMO any solution enforcing portability and interoperability is architecture dependent, the goal is to make this dependence invisible to the user. The "pickle + docker" option offers to the user a way to run predictions with a model trained on a different architecture... obviously the producer of the model should provide the right "packaging" to the user.