2026-10-20 · KI im Produktivbetrieb
Wann sich ein Feature Store lohnt — Kriterien aus dem Betrieb einer GenAI-Plattform
In LLMOps-Checklisten steht der Feature Store als Standardbaustein. Für eine mandantenfähige GenAI-Plattform habe ich geprüft, welches Problem er löst — und woran man erkennt, dass man es hat.
Feast, Tecton, Vertex Feature Store: Wer eine «erwachsene» KI-Plattform baut, findet diese Bausteine in jeder Architektur-Checkliste. Sie kommen aus dem klassischen Machine Learning, und genau da liegt die Frage.
Was ein Feature Store tatsächlich löst
Er sorgt dafür, dass tabellarische Merkmale beim Training eines eigenen Modells und im Produktivbetrieb gleich berechnet werden — offline und online, mit Zeitbezug, damit das Modell beim Training nicht in die Zukunft sieht. Das Problem existiert nur, wenn man eigene Modelle auf tabellarischen Daten trainiert.
Was in einem LLM-System seine Rolle übernimmt
Auf der Plattform, einem System für Content- und PR-Analytik, entscheiden LLMs über eine API anhand von Prompt und Kontext. Reproduzierbarkeit kommt hier aus zwei anderen Bausteinen: Prompts liegen versioniert in der Datenbank, und jede LLM-Entscheidung schreibt einen unveränderlichen Eintrag — Pipeline-Version, Momentaufnahme und SHA-256 der Eingabe, Urteil, Tokens, Kosten, Dauer. Für die Suche nach Bedeutung gibt es Embeddings in pgvector; das ist ein Vector Store, kein Feature Store.
Ein Feature Store hätte heute einen weiteren Dienst, Synchronisation und Betrieb gebracht, aber keinen Nutzen. Ich habe ihn nicht eingeführt — und das Kriterium für die Wiedervorlage gleich festgehalten.
Ab wann er sich lohnt
Der Auslöser ist das erste eigene Modell auf tabellarischen Daten. Realistische Kandidaten: ein günstiger Klassifikator statt eines Teils der LLM-Rückfälle beim Clustern von Themen, die Wahl der Crawling-Strategie je Domain nach Erfolg und Kosten, ein Scoring von Medien und Autoren.
Auch dann ist der erste Schritt keine neue Plattform, sondern eine Merkmalstabelle in Postgres mit einem Zeitstempel «as_of». Das Entscheidungsprotokoll mit den manuellen Korrekturen ist dann bereits ein beschrifteter Datensatz — gebaut für Audit und Kostentransparenz. Einen eigenen Feature Store braucht man, wenn es mehrere solche Modelle gibt und sie Online-Serving mit niedriger Latenz brauchen.
Die Regel gilt auch für Model Registry und Co.: Erst klären, welches Problem der Baustein löst, dann prüfen, ob man es hat.