Defining prediction API - some tips

The end result of a requirement gathering exercise for AI is often the end point definition for the desired prediction rule. Defining the API end point has multiple dimensions to it. In this micro blog, lets cover one. In my opinion, the first rule is that while you define end point based on the known requirement, try and broad base it to multiple consumption points. Your requirement might need an end point that is available in offline batch mode, but there might be other consumption points needing the same prediction in real time. Knowing this upfront while defining the end point can guide data science and engineering teams in defining their pipeline and code accordingly. Other aspects are also revealed as you think about multiple consumption points. For example, may be some consumption points need top three predictions and not just one. May be, the measure of success (accuracy, recall, etc.) might be different for different consumption points for the same API. Another scenario could be that parts of the requirement, not whole, are common to multiple consumption points. In such case, it might make sense to break the API into multiple APIs. Knowing different points of consumption would also give you an idea of how many input fields are available at various points, thus helping define inputs to the end point correctly. I have also noticed the threshold for the same success measure (e.g. accuracy) being different for the same API across various applications/ workflows where it is called. Go broader in terms of applications consuming your API, and you will be one step closer towards building practical AI. #abhayPracticalAI #artificialintelligence #machinelearning #ai