Martyna Mul, Autor w serwisie Inero Software - Rozwiązania IT i Konsulting

Ile kosztuje wdrożenie i utrzymanie modelu LLM w firmie? Szczegółowa analiza

Martyna Mul — Tue, 13 May 2025 09:16:26 +0000

Rozważając wprowadzenie sztucznej inteligencji do firmy, warto wiedzieć, jakie koszty wiążą się z wdrożeniem i utrzymaniem własnego modelu LLM. Wydatki nie sprowadzają się wyłącznie do opłat za wykorzystanie modelu (np. za tokeny w API), ale obejmują szereg czynników – od infrastruktury po bezpieczeństwo. Poniżej omawiamy rodzaje kosztów korzystania z dedykowanych LLM, a także przedstawiamy przykładowe kalkulacje dla popularnych modeli (GPT-4, Claude, Mistral, LLaMA itp.), w tym scenariusze użycia w firmie.

Coraz więcej firm rozważa wykorzystanie dużych modeli językowych (LLM – Large Language Models) we własnych produktach i procesach. Takie „dedykowane” modele mogą działać jako inteligentni asystenci: odpowiadać na pytania klientów, analizować dokumenty, generować raporty i wiele więcej. Wiecej przeczytasz o tym tutaj.

Rodzaje kosztów przy korzystaniu z LLM

Przed rozpoczęciem wdrożenia warto poznać wszystkie elementy, które składają się na pełny koszt korzystania z dedykowanego modelu.

Infrastruktura:

Jeśli korzystasz z modeli przez chmurowe API (OpenAI, Anthropic, Google): płacisz wyłącznie za zużyte tokeny. Koszt infrastruktury jest „ukryty” po stronie dostawcy.

Jeśli z kolei zdecydujesz się na self‑hosting wybranego modelu, np. Mistral, LLaMA, musisz utrzymać serwer GPU (lokalnie lub w chmurze). Przykładowo, wynajęcie instancji z kartą A100 to koszt rzędu  $1 – 2 za godzinę, czyli $750 do 1 500 na miesiąc przy ciągłym działaniu serwera. Taka inwestycja może obsłużyć wiele zapytań, ale przy małej skali obciążenia może okazać się niewykorzystana.

Licencje i opłaty za modele

Modele komercyjne wiążą się z opłatami licencyjnymi lub abonamentowymi. Na przykład korzystając z API GPT-4 od OpenAI czy Claude od Anthropic, płacimy za każdy użyty token według cennika dostawcy (szczegóły kosztów za tokeny przedstawiamy w dalszej części). Z drugiej strony, dostępne są otwartoźródłowe modele jak LLaMA czy Mistral, które można używać za darmo – nie ma opłaty za licencję ani za tokeny. Meta udostępniła np. model LLaMA 2 na licencji pozwalającej firmom na swobodne użycie bez opłat. “Za darmo” nie oznacza jednak braku kosztów – wówczas płacimy za infrastrukturę i prąd potrzebny do ich uruchomienia (jak wspomniano wyżej). Warto też sprawdzić ograniczenia licencyjne: niektóre otwarte modele mogą mieć pewne warunki użytkowania (np. zakaz użycia w określonych branżach).

Adaptacja i dostosowanie modelu

Aby model LLM dobrze sprawdzał się w konkretnej firmie, często wymaga on dostosowania – np. dodatkowego treningu (fine-tuning) na firmowych danych lub przynajmniej przygotowania odpowiednich promptów (tzw. prompt engineering). Adaptacja może generować znaczące koszty:

- Fine-tuning modelu: Trenowanie modelu na własnym zbiorze danych wymaga mocy obliczeniowej (GPU przez wiele godzin) i wiedzy specjalistów. Dla dużych modeli może to kosztować od kilku do kilkudziesięciu tysięcy dolarów, biorąc pod uwagę zarówno opłaty za maszyny, jak i czas pracy ekspertów. Nawet fine-tuning mniejszego modelu (np. GPT-3.5) przez API OpenAI to koszt zużycia setek tysięcy czy milionów tokenów podczas treningu (liczonych również według stawek za token).

- Inżynieria promptów: Alternatywą lub uzupełnieniem treningu jest przygotowanie odpowiednich zapytań i instrukcji dla modelu. Choć samo tworzenie promptów nie wymaga płatnych zasobów, to jednak iteracyjne testowanie wielu wersji zapytań też zużywa tokeny (koszt w przypadku modelu w chmurze) i czas pracy zespołu. Można to traktować jako koszt operacyjny lub koszt kompetencji – potrzebny jest czas specjalisty, by zoptymalizować działanie modelu pod nasze potrzeby.

Koszty operacyjne

Po wdrożeniu modelu dochodzą bieżące koszty operacyjne. Obejmują one monitorowanie działania modelu, utrzymanie wydajności, logowanie wyników, aktualizacje i ewentualne naprawy błędów. Jeśli korzystamy z API, kosztem operacyjnym będzie głównie miesięczny rachunek za wykorzystane tokeny oraz ewentualny abonament za dostęp premium (niektórzy dostawcy oferują plany subskrypcyjne z określonym limitem lub stawkami). Jeśli model jest hostowany lokalnie, do kosztów operacyjnych zaliczamy:

- Energie elektryczną zużywaną przez serwery (przy modelach GPU może to być niebagatelna kwota miesięcznie),

- Administrację systemem – czas administratorów na utrzymanie serwera, wykonywanie kopii zapasowych, aktualizacje oprogramowania (np. bibliotek AI),

- Skalowanie infrastruktury w razie zwiększenia obciążenia – może zajść potrzeba dokupienia dodatkowych maszyn lub instancji chmurowych, co wiąże się z kolejnymi kosztami.

- Wysoka dostępność – jeśli asystent LLM ma działać 24/7 bez przerw, być może trzeba zainwestować w redundantne zasoby (zapasowe serwery na wypadek awarii) lub w umowę SLA z dostawcą chmury.

Kompetencje zespołu

Wdrożenie LLM wymaga odpowiednich kompetencji w zespole IT/Danych. Jeśli w firmie brakuje doświadczenia z AI, może być konieczne przeszkolenie pracowników lub zatrudnienie nowych specjalistów (np. inżyniera ML czy MLOps). To wiąże się z dodatkowymi kosztami rekrutacji lub szkoleń. Alternatywnie, firmy czasem korzystają z konsultantów lub usługodawców zewnętrznych do wdrożenia modelu – co również generuje koszty (najczęściej jednorazowe za projekt wdrożeniowy, ale nierzadko znaczące). Warto uwzględnić też czas poświęcony przez zespół na integrację modelu z istniejącymi systemami (np. połączenie modelu z bazą danych, z aplikacją użytkownika itp.) – jest to koszt czasu pracy, który w małych projektach bywa pomijany, a w praktyce może być istotny.

Powyższe kategorie pokazują, że całkowity koszt posiadania dedykowanego rozwiązania opartego o LLM to nie tylko opłata za dostęp do modelu. Warto je wszystkie przeanalizować przed podjęciem decyzji. W dalszej części przejdziemy do konkretnych liczb: ile kosztuje pojedyncze zapytanie (prompt) do różnych popularnych modeli oraz ile wyniosłoby utrzymanie prostego asystenta LLM w dwóch przykładowych zastosowaniach biznesowych.

Koszt jednego zapytania w popularnych modelach LLM

Modele językowe rozliczane są zazwyczaj w oparciu o liczbę tokenów. Token to mały fragment tekstu – może odpowiadać pojedynczemu słowu lub jego części (przykładowo, 1000 tokenów odpowiada mniej więcej 750 słowom ciągłego tekstu). Dostawcy API podają ceny w przeliczeniu na 1 tys. tokenów lub milion tokenów. Poniżej zestawiamy orientacyjne koszty przetworzenia 1000 tokenów dla wybranych, popularnych modeli LLM:

Porównanie modeli LLM

Model LLM	Dostęp / Licencja	Koszt za 1000 tokenów	Uwagi
GPT-3.5 Turbo (OpenAI)	API w chmurze (model chat dostępny np. w ChatGPT)	$0,0015 (wejście) $0,0020 (wyjście)	Bardzo niski koszt – 16k tokenów + płatne rozszerzenie do 128k Dobre jakość odpowiedzi
GPT-4 (8k)	API w chmurze (OpenAI)	$0,08 (wejście) $0,16 (wyjście)	Wysoka jakość; wysoki koszt
GPT-4 Turbo (128k)	API w chmurze (OpenAI)	$0,01 (wejście) $0,03 (wyjście)	Bezpieczny duży kontekst (do 128k tokenów) Tańszy (niewiele droższy niż GPT-4)
Claude Instant v1.2	API w chmurze (Anthropic)	$0,0008 (wejście) $0,0024 (wyjście)	Szybki, tańszy model Claude (odpowiednik GPT-3.5)
Claude 2 (100k)	API w chmurze (Anthropic)	$0,008 (wejście) $0,024 (wyjście)	Wysokiej jakości model od Anthropica; kontekst do 100k tokenów
Mistral 7B	Open source (darmowy model)	50 ttoken (opłat za tokeny)	Trzeba samodzielnie hostować Alternatywa dla GPT-3.5 – niskie wymagania (można uruchomić nawet <1M tokenów)
LLaMA 2 13B	Open source (darmowy model)	50 ttoken (opłat za tokeny)	Samodzielny hosting Wymaga mocniejszego sprzętu (np. 2x 24GB GPU) niż 7B, ale nadal dostępny dla wielu firm
LLaMA 2 70B	Open source (darmowy model)	50 ttoken (opłat za tokeny)	Samodzielny hosting Wymaga kosztownego infrastruktury (np. 8x 80GB GPU) Przy takiej skali koszt może zbliżać się lub nawet kilkukrotnie przekraczać model np. GPT-4

Legenda: jak liczone są koszty tokenów

- Tokeny wejściowe („wejście”) – to słowa zawarte w zapytaniu użytkownika (prompt).
- Tokeny wyjściowe („wyjście”) – to słowa wygenerowane przez model w odpowiedzi (completion).

W przypadku większości komercyjnych dostawców, koszt naliczany jest osobno dla wejścia i wyjścia. Przykład:

- GPT-4 Turbo:
  - 1000 tokenów wejściowych: $0,03
  - 1000 tokenów wyjściowych: $0,06
  - Przy dialogu zawierającym łącznie 1000 tokenów (np. 500 wejścia + 500 wyjścia), koszt to około $0,045.
  - Dla uproszczenia można przyjąć, że interakcja o wielkości 1000 tokenów kosztuje około $0,09.

Dla porównania:

- GPT-3.5 Turbo – koszt podobnego 1000-tokenowego dialogu to tylko około $0,0035 (czyli 0,35 centa).
- Modele open-source (np. Mistral, LLaMA) – koszt tokenów wynosi $0, ponieważ modele działają lokalnie. Ponosimy jedynie koszty związane z infrastrukturą (zużycie energii, czas działania serwera itp.).

Otwartoźródłowe modele (Mistral, LLaMA itp.) kuszą brakiem opłat za sam model – można generować dowolne ilości tokenów nie płacąc dostawcy modelu ani centa. Jednakże, aby te modele działały, musimy utrzymywać własną infrastrukturę. Przy niewielkiej skali użycia może się okazać, że koszt wynajmu maszyny na jedno zapytanie będzie nawet wyższy niż zapłata za pojedyncze wywołanie API GPT. Z drugiej strony, przy dużej skali (bardzo wielu zapytaniach dziennie) wykorzystanie open-source może okazać się dużo bardziej opłacalne. Podsumowując, opłacalność zależy od scenariusza użycia, o czym opowiemy w kolejnym punkcie.

Przykładowe koszty wdrożenia asystenta LLM (100 zapytań dziennie)

Rozważmy teraz praktyczny scenariusz: Twoja firma chce wdrożyć prostego wirtualnego asystenta opartego na LLM, który wykonuje jedno z zadań:

- Analiza dokumentów – np. asystent wczytuje oferty lub umowy i wyciąga z nich najważniejsze informacje (klauzule, terminy, kwoty).

- Obsługa zapytań klientów – np. asystent odpowiada na maile klientów z pytaniami o ofertę, dostępność produktów, pomoc techniczną itp.

Załóżmy, że:

- asystent będzie obsługiwał około 100 interakcji dziennie

- każda interakcja to zapytanie + odpowiedź o łącznej długości ~2000 tokenów (np. 1000 tokenów w pytaniu – odpowiada to mniej więcej 750 słowom lub kilku akapitom tekstu – oraz 1000 tokenów w odpowiedzi, czyli ok. 750 słów wygenerowanej odpowiedzi). Taka długość pokrywa już dosyć złożone zapytanie i obszerną odpowiedź.

- miesięcznie nasz asystent przetworzy około 6 milionów tokenów (3000 * 2000 = 6 000 000 tokenów).

Chcemy porównać koszty miesięczne utrzymania takiego asystenta w zależności od wyboru modelu i sposobu wdrożenia. Pokażemy dwa warianty:

- Wariant API (model zamknięty): Korzystamy z komercyjnego modelu poprzez API (np. OpenAI GPT lub Anthropic Claude). Nie utrzymujemy własnych serwerów – płacimy wyłącznie za wykorzystane tokeny według cennika.

- Wariant self-hosted (model open-source): Korzystamy z otwartoźródłowego modelu (np. Mistral lub LLaMA) zainstalowanego na naszych serwerach. Płacimy za infrastrukturę potrzebną do obsługi tych ~100 zapytań dziennie (np. wynajem instancji GPU w chmurze lub amortyzacja zakupu sprzętu, plus prąd).

Zapraszamy na bezpłatne szkolenie dla MŚP

Usługa edukacyjno-szkoleniowa w zakresie automatyzacji procesów integracji i wdrożenia narzędzi AI w ramach Pomorskiego Hubi Innowacji Cyfrowych

Poznaj szczegóły

Poniżej przedstawiamy tabelę porównującą orientacyjne miesięczne koszty dla kilku przykładowych modeli w obu wariantach, przy założeniu 6 mln tokenów miesięcznie:

Porównanie kosztów miesięcznych LLM

Model (wariant)	Szacowany koszt miesięczny	Komentarz
GPT-3.5 Turbo (API)	ok. $18 (USD)	Bardzo niski koszt przy tej jakości. Wyliczenie: ok. $0,0027/1k tok. → $12 za wygenerowanie 4M tok. + $6 za zapytania → $18 miesięcznie orientacyjnie.
GPT-4 (8k) (API)	ok. $270	Dużo wyższy koszt za lepszą jakość. Wyliczenie: np. 8M tok. → koszt: 8M × $0,08/1k (tok wejści) + $0,16/1k (tok wyjści) → koszt miesięczny $270–$540.
GPT-4 Turbo (128k) (API)	ok. $18	Niewiele droższy niż zwykły GPT-3.5 dzięki tańszym tokenom wejściowym i wyjściowym. Może mieć nawet lepszą jakość niż GPT-4 (8k).
Claude Instant (API)	ok. $20–25	Porównywalny z kosztem GPT-3.5. Wyliczenie: ok. $0,0021/1k tok. (wej+wyj) → analogicznie $18–25 za 8 mln tok. (Plus ewentualne opłaty stałe).
Claude 2 (API)	ok. $150–200	Tańszy od GPT-4, ale wciąż kilkukrotnie droższy niż GPT-3.5. Wyliczenie: $0,032/1k tok. → 8M = ~$192 za 8 mln tok.
Mistral 7B (open source, 1 self-host, 1xGPU)	ok. $300	Koszt głównie za utrzymanie serwera / GPU. Założenie: instancja na 1x24GB GPU – model generuje ~30–60 tok./s, zużycie 100–150W. Rzeczywisty koszt zależy od lokalizacji i zużycia (prąd + serwer = ~300 zł–400 zł/mies.).
LLaMA 2 70B (open source, self-host, multi-GPU)	ok. $1,000+	Wysoki koszt związany wymaga dużą mocą GPU. Przy 70B to zazwyczaj instancja na minimum 8x80GB GPU (~10k–12k USD sprzętowo + wysokie zużycie prądu). Wyliczenia zależne od modelu działania (on-prem / cloud / GPU provider).
Lokalny model (np. LLaMA 13B, GPTQ, Mistral 7B – CPU)	ok. $300–500	Koszt obejmuje eksploatację lokalnego serwera. Model może być wolniejszy niż GPT-3.5, ale za to bezpieczny i prywatny. Dla instancji na CPU (np. 12 rdzeni, 64 GB RAM) koszt miesięczny to głównie energia i obsługa.

Z powyższego porównania można wyciągnąć kilka wniosków:

Mała skala (100 zapytań/dziennie) sprzyja API

Przy stosunkowo niewielkim obciążeniu, korzystanie z gotowego API (OpenAI, Anthropic) jest bardzo tanie w przypadku tańszych modeli (GPT-3.5, Claude Instant) – mówimy o kilkunastu czy kilkudziesięciu dolarach miesięcznie. Przy użyciu droższych modeli, koszt miesięczny może wzrosnąć do kilkuset dolarów. Gdy zapytań jest mało, własny serwer GPU za $300+ miesięcznie byłby mniej opłacalny.

Duża skala (wiele tysięcy zapytań) zmienia kalkulację

Jeśli nasz asystent odniesie sukces i skala zapytań wzrośnie np. 10x lub 100x, wtedy comiesięczny rachunek za API mógłby urosnąć do tysięcy czy dziesiątek tysięcy dolarów. W takiej sytuacji inwestycja we własny model open-source zaczyna mieć sens. Przy odpowiednio dużej liczbie zapytań koszt jednostkowy generowania odpowiedzi lokalnie staje się niższy niż koszt w API (bo pełniej wykorzystujemy zakupiony/wynajęty sprzęt). W skrajnym przypadku ogromnej skali można nawet myśleć o trenowaniu własnego modelu od podstaw – ale to już domena największych graczy z bardzo dużymi budżetami.

Znaczenie przypadku użycia (jakość vs. oszczędność)

Wybór modelu powinien zależeć nie tylko od kosztu, ale i od wymaganego poziomu odpowiedzi. W scenariuszu analizy dokumentów najbardziej zależy nam na precyzji ekstrakcji informacji. Być może wystarczy tu model tańszy lub open-source, który po odpowiednim dostrojeniu poprawnie wyłuska dane z tekstu. Taki model (np. 7B-13B parametrów) może być znacznie tańszy w użyciu i wystarczający jakościowo. Co więcej, jeśli przetwarzamy wrażliwe dokumenty (np. umowy), lokalne uruchomienie open-source gwarantuje, że treść dokumentów nie opuści naszej firmy, co bywa bezcenne ze względów prawnych. Z drugiej strony, w scenariuszu obsługi zapytań klientów, gdzie liczy się jakość języka, uprzejmość, kontekst – model GPT-4 może znacząco przewyższać prostsze modele w jakości odpowiedzi. Tu firma może zdecydować, że warto zapłacić więcej za lepsze wrażenia klienta.

Niewidoczne koszty wokół projektu

Zauważmy, że powyższe kalkulacje dotyczą kosztów czysto technologicznych (tokeny lub sprzęt). W praktyce do tego dojdą koszty „miękkie” – czas personelu na przygotowanie wdrożenia, integrację modelu z systemem np. CRM lub bazą wiedzy, testowanie i iteracyjne usprawnianie. Jeśli nasz asystent ma np. pobierać dane z firmowej bazy dokumentów, często dane te trzeba też odpowiednio uporządkować.

Przykład kosztów: Asystent AI analizujący maile i dokumenty PDF

Przedstawiamy tutaj też koszty naszego asystenta opartego na modelu Gemini od Google, który opisaliśmy tutaj. Jego zadaniem jest automatyczna analiza przychodzących e-maili w celu identyfikacji polis ubezpieczeniowych oraz ekstrakcja kluczowych danych z załączonych dokumentów PDF, takich jak numer polisy, adres ubezpieczonego czy potwierdzenie płatności.

Średnia liczba tokenów na e-mail:

- Wejście (input): 3 500 tokenów

- Wyjście (output): 220 tokenów

Analiza 100 maili z załącznikami z użyciem modelu Gemini 2.0 Flash kosztuje zatem około $1.5.

Podsumowanie

Czy stać nas na własnego „ChatGPT” w firmie? Jak widać, odpowiedź brzmi: to zależy – przede wszystkim od skali użycia i wymagań jakościowych. Kluczem jest wybór modelu i sposóbu wdrożenia adekwatnego do naszych potrzeb. Często praktykuje się podejście iteracyjne – start z tańszym modelem/API, ocena efektów, a następnie ewentualne przejście na mocniejszy model lub własny hosting, gdy projekt się rozwinie. Niezależnie od wyboru, ważne jest świadome planowanie i monitorowanie wszystkich rodzajów kosztów. Mamy nadzieję, że powyższe zestawienie pomoże w podjęciu decyzji i przygotowaniu realnego budżetu na wdrożenie dedykowanego modelu LLM w Waszej organizacji.

Jeśli rozważasz wdrożenie asystenta w Twojej firmie, warto znaleźć odpowiedzi na poniższe pytania:

- Czy potrzebuję wysokiej jakości odpowiedzi (GPT-4), czy wystarczy przybliżona (Claude Haiku, Gemini Flash)?

- Czy przetwarzam dane wrażliwe (np. dokumenty klientów)?

- Czy mam zespół IT zdolny hostować własny model?

- Jaka jest spodziewana liczba zapytań dziennie/miesięcznie?

- Czy opłaca mi się własna infrastruktura, czy lepiej płacić za API?

Dla małych i średnich zastosowań, koszty korzystania z dedykowanego modelu LLM mogą być całkiem przystępne. Dzięki usługom chmurowym można zacząć od kilkunastu dolarów miesięcznie za model pokroju GPT-3.5 czy Claude Instant, co jest świetnym sposobem na eksperymenty i pierwsze prototypy. Jeśli potrzebujemy najwyższej jakości, dostępnej np. w GPT-4, musimy liczyć się z wyższą ceną, ale nawet kilkaset dolarów miesięcznie może być uzasadnione, jeśli wartość dodana dla biznesu jest istotna (np. automatyzacja oszczędzająca wiele godzin pracy ludzi).

Z drugiej strony, dla dużych firm planujących intensywne użycie AI, koszty mogą rosnąć wykładniczo – wtedy warto rozważyć opcje open-source i większe inwestycje we własną infrastrukturę. Otwarte modele jak LLaMA czy Mistral dają wolność od opłat za każdy token, ale przenoszą ciężar kosztów na sprzęt i zespół. Opłacą się, gdy mamy odpowiednią skalę lub priorytetem jest pełna kontrola nad danymi.

Chcesz wprowadzić narzędzia AI do swojej firmy?

Oferujemy kompleksowe wsparcie technologiczne w zakresie sztucznej inteligencji i agentów AI. Opisz nam swój pomysł!

Napisz do nas

Artykuł Ile kosztuje wdrożenie i utrzymanie modelu LLM w firmie? Szczegółowa analiza pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

Jak platformy AI korzystają z Twoich danych? Przegląd obowiązujących zasad

Martyna Mul — Wed, 30 Apr 2025 12:10:39 +0000

Zastanawiałeś się kiedyś, co dzieje się z Twoimi danymi, gdy korzystasz z chmurowych platform AI, albo czy informacje, które podajesz są wykorzystywane do trenowania przyszłych modeli? W tym artykule przedstawiamy zasady, dotyczące prywatności danych, obowiązujące w czołowych platformach AI. Dowiesz się także, co zrobić, aby Twoje dane nie były wykorzystywane do trenowania dużych modeli językowych (LLM).

Najwięksi dostawcy chmurowych usług AI stają się coraz bardziej transparentni w kwestii wykorzystywania danych – zwłaszcza w kontekście trenowania modeli. Choć większość platform, szczególnie tych oferujących usługi na poziomie korporacyjnym, domyślnie nie wykorzystuje Twoich danych wejściowych i wyjściowych do treningu, to szczegóły zapisane drobnym drukiem mają znaczenie. Zrozumienie, w jaki sposób te usługi przetwarzają dane – oraz jak możesz zachować nad nimi kontrolę – jest kluczowe.

Z tego bloga dowiesz się jakie zasady, dotyczące prywatności danych i trenowania modeli stosują najpopularniejsze platformy AI, takie jak OpenAI, Google Gemini, Azure OpenAI od Microsoftu oraz Claude firmy Anthropic. Z tekstu dowiesz się między innymi:

- w jaki sposób platformy AI wykorzystują Twoje dane i czy są one domyślnie używane do trenowania modeli
- jak, w razie potrzeby, uniemożliwić wykorzystywanie swoich danych przez AI (opcja opt-out)
- gdzie przechowywane są Twoje dane (tzw. lokalizacja danych)
- jakie środki zgodności z przepisami, takimi jak RODO, mają zastosowanie

Wdrażanie AI to nie tylko kwestia tworzenia promptów czy wydajności modeli. To również świadomość, gdzie trafiają Twoje dane – i jak zadbać o to, by pozostały pod Twoją kontrolą.

Oto, co warto wiedzieć:

OpenAI – Wykorzystanie danych i prywatność

OpenAI traktuje Twoje dane w różny sposób, w zależności od tego, jak korzystasz z jego usług:

Aplikacja ChatGPT (wersja webowa/mobilna)

Gdy prowadzisz rozmowy z ChatGPT, Twoje konwersacje mogą być wykorzystywane do trenowania modeli AI – chyba że ręcznie zrezygnujesz z tego (opt-out).
Aby zapobiec wykorzystywaniu Twoich danych:

- Przejdź do Ustawienia → Kontrola danych → Ulepszanie modelu dla wszystkich i wyłącz tę opcję.
- Nawet po rezygnacji (opt-out), OpenAI przechowuje rozmowy przez 30 dni w celu monitorowania nadużyć, a następnie je usuwa.

OpenAI API i ChatGPT Enterprise

Jeśli jesteś deweloperem lub firmą korzystającą z API OpenAI albo ChatGPT Enterprise, nie musisz rezygnować z udziału w trenowaniu modeli – domyślnie OpenAI nie wykorzystuje danych z API ani z wersji Enterprise do tego celu, a Twoje dane pozostają prywatne. Nie musisz podejmować żadnych dodatkowych działań – ochrona danych jest włączona automatycznie. Możesz zdecydować się na udostępnienie danych w celu ulepszania modeli, ale tylko jeśli tego chcesz.

Lokalizacja danych

Serwery OpenAI znajdują się głównie w Stanach Zjednoczonych i obecnie – jeśli korzystasz bezpośrednio z API – nie masz możliwości wyboru, gdzie Twoje dane są przechowywane. Oznacza to, że dane są przetwarzane w infrastrukturze OpenAI – objętej solidnymi zabezpieczeniami, ale niekoniecznie zlokalizowanej w Twoim kraju.

Są jednak postępy dla użytkowników biznesowych. OpenAI niedawno wprowadziło opcję dla wybranych klientów API w wersji Enterprise, która umożliwia przechowywanie danych w Europie – pod warunkiem zawarcia odpowiedniej umowy.

Jeśli lokalizacja danych ma dla Twojej firmy istotne znaczenie – np. ze względu na RODO lub wewnętrzne wymogi zgodności – warto rozważyć korzystanie z Azure OpenAI. W tym wariancie modele OpenAI są uruchamiane w chmurze Microsoftu, a Ty możesz wybrać konkretny region, np. Europę Zachodnią lub Azję, zapewniając, że dane będą przetwarzane i przechowywane wyłącznie w wybranej lokalizacji.

Więcej o Azure przeczytasz w kolejnej części – ale w skrócie: OpenAI zapewnia bezpieczne przetwarzanie danych, jednak jeśli zależy Ci na pełnej kontroli nad ich lokalizacją, lepszym wyborem może być chmurowy partner, taki jak Azure.

Gemini – Podejście Google do Twoich danych

Google rozwija generatywną sztuczną inteligencję m.in. poprzez model Gemini – nowej generacji rozwiązanie, które zasila produkty takie jak chatbot Google Gemini oraz różne usługi AI dostępne w Google Cloud. Oto jak Google podchodzi do kwestii Twoich danych:

Aplikacja Gemini

Domyślnie Google zapisuje historię czatów z Gemini na Twoim koncie (podobnie jak historię wyszukiwania) i może wykorzystywać te dane do ulepszania swoich usług. Użytkownik ma jednak możliwość zarządzania tym ustawieniem za pomocą funkcji „Gemini Activity”.

Aby to skonfigurować:

- Przejdź do ustawień Gemini Activity,
- Wstrzymaj Gemini Activity, aby zatrzymać zapisywanie rozmów i uniemożliwić ich wykorzystanie jako źródła danych do trenowania modeli AI.
- Możesz także usunąć dotychczasową historię konwersacji.

Wyłączenie Aktywności Gemini oznacza, że nowe rozmowy nie będą wykorzystywane do ulepszania usług opartych na uczeniu maszynowym ani przeglądane przez członków zespołu Google – chyba że samodzielnie prześlesz je jako opinię. Daje to zwykłym użytkownikom możliwość rezygnacji z udziału w trenowaniu modeli, podobnie jak opcja opt-out dostępna w ChatGPT.

Aby zatrzymać zapisywanie rozmów, przejdź do zakładki Activity i wyłącz opcję Gemini Apps Activity. Możesz również usunąć wcześniejsze konwersacje.

API i Vertex AI

Jeśli korzystasz z platformy Vertex AI w Google Cloud:

- Twoje prompty i odpowiedzi nie są wykorzystywane do trenowania modeli AI bez Twojej wyraźnej zgody.
- Dane mogą być tymczasowo buforowane (do 24 godzin) w celu poprawy wydajności, ale pozostają w wybranym przez Ciebie regionie geograficznym.
- Firmy mogą zdecydować się na politykę braku retencji danych (zero-retention), aby zapewnić maksymalny poziom prywatności.

Lokalizacja danych

Lokalizacja danych to mocna strona Google – możesz samodzielnie wybrać region geograficzny, w którym działa Twoja usługa AI (np. centra danych w UE lub USA), a Google będzie przetwarzać i przechowywać dane właśnie w tym regionie, spełniając wymagania dotyczące lokalizacji danych.

Microsoft Azure OpenAI - Domyślna ochrona prywatności danych

Zasady trenowania modelu

Usługa Azure OpenAI firmy Microsoft umożliwia firmom korzystanie z modeli OpenAI za pośrednictwem zaufanej platformy chmurowej Azure. Prywatność jest tutaj jednym z głównych atutów. Microsoft wyraźnie zaznacza: wszelkie dane przesyłane do Azure OpenAI nie są wykorzystywane do trenowania modeli ani do ulepszania usług Microsoftu czy OpenAI.

Usługa Azure OpenAI w praktyce hostuje modele OpenAI (GPT-4, GPT-3.5 itd.) w infrastrukturze chmurowej Microsoft Azure. Microsoft zaprojektował tę usługę specjalnie z myślą o przedsiębiorstwach, które wymagają silnych mechanizmów ochrony prywatności. Do kluczowych elementów należą:

- Wszelkie dane wprowadzone do usługi Azure OpenAI – takie jak prompty, odpowiedzi modeli (completions), osadzenia (embeddings) czy dane do fine-tuningu – nie są wykorzystywane do trenowania modeli AI.
- Twoje dane wejściowe i wyjściowe „nie są dostępne dla innych klientów, nie są udostępniane OpenAI i nie są wykorzystywane do ulepszania modeli OpenAI”.
- Microsoft przechowuje dane jedynie w zakresie niezbędnym do świadczenia usługi i monitorowania nadużyć. Domyślnie prompty i odpowiedzi są przechowywane tymczasowo (do 30 dni) wyłącznie w celu wykrywania nadużyć, po czym są usuwane.
  Jeśli nawet to tymczasowe przechowywanie stanowi problem (np. w przypadku danych o wysokiej wrażliwości), Microsoft oferuje procedurę zwaną „modified abuse monitoring”, która umożliwia całkowite pominięcie 30-dniowego przechowywania. Oznacza to, że żadne prompty nie są w ogóle zapisywane. Zazwyczaj wymaga to zatwierdzenia, ale jest to możliwe w scenariuszach o podwyższonym poziomie bezpieczeństwa.

Lokalizacja danych

Ponieważ usługa działa w środowisku Azure, możesz łatwo wybrać region i spełnić wymagania dotyczące lokalizacji danych. Podczas konfigurowania Azure OpenAI wybierasz region, w którym zostanie wdrożona usługa (np. Wschodnie USA, Europa Zachodnia, Azja Południowo-Wschodnia itd.). Całe przetwarzanie i przechowywanie danych na potrzeby wnioskowania (inference) odbywa się w wybranym regionie lub w jego granicach geograficznych.

Oznacza to, że jeśli wdrożysz usługę w Europie Zachodniej, Twoje dane nie opuszczą Europy – co ma kluczowe znaczenie dla zgodności z RODO. Sama platforma Azure spełnia szereg standardów zgodności (takich jak SOC 2, ISO 27001 itp.), a certyfikacje te obejmują również usługę Azure OpenAI jako część oferty Azure.

Anthropic (Claude) – Asystent AI z priorytetem prywatności

Zasady trenowania modelu

Anthropic, firma stojąca za asystentem AI Claude (Claude 2 i nowsze wersje), od początku kładzie duży nacisk na podejście zorientowane na prywatność. Stosuje model działania oparty na zgodzie użytkownika (opt-in):

- Domyślnie Anthropic nie wykorzystuje Twoich rozmów ani danych do trenowania swoich modeli. Dotyczy to zarówno oferty komercyjnej (Claude for Work, Anthropic API), jak i produktów konsumenckich (Claude Free, Claude Pro) – Twoje prompty oraz odpowiedzi Claude’a nie są automatycznie używane do trenowania modeli.
- Dane są wykorzystywane wyłącznie wtedy, gdy świadomie wyrazisz na to zgodę – na przykład przesyłając opinię. Jeśli klikniesz ikonę kciuka w górę lub w dół w interfejsie Claude’a albo prześlesz dane przez kanał feedbacku, oznacza to, że wyrażasz zgodę: „you can learn from this”.

Dla klientów biznesowych Anthropic oferuje rozwiązania Claude Team/Enterprise, które nie tylko gwarantują, że dane nie są wykorzystywane do trenowania modeli, ale także udostępniają funkcje kontroli administracyjnej. Jedną z nich są niestandardowe ustawienia dotyczące retencji danych.

Domyślnie systemy Anthropic mogą przechowywać dane wejściowe i wyjściowe bezterminowo na potrzeby konta (ale nie do trenowania modeli). Jednak administratorzy usługi Claude Enterprise mogą ustawić własną politykę retencji – na przykład usuwanie wszystkich danych rozmów po 30, 60 dniach itd., przy czym aktualne minimum to 30 dni.

Takie mechanizmy kontroli mają na celu wspieranie zgodności z przepisami takimi jak RODO.

Lokalizacja danych

Anthropic to stosunkowo nowy gracz na rynku, i obecnie – korzystając bezpośrednio z ich API – nie masz możliwości jawnego wyboru regionu przechowywania danych. Najprawdopodobniej dane są hostowane w USA przez Anthropic lub za pośrednictwem dostawców chmurowych, takich jak AWS, w regionie amerykańskim.

Jednak modele Anthropic są również dostępne za pośrednictwem partnerów, co może pomóc w spełnieniu wymagań dotyczących lokalizacji danych. Przykładowo, Claude firmy Anthropic jest oferowany przez usługę Amazon Bedrock (AI-as-a-service od AWS) oraz przez Google Cloud Vertex AI. Korzystając z Claude’a za pośrednictwem jednej z tych platform, możesz skorzystać z możliwości wyboru regionu oferowanych przez AWS lub Google.

Podsumowanie

Zrozumienie praktyk związanych z gromadzeniem danych przez dostawców dużych modeli językowych (LLM) ma kluczowe znaczenie dla zgodności z przepisami, zaufania klientów oraz ładu informacyjnego w organizacji. Niezależnie od tego, czy priorytetem jest zgodność z regulacjami, transparentność wobec klientów czy wewnętrzne zarządzanie danymi – poniższe informacje pomogą w podjęciu świadomych decyzji. Wybieraj dostawców, którzy są zgodni z Twoimi standardami prywatności – i zawsze weryfikuj ustawienia swoich usług.

Oto porównanie najważniejszych platform:

Dostawca	Domyślne trenowanie na danych	Ustawienia w aplikacji webowej	Opcje lokalizacji danych	Zgodność z RODO/CCPA	Polityka prywatności
OpenAI	Nie (API)	Dostępna opcja opt-out	Nie (chyba że przez Azure Microsoft)	Tak	Prywatność konsumencka
Google	Nie (Cloud + Gemini)	Brak trenowania domyślnie	Szeroka kontrola regionalna	Tak	Prywatność korporacyjna, Prywatność Gemini, Vertex AI
Azure	Nie	Nie dotyczy	Pełna kontrola regionalna	Tak	Prywatność Azure i OpenAI
Anthropic	Nie	Brak trenowania domyślnie	Nie (chyba że przez partnerów)	Tak	Użytkownicy API, Użytkownicy Claude.ai

Dla maksymalnej prywatności i pełnej kontroli alternatywą pozostaje lokalne wdrożenie modeli (on-premises). Pozwala to całkowicie wyeliminować obawy związane z przechowywaniem danych w chmurze. Więcej na temat lokalnego wdrażania przeczytasz tutaj.

Chcesz porozmawiać o agentach AI?

Planujesz wdrożyć narzędzia AI? Z nami zrobisz to jak należy.

Napisz do nas

Artykuł Jak platformy AI korzystają z Twoich danych? Przegląd obowiązujących zasad pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

Lokalne LLM-y: testujemy lekkie modele do przetwarzania dokumentów

Martyna Mul — Thu, 17 Apr 2025 12:42:27 +0000

Uruchamianie dużych modeli językowych (LLM) na własnym sprzęcie staje się coraz bardziej dostępne dzięki tzw. lekkim modelom LLM — modelom o stosunkowo niewielkiej liczbie parametrów, które zapewniają wysoką wydajność bez potrzeby korzystania z kart graficznych klasy serwerowej. W tym wpisie przyjrzymy się kilku najlepszym otwartoźródłowym lekkim modelom LLM oraz sposobom ich uruchamiania na lokalnym komputerze z systemem Windows — zarówno przy użyciu samego CPU, jak i z ograniczoną kartą graficzną (GPU) — w zastosowaniach związanych z przetwarzaniem dokumentów. Opisaliśmy także benchmark, który porównuje modele pod względem dokładności i szybkości wnioskowania, co pomoże Ci wybrać odpowiedni model do lokalnego środowiska i konkretnego przypadku użycia.

Lekkie modele LLM – czym są i czy warto uruchamiać je lokalnie?

„Lekkie” modele LLM to zazwyczaj modele mieszczące się w przedziale od około 1 do 8 miliardów parametrów — znacznie mniejsze niż modele klasy GPT-3 — często zoptymalizowane do działania na jednej karcie graficznej (GPU) lub nawet samym procesorze (CPU). Zazwyczaj są one udostępniane jako modele otwarte, z publicznie dostępnymi wagami. Tego typu rozwiązania rezygnują z części mocy obliczeniowej na rzecz większej efektywności, jednak dzięki postępom badawczym i przemyślanej inżynierii (lepsze dane, trenowanie z użyciem destylacji, wydajne mechanizmy uwagi itd.) ich możliwości znacząco wzrosły. Wiele z tych modeli dorównuje dziś, a nawet przewyższa znacznie większe modele w wybranych benchmarkach.

Lokalne uruchamianie takich modeli ma wiele zalet:

- Prywatność i bezpieczeństwo: Wszystkie dane pozostają na Twoim urządzeniu, co ma kluczowe znaczenie w przypadku poufnych dokumentów, takich jak umowy ubezpieczeniowe. Nie wysyłasz wrażliwych treści do zewnętrznego API.
- Oszczędność kosztów: Po pobraniu model działa lokalnie za darmo — bez opłat za korzystanie z API czy zasoby chmurowe. Przy regularnym przetwarzaniu dużej liczby dokumentów może to oznaczać znaczące oszczędności.
- Niskie opóźnienia i dostęp offline: Lokalna inferencja eliminuje opóźnienia sieciowe. Na GPU odpowiedzi mogą pojawiać się niemal natychmiast, a cały system może działać w trybie offline. To szczególnie przydatne w środowiskach lokalnych lub tam, gdzie dostęp do internetu jest ograniczony.
- Możliwość dostosowania: Korzystając z modeli lokalnych, masz pełną kontrolę — możesz zmieniać parametry, prompty lub dostrajać model do specyfiki swojej branży (np. danych ubezpieczeniowych) bez ograniczeń narzuconych przez dostawcę.

Krótko mówiąc, lekkie modele LLM dają Ci dostęp do możliwości sztucznej inteligencji bezpośrednio na Twoim sprzęcie. W dalszej części porównamy wybrane otwarte modele, które szczególnie dobrze sprawdzają się w lokalnym przetwarzaniu dokumentów.

Porównanie najlepszych lekkich modeli LLM

Lekkie, otwartoźródłowe duże modele językowe (LLM) stają się praktycznym wyborem dla organizacji, które chcą uruchamiać zadania AI lokalnie. Oferują one korzystny kompromis między wydajnością, szybkością a wymaganiami sprzętowymi — co czyni je idealnym rozwiązaniem do podsumowywania, ekstrakcji i klasyfikacji dokumentów bez potrzeby korzystania z infrastruktury chmurowej.

Skupimy się na następujących otwartoźródłowych modelach (każdy z dostępem do punktów kontrolnych do pobrania), które cieszą się dobrą opinią pod względem jakości w stosunku do swojej wielkości:

- Llama 3.1 – 8B parametrów (Meta AI)
- StableLM Zephyr – 3B parametrów (Stability AI)

- Llama 3.2 – 1B/3B parametrów (Meta AI)

- Mistral – 7B parametrów (Mistral AI)

- Gemma 3 – warianty 1B i 4B (Google DeepMind)

- DeepSeek R1 – warianty 1.5B i 7B (DeepSeek AI)

- Phi-4 Mini – 3.8B parametrów (Microsoft)

- TinyLlama – 1.1B parametrów (community project)

Te modele obejmują zakres od bardzo małych (poniżej 1 GB na dysku) do średniej wielkości (około 5 GB). Wszystkie mogą być uruchamiane w trybie inferencji na karcie graficznej z 16 GB pamięci (często nawet w wersji z obniżoną precyzją lub skwantyzowanej do 4 bitów), a wiele z nich działa również na procesorze, o ile dysponujemy odpowiednią ilością pamięci RAM i cierpliwością. Tabela 1 przedstawia ich charakterystyki.

Model	Rozmiar na dysku (po kwantyzacji)	Maksymalny kontekst	Licencja
Llama 3.1 (8B)	4,9 GB	128 tys. tokenów	Open-source
StableLM Zephyr (3B)	1,6 GB	4 tys. tokenów	Tylko do użytku niekomercyjnego
Llama 3.2 (3B)	2,0 GB	128 tys. tokenów	Open-source
Mistral (7B)	4,1 GB	32 tys. tokenów	Open-source (licencja Apache 2.0)
Gemma 3 (4B)	3,3 GB	128 tys. tokenów	Open-source
Gemma 3 (1B)	0,8 GB	32 tys. tokenów	Open-source
DeepSeek R1 (7B)	4,7 GB	128 tys. tokenów	Open-source (licencja MIT)
DeepSeek R1 (1.5B)	1,1 GB	128 tys. tokenów	Open-source (licencja MIT)
Phi-4 Mini (3.8B)	2,5 GB	128 tys. tokenów	Open-source
TinyLlama (1.1B)	0,6 GB	2 tys. tokenów	Open-source

Tabela 1: Lekkie modele LLM do użytku lokalnego – rozmiary modeli i maksymalne okno kontekstu.

Uwaga: „Maksymalny kontekst” to maksymalna długość sekwencji (w tokenach), jaką model może przetworzyć jednorazowo.

Przyjrzyjmy się teraz zaletom i ograniczeniom każdego z modeli, szczególnie w kontekście zadań związanych z dokumentami.

- Llama 3.1 (8B): Wszechstronny, wydajny model ogólnego zastosowania; umiarkowany rozmiar i dobre możliwości wielojęzyczne. Zbyt ciężki dla systemów opartych wyłącznie na CPU; wymaga dzielenia długich dokumentów na fragmenty.
- StableLM Zephyr (3B): Bardzo lekki model, sprawdza się w podstawowym QA i ekstrakcji. Ograniczony przez niewielką liczbę parametrów i restrykcyjną licencję komercyjną.
- Llama 3.2 (3B): Doskonały do podsumowań i wyszukiwania informacji; obsługuje długi kontekst (128 tys. tokenów). Mniejszy rozmiar wpływa na precyzję w złożonym rozumowaniu.
- Mistral (7B): Najlepszy ogólny model w swojej klasie; bardzo wydajna inferencja. Idealny do szczegółowych zadań podsumowujących.
- Gemma 3 (4B/1B): Oferuje możliwości multimodalne i szerokie wsparcie językowe. Wariant 4B to dobry kompromis między mocą a szybkością, wariant 1B najlepiej sprawdza się w prostych zadaniach.
- DeepSeek R1 (7B/1.5B): Zrównoważona wydajność i rozumienie ogólnych zadań NLP; słabsze wnioskowanie w porównaniu do Mistrala.
- Phi-4 Mini (3.8B): Wyjątkowe zdolności analityczne, matematyczne i logiczne; idealny do analitycznego przetwarzania dokumentów. Skoncentrowany głównie na języku angielskim.
- TinyLlama (1.1B): Bardzo lekki model; odpowiedni do prostych zadań ekstrakcji i klasyfikacji tekstu. Ograniczone rozumienie kontekstu.

Omówione powyżej modele obejmują szeroki zakres rozmiarów i możliwości. Większe warianty, takie jak Llama 3.1 i Mistral, dobrze radzą sobie ze złożonymi zadaniami podsumowania i obsługą wielu języków, ale mniej nadają się do systemów opartych wyłącznie na CPU. Modele średniej wielkości, takie jak Llama 3.2 i Gemma 3 (4B), efektywnie przetwarzają długie dane wejściowe, oferując przy tym rozsądną wydajność. Mniejsze modele, w tym TinyLlama i StableLM Zephyr, są lekkie i szybkie, co czyni je praktycznym wyborem do prostych zadań ekstrakcji lub klasyfikacji.

Porównanie modeli: ekstrakcja i podsumowywanie dokumentów

Poniżej przedstawiamy prosty plan benchmarku modeli, obejmujący dwa typowe zadania związane z przetwarzaniem dokumentów:

Ekstrakcja informacji: Ocenialiśmy, jak dobrze każdy model potrafi wyodrębnić konkretne pola z polisy lub certyfikatu. W szczególności prosiliśmy modele o znalezienie numeru polisy, nazwy ubezpieczonego, NIP-u, adresu oraz okresu ubezpieczenia w treści dokumentu i zwrócenie ustrukturyzowanego wyniku — czystej odpowiedzi w formacie JSON zawierającej wszystkie wymagane wartości.
Podsumowanie: Każdy model generował zwięzłe podsumowanie polisy ubezpieczeniowej, obejmujące kluczowe informacje, takie jak zakres ochrony, wyłączenia i warunki. Podsumowania ocenialiśmy pod względem przejrzystości, poprawności, zgodności z faktami i czytelności, a za zmyślanie informacji przyznawaliśmy znaczące kary.

Wykorzystaliśmy 11 dokumentów i przeprowadziliśmy wszystkie testy za pomocą Ollama (więcej o uruchamianiu modeli z użyciem Ollama możesz przeczytać tutaj). Benchmarki zostały wykonane na komputerze z kartą graficzną NVIDIA GeForce RTX 2060 z 6 GB pamięci VRAM. Aby zapewnić spójność wyników, każdy model był uruchamiany z temperaturą ustawioną na 0 w zadaniu ekstrakcji (dla uzyskania deterministycznych odpowiedzi) oraz z ustaloną temperaturą 0,7 w zadaniu podsumowania. W przypadku ekstrakcji wykorzystaliśmy również ustrukturyzowane odpowiedzi:

 "stream": false, 
    "format": { 
    "type": "object", 
    "properties": { 
      "numer_polisy": { 
        "type": "string" 
      }, 
      "okres_ubezpieczenia_od": { 
        "type": "string" 
      }, 
      "okres_ubezpieczenia_do": { 
        "type": "string" 
      }, 
      "ubezpieczony": { 
        "type": "string" 
      }, 
      "nip_ubezpieczonego": { 
        "type": "string" 
      }, 
      "adres_ubezpieczonego": { 
        "type": "string" 
      } 
    }, 
    "required": [ 
      "numer_polisy", 
      "okres_ubezpieczenia_od", 
      "okres_ubezpieczenia_do", 
      "ubezpieczony", 
      "nip_ubezpieczonego", 
      "adres_ubezpieczonego" 
    ] 
  } 
}

Przykłady certyfikatów ubezpieczeniowych.

Tabela poniżej przedstawia wyniki benchmarku. Dokładność ekstrakcji odnosi się do liczby dokumentów (z 11), w których model poprawnie wyodrębnił wszystkie kluczowe pola. Tokeny/sek to szybkość wnioskowania modelu — czyli tempo generowania odpowiedzi.

Model	Podsumowanie	Dokładność ekstrakcji	Tokeny/sek.
Llama 3.1 (8B)	Wysoka jakość, brak halucynacji	10/11	13.49
StableLM 3B	Średnia jakość, literówki/halucynacje	4/11	56.51
Llama 3.2 (3B)	Zwięzłe i pełne podsumowanie, brak halucynacji	8/11	49.49
Mistral 7B	Rozbudowane podsumowanie, zgodne z faktami	8/11	29.01
Gemma 3 4B	Zwięzłe i pełne podsumowanie, brak halucynacji	10/11	13.37
Gemma 3 1B	Zwięzłe i pełne podsumowanie, brak halucynacji	4/11	73.46
DeepSeek 7B	Zwięzłe i pełne podsumowanie, brak halucynacji	6/11	16.39
DeepSeek 1.5B	Bardzo słaba jakość, częste halucynacje/błędy	0/11	66.45
Phi-4 Mini 3.8B	Bardzo zwięzłe podsumowania, zgodne z faktami	9/11	39.31
TinyLlama 1.1B	Słaba jakość, poważne halucynacje	2/11	107.34

Tabela: Porównanie modeli

Ten wykres punktowy przedstawia kompromis między dokładnością ekstrakcji a szybkością wnioskowania (mierzoną w tokenach na sekundę).

Wyniki benchmarku ujawniają istotne różnice pomiędzy testowanymi modelami.

- Modele z dolnej prawej części wykresu — Llama 3.1 (8B), Gemma 3 (4B) i Phi-4 Mini (3.8B) — wyróżniają się wysoką jakością podsumowań i dokładnością ekstrakcji, konsekwentnie dostarczając zwięzłe i precyzyjne odpowiedzi. Phi-4 Mini wydaje się oferować dobry kompromis między szybkością a dokładnością.
- Modele takie jak Mistral 7B, DeepSeek 7B oraz Llama 3.2 generują szczegółowe i bogate w treść podsumowania, choć ich skuteczność w zadaniach ekstrakcji jest umiarkowana.
- Z kolei mniejsze modele (w lewej górnej części wykresu), takie jak StableLM Zephyr (3B), Gemma 3 (1B) i TinyLlama (1.1B), cechują się znacznie niższą dokładnością ekstrakcji i są podatne na częste halucynacje. Ich zaletą jest natomiast szybka inferencja. Ograniczone okna kontekstu (np. 4 tys. tokenów) mogą dodatkowo wpływać na obniżoną skuteczność. Ogólnie rzecz biorąc, modele te nadają się raczej do bardzo podstawowych zadań.

Dobór odpowiedniego modelu do Twoich potrzeb

Wybór modelu językowego do ekstrakcji lub podsumowywania dokumentów to kwestia znalezienia odpowiedniego balansu między dokładnością, szybkością działania a ograniczeniami sprzętowymi. Poniżej znajdziesz krótkie zestawienie, które pomoże Ci dobrać najlepsze rozwiązanie — niezależnie od tego, czy zależy Ci na wysokiej precyzji, szybkiej inferencji, czy lekkim modelu do podstawowych zadań.

- Wysoka dokładność i rozsądna szybkość: Wybierz Phi-4 Mini (3.8B), Gemma 3 (4B) lub Llama 3.1 (8B), jeśli zależy Ci na solidnej dokładności ekstrakcji i podsumowań.
- Szybka inferencja i umiarkowana dokładność: Postaw na Llama 3.2 (3B) lub StableLM Zephyr (3B) w przypadku prostszych zadań na sprzęcie o ograniczonych zasobach.
- Zrównoważona wydajność (kompromis między dokładnością a szybkością): Mistral (7B) oferuje silne możliwości ogólnego zastosowania, dobrze sprawdzając się w szczegółowych zadaniach podsumowywania dokumentów.
- Środowiska o niskich zasobach (zadania podstawowe): Rozważ TinyLlama (1.1B) do szybkiej ekstrakcji lub klasyfikacji na minimalnym sprzęcie, jeśli dokładność nie jest kluczowa.

Podsumowanie

Lekkie modele LLM stają się coraz bardziej dostępną opcją do lokalnego uruchamiania, szczególnie w branżach intensywnie pracujących z dokumentami, takich jak ubezpieczenia. Modele takie jak Phi-4 Mini, Gemma 3 (4B) czy Mistral 7B oferują wysoką wydajność w zadaniach podsumowywania, ekstrakcji i klasyfikacji. Odpowiednie zrównoważenie rozmiaru modelu, szybkości wnioskowania i dokładności pozwala osiągać optymalne rezultaty, dając organizacjom dostęp do niedrogich, prywatnych i responsywnych rozwiązań AI uruchamianych bezpośrednio na własnym sprzęcie.

To może Cię zainteresować

Optymalizacja procesów back – office, dzięki wdrożeniu agenta AI. Praktyczny przykład

Czytaj całość

Artykuł Lokalne LLM-y: testujemy lekkie modele do przetwarzania dokumentów pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

Lokalne wdrażanie modeli LLM: przewodnik po Ollama i LM Studio

Martyna Mul — Fri, 04 Apr 2025 10:40:41 +0000

Lokalne wdrażanie dużych modeli językowych (LLM) staje się coraz bardziej popularne wśród programistów, entuzjastów technologii oraz specjalistów z branż takich jak ubezpieczenia czy transport. W przeciwieństwie do rozwiązań opartych na chmurze, lokalne wdrażanie LLM-ów zapewnia większą prywatność, dostępność offline oraz pełną kontrolę nad optymalizacją zasobów i wydajnością działania modelu.

Uruchamianie modeli takich jak Llama 2 czy Mistral bezpośrednio na własnym sprzęcie oznacza, że dane pozostają na Twoim urządzeniu — co jest idealnym rozwiązaniem w przypadku zadań wymagających wysokiego poziomu prywatności, takich jak przetwarzanie dokumentów ubezpieczeniowych czy praca z zastrzeżonymi danymi transportowymi. Przy okazji nie ponosisz stałych kosztów związanych z API, a wydajność zależy wyłącznie od Twojego systemu. Niezależnie od tego, czy tworzysz własnego chatbota, agenta, asystenta programistycznego opartego na AI, czy analizujesz dokumenty offline — lokalne wdrożenie daje Ci swobodę eksperymentowania i wprowadzania innowacji bez konieczności polegania na zewnętrznych usługach.

W tym przewodniku przyjrzymy się dwóm zaawansowanym narzędziom, które umożliwiają lokalne uruchamianie modeli: Ollama i LM Studio. Przejdziemy przez proces instalacji, omówimy sposób ich użycia oraz możliwości dostosowania, pomagając Ci wybrać najlepsze rozwiązanie dopasowane do Twoich potrzeb.

Pierwsze kroki z Ollama (narzędzie CLI)

Ollama to wydajne, otwartoźródłowe narzędzie konsolowe do lokalnego uruchamiania modeli LLM. Działa jako menedżer modeli i środowisko wykonawcze, ułatwiając pobieranie i uruchamianie modeli open source (takich jak Llama 2, Mistral, CodeLlama itp.) bezpośrednio na Twoim komputerze. Ollama jest dostępna dla systemów macOS, Linux i Windows, a dodatkowo oferuje lokalne API REST do integracji z aplikacjami.

Zainstaluj Ollama na swoim systemie: Pobierz instalator dla swojego systemu operacyjnego ze strony internetowej Ollama lub skorzystaj z menedżera pakietów.

W systemie Windows pobierz plik OllamaSetup.exe ze strony internetowej i uruchom go.
W systemie Linux możesz zainstalować Ollama za pomocą jednej komendy:

curl -fsSL https://ollama.com/install.sh | sh

Po zakończeniu instalacji otwórz terminal (lub wiersz poleceń w systemie Windows) i sprawdź, czy Ollama zostało poprawnie zainstalowane, wyświetlając jego wersję:

ollama --version

Powinno to wyświetlić zainstalowaną wersję Ollama, co potwierdzi, że narzędzie jest gotowe do użycia, np.:

ollama version is 0.6.2

Pobierz model LLM („ściągnij” model): Ollama zawiera wbudowaną bibliotekę modeli. Możesz przeszukiwać katalog dostępny na stronie internetowej lub po prostu pobrać znany model, podając jego nazwę.
Na przykład, aby pobrać model Llama 2 Chat (7B), użyj polecenia:

ollama pull llama2:7b-chat

To polecenie pobiera na Twój komputer pliki modelu (może to chwilę potrwać, ponieważ mają one zazwyczaj kilka gigabajtów). Model wystarczy pobrać tylko raz — zostaje zapisany lokalnie. W razie potrzeby możesz wyświetlić listę wszystkich pobranych modeli za pomocą polecenia ollama list.

Uruchom model lokalnie: Po pobraniu możesz uruchomić model za pomocą polecenia ollama run. Spowoduje to uruchomienie interaktywnej sesji, w której możesz wpisywać zapytania i otrzymywać odpowiedzi. Na przykład:

ollama run llama2:7b-chat >>> What is the capital city of Poland?

Po uruchomieniu powyższego polecenia Ollama załaduje model, a na ekranie pojawi się znak >>>. Możesz wtedy wpisywać pytania lub polecenia. Model (w tym przypadku Llama 2 7B Chat) będzie generował odpowiedź na każde zapytanie. Na przykład możesz zapytać: „What is the capital of France?” i otrzymać odpowiedź: „Paris is the capital of France.” wyświetloną w terminalu.

Przy pierwszym uruchomieniu inicjalizacja modelu może chwilę potrwać, ale kolejne zapytania są obsługiwane szybciej, bez ponownego ładowania modelu.

Wskazówka: Możesz też przekazać jednorazowe zapytanie bezpośrednio w poleceniu, np. ollama run llama2:7b "What is the capital city of Poland?" spowoduje wygenerowanie jednej odpowiedzi i powrót do powłoki systemowej.

Możesz także uruchomić Ollama jako serwer w tle za pomocą polecenia ollama serve. Umożliwia to korzystanie z API REST dostępnego pod adresem localhost:11434, które deweloperzy mogą wykorzystać do integracji modelu z aplikacjami za pomocą zapytań HTTP. Możesz zadawać pytania modelowi, wysyłając zapytania POST, na przykład:

curl http://localhost:11434/api/generate -d '{ 
  "model": "llama2:7b-chat", 
  "prompt": "What is the capital city of Poland?" 
}'

API zwraca odpowiedź w postaci obiektów JSON, w miarę jak model stopniowo ją generuje. Każdy obiekt zawiera fragment tekstu (ang. chunk).

{ 
    "model": "llama2:7b-chat", 
    "created_at": "2025-04-02T15:19:17.1569954Z", 
 
    "response": "The", 
    "done": false 
} 
{ 
    "model": "llama2:7b-chat", 
    "created_at": "2025-04-02T15:19:17.268992Z", 
    "response": " capital", 
    "done": false 
} 
{ 
    "model": "llama2:7b-chat", 
    "created_at": "2025-04-02T15:19:17.3796491Z", 
    "response": " city", 
    "done": false 
} 
... 
{ 
    "model": "llama2:7b-chat", 
    "created_at": "2025-04-02T15:19:21.3106413Z", 
    "response": " Warszawa", 
    "done": false 
} 
{ 
    "model": "llama2:7b-chat", 
    "created_at": "2025-04-02T15:19:21.4619772Z", 
    "response": ").", 
    "done": false 
} 
{ 
    "model": "llama2:7b-chat", 
    "created_at": "2025-04-02T15:19:21.6296267Z", 
    "response": "", 
    "done": true, 
    "done_reason": "stop", 
    "total_duration": 5337417000, 
    "load_duration": 8625100, 
    "prompt_eval_count": 28, 
    "prompt_eval_duration": 854952300, 
    "eval_count": 15, 
    "eval_duration": 4472807400 
}

Jeśli ustawisz stream: false, odpowiedź zostanie zwrócona jako pojedynczy obiekt JSON.

curl http://localhost:11434/api/generate -d '{ 
  "model": "llama2:7b-chat", 
  "prompt": "What is the capital city of Poland?", 
  "stream": false 
}

Możesz również ustawić różne parametry modelu, takie jak temperatura (czyli poziom losowości generowanych odpowiedzi), dodając odpowiednie pola w opcjach.

curl http://localhost:11434/api/generate -d '{ 
  "model": "llama2:7b-chat", 
  "prompt": "What is the capital city of Poland?", 
  "options": { 
 "temperature": 0.2   
  } 
  "stream": false 
}'

Dostosuj modele: Ollama obsługuje pliki Modelfile o składni podobnej do Dockerfile, które umożliwiają tworzenie własnych wariantów modeli LLM. Dzięki niej możesz:

- Rozpocząć od istniejącego modelu (np. llama3)
- Dodać własne systemowe prompt’y
- Wprowadzić dane zdefiniowane przez użytkownika (np. instrukcje, kontekst)
- Ustawić parametry modelu, takie jak temperatura

Oto prosty przykład, jak możesz stworzyć własnego asystenta do przetwarzania dokumentów ubezpieczeniowych:

FROM llama2:7b-chat 
 
PARAMETER temperature 0.7 
 
SYSTEM """ 
 
You are an assistant that extracts insurance-related information from a given input text. 
 
You must extract and return only the following fields: 
- policy_number 
- insurance_period 
- insured (company or person name) 
- nip (tax identification number) 
- address (of the insured) 
 
Return the output as a **clean JSON object** -- not as a string, not inside quotes, and without any commentary. If a field is missing, use "Not found". 
Example output format: 
{ 
  "policy_number": "...", 
  "insurance_period": "...", 
  "insured": "...", 
  "nip": "...", 
  "address": "..." 
} 
 
""" 
TEMPLATE """ 
{{ .System }} 
Input: 
{{ .Prompt }} 
Response: 
""" Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

Aby skorzystać z pliku Modelfile, zapisz go w wybranym katalogu, np. insurance-assistant, a następnie utwórz własny model za pomocą polecenia:

ollama create insurance-assistant -f insurance-assitant/Modelfile

Następnie możesz użyć swojego modelu, podając właściwą nazwę modelu w zapytaniu:

 curl http://localhost:11434/api/generate -d '{ 
  "model": "insurance-extractor", 
  "prompt": "", 
  "stream": false 
}'

Ollama działa wyłącznie w trybie konsolowym — nie posiada graficznego interfejsu użytkownika. Jednak dzięki temu świetnie sprawdza się w automatyzacji: możesz przekierowywać dane wejściowe i wyjściowe, zapisywać odpowiedzi do plików lub korzystać z API Ollama bezpośrednio w kodzie.

Podsumowując, za pomocą zaledwie kilku poleceń możesz uruchomić lokalnie model LLM, który chroni prywatność, działa bez połączenia z internetem i jest gotowy do odpowiadania na pytania lub wspierania Cię w pracy programistycznej.

Pierwsze kroki z LM Studio (aplikacja desktopowa)

LM Studio to przyjazna dla użytkownika aplikacja desktopowa, która umożliwia pobieranie i uruchamianie lokalnych modeli LLM za pomocą interfejsu graficznego. Działa na wielu platformach (Windows, macOS, Linux) i jest idealna dla początkujących, którzy wolą nie korzystać z konsoli. Dzięki LM Studio możesz rozmawiać z modelami w estetycznym interfejsie, zarządzać pobieraniem modeli, a także uruchomić lokalny serwer, by wykorzystywać model w innych aplikacjach.

To polecenie pobiera pliki modelu na Twój komputer (może to potrwać, ponieważ modele mają zazwyczaj kilka gigabajtów). Model wystarczy pobrać tylko raz — później jest przechowywany lokalnie. W razie potrzeby możesz wyświetlić listę wszystkich pobranych modeli za pomocą polecenia ollama list.

Zainstaluj i uruchom LM Studio: Pobierz instalator dla swojego systemu operacyjnego ze strony LM Studio i zainstaluj aplikację. Po zakończeniu instalacji uruchom LM Studio. Przy pierwszym uruchomieniu zostaniesz poproszony o pobranie modelu AI. Możesz wybrać jeden z popularnych modeli open source z dostępnej listy. Na początek możesz na przykład wybrać mniejszy model, taki jak „Mistral 7B” lub wariant Llama2 dostosowany do instrukcji.
Uruchom swoją pierwszą rozmowę: Gdy model zostanie pobrany, LM Studio załaduje go do pamięci. Następnie możesz rozpocząć nową sesję czatu w aplikacji. Interfejs zazwyczaj zawiera pole tekstowe, w którym wpisujesz zapytanie lub polecenie, a odpowiedź modelu pojawia się w oknie rozmowy. Wystarczy, że wpiszesz pytanie (na przykład: „Jaka jest stolica Francji?” albo „Wyjaśnij mechanikę kwantową w prosty sposób”) i naciśniesz Enter. Odpowiedź AI zostanie wyświetlona jako odpowiedź „Asystenta” w czacie.
LM Studio w przejrzysty sposób pokazuje również metryki generowania odpowiedzi.

- liczba tokenów wejściowych i wyjściowych,
- tokeny na sekundę – możesz zobaczyć, jak szybko model generuje tekst,
- zajętość kontekstu,
- wykorzystanie zasobów systemowych (RAM i użycie procesora).

Odkryj dostępne funkcje: Graficzny interfejs LM Studio oferuje dodatkowe możliwości dostępne zarówno dla początkujących, jak i zaawansowanych użytkowników:

- Biblioteka modeli: Sekcja „Odkrywaj modele” lub katalog, w którym możesz pobierać nowe modele lub aktualizować już posiadane. Nie jesteś ograniczony do jednego modelu — możesz przechowywać wiele modeli i swobodnie się między nimi przełączać. Oznacza to szeroki wybór: od małych modeli z 3 miliardami parametrów, zapewniających szybkość działania, aż po modele 70-miliardowe, jeśli Twój system jest w stanie je obsłużyć.

- Interfejs czatu: Główne okno czatu (jak pokazano wcześniej) to miejsce, w którym prowadzisz interakcję z modelem. Każde nowe zapytanie, które wpiszesz, jest traktowane jako część rozmowy i otrzymuje odpowiedź w formacie konwersacyjnym. Możesz prowadzić wieloetapowy dialog — tak jak w rozmowie z ChatGPT. Nie musisz samodzielnie zarządzać historią zapytań — aplikacja automatycznie zachowuje kontekst rozmowy.

- Ustawienia zaawansowane: W panelu bocznym LM Studio udostępnia opcje konfiguracji dla użytkowników, którzy chcą mieć większą kontrolę nad działaniem modelu. Możesz ustawić systemowy prompt (czyli rolę lub instrukcję, która globalnie wpływa na zachowanie AI), dostosować parametry generowania, takie jak temperatura (twórczość vs. spójność), top-p lub top-k (do kontrolowania losowości), maksymalna liczba tokenów w odpowiedzi itd. Te ustawienia pozwalają precyzyjnie dostosować sposób działania modelu — bez potrzeby pisania kodu.
  Na przykład możesz ustawić instrukcję systemową typu: „Jesteś pomocnym asystentem programisty”. To przystępny sposób na personalizację zachowania modelu, choć nie tak rozbudowany jak możliwości oferowane przez narzędzie konsolowe.

Ustawienia zaawansowane – prosty przykład asystenta AI do przetwarzania dokumentów ubezpieczeniowych.

- Lokalny serwer API: Dla deweloperów LM Studio oferuje tryb „Local LLM Server”. Wystarczy przełączyć się na zakładkę Developer, wybrać model i kliknąć przycisk Start. Włącza to punkt końcowy API na localhost, który imituje API OpenAI, co pozwala innym programom wysyłać zapytania do lokalnie uruchomionego modelu.
  To bardzo przydatne rozwiązanie, jeśli chcesz zintegrować lokalny model LLM z własnymi aplikacjami (na przykład podłączając interfejs czatu lub wykorzystując model do funkcji AI w środowisku IDE), zachowując jednocześnie prywatność i uniezależniając się od usług zewnętrznych.

Zakładka Developer – umożliwia uruchomienie lokalnego serwera LLM, hostującego Twój spersonalizowany model.

Korzystanie z LM Studio jest równie proste jak w przypadku ChatGPT — wpisujesz zapytanie i otrzymujesz odpowiedź — z tą różnicą, że wszystko działa lokalnie na Twoim sprzęcie. Przyjazny interfejs użytkownika obniża próg wejścia, ponieważ nie musisz używać konsoli ani pamiętać poleceń. Otrzymujesz natychmiastowe, interaktywne odpowiedzi AI, a wszystkim możesz wygodnie zarządzać za pomocą przycisków i menu.

Ollama vs. LM Studio: porównanie narzędzi

Zarówno Ollama, jak i LM Studio umożliwiają lokalne uruchamianie modeli LLM, jednak są skierowane do nieco innych grup użytkowników i przypadków użycia. Oto porównanie kluczowych aspektów, które pomoże zrozumieć różnice między tymi narzędziami:

- Interfejs i łatwość obsługi:
  LM Studio oferuje dopracowany graficzny interfejs użytkownika, co czyni je wyjątkowo przystępnym dla początkujących. Obsługa odbywa się metodą „wskaż i kliknij”, z wbudowanym oknem czatu, dzięki czemu nie jest wymagana żadna wiedza techniczna, aby rozpocząć pracę.
  Ollama z kolei to narzędzie konsolowe (CLI) z opcjonalnym API REST. Daje dużą moc i elastyczność, ale wymaga swobody w korzystaniu z terminala, aby w pełni wykorzystać jego możliwości. Początkujący mogą uznać krzywą uczenia się Ollamy za bardziej stromą, podczas gdy LM Studio sprawia wrażenie rozwiązania typu „podłącz i używaj”.

- Obsługiwane modele:
  Oba narzędzia obsługują szeroką gamę otwartoźródłowych modeli LLM. LM Studio może ładować dowolny model w formacie GGUF (standard używany przez llama.cpp), co oznacza, że możesz korzystać z modeli takich jak Llama 2 (7B, 13B, 70B), Mistral, Vicuna, Alpaca, CodeLlama i wielu innych — o ile Twój sprzęt jest w stanie je obsłużyć.

- Odpowiednie zastosowania:
  Ze względu na powyższe różnice, LM Studio świetnie sprawdzi się u użytkowników, którzy chcą mieć na swoim komputerze osobistego asystenta w stylu ChatGPT, bez potrzeby skomplikowanej konfiguracji. To dobre rozwiązanie do interaktywnych pytań i odpowiedzi, burzy mózgów czy codziennego, swobodnego użytkowania — uruchamiasz, gdy potrzebujesz, wpisujesz zapytanie, otrzymujesz odpowiedź.
  Ollama natomiast jest idealna dla programistów oraz osób, które chcą zintegrować modele LLM ze swoimi projektami lub procesami. Jeśli planujesz eksperymentować z promptami w skryptach, dostosowywać zachowanie modelu lub budować aplikację (np. chatbota, integrację asystenta kodu itp.), interfejs CLI i API Ollamy daje Ci elastyczność potrzebną do takich zastosowań.

Wnioski i rekomendacje

Lokalne wdrażanie modeli LLM oferuje wiele możliwości dla programistów i entuzjastów. Omówiliśmy Ollama i LM Studio – dwa doskonałe narzędzia, które umożliwiają dostęp do lokalnej sztucznej inteligencji. Oto krótkie podsumowanie wskazówek dotyczących wyboru między nimi:

- Wybierz LM Studio, jeśli chcesz gotowe rozwiązanie do rozmów z AI z przyjaznym interfejsem graficznym. To idealna opcja dla początkujących lub osób, które nie chcą korzystać z konsoli. Oferuje szybkie uruchomienie, łatwe pobieranie modeli i wygodny interfejs czatu do interakcji z AI. Świetnie sprawdzi się jako „offline’owy ChatGPT” do użytku osobistego, robienia notatek czy generowania pomysłów — bez konieczności zagłębiania się w konfigurację. To także wygodny sposób na zaprezentowanie możliwości LLM osobom nietechnicznym, ponieważ aplikacja działa jak zwykły program.

- Wybierz Ollama, jeśli zależy Ci na większej kontroli, automatyzacji lub integracji. Deweloperzy i zaawansowani użytkownicy docenią jej elastyczność — możesz ją skryptować, uruchamiać bez interfejsu na serwerze, integrować lokalny model LLM z własnymi aplikacjami przez API oraz dostosowywać zachowanie modeli za pomocą plików Modelfile. Jeśli dobrze czujesz się w pracy z konsolą i chcesz precyzyjnie kontrolować sposób działania AI (poza tym, co oferuje interfejs graficzny), Ollama będzie lepszym wyborem. To także lekkie narzędzie, jeśli planujesz uruchamiać usługi AI w tle w sposób ciągły.

Na koniec pamiętaj, że sam model LLM, który wybierzesz, jest równie istotny jak narzędzie. Warto poświęcić czas na znalezienie modelu dopasowanego do konkretnego zadania — niezależnie od tego, czy potrzebujesz zwięzłego narzędzia do podsumowań, czy kreatywnego opowiadacza historii — i dostosowanego do możliwości Twojego sprzętu. Zarówno Ollama, jak i LM Studio umożliwiają łatwą zamianę modeli, więc nie jesteś ograniczony do jednego wyboru. Ekosystem otwartoźródłowych modeli rozwija się bardzo szybko, co oznacza, że uruchamianie zaawansowanej AI na własnym urządzeniu staje się coraz prostsze i powszechniejsze.

Podsumowując, lokalne wdrażanie modeli LLM za pomocą omawianych w tym tekście narzędzi daje Ci to, co najlepsze z obu światów: możliwości sztucznej inteligencji porównywalne z usługami chmurowymi, ale z zachowaniem prywatności, pełną kontrolą i bez żadnych stałych kosztów. Niezależnie od tego, czy wybierzesz zaawansowane narzędzie konsolowe, takie jak Ollama, czy przyjazną aplikację graficzną, jak LM Studio — dołączasz do czołówki rozwoju lokalnej AI.

Powodzenia w eksperymentach i udanego korzystania z własnego, lokalnego asystenta AI!

Artykuł Lokalne wdrażanie modeli LLM: przewodnik po Ollama i LM Studio pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

OpenAI vs. DeepSeek: Techniczne porównanie z wykorzystaniem zunifikowanych interfejsów API

Martyna Mul — Fri, 14 Mar 2025 14:40:50 +0000

Duże modele językowe (LLM) są coraz częściej wykorzystywane do analizy i ekstrakcji informacji z obszernych dokumentów, w tym długich raportów statystycznych w formacie PDF. Jednak nie wszystkie modele radzą sobie równie dobrze z przetwarzaniem dużych plików, zwłaszcza tych przekraczających 50 stron. W tym artykule przeprowadzamy analizę porównawczą trzech popularnych modeli LLM—modeli GPT od OpenAI: 4o-mini i o3-mini, oraz DeepSeek R1—w celu oceny ich skuteczności w odczytywaniu i analizie danych statystycznych z dużych plików PDF. Nasza ocena koncentruje się na trzech kluczowych czynnikach: dokładności, czasie odpowiedzi oraz szacunkowych kosztach korzystania z każdego modelu.

Aby zapewnić rzetelne porównanie, wykorzystaliśmy LiteLLM – zunifikowane API, które upraszcza benchmarking różnych modeli LLM. Standaryzując interakcje między dostawcami modeli, LiteLLM pozwoliło nam skupić się na ocenie metryk wydajności LLM zamiast na różnicach w implementacji.

Zunifikowane podejście API

Porównywanie modeli LLM typu od różnych dostawców bywa wyzwaniem ze względu na różnice w ich interfejsach API. Aby ujednolicić nasze testy, wykorzystaliśmy LiteLLM – bibliotekę zapewniającą spójny interfejs do obsługi wielu modeli LLM. Dzięki temu możliwa była łatwa zamiana modeli oraz bardziej obiektywne porównanie ich wydajności. Oto, jak proste jest przełączanie między modelami przy użyciu zunifikowanego API LiteLLM:

import litellm 
 
# To use openai. 
response = litellm.completion(model="o3-mini", messages=[{"content": "Hello", "role": "user"}]) 
 
# To use deepseek. 
response = litellm.completion(model="deepseek/deepseek-reasoner", messages=[{"content": "Hello", "role": "user"}])

To uproszczone podejście pozwoliło nam porównać modele bez konieczności zajmowania się złożonością ich implementacji.

DeepSeek vs. OpenAI – przegląd modeli

Zanim przejdziemy do wyników benchmarku modeli AI, zdefiniujmy kluczowe pojęcia i przedstawmy podstawowe specyfikacje testowanych modeli.

Jednym z najważniejszych parametrów w benchmarkingu modeli LLM jest okno kontekstowe – maksymalna liczba tokenów, które model może przetworzyć jednocześnie. Tokeny reprezentują fragmenty tekstu, a nie pojedyncze słowa. Większe okno kontekstowe pozwala modelowi obsługiwać bardziej rozbudowane dokumenty w jednym zapytaniu, co ma kluczowe znaczenie przy pracy z długimi raportami statystycznymi.

Ceny korzystania z modeli LLM są zazwyczaj oparte na liczbie przetworzonych tokenów, przy czym koszt może się różnić w zależności od rodzaju tokenów. W modelach LLM wyróżnia się zazwyczaj trzy typy tokenów wpływające na wycenę:

Tokeny wejściowe (input tokens) – reprezentują dane dostarczane do modelu, takie jak tekst zapytania lub dokument do analizy. Koszt przetwarzania wejściowych tokenów zależy od modelu i dostawcy.
Tokeny wyjściowe (output tokens) – to treść generowana przez model w odpowiedzi na zapytanie. Ponieważ modele LLM mogą zwracać różne długości odpowiedzi, liczba tokenów wyjściowych ma istotny wpływ na końcowy koszt użytkowania.
Tokeny kontekstowe (context tokens) – obejmują zarówno tokeny wejściowe, jak i poprzednie odpowiedzi modelu w sesji konwersacyjnej. Im większy kontekst przechowywany w pamięci modelu, tym większe zużycie tokenów i potencjalnie wyższy koszt.

Zrozumienie tych kategorii jest kluczowe dla optymalizacji kosztów korzystania z LLM, zwłaszcza w przypadku analizy dużych dokumentów.

Modele wybrane do tego porównania należą do najnowszych wersji wydanych w ostatnich miesiącach. Choć różnią się pod względem cen i możliwości, naszym celem jest ocena, czy te różnice przekładają się na mierzalne różnice w wydajności. Poniżej przedstawiamy kluczowe charakterystyki modeli DeepSeek-R1, OpenAI 4o-mini oraz OpenAI o3-mini:

	DeepSeek-R1	OpenAI 4o-mini	OpenAI o3-mini
Okno kontekstowe	128 000 tokenów	128 000 tokenów (maksymalnie 16 384 tokenów w odpowiedzi)	200 000 tokenów (maksymalnie 100 000 tokenów w odpowiedzi)
Data wydania	Styczeń 2025	Lipiec 2024	Styczeń 2025
Cennik (za 1 milion tokenów)	Wejście: 0,55 USD Pamięć podręczna wejścia: 0,14 USD Wyjście: 2,19 USD	Wejście: 0,15 USD Pamięć podręczna wejścia: 0,075 USD Wyjście: 0,60 USD	Wejście: 1,10 USD Pamięć podręczna wejścia: 0,55 USD Wyjście: 4,40 USD
Obsługiwane formaty wejściowe	Tekst	Tekst, obrazy (w tym PNG, JPEG, GIF, WEBP)	Tekst
Obsługiwane formaty wyjściowe	Tekst	Tekst	Tekst

Plik PDF użyty do testów

Dokument użyty do testów składa się z kilku rozdziałów raportu dotyczącego polskiej i światowej gospodarki morskiej w latach 2017–2020. Raport ma 50 stron i zawiera różne statystyki oraz analizy dotyczące ruchu ładunkowego, żeglugi, przemysłu stoczniowego i innych sektorów gospodarki morskiej. Dane w pliku są sformatowane w tabelach i tekście. Większość informacji przedstawiono w tabelach, z dodatkowymi objaśnieniami i podsumowaniami w otaczającym tekście. Przykładowe strony dokumentu użytego do testów:

Metodologia testowania

Przeprowadziliśmy serię testów, wykorzystując następujące zapytania związane z gospodarką morską oraz plik PDF zawierający kontekstowe informacje. Oto przykładowe zapytania dotyczące danych zawartych w pliku PDF:

- Podsumuj kluczowe wnioski ekonomiczne z raportu dotyczącego gospodarki morskiej.
- Jaki był całkowity obrót ładunkowy w polskich portach morskich w 2020 roku?
- Jakie są główne rodzaje ładunków obsługiwanych przez polskie porty morskie?
- Które kraje są głównymi partnerami handlowymi Polski w transporcie morskim?
- Jaki jest średni wiek statków we flocie polskiego transportu morskiego?
- Jakie są kluczowe wskaźniki ekonomiczne polskiego przemysłu stoczniowego?

Jak wcześniej wspomniano, porównaliśmy następujące modele:

- OpenAI’s 4o-mini

- OpenAI’s o3-mini

- DeepSeek’s deepseek-resoner (R1)

Zmierzyliśmy następujące metryki:

- Czas inferencji – Określa czas potrzebny modelowi na wygenerowanie odpowiedzi po otrzymaniu zapytania. Krótszy czas inferencji oznacza szybsze reakcje, co ma kluczowe znaczenie dla aplikacji czasu rzeczywistego oraz przetwarzania dużych dokumentów.
- Zużycie tokenów – Modele LLM przetwarzają i generują tekst w jednostkach zwanych tokenami. Token może być pełnym słowem, jego częścią lub nawet znakiem interpunkcyjnym. Całkowite zużycie tokenów obejmuje zarówno tokeny wejściowe (zapytanie użytkownika lub dokument), jak i tokeny wyjściowe (odpowiedź modelu). Im więcej tokenów jest używanych, tym wyższy koszt zapytania.
- Koszt odpowiedzi – Obliczany jako zużycie tokenów × cena modelu (za 1 000 lub 1 000 000 tokenów, w zależności od dostawcy). Ponieważ różne modele mają różne struktury cenowe, porównanie kosztów odpowiedzi pozwala określić, który model jest bardziej opłacalny w zastosowaniach na dużą skalę.

Wyniki testów

Oto podsumowane wyniki naszych testów (każdy test był powtarzany kilkukrotnie):

Model	Średni czas inferencji (s)	Średni koszt odpowiedzi ($)	Średnia liczba tokenów wejściowych	Średnia liczba tokenów wyjściowych
DeepSeek R1	57,2	0,0039	63 961,7	751,6
o3-mini	13,8	0,0755	63 251,5	1 162,5
4o-mini	9,5	0,0511	62 538,0	1 046,5

Kluczowe wnioski

- Czas inferencji: DeepSeek konsekwentnie wykazywał dłuższe czasy inferencji w porównaniu do obu modeli OpenAI. Może to być istotny czynnik dla aplikacji, które wymagają szybkiego przetwarzania.
- Koszt odpowiedzi: DeepSeek wykazał przewagę kosztową, szczególnie w zakresie tokenów wyjściowych. Pomimo dłuższego czasu inferencji, całkowity koszt zapytania pozostaje niższy niż w przypadku OpenAI o3-mini i 4o-mini. Niższy koszt odpowiedzi DeepSeek wynika z mechanizmu buforowania, który ogranicza konieczność ponownego przetwarzania danych wejściowych. Większość treści wejściowych, zwłaszcza zawartość pliku PDF, była buforowana, co pozwoliło na znaczne oszczędności w kosztach przetwarzania. Dzięki temu systemowi DeepSeek efektywnie obsługiwał powtarzające się zapytania, czyniąc go opłacalnym wyborem do analizy dużych dokumentów.
- Zmienność odpowiedzi: Modele różniły się pod względem stylu i poziomu szczegółowości generowanych odpowiedzi. Ma to znaczenie w zależności od kontekstu i wymagań użytkownika (np. ogólne podsumowania vs. szczegółowa analiza).
- API LiteLLM: LiteLLM znacząco ułatwiło śledzenie kosztów, zużycia tokenów i czasu odpowiedzi bezpośrednio w odpowiedziach API, umożliwiając prostą i przejrzystą analizę porównawczą modeli.

Podsumowanie

Nasze testy podkreślają zalety stosowania zunifikowanych interfejsów API do benchmarkingu modeli LLM. LiteLLM znacząco uprościło cały proces, pozwalając nam skupić się na ocenie efektywności modeli oraz ich wydajności.

DeepSeek R1 wykazał się konkurencyjną opłacalnością, głównie dzięki mechanizmowi buforowania, który redukował koszty ponownego przetwarzania tych samych danych wejściowych. Jednak był zdecydowanie najwolniejszym modelem w naszych testach, osiągając średni czas inferencji na poziomie 57,2 sekundy.

Z kolei OpenAI o3-mini i 4o-mini zapewniały znacznie krótszy czas odpowiedzi, co czyni je bardziej odpowiednimi dla zastosowań wymagających przetwarzania w czasie rzeczywistym.

Artykuł OpenAI vs. DeepSeek: Techniczne porównanie z wykorzystaniem zunifikowanych interfejsów API pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

Ocena dużych modeli językowych (LLM) z wykorzystaniem Retrieval-Augmented Generation (RAG) i DeepEval dla złożonych danych tabelarycznych

Martyna Mul — Tue, 04 Feb 2025 11:56:49 +0000

Modele Retrieval-Augmented Generation (RAG) zmieniają sposób, w jaki inteligentni asystenci przetwarzają informacje, umożliwiając bardziej precyzyjne i kontekstowe odpowiedzi na zapytania użytkowników. W przeciwieństwie do tradycyjnych dużych modeli językowych (LLMs), systemy RAG łączą dwa kluczowe elementy: mechanizm wyszukiwania, który pobiera istotne dokumenty, oraz model generatywny, który tworzy odpowiedzi na podstawie aktualnych danych. W tym artykule przyjrzymy się, jak DeepEval pomaga w systematycznej ocenie skuteczności zarówno wyszukiwania, jak i generowania, zwiększając wiarygodność informacji tworzonych przez AI.

Chociaż wirtualni asystenci wykorzystujący RAG znacząco poprawiają trafność odpowiedzi, ich skuteczna ocena nadal stanowi wyzwanie. Ponieważ modele te opierają się zarówno na mechanizmie wyszukiwania, jak i generowaniu tekstu, niedokładne lub nieefektywne pobieranie dokumentów może prowadzić do błędnych lub mylących odpowiedzi, nawet jeśli sam model językowy (LLM) jest zaawansowany technologicznie.

W tym artykule przedstawimy ten proces na przykładzie naszego autorskiego asystenta AI, zaprojektowanego do udzielania odpowiedzi na złożone pytania dotyczące statystyk gospodarki morskiej. Pokażemy, jak wykorzystanie LLM do inteligentnego wyszukiwania informacji wspiera podejmowanie decyzji opartych na danych.

SeaStat - nasz asystent AI

Świetnym przykładem, który możemy wykorzystać do omówienia tego zagadnienia, jest asystent AI SeaStat, opracowany przez nas w ramach projektu Incone60 Green (https://www.incone60.eu/). Celem tego projektu jest zwiększenie konkurencyjności oraz wspieranie zrównoważonego rozwoju małych portów morskich w regionie południowego Bałtyku.

W ramach projektu Incone60 Green opracowaliśmy asystenta AI, który odpowiada na pytania dotyczące danych gospodarki morskiej, zapewniając natychmiastowy dostęp do uporządkowanych informacji. Asystent wykorzystuje podejście Retrieval-Augmented Generation (RAG), dzięki czemu jego odpowiedzi opierają się na ustrukturyzowanej bazie danych obejmującej kluczowe aspekty, takie jak porty morskie, transport morski, stocznie, ruch pasażerski, handel oraz przemysł rybny.

Nasz asystent AI działa w ramach potoku RAG, który integruje trzy kluczowe elementy:

Ustrukturyzowaną bazę danych gospodarki morskiej, zawierającą globalne i polskie statystyki morskie z lat 2017–2020. Dane pochodzą z publikacji Uniwersytetu Morskiego w Gdyni, które agregują informacje z instytutów rządowych, uczelni oraz przedsiębiorstw portowych. Baza składa się z 50 tabel obejmujących kluczowe aspekty transportu morskiego i będzie rozszerzana o kolejne lata.
Dynamiczne generowanie zapytań SQL, umożliwiające precyzyjne pobieranie potrzebnych informacji z bazy danych.
Generatywny model LLM, który formułuje odpowiedzi na podstawie uzyskanych danych.

Budowa takiego asystenta wymaga kilku istotnych decyzji i optymalizacji, w tym:

Dobór odpowiedniego modelu LLM oraz dostosowanie jego parametrów (np. temperatury).
Projektowanie skutecznej struktury promptów, zapewniającej jasne i trafne odpowiedzi.
Zoptymalizowanie mechanizmu wyboru tabel, tak aby asystent konsekwentnie korzystał z najbardziej adekwatnych danych.

Na tym etapie automatyczne testowanie odgrywa kluczową rolę – pozwala mierzyć wydajność systemu, wykrywać jego słabe punkty oraz zapewniać jego stały rozwój.

LLM-as-a-Judge: Automatyzacja ewaluacji modeli RAG

Ocena systemów generujących niedeterministyczne, otwarte odpowiedzi tekstowe stanowi wyzwanie, ponieważ często nie istnieje jedna „poprawna” odpowiedź. Choć ocena przeprowadzana przez ludzi jest precyzyjna, bywa kosztowna i czasochłonna.

LLM-as-a-Judge to metoda, która naśladuje ocenę ludzką, oceniając wyniki systemu na podstawie dostosowanych kryteriów, dopasowanych do konkretnej aplikacji. Jednym z narzędzi wspierających ten proces jest DeepEval – framework testowy, który oferuje zestaw metryk zarówno dla zadań wyszukiwania, jak i generowania tekstu, a także umożliwia tworzenie własnych kryteriów oceny.

Kluczowe metryki oceny:

G-Eval – uniwersalna metryka oceniająca odpowiedzi LLM na podstawie niestandardowych, zdefiniowanych kryteriów.
Answer Relevancy – mierzy, jak dobrze odpowiedź modelu odnosi się do zapytania użytkownika.
Faithfulness – ocenia, na ile odpowiedź jest zgodna z dostarczonym kontekstem, co pomaga ograniczyć halucynacje w systemach RAG.
ContextualRecallMetric, ContextualPrecisionMetric, ContextualRelevancyMetric – metryki szczególnie przydatne w systemach RAG, oceniające, czy mechanizmy wyszukiwania zwracają wszystkie istotne informacje, jednocześnie eliminując treści nieistotne.

Testowanie modelu RAG za pomocą DeepEval – krok po kroku

Aby zapewnić niezawodność i dokładność naszego modelu Retrieval-Augmented Generation (RAG), stosujemy ustrukturyzowane podejście do ewaluacji. Proces ten obejmuje tworzenie zbioru danych, generowanie odpowiedzi oraz ocenę modelu za pomocą DeepEval, co pozwala na systematyczną analizę skuteczności zarówno komponentu wyszukiwania, jak i generowania.

Przyjrzyjmy się każdemu z tych kroków.

1. Tworzenie Zbioru Danych

Aby skutecznie ocenić wydajność modelu, tworzymy zestaw testowy składający się z:

Realistycznych pytań użytkowników – obejmujących zarówno proste zapytania faktograficzne, jak i bardziej złożone pytania wieloetapowe, wymagające szczegółowych odpowiedzi na podstawie wielu tabel.
Oczekiwanych odpowiedzi referencyjnych (ground truth) – pochodzących bezpośrednio z bazy danych, zapewniających wzorzec do oceny poprawności generowanych odpowiedzi.

2. Generowanie Odpowiedzi Modelu

Dla każdego zapytania testowego asystent generuje odpowiedź na podstawie odpowiednich danych pobranych z bazy danych.

3. Ewaluacja za pomocą DeepEval

Szczególnie zależy nam na poprawności faktograficznej naszego asystenta, dlatego do oceny tego aspektu wykorzystujemy metrykę G-Eval.

Musimy zdefiniować G-Eval, opisując kryteria testowe, np.:

correctness_metric = GEval(     
    name="Correctness",      
    evaluation_steps=[   
        "Assess whether the actual output is accurate in terms of facts compared to the expected output.",       
        "Penalize missing information."   
    ],       
    evaluation_params=[   
       LLMTestCaseParams.INPUT,    
       LLMTestCaseParams.ACTUAL_OUTPUT,    
       LLMTestCaseParams.EXPECTED_OUTPUT   
    ],     
)

Dodatkowo korzystamy z kilku wbudowanych metryk:

contextual_precision = ContextualPrecisionMetric() 
contextual_recall = ContextualRecallMetric() 
contextual_relevancy = ContextualRelevancyMetric() 
answer_relevancy = AnswerRelevancyMetric() 
faithfulness = FaithfulnessMetric()

Następnie definiujemy przypadki testowe:

test_case = LLMTestCase(   
    input=#user prompt,   
    actual_output=#model output here,   
    expected_output=#the ground truth response  

    retrieval_context=#data extracted by retriever, in our case it is data extracted from the database 
)

Oto jeden z przypadków testowych, których użyliśmy do oceny naszego asystenta SeaStat:

test_case = LLMTestCase(   
    input='Compare cargo traffic in Suez Canal and Panama Canal in 2019',   
    actual_output= 'In 2019, the cargo traffic data for the Suez Canal and Panama Canal was as follows: Suez Canal - 1031 million tons; Panama Canal - 243059 thousand tons. The Suez Canal had significantly higher cargo traffic compared to the Panama Canal in 2019.'  
    expected_output=' In 2019, the Suez Canal handled 1,031 million tons of cargo, whereas the Panama Canal transported only 243 million tons. This indicates that the Suez Canal carried a substantially higher volume of cargo than the Panama Canal that year.'  

    retrieval_context=[ 

{'table': 'Suez_Canal_Cargo_Traffic', 'year': 2019, 'cargo_volume_million_tons': 1031}, 

{'table': 'Panama_Canal_Cargo_Traffic', 'year': 2019, 'direction': 'Atlantic – Pacific', 'cargo_volume_thousand_tons': 156899}, {'table': 'Panama_Canal_Cargo_Traffic', 'year': 2019, 'direction': 'Pacific – Atlantic', 'cargo_volume_thousand_tons': 86160} 

] 
)

I przeprowadzamy ewaluację:

assert_test(test_case, [correctness_metric, answer_relevancy, contextual_precision, contextual_recall, contextual_relevancy, faithfulness])

4. Testowanie wyników

DeepEval przypisuje każdej metryce wynik w skali od 0 do 1, wraz z opisowym wyjaśnieniem oceny. Poniżej przedstawiamy wyniki jednego z testów oceniających odpowiedź asystenta SeaStat na zapytanie:

„Porównaj ruch towarowy w Kanale Sueskim i Kanale Panamskim w 2019 roku.”

Interpretacja wyników metryk:

Contextual Recall (1.0) – Mechanizm wyszukiwania skutecznie pobrał wszystkie kluczowe informacje, zapewniając prawie pełne pokrycie oczekiwanej odpowiedzi.
Contextual Relevancy (0.95) i Contextual Precision (1.0) – Pobrany kontekst był bardzo trafny, co oznacza, że retriever precyzyjnie dobrał informacje istotne dla zapytania.
Faithfulness (1.0) – Odpowiedź modelu była w pełni zgodna z dostarczonymi danymi i nie zawierała żadnych halucynacji.
Answer Relevancy (1.0) – Model dokładnie odpowiedział na pytanie użytkownika, dostarczając kompletną i adekwatną odpowiedź.
Correctness (0.78) – Wynik był nieco niższy z powodu drobnych rozbieżności liczbowych wynikających z zaokrągleń.

Systematyczna analiza przypadków testowych za pomocą DeepEval dostarcza cennych informacji na temat mocnych stron naszego modelu RAG oraz obszarów wymagających usprawnień. Przyszłe optymalizacje mogą obejmować ulepszenie strategii wyszukiwania, dopracowanie promptów lub dostosowanie parametrów modelu LLM w celu poprawy precyzji faktograficznej.

Test case	Metric	Score	Status	Overall Success Rate
test_case_0	Correctness (GEval)	0.78 (threshold=0.5, evaluation model=gpt-4o, reason=The actual output closely matches the expected output in terms of cargo volumes and comparative conclusion, but the numbers are expressed in different units (thousand tons vs million tons) and slightly differ, which may indicate rounding or conversion discrepancies., error=None)	PASSED	100%
	Answer Relevancy	1.0 (threshold=0.5, evaluation model=gpt-4o, reason=The score is 1.00 because the response thoroughly addressed the comparison of cargo traffic in the Suez Canal and the Panama Canal in 2019 with no irrelevant details included. It’s precise and to the point, showcasing a deep understanding of the topic., error=None)	PASSED
	Contextual Precision	1.0 (threshold=0.5, evaluation model=gpt-4o, reason=The score is 1.00 because the relevant nodes, offering essential data for comparing cargo traffic in the Suez and Panama Canals in 2019, are perfectly ranked at the top. These nodes effectively deliver a comprehensive breakdown of cargo volumes through both canals during that year, ensuring accurate comparisons can be made efficiently., error=None)	PASSED
	Contextual Recall	1.0 (threshold=0.5, evaluation model=gpt-4o, reason=The score is 1.00 because every sentence in the expected output aligns perfectly with the data from the nodes in the retrieval context, effectively illustrating the significant difference in cargo volumes handled by both canals. Well done on maintaining precise and accurate attention to detail!, error=None)	PASSED
	Contextual Relevancy	0.95 (threshold=0.5, evaluation model=gpt-4o, reason=The score is 0.95 because although the context is rich with detailed data on Suez Canal cargo traffic, it lacks specific information on the Panama Canal’s cargo traffic, necessitating additional data for a complete comparison., error=None)	PASSED
	Faithfulness	1.0 (threshold=0.5, evaluation model=gpt-4o, reason=Awesome job! The score is 1.00 because there are no contradictions present, showcasing perfect alignment and faithfulness of the actual output to the retrieval context. Keep up the excellent work!, error=None)	PASSED

Ocena modeli Retrieval-Augmented Generation (RAG) wymaga ustrukturyzowanego podejścia, które zapewnia zarówno precyzję wyszukiwania, jak i wiarygodność odpowiedzi. LLM-as-a-Judge stanowi efektywną alternatywę dla oceny ludzkiej, umożliwiając systematyczną analizę wyników na podstawie wcześniej zdefiniowanych kryteriów, co przekłada się na skalowalność i redukcję kosztów walidacji.

Korzystając z DeepEval, przetestowaliśmy naszego asystenta AI SeaStat pod kątem kluczowych metryk, takich jak Correctness (G-Eval), Answer Relevancy, Contextual Precision, Contextual Recall, Contextual Relevancy oraz Faithfulness. Wyniki testów wykazały drobne rozbieżności w wartościach liczbowych, brak niektórych kontekstowych informacji oraz niewielkie niedokładności w precyzji wyszukiwania – informacje te są kluczowe dla dalszej optymalizacji modelu.

Te obserwacje podkreślają, że nawet wysokowydajne modele RAG wymagają rygorystycznej ewaluacji, aby zapewnić poprawność faktograficzną i uniknąć potencjalnie wprowadzających w błąd odpowiedzi. Automatyzacja tego procesu umożliwia ciągłe doskonalenie modeli, zapewniając, że asystenci AI dostarczają rzetelne i kontekstowo trafne informacje na dużą skalę.

Asystenci AI to technologia, która wkrótce stanie się nieodzownym narzędziem dla pracowników na wszystkich szczeblach organizacji – od kadry zarządzającej po specjalistów. Ich dynamiczny rozwój pozwala na błyskawiczne dostosowanie się do potrzeb biznesowych oraz zmieniających się oczekiwań użytkowników.

Stworzymy Twojego Asystenta AI

Jeśli szukasz firmy, która pomoże Ci wdrożyć rozwiązanie oparte na sztucznej inteligencji, skontaktuj się z nami. Chętnie omówimy Twój pomysł.

Napisz do nas

Artykuł Ocena dużych modeli językowych (LLM) z wykorzystaniem Retrieval-Augmented Generation (RAG) i DeepEval dla złożonych danych tabelarycznych pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

Sieci neuronowe w przeglądarce: Przewodnik na przykładzie customowej sieci YOLO do wykrywania twarzy

Martyna Mul — Thu, 10 Oct 2024 11:20:57 +0000

Wraz z rosnącym zapotrzebowaniem na aplikacje działające w czasie rzeczywistym, uruchamianie modeli głębokiego uczenia w przeglądarce staje się coraz bardziej dostępne i wydajne. W tym artykule pokażemy, jak zaimplementować wykrywanie obiektów bezpośrednio w przeglądarce, wykorzystując YOLO (You Only Look Once) oraz TensorFlow.js. Skoncentrujemy się na zastosowaniu wytrenowanego przez nas niestandardowego modelu YOLOv8 do wykrywania ludzkich twarzy. Na końcu tego przewodnika dowiesz się, jak skonfigurować i uruchomić model YOLO do wykrywania twarzy za pomocą TensorFlow.js, przetworzyć wyniki i zoptymalizować wydajność – wszystko to bez potrzeby korzystania z serwera czy przetwarzania po stronie backendu.

Dlaczego warto korzystać z sieci neuronowych w przeglądarce?

Uruchamianie sieci neuronowych w przeglądarce ma wiele zalet. Najważniejsze z nich to:

Niskie opóźnienia: Wszystko odbywa się po stronie klienta, co eliminuje opóźnienia wynikające z przesyłania danych na serwer i oczekiwania na odpowiedź.
Większa prywatność: Wrażliwe dane pozostają na urządzeniu użytkownika, co minimalizuje ryzyko ich naruszenia lub ujawnienia.
Możliwość użycia offline: Użytkownicy mogą korzystać z funkcji uczenia maszynowego nawet bez stałego połączenia z internetem.
Kompatybilność między platformami: Aplikacja działa na każdym urządzeniu z przeglądarką – niezależnie czy to komputer, tablet, czy smartfon.

Wybór i przygotowanie sieci neuronowej

Przy wyborze sieci neuronowej do implementacji w przeglądarce warto uwzględnić takie czynniki jak rozmiar modelu, szybkość działania, zużycie pamięci oraz kompatybilność z technologiami przeglądarkowymi, np. WebGL. Dla optymalnej wydajności na urządzeniach o ograniczonych zasobach zaleca się stosowanie modeli o rozmiarze poniżej 30 MB. Do odpowiednich modeli należą MobileNetV2, SqueezeNet, EfficientNet oraz wybrane warianty YOLO. My zdecydowaliśmy się na wytrenowany przez nas model YOLOv8 do wykrywania ludzkich twarzy na obrazach.

Jeśli Twój model przekracza zalecany rozmiar, warto rozważyć techniki optymalizacji, takie jak kwantyzacja (quantization) i przycinanie (pruning). Kwantyzacja zmniejsza precyzję wag modelu, zazwyczaj konwertując wartości zmiennoprzecinkowe 32-bitowe na liczby zmiennoprzecinkowe 16-bitowe lub całkowite 8-bitowe. Przycinanie usuwa zbędne połączenia w sieci neuronowej. Obie metody zmniejszają rozmiar modelu i redukują złożoność obliczeniową, co poprawia szybkość inferencji – szczególnie na urządzeniach takich jak smartfony – choć mogą one nieznacznie wpłynąć na dokładność.

Optymalizacja YOLOv8 do wykrywania twarzy: wyniki naszego niestandardowego modelu

Nasz model YOLOv8 został wytrenowany na niestandardowym zbiorze danych w celu automatycznego sprawdzania, czy załącznik zawiera wyraźne zdjęcie ludzkiej twarzy, skierowanej na wprost i niezasłoniętej, np. przez maskę. Taka funkcjonalność jest szczególnie przydatna w systemach obiegu dokumentów, gdzie weryfikacja tożsamości wymaga widoczności twarzy. Zbiór danych składał się z 1500 obrazów, z czego 1200 wykorzystano do treningu, a 300 do walidacji. Dataset zawierał zdjęcia twarzy fotografowanych z różnych kątów, twarzy częściowo zasłoniętych oraz zdjęcia innych obiektów. Dzięki treningowi model nauczył się skutecznie wykrywać twarze spełniające wymagane kryteria. Poniższe przykłady ilustrują, jak model działa w praktyce. Dwie twarze po lewej stronie zostały poprawnie wykryte, podczas gdy dwie po prawej nie zostały rozpoznane, ponieważ były częściowo zasłonięte:

(source of images: https://www.kaggle.com/datasets/ashwingupta3012/human-faces, https://www.kaggle.com/datasets/andrewmvd/face-mask-detection)

Wyniki wnioskowania na czterech przykładach – dwie twarze po lewej stronie zostały poprawnie wykryte, natomiast dwie po prawej nie, ponieważ były częściowo zasłonięte.

Jako bazowy model dla naszego projektu wybraliśmy YOLOv8s (small), co dało model o rozmiarze 44 MB, osiągający 99,9% precyzji (ang. precision) oraz 99,1% czułości (ang. recall) na naszym niestandardowym zbiorze danych walidacyjnych. W celu optymalizacji przetestowaliśmy również mniejszy model bazowy, YOLOv8n (nano), oraz przeanalizowaliśmy efekty kwantyzacji. Trening z modelem YOLOv8n dał model o rozmiarze zaledwie 12 MB, przy niemal identycznych wynikach – 99,7% precyzji i 99,1% czułości. Następnie przeprowadziliśmy kwantyzację obu modeli, a ich rozmiary oraz dokładność po kwantyzacji zostały zaprezentowane w poniższej tabeli:

	Model bazowy			Model kwantyzowany 16-bitowy
	Rozmiar	Precyzja	Recall	Rozmiar	Precyzja	Recall
YOLOv8 small	44 MB	0.999	0.991	22 MB	0.997	0.991
YOLOv8 nano	12 MB	0.997	0.991	6 MB	0.989	0.991

Uwaga: Czułość mierzy, ile rzeczywistych pozytywnych próbek zostało poprawnie zidentyfikowanych (tutaj: ile twarzy zostało poprawnie wykrytych), natomiast precyzja wskazuje, ile próbek zidentyfikowanych przez model jako pozytywne było faktycznie pozytywnych (tutaj: ile obiektów wykrytych przez model to faktycznie ludzkie twarze). W idealnym przypadku oba wskaźniki wynoszą 1.

W naszym przykładzie, zastosowanie mniejszego modelu bazowego wraz z kwantyzacją zmniejszyło dokładność o mniej niż 1%, jednocześnie redukując rozmiar modelu z 44 MB do zaledwie 6 MB.

Poniżej przedstawiamy kilka przykładowych zdjęć, które pokazują, jak działają dwa modele: YOLOv8s i YOLOv8n z kwantyzacją.

Wyniki inferencji z modelem YOLOv8s, bez kwantyzacji (o rozmiarze 44 MB):

(source of images: https://www.kaggle.com/datasets/ashwingupta3012/human-faces).

Wyniki inferencji z modelem YOLOv8n po kwantyzacji 16-bitowej (o rozmiarze 6 MB). Różnica w poziomie ufności jest minimalna, natomiast położenie wykrytych obiektów pozostało takie samo.

Przetestowaliśmy wydajność dwóch modeli — YOLOv8s (44 MB) i YOLOv8n po kwantyzacji 16-bitowej (6 MB) — na trzech różnych procesorach. Mniejszy model, YOLOv8n, konsekwentnie przewyższał swój większy odpowiednik pod względem czasu wczytania modelu oraz szybkości pojedynczej inferencji. Szczegółowe dane dotyczące wydajności zostały podsumowane w tabeli poniżej.

	Ładowanie modelu			Pojedyncze wnioskowanie
	CPU 1	CPU 2	CPU 3	CPU 1	CPU 2	CPU 3
YOLOv8 small	1050 ms	3700 ms	4200 ms	21 ms	117.5 ms	196.5 ms
YOLOv8 nano 16-bit	980 ms	3200 ms	3700 ms	16 ms	112.5 ms	189 ms
Przyspieszenie	6.7 %	13.5 %	11.9 %	23.8 %	4.2 %	3.8 %

Oprócz czasu wczytania modelu i inferencji, istotnym czynnikiem do rozważenia jest również czas pobrania modelu, który nie został uwzględniony w tabeli. Czas ten jest bezpośrednio proporcjonalny do rozmiaru modelu i w znacznym stopniu zależy od prędkości połączenia internetowego użytkownika.

Praktyczna implementacja krok po kroku

Aby wdrożyć model uczenia maszynowego w przeglądarce, skorzystamy z TensorFlow.js — popularnej biblioteki, która umożliwia uruchamianie wytrenowanych modeli lub całkowite trenowanie nowych modeli bezpośrednio w przeglądarce. W tym przewodniku skupimy się na wdrożeniu wytrenowanego modelu YOLOv8 do wykrywania twarzy. Poniżej znajdziesz instrukcję, jak krok po kroku skonfigurować środowisko i uruchomić model z TensorFlow.js.

1. Instalacja TensorFlow.js

Najłatwiejszą metodą instalacji Tensorflow.js jest użycie npm:

npm install @tensorflow/tfjs

2. Wczytanie modelu

Ponieważ używamy biblioteki TensorFlow.js, musisz przekonwertować swój model na format TensorFlow.js (Tf.js). W przypadku modeli YOLO, twórcy Ultralytics udostępnili łatwy sposób na dokonanie tego za pomocą prostego polecenia:

yolo export model=path/to/best.pt format=tfjs

Po konwersji Twój model zostanie zapisany jako pliki binarne wraz z plikiem JSON o nazwie model.json. Wówczas możesz wczytać model korzystając z funkcji tf.loadGraphModel(). Poniżej znajdziesz przykład implementacji. Zwróć uwagę na dodatkowy etap „rozgrzewki” modelu, poprzez wykonanie jednokrotnej inferencji na losowych danych wejściowych. Ten krok poprawi wydajność modelu przy kolejnej inferencji.

export async function loadModel(modelPath) { 
  try { 
    // Load the model using a URL 
    const model = await tf.loadGraphModel(`${modelPath}/model.json`); 
    // Warm up the model 
    const dummyInput = tf.ones(model.inputs[0].shape); 
    await model.execute(dummyInput); 
    return model; 
  } catch (error) { 
    throw new Error(`Failed to load model: ${error.message}`); 
  } 
}

3. Przygotowanie danych wejściowych

Przed uruchomieniem modelu musimy odpowiednio przygotować obraz wejściowy. Modele YOLO oczekują obrazów o określonym rozmiarze, takim samym jaki został użyty podczas treningu sieci. Zamiast jednak zmieniać rozmiar obrazu (np. funkcją resize()), zalecamy bardziej zaawansowaną metodę przetwarzania obrazu, która zachowuje proporcje i stosuje wypełnienie (letterbox padding). Takie podejście jest zgodne z przetwarzaniem stosowanym przez Ultralytics podczas trenowania modelu YOLO i zapewni najlepszą skuteczność.

Poniższa funkcja skaluje obraz tak, aby największy jego wymiar zgadzał się z tym oczekiwanym przez model, dodaje wypełnienie aby dopasować drugi wymiar obrazu (jeżeli trzeba) i normalizuje obraz wejściowy:

function preprocessImage(base64Image, imgSize) { 
  const image = new Image(); 
  image.src = base64Image; 
  const canvas = document.createElement('canvas'); 
  canvas.width = image.width; 
  canvas.height = image.height; 
  const ctx = canvas.getContext('2d'); 
  ctx.drawImage(image, 0, 0, image.width, image.height); 
 
  // Convert canvas image to a tensor 
  let imgTensor = tf.browser.fromPixels(canvas); 
 
  // Determine rescale factor 
  const xFactor = image.width / imgSize; 
  const yFactor = image.height / imgSize; 
  const factor = Math.max(xFactor, yFactor); 
  const newWidth = Math.round(image.width / factor); 
  const newHeight = Math.round(image.height / factor); 
 
  // Resize to expected input shape  
  imgTensor = tf.image.resizeBilinear(imgTensor, [newHeight, newWidth]); 
 
  // Add padding 
  const xPad = (imgSize - newWidth) / 2; 
  const yPad = (imgSize - newHeight) / 2; 
  const top = Math.floor(yPad); 
  const bottom = Math.ceil(yPad); 
  const left = Math.floor(xPad); 
  const right = Math.ceil(xPad); 
  imgTensor = tf.pad(imgTensor, [[top, bottom], [left, right], [0, 0]], 114); 
 
  // Normalize pixel values 
  imgTensor = imgTensor.div(255.0).expandDims(0); // Add batch dimension 
  return { imgTensor, left, top, factor }; 
 
}

4. Uruchom inferencję modelu

Po załadowaniu modelu i przetworzeniu danych wejściowych, wykonanie inferencji odbywa się za pomocą tej linii kodu:

const prediction = await model.execute(inputTensor);

5. Przetwarzanie wyników modelu

Wynik sieci YOLO to tensor, który należy odpowiednio zinterpretować. Poniżej znajdują się kroki w naszej funkcji postprocessInferenceResults(), które pozwalają na wyodrębnienie współrzędnych wszystkich wykrytych obiektów:

const results = prediction.transpose([0, 2, 1]);  
const numClass = 1; // Only one class in our case 
const boxes = tf.tidy(() => { 
const w = results.slice([0, 0, 2], [-1, -1, 1]); // Get width 
const h = results.slice([0, 0, 3], [-1, -1, 1]); // Get height 
const x1 = tf.sub(results.slice([0, 0, 0], [-1, -1, 1]), tf.div(w, 2)); // Get x1 

const y1 = tf.sub(results.slice([0, 0, 1], [-1, -1, 1]), tf.div(h, 2)); // Get y1 
return tf.concat([y1, x1, y1.add(h), x1.add(w)], 2).squeeze(); 
});

Aby wyodrębnić klasy i poziomy ufności dla każdego obiektu:

const numClass = labels.length; 
const [scores, classes] = tf.tidy(() => { 
const rawData = results.slice([0, 0, 4], [-1, -1, numClass]).squeeze(0); 
  return [rawData.max(1), rawData.argMax(1)]; 
});

Następnie należy pozbyć się wyników z poziomem ufności poniżej ustalonego progu (u nas był to 0.4):

const array = await scores.array(); 
const highConfidenceIndices = array.reduce((acc, value, index) => { 
  if (value > 0.4) acc.push(index); 
  return acc; 
}, []); 
 
const highConfidenceBoxes = boxes.gather(highConfidenceIndices); 
const highConfidenceScores = scores.gather(highConfidenceIndices); 
const highConfidenceClasses = classes.gather(highConfidenceIndices);

Na koniec zastosuj Non-Max Suppression (NMS), aby odfiltrować duplikaty, tzn. wykryte obiekty, które się na siebie nakładają:

const nms = await tf.image.nonMaxSuppressionAsync(highConfidenceBoxes, highConfidenceScores, 40, 0.45, 0.4); // NMS to filter boxes 
 
const boxesData = highConfidenceBoxes.gather(nms, 0); // Indexing boxes by NMS index 
const scoresData = highConfidenceScores.gather(nms, 0).dataSync(); // Indexing scores by 
const classesData = highConfidenceClasses.gather(nms, 0).dataSync(); // Indexing classes by NMS index

Ostatnim krokiem jest przeskalowanie współrzędnych, aby dopasować je do kształtu oryginalnego obrazu:

// Precompute the margins and factors outside the stack 
const yMarginTensor = tf.scalar(yMargin); 
const xMarginTensor = tf.scalar(xMargin); 
const resizeFactorTensor = tf.scalar(resizeFactor); 
// Slice the boxesData and apply transformations in one step 
 
const [yCoordinates, xCoordinates, height, width] =  
  ['0', '1', '2', '3'].map((index) =>  
    boxesData.slice([0, parseInt(index)], [-1, 1]).sub(index % 2 === 0 ? yMarginTensor : xMarginTensor).mul(resizeFactorTensor) 
); 
 
// Stack the tensors without converting to arrays (unless needed) 
const bbox = tf.stack([yCoordinates, xCoordinates, height, width], 1); 
 
// Convert to an array only if absolutely necessary 
const bboxArray = bbox.arraySync();

Na końcu możemy zdefiniować funkcję runInference(), która zawiera cały opisany powyżej proces wykrywania obiektów. Ta funkcja zawiera przygotowanie obrazu, uruchomienie inferencji modelu oraz przetworzenie wyników. Oto jak wygląda:

export async function runInference(model, labels, image, confidenceThreshold = 0.4) { 
  try { 
    // Preprocess the image 
    const imgSize = model.inputs[0].shape[1]; 
    const { imgTensor: inputTensor, left: xMargin, top: yMargin, factor: resizeFactor } = preprocessImage(image, imgSize); 
 
    // Run inference 
    const prediction = await model.execute(inputTensor); 
 
    // Post-process the model output 
    const [boxes, scores, classes] = await postprocessInferenceResults(prediction, labels, xMargin, yMargin, resizeFactor, confidenceThreshold); 
    return [boxes, scores, classes]; 
 
  } catch (error) { 
    throw new Error(`Inference failed: ${error.message}`); 
  } 
}

6. Wizualizacja wyników

Na samym końcu, gdy mamy już gotowe wyniki detekcji, możemy narysować wykryte obiekty na obrazie:

function drawBoxesOnCanvas(ctx, boxes, classes, scores, colors) { 
  boxes.forEach((box, i) => { 
    const [x1, y1, x2, y2] = box; 
    ctx.strokeStyle = colors[classes[i]]; 
    ctx.lineWidth = 2; 
    ctx.strokeRect(x1, y1, x2 - x1, y2 - y1); 
    ctx.fillStyle = colors[classes[i]]; 
    ctx.fillText(`${labels[classes[i]]} (${Math.round(scores[i] * 100)}%)`, x1, y1); 
  }); 
}

Podsumowując, uruchamianie modelu YOLO do wykrywania obiektów bezpośrednio w przeglądarce przy użyciu TensorFlow.js otwiera nowe możliwości dla aplikacji real-time. W tym wpisie przedstawiliśmy wszystkie kroki, od konfiguracji TensorFlow.js, przez ładowanie modeli, przetwarzanie obrazów, uruchamianie wnioskowania, aż po wizualizację wyników, wraz ze wskazówkami jak zrobić to efektywnie. W miarę dalszego zgłębiania tej ciekawej technologii, warto eksperymentować z różnymi modelami, technikami optymalizacji oraz przypadkami użycia, aby w pełni wykorzystać potencjał uczenia maszynowego w aplikacjach internetowych.

Zapraszam do kontaktu, jeśli masz pytania lub chciałbyś podzielić się swoimi implementacjami!

Artykuł Sieci neuronowe w przeglądarce: Przewodnik na przykładzie customowej sieci YOLO do wykrywania twarzy pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.