Prediction end point - how comprehensive should it be?

While defining the prediction rule end point, I have often seen the spec designed such that the data science behind it becomes logic heavy. Most often this is not done intentionally. This happens more because the analyst / business user helping define the end point looks at it purely from a business perspective. Nothing wrong with that. But the dev and business personas should analyze the end point for reusability. For example, if your prediction rule needs a vocabulary builder, it might make sense to build the vocabulary builder as an endpoint separate from that for the prediction rule. That might not only help build a vocabulary that can be consumed by multiple prediction endpoints; but reduce the maintenance cost. Another practice I have seen is to incorporate multiple algorithms in one end point. There definitely is a merit to doing this. It relieves the consuming application from chaining multiple APIs. But it also impacts reusability. Example, if your pipeline needs you to cluster records first, then create a regression model within each clusteruser; it might make sense to define these as two different APIs. There sure will be more use cases that might need either clustering or regression. Define the right amount of logic in an endpoint, and you will take one more step towards practical AI. #abhayPracticalAI #ArtificialIntelligence #machinelearning