ML Evaluation Metrics — 99% Accuracy Missed All Fraud

Every ML model you ship into production makes decisions that cost real money or carry real risk. A fraud detector that misses fraud is a liability. A cancer screener that cries wolf scares patients and wastes resources. Picking the wrong metric is one of the costliest MLOps mistakes — and it happens constantly because teams default to accuracy without checking what accuracy measures in their context.

Here's the thing: a single number like '94% accuracy' hides everything that matters. It doesn't show whether your model fails on the minority class, whether its confidence scores are calibrated, or how performance changes as you move the decision threshold. Those blind spots are exactly where production models go wrong — not because the model is bad, but because it was optimised for the wrong thing from the start.

By the end you'll read a confusion matrix without hesitation, choose the right metric for any ML problem, implement accuracy, precision, recall, F1, ROC-AUC, and PR-AUC in Python from scratch, and explain the trade-offs in a job interview. Everything builds around a single realistic dataset so you see how each metric paints a different picture of the same model.

Why 99% Accuracy Missed All Fraud

ML model evaluation metrics are quantitative measures that assess how well a model's predictions match reality. The core mechanic is comparing predicted outcomes against ground truth labels using a confusion matrix: true positives, false positives, true negatives, and false negatives. Accuracy alone—(TP+TN)/(TP+TN+FP+FN)—is dangerously misleading when classes are imbalanced. In a fraud detection dataset with 0.1% fraud, a model that predicts 'not fraud' for every transaction achieves 99.9% accuracy yet catches zero fraud. Precision (TP/(TP+FP)) and recall (TP/(TP+FN)) expose this failure: precision tells you how many flagged frauds are real, recall tells you how many real frauds you caught. The F1-score, the harmonic mean of precision and recall, collapses both into a single metric that penalizes extreme imbalance. In production, you must also consider latency (inference time per record) and throughput (records per second) because a model that scores perfectly but takes 500ms per transaction is useless for real-time fraud blocking. Use precision-recall curves when the positive class is rare; use ROC-AUC only when you care equally about both classes. The choice of metric directly determines what the model optimizes—and what it misses.

ML Model Evaluation Metrics is

ML Model Evaluation Metrics is a core concept in ML / AI. Rather than starting with a dry definition, let's see it in action and understand why it exists.

At its core, evaluation metrics quantify how well a machine learning model performs on a given dataset. The simplest metric is accuracy — the fraction of correct predictions. But as anyone who has worked on fraud detection, medical diagnosis, or any imbalanced dataset knows, accuracy can lie. The real power of evaluation metrics comes from understanding the full picture: not just how many predictions were correct, but how the model behaves for each class, how confident it is, and how its performance changes as you adjust decision thresholds.

We'll start with the confusion matrix, the foundation for all classification metrics. Then we'll dive into each metric, see how they're computed, when they're useful, and when they break. Every example uses the same synthetic dataset so you can compare metrics directly.

from sklearn.datasets import make_classification
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier
from io_thecodeforge.metrics import confusion_matrix, classification_report

# Create an imbalanced dataset (5% positive class)
X, y = make_classification(n_samples=10000, weights=[0.95, 0.05], random_state=42)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

model = RandomForestClassifier(random_state=42)
model.fit(X_train, y_train)
y_pred = model.predict(X_test)

# Confusion matrix
cm = confusion_matrix(y_test, y_pred)
print('Confusion Matrix:\n', cm)
# Full report
print(classification_report(y_test, y_pred, target_names=['Legitimate', 'Fraud']))

Accuracy — The Most Dangerous Metric in MLOps

Accuracy = (TP + TN) / (TP + TN + FP + FN).

It's intuitive: what fraction of predictions did the model get right? For balanced datasets this works fine. But in most real-world ML problems, classes are imbalanced — sometimes severely. Consider a credit card fraud dataset where 0.1% of transactions are fraudulent. A model that predicts 'not fraud' for every single transaction achieves 99.9% accuracy. That sounds great, but it caught zero fraud.

Accuracy is also sensitive to the distribution of classes in the test set. If your test set doesn't reflect production class ratios, accuracy gives a false sense of performance. That's why you should never use accuracy as your primary metric when: - The minority class is what you care about (fraud, disease, churn). - The cost of false negatives is high. - The dataset is imbalanced (most real-world binary classification).

In production, we often see accuracy reported in dashboards with a green checkmark. That's a trap. If the model's accuracy stays high but recall drops, you won't notice until the financial damage is done.

One practical fix: compute a cost matrix where each error type (FP vs FN) has a dollar value. Then optimise for minimum cost, not maximum accuracy. This maps business reality to model selection.

from io_thecodeforge.metrics import accuracy_score, recall_score

# Simulate : 95% legitimate, 5% fraud
# Model predicts all legitimate
y_true = [0]*950 + [1]*50
y_pred = [0]*1000

print('Accuracy:', accuracy_score(y_true, y_pred))  # 0.95
print('Recall:', recall_score(y_true, y_pred))      # 0.0

Precision and Recall — The Trade-off You Can't Ignore

Precision = TP / (TP + FP). It answers: when the model predicts positive, how often is it correct? Recall = TP / (TP + FN). It answers: of all actual positives, how many did the model find?

These two metrics are in tension. Increasing one usually decreases the other. For example, in a spam filter: - High precision means you almost never mark a legitimate email as spam (low FP), but you might miss some spam. - High recall means you catch almost all spam, but you also flag some legitimate emails.

Which matters more depends on your problem. For cancer screening, you want high recall — missing a cancer case is far worse than a false alarm. For recommending content to users, you want high precision — showing irrelevant content hurts user trust.

In production, you often choose a trade-off by adjusting the decision threshold. The default threshold (0.5) is rarely optimal for real-world costs.

A common approach: plot precision-recall curve over all thresholds and pick the point that maximises some business utility function (e.g., profit).

from io_thecodeforge.metrics import precision_score, recall_score
from io_thecodeforge.calibration import adjust_threshold

# Get predicted probabilities
y_prob = model.predict_proba(X_test)[:, 1]

# Default threshold 0.5
print('Precision:', precision_score(y_test, y_prob > 0.5))
print('Recall:', recall_score(y_test, y_prob > 0.5))

# Lower threshold to catch more fraud
y_pred_low = y_prob > 0.3
print('\nWith threshold 0.3:')
print('Precision:', precision_score(y_test, y_pred_low))
print('Recall:', recall_score(y_test, y_pred_low))

F1 Score — The Harmonic Mean That Balances

F1 = 2 (Precision Recall) / (Precision + Recall)

F1 is a single metric that combines precision and recall. Because it's a harmonic mean (not arithmetic), it's heavily penalised when either precision or recall is low. A model with precision=1.0 and recall=0.0 gives F1=0, not 0.5. This makes F1 a good default for imbalanced datasets when you care about both precision and recall.

But F1 is not a silver bullet. If your business cares only about recall (e.g., catching disease), F1 will push you to improve precision at the cost of recall — potentially losing real cases. Similarly, if false positives are extremely costly (e.g., missile launch alerts), F1 will try to balance, but you really need high precision.

There's also the F-beta metric, which generalises F1 by weighting recall more (beta > 1) or precision more (beta < 1). F2 is common for recall-focused problems.

When comparing models, don't just look at F1 — always inspect precision and recall components. A model with lower F1 but better recall may be the right choice for your business.

from io_thecodeforge.metrics import f1_score, precision_score, recall_score
# Assume y_test and y_pred from previous
print('Precision:', precision_score(y_test, y_pred))
print('Recall:', recall_score(y_test, y_pred))
print('F1:', f1_score(y_test, y_pred))
# Note: the harmonic mean penalizes extreme imbalance

ROC Curve and AUC-ROC — Threshold Independence

The Receiver Operating Characteristic (ROC) curve plots the true positive rate (recall) against the false positive rate (1 - specificity) at every possible threshold. The Area Under the ROC Curve (AUC-ROC) summarises this into a single number: the probability that the model ranks a random positive instance higher than a random negative instance.

AUC-ROC is threshold-independent — it evaluates the model's ability to separate classes regardless of where you set the cutoff. A perfect model has AUC-ROC = 1.0; a random model has 0.5. AUC-ROC is excellent for comparing classifiers, especially when the class distribution is balanced or you don't know the costs yet.

However, AUC-ROC can be misleading when the dataset is highly imbalanced. Because it includes FPR (which uses true negatives), and if negatives dominate, FPR will be tiny even if the model is mediocre. In such cases, use the Precision-Recall curve (PR-AUC) instead. PR-AUC focuses on the minority class and is more informative for imbalanced datasets.

A common mistake: treating AUC-ROC as a deployment performance metric. It's a ranking metric — you still need to pick a threshold that optimises your business objective.

from sklearn.metrics import roc_curve, auc, roc_auc_score
import matplotlib.pyplot as plt

# Assume we have y_test and model probabilities from previous example
y_prob = model.predict_proba(X_test)[:, 1]
fpr, tpr, _ = roc_curve(y_test, y_prob)
roc_auc = auc(fpr, tpr)

print(f'AUC-ROC: {roc_auc:.3f}')

# Plot ROC curve
plt.plot(fpr, tpr, label=f'ROC curve (AUC = {roc_auc:.2f})')
plt.plot([0, 1], [0, 1], 'k--')
plt.xlabel('False Positive Rate')
plt.ylabel('True Positive Rate')
plt.title('ROC Curve')
plt.legend()
plt.show()

Precision-Recall Curve: When AUC-ROC Deceives

The Precision-Recall (PR) curve plots precision against recall at every threshold, completely ignoring true negatives. This makes it far more sensitive to the minority class. For highly imbalanced datasets (e.g., <10% positives), AUC-ROC can remain optimistically high because FPR stays small due to the sheer number of negatives. PR-AUC (area under the PR curve) better reflects the model's real-world performance on the class you actually care about.

A typical trap: a model achieves AUC-ROC 0.99 on a 1% fraud dataset, but PR-AUC is only 0.55. The model ranks positives well (hence high ROC) but at any usable threshold, it either misses fraud or generates too many false alarms (low PR). If you only monitor ROC, you'd ship a broken model.

Always include PR-AUC in your evaluation dashboard when the minority class matters. It catches failures that ROC silently ignores.

Here's the math: AUC-ROC uses FPR which has a denominator of total negatives. When negatives outnumber positives 99:1, the FPR can be low even if the model is mediocre on the positive class. PR-AUC uses precision, which has a denominator of predicted positives — it's directly affected by the minority class. That's why PR-AUC is the honest metric for rare events.

from sklearn.metrics import precision_recall_curve, average_precision_score
import matplotlib.pyplot as plt

y_prob = model.predict_proba(X_test)[:, 1]
precision, recall, _ = precision_recall_curve(y_test, y_prob)
pr_auc = average_precision_score(y_test, y_prob)

print(f'PR-AUC (Average Precision): {pr_auc:.3f}')

plt.plot(recall, precision, label=f'PR curve (AP = {pr_auc:.2f})')
plt.xlabel('Recall')
plt.ylabel('Precision')
plt.title('Precision-Recall Curve')
plt.legend()
plt.show()

Multi-Class Evaluation Metrics: Macro, Micro, and Weighted F1

Production models often predict more than two classes: digit recognition (0-9), sentiment (positive/neutral/negative), or image classification (dog, cat, bird). For multi-class problems, you need to aggregate per-class metrics into a single number. Three common aggregation methods exist:

• Macro F1: Compute F1 for each class independently, then take the arithmetic mean. All classes count equally, regardless of their frequency. Useful when you care about performance on every class equally, even rare ones. But it can be heavily influenced by classes with very few samples.

• Micro F1: Aggregate all TP, FP, FN across all classes, then compute F1 globally. This is equivalent to computing accuracy on a per-instance basis but expressed as F1. It's dominated by the most frequent class — good if class imbalance is not a concern.

• Weighted F1: Compute F1 per class, then take weighted average by the number of true instances per class. It accounts for class imbalance and is often the most realistic for production. scikit-learn's f1_score(average='weighted') uses this.

Choose based on your business needs. If rare classes matter (e.g., detecting rare diseases), use macro F1. If you want a single number that reflects overall performance, use weighted F1. Micro F1 is rarely used outside multi-label problems.

from io_thecodeforge.metrics import f1_score, classification_report

# Example: 3-class problem
y_true = [0, 1, 2, 0, 1, 2, 0, 0, 1]
y_pred = [0, 1, 1, 0, 2, 2, 0, 0, 1]

print('Macro F1:', f1_score(y_true, y_pred, average='macro'))
print('Micro F1:', f1_score(y_true, y_pred, average='micro'))
print('Weighted F1:', f1_score(y_true, y_pred, average='weighted'))
print('\nPer-class report:')
print(classification_report(y_true, y_pred))

Choosing the Right Evaluation Strategy: A Decision Framework

You've seen each metric individually. Now the hard part: picking the right one for your problem. The answer always starts with business context, not data statistics.

Start by answering two questions: 1. What is the cost of a false negative vs a false positive? 2. How rare is the positive class?

If FN cost >> FP cost (disease, fraud, safety) → prioritise recall. Use recall as primary, PR-AUC for model selection. If FP cost >> FN cost (spam, recommendation) → prioritise precision. Use precision at a fixed recall threshold. If costs are similar → use F1, but still check components. For model comparison before threshold tuning → use AUC-ROC or PR-AUC (prefer PR for imbalanced).

In production, define a metric suite: confusion matrix, precision, recall, F1, AUC-ROC, PR-AUC. Pick one primary, set minimum acceptable thresholds for others. Alert on any metric crossing threshold.

The biggest mistake? Changing metrics during model development. Pick your evaluation approach before you train a single model. Let the business goals drive the choice, not the other way around.

# Not runnable — conceptual decision framework
# Define costs
cost_fn = 100  # false negative cost (missed disease)
cost_fp = 1    # false positive cost (unnecessary test)

# Choose threshold that minimizes total cost
def total_cost(y_true, y_prob, threshold):
    y_pred = y_prob > threshold
    fp = ((y_pred == 1) & (y_true == 0)).sum()
    fn = ((y_pred == 0) & (y_true == 1)).sum()
    return cost_fp * fp + cost_fn * fn

# Evaluate thresholds
def select_threshold(y_true, y_prob):
    thresholds = np.linspace(0, 1, 100)
    costs = [total_cost(y_true, y_prob, t) for t in thresholds]
    return thresholds[np.argmin(costs)]

Threshold Tuning: From Model Scores to Business Decisions

All the metrics we've discussed depend on where you set the decision threshold — the probability cutoff above which you predict positive. The default 0.5 is rarely optimal. Tuning the threshold is where you turn a good ranking model into a deployed system that actually delivers business value.

Here's your workflow: 1. Get predicted probabilities on a validation set (never the test set). 2. Plot precision and recall across thresholds. 3. Compute the total cost at each threshold using your cost matrix. 4. Pick the threshold that minimises expected cost.

This approach works for any binary problem. It also lets you adjust the trade-off as business conditions change — e.g., if the cost of fraud increases, you lower the threshold to catch more cases.

A common production mistake: freezing the threshold at deployment and never revisiting it. Thresholds should be re-evaluated quarterly or whenever class distributions shift significantly.

For multi-class problems, you may need one threshold per class or use a global confidence cutoff. The same principle applies — optimise each threshold for the cost structure of that class's errors.

import numpy as np
from sklearn.metrics import precision_recall_curve

# Validation set
y_prob_val = model.predict_proba(X_val)[:, 1]
precisions, recalls, thresholds = precision_recall_curve(y_val, y_prob_val)

# Cost assumptions
cost_fn = 50  # missed fraud costs $50
cost_fp = 1   # false alarm costs $1

# Total cost for each threshold
costs = []
for t in thresholds:
    y_pred = (y_prob_val >= t).astype(int)
    fp = ((y_pred == 1) & (y_val == 0)).sum()
    fn = ((y_pred == 0) & (y_val == 1)).sum()
    costs.append(cost_fp * fp + cost_fn * fn)

best_idx = np.argmin(costs)
print(f'Optimal threshold: {thresholds[best_idx]:.2f}')
print(f'Precision: {precisions[best_idx]:.2f}')
print(f'Recall: {recalls[best_idx]:.2f}')

Monitoring Metrics in Production: What to Track and When to Alert

After you deploy, metrics drift. The model that performed well on your test set will eventually degrade because the world changes. Effective production monitoring is a combination of metrics and alerting.

When an alert fires: pause automated rollouts, rollback the model if necessary, and debug using the guides above.

# Not runnable — production monitoring skeleton
from io_thecodeforge.monitoring import (
    ModelMonitor, DataDriftDetector, MetricTracker
)

monitor = ModelMonitor(
    model_id="fraud_v2",
    metrics=["precision", "recall", "f1", "pr_auc"],
    alert_thresholds={
        "recall_class_1": 0.7,
        "pr_auc": 0.05  # drop threshold
    },
    drift_detector=DataDriftDetector()
)

# After each prediction batch:
monitor.log_batch(y_true, y_pred, y_prob, features)

# Weekly check:
report = monitor.weekly_report()
if report.alerts:
    # Trigger rollback or investigation
    print(f"Alerts: {report.alerts}")

Log Loss (Cross-Entropy): Probabilistic Evaluation Metric

Log loss, also known as cross-entropy loss, measures the performance of a classification model where the output is a probability between 0 and 1. Unlike accuracy or F1 which only care about the final binary decision, log loss penalises confident wrong predictions more than uncertain ones. That makes it the go-to metric when you need well-calibrated probabilities — for example, in ranking systems, risk scoring, or anytime you feed predictions into a downstream decision pipeline.

The formula for binary log loss: - (1/N) Σ [y log(p) + (1-y) * log(1-p)], where p is the predicted probability and y is the true label. A perfect model has log loss of 0. A model that predicts p=0.5 for everything gets log loss of about 0.693 (the natural log of 2).

In practice, log loss is harder to interpret than accuracy because you need a baseline comparison. Always compare against a naive model (e.g., always predict the majority class) or use a normalised version like pseudo-R².

One production trap: log loss is sensitive to extreme predictions. If your model outputs a probability of 0.9999 for a wrong prediction, log loss skyrockets. Some teams clip probabilities to [0.001, 0.999] to avoid infinite loss. That's a sign the model isn't calibrated — fix the calibration, don't just clip the output.

from sklearn.metrics import log_loss
import numpy as np

# Example: perfect model
y_true = [0, 1, 0, 1]
y_prob_perfect = [0.01, 0.99, 0.01, 0.99]
print('Log loss (perfect):', log_loss(y_true, y_prob_perfect))

# Example: confident wrong predictions
y_prob_confident_wrong = [0.99, 0.01, 0.99, 0.01]
print('Log loss (confident wrong):', log_loss(y_true, y_prob_confident_wrong))

# Example: uncertain predictions (always 0.5)
y_prob_uncertain = [0.5, 0.5, 0.5, 0.5]
print('Log loss (uncertain):', log_loss(y_true, y_prob_uncertain))

# Baseline: always predict majority class (class 0)
baseline_prob = [1 - np.mean(y_true)] * len(y_true)
print('Log loss (baseline):', log_loss(y_true, baseline_prob))

Model Selection and Validation: Avoiding the Metric-Based Trap

Picking a model based on a single metric from one test set is like buying a car based on horsepower — you miss everything about drivability and maintenance. Cross-validation and proper model selection are essential to get a reliable picture of performance.

Use stratified k-fold cross-validation especially for imbalanced datasets. This ensures each fold maintains the class distribution. Compute the metric of interest on each fold and report mean ± std. A low variance across folds means the model is stable.

Avoid data leakage between folds and between train/validation/test sets — any feature that uses information from the future or from the test set will inflate metrics. Common leak sources: scaling before split, using target encoding on the full dataset, or including time-based features incorrectly.

Hold out a proper test set that is never used for any decision — no threshold tuning, no feature selection, no hyperparameter tuning. If you tune anything on the test set, you are cheating yourself.

One practical framework: 70% train, 15% validation (for threshold tuning), 15% test (for final evaluation). Or use nested cross-validation for small datasets.

from sklearn.model_selection import StratifiedKFold, cross_val_score
from sklearn.ensemble import RandomForestClassifier
import numpy as np

X, y = make_classification(n_samples=5000, weights=[0.9, 0.1], random_state=42)

cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
model = RandomForestClassifier(random_state=42)

scores = cross_val_score(model, X, y, cv=cv, scoring='f1')
print(f'F1 across folds: {scores}')
print(f'Mean F1: {np.mean(scores):.3f} +/- {np.std(scores):.3f}')

Business Alignment: From Metrics to Decision Making

The most expensive mistake in ML is optimising a metric that doesn't map to business outcomes. You can have a model with perfect F1 but if it doesn't move the business needle, it's worthless.

Step 1: Define the business objective. Is it revenue, cost savings, customer retention, or user satisfaction? Step 2: Translate to model metric. For fraud: estimated dollars prevented. For churn: number of customers proactively retained. Step 3: Build a cost matrix. Assign dollar values to TP, FP, FN, TN. Then the optimal model is not the one with highest F1 or AUC — it's the one with the highest expected value. Step 4: Use a decision threshold that maximises business value. This is often different from the threshold that maximises F1. Step 5: Validate offline before online. Use historical data to simulate the business impact of your model at different thresholds.

Many teams skip to step 5 with a metric they copied from a blog post. Don't. Ground every decision in business reality.

# Business impact simulation
# Assume each true positive (fraud caught) saves $100
# Each false positive (false alarm) costs $5
# Each false negative (missed fraud) costs $100
# Each true negative costs $0

value_per_tp = 100
cost_per_fp = -5
cost_per_fn = -100

def compute_business_value(y_true, y_pred):
    tp = ((y_pred == 1) & (y_true == 1)).sum()
    fp = ((y_pred == 1) & (y_true == 0)).sum()
    fn = ((y_pred == 0) & (y_true == 1)).sum()
    return tp * value_per_tp + fp * cost_per_fp + fn * cost_per_fn

# Evaluate across thresholds and pick the one with max value

Regression Metrics: When Your Model Predicts Continuous Values

You've been shipping classification models for months. Now your team launches a demand forecasting system. Classification metrics won't save you here. You need regression metrics. Mean Absolute Error (MAE) tells you the average prediction error in original units. It's interpretable. Your business stakeholders understand "our forecast is off by $500 on average." Mean Squared Error (MSE) punishes large errors quadratically. That single outlier that crashed your model at 3 AM? MSE catches it. Root Mean Squared Error (RMSE) brings MSE back to original units for comparison. Root Mean Squared Logarithmic Error (RMSLE) is your friend when predictions span multiple orders of magnitude — like predicting sales during Black Friday versus a Tuesday afternoon. R-squared (R²) measures variance explained by your model. A value of 0.85 means your model explains 85% of the variance. But here's the trap: R² always increases with more features. Use adjusted R² for feature selection. Never deploy a regression model with only MAE. You'll miss the outliers that burn your production pipeline.

// io.thecodeforge
import numpy as np
from sklearn.metrics import mean_absolute_error, mean_squared_error, r2_score

y_true = np.array([1200, 4500, 3200, 890, 15000])
y_pred = np.array([1150, 4700, 3000, 950, 13000])

mae = mean_absolute_error(y_true, y_pred)
mse = mean_squared_error(y_true, y_pred)
rmse = np.sqrt(mse)
r2 = r2_score(y_true, y_pred)

print(f"MAE: {mae:.2f} units")  # Average error in original units
print(f"MSE: {mse:.2f}")        # Catches outlier impact
print(f"RMSE: {rmse:.2f} units") # Back to interpretable scale
print(f"R²: {r2:.3f}")          # Variance explained

Confusion Matrix: The First Thing You Look At After Training

Before you calculate a single metric, look at the confusion matrix. It's a 2x2 grid that tells you exactly where your model fails. True positives, true negatives, false positives, false negatives. No averaging. No hiding. When your fraud model shows 99% accuracy but the confusion matrix reveals 500 false negatives on the fraud class, you know exactly what's broken. The matrix is your ground truth. Use it to calculate precision, recall, and F1 manually at first. It forces you to understand the cost of each error type. In credit risk, false negatives cost you loan defaults. In spam detection, false positives cost you angry users. The confusion matrix makes these trade-offs visible. Production monitoring tip: track the raw counts in your confusion matrix over time. If your false positive rate creeps up from 2% to 5% over two weeks, you'll catch concept drift before it burns you. Don't let automated metrics blind you. Start with the matrix.

// io.thecodeforge
from sklearn.metrics import confusion_matrix, classification_report
import numpy as np

y_true = np.array([1, 0, 1, 1, 0, 1, 0, 0, 1, 0])
y_pred = np.array([1, 0, 0, 1, 0, 1, 1, 0, 0, 0])

cm = confusion_matrix(y_true, y_pred)
print("Confusion Matrix:")
print(f"TN={cm[0,0]} FP={cm[0,1]}")
print(f"FN={cm[1,0]} TP={cm[1,1]}")

# Manual calculation - understand the math
tn, fp, fn, tp = cm.ravel()
precision = tp / (tp + fp) if (tp + fp) > 0 else 0
recall = tp / (tp + fn) if (tp + fn) > 0 else 0
f1 = 2 * precision * recall / (precision + recall) if (precision + recall) > 0 else 0

print(f"\nPrecision: {precision:.2f}")
print(f"Recall: {recall:.2f}")
print(f"F1: {f1:.2f}")