Feature Stores: Grundlagen und Implementierung für KI-Anwendungen - KI

Einführung in Feature Stores

Die Notwendigkeit eines Feature Stores wird oft erst durch praktische Erfahrungen deutlich. Ein Betrugsmodell funktioniert in einer Testumgebung, versagt jedoch in der Produktion. Ein Supportmitarbeiter gibt eine allgemeine Antwort, weil er keine Informationen über den Benutzer hat. Ein Empfehlungssystem berechnet denselben „30-Tage-Ausgaben“-Wert in drei verschiedenen Jobs, wobei zwei von ihnen unterschiedliche Ergebnisse liefern.

Ein Feature Store ist die Infrastruktur, die diese Probleme löst. Er definiert Merkmale einmal, speichert sie in zwei Formaten (eines für das Training und eines für die Bereitstellung) und hält beide synchron. In diesem Artikel wird ein minimaler Feature Store von Grund auf in Python entwickelt, unter Verwendung von DuckDB, Parquet, Redis und FastAPI. Anschließend wird untersucht, wie KI-Anwendungen die Nutzung solcher Systeme beeinflussen.

Probleme, die ein Feature Store löst

Das klassische Problem ist die Diskrepanz zwischen Training und Bereitstellung: Der SQL-Code, der das Trainingsset erstellt, ist nicht derselbe Code, der bei der Inferenz verwendet wird, was zu abweichenden Werten führt. Dieses Problem ist real, und die Trennung zwischen Offline- und Online-Daten ist die gängige Lösung.

Das moderne Problem ist umfassender. Große Sprachmodelle (LLMs) und retrieval-augmented generation (RAG)-Pipelines benötigen strukturierte Benutzerkontexte in weniger als 10 Millisekunden bei jeder Anfrage. Ein LLM hat kein Gedächtnis darüber, wer der Benutzer ist. Um personalisierte Ausgaben zu erhalten, müssen wir den Tarif des Benutzers, die letzten Aktivitäten und den Kontostatus in den Prompt einfügen. Ein Feature Store bietet genau die Online-Speicher- und Abruf-API, die dafür erforderlich ist.

Die fünf Komponenten eines Feature Stores

Ein Feature-Register, das Merkmale als Code definiert.
Ein Offline-Speicher auf Parquet, der mit DuckDB abgefragt wird, für Training und Backfills.
Ein Online-Speicher auf Redis für latenzarme Abfragen bei der Inferenz.
Eine Materialisierungspipeline, die die neuesten Werte vom Offline- in den Online-Speicher überträgt.
Ein FastAPI-Dienst, der eine typisierte Abruf-API bereitstellt.

Beispiel: Ein personalisierter LLM-Empfehlungsdienst

In diesem Beispiel betreiben wir einen Streaming-Dienst. Wenn ein Benutzer die App öffnet, generiert ein LLM eine kurze, personalisierte Nachricht mit der Empfehlung „Was als Nächstes ansehen“. Das LLM benötigt drei Informationen über den Benutzer:

Feature: user_segment (Typ: string, Aktualisierung: täglich)
Feature: watch_count_30d (Typ: int, Aktualisierung: stündlich)
Feature: last_genre (Typ: string, Aktualisierung: bei jedem Ereignis)

Die Entität ist user_id. Diese drei Merkmale werden registriert, materialisiert und dem LLM zur Verfügung gestellt.

1. Definition des Feature-Registers

Ein Register ist ein Ort, an dem Merkmale einmal deklariert werden, zusammen mit ihrer Entität, Datentyp und Quelle. Hier verwenden wir eine Dataclass.

from dataclasses import dataclass
from typing import Literal
@dataclass(frozen=True)
class Feature:
 name: str
 entity: str
 dtype: Literal["int", "float", "str"]
 source: str # Pfad zu einer Parquet-Datei oder einer SQL-Ansicht
REGISTRY: dict[str, Feature] = {
 "user_segment": Feature("user_segment", "user_id", "str", "data/user_segment.parquet"),
 "watch_count_30d": Feature("watch_count_30d", "user_id", "int", "data/watch_count_30d.parquet"),
 "last_genre": Feature("last_genre", "user_id", "str", "data/last_genre.parquet"),
}