Page MenuHomePhabricator

Improve Lift Wing documentation
Closed, ResolvedPublic

Description

Our documentation: https://wikitech.wikimedia.org/wiki/Machine_Learning

I made some improvements to our Lift Wing documentation. It was a bit hard to read previously, because pieces were scattered over the different documents and they were not connected to each other. In the past few months, I have been working on different tasks to deploy models to Lift Wing includes deveping production images, configuring pipelines and deployment. I sorted out the process I've learned and figured out to connect everything together.

I hope it is useful for the members (esp. MLE) in the team and people who are interested in our project.

Related Objects

Event Timeline

Thanks a lot for the efforts Aiko, great work!

Before closing, since you brought up the subject, I think that we could take this task one step further - we could involve Miriam / Diego / Isaac and ask to them what they think about the documentation, and what parts are confusing etc.. Based on their suggestions we could then improve the wiki pages. What do you and others think?

achou renamed this task from Improve Lift Wing documentaton to Improve Lift Wing documentation.Sep 9 2022, 3:28 PM

That's a good idea, Luca :)

Hi @Miriam @diego @Isaac @fkaelin @MunizaA @Htriedman!

ML team has been writing the Lift Wing documentation so people can get to know more about it. There're three main pages:

  • LiftWing - Our stack, hosts, components, and current Inference Services on Lift Wing
  • LiftWing/Inference Services - A guide to developing KServe Inference Services and how to configure pipelines
  • LiftWing/Deploy - Introduction to Helm Charts and Helmfile at WMF and a guide to deploying Inference Services to Lift Wing

We'd love to hear what you think about the documentation, and what parts are confusing etc.. so we can further improve it. Thanks a lot! :)

Thanks @achou for putting this together. I can't speak so well to the deployment / tech-stack side of things though I really appreciate the depth you went to in breaking down each component into its different services and connecting up the documentation! I already made some use of this when I was playing around with the outlinks model. The piece that feels missing right now is the proposer/end-user side, but I want to acknowledge that that very likely exists or should exist outside of Wikitech? A start for that might include:

  • How to access a model from stat machines and eventually externally? You gave me great Python code examples with the outlinks model for this and Luca helped me find a few additional config switches that might be necessary for folks depending on their environment (disabling https_proxy; adding internal API to trusted certs list in Python; maybe others?). Would be great to include those somewhere.
  • How to request a model be added (staff and volunteers) and what is needed -- e.g., single model binary, API code for single input -> single output, model card, etc.
  • Good code patterns for model -- you give a little of this in the new service section but I wonder if there is any other guidance around code patterns or libraries to avoid etc. -- e.g., does it matter if it's a single model binary vs. model + separate embeddings? what are acceptable external calls that can be made such as Mediawiki APIs? Does the code have to be Python?

Hi @Isaac, thanks for your suggestions! These suggestions are all valuable. :)

How to access a model from stat machines and eventually externally? ...

That's a good point! I'll move the code examples of how to access model from stat machines and additional config switches to the documentation. About how to access it externally, it needs to wait for API gateway is ready.

How to request a model be added (staff and volunteers) and what is needed -- e.g., single model binary, API code for single input -> single output, model card, etc.

That's something ML team needs to have a discussion. Thanks for mentioning it! I'll keep you updated.

Good code patterns for model -- you give a little of this in the new service section but I wonder if there is any other guidance around code patterns or libraries to avoid etc.

We don't have best code patterns for now, so as we're getting more and more models deployed in Lift Wing, we'll have more experience and will find something is best practice or something to avoid etc. Like now I'm working with Diego and Muniza on a new model, we're using a different approach -- having a separate library for various feature objects and functions that are reusable for other models. I'll add more guidance around code as time goes by.

HI @AikoChou this is wonderful wonderful, thank you so much!

Most of my feedback was included already in Isaac's comments! Just a few more suggestions:

  • In the main Liftwing page, you might want to have an introduction about what LiftWing is and isn't, what information you can find in the page, similar to what you have in the /Deploy page
  • Are there limitations about the types of models you can accept on LiftWing? What are the basic requirements that a model should have, and what are the types of models that cannot run on LiftWing? You might want to add this information in one of these pages, for example in a "Model" section in the Deploy page.

HI @AikoChou this is wonderful wonderful, thank you so much!

Most of my feedback was included already in Isaac's comments! Just a few more suggestions:

  • In the main Liftwing page, you might want to have an introduction about what LiftWing is and isn't, what information you can find in the page, similar to what you have in the /Deploy page
  • Are there limitations about the types of models you can accept on LiftWing? What are the basic requirements that a model should have, and what are the types of models that cannot run on LiftWing? You might want to add this information in one of these pages, for example in a "Model" section in the Deploy page.

@Miriam I tried to update https://wikitech.wikimedia.org/wiki/Machine_Learning/LiftWing following your suggestions, lemme know if it works better now :)

In my opinion the documentation is good enough for the moment, I am inclined to close the task. We'll surely improve it over time based of people's feedback, but for the moment the baseline is good.

Please re-open if you don't feel the same :)

elukey claimed this task.