Bird
Raised Fist0
TensorFlowml~8 mins

REST API for predictions in TensorFlow - Model Metrics & Evaluation

Choose your learning style10 modes available
Metrics & Evaluation - REST API for predictions
Which metric matters for REST API predictions and WHY

When you build a REST API to serve machine learning predictions, the key metrics to watch are latency and accuracy. Latency means how fast the API responds with predictions. Accuracy means how correct those predictions are. Fast and correct answers make users happy and trust your app. If the API is slow, users wait too long. If predictions are wrong, users lose trust. So, both speed and prediction quality matter.

Confusion matrix for prediction quality
Confusion Matrix (Example for binary classification):

           Predicted Positive   Predicted Negative
Actual Positive       TP=80              FN=20
Actual Negative       FP=10              TN=90

Total samples = 80 + 20 + 10 + 90 = 200

Precision = TP / (TP + FP) = 80 / (80 + 10) = 0.89
Recall = TP / (TP + FN) = 80 / (80 + 20) = 0.80
F1 Score = 2 * (0.89 * 0.80) / (0.89 + 0.80) = 0.84
    

This matrix helps you understand how well your API's model predicts each class. It shows correct and wrong predictions clearly.

Precision vs Recall tradeoff with examples

Imagine your REST API predicts if an email is spam.

  • High Precision: Few good emails are wrongly marked as spam. Users don't miss important emails.
  • High Recall: Most spam emails are caught, but some good emails might be wrongly marked as spam.

Depending on your app, you choose which is more important. For spam filters, high precision is often better to avoid losing good emails. For a cancer detection API, high recall is better to catch all possible cases.

What good vs bad metric values look like for REST API predictions

Good:

  • Accuracy above 85% for classification tasks
  • Latency under 200 milliseconds per request
  • Precision and recall balanced above 80%

Bad:

  • Accuracy below 60% means many wrong predictions
  • Latency over 1 second frustrates users
  • Very low recall (e.g., 20%) means many positive cases missed
Common pitfalls in REST API prediction metrics
  • Accuracy paradox: High accuracy can be misleading if classes are imbalanced. For example, 95% accuracy if 95% data is negative but model never predicts positive.
  • Data leakage: If training data leaks into API test data, metrics look better but real-world performance is poor.
  • Overfitting: Model works well on training data but poorly on new API requests, causing low real accuracy.
  • Ignoring latency: A very accurate model that is too slow makes the API unusable.
Self-check question

Your REST API model has 98% accuracy but only 12% recall on fraud detection. Is it good for production? Why or why not?

Answer: No, it is not good. The low recall means the model misses 88% of fraud cases, which is dangerous. Even with high accuracy, missing most frauds makes the API unreliable for fraud detection.

Key Result
For REST API predictions, balance fast response time with high precision and recall to ensure useful and trustworthy results.

Practice

(1/5)
1. What is the main purpose of creating a REST API for a TensorFlow model?
easy
A. To save the model in a different file format
B. To train the model faster on a server
C. To visualize the model's architecture
D. To allow other programs to send data and get predictions easily

Solution

  1. Step 1: Understand REST API role

    A REST API acts as a bridge to send data and receive results from a model.
  2. Step 2: Match purpose with options

    Only To allow other programs to send data and get predictions easily describes this role correctly as it enables easy data exchange for predictions.
  3. Final Answer:

    To allow other programs to send data and get predictions easily -> Option D
  4. Quick Check:

    REST API purpose = Easy data exchange for predictions [OK]
Hint: REST API = send input, get output from model [OK]
Common Mistakes:
  • Confusing API with training process
  • Thinking API is for visualization
  • Assuming API changes model files
2. Which Flask code snippet correctly defines a POST endpoint to receive JSON input for predictions?
easy
A. app.post('/predict')\ndef predict():\n data = request.get_json()
B. app.route('/predict')\ndef predict():\n data = request.get_json()
C. app.route('/predict', methods=['POST'])\ndef predict():\n data = request.get_json()
D. app.get('/predict')\ndef predict():\n data = request.get_json()

Solution

  1. Step 1: Identify correct Flask route syntax for POST

    Flask uses @app.route with methods=['POST'] to define POST endpoints.
  2. Step 2: Check code snippets

    Only app.route('/predict', methods=['POST'])\ndef predict():\n data = request.get_json() uses @app.route with methods=['POST'] and calls request.get_json() correctly.
  3. Final Answer:

    app.route('/predict', methods=['POST'])\ndef predict():\n data = request.get_json() -> Option C
  4. Quick Check:

    Flask POST route = @app.route with methods=['POST'] [OK]
Hint: Flask POST = @app.route with methods=['POST'] [OK]
Common Mistakes:
  • Using app.post decorator (not standard Flask)
  • Missing methods=['POST'] in route
  • Using app.get for POST requests
3. Given this Flask code snippet, what will be the output if the input JSON is {'input': [1, 2, 3]} and the model predicts sum of inputs?
from flask import Flask, request, jsonify
app = Flask(__name__)

@app.route('/predict', methods=['POST'])
def predict():
    data = request.get_json()
    inputs = data['input']
    prediction = sum(inputs)
    return jsonify({'prediction': prediction})
medium
A. {"prediction": 6}
B. {"prediction": [1, 2, 3]}
C. {"prediction": 123}
D. Error: KeyError

Solution

  1. Step 1: Extract input and compute prediction

    The input JSON has 'input': [1, 2, 3]. The code sums these values: 1+2+3=6.
  2. Step 2: Return prediction as JSON

    The code returns jsonify({'prediction': 6}), so output is {"prediction": 6}.
  3. Final Answer:

    {"prediction": 6} -> Option A
  4. Quick Check:

    Sum([1,2,3]) = 6 [OK]
Hint: Sum input list to get prediction output [OK]
Common Mistakes:
  • Returning input list instead of sum
  • Concatenating numbers as string
  • Misreading JSON keys causing KeyError
4. You wrote this Flask API code but get an error when sending POST requests. What is the likely cause?
from flask import Flask, request, jsonify
app = Flask(__name__)

@app.route('/predict')
def predict():
    data = request.get_json()
    prediction = model.predict(data['input'])
    return jsonify({'prediction': prediction.tolist()})
medium
A. model.predict() cannot accept JSON data
B. Missing methods=['POST'] in @app.route decorator
C. request.get_json() only works with GET requests
D. jsonify() cannot convert lists

Solution

  1. Step 1: Check route decorator for HTTP methods

    The route lacks methods=['POST'], so it defaults to GET only, causing errors on POST requests.
  2. Step 2: Confirm other parts are correct

    model.predict() can accept arrays, get_json() works with POST, and jsonify converts lists fine.
  3. Final Answer:

    Missing methods=['POST'] in @app.route decorator -> Option B
  4. Quick Check:

    POST route needs methods=['POST'] [OK]
Hint: Add methods=['POST'] to route for POST requests [OK]
Common Mistakes:
  • Forgetting to specify POST method in route
  • Assuming get_json works only with GET
  • Thinking jsonify can't handle lists
5. You want to deploy a TensorFlow model with a REST API that accepts multiple inputs and returns predictions for each. Which approach is best to handle batch inputs in your Flask API?
hard
A. Accept a JSON list of inputs, convert to numpy array, predict batch, return list of predictions
B. Accept one input at a time, call model.predict repeatedly for each
C. Save each input to a file, then load and predict later
D. Use GET requests with inputs in URL parameters

Solution

  1. Step 1: Understand batch prediction needs

    Batch prediction means processing many inputs at once for efficiency.
  2. Step 2: Choose method to handle batch inputs

    Accept a JSON list of inputs, convert to numpy array, predict batch, return list of predictions accepts JSON list, converts to array, predicts all at once, then returns all predictions, which is efficient and standard.
  3. Final Answer:

    Accept a JSON list of inputs, convert to numpy array, predict batch, return list of predictions -> Option A
  4. Quick Check:

    Batch input = JSON list + batch predict [OK]
Hint: Batch predict by sending list and returning list [OK]
Common Mistakes:
  • Predicting one input at a time (slow)
  • Using files instead of direct JSON
  • Using GET for large input data
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard