Was wird im Vorstellungsgespräch als Machine Learning Engineer am häufigsten gefragt?

Wie du Features auf Sprachmodellen baust: Retrieval und RAG, Agenten und Tools, Evaluation, Kosten und Tempo und Sicherheit. Programmierrunden sind meist gewöhnliches Python.

Muss ich LangChain oder LangGraph kennen?

Eines davon zu kennen hilft, und manche Anzeigen nennen sie. Im Interview wird geprüft, ob du verstehst, was so ein Framework im Hintergrund tut: die Schritte, die Grenzen, die Suche.

Wie tief geht die Theorie des Machine Learning?

Für Rollen, die KI in Produkte bringen, die Grundlagen: Embeddings, Attention in einfachen Worten, Testdaten, einfache Kennzahlen. Rollen in Forschung und Plattform gehen tiefer.

Wie bereite ich mich in einer Woche vor?

Bau ein kleines Retrieval-Projekt mit Testset oder nimm ein altes wieder auf, sag die beiden ausgearbeiteten Antworten laut und bereite zu jedem Abschnitt eine Geschichte über einen Fehlschlag vor.

Sind diese Antworten an einen Anbieter gebunden?

Nein. Wo ein Detail von einem Anbieter oder einer Version abhängt, ist es markiert, damit du die aktuelle Dokumentation prüfen kannst.

Interviewfragen für Machine Learning Engineers und AI Engineers, mit ausgearbeiteten Antworten

Achtzehn Fragen, die in Vorstellungsgesprächen für Machine Learning Engineers und AI Engineers immer wieder kommen. Zu jeder: worauf der Interviewer achtet, eine kurze Antwort, eine ausführliche Antwort in einfachen Worten und eine typische Nachfrage.

Das cvscored-TeamVeröffentlicht 05.11.2026 · Aktualisiert 05.11.2026

Inhalt

So nutzt du diese Fragen
Was ein Machine Learning Engineer können muss
Retrieval und RAG
Agenten und Tools
Evaluation
Modelle, Kosten und Tempo
Sicherheit, Datenschutz und Recht
Grundlagen und Systemdesign
Dein Lebenslauf für diese Fragen
Das Wichtigste
Häufige Fragen
Mehr zu diesem Beruf

So nutzt du diese Fragen

Lies die kurze Antwort und sag sie laut. Das sind deine ersten dreißig Sekunden. Lies dann die ausführliche Antwort und such dir zwei oder drei Punkte aus, die du ergänzt. Interviewer wollen Abwägungen, Grenzen und wie du das Ergebnis messen würdest, keine Liste von Werkzeugen.

Ein Hinweis „je nach Anbieter“ oder „je nach Version“ markiert ein Detail, das sich mit einem Anbieter oder einem Release ändern kann. Prüf die aktuelle Dokumentation, bevor du es zitierst.

Was ein Machine Learning Engineer können muss

Python für die Produktion: sauberer, getesteter Code und ein kleiner Webdienst, zum Beispiel mit FastAPI.
TypeScript: Viele Machine Learning Engineers bauen auch den Teil des Features, den die Leute im Browser sehen.
APIs für Sprachmodelle (LLM): Anfragen senden, das Modell Tools aufrufen lassen, Antworten in einem festen Format bekommen und die Tokens im Blick behalten (die Einheiten, in denen das Modell liest und abrechnet). je nach Anbieter
RAG (Retrieval-Augmented Generation): Das Modell antwortet aus Textstellen, die du vorher nachschlägst, nicht aus dem Gedächtnis. Dazu gehören das Aufteilen von Dokumenten, Suche, Ranking und Quellenangaben, oft mit einer Vektordatenbank.
Agenten: ein Modell, das Schritt für Schritt und innerhalb von Grenzen entscheidet, welches Tool es als Nächstes nutzt.
Evals: ein fester Satz von Testfragen, jedes Mal gleich bewertet, damit du sagen kannst, ob eine Änderung etwas besser oder schlechter gemacht hat.
Ausliefern: Git, CI/CD (Tests laufen bei jeder Änderung), Docker, eine Cloud (Azure oder AWS), manchmal Kubernetes.
Modelle: wann ein guter Prompt reicht, wann du Dinge nachschlagen lässt und wann du feintunst (ein Modell mit deinen eigenen Beispielen weitertrainierst).
Sicherheit und Recht: Prompt Injection (Text, der dem Modell neue Befehle geben will), die DSGVO und die Grundlagen des EU AI Act.
Grundlagen: Begriffe des Machine Learning wie Trainings- und Testdaten und genug Statistik, um eine echte Verbesserung von Glück zu unterscheiden.

Retrieval und RAG

Wie baust du agentische Suche und agentisches Retrieval in einem Chatbot auf?

Worauf sie achten: dass du einfach anfängst, jeden Teil von Suche und Retrieval kennst, dem Agenten harte Grenzen setzt, Zugriffsrechte aus den Händen des Modells hältst und das Ergebnis messen kannst.

Kurze Antwort: „Ich fange mit einfachem Retrieval an: die Frage klar machen, gleichzeitig nach Stichwörtern und nach Bedeutung suchen, die Ergebnisse zusammenführen, die besten nach vorn stellen und mit Quellenangaben antworten. Einen Agenten lasse ich nur dann mehrere Suchen planen, wenn eine Suche nicht reicht. Der Agent arbeitet mit einem Schrittlimit, einem Token-Budget und einem Zeitlimit. Jede Aussage muss auf eine gefundene Textstelle verweisen, und das prüfen wir. Geht etwas kaputt, gibt es einen Plan B, und der Bot sagt, was er nicht finden konnte, statt zu raten.“

Die ausführliche Antwort in acht Schritten:

Brauche ich überhaupt einen Agenten? Die meisten Fragen brauchen ein einziges Nachschlagen, etwa „Wie lang ist die Kündigungsfrist?“. Das ist schnell, günstig und leicht zu testen. Ein Agent (das Modell plant mehrere Suchen) ist langsamer und teurer. Er lohnt sich für Fragen mit mehreren Teilen, Fragen, die mehrere Quellen brauchen, oder Fragen, die eine Rückfrage wie „Welchen Vertrag meinst du?“ brauchen. Ein kleines, günstiges Modell davor kann jede Frage auf den richtigen Weg schicken.
Die Frage klar machen. Mach aus „und die zweite?“ mithilfe des Chatverlaufs eine vollständige Frage. Teil eine Frage mit zwei Teilen in zwei Suchen. Zieh Filter wie Produkt, Datum oder Sprache heraus und gib sie der Suche als Filter mit, nicht als Wörter.
Gib dem Modell wenige klare Tools. Zum Beispiel „Hilfeseiten durchsuchen“, „einen Abschnitt öffnen“ und „eine Bestellung nachschlagen“. Jedes Tool sagt, wann es zu nutzen ist, und liefert kurze Ergebnisse mit einer ID. Zugriffsrechte werden in jedem Tool geprüft, anhand dessen, wer angemeldet ist. Das Modell entscheidet nie, wer was sehen darf.
Die Dokumente gut aufteilen. Zerleg sie beim Chunking (dem Schneiden in Stücke) entlang ihrer Überschriften, nicht alle paar hundert Zeichen. Setz die Überschrift an den Anfang jedes Chunks, damit er leichter gefunden wird. Lass Tabellen ganz. Sprachen mit langen zusammengesetzten Wörtern wie Deutsch brauchen Sorgfalt: Für die Stichwortsuche müssen die Wörter zerlegt werden.
Auf zwei Arten zugleich suchen: hybride Suche. Die Stichwortsuche (BM25, die Textstellen nach den Wörtern bewertet, die sie mit der Frage teilen) findet genaue Namen, Codes und seltene Wörter. Die Vektorsuche (die Bedeutungen vergleicht) findet dieselbe Idee in anderen Worten. Führ die beiden Listen so zusammen, dass eine Textstelle, die in einer der beiden weit oben steht, auch insgesamt weit oben landet. Ein verbreiteter Weg dafür ist Reciprocal Rank Fusion, die nur auf die Positionen schaut, sodass du nie zwei verschiedene Arten von Werten vergleichen musst.
Reranking. Ein Reranker ist ein zweites, sorgfältigeres Modell, das die Frage und jedes der besten Ergebnisse zusammen liest und sie in eine bessere Reihenfolge bringt. Behalte die besten fünf bis acht. Schneidet selbst das beste schwach ab, behandle es als „nichts gefunden“. Genau das lässt den Bot ehrlich „Ich weiß es nicht“ sagen.
Zitieren und prüfen. Nummeriere die Textstellen und verlange nach jeder Tatsache eine Quellenangabe. Prüf danach, dass jede Quellenangabe auf eine echte Textstelle zeigt und dass diese das wirklich sagt. Entferne oder markiere Sätze, die nicht belegt sind. Manche APIs haben eingebaute Quellenangaben; die Prüfung bleibt. je nach Anbieter
Für den Fehlerfall planen. Fällt die Vektorsuche aus, nutze die Stichwortsuche allein. Fällt der Reranker aus, behalte die zusammengeführte Reihenfolge. Scheitert das Modell, versuch es nach kurzer Wartezeit noch einmal und nimm dann ein zweites Modell. Wird nichts gefunden, versuch eine breitere Suche und sag es dann. Text, der in einem Dokument steht, ist nie ein Befehl an das Modell, und Tools, die etwas ändern, brauchen das Okay der Person.

Die Grenzen, in einfachen Worten: ein Schrittlimit (höchstens fünf oder sechs Tool-Aufrufe), ein Token-Budget für den ganzen Lauf, ein Zeitlimit und ein Stopp, wenn der Agent dieselbe Suche wiederholt. Ist ein Limit erreicht, antwortet der Bot mit dem, was er hat, und sagt, was fehlt. Jeder Schritt wird protokolliert, damit du später sehen kannst, was passiert ist.

So würdest du es messen: wie oft die richtige Textstelle unter den ersten fünf ist (Recall), ob jede Aussage durch eine Textstelle belegt ist (Faithfulness), ob der Bot ablehnt, wenn es keine Antwort gibt, wie lange Antworten dauern und was jede Antwort kostet.

Schwache Antwort: „Ich würde LangChain und eine Vektordatenbank nehmen.“ Keine Grenzen, keine Zugriffsrechte, keine Messung, kein Plan für „nicht gefunden“.

Nachfrage: „Die richtige Textstelle ist nur bei sechs von zehn Fragen unter den ersten fünf. Was tust du?“ Sortier zuerst die Fehltreffer. Fehlt die Textstelle im Index (ein Problem beim Aufteilen)? Wird sie gefunden, aber zu weit unten eingeordnet (ein Problem beim Ranking)? Oder wurde die Frage schlecht umformuliert? Behebe die größte Gruppe und miss noch einmal.

Wie entscheidest du, wie Dokumente in Chunks aufgeteilt werden?

Worauf sie achten: dass du misst statt zu raten und der Struktur des Dokuments folgst.

Kurze Antwort: „Ich schneide entlang von Überschriften und Absätzen, behalte die Überschrift bei jedem Chunk und probiere zwei oder drei Größen an meinen Testfragen aus. Ich nehme die Größe, die die richtige Textstelle am häufigsten findet. Verlieren kleine Chunks den Zusammenhang, gebe ich dem Modell den ganzen Abschnitt rund um den gefundenen Chunk.“

Die ausführliche Antwort: Verschiedene Dokumente wollen verschiedene Chunks: eine Frage und Antwort pro Chunk bei einer FAQ, eine Klausel bei einem Vertrag, eine ganze Tabelle bei einer Tabelle.

Schwache Antwort: „512 Tokens mit etwas Überlappung“, ohne Begründung. Nachfrage: „Den Antworten fehlt eine Bedingung, die zwei Absätze später steht.“ Gib dem Modell den ganzen Abschnitt, oder schneide nach Klauseln.

Stichwortsuche, Vektorsuche oder beides? Wann nimmst du einen Reranker dazu?

Worauf sie achten: dass du weißt, worin jede Art der Suche gut ist.

Kurze Antwort: „Beides. Die Stichwortsuche für genaue Namen und Codes, die Vektorsuche für dieselbe Bedeutung in anderen Worten, zusammengeführt in eine Liste. Einen Reranker nehme ich dazu, wenn die richtige Textstelle unter den ersten fünfzig ist, aber nicht unter den ersten fünf. Das zeigen mir meine Testfragen.“

Die ausführliche Antwort: Die Vektorsuche allein verpasst Bestellnummern und Produktcodes. Die Stichwortsuche allein verpasst „kündigen“, wenn im Text „beenden“ steht. Ein Reranker kostet bei jeder Frage etwas Zeit, deshalb sortierst du nur die ersten dreißig bis fünfzig neu.

Schwache Antwort: „Die Vektorsuche ist immer besser.“ Nachfrage: „Welches Embedding-Modell?“ Eines, das alle Sprachen deiner Inhalte beherrscht, ausgewählt durch Tests mit deinen eigenen Fragen. Ein Embedding-Modell verwandelt Text in Zahlen, die seine Bedeutung erfassen. je nach Anbieter

Wie bringst du das Modell dazu, seine Quellen anzugeben, und wie prüfst du, dass die Quellenangaben echt sind?

Worauf sie achten: dass du einer Quellenangabe nicht traust, nur weil sie da ist.

Kurze Antwort: „Ich nummeriere die Textstellen, verlange nach jeder Tatsache eine Quellenangabe und prüfe danach, dass jede zitierte Textstelle das wirklich sagt. Sätze ohne Beleg werden entfernt oder markiert.“

Die ausführliche Antwort: Prüf zuerst, ob die zitierte Nummer überhaupt existiert. Ein kurzes wörtliches Zitat lässt sich am leichtesten prüfen. Für den Rest kann ein kleines zweites Modell beurteilen, ob die Textstelle den Satz stützt. Miss auch diesen Prüfer an Beispielen.

Schwache Antwort: „Der Prompt sagt ihm, dass es Quellen angeben soll.“ Nachfrage: „Die Prüfung entfernt zu viel.“ Oft ist die Textstelle richtig, aber zu kurz. Gib dem Prüfer den ganzen Abschnitt.

Agenten und Tools

Wie entwirfst du die Tools, die ein Agent aufrufen kann?

Worauf sie achten: dass du weißt, dass das Modell von jedem Tool nur Name, Beschreibung und Ergebnis sieht, und dass genau das dein Entwurf ist.

Kurze Antwort: „Wenige Tools, die jeweils eine Sache tun, mit Namen und Beschreibungen, die sagen, wann sie zu nutzen sind, geprüften Eingaben, kurzen Ergebnissen und Fehlermeldungen, mit denen das Modell etwas anfangen kann.“

Die ausführliche Antwort:

Namen, die sich nicht verwechseln lassen: „Bestellungen suchen“ und „eine Bestellung holen“, nicht „suchen“ und „finden“.
Eine falsche Eingabe bekommt eine klare Meldung zurück, etwa „eine Bestellnummer hat 8 Ziffern“, damit das Modell es noch einmal versuchen kann.
Tools, die nur lesen, bleiben getrennt von Tools, die etwas ändern. Eine Änderung braucht das Okay der Person.
Teste jedes Tool für sich wie jede andere API, mit Unit-Tests, bevor das Modell es nutzt.

Schwache Antwort: „Ich gebe dem Modell Zugriff auf unsere Datenbank.“ Nachfrage: „Das Modell wählt das falsche Tool.“ Lies die Logs: Meist klingen zwei Beschreibungen ähnlich. Leg die Tools zusammen oder schärfe die Formulierung, und nimm diese Fälle in die Testfragen auf.

Wie verhinderst du, dass ein Agent in Schleifen läuft, und wie begrenzt du Kosten und Zeit?

Worauf sie achten: harte Grenzen und eine sinnvolle Antwort, wenn eine Grenze erreicht ist.

Kurze Antwort: „Ein Schrittlimit, ein Token-Budget, ein Zeitlimit und ein Timeout für jedes Tool, dazu ein Stopp, wenn er sich wiederholt. Ist ein Limit erreicht, antwortet er mit dem, was er hat, und sagt, was fehlt.“

Die ausführliche Antwort: Sag dem Agenten, wie viel Budget noch übrig ist, damit er innerhalb davon plant. Protokolliere die Kosten jedes Laufs und lass dich warnen, wenn ein Lauf weit mehr kostet als üblich. Stoßen viele Läufe an die Grenze, repariere die Tools oder den Plan, statt die Grenze anzuheben.

Schwache Antwort: „Wir setzen ein hohes Limit und hoffen.“ Nachfrage: „Was sieht die Person, wenn das Limit erreicht ist?“ Eine nützliche Teilantwort und das Angebot, an einen Menschen zu übergeben.

Wie baust du einen Harness, der robust ist und jeden Schritt abdeckt?

Worauf sie achten: dass der Code rund um das Modell solide ist und dass du jeden Schritt testen kannst, nicht nur die endgültige Antwort.

Kurze Antwort: „Der Harness ist der Code, der das Modell betreibt: Er bereitet die Anfrage vor, ruft das Modell und die Tools auf, verfolgt das Gespräch und setzt die Grenzen durch. Ich halte jeden Schritt klein und testbar, gebe jedem Aufruf nach außen ein Timeout und einen neuen Versuch, protokolliere jeden Schritt und teste jeden Schritt für sich ebenso wie den ganzen Lauf.“

Die ausführliche Antwort:

Kleine Schritte: Frage umformulieren, suchen, ranken, handeln, schreiben, prüfen. Jeder Schritt lässt sich für sich testen und austauschen.
Aufrufe nach außen: ein Timeout und ein neuer Versuch nach kurzer Wartezeit für jeden Aufruf von Modell und Tool. Alles, was Daten ändert, ist so geschützt, dass ein neuer Versuch es nicht doppelt tun kann.
Antworten in einem festen Format: Prüf jede Antwort gegen das erwartete Format. Ist sie falsch, frag noch einmal mit dem Fehler nach und greif dann auf einen Plan B zurück.
Gespeicherter Zustand: Eine halb erledigte Aufgabe lässt sich nach einem Absturz wieder aufnehmen.
Tests für jeden Schritt: Gespeicherte Antworten des Modells machen Tests schnell, kostenlos und jedes Mal gleich. Teste auch, was passiert, wenn ein Tool langsam ist, kaputt ist oder Unsinn liefert.

Schwache Antwort: „Wir prüfen die endgültigen Antworten von Hand.“ Nachfrage: „Ein Tool ändert das Format seiner Antworten.“ Die Formatprüfung in den Tests schlägt sofort fehl, bevor ein echter Nutzer eine kaputte Antwort sieht.

Evaluation

Welche Schritte braucht die Evaluation eines LLM-Features, etwa mit Probes für die Evals?

Worauf sie achten: dass du ein KI-Feature testest wie jede andere Software: Testsets, wiederholbare Prüfungen, ein Gate vor dem Release und Budgets. Und dass du weißt, wie sich ein KI-Bewerter irren kann.

Kurze Antwort: „Ich lege fest, was gut für jeden Schritt und für die ganze Antwort heißt, einschließlich Kosten und Tempo. Ich baue einen Satz echter Testfragen, mit Gruppen für die schwierigen Fälle, und kleine Probes, die jeweils ein Verhalten testen. Jede Änderung läuft gegen sie. Ich nutze exakte Prüfungen, wo ich kann, und einen KI-Bewerter nur, wo ich muss, und ich prüfe den Bewerter gegen Menschen. Ein Release stoppt, wenn die Qualität stärker sinkt, als der Zufall erklärt, wenn ein kritischer Fall bricht oder wenn Kosten oder Tempo über dem Budget liegen.“

Die ausführliche Antwort in acht Schritten:

Festlegen, was gut heißt. Für die Suche: Steht die richtige Textstelle weit oben? Für die Antwort: Ist jede Aussage durch eine Textstelle belegt, beantwortet sie die Frage, ist sie in der richtigen Sprache, lehnt sie ab, wenn sie ablehnen sollte? Für das ganze Feature: Wird die Aufgabe erledigt, wie lange dauert es und was kostet es?
Das Eval-Set bauen. Fang mit hundert bis dreihundert echten Fragen an: aus Support-Tickets, von Fachleuten und einige aus den Dokumenten erzeugt und von einem Menschen geprüft. Schreib zu jeder auf, wo die Antwort steht, was sie sagen muss, was sie nicht sagen darf und ob es überhaupt eine Antwort gibt. Teil sie in Gruppen ein: einfach, mehrteilig, keine Antwort, knifflig und jede Sprache, die du unterstützt. Leg einige zur Seite, auf die du nie optimierst.
Probes ergänzen. Eine Probe ist ein kleiner Test für ein einziges Verhalten, sodass ein Fehler dir genau sagt, was kaputt ist. Zum Beispiel: Die Antwort steht nicht in den Dokumenten (lehnt es ab?), ein Dokument enthält einen versteckten Befehl (wird er ignoriert?), zwei Dokumente widersprechen sich (wird das neuere genutzt?), ein Tool fällt aus (fängt sich der Agent?), personenbezogene Daten stehen im Kontext (gelangen sie nach außen?).
Jeden Schritt testen, nicht nur das Ende. Lass jeden Schritt für sich mit gespeicherten Eingaben laufen, dann die ganze Kette, damit ein Fehler auf einen Schritt zeigt. Gespeicherte Antworten des Modells halten die täglichen Testläufe günstig und wiederholbar. Lass gegen das Live-Modell nach Zeitplan laufen oder wenn sich Modell oder Prompt ändern, mit einer Ausgabengrenze. Notier bei jedem Ergebnis die Versionen von allem.
Zuerst mit exakten Prüfungen bewerten. Nutze einen Bewerter (ein zweites Modell, das Antworten benotet) nur für offene Fragen wie „Beantwortet es die Frage?“, mit einfachen Punkten für Bestanden oder Nicht bestanden statt einer Note von eins bis zehn.
Gegen einen unzuverlässigen Bewerter absichern. Ein Bewerter kann jedes Mal eine andere Note geben. Leg die Version des Bewertermodells fest. Lass ihn dreimal laufen und nimm die Mehrheit. Lass Menschen fünfzig bis hundert Antworten bewerten, und trau dem Bewerter nur, wenn er meist mit ihnen übereinstimmt. Tausch die Reihenfolge, wenn er zwei Antworten vergleicht, weil Bewerter dazu neigen, die erste zu bevorzugen. Nimm lieber einen Bewerter aus einer anderen Modellfamilie, weil Modelle dazu neigen, ihre eigenen Texte zu mögen. je nach Anbieter
Regressionsprüfungen vor dem Release. Eine Regression ist etwas, das früher funktioniert hat und jetzt nicht mehr. Vergleich die neuen Ergebnisse Frage für Frage mit dem letzten Release. Zähl, was von Bestanden zu Nicht bestanden ging und umgekehrt: neun gegen drei kann Glück sein, zwanzig gegen drei nicht. Kritische Fragen müssen alle bestehen, und die Gruppe ohne Antwort darf nie schlechter werden, auch wenn der Durchschnitt steigt.
Budgets. Vereinbare Kosten pro hundert Antworten und eine Zeit, unter der die meisten Antworten bleiben müssen. Miss beides bei jedem Lauf und stopp eine Änderung, die sie sprengt, auch wenn die Qualität steigt. Beobachte nach dem Release Feedback, Übergaben an Menschen, Antworten mit „nicht gefunden“, Tempo und Kosten, und nimm jede Woche echte Fehler in das Eval-Set auf.

Schwache Antwort: „Wir schauen uns ein paar Antworten an, und sie wirken gut.“ Oder ein einziger Wert eines Bewerters, ohne etwas, woran man ihn prüfen könnte.

Nachfrage: „Der Bewerter sagt, die Qualität sei gestiegen, aber die Leute beschweren sich mehr. Warum?“ Vielleicht mag der Bewerter lange oder selbstsichere Antworten, vielleicht fehlen dem Eval-Set die neuen Arten von Fragen, oder die Gruppe, die schlechter wurde, ist im Test klein, aber in der echten Nutzung groß. Prüf den Bewerter erneut gegen Menschen und vergleich die Testgruppen mit dem, was die Leute wirklich fragen.

Wie nutzt du ein LLM als Bewerter, ohne dich von ihm in die Irre führen zu lassen?

Worauf sie achten: dass du weißt, dass sich der Bewerter auf beständige Weise irren kann.

Kurze Antwort: „Einfache Fragen mit Bestanden oder Nicht bestanden, die Textstelle und eine gute Antwort zum Vergleich, ein festes Bewertermodell, mehrere Läufe und ein regelmäßiger Abgleich mit Menschen.“

Die ausführliche Antwort: Bewerter sind schlecht darin, Fakten zu prüfen, die sie nicht sehen, also gib ihnen immer die Textstelle. In den täglichen Testläufen bewerte eine Stichprobe; vor einem Release bewerte alles.

Schwache Antwort: „Der Bewerter gibt jeder Antwort eine Note von eins bis zehn.“ Nachfrage: „Bewerter und Menschen sind sich bei einer Gruppe von Fragen nicht einig.“ Schau dir diese Fälle an, korrigiere die Bewertungspunkte und lass Menschen diese Gruppe so lange bewerten, bis beide übereinstimmen.

Was testest du vor dem Release, und was beobachtest du in der Produktion?

Worauf sie achten: dass du auch an das Feature nach dem Launch denkst.

Kurze Antwort: „Vor dem Release: das Eval-Gate, die Probes und einen Lasttest für Tempo und Kosten. Nach dem Release: Feedback, Übergaben an Menschen, Antworten mit ‚nicht gefunden‘, Tempo, Kosten und Fehler, mit Alarmen, und jede Woche liest ein Mensch eine Stichprobe von Gesprächen.“

Die ausführliche Antwort: Gib das Release zuerst für einen kleinen Teil der Nutzer frei und roll bei einem schlechten Signal zurück. Protokolliere genug, um einen Fall nachzuspielen, ohne personenbezogene Daten zu behalten, die du nicht brauchst. Modellanbieter aktualisieren ihre Modelle, also leg die Version fest, wo du kannst. je nach Anbieter

Schwache Antwort: „Wir veröffentlichen und warten auf Beschwerden.“ Nachfrage: „Die Antworten sind über Nacht langsamer geworden, ohne Änderung auf unserer Seite.“ Prüf, ob der Anbieter das Modell geändert hat oder unter Last steht, und halte ein Ersatzmodell bereit.

Modelle, Kosten und Tempo

Prompting, Retrieval oder Fine-Tuning: Wann nutzt du was?

Worauf sie achten: dass du das Einfachste wählst, das funktioniert.

Kurze Antwort: „Zuerst ein guter Prompt. Retrieval, wenn die Antwort von Fakten abhängt, die das Modell nicht kennt oder die sich ändern. Fine-Tuning, wenn ich einen festen Stil oder ein festes Format brauche oder eine enge Aufgabe günstig erledigt haben will und gute Beispiele zum Trainieren habe.“

Die ausführliche Antwort: Retrieval fügt Wissen hinzu und hält es aktuell. Fine-Tuning bringt Verhalten bei und ist ein schlechter Weg, Fakten hinzuzufügen. LoRA ist ein günstiger Weg zum Feintunen: Statt das ganze Modell zu ändern, trainierst du einen kleinen Zusatz. Ein kleines, feingetuntes Modell kann für eine enge Aufgabe ein großes ersetzen, wenn deine Testfragen zeigen, dass die Qualität hält. Werkzeuge: PyTorch und Hugging Face oder der eigene Dienst des Anbieters. je nach Anbieter

Schwache Antwort: „Wir feintunen es auf unseren Dokumenten, damit es sie kennt.“ Nachfrage: „Die Dokumente ändern sich jede Woche.“ Dann Retrieval, weil ein feingetuntes Modell veraltet wäre.

Wie senkst du Kosten und Wartezeit?

Worauf sie achten: dass du zuerst misst und Qualität nicht unbemerkt gegen Tempo tauschst.

Kurze Antwort: „Ich messe, wohin Zeit und Tokens gehen, und schicke dann weniger Text, nutze Antworten wieder, nehme ein kleines Modell für einfache Fragen und zeige die Antwort, während sie geschrieben wird.“

Die ausführliche Antwort:

Kürzere Prompts und weniger, kürzere Textstellen.
Caching: Antworten auf wiederholte Fragen wiederverwenden und das Prompt Caching des Anbieters für einen langen, festen Anfang des Prompts nutzen. je nach Anbieter
Routing: ein kleines Modell für einfache Fragen und ein großes für schwierige.
Streaming: Die Leute sehen die ersten Wörter sofort.
Batch für Arbeit, auf die niemand wartet, oft zu einem niedrigeren Preis. je nach Anbieter

Jede Änderung läuft durch das Eval-Set, denn eine günstigere Antwort, die schlechter ist, ist keine Ersparnis.

Schwache Antwort: „Wir wechseln zum billigsten Modell.“ Nachfrage: „Woher weißt du, dass die Qualität gehalten hat?“ Aus dem Eval-Set, vorher und nachher gelaufen.

Wie bekommst du jedes Mal Antworten in einem exakten Format?

Worauf sie achten: dass du der Ausgabe des Modells nicht blind traust.

Kurze Antwort: „Ich nutze die strukturierte Ausgabe der API, wo es sie gibt, prüfe jede Antwort in meinem eigenen Code gegen das Format und frage noch einmal mit dem Fehler nach, wenn sie falsch ist.“

Die ausführliche Antwort: Halte das Format klein und einfach, mit festen Auswahlwerten, wo es geht. Zähl die Fehlschläge, damit du merkst, wenn sie zunehmen. je nach Anbieter

Schwache Antwort: „Ich bitte im Prompt freundlich um JSON.“ Nachfrage: „Es scheitert einmal in hundert Fällen.“ Die Prüfung fängt es ab, der neue Versuch behebt das meiste, und der Rest fällt auf eine sichere Antwort zurück.

Du betreibst ein offenes Modell auf deinen eigenen Servern. Was bestimmt die Hardware und das Tempo?

Worauf sie achten: dass du über Speicher, Tempo und Kosten nachdenken kannst.

Kurze Antwort: „Zuerst der Speicher: das Modell selbst plus der Speicher, den jedes laufende Gespräch braucht. Dann ein Serving-Tool, das viele Anfragen gleichzeitig bearbeitet. Dann vergleiche ich die Kosten mit einer API bei unserem echten Traffic.“

Die ausführliche Antwort: Quantisierung speichert das Modell in weniger genauen Zahlen, um Speicher und Geld zu sparen, kann aber Qualität kosten, also teste sie. Ein Serving-Tool wie vLLM bearbeitet viele Anfragen zusammen und ist dadurch viel schneller als eine nach der anderen. je nach Version Lass es in Docker auf Kubernetes mit Grafikkarten laufen und skaliere nach den wartenden Anfragen.

Schwache Antwort: „Selbst hosten ist immer billiger.“ Nachfrage: „Nachts ist wenig Traffic.“ Skaliere herunter oder nutze für die ruhigen Stunden eine API.

Sicherheit, Datenschutz und Recht

Wie wehrst du Prompt Injection in Dokumenten und Tool-Ergebnissen ab?

Worauf sie achten: dass du begrenzt, was das Modell tun kann, statt zu hoffen, dass es gehorcht.

Kurze Antwort: „Text, den das Modell liest, sind Daten, nie Befehle. Das Modell bekommt standardmäßig Tools, die nur lesen, alles, was etwas ändert, braucht das Okay der Person, und Zugriffsrechte werden in den Tools geprüft, nicht vom Modell.“

Die ausführliche Antwort: Lass das Modell keine Daten nach außen schicken, etwa in einem Link, außer die Adresse steht auf einer Allowlist. Nimm eingeschleusten Text in deine Probes auf. Die OWASP Top 10 für LLM-Anwendungen sind eine gute Checkliste.

Schwache Antwort: „Wir sagen dem Modell, dass es schlechte Anweisungen ignorieren soll.“ Nachfrage: „Ein Dokument fordert das Modell auf, eine Kundenliste per E-Mail zu verschicken.“ Das kann es nicht: Es hat kein Tool, das E-Mails sendet.

Personenbezogene Daten in einem KI-Feature: Was tust du wegen der DSGVO?

Worauf sie achten: dass du weißt, wohin die Daten gehen und wie lange sie bleiben.

Kurze Antwort: „Nur schicken, was die Aufgabe braucht, wissen, wo der Anbieter die Daten verarbeitet und speichert, Logs kurz halten und abschotten und dafür sorgen, dass das Löschen überall funktioniert, auch im Suchindex.“

Die ausführliche Antwort: Der EU AI Act ordnet Anwendungen nach ihrem Risiko ein. Die meisten Chatbots müssen sagen, dass sie eine KI sind. Anwendungen wie Personalauswahl oder Kreditvergabe gelten als hochriskant und brauchen viel mehr. Wisse, in welche Gruppe dein Feature fällt. je nach Anbieter

Schwache Antwort: „Um die DSGVO kümmert sich der Anbieter.“ Nachfrage: „Ein Kunde verlangt, gelöscht zu werden.“ Seine Daten verschwinden aus den Datensätzen, den Logs und dem Suchindex.

Grundlagen und Systemdesign

Was ist ein Embedding, und was macht Attention, in einfachen Worten?

Worauf sie achten: dass du die Grundlagen gut genug verstehst, um sie zu erklären.

Kurze Antwort: „Ein Embedding verwandelt Text in eine Liste von Zahlen, sodass Texte mit ähnlicher Bedeutung nah beieinander landen. Attention lässt jedes Wort in einem Modell auf die anderen Wörter schauen und aufnehmen, was zählt; so nutzt das Modell den Kontext.“

Die ausführliche Antwort: Rechne mit einer Nachfrage zu den Grundlagen des Machine Learning: Trainings- und Testdaten getrennt halten, auf Daten achten, die zum Zeitpunkt einer echten Vorhersage noch gar nicht existieren würden, und seltene Fälle danach beurteilen, wie viele du erwischst, nicht nach der Gesamtgenauigkeit.

Schwache Antwort: eine lange Liste von Modellnamen ohne Erklärung. Nachfrage: „Warum vergleicht man Embeddings nach dem Winkel und nicht nach dem Abstand?“ Die Richtung trägt die Bedeutung; die Länge meist nicht.

Entwirf einen Support-Chatbot für einen Versicherer, in zwei Sprachen.

Worauf sie achten: dass du die Teile zusammensetzen kannst, mit Zahlen, Grenzen und einem Plan für den Fehlerfall.

Kurze Antwort: „Ich würde mit einfachem Retrieval über die Versicherungsbedingungen anfangen, einen vorsichtigen Agenten für Fragen zum eigenen Vertrag der Person ergänzen, jede Antwort prüfen, bei Unsicherheit an Mitarbeiter übergeben und alles mit einem Testset in beiden Sprachen messen.“

Die ausführliche Antwort:

Zuerst fragen: wie viele Fragen am Tag, welche Daten, was eine falsche Antwort kostet, was an einen Menschen gehen muss.
Daten: Versicherungsbedingungen, auf beide Arten durchsucht, mit den langen Wörtern jeder Sprache sauber behandelt; Kundendaten nur über Tools, die nur lesen und prüfen, wer fragt.
Antworten: mit Quellenangaben, geprüft, in der Sprache der Person, mit einer Übergabe, wenn nichts eine Antwort belegt.
Tests: ein Satz von Fragen pro Sprache, mit Gruppen für Bedingungen, eigenen Vertrag, keine Antwort und eingeschleusten Text; ein Gate vor jedem Release.
Zahlen und Recht: Kosten pro Antwort und eine Wartezeit, vorab vereinbart; sagen, dass es eine KI ist; personenbezogene Daten in der EU halten.

Schwache Antwort: mit dem Agenten und dem neuesten Framework anfangen. Nachfrage: „Was baust du zuerst?“ Einfaches Retrieval und das Testset; der Agent und ein mögliches Fine-Tuning kommen später.

Dein Lebenslauf für diese Fragen

Jede Antwort oben fällt leichter, wenn dein Lebenslauf sie schon sagt, denn der Interviewer fragt nach dem, was darin steht. Schreib unter jede Stelle eine Zeile für jeden dieser Punkte, in den Wörtern der Anzeigen:

Skill	Schwache Zeile	Starke Zeile, mit Beleg
RAG	RAG-Pipelines gebaut.	Hybrides Retrieval über 40.000 Seiten; die richtige Seite bei 83 von 100 Testfragen unter den ersten fünf, vorher bei 61.
Evals	LLM-Evaluation.	Eval-Set mit 300 Fragen, Probes und einem Release-Gate; 3 Regressionen vor dem Release abgefangen.
Agenten	Agentische Workflows.	Agent für Bestellungen mit 3 Tools und einem Schrittlimit; Übergaben an Mitarbeiter um ein Drittel gesenkt.
Kosten	Kosten optimiert.	Routing und Caching haben die Kosten pro Antwort um 45 % gesenkt; die Testwerte haben gehalten.
Kubernetes	Docker, Kubernetes.	Ein offenes Modell auf Kubernetes betrieben, das mit der Nachfrage skaliert; Antworten unter 2 Sekunden zur Spitzenzeit.

Bewerte dann deinen Lebenslauf an einem echten Job: Du siehst, welche dieser Punkte der Job verlangt und welche dein Lebenslauf noch nicht belegt.

Das Wichtigste

Fang einfach an; lass einen Agenten nur dort mehrere Suchen planen, wo eine Suche nicht reicht.
Hybride Suche, Reranking, Chunking entlang der Überschriften und geprüfte Quellenangaben sind der Kern guter Antworten zum Retrieval.
Jeder Agent braucht ein Schrittlimit, ein Token-Budget, ein Zeitlimit und einen Plan B.
Evals sind ein Gate vor dem Release: Eval-Sets, Probes, Schutz gegen einen unzuverlässigen Bewerter, Regressionsprüfungen und Budgets.
Belege jede Antwort mit einer Zeile im Lebenslauf, in der eine Zahl steht.

Häufige Fragen

Was wird im Vorstellungsgespräch als Machine Learning Engineer am häufigsten gefragt?: Wie du Features auf Sprachmodellen baust: Retrieval und RAG, Agenten und Tools, Evaluation, Kosten und Tempo und Sicherheit. Programmierrunden sind meist gewöhnliches Python.
Muss ich LangChain oder LangGraph kennen?: Eines davon zu kennen hilft, und manche Anzeigen nennen sie. Im Interview wird geprüft, ob du verstehst, was so ein Framework im Hintergrund tut: die Schritte, die Grenzen, die Suche.
Wie tief geht die Theorie des Machine Learning?: Für Rollen, die KI in Produkte bringen, die Grundlagen: Embeddings, Attention in einfachen Worten, Testdaten, einfache Kennzahlen. Rollen in Forschung und Plattform gehen tiefer.
Wie bereite ich mich in einer Woche vor?: Bau ein kleines Retrieval-Projekt mit Testset oder nimm ein altes wieder auf, sag die beiden ausgearbeiteten Antworten laut und bereite zu jedem Abschnitt eine Geschichte über einen Fehlschlag vor.
Sind diese Antworten an einen Anbieter gebunden?: Nein. Wo ein Detail von einem Anbieter oder einer Version abhängt, ist es markiert, damit du die aktuelle Dokumentation prüfen kannst.

So nutzt du diese Fragen

Was ein Machine Learning Engineer können muss

Retrieval und RAG

Wie baust du agentische Suche und agentisches Retrieval in einem Chatbot auf?

Wie entscheidest du, wie Dokumente in Chunks aufgeteilt werden?

Stichwortsuche, Vektorsuche oder beides? Wann nimmst du einen Reranker dazu?

Wie bringst du das Modell dazu, seine Quellen anzugeben, und wie prüfst du, dass die Quellenangaben echt sind?

Agenten und Tools

Wie entwirfst du die Tools, die ein Agent aufrufen kann?

Wie verhinderst du, dass ein Agent in Schleifen läuft, und wie begrenzt du Kosten und Zeit?

Wie baust du einen Harness, der robust ist und jeden Schritt abdeckt?

Evaluation

Welche Schritte braucht die Evaluation eines LLM-Features, etwa mit Probes für die Evals?

Wie nutzt du ein LLM als Bewerter, ohne dich von ihm in die Irre führen zu lassen?

Was testest du vor dem Release, und was beobachtest du in der Produktion?

Modelle, Kosten und Tempo

Prompting, Retrieval oder Fine-Tuning: Wann nutzt du was?

Wie senkst du Kosten und Wartezeit?

Wie bekommst du jedes Mal Antworten in einem exakten Format?

Du betreibst ein offenes Modell auf deinen eigenen Servern. Was bestimmt die Hardware und das Tempo?

Sicherheit, Datenschutz und Recht

Wie wehrst du Prompt Injection in Dokumenten und Tool-Ergebnissen ab?

Personenbezogene Daten in einem KI-Feature: Was tust du wegen der DSGVO?

Grundlagen und Systemdesign

Was ist ein Embedding, und was macht Attention, in einfachen Worten?

Entwirf einen Support-Chatbot für einen Versicherer, in zwei Sprachen.

Dein Lebenslauf für diese Fragen

Das Wichtigste

Häufige Fragen

Mehr zu diesem Beruf