Projekty do portfolio Data Scientist — pomysły i przykłady
Jak zbudować portfolio Data Scientist: pomysły na projekty, tabela oceny projektu, przykład na publicznych danych i lista kontrolna przed publikacją.
Zespół LearnIT
Krótka odpowiedź
Dobre portfolio Data Scientist to 2–4 dopracowane projekty pokazujące pełen proces: od pozyskania i czyszczenia surowych danych, przez eksplorację i wizualizację, po model uczenia maszynowego z interpretacją wyników. Każdy projekt opisz czytelnie (problem, dane, wnioski) i opublikuj kod na GitHubie z porządnym README. Lepiej 2–3 dopracowane projekty niż 10 powierzchownych — rekruterzy cenią umiejętność opowiedzenia historii z danych.
Spis treści · 8
Dobre portfolio przekonuje pracodawcę szybciej niż lista kursów. Pokazuje, że potrafisz przejść całą drogę: od surowych danych po wnioski i model. Poniżej — co w nim umieścić, jak ocenić własny projekt przed publikacją i jak wygląda przykład, który da się sprawdzić.
Co powinno znaleźć się w portfolio?
- 2–4 projekty pokazujące różne umiejętności,
- czytelny opis problemu, danych i wniosków,
- kod (np. na GitHubie) i wizualizacje,
- krótkie podsumowanie „co i dlaczego” dla nietechnicznych odbiorców.
Pomysły na projekty
- Analiza i wizualizacja — eksploracja publicznego zbioru danych (miejskich, sportowych, finansowych) z wnioskami.
- Model predykcyjny — klasyfikacja lub regresja, np. przewidywanie odejść klientów albo prognoza sprzedaży, z oceną jakości modelu.
- Przetwarzanie tekstu / NLP — analiza opinii lub klasyfikacja wiadomości (spam, sentyment) z metrykami.
- Dashboard — interaktywna prezentacja wyników dla nietechnicznego odbiorcy.
Jak ocenić projekt przed publikacją?
Rekruter albo prowadzący patrzy na projekt pod tymi samymi kątami. Przejdź przez tabelę — każdy wiersz powinien mieć w repozytorium konkretne miejsce, w którym go widać.
| Kryterium | Co pokazać | Sygnał ostrzegawczy |
|---|---|---|
| Problem | jedno pytanie, na które projekt odpowiada, i komu ta odpowiedź się przyda | „analiza zbioru X” bez pytania |
| Pochodzenie danych | źródło z linkiem, data pobrania, licencja, opis kolumn | plik CSV bez źródła |
| Czyszczenie | braki, duplikaty, błędne wartości — co zrobiłeś i dlaczego | dane „od razu gotowe” |
| Baseline | najprostsze rozwiązanie, z którym porównujesz model | model bez punktu odniesienia |
| Metryki | metryka dobrana do problemu i wynik na danych, których model nie widział | sama dokładność przy niezrównoważonych klasach |
| Wyciek danych | podział danych, który nie przemyca przyszłości do treningu | losowy podział szeregu czasowego |
| Powtarzalność | plik z wersjami bibliotek, ustalone ziarno losowości, instrukcja uruchomienia | „u mnie działa” |
| README | problem, dane, metoda, wynik i ograniczenia na jednej stronie | README z samym tytułem |
| Od notebooka do aplikacji | kod przeniesiony z notebooka do modułów, skrypt lub proste API zwracające wynik | jeden notebook na dwieście komórek |
Przykład projektu, który da się sprawdzić
To szkic projektu na publicznych danych — nie gotowa praca kursanta, tylko wzór, jak mogłoby to wyglądać. Każdy element da się zweryfikować, bo dane są otwarte.
- Pytanie: czy da się przewidzieć dobowe stężenie PM10 w Krakowie na następny dzień lepiej niż przy założeniu, że „jutro będzie jak dziś”?
- Dane: archiwalne wyniki pomiarów jakości powietrza Głównego Inspektoratu Ochrony Środowiska (powietrze.gios.gov.pl) i dane meteorologiczne IMGW (danepubliczne.imgw.pl) — w README z datą pobrania.
- Baseline: wartość z dnia poprzedniego.
- Kontrola wycieku: podział w czasie — trening na starszych latach, test na ostatnim roku; żadnych cech z dnia, który model ma przewidzieć.
- Metryka: średni błąd bezwzględny (MAE) porównany z baseline'em.
- Co pokazać: README z wykresem prognozy na okresie testowym, opisem ograniczeń (np. braków w pomiarach) i skryptem, który odtwarza wynik jednym poleceniem.
Lista kontrolna przed publikacją
- README w pierwszym akapicie mówi, jaki problem, jakie dane i jaki wynik,
- źródło danych ma link i datę pobrania,
- jest baseline i wynik modelu na danych testowych,
- podział danych wyklucza wyciek,
- projekt uruchamia się w czystym środowisku według instrukcji,
- w repozytorium nie ma haseł, kluczy ani danych osobowych,
- historia commitów pokazuje, jak projekt powstawał — nie jeden commit z gotowym wynikiem.
Najczęstsze błędy
- tylko notebook bez opisu i wniosków,
- brak czyszczenia danych — pokaż ten etap, to realna praca,
- kopiowanie gotowych tutoriali bez własnego wkładu,
- wynik bez porównania z czymkolwiek — wysoka trafność nic nie znaczy bez baseline'u,
- ocena modelu na danych, na których był trenowany.
Co jest dowodem własnej pracy?
Rekruter nie sprawdzi, kto napisał kod, ale widzi ślady procesu. Przekonują: historia commitów rozłożona w czasie, decyzje opisane w README („spróbowałem X, nie zadziałało, bo…”), własne pytanie postawione publicznemu zbiorowi danych i umiejętność omówienia każdego kroku na rozmowie. Nie przekonują: jeden commit z gotowym projektem i wynik identyczny z popularnym tutorialem.
Skąd brać projekty? Najlepiej z kursu z realnymi danymi — plan opisaliśmy w artykule Data Science od podstaw, a samą rolę w tekście jak zostać Data Scientistem.
Gdzie publikować portfolio?
Najlepiej GitHub (kod i README) i krótki opis na LinkedIn. Jak przygotować repozytorium i profil, opisaliśmy w tekście portfolio na GitHubie. Projekty z realnymi danymi zbudujesz na kursie Data Science.
Chcesz budować portfolio pod okiem praktyków? Sprawdź kurs Data Science — projekty trafiają do Twojego portfolio.
Chcesz nauczyć się analizy danych i Data Science?
Przejdź od teorii do praktyki pod okiem mentorów. Sprawdź kurs Data Science w LearnIT.
Zobacz kurs Data Science
