Podstawy AI i ML dla inżynierów

Każdy model popełnia błąd generalizacji z dwóch niezależnych źródeł: bias (systematyczne uproszczenie zbyt sztywnego modelu) i wariancja (nadwrażliwość zbyt elastycznego modelu na szum w danych treningowych). Zrozumienie tego kompromisu jest podstawą diagnozowania, dlaczego model działa źle, zanim zacznie się zmieniać architekturę.

import numpy as np
from sklearn.linear_model import LinearRegression
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import PolynomialFeatures
from sklearn.metrics import mean_squared_error

rng = np.random.default_rng(42)
X = rng.uniform(-3, 3, size=(40, 1))
y = 0.5 * X[:, 0] ** 2 - X[:, 0] + rng.normal(0, 1, size=40)

X_train, X_test = X[:30], X[30:]
y_train, y_test = y[:30], y[30:]

for degree in (1, 4, 15):
    model = make_pipeline(PolynomialFeatures(degree), LinearRegression())
    model.fit(X_train, y_train)
    train_mse = mean_squared_error(y_train, model.predict(X_train))
    test_mse = mean_squared_error(y_test, model.predict(X_test))
    print(f"degree={degree}: train_mse={train_mse:.2f}, test_mse={test_mse:.2f}")

1. 1 Wykreśl krzywe uczenia (learning curves) Błąd treningowy i walidacyjny w funkcji liczby przykładów treningowych.
2. 2 Zdiagnozuj wzorzec Obie krzywe wysoko i blisko siebie → underfitting. Duża luka między nimi → overfitting.
3. 3 Zastosuj odpowiednią interwencję Underfitting: zwiększ pojemność modelu lub liczbę cech. Overfitting: regularyzacja, więcej danych, uproszczenie modelu.
4. 4 Zweryfikuj na zbiorze testowym Dopiero po ustabilizowaniu walidacji, jednorazowo, żeby nie zanieczyścić decyzji o architekturze.

• Regularyzacja L1 (Lasso): wymusza rzadkość wag, efektywna selekcja cech
• Regularyzacja L2 (Ridge/weight decay): tłumi duże wagi bez zerowania ich
• Dropout: losowe wyłączanie neuronów podczas treningu sieci głębokich
• Early stopping: zatrzymanie treningu, gdy błąd walidacyjny przestaje spadać
• Augmentacja danych: sztuczne powiększenie zbioru treningowego bez zbierania nowych danych

Poprawny podział danych to fundament wiarygodnej ewaluacji modelu. Błąd metodologiczny na tym etapie daje fałszywie optymistyczne wyniki w laboratorium i katastrofę w produkcji, ponieważ model był oceniany na danych, które w praktyce nigdy nie powinien był 'widzieć' przed predykcją.

from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.svm import SVC
from sklearn.model_selection import cross_val_score, StratifiedKFold

pipeline = Pipeline([
    ("scaler", StandardScaler()),
    ("clf", SVC(kernel="rbf", C=1.0)),
])

cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
scores = cross_val_score(pipeline, X, y, cv=cv, scoring="f1_macro")
print(f"F1 macro: {scores.mean():.3f} +/- {scores.std():.3f}")

• Czy preprocessing był dopasowany wyłącznie na zbiorze treningowym?
• Czy jakakolwiek cecha jest dostępna dopiero po zaistnieniu etykiety (target leakage)?
• Czy dane mają porządek czasowy i czy podział go respektuje?
• Czy zbiór testowy był użyty więcej niż raz do podejmowania decyzji o modelu?

Accuracy jest najbardziej intuicyjną metryką i najczęściej złym wyborem w realnych problemach klasyfikacji, gdzie klasy są niezbalansowane. Precision, recall, F1 i AUC-ROC rozbijają jakość modelu na komponenty, które faktycznie odpowiadają na pytania biznesowe: ile fałszywych alarmów, ile przeoczonych przypadków.

from sklearn.metrics import classification_report, roc_auc_score
from sklearn.linear_model import LogisticRegression

clf = LogisticRegression(class_weight="balanced", max_iter=1000)
clf.fit(X_train, y_train)

y_pred = clf.predict(X_test)
y_proba = clf.predict_proba(X_test)[:, 1]

print(classification_report(y_test, y_pred, target_names=["ok", "defekt"]))
print(f"AUC-ROC: {roc_auc_score(y_test, y_proba):.3f}")

1. 1 Zidentyfikuj koszt każdego typu błędu Ile kosztuje fałszywy alarm, ile kosztuje przeoczenie.
2. 2 Sprawdź balans klas Jeśli klasa mniejszościowa poniżej ~10-20%, accuracy jest niewiarygodne.
3. 3 Wybierz metrykę zgodną z kosztem Recall gdy przeoczenie jest drogie, precision gdy fałszywy alarm jest drogi, F1 gdy oba porównywalne.
4. 4 Dostrój próg decyzyjny Na podstawie krzywej precision-recall, nie zostawiaj domyślnego 0.5.

Transformer, wprowadzony w pracy 'Attention Is All You Need' (2017), zastąpił rekurencyjne sieci (RNN, LSTM) jako dominującą architekturę dla sekwencji dzięki jednej zmianie koncepcyjnej: zamiast przetwarzać sekwencję krok po kroku, każdy token 'patrzy' bezpośrednio na wszystkie inne tokeny naraz poprzez mechanizm uwagi (attention).

import numpy as np

def scaled_dot_product_attention(Q, K, V):
    d_k = Q.shape[-1]
    scores = Q @ K.T / np.sqrt(d_k)
    weights = np.exp(scores - scores.max(axis=-1, keepdims=True))
    weights /= weights.sum(axis=-1, keepdims=True)
    return weights @ V

Q = np.random.randn(4, 8)  # 4 tokeny, wymiar reprezentacji 8
K = np.random.randn(4, 8)
V = np.random.randn(4, 8)
output = scaled_dot_product_attention(Q, K, V)

• Warstwa self-attention (multi-head)
• Warstwa feed-forward (dwuwarstwowa sieć gęsta stosowana niezależnie do każdego tokenu)
• Połączenia rezydualne (residual connections) wokół obu podwarstw
• Layer normalization stabilizująca trening głębokich stosów bloków

W praktyce inżynierskiej jakość i reprezentatywność danych treningowych decydują o wyniku projektu ML częściej niż wybór architektury czy hiperparametrów. Nurt data-centric AI formalizuje tę obserwację: poprawienie etykiet i usunięcie szumu w danych zwykle daje większy wzrost jakości modelu niż zmiana algorytmu.

import numpy as np
from scipy.stats import ks_2samp

def detect_feature_drift(reference: np.ndarray, production: np.ndarray, alpha: float = 0.01) -> bool:
    statistic, p_value = ks_2samp(reference, production)
    return p_value < alpha  # True = statystycznie istotny dryf

drift_detected = detect_feature_drift(
    reference_batch["panel_temp_delta"],
    production_batch["panel_temp_delta"],
)

• Latencja: budżet czasowy na pojedynczą inferencję zgodny z wymogiem UX/SLA
• Koszt: koszt inferencji na żądanie przy skali produkcyjnej, nie tylko koszt treningu
• Monitoring: dashboard metryk jakości predykcji i rozkładu danych wejściowych w czasie
• Alerting: automatyczne powiadomienie, gdy metryka lub dryf przekroczy próg
• Plan rollbacku: możliwość szybkiego powrotu do poprzedniej wersji modelu

1. 1 Walidacja danych przed treningiem Automatyczne sprawdzenie schematu, zakresów wartości i braków danych.
2. 2 Shadow deployment Nowy model liczy predykcje równolegle z produkcyjnym, bez wpływu na decyzje, do porównania metryk.
3. 3 Canary release Stopniowe przekierowanie małego procenta ruchu na nowy model przed pełnym wdrożeniem.
4. 4 Monitoring ciągły Śledzenie dryfu danych, latencji, kosztu i metryk jakości predykcji w czasie.
5. 5 Plan rollbacku Automatyczny lub ręczny powrót do poprzedniej wersji przy przekroczeniu progów alertowych.