Bei einer Bewerbung um ein KI-Praktikum haben alle dieselben Vorlesungen gehört. Was übrig bleibt, um sich zu unterscheiden, sind die Dinge, die du daneben gebaut hast. Deshalb schaut fast jeder Fachbereich zuerst dorthin.
Warum Kursprojekte wenig zählen
Ein Notebook zum Titanic-Datensatz, eine Ziffernerkennung auf MNIST, eine Hauspreisvorhersage aus Boston - diese drei Projekte hat jeder gemacht, der einen Onlinekurs abgeschlossen hat. Sie zeigen, dass du einer Anleitung folgen kannst. Mehr nicht.
Das ist kein Vorwurf, sondern eine Einordnung. Solche Aufgaben sind zum Lernen gut. Als Aushängeschild taugen sie nicht, weil bei ihnen jede interessante Entscheidung bereits getroffen wurde: Die Daten sind sauber, die Fragestellung steht, die Metrik ist vorgegeben. Genau diese Entscheidungen sind aber die Arbeit.
Was ein gutes Projekt ausmacht
Drei Eigenschaften machen den Unterschied.
Eigene Daten. Nicht zwingend selbst erhoben, aber auch nicht aus dem Kurs. Ein öffentlicher Datensatz, den du selbst gefunden hast, reicht schon. Noch besser: Daten, die du selbst zusammengetragen hast - aus einer öffentlichen Schnittstelle, aus einem Verein, aus einem eigenen Messaufbau. Wer einmal gemerkt hat, wie schmutzig echte Daten sind, argumentiert im Gespräch anders.
Eine eigene Frage. Nicht "ein Modell trainieren", sondern eine Frage, die dich interessiert hat. Wie gut lässt sich der Ausgang eines Spiels vorhersagen? Kann man aus Fahrplandaten Verspätungen prognostizieren? Lässt sich erkennen, ob ein Text von einem Sprachmodell stammt? Die Frage muss nicht weltbewegend sein, sie muss deine sein.
Ein ehrliches Ergebnis. Ein Projekt, das mit "hat leider nicht funktioniert, hier ist warum" endet, ist besser als eines mit 99 Prozent Genauigkeit und einem Datenleck darin. Fachleute erkennen zu gute Zahlen sofort - und dann geht das Gespräch in eine Richtung, die du nicht willst.
Die Baseline ist das halbe Projekt
Der wirksamste Trick, um aus einem Kursprojekt ein echtes zu machen: Bau zuerst die einfachste denkbare Lösung.
Bei einer Vorhersage ist das oft der Mittelwert, bei einer Klassifikation die häufigste Klasse, bei Zeitreihen der Wert von gestern. Diese Baseline misst du sauber - und danach zeigst du, ob dein Modell sie schlägt.
Erstaunlich oft ist der Abstand kleiner als erwartet. Genau das ist ein wertvolles Ergebnis: Es zeigt, dass du die Frage stellst, die in Unternehmen ständig gestellt wird und in Kursen nie vorkommt.
Die README entscheidet
Die meisten Projekte scheitern nicht am Code, sondern daran, dass niemand versteht, worum es geht. Eine README, die jemand in zwei Minuten liest, ist wichtiger als jede Modellwahl.
Was hineingehört:
- Worum geht es? Zwei Sätze, ohne Fachjargon.
- Welche Daten? Herkunft, Umfang, Zeitraum, bekannte Einschränkungen.
- Wie bist du vorgegangen? Baseline, Verfahren, Metrik - und warum diese Metrik.
- Was kam heraus? Eine Tabelle mit Baseline und Modell nebeneinander.
- Was ist offen? Was du weißt, aber nicht gemacht hast.
Der letzte Punkt wirkt seltsam und ist stark. Wer die Grenzen des eigenen Projekts benennt, wirkt souveräner als jemand, der so tut, als wäre alles gelöst.
Ein oder zwei Abbildungen helfen enorm: eine Verteilung der Daten, ein Vergleich der Ergebnisse. Bilder werden angesehen, Code oft nicht.
Wie viele Projekte?
Zwei bis drei ordentliche schlagen zehn halbfertige. Wenn dein GitHub-Profil aus fünfzehn Übungsordnern besteht, archiviere die meisten davon und lass die guten stehen.
Für ein Portfolio ist eine gute Mischung:
- Ein Datenprojekt mit eigener Fragestellung, Baseline und ehrlicher Auswertung
- Ein Anwendungsprojekt, bei dem etwas Benutzbares herauskommt - ein kleines Werkzeug, eine Oberfläche, ein Dienst
- Optional ein Vertiefungsprojekt in der Richtung, in die du willst: ein Sprachmodell-Prototyp, eine Bildverarbeitungsaufgabe, eine Datenpipeline
Das Anwendungsprojekt wird häufig vergessen und ist wertvoll. Wer zeigen kann, dass sein Modell nicht nur im Notebook lief, sondern über eine Schnittstelle erreichbar war, beantwortet eine Frage, die im Gespräch garantiert kommt.
Was sofort negativ auffällt
Notebooks ohne Struktur. Vierhundert Zellen, Ausgaben aus drei Sitzungen, Variablen namens df2_final. Räum auf oder überführe es in Skripte.
Zu gute Zahlen ohne Erklärung. 99 Prozent auf einem realen Problem ist ein Warnsignal. Wenn es stimmt, erkläre warum. Wenn du es nicht erklären kannst, such den Fehler.
Kopierter Code ohne Hinweis. Sich an einer Vorlage zu orientieren ist völlig in Ordnung - sie als eigene Arbeit auszugeben nicht. Ein Satz in der README genügt.
Datensätze mit Personenbezug. Wer echte Daten von Menschen öffentlich in ein Repository legt, disqualifiziert sich - besonders bei Unternehmen, die selbst mit sensiblen Daten arbeiten.
Wenn die Zeit knapp ist
Ein brauchbares Portfolioprojekt braucht kein Semester. Zwei Wochenenden reichen für etwas Vorzeigbares:
Am ersten Wochenende suchst du dir einen Datensatz zu einem Thema, das dich interessiert, und beantwortest eine einzige Frage - mit Baseline, einem Modell und einer sauberen Auswertung. Am zweiten Wochenende schreibst du die README, machst zwei Abbildungen und räumst den Code auf.
Das Ergebnis wird kein Forschungsbeitrag. Es wird aber zeigen, dass du eigenständig arbeiten kannst - und das ist genau die Frage, die dein Gegenüber beantwortet haben möchte.
Der eigentliche Punkt
Ein Portfolio ist kein Leistungsnachweis, sondern eine Arbeitsprobe. Es soll nicht zeigen, dass du viel weißt, sondern wie du vorgehst, wenn niemand dir sagt, was zu tun ist. Wer das verstanden hat, baut andere Projekte - und deutlich überzeugendere.
Bereit für den nächsten Schritt?
Setz dein Wissen direkt ein und finde einen freien KI-Praktikum in deiner Nähe – kostenlos und ohne Anmeldung.
KI-Praktika finden