Wróć do zasobów
Guides & Templates
Zarządzanie produktem AI: od wyboru modelu po architekturę danych
Starszy Techniczny Product Manager AI i Architekt Machine Learningu
Cel: Kompleksowy, praktyczny przewodnik edukacyjny, którego celem jest przekształcenie Product Managera w lidera technicznego dla produktów opartych na AI, ze szczególnym uwzględnieniem branż o wysokim ryzyku, takich jak Fintech i Travel.
Moduł 1: Taksonomia i wybór modeli
Zrozumienie krajobrazu modeli AI to podstawa zestawu narzędzi każdego technicznego PM-a.
Rodzaje modeli
- SLM (małe modele językowe): Lekkie, szybkie, efektywne kosztowo. Idealne do klasyfikacji, podsumowań i wnioskowania na urządzeniach końcowych. Przykłady: Phi-3, Gemma.
- LLM (duże modele językowe): Szeroka wiedza, duża zdolność do generalizacji. Najlepsze do złożonego generowania treści, wieloturowych konwersacji i zadań kreatywnych. Przykłady: GPT-4, Claude, Gemini.
- Modele rozumujące (w stylu o1): Zoptymalizowane pod kątem wieloetapowego logicznego rozumowania i rozwiązywania problemów typu „chain-of-thought”. Najlepsze do złożonych analiz, generowania kodu i rozumowania matematycznego.
- Modele wizyjne: Przetwarzają i rozumieją obrazy wraz z tekstem. Niezbędne do OCR dokumentów, inspekcji wizualnej i zastosowań multimodalnych.
Macierz decyzyjna
| Przypadek użycia | Fintech | Travel | Zalecany typ modelu |
|---|---|---|---|
| Wykrywanie oszustw | Analiza wzorców transakcji | Wykrywanie anomalii w rezerwacjach | SLM / Model rozumujący |
| Obsługa klienta | Zapytania o konto, Q&A dot. zgodności z przepisami | Zmiany rezerwacji, porady podróżne | LLM |
| Przetwarzanie dokumentów | Weryfikacja dokumentów KYC | OCR paszportów/wiz | Model wizyjny |
| Złożona analiza | Ocena ryzyka, zgodność z regulacjami | Dynamiczne ceny, optymalizacja planu podróży | Model rozumujący |
| Generowanie treści | Generowanie raportów | Opisy planów podróży, przewodniki turystyczne | LLM |
Lista kontrolna dla PM-ów
- Zdefiniuj główne zadanie (klasyfikacja, generowanie, rozumowanie, wizja)
- Oceń wymagania dotyczące opóźnień (czas rzeczywisty vs. przetwarzanie wsadowe)
- Oszacuj ograniczenia kosztowe i oczekiwany wolumen
- Ustal, czy kluczowa jest wiedza specyficzna dla danej domeny
- Weź pod uwagę wymogi regulacyjne i dotyczące zgodności
Moduł 2: Hosting i infrastruktura
Hosting lokalny
Narzędzia: Ollama, vLLM, llama.cpp
Wymagania sprzętowe:
- Modele 7B parametrów: 8GB+ RAM, konsumenckie GPU (RTX 3060+)
- Modele 13B parametrów: 16GB+ RAM, GPU średniej klasy (RTX 3090+)
- Modele 70B+ parametrów: 64GB+ RAM, GPU klasy enterprise (A100, H100)
Kiedy używać: Prototypowanie, aplikacje z danymi wrażliwymi, środowiska izolowane (air-gapped), optymalizacja kosztów przy dużej skali.
Hosting w chmurze
Ekosystem Hugging Face:
- Spaces: Szybkie dema i prototypy z Gradio/Streamlit
- Inference Endpoints: Produkcyjne, automatycznie skalujące się serwowanie modeli
- Zalety: Ogromna biblioteka modeli, wsparcie społeczności, elastyczne ceny
Dostawcy zarządzani (OpenAI, Anthropic, Google):
- Zalety: Najkrótszy czas do wdrożenia na produkcję, zarządzana infrastruktura, umowy SLA na poziomie enterprise
- Wady: Obawy dotyczące prywatności danych, uzależnienie od dostawcy (vendor lock-in), mniejsza możliwość personalizacji
Kwantyzacja
Kwantyzacja zmniejsza precyzję modelu (np. z FP16 do INT8 lub INT4), aby zmniejszyć zużycie pamięci i zwiększyć prędkość.
- FP16: Pełna precyzja, najwyższa jakość, najwyższy koszt
- INT8: Redukcja pamięci o ~50%, minimalna utrata jakości
- INT4: Redukcja pamięci o ~75%, zauważalny kompromis w jakości
Wpływ: Model 70B w precyzji FP16 wymaga ~140GB VRAM. W precyzji INT4 mieści się w ~35GB, co umożliwia uruchomienie go na pojedynczej karcie A100.
Lista kontrolna dla PM-ów
- Oblicz oczekiwany wolumen zapytań i umowy SLA dotyczące opóźnień
- Oceń wymagania dotyczące rezydencji i prywatności danych
- Porównaj całkowity koszt posiadania: chmurowe API vs. self-hosting
- Zaplanuj skalowanie: automatycznie skalujące się punkty końcowe vs. stała infrastruktura
- Oceń zdolność zespołu do zarządzania infrastrukturą
Moduł 3: Drzewo decyzyjne optymalizacji
Schemat
Zacznij tutaj: Czy wiedza bazowego modelu jest wystarczająca?
|
+-- TAK --> Czy format/styl odpowiedzi jest poprawny?
| |
| +-- TAK --> Użyj bez zmian (ewentualnie lekki Prompt Engineering)
| +-- NIE --> Prompt Engineering (prompty systemowe, przykłady few-shot)
|
+-- NIE --> Czy model potrzebuje dostępu do TWOICH danych?
|
+-- TAK, a dane często się zmieniają --> RAG
+-- TAK, i jest to stabilna wiedza domenowa --> Fine-tuning
+-- Potrzebujesz zupełnie nowej zdolności --> Pełny pre-training (rzadkie, kosztowne)
Kluczowe rozróżnienie techniczne
Aktualizacja wag modelu (Fine-tuning):
- Trwale zmienia zachowanie modelu
- Wymaga danych treningowych i mocy obliczeniowej
- Wiedza staje się „wbudowana” w model
- Jak uczenie kogoś nowej umiejętności
Aktualizacja bazy wiedzy (RAG):
- Zachowanie modelu pozostaje bez zmian
- Nowe informacje są pobierane w czasie zapytania
- Wiedza jest zewnętrzna i łatwa do aktualizacji
- Jak danie komuś książki jako źródła informacji
Tabela porównawcza
| Podejście | Koszt | Wysiłek | Najlepsze dla |
|---|---|---|---|
| Prompt Engineering | Niski | Godziny | Format, ton, proste instrukcje zadania |
| RAG | Średni | Dni-Tygodnie | Dynamiczne dane, dokumenty firmowe, FAQ |
| Fine-tuning | Wysoki | Tygodnie | Wiedza domenowa, spójny styl |
| Pre-training | Bardzo wysoki | Miesiące | Całkowicie nowy język lub dziedzina |
Lista kontrolna dla PM-ów
- Zawsze zaczynaj od prompt engineeringu przed eskalacją
- Dokumentuj, kiedy prompt engineering osiąga swoje granice
- W przypadku RAG: zidentyfikuj źródła danych i częstotliwość ich aktualizacji
- W przypadku fine-tuningu: przygotuj co najmniej 1000+ przykładów wysokiej jakości
- Zawsze porównuj wyniki z modelem bazowym
Moduł 4: Architektura danych
Kiedy wystarczy tradycyjna baza danych (SQL/JSON)?
- Ustrukturyzowane, tabelaryczne dane o znanych schematach
- Zapytania o dokładne dopasowanie (profile użytkowników, transakcje, rezerwacje)
- Wymagania zgodności z ACID (zapisy finansowe)
- Proste filtrowanie, sortowanie i agregacja
Przykład: Historia rezerwacji klienta, rejestry transakcji, preferencje użytkownika.
Kiedy konieczna jest wektorowa baza danych?
Wektorowe bazy danych są niezbędne, gdy potrzebujesz wyszukiwania semantycznego – znajdowania informacji według znaczenia, a nie dokładnych słów kluczowych.
Proces krok po kroku:
- Wybierz model embeddingu: Przekształć tekst/obrazy w wektory numeryczne (np. OpenAI text-embedding-3, Sentence Transformers)
- Wygeneruj embeddingi: Przetwórz swoje dokumenty za pomocą modelu embeddingu
- Zaindeksuj wektory: Przechowuj je w wektorowej bazie danych (Pinecone, Weaviate, Qdrant, pgvector)
- Skonfiguruj odpytywanie: Ustaw metryki podobieństwa (kosinusowe, iloczyn skalarny) i liczbę zwracanych wyników (top-k)
- Zintegruj z LLM: Przekaż pobrany kontekst do modelu (wzorzec RAG)
Przykład: Przeszukiwanie opinii z podróży w poszukiwaniu „romantycznych hoteli przy plaży z dobrym jedzeniem” lub znajdowanie podobnych wzorców oszustw w transakcjach.
Kiedy graf wiedzy ma przewagę?
Grafy wiedzy sprawdzają się najlepiej, gdy:
- Złożone relacje mają znaczenie
- Wymagane jest wieloetapowe rozumowanie (multi-hop reasoning)
- Kluczowa jest wyjaśnialność (explainability)
- Dane mają bogatą, wzajemnie połączoną strukturę
Lista kontrolna dla PM-ów
- Określ typy swoich danych: ustrukturyzowane, nieustrukturyzowane czy oba?
- Zidentyfikuj wzorce zapytań: dokładne dopasowanie, wyszukiwanie semantyczne czy relacyjne?
- W przypadku wektorowych baz danych: oszacuj wymiary embeddingów i potrzeby w zakresie przechowywania
- W przypadku grafów wiedzy: zmapuj typy encji i typy relacji
- Rozważ podejścia hybrydowe: połączenie SQL + wektorowa baza danych jest coraz bardziej popularne