Projekty dotyczące uczenia maszynowego wymagają zespołów, których członkowie mają różne umiejętności, doświadczenie i obowiązki związane z uczeniem maszynowym. Oto najpopularniejsze role w typowych zespołach zajmujących się uczeniem maszynowym:
| Rola | Wiedza i umiejętności | Główny element do dostarczenia |
|---|---|---|
| Menedżer produktu ML | Menedżerowie ds. usług opartych na ML mają dogłębną wiedzę o mocnych i słabych stronach tej technologii oraz procesie jej rozwoju. Dopasowują rozwiązania oparte na ML do problemów biznesowych, współpracując bezpośrednio z zespołem ds. uczenia maszynowego, użytkownikami końcowymi i innymi zainteresowanymi osobami. Tworzą oni wizję produktu, definiują przypadki użycia i wymagania oraz planują projekty i nadają im priorytety. |
Dokument wymagań usługi (PRD). |
| Menedżer ds. inżynieryjnych | Menedżerowie ds. inżynierii osiągają cele biznesowe, ustalając priorytety zespołu, komunikując je i realizując je. Podobnie jak menedżerowie ds. produktów w zakresie uczenia maszynowego, dopasowują oni rozwiązania do problemów biznesowych. określają jasne oczekiwania wobec członków zespołu, przeprowadzają oceny wyników i pomagają w rozwoju zawodowym; |
dokumenty projektowe, plany projektów i oceny wyników. |
| badacz danych, | Badacze danych korzystają z analizy ilościowej i statystycznej, aby wydobywać z danych informacje i wartość. Pomagają identyfikować i testować cechy, prototypować modele oraz zwiększać interpretowalność modeli. | raporty i wizualizacje danych, które odpowiadają na pytania biznesowe za pomocą analizy statystycznej; |
| Inżynier systemów uczących się | Inżynierowie systemów uczących się projektują, tworzą, wprowadzają do produkcji i zarządzają modelami systemów uczących się. To doświadczeni inżynierowie oprogramowania, którzy dobrze znają technologie i sprawdzone metody związane z systemami uczącymi się. | Wdrożony model o wystarczającej jakości prognoz, aby spełniać cele biznesowe. |
| Inżynier danych | Inżynierowie danych tworzą potoki danych do przechowywania, agregowania i przetwarzania dużych ilości danych. Tworzą infrastrukturę i systemy do zbierania oraz przetwarzania danych nieprzetworzonych w przydatne formaty do trenowania i wyświetlania modeli. Inżynierowie danych odpowiadają za dane w całym procesie tworzenia systemów uczących się. | w pełni produkcyjne potoki danych z niezbędnym monitorowaniem i ostrzeganiem. |
| Inżynier ds. obsługi programistów (DevOps) | Inżynierowie DevOps opracowują, wdrażają, skalują i monitorują infrastrukturę służącą do obsługi modeli ML. | Automatyczny proces obsługi, monitorowania, testowania i ostrzegania o zachowaniu modelu. |
W przypadku udanych projektów dotyczących uczenia się maszynowego zespoły muszą zawierać odpowiednią liczbę osób na każdą z tych ról. W mniejszych zespołach poszczególne osoby będą musiały pełnić obowiązki związane z wieloma rolami.
Ustalanie zasad dotyczących pracy zespołowej
Ponieważ role, narzędzia i ramy są bardzo zróżnicowane w rozwoju ML, ważne jest, aby ustalić wspólne praktyki poprzez dokładną dokumentację procesów. Na przykład jeden inżynier może uważać, że do rozpoczęcia trenowania modelu wystarczy pozyskanie odpowiednich danych, podczas gdy bardziej odpowiedzialny inżynier sprawdzi, czy zbiór danych jest prawidłowo anonimizowany, oraz udokumentuje jego metadane i pochodzącość. Upewnij się, że inżynierowie używają wspólnych definicji procesów i wzorców projektowych. Pomoże to uniknąć nieporozumień i zwiększy wydajność zespołu.
Dokumentacja procesu
Dokumentacja procesów powinna określać narzędzia, infrastrukturę i procesy, których zespół będzie używać do tworzenia rozwiązań opartych na ML. Dobre dokumenty procesów pomagają dostosować się nowym i obecnym członkom zespołu. Powinny one odpowiadać na te typy pytań:
- Jak są generowane dane dla modelu?
- Jak sprawdzamy, weryfikujemy i wizualizujemy dane?
- Jak zmodyfikować cechę wejściową lub etykietę w danych treningowych?
- Jak dostosowujemy łańcuch generowania danych, trenowania i oceny?
- Jak zmienić architekturę modelu, aby uwzględnić zmiany w wprowadzanych cechach lub etykietach?
- Jak uzyskać przykłady testów?
- Których danych użyjemy do oceny jakości modelu?
- Jak wdrażamy modele w produkcji?
- Skąd będziemy wiedzieć, że coś jest nie tak z naszym modelem?
- Od jakich systemów zewnętrznych zależą nasze modele?
- Jak sprawić, aby kod SQL był łatwy w utrzymaniu i wielokrotnym użyciu?
Więcej potencjalnych pytań
ModelCzy mogę trenować modele na różnych zbiorach danych w ramach tego samego procesu, np. w celu dostosowania do własnych potrzeb?
Jak dodać nowy testowy zbiór danych do potoku?
Jak sprawdzić prognozę modelu na przykładzie ręcznie przygotowanym?
Jak znaleźć, sprawdzić i wizualizować przykłady, w których model popełnił błędy?
Jak mogę określić, która cecha miała największy wpływ na daną prognozę?
Jak określić, które cechy mają największy wpływ na prognozy w danej próbce?
Jak obliczyć lub narysować prognozy modelu na wybranym zbiorze danych lub próbce?
Jak obliczyć standardowe dane dla prognoz modelu na wybranym zbiorze danych?
Jak opracowywać i obliczać dane niestandardowe?
Jak porównać mój model z innymi modelami w trybie offline?
Czy mogę przeprowadzić metaanalizę w przypadku wielu ocen modeli w jednym środowisku programistycznym?
Czy mogę porównać bieżący model z modelem sprzed 10 miesięcy?
Myślę, że udało mi się utworzyć dobry model. Jak mogę wdrożyć go w wersji produkcyjnej?
Jak sprawdzić, czy nowy model działa prawidłowo w produkcji?
Czy mogę uzyskać historię ocen modelu na przestrzeni czasu?
Jak dowiem się, że coś jest nie tak z modelem?
Przypisano mi stronę lub błąd, w których coś wspomina o tym modelu. Co mam zrobić?
Jak mogę dostosować potok generowania/trenowania/oceny danych?
Kiedy i jak utworzyć zupełnie nowy potok?
Potrzebuję SQL do wygenerowania danych. Gdzie mam go umieścić?
Jak działa wyświetlanie modeli? Czy masz diagram?
Od jakich systemów zewnętrznych zależy mój model i co powinienem wiedzieć na ich temat?
Nie mogę czegoś zrozumieć. Z kim (i jak) mogę się skontaktować?
Pamiętaj
To, co stanowi „sprawdzone metody dotyczące uczenia maszynowego”, może się różnić w zależności od firmy, zespołu lub osoby. Na przykład niektórzy członkowie zespołu mogą uznać eksperymentalne Colabs za główny produkt, a inni wolą pracować w R. Ktoś może pasjonować się inżynierią oprogramowania, ktoś inny uważa, że monitoring jest najważniejszy, a jeszcze inna osoba zna dobre metody produkcji funkcji, ale chce używać Scala. Każdy ma „rację” ze swojej perspektywy, a jeśli wszystko pójdzie zgodnie z planem, mix będzie potężny. W przeciwnym razie może to być kłopotliwe.
Wybór narzędzi, procesów i infrastruktury, których zespół będzie używać, zanim napisze choćby jeden wiersz kodu, może przesądzić o tym, czy projekt zakończy się niepowodzeniem po 2 latach, czy też zostanie uruchomiony o kwartał wcześniej.
Oceny skuteczności
Ze względu na niejednoznaczność i niepewność związaną z systemami uczącymi się menedżerowie zespołów muszą jasno określać oczekiwania i wymagania dotyczące wyników.
Określając oczekiwania i wyniki, zastanów się, jak będą oceniane, jeśli projekt lub podejście nie przyniesie oczekiwanych rezultatów. Inaczej mówiąc, ważne jest, aby wyniki członka zespołu nie były bezpośrednio powiązane z sukcesem projektu. Na przykład członkowie zespołu często spędzają tygodnie na badaniu rozwiązań, które ostatecznie okazują się nieskuteczne. Nawet w takich przypadkach ich wysoka jakość kodu, rzetelna dokumentacja i skuteczna współpraca powinny pozytywnie wpłynąć na ocenę.