Projekty do portfolio Data Scientist — pomysły i przykłady

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

1. Analiza i wizualizacja — eksploracja publicznego zbioru danych (miejskich, sportowych, finansowych) z wnioskami.
2. Model predykcyjny — klasyfikacja lub regresja, np. przewidywanie odejść klientów albo prognoza sprzedaży, z oceną jakości modelu.
3. Przetwarzanie tekstu / NLP — analiza opinii lub klasyfikacja wiadomości (spam, sentyment) z metrykami.
4. 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ć.

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.

Pierwszy projekt machine learning: baseline przed modelem

Pierwszy projekt z modelem łatwo zacząć od końca — od wyboru algorytmu. Lepsza kolejność wygląda tak:

1. Zdefiniuj zadanie — co przewidujesz, w którym momencie prognoza ma być dostępna i jaki błąd jest najdroższy.
2. Zbuduj baseline — dla klasyfikacji najczęstsza klasa, dla prognozy liczbowej średnia albo wartość z poprzedniego okresu. Zapisz jego wynik na danych testowych.
3. Dodaj najprostszy model — np. regresję liniową lub logistyczną. Porównaj z baseline'em tą samą metryką i na tym samym podziale danych.
4. Dopiero potem komplikuj — bardziej złożony model ma sens, jeśli poprawia wynik w sposób, który da się wyjaśnić, a nie tylko o ułamek w jednym przebiegu.
5. Opisz, co nie zadziałało — odrzucone cechy i modele w README pokazują sposób myślenia lepiej niż sam najlepszy wynik.

To opis procedury, a nie gotowego repozytorium: przejdź ją na własnym zbiorze, np. w projekcie z prognozą PM10 opisanym wyżej.

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.

Co zobaczy czytelnik przez pierwszą minutę?

Otwórz repozytorium w oknie prywatnym i przeczytaj tylko pierwszą część README. Czy od razu wiadomo, na jakie pytanie odpowiada projekt, kto mógłby wykorzystać wynik i co właściwie udało się ustalić? Nie chowaj ograniczeń za technicznym słownikiem. Zamiast „zastosowałem XGBoost” napisz, jaki problem rozwiązujesz, z czym porównujesz model i kiedy wynik zawodzi. Jeżeli odpowiedź wymaga przejrzenia całego notebooka, dodaj krótki opis na górze.

Czy inna osoba odtworzy wynik bez Twojego komputera?

Zapisz wersje zależności i instrukcję uruchomienia w czystym środowisku. Wskaż, skąd pobrać dane i czy licencja pozwala na ich dołączenie do repozytorium. Jeśli nie pozwala, podaj procedurę pobrania i strukturę oczekiwanych plików, bez publikowania samego zbioru. Uruchom instrukcję od początku, nie korzystając ze zmiennych zapisanych w starej sesji notebooka. Notuj błąd instalacji i popraw instrukcję; to część projektu, nie kompromitacja.

Gdzie najłatwiej ukryć wyciek danych?

Zobacz, czy skalowanie, imputacja i dobór cech były dopasowane wyłącznie na danych treningowych. Przy danych czasowych ustal moment prognozy i odrzuć cechy dostępne dopiero później. Jeżeli zbiór ma kilka rekordów tej samej osoby lub jednostki, losowy podział wierszy może przenieść jej informacje między próbami. W README opisz, dlaczego zastosowano konkretny podział; nie podawaj jednej metryki bez kontekstu.

Jak przetłumaczyć metrykę na decyzję?

Przedstaw prosty baseline oraz metrykę dobraną do kosztu pomyłki. Jeżeli pominięcie rzadkiego zdarzenia jest drogie, sama accuracy niewiele wyjaśnia. Dodaj krótką analizę błędów: przykłady obserwacji, na których model zawodzi, bez ujawniania danych identyfikujących osoby. Nie przypisuj projektowi „wpływu na biznes”, jeżeli nie było wdrożenia ani pomiaru decyzji. Możesz napisać, jak należałoby ten wpływ przetestować.

Co usunąć przed publikacją i jak opisać własny wkład?

Sprawdź historię commitów, pliki konfiguracyjne i output notebooków: token mógł trafić do starszej wersji nawet po usunięciu z bieżącego pliku. Nie publikuj danych klientów, cudzych rozwiązań ani wygenerowanych opisów, których nie umiesz wyjaśnić. Zaznacz, które decyzje były Twoje: definicja problemu, analiza błędów, odrzucone pomysły. Przy projekcie grupowym rozdziel role. Jeśli recenzent pyta „dlaczego tak?”, powinieneś umieć odpowiedzieć bez powtarzania README.

Praktykę można skonfrontować z programem kursu Data Science, a kolejność nauki ustalić według planu od podstaw. Jeśli rozważasz naukę z pomocą programu finansowania, sprawdź warunki dofinansowania; link nie oznacza automatycznej kwalifikacji.

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.