RadLab — Blog

Zmrożone kopalnie kryptowalut?

2026-01-01T00:00:00Z

Dzisiaj nieco z innej „bajki”. Nie technicznie od strony wytwórczej, a być może propozycja częściowego rozwiązania problemu z mediów do czego można jeszcze wykorzystać „zamrożone” kopalnie kryptowalut 😉 np. LINK. Biorąc pod uwagę zapotrzebowanie na moce obliczeniowe potrzebne do uczenia modeli nie każda karta będzie odpowiednia do tego celu (potrzebne są karty z bardzo dużą ilością vRAM). W tym wpisie pokażemy jak zmienić nośnik USB w gotowe środowisko obliczeniowe, do którego podepniemy LLM Router jako warstwę komunikacyjną z modelami generatywnymi.

Jeżeli posiadasz już gotowe środowisko do kopania kryptowalut, śmiało możesz pominąć krok Instalacji HiveOS. Jeśli nie, to przejście przez ten krok pomaga w przygotowaniu systemu. W opisie wykorzystany został USB jako nośnik systemu, ponieważ HiveOS domyślnie instalowany jest na USB.

Intro

Jak zatem llm-router może pomóc w rozwiązaniu tego problemu? Propozycja jest w sumie dość oczywista i prosta, wykorzystanie zasobów kopalni kryptowalut, jako providera do świadczenia usług inferencji modeli generatywnych. Czyli, jeżeli posiadasz już gotową infrastrukturę, ten wpis pokaże Ci jak wykorzystać ją do uruchamiania modeli generatywnych. Dzięki temu będziesz miał działającą lokalnie usługę uruchamiania modeli takich jak gpt-oss czy gemma. A co z tym fantem można zrobić? Np. świadczyć płatną usługę do obliczeń (inferencji) właśnie na tych modelach.

Instalacja HiveOS

Pierwszym krokiem jest zainstalowanie gotowego systemu ze skonfigurowanymi sterowanikami do kart graficznych. Przykładowo może to być HiveOS (samo Ubuntu-desktop też nie jest najgorszym rozwiązaniem, jeśli nie chcemy przejmować się instalacją bibliotek do obsługi sterowników GPU). Proces instalacji przedstawiony jest dokładnie na oficjalnej stronie https://hiveon.com/install – aktualnie dostępna wersja oparta jest o Ubuntu 22.04.

Wybieramy oczywiście GPU (lub beta z nowymi sterownikami dla odważnych ;-)) i instalujemy zgodnie z How to Write Image. W przykładzie wykorzystaliśmy instalację na USB za pomocą wbudowanego w Ubuntu narzędzia do nagrywania obrazów (można również skorzystać z balenaEtcher).

Po instalacji domyślny użytkownik to user a hasło to 1. Oczywiście dobrym zwyczajem jest zmiana domyślnego hasła na bardziej skomplikowane (po zalogowaniu na maszynę z GPUpasswd).

Konfiguracja OS

Pomijamy tutaj proces konfiguracji serwera z kartami jako RIG do obliczeń w HiveOS (wydobywania kryptowalut i monitorowania procesu w interfejsie HiveOS’a). Wykorzystujemy fakt już skonfigurowanego systemu, do którego doinstalujemy kilka podstawowych bibliotek systemowych, które wymagane będą do uruchomienia lokalnie swojej isntancji LLM Routera w konfiguracji z modelem dostępnym przez Ollamę. Lokalny provider jest oczywiście dowolny: Ollama, vLLM, llama.cpp – bez znaczenia, LLM Router jest interfejsem, który komunikuje się z dowolnym protokołem lokalnego providera modeli. Po zalogowaniu się na maszynę z postawionym HiveOS: ssh user@IP.LOKALNE.MASZYNY dostaniemy informację odnośnie załadowanych driverów i dostępnych kart graficznych:

W naszym przypadku dostępne są trzy karty RTX 3090, każda po 24GB VRAM. Dokładne informacje odnośnie limitów, temperatury itp. można podejrzeć komendą nvidia-info (dla kart Nvidii):

Teraz wystarczy doinstalować podstawowe pakiety pip (do instalacji zależności) oraz git (do klonowania repozytorium):

# Instalacja w systemie (jeżeli nie ma) git + pip
apt install git python3-pip -y

Właściwie te dwa dodatkowe pakiety wystarczą aby system operacyjny był już skonfigurowany do uruchomienia LLM Routera.

Instalacja LLM Routera

W przykładzie pokazujemy w jaki sposób uruchomić natywnie (nie z obrazu dockerowego) najnowszą wersję LLM Routera z głównej gałęzi main.

# Klonowanie rpozytorium llm-router
git clone https://github.com/radlab-dev-group/llm-router

# Instalacja zależności oraz API
cd llm-router/
pip install -r requirements.txt
pip install .[api]

I tyle, w skrócie: pobranie, instalacja, uruchomienie w 3 komendach :). Teraz wydając komendę: ./run-rest-api-gunicorn.sh wystawiamy gotowe API za pomocą Gunicorna, jeszcze bez podpiętych modeli, ale już z działająca usługa sieciową (REST Api):

Zobacz log z uruchomienia [KLIK]+

root@HiveOS:/home/user/llm-router# ./run-rest-api-gunicorn.sh
2026-01-01 17:59:14,058 INFO main: Starting LLM‑Router API with gunicorn
2026-01-01 17:59:14,065 DEBUG llm_router_api.core.lb.provider_strategy_facade: [provider-monitor] keys to check: []
2026-01-01 17:59:14,072 INFO llm_router_api.core.lb.provider_strategy_facade: [Load balancing] Strategy FirstAvailableStrategy
2026-01-01 17:59:14,072 DEBUG llm_router_api.core.monitor.services_monitor: [services-monitor] thread started
2026-01-01 17:59:14,077 DEBUG llm_router_api.register.auto_loader: Instantiating OpenAICompletionHandlerWOApi
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating AnswerBasedOnTheContext
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating OpenAICompletionHandler
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating OpenAIModelsV1Handler
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating ApiVersion
2026-01-01 17:59:14,078 INFO llm_router_api.endpoints.endpoint_i: -> Running LLM-Router version: 0.4.4
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating OpenAIResponsesV1Handler
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating Ping
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating OpenAIResponsesHandler
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating ConversationWithModel
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating FullArticleFromTexts
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating ExtendedConversationWithModel
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating GenerateNewsFromTextHandler
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating TranslateTexts
2026-01-01 17:59:14,078 DEBUG llm_router_api.register.auto_loader: Instantiating SimplifyTexts
2026-01-01 17:59:14,079 DEBUG llm_router_api.register.auto_loader: Instantiating OllamaTagsHandler
2026-01-01 17:59:14,079 DEBUG llm_router_api.register.auto_loader: Instantiating GenerateQuestionsFromTexts
2026-01-01 17:59:14,079 DEBUG llm_router_api.register.auto_loader: Instantiating LLMStudioChatV0Handler
2026-01-01 17:59:14,079 DEBUG llm_router_api.register.auto_loader: Instantiating OllamaHomeHandler
2026-01-01 17:59:14,079 DEBUG llm_router_api.register.auto_loader: Instantiating FastTextMasking
2026-01-01 17:59:14,079 DEBUG llm_router_api.register.auto_loader: Instantiating VllmChatCompletion
2026-01-01 17:59:14,079 DEBUG llm_router_api.register.auto_loader: Instantiating LmStudioModelsHandler
2026-01-01 17:59:14,079 DEBUG llm_router_api.register.auto_loader: Instantiating OpenAIModelsHandler
2026-01-01 17:59:14,079 DEBUG llm_router_api.register.auto_loader: Instantiating OllamaChatHandler
2026-01-01 17:59:14,079 INFO llm_router_api.register.register: Registered endpoint POST /chat/completions (OpenAICompletionHandlerWOApi)
2026-01-01 17:59:14,079 INFO llm_router_api.register.register: Registered endpoint POST /api/generative_answer (AnswerBasedOnTheContext)
2026-01-01 17:59:14,080 INFO llm_router_api.register.register: Registered endpoint POST /api/chat/completions (OpenAICompletionHandler)
2026-01-01 17:59:14,080 INFO llm_router_api.register.register: Registered endpoint GET /v1/models (OpenAIModelsV1Handler)
2026-01-01 17:59:14,080 INFO llm_router_api.register.register: Registered endpoint GET /api/version (ApiVersion)
2026-01-01 17:59:14,080 INFO llm_router_api.register.register: Registered endpoint POST /v1/responses (OpenAIResponsesV1Handler)
2026-01-01 17:59:14,080 INFO llm_router_api.register.register: Registered endpoint GET /api/ping (Ping)
2026-01-01 17:59:14,081 INFO llm_router_api.register.register: Registered endpoint POST /responses (OpenAIResponsesHandler)
2026-01-01 17:59:14,081 INFO llm_router_api.register.register: Registered endpoint POST /api/conversation_with_model (ConversationWithModel)
2026-01-01 17:59:14,081 INFO llm_router_api.register.register: Registered endpoint POST /api/create_full_article_from_texts (FullArticleFromTexts)
2026-01-01 17:59:14,081 INFO llm_router_api.register.register: Registered endpoint POST /api/extended_conversation_with_model (ExtendedConversationWithModel)
2026-01-01 17:59:14,081 INFO llm_router_api.register.register: Registered endpoint POST /api/generate_article_from_text (GenerateNewsFromTextHandler)
2026-01-01 17:59:14,081 INFO llm_router_api.register.register: Registered endpoint POST /api/translate (TranslateTexts)
2026-01-01 17:59:14,082 INFO llm_router_api.register.register: Registered endpoint POST /api/simplify_text (SimplifyTexts)
2026-01-01 17:59:14,082 INFO llm_router_api.register.register: Registered endpoint GET /api/tags (OllamaTagsHandler)
2026-01-01 17:59:14,082 INFO llm_router_api.register.register: Registered endpoint POST /api/generate_questions (GenerateQuestionsFromTexts)
2026-01-01 17:59:14,082 INFO llm_router_api.register.register: Registered endpoint POST /api/v0/chat/completions (LLMStudioChatV0Handler)
2026-01-01 17:59:14,082 INFO llm_router_api.register.register: Registered endpoint GET / (OllamaHomeHandler)
2026-01-01 17:59:14,082 INFO llm_router_api.register.register: Registered endpoint POST /api/fast_text_mask (FastTextMasking)
2026-01-01 17:59:14,083 INFO llm_router_api.register.register: Registered endpoint POST /v1/chat/completions (VllmChatCompletion)
2026-01-01 17:59:14,083 INFO llm_router_api.register.register: Registered endpoint GET /api/v0/models (LmStudioModelsHandler)
2026-01-01 17:59:14,083 INFO llm_router_api.register.register: Registered endpoint GET /models (OpenAIModelsHandler)
2026-01-01 17:59:14,083 INFO llm_router_api.register.register: Registered endpoint POST /api/chat (OllamaChatHandler)
2026-01-01 17:59:14,083 INFO llm_router_api.core.metrics: [Prometheus] preparing metrics request hooks
2026-01-01 17:59:14,083 INFO llm_router_api.core.metrics: [Prometheus] registering metrics request hooks
[2026-01-01 17:59:14 +0000] [147288] [INFO] Starting gunicorn 23.0.0
[2026-01-01 17:59:14 +0000] [147288] [INFO] Listening at: http://0.0.0.0:8080 (147288)
[2026-01-01 17:59:14 +0000] [147288] [INFO] Using worker: gthread
[2026-01-01 17:59:14 +0000] [147296] [INFO] Booting worker with pid: 147296
[2026-01-01 17:59:14 +0000] [147297] [INFO] Booting worker with pid: 147297
[2026-01-01 17:59:14 +0000] [147298] [INFO] Booting worker with pid: 147298
[2026-01-01 17:59:14 +0000] [147299] [INFO] Booting worker with pid: 147299
2026-01-01 17:59:19,066 DEBUG llm_router_api.core.lb.provider_strategy_facade: [provider-monitor] keys to check: []

Log zawiera informacje z trybu DEBUG, więc jest ich całkiem sporo. Jest to domyślny poziom logowania, który dowolnie może być zmieniony.

Przykładowa konfiguracja: Ollama + gpt-oss:120b

Teraz zajmiemy się instalacją Ollamy z udostępnieniem modelu o wielkości 120b parametrów (gpt-oss:120b). Model jest na dyle duży, że wymaga 3 kart RTX z 24GB VRAM każda. Ollama potrafi bardzo dobrze uruchomić ten model na 3 kartach, zachowując przy tym niemalże pełną obsługę długości kontekstu. Zamykamy uruchomioną instancję LLM Routera (CTRL+C) i instalujemy Ollamę – instacja jest banalna, wystarczy w konsoli wywołać oficjalny skrypt instalacyjny:

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

Po chwili (zależy jakie łącze internetowe) Ollama jest gotowa i należy załadować na nią model lokalny. Dokładny opis jak zrobić to lokalnie znajduje się na stronie karty modelu: https://ollama.com/library/gpt-oss. Wystarczy:

ollama run gpt-oss:120b

Po pobraniu, model od razu dostępny jest w lokalnej instancji Ollamy.

OPCJA: Jeżeli model jest już pobrany i dostępny w ramach sieci, można podłączyć model z dysku sieciowego zamiast pobierać na pendrive. Przykład jak na 3 kartach uruchomić model dostępny w ramach sieci (np. po nfs) z katalogu /mnt/data2/llms/models/ollama/.ollama/models/:

CUDA_VISIBLE_DEVICES=0,1,2 \
  OLLAMA_NOPRUNE=true \
  OLLAMA_CONTEXT_LENGTH=128000 \
  OLLAMA_MODELS=/mnt/data2/llms/models/ollama/.ollama/models/ \
  OLLAMA_HOST=0.0.0.0 \
  ollama serve

Aby sprawdzić jakie modele dostępne są w Ollamie wystarczy polecenie ollama list. Przykładowo u nas (z podmontowanego dysku sieciowego):

root@HiveOS:/home/user/llm-router# ollama list
NAME                           ID              SIZE      MODIFIED
dolphin-mistral:latest         5dc8c5a2be65    4.1 GB    5 days ago
dolphin3:8b                    d5ab9ae8e1f2    4.9 GB    6 days ago
devstral-2:latest              524a6607f0f5    74 GB     6 days ago
devstral-2:123b                524a6607f0f5    74 GB     6 days ago
deepseek-r1:70b                d37b54d01a76    42 GB     4 weeks ago
gemini-3-pro-preview:latest    91a1db042ba1    -         4 weeks ago
gpt-oss:120b-ctx32k-rope       c265a9f5b5de    65 GB     7 weeks ago
gpt-oss:120b-ctx250k           964592b444fd    65 GB     7 weeks ago
glm-4.6:cloud                  05277b76269f    -         8 weeks ago
qwen3-coder:30b                06c1097efce0    18 GB     2 months ago
qwen3:235b                     72840bddff91    142 GB    3 months ago
gpt-oss:120b                   f7f8e2f8f4e0    65 GB     4 months ago
gpt-oss:20b                    aa4295ac10c3    13 GB     4 months ago

Konfiguracja LLM Routera do obsługi gpt-oss:120b

Ok, to posiadamy już system, mamy pobrany router oraz załadowany model do Ollamy. Teraz pora podpiąć model do routera. Wcześniejsze polecenia uruchamiają model na tej samej maszynie, na której uruchomiony jest llm-router. Aby uprościć demonstrację udostępniliśmy również plik konfiguracyjny, który wystarczy podpiąć do uruchamianego routera (nadpisać domyślny plik konfiguracyjny):

Można albo zmodyfikować w skrypcie uruchomieniowym run-rest-api-gunicorn.sh domyślną ścieżkę do konfigu (zmienna LLM_ROUTER_MODELS_CONFIG )
lub prościej: do procesu routera przekazać przy uruchamianiu ścieżkę do gotowej konfiguracji. Czyli wydać po prostu komednę:

LLM_ROUTER_MODELS_CONFIG=resources/configs/specific/models-config-local-ollama.json ./run-rest-api-gunicorn.sh

I właściwie, to tyle 🙂 Można już odpytywać router podając nazwę modelu. Przykład w curlu i formatowaniem do jsona za pomocą jq:

curl -X POST http://localhost:8080/v1/chat/completions -H "Content-Type: application/json" -d '{"model": "gpt-oss:120b", "messages": [{"role": "user", "content": "Cześć"}]}' | jq

co powinno dać wynik zbliżony do:

Outro

Te kilka opisanych kroków wystarczy na uruchomienie na sprzęcie oraz systemie typowo do wydobywania kryptowalut LLM Routera wykorzystującego te zasoby. Oczywiście to jest tylko przykład, na repozytorium podaliśmy więcej przykładów modeli i łączenia do różnych lokalnych providerów.

Górnicy, to druga szansa! 🙂

Dobrego w nowym roku! Dbajcie o dane i nie wysyłajcie do chmury danych wrażliwych!

Czy można w prosty sposób wprowadzić bazę wiedzy dla GenAI?

2025-12-27T00:00:00Z

Jak najbardziej, wystarczy langchain_rag podpięty do llm-routera 😉

Intro

Witajcie! Dzisiaj pokazujemy dodatkowe możliwości LLM Routera w postaci pluginów, a właściwie to jednego pluginu langchain_rag. Jest to wtyczka, która tworzy lokalną bazę wiedzy z przekazanych w procesie indeksacji treści. Wykorzystuje znane rozwiązania jak langchain do tworzenia systemu ragowego oraz fais jako wektorowa baza wiedzy. Następnie utworzoną bazę wiedzy można podpiąć do dowolnego zapytania w LLM routerze, bez modyfikacji aplikacji, która aktualnie wykorzystuje modele generatywne. Co daje takie podejście?

Możliwość automatycznego wzbogacenia kontekstu przekazywanego do modelu generatywnego – czyli standardowe podejście RAG. Wystarczy zaindeksować wybrane przez siebie dokumenty za pomocą dostępnej komendy CLI llm-router-rag-langchain index [OPTIONS] i wszystkie te treści dostępne są dla modelu generatywnego podczas generowania odpowiedzi.

Co to daje?

Możliwość automatycznego wzbogacenia kontekstu przekazywanego do modelu generatywnego – czyli standardowe podejście

RAG

. Wystarczy zaindeksować wybrane przez siebie dokumenty za pomocą dostępnej komendy CLI

llm-router-rag-langchain index [OPTIONS]

i wszystkie te treści dostępne są dla modelu generatywnego podczas generowania odpowiedzi.

— Możliwość automatycznego wzbogacenia kontekstu przekazywanego do modelu generatywnego – czyli standardowe podejścieRAG. Wystarczy zaindeksować wybrane przez siebie dokumenty za pomocą dostępnej komendy CLIllm-router-rag-langchain index [OPTIONS]i wszystkie te treści dostępne są dla modelu generatywnego podczas generowania odpowiedzi.

Indeksacja

Indeksacja danych to krok, w którym z zadanego katalogu, pliki z zadanymi rozszerzeniami zapisywane są w lokalnej bazie wiedzy. Plugin bazy wiedzy wykorzystuje załadowany model embeddera (domyślnie skonfigurowany jest google/embeddinggemma-300m) którym tworzy wektorowe reprezentacje pochunkowanych tekstów i zapisuje je do lokalnie utworzonej bazy wektorowej FAISS. To użytkownik wybiera jakie dokumenty chce wykorzystać do wzbogacania kontekstu oraz w jakich kolekcjach mają się znaleźć. Jest to o tyle istotny krok, ponieważ to od zawartości tej bazy zależny trafność odpowiedzi modelu generatnywnego. Pomimo istotności proces jest bardzo prosty. Po instalacji llm-routera dostępna jest komenda do obsługi bazy wiedzy tej wtyczki: llm-router-rag-langchain. Komenda instaluje się w CLI więc dostępna jest z poziomu dowolnego katalogu routera. W poruszanym dzisiaj przykładzie jako baza wiedzy wykorzystaliśmy wszystkie opisy ze wszystkich repozytorium i pod-repozytoriów LLM Routera:

Główne repozytorium llm-routera : pliki md i txt ;
Repozytorium z pluginami (również z opisywanym pluginem) – pliki w formacie md , txt ;
Serwisy z obsługą pluginów typu guardrails i maskers – md i txt ;
Repozytorium z przykładowymi narzędziami wykorzystującymi llm-router – pliki md oraz txt ;
Dedykowane interfejsy graficzne dla Anonimizatora i Configs Managera – również pliki md i txt ;
Strona internetowa llm-router.cloud – pliki html , md oraz txt ;

Dla uproszczenia sprawy dodaliśmy prosty skrypt bashowym, w którym wystarczy zmienić typy plików oraz ścieżki do indeksacji i bez modyfikacji pozostałych ustawień z głównego katalogu routera wydać polecenie [tutaj pełen skrypt]:

bash scripts/llm-router-rag-langchain-index.sh

Dzięki temu w domyślnie ustawionym katalogu: workdir/plugins/utils/rag/langchain/sample_collection/ zapisana będzie lokalna baza wiedzy, którą następnie można podpiąć jako baza wiedzy llm-routerze.

Uruchomienie bazy wiedzy w LLM Routerze

Baza wiedzy wczytywana jest domyślnie z katalogu, w którym uruchomiony jest LLM Router, jednak miejsce zapisu/wczytania może być dowolnie ustawione zmienną systemową LLM_ROUTER_LANGCHAIN_RAG_PERSIST_DIR. Aby LLM Router obsługiwał utworzoną bazę wiedzy, należy aktywować plugin langchain_rag oraz ustawić ścieżkę do utworzonej bazy wiedzy. Po uruchomieniu routera z taką konfiguracją, każde zapytanie do modelu generatywnego będzie wzbogacane o kontekst pochodzący z podpiętej bazy wiedzy. Aktywacja wtyczki to po prostu wyeksportowanie zmiennej środowiskowej z pluginami typu utils przy starcie routera (domyślny skrypt umożliwia modyfikacje):

export LLM_ROUTER_UTILS_PLUGINS_PIPELINE="langchain_rag"

I to właściwie tyle, jeżeli nie modyfikujemy parametrów jak wielkość kontekstu, embedder, to nic nie trzeba zmieniać i ustawiać – tylko indeksować własne dane 🙂 A jak to wygląda w praktyce. Poniżej na zdjęciu odpowiedź modelu bez podpiętej wtyczki langchain_rag z zaindeksowanymi treściami:

Oraz odpowiedź z podpiętą wtyczką:

Outro

A na zakończenie jeszcze filmik z konsoli, jak zaindeksować wspomniane treści:

oraz przełączanie routera do działania w trybie bazy wiedzy (początek filmu, to działanie routera bez bazy wiedzy, druga część filmu, to działanie z podpiętą bazą wiedzy):

W roli głównej: OpenWeb UI z podpiętym LLM-Routerem (z wyłączoną i włączoną wtyczką langchain_rag).

Zachęcamy do pobierania, sprawdzania oraz dzielenia się swoimi odczuciami z wykorzystywania 🙂

Zobacz powiązane produkty: Wzbogacanie kontekstu w oparciu o bazę wiedzy jest natywnie wspierane przez ekosystem wtyczek bramy LLM Router. Sprawdź także demonstrację działania na żywo w RDL Playground AI.

Czy prawa natury można złamać?

2025-12-15T00:00:00Z

Nie wiem, choć się domyślam […]

Witajcie! Dzisiaj przybywamy po dwóch miesiącach intensywnej pracy nad upublicznieniem LLM Routera. Tutaj wcześniejszy wpis: klik. Z małego projektu wyszedł spory moloch, w którego rozwój nie tylko deweloperski zaangażowały się nowe osoby. Oprócz Michała i Bartka, pojawili się Krzysiek i Maciek. Robi się niezły set skillsów… 😉

W dzisiejszym wpisie przedstawiamy w jaki sposób można skonfigurować LLM Router wykorzystując do tego celu dostępne modele na licencji Apache 2.0. Wielkie dzięki dla fundacji Speakleash, która w ramach swojej działalności udostępniła dwa modele, które idealnie nadają się do wykorzystania w routerze. W tym wpisie pokazujemy jak można podpiąć modele Bielik-11B-v2.3-Instruct oraz Bielik-Guard-0.1B-v1.0 aby współgrały w LLM Routerze. Pokazaliśmy przykład, jak 8 Bielików i 5 Sójek może ze sobą współpracować w wirtualnym ekosystemie 🙂

Bieliki i Sójki w jednym gnieździe

W naturze Orzeł Bielik, to samotny drapieżca, który na czas godów łączy się w pary. Nie dopuszcza do swojego terytorium obcego ptactwa. W kontekście Sójki jest prosta relacja: drapieżca – ofiara. Jednak… to „tylko” natura, a w świecie cyfrowym można więcej.

Metafora Ekosystemu natury

W świecie cyfrowym miano Bielika przejmuje model językowy Bielik-11B-v2.3-Instruct, ofiarą jest Sójka – Bielik-Guard-0.1B-v1.0 typu guardrail, a gniazdem LLM Router, który w swoim ekosystemie wprowadza ład i harmonię, a zależność drapieżca – ofiara przestaje istnieć. Wręcz przeciwnie, te gatunki zaczynają razem tworzyć liczne stada, a niechciana zwierzyna nie ma wstępu. W konglomeracie modeli Instruct i Guardrail wspomaganych technikami maskowania danych wrażliwych otrzymujemy idealne rozwiązanie do kontrolowanego wykorzystywania modeli językowych typu generatywnego. Lokalnie uruchomiony router umożliwia kontrolę treści wysyłanych do modeli generatywnych. Ofiara ze świata natury staje się obrońcą, model językowy komunikuje się z aplikacją, zaś mechanizmy maskowania w tle zamazują dane wrażliwe. Ten konglomerat, to właśnie opisywane dzisiaj rozwiązanie w LLM Routerze 😉

Kilka słów o LLM Routerze

Pełen opis LLM Routera znajduje się stronie domowej llm-router.cloud oraz w poprzednim wpisie na blogu.

LLM Router, to rozwiązanieon-prem, którego zadaniem jest kontrola i optymalizacja ruchu do modeli generatywnych. W odróżnieniu od większości routerów nie optymalizujemy tutaj kosztu odpytania api, a wręcz przeciwnie – mając do dyspozycji providerów (lokalnych i chmurowych) chcemy tak rozłożyć ruch, aby czas odpowiedzi był jak najmniejszy. W całym procesie następują jeszcze dodatkowe kroki, takie jak sprawdzanie wysyłanej treści pod względem etyki oraz danych wrażliwych. Poprawność etyczna wysyłanych treści kontrolowana jest poprzez mechanizmy typu Guardrails, w momencie wykrycia incydentu, rozmowa/wiadomość automatycznie jest blokowana, tworzony jest audyt, do modelu generatywnego nie jest wysyłana żadna treść, a aplikacja otrzymuje informację, że treść jest zablokowana i nie jest możliwa dalsza kontynuacja rozmowy. Zaś mechanizmy maskowania działają w tle i mają za zadanie zamaskowanie informacji wrażliwych przed wysłaniem do modelu generatywnego – ten mechanizm nie blokuje wiadomości, w locie podmienia ją na zamaskowaną, odkłada audyt o wykrytym incydencie i wysyła do modelu generatywnego zamaskowaną wiadomość. Całość konfigurowalna jest poprzez odpowiednie ustawienie uruchamianego routera.

Bieliki i Sójki w LLM Routerze

Aby wspomniany ekosystem mógł poprawnie działać, musimy odpowiednio przygotować to środowisko. Do tego celu potrzebujemy kilku elementów:

llm-router – główny ekosystem koordynowania ruchu (dokładny opis znajduje się na gitgubie i www );
llm-router-services – serwisy, w których uruchamiane są modele typu guardrails (przykład z Bielik-Guard );
model Bielik-11B-v2.3-Instruct – polski model generatywny;
model Bielik-Guard-0.1B-v1.0 – model typu guardrail działający na tekstach w języku polskim;

Następnie poszczególne elementy wystarczy poskładać w jednym miejscu – konfiguracji LLM Routera. Aby wpis nie był zbyt długi, wszystkie konfiguracje wrzuciliśmy na githuba: tutaj, tam też umieściliśmy kompletny opis wszystkich kroków. Jednak w skrócie:

Uruchomienie serwisu z Sójką (pięć Sójek jednocześnie pilnuje treści);
Uruchomienie Bielika na vLLM (8 providerów z tym samym modelem), na GPU cuda:0 , cuda:1 , cuda:2 ;
Konfiguracja i uruchomienie LLM Routera;

W podanym przykładzie uruchomiliśmy proces audytowania i blokowania treści niedozwolonych oraz audytowania i maskowania danych wrażliwych wbudowanym mechanizmem fast_masker (opis reguł maskujących oraz ich implementacje w pluginach routera).

Podgląd na ekosystem

Poniżej znajdują się screeny uruchomionego nvitopa na każdym z hostów oraz podgląd na konsolę API

Host Lab2 z odpalonymi trzema modelami Bielika (w vLLM)

Host Lab3 również trzema z odpalonymi modelami Bielika (vLLM)

Host Lab4 z dwoma modelami Bielik (vLLM)

Host z API routera (4 workery gunicorna, po 16 wątków) i pięcioma Sójkami (5 workerów gunicorna na cuda:0)

Tak skonfigurowane środowisko gotowe jest do przyjmowania dziesiątek zapytań 🙂 Dla testów wydajności przygotowaliśmy prostą aplikację, której zadaniem jest przetłumaczenie zadanego tekstu na język polski. Do tego wykorzystaliśmy wbudowany endpoint z llm-routera /api/translate a zbiór do tłumaczenia, to marmikpandya/mental-health dostępny na huggingface. Do przeprowadzenia testu wykorzystaliśmy aplikację run-text-translator.sh z repozytorium z utilsami, po instalacji biblioteki dostępna jest komenda w CLI translate-texts:

Zobacz: translate-texts –help

$ translate-texts --help
usage: translate-texts [-h] --llm-router-host LLM_ROUTER_HOST --model MODEL --dataset-path DATASET_PATH [--dataset-type {json,jsonl}] [--accept-field ACCEPT_FIELD] [--num-workers NUM_WORKERS] [--batch-size BATCH_SIZE]

options:
  -h, --help            show this help message and exit
  --llm-router-host LLM_ROUTER_HOST
                        Base URL of the LLM router service (e.g., http://localhost:port)
  --model MODEL         Model name to use for translation (e.g., speakleash/Bielik-11B-v2.3-Instruct)
  --dataset-path DATASET_PATH
                        Path to a dataset file. This option can be provided multiple times to process several files.
  --dataset-type {json,jsonl}
                        Explicit type of dataset files (json or jsonl). If omitted, the type is inferred from each file's extension.
  --accept-field ACCEPT_FIELD
                        Name of a field to retain from each record. Can be supplied multiple times; if omitted all fields are kept.
  --num-workers NUM_WORKERS
                        Number of worker threads for parallel translation (default: 1 – runs sequentially).
  --batch-size BATCH_SIZE
                        How many texts to send in a single request to the router (default: 8).

Na filmiku poniżej pokazaliśmy działanie routera w połączeniu we wspomnianymi wcześniej modelami. Na początku (pierwsze 3 sekundy), to widok na maszynę API (w górnej części) z llm-routera, dolna lewa część to uruchomiony serwis z Sójkami, zaś prawa dola część to podgląd nvitopem na kraty graficzne. Sekundy 3-6 to podgląd na maszynę Lab4 z dwoma Bielikami (z lewej strony uruchomione vLLMy, z prawej podgląd na utylizację kart graficznych). Kolejne sekundy 6-10 to podgląd na maszynę Lab3 z trzema Bielikami. Sekundy 11-13 to podobny podgląd na obciążenie maszyny Lab2 (trzy Bieliki). Kolejne sekundy, to przełączanie między maszynami, zaś końcówka to podgląd na API.

Podczas pracy, mechanizm maskowania i wykrywania treści niedozwolonych wyłapał przypadki, które zamaskował, zablokował oraz zaudytował do pliku (w logach pojawiają się wpisy [AUDIT]************. Audytowana treść zapisywana jest w wydzielonym katalogu (innym niż logi główne) i szyfrowana jest kluczem publicznym GPG. Całość możliwa jest do odkodowania tylko poprzez prywatny klucz. Na poniższym filmiku pokazujemy w jaki sposób przechowywane są logi (pliki z rozszerzeniem .audit) oraz jak odkodować je z wykorzystaniem dostępnego w repozytorium llm-routera skryptu do deszyfracji scripts/decrypt_auditor_logs.sh. A oto efekt wykonania komendy

$ bash scripts/decrypt_auditor_logs.sh

z ustawionym dodatkowo hasłem na klucz deszyfrujący:

Outro

W ten oto sposób w wirtualnym świecie zastał porządek. Sójki pilnują treści wysyłanych do modeli generatywnych, Bieliki generują treść, mechanizmy maskowania ukrywają treści wrażliwe a audytorzy na bieżąco monitorują całość pod względem bezpieczeństwa.

Oczywiście zachęcamy do pobierania i testowania rozwiązania! Wszystko dostępne na Apache 2.0. Dobrego maskowania! 😉

Llm-Router – łącznik między aplikacją, a modelami generatywnymi

2025-10-23T00:00:00Z

Tym razem przybywamy z projektem, który wykorzystujemy od jakiegoś czasu wewnętrznie. Jednak ze względu na dość dużą uniwersalność rozwiązania — może komuś się przydać — a nawet zachęcamy do korzystania i zgłaszania problemów 🙂

W dalszej części krótko opiszemy zawartość repozytorium, sposób uruchomienia gotowego obrazu (tak, wystarczy pobrać i uruchomić :)) oraz przykład konfiguracji. W README na githubie opisaliśmy projekt od strony technicznej, tutaj skupiamy się bardziej na wykorzystaniu.

Na githubie udostępniliśmy publicznie projekt llm-router. To rozwiązanie, które działa jak router w świecie sieciowym z tą różnicą, że routing w llm-router jest między użytkownikiem, a modelami generatywnymi. Tak jak router dostaje wiadomość, obsługuje ją, wie gdzie ją skierować dalej i odsyła do użytkownika odpowiedź, tak nasz llm-router otrzymuje zapytanie od użytkownika z informacją o modelu z jakiego chce skorzystać, i już llm-router odpowiednio przekierowuje zapytanie do modelu (zna ich lokalizacje), obsługuje wynik modelu i zwraca odpowiedź do użytkownika. Innymi słowy – użytkownik nie martwi się gdzie jakiś model jest uruchomiony, a jedynie musi znać nazwę modelu i skierować zapytanie do llm-routera.

Eksplozja supernowej

Do czego można wykorzystać llm-router? To rozwiązanie dostępne poprzez API RESTowe, które obsługuje ruch między aplikacją a modelem generatywnym. Robi to w taki sposób, że użytkownik/aplikacja nie musi znać lokalizacji modelu, parametrów połączenia, a tym bardziej nie przechowuje kluczy prywatnych do zewnętrznych serwisów z modelami generatywnymi (openai, google), bo cała logika obsługi modelu jest po stronie llm-routera. Wystarczy wpiąć do niego listę zewnętrznych modeli, a już router zadba o odpowiednie przekierowywanie. I tutaj nie ma znaczenia czy model jest lokalnie uruchomiony np. za pomocą VLLM, LMStudio czy Ollamy, czy też jest dostępny publicznie w chmurze.

Aktualnie obsługiwane są wszystkie API, które implementują standard Ollama lub OpenAI, a mało tego router potrafi przekierować ruch między różnymi standardami (również strumieniowanie). Nawet jeżeli do tej pory użytkownik korzystał z Ollamy nadal może pozostać przy tym standardzie i bez modyfikacji kodu aplikacji, ale za pomocą llm-routera może wysłać zapytanie do API np. VLLM co daje duże uproszczenie w produkcyjnym uruchamianiu modeli.

Dodatkowo, predefiniowane endpointy (klik), które dowolnie można rozbudowywać i dodawać nowe, znacznie upraszczają proces wytwarzania oprogramowania. Ta sama funkcjonalność, która musiałaby być oprogramowana w aplikacji (i dostępna by była tylko w niej), teraz może być zaimplementowana po stronie llm-routera, jako centralnym węźle dostępowym. Upraszcza to wprowadzanie poprawek, nowych funkcjonalności i zarządzenie nimi. Dedykowane endpointy, można nazwać agentami realizującymi określone funkcjonalności.

Elastyczność konfiguracji, daje również możliwość nazywania modeli dowolnie, np. po stronie aplikacji model, do którego aplikacja wysyła zapytanie może się np. nazywać model_generatywny, a ta nazwa rozwiązywana jest do poprawnego modelu i hosta po stronie llm-routera (na nagraniu poniżej przykład jak to może wyglądać – aplikacja nie wie jaki model uruchamia).

Karton z klockami

A w kartonie w dwa kartony: jeden ze złożoną zabawką a drugi faktycznie z klockami. Zacznijmy od zabawki, czyli publicznie dostępnego obrazu na quay, który można pobrać i uruchomić bez budowania. Jedynie konfigurujemy modele, do których mamy dostęp/aktualnie wykorzystujemy. Proces pobrania i uruchomienia obrazu jest bardzo prosty, wystarczy posiadać zainstalowanego w systemie dockera i pobrać gotowy obraz z naszego repozytorium Quay. Do pobrania obrazu wystarczy:

docker run -p 5555:8080 quay.io/radlab/llm-router:rc1

a do aktualizacji do najnowszej wersji:

docker pull quay.io/radlab/llm-router:rc1

Po pobraniu, obraz sam się uruchomi i wystawi api llm-routera w najprostszej wersji z Flaskiem na porcie 5555 (-p 5555:8080 oznacza, że przekierowujemy port 8080 z wewnątrz dockera, na którym działa router, na port 5555 dostępny na zewnątrz dockera). Serwerem podstawowym jest Flask, dlatego przed wykorzystywaniem na większą skalę (szczególnie z opcją strumieniowania), zachęcamy do przeczytania możliwości konfiguracji zmiennymi środowiskowymi – i rozważenie uruchomienia z gunicornem z ustaloną liczba workerów, log-levelem itp. Aby uruchomić llm-router z własnych konfigiem, wystarczy podmontować go do obrazu i podmienić domyślny, który znajduje się w obrazie pod ścieżką /srv/llm-router/resources/configs/models-config.json. Czyli przekazujemy parametr -v do dockera:

-v sciezka/do/lokalnego/pliku/models.json:/srv/llm-router/resources/configs/models-config.json

Teraz klocki… instrukcja dostępna w README (oraz opis po polsku z przykładowym zaawansowany endpointem, który samemu można dodać do llm-routera), dlatego tutaj nie będziemy tego powtarzać, jednak to co jest kluczowe, to sposób budowy pliku konfiguracyjnego. Poniżej w „Coś dla oka” zamieściliśmy przykładowy plik json, z konfiguracją do trzech modeli:

google/vllm – to model google/gemma-3-12b-it uruchomiony w sieci lokalnej ( http://192.168.100.79:7000/ ), uruchomiony za pomocą VLLMa;
google/chmura – to tak na prawdę model gemini-2.5-flash-lite dostępny przez api chmurowe googla: https://generativelanguage.googleapis.com/v1beta/openai/ do którego posiadamy klucz PUT YOUR API KEY HERE ;
openai/model – to model gpt-oss:120b dostępny w lokalnej sieci na hoście http://192.168.100.66:11434 uruchomiony za pomocą Ollamy;

Coś dla oka

Filmik poniżej zawiera kilka ekranów: lewy górny róg, to podgląd na VLLMa z google/gemma3-12b-it, dolny lewy róg, to Ollama z modelem gpt-oss:120b, dolny prawy róg – konsola z uruchomionym llm-routerem, zaś prawy górny róg to wtyczka AI Assistant do Pycharma. Domślnie wtyczka umożliwia podpięcie się do jednego providera modeli, zaś wpięcie llm-routera pozwala wstrzyknąć dowolny standard, nawet ten nieobsługiwany przez aplikację. Dodatkowo na filmiku pokazaliśmy jak można zmienić nazwy modeli, aby od strony aplikacji nie było wiadomo jaki model jest pod spodem. Zaś w konsoli na dole widać jak llm-router przyjmuje zapytania i kieruje do odpowiedniego hosta:

Konfiguracja użyta do uruchomienia llm-routera:

{
  "google_models": {
    "google/vllm": {
      "api_host": "http://192.168.100.79:7000/",
      "api_token": "",
      "api_type": "vllm",
      "input_size": 4096,
      "model_path": "google/gemma-3-12b-it"
    },
    "google/chmura": {
      "api_host": "https://generativelanguage.googleapis.com/v1beta/openai/",
      "api_token": "PUT YOUR API KEY HERE",
      "api_type": "openai",
      "input_size": 512000,
      "model_path": "gemini-2.5-flash-lite"
    }
  },
  "openai_models": {
    "openai/model": {
      "api_host": "http://192.168.100.66:11434",
      "api_token": "",
      "api_type": "ollama",
      "input_size": 256000,
      "model_path": "gpt-oss:120b"
    }
  },
  "active_models": {
    "google_models": [
      "google/vllm",
      "google/chmura"
    ],
    "openai_models": [
      "openai/model"
    ]
  }
}

I pełen skrypt z uruchomieniem dockera (to co uruchamiane jest w terminalu na filmie — czyli pełna konfiguracja i zmiana wszystkich domyślnych parametrów :)):

#!/bin/bash

PWD=$(pwd)

docker run \
  -p 5555:8080 \
  -e LLM_ROUTER_TIMEOUT=500 \
  -e LLM_ROUTER_IN_DEBUG=1 \
  -e LLM_ROUTER_MINIMUM=1 \
  -e LLM_ROUTER_EP_PREFIX="/api" \
  -e LLM_ROUTER_SERVER_TYPE=gunicorn \
  -e LLM_ROUTER_SERVER_PORT=8080 \
  -e LLM_ROUTER_SERVER_WORKERS_COUNT=4 \
  -e LLM_ROUTER_DEFAULT_EP_LANGUAGE="pl" \
  -e LLM_ROUTER_LOG_FILENAME="llm-proxy-rest.log" \
  -e LLM_ROUTER_EXTERNAL_TIMEOUT=300 \
  -e LLM_ROUTER_MODELS_CONFIG=/srv/cfg.json \
  -e LLM_ROUTER_PROMPTS_DIR="/srv/prompts" \
  -v "${PWD}/resources/configs/models-config-names.json":/srv/cfg.json \
  -v "${PWD}/resources/prompts":/srv/prompts \
  quay.io/radlab/llm-router:rc1

Logout

Jednym z miejsc, gdzie llm-router działa jest nasz playground. Każda funkcjonalność dotycząca modelu generatywnego oprogramowana jest jako dedykowany EP w llm-router. Kody udostępniamy oczywiście na licencji Apache 2.0 — można brać i wykorzystywać komercyjnie i niekomercyjnie — smacznego!

Zachęcamy do korzystania i zgłaszania swoich sugestii i uwag.

Aktualizacja (Wydanie v1.1+): Zapowiadane funkcjonalności (6 zaawansowanych strategii Load Balancingu, Redis Rate Limiting w przesuwnym oknie czasowym, metryki Prometheus oraz potok wtyczek maskowania PII i guardraili NASK/Sójka) zostały w pełni wdrożone! Zobacz pełną specyfikację LLM Routera.

Upubliczniamy kody

2025-09-27T00:00:00Z

Witajcie! Dzisiaj technicznie. Ostatni miesiąc pracowaliśmy nad publikacją części naszych rozwiązań. Dzisiaj chcielibyśmy przedstawić kilka z nich. Część, to działające mechanizmy na playgroundzie, a inne, to realizowane pomysły „z boku”. Wróciliśmy do pomysłu rozwijania rozwiązań całkowicie publicznie na Githubie. Dlatego zapraszamy na nasz profil githubowy, który krótko w tym wpisie przedstawiamy 😉

Poniżej przedstawiamy projekty z krótkimi opisami. Każdy z nich na Githubie posiada dość obszerny plik README.

relgat-projector („z boku”)

Repozytorium (klik) zawiera autorską implementację mechanizmów link-prediction na podstawie grafów semantycznych. Ideą było odtworzenie relacji semantycznych oraz możliwość tworzenia nowych reprezentacji bazując na istniejących. Zakładamy, że w grafie węzły posiadają opis semantyczny (np. za pomocą embeddingu), krawędzie nie posiadają opisu, jednak są rozróżnialne między sobą. Labelka krawędzi w takim grafie oznacza nazwę relacji.

Metoda umożliwia uczenie się macierzy przekształceń dla krawędzi w grafie, bazując na otoczeniu węzłów. Model jednocześnie uczy się przekształceń każdej relacji z osobna oraz uczy się definiować węzły na podstawie istniejących w grafie. Węzeł definiowany jest poprzez jego otoczenie (wejście), zakładamy, że to, co wchodzi do danego węzła, definiuje go. W odróżnieniu od standardowego RelGATa, nie uczymy się całej sieci — uczymy się przekształceń bazowej przestrzeni, do tej samej przestrzeni w taki sposób, że dla [A -> rel1 -> B], [C -> rel2 -> B] szukamy przekształceń rel1 i rel2 tak, aby kombinacja embeddingów A i C dały embedding B. Stosując dodatkowo ocenę przez metryki typu hits@X jako funkcje straty, dodatkowo uczymy się predykcji linków. Dzięki temu, możliwe będzie przetransformowanie dowolnego wektora X(z uczonej przestrzeni) za pomocą macierzy przekształceń M (np. aktywując określone relacje), w taki sposób, aby dostać wektorX'w tej samej przestrzeni, jednak po przekształceniu relacjami.

Przeprowadziliśmy już serię eksperymentów (na wykresach ostatnie stabilne treningi) i jak na razie (po wykresach) wygląda to obiecująco 😉

plwordnet („z boku”)

To repozytorium (klik), za pomocą którego można operować na polskiej i angielskiej Słowosieci (Słowosieć – polski, Princeton Wordnet – angielski). Co prawda nie służy ono aktualnie tylko do przeglądania Słowosieci, ale przede wszystkim jest to mechanizm to tworzenia zbiorów danych. Zaimplementowana jest tam metoda tworzenia embeddingów dla węzłów grafów semantycznych. Zawarty jest tam pełen proces od pobrania Słowosieci, przygotowania danych do dalszych procesów, aż do: tworzenia

embeddera semantycznego,
reprezentacji embeddingowych dla znaczeń Słowosieci i Princeton Wordnetu z wykorzystaniem tego embeddera.

Na huggingface udostępniliśmy pierwszą wersję modelu (radlab/semantic-euro-bert-encoder-v1). To dwujęzyczny model embeddera, w którym jako model językowy wykorzystaliśmy EuroBERT. Tworzenie reprezentacji embeddingowych to kilkuetapowy proces. Na początku reprezentacje tworzone są dla jednostek leksykalnych. Następnie, dla tych jednostek, dla których nie można było utworzyć reprezentacji, ale znajdują się w synsecie, w którym są jakieś reprezentacje, tworzona jest sztuczna (fake) reprezentacja dla jednostki. Po czym dla każdego synsetu, który posiada choć jedną reprezentację jednostki, tworzone są reprezentacje embeddingowe jako ważone, uśrednienie embeddingów jednostek. Po takiej operacji, nie wszystkie jednostki i synsety posiadają definicje, dlatego relgat-projector ma posłużyć między innymi do transformacji węzła bez reprezentacji, jednak posiadającego jakieś otoczenie (synset lub jednostka).

ml-utils („z boku”)

Wcześniejsze biblioteki mają zależność do ml-utils. Jest to biblioteka, która upraszcza potok przetwarzania w kontekście uczenia maszynowego. Zawiera ogólne klasy i metody, które niezależne są od projektu, jednak ich funkcjonalność może być współdzielona do innych projektów. Za pomocą ml-utils można między innymi:

w prosty sposób zarządzać logowaniem wyników do Weights & Biases,
zarządzać promptami do modeli generatywnych, poprzez nazwy wynikające ze struktury katalogów,
obsługiwać dowolne api modelu generatywnego zgodne z OpenAPI, tworzyć kolejki oraz cache’ować odpowiedzi dla zmniejszenia liczby odpytań modelu.

Dodatkowo dostępne są moduły ogólnego przeznaczenia, takie jak parsowanie envów czy tworzenie ujednoliconych loggerów, ale znajduje się tam również moduł do pobierania danych z Wikipedii, który wykorzystywany jest w plwordnet do wzbogacenia kontekstu budowanych embeddingów.

Moduły z playgroundu

W repozytorium clusterer zamieściliśmy moduł odpowiadający za tworzenie klastrów na playgroundzie. Typy informacji, które widoczne są w Przeglądarce Informacji czy też w Eksploratorze informacji są tworzone właśnie za pomocą tego modułu. Dokładniejszy opis metody zamieściliśmy na blogu w podlinkowanych artykułach. Oprócz tego, udostępniliśmy kod do wizualizatora grafów, który aktualnie uruchomiony jest pod adresem https://graph.playground.radlab.dev/ gdzie prezentowane są grafy informacyjne ciągłe i nieciągłe. Oprócz tego, do kolekcji dołączyliśmy repozytorium radlab-playground-ui z kodem interfejsu Playgroundu, jako aplikacji w streamlicie.

Zakończenie

Wszystkie kody udostępniamy na otwartej licencji Apache 2.0, można dowolnie wykorzystywać – komercyjnie i niekomercyjnie. Koniec. 😉

Eksplorator Informacji – nie młotek, a skalpel

2025-07-17T00:00:00Z

Dziś na blogu będzie krótko, ale w załączniku już długaśnie 🙂

Intro i Outro

Zachęcamy zapoznać się od kuchni z działaniem Przeglądarki i Eksploratora Informacji 😉 Na tę okazję przygotowaliśmy raport techniczny z dokładnym opisem działania naszych rozwiązań. W raporcie przedstawiliśmy dokładne definicje informacji oraz jej rodzajów, czyli informacji dziennej, ciągłej i nieciągłej. Wprowadziliśmy definicje grafów informacyjnych dla informacji oraz przedstawiliśmy proces ich budowy, analizy i ekstrakcji z nich elementów, które tworzą przeglądarkę i eksploratora informacji. Dane, którymi zasilane są te metody, to oczywiście newsy ze Strumienia Aktualności. Uruchomiliśmy również publicznego githuba, na którym umieściliśmy zarówno pdfa jak i kody LaTeXowe raportu.

Kombo

Przechodząc do lektury, proponujemy czytać całość od początku do końca, nie gubiąc przy tym szczegółów. Raport pokazuje możliwości wyciągania z danych informacji zapisanych między wierszami. Oto podgląd pliku pdf:

Pobierz PDF

Eksplorator_Informacji-Raport-techniczny-v1.0-20250714

Pobierz

Zobacz powiązane produkty: Algorytmy grafowe i klastrowanie wiedzy są wdrożone w Radarze Informacji oraz module analitycznym na platformie RDL Playground AI.

Polaryzacja 3c – model z plg na HF

2025-06-01T00:00:00Z

Intro

Witajcie 😉 Dzisiaj przedstawiamy i upubliczniamy element działania playgroundu. Jest to model klasyfikacyjny, którego zadaniem jest określanie polaryzacji tekstów. Model upubliczniamy na naszym huggingface 😉 Polaryzacje określamy jako:

pozytywna — model przypisuje tę klasę, jeżeli informacje w tekstach mogą wzbudzić pozytywne emocje/odczucia;
negatywna — jeżeli informacje w tekstach wzbudzają pozytywne odczucia;
ambiwalentna/neutralna — jeżeli informacja jest obojętna lub wywołuje przeciwstawne odczucia w tym samym czasie;

Proces: dane i uczenie

Model powstawał w dwóch etapach. W odróżnieniu jednak od standardowego podejścia (start od anotacji), rozpoczęliśmy jednak od uczenia modelu na podstawie istniejących już anotacji (hm… to nic nowego przecież… i tak i nie…). Jednak szukając zbioru danych do polaryzacji, najczęściej są to zbiory dotyczące opinii na jakiś temat. W naszym przypadku nie chodzi o określenie polaryzacji opinii (np. Ten produkt można wyrzucić do kosza! lub Polecam lekarza bo ma bardzo dobre podejście do pacjenta!) a określenie polaryzacji informacji, którą wtłaczają w nas media (serwisy internetowe).

Zatem należało szukać w innym miejscu 😉 Wybór nie był aż tak oczywisty, ale oddający bardziej ideę polaryzacji informacji, niż opinii… i padło na Słowosieć Emo. Słowosieć Emo, to oznaczona za pomocą emocji (i nie tylko) wybrana część Słowosieci (oznaczenia są na poziomie znaczeń słów) — polecam zapoznać się czym jest Słowosieć — to bardzo cenne źródło informacji. Po kilku technicznych krokach, przekształcone przykłady użycia do znaczeń z opisem emocjonalnym, przekształciliśmy w przybliżony zbiór polaryzacji emocjonalnej (redukcja emocji i granulacji do 3 – pozytywna, negatywna, ambiwalentna). Poniżej na zdjęciu kilka przykładów ze zbioru, już po konwersji:

Ten zbiór wykorzystaliśmy do wyuczenia modelu polarity3c-zero, czyli modelu, który wykorzystany został od razu w procesie wspierania decyzji podczas anotacji. Model w czasie rzeczywistym proponował propozycje anotacji dla dwóch anotatorów. W ten sposób powstał zbiór około 3500 ręcznych anotacji, które wykorzystane były do finalnego uczenia modelu.

Finalny model, to prosta architektura, w której nad modelem językowym dodana jest prosta warstwa klasyfikacyjna (ClassificationHead), która wyuczana jest do określania polaryzacji. Architektura warstwy klasyfikacyjnej:

  (classifier): RobertaClassificationHead(
    (dense): Linear(in_features=1024, out_features=1024, bias=True)
    (dropout): Dropout(p=0.1, inplace=False)
    (out_proj): Linear(in_features=1024, out_features=3, bias=True)
  )

1024 na pierwszej gęstej warstwie Liniowej to wyjście modelu bazowego polish-roberta-large-v2, wyjście modelu polarity3c, to warstwa oznaczona (out_proj), która na wyjściu ma 3 cechy, czyli nasze wykrywane klasy. Na wykresach poniżej przedstawiamy podstawowe metryki z uczenia tego modelu:

Uruchomienie i testowanie

Najprościej uruchomić model za pomocą biblioteki transformers z wykorzystaniem pipeline’a.

from transformers import pipeline

classifier = pipeline(model="radlab/polarity-3c", task="text-classification")

Samo użycie modelu jest równie proste:

 classifier("Po upadku reżimu Asada w Syrii, mieszkańcy, borykający się z ubóstwem, zaczęli tłumnie poszukiwać skarbów, zachęceni legendami o zakopanych bogactwach i dostępnością wykrywaczy metali, które stały się popularnym towarem. Mimo, że działalność ta jest nielegalna, rząd przymyka oko, a sprzedawcy oferują urządzenia nawet dla dzieci. Poszukiwacze skupiają się na obszarach historycznych, wierząc w legendy o skarbach ukrytych przez starożytne cywilizacje i wojska osmańskie, choć eksperci ostrzegają przed fałszywymi monetami i kradzieżą artefaktów z muzeów.")

W odpowiedzi dostaniemy wartość

[{'label': 'ambivalent', 'score': 0.9994786381721497}]

Aby odczytać pełen rozkład pewności modelu, wystarczy dodać opcję ile labelek o najwyższym prawdopodobieństwie chcemy otrzymać. W naszym przypadku mamy 3 labelki, dlatego do classifier dodajemy opcje top_k=3 aby otrzymać informacje o wszystkich klasach:

 classifier("Po upadku reżimu Asada w Syrii, mieszkańcy, borykający się z ubóstwem, zaczęli tłumnie poszukiwać skarbów, zachęceni legendami o zakopanych bogactwach i dostępnością wykrywaczy metali, które stały się popularnym towarem. Mimo, że działalność ta jest nielegalna, rząd przymyka oko, a sprzedawcy oferują urządzenia nawet dla dzieci. Poszukiwacze skupiają się na obszarach historycznych, wierząc w legendy o skarbach ukrytych przez starożytne cywilizacje i wojska osmańskie, choć eksperci ostrzegają przed fałszywymi monetami i kradzieżą artefaktów z muzeów.", top_k=3)

A oto i wyjście:

[{'label': 'ambivalent', 'score': 0.9994786381721497},
 {'label': 'negative', 'score': 0.0002675618161447346},
 {'label': 'positive', 'score': 0.0002538080152589828}]

Outro

Model udostępniony jest od lipca ubiegłego roku na naszym playgroundzie. Zbieramy efekty jego działania, które można podejrzeć w statystykach. Na strumieniu przy każdym newsie, dodawana jest również informacja o polarzyacji, właśnie przez ten model. Model oczywiście za free na naszych HF: Klik do modelu.

Powiązane rozwiązania: Model ten stanowi integralną część analizy sentymentu w Radarze Informacji oraz strumienia wiadomości na platformie RDL Playground AI.

Przeglądarka informacji

2025-09-26T00:00:00Z

Z perspektywy marketingowej, dobrze byłoby zacząć ten wpis w stylu:

Dzisiaj przedstawiamy rewolucyjne, w pełni zautomatyzowane rozwiązanie, które w czasie „rzeczywistym” pozwoli Ci analizować trendy w mediach. Chcesz się dowiedzieć o czym się pisze? Co jest na topie? Tak! Dobrze trafiłeś, to właśnie dzisiaj masz okazję skorzystać….

Easy…. Takie trochę Telemango w dzisiejszych czasach… nie wypada tak 😉 Także zaczniemy standardowo.

O czym jest dzisiejszy wpis?

Na playgroundzie udostępniliśmy nową funkcjonalność, nazwaliśmy ją Przeglądarka Informacji i służy dokładnie do tego, jak się nazywa — czyli przeglądania informacji w czasie.

Czym jest informacja? Jako informację rozumiemy zwartą grupę tematyczną newsów ze stron internetowych, które w domyśle dotyczą tej samej sytuacji/tematu/zdarzenia… Tego, co pojawia się w wiadomościach, o czym piszą media, co jest na topie. To, co w danym dniu/przedziale czasowym jest tym, o czym się czyta, tylko zebrane w jednym miejscu, podsumowane i nazwane. Nazwa informacji nie jest w żadnym stopniu predefiniowana, jest wyznaczana na podstawie pojawiających się newsów powiązanych w zwarte grupy informacyjne. Nazwa informacji codziennie może być inna — zależy o czym się pisze (i czyta ;-)).

Podstawą działania Przeglądarki, są informacje występujące na popularnych serwisach newsowych, które cyklicznie analizujemy i wyniki tych analiz prezentujemy w piaskownicy. Przeglądarka prezentuje proces automatycznej analizy informacji z tych serwisów. Jest mechanizmem, który przedstawia najistotniejsze informacje z danego dnia, nazwie te informacje oraz napisze krótkie streszczenie, w którym można dowiedzieć się w skrócie czego dotyczy wykryta informacja. Oprócz tego, przedstawi szereg powiązanych (nazwijmy to) wyzwalaczy tej informacji:

poda dokładne adresy do stron internetowych, które o tej informacji piszą;
pokaże źródła propagacji informacji za pomocą diagramu z wizualizacją procentowego udział konkretnego portalu w udostępnianiu tej informacji;
przedstawi analizę polaryzacji tej informacji (warto zwrócić uwagę na korelację nazwy informacji z polaryzacją informacji);
za pomocą kalendarza umożliwi śledzenie i analizę informacji w czasie (aczkolwiek może być ona różnie nazwana);

Jak to działa?

Od strony technicznej, jest to mix różnych metod i optymalizacji. Mechanizm bada różnice między tekstami i na podstawie ich podobieństwa dobiera do jednej grupy informacyjnej te newsy, które z perspektywy zredukowanego embeddingu są do siebie najbardziej podobne. Mechanizm wydzielania skupisk informacyjnych dostraja swoje działanie do liczby danych, które analizuje. Są dni, w których pojawia się około 600 newsów, ale są również dni, kiedy pojawia się dwa razy więcej. Mechanizm na podstawie wielu rozkładów dobiera taki, który najlepiej wpasowuje się w dodatkowe warunki podziału danych, np. nie pozwala na podziały poniżej 5 grup informacyjnych oraz na powyżej 60, a dodatkowo uwzględnia złoty środek czyli celowanie w 20 tematów dziennie, a jednocześnie optymalizuje liczbę przykładów odrzucanych. Z perspektywy Przejrzanych dwóch miesięcy, najczęściej w mediach pojawia się od 20 do 30 informacji dziennie.

Dla kogo: od Sasa do lasa

Można powiedzieć: Od Sasa do lasa… Z perspektywy osoby poszukujących pewnych informacji, jest to rozwiązanie, które w jednym miejscu pozwala dotrzeć do dziesiątek czy setek newsów z konkretnego dnia z konkretną informacją. Jeżeli interesują kogoś wydarzenia sportowe, a danego dnia pojawiło się odpowiednio dużo informacji z wydarzeń sportowych, to dostanie podsumowanie wielu wydarzeń (w tym również z zagranicznych źródeł). Przykładowo propozycja numer 1 (domyślnie pojawia się numer 0) w dniu 26.05.2025 pojawia się informacja „Sport – sukcesy i zmiany.„, której podsumowanie wygląda tak (klik aby powiększyć):

A dodatkowo dostajemy adresy powiązanych stron z informacją z tym opisem:

Kliknij aby zobaczyć zdjęcie

Zaś z perspektywy analityka, powiązanie informacji odnośnie źródeł propagacji, czyli wykres:

pokazuje skąd ta informacja przychodzi i na ile zdominowana jest przez jedno źródło danych. I o ile w przypadku sportu, może to być mniej istotna zmienna, o tyle w informacjach związanych np. z polityką czy nowoczesnymi technologiami, rozkład pochodzenia stron może pokazywać proces wprowadzania informacji w obieg. Zaś analiza tej informacji w czasie za pomocą kalendarza, umożliwia śledzenie jej i umożliwia wyciąganie wniosków. Należy jedynie pamiętać, że informacje nazywane są indywidualnie w perspektywie jednego dnia, dlatego nazwy mogą się różnić w zależności od dnia. Dlatego (jeszcze) wymagana jest ludzka interakcja, aby śledzić konkretną informację w czasie 😉 Dodatkowo otrzymujemy podsumowanie na temat rozkładu polaryzacji emocji w postaci diagramu:

Przy analizie takiego diagramu warto zwrócić uwagę na korelację nazwy informacji z polaryzacją/wydźwiękiem tekstu (informacja pozytywna, negatywna, neutralna). Nazwa kategorii bardzo wskazuje jaki może być rozkład polaryzacji. A za wykrycie polaryzacji odpowiada nasz model, który na playgroundzie działa od bardzo dawna i służy do oceny tekstów w czasie rzeczywistym. Właśnie na podstawie decyzji tego modelu przedstawiony jest udział konkretnego wydźwięku w konkretnej informacji (nie jest to wydźwięk artykułu podsumowującego, a newsów z informacją). Oprócz tego dostajemy dokładne dane dotyczące informacji odnośnie liczby newsów:

A powiązanie liczby newsów w informacji z liczbą newsów w całym dniu (a do tej zmiennej jest dostęp):

pozwala określić istotność informacji w kontekście całego dnia…. Resztę można zostawić wyobraźni 😉

Outro

Dlaczego tylko jeden dzień? Nie ma problemu, mechanizm działa w oparciu o przedziały czasowe, analizuje informacje ze wskazanego przedziału, nie na wskazany dzień. Sam mechanizm jest uniwersalny i do analiz ponadtygodniowych wymaga już nieco mocniejszego sprzętu (i o dziwo jest to RAM i procesor, nie gpu :)), analiza około tysiąca newsów z dnia trwa od 15 do 28 minut, więc nie tak długo. Aktualnie analizujemy dni aż do 01.01.2025, po tym procesie można będzie prześledzić informacje od 01.01.2025 do dnia, w którym będzie się śledziło 😉 Mechanizm działa w oparciu o zautomatyzowane jednodniowe analizy, dlatego codziennie pojawia się podsumowanie informacji z dnia wcześniejszego. Po analizie jednodniowej planujemy wprowadzić właśnie analizy tygodniowe.

Zachęcamy do Przeglądania Informacji, analizowania i wyciągania wniosków. Przeglądarka jest oczywiście w całości non-profit, bez reklam i logowania się 😉

Content Supervisor o Przeglądarce [klik]

Podsumowanie tego wpisu za pomocą content supervisora z Czatu Publicznego 😉 Oto, co gemma napisała o Przeglądarce:

Rozmowa do przeczytania na Czacie Publicznym, wystarczy załadować hash:

text 7ivUpPCTNPR0d8gGbPT9hh5nD1Y8yMapJSOISOTg7mFJvryf3BgzGdT03Bsf0Ui3gWymAkciIWRxPJnHslFwnP0FtYzrSi8xj7AOqxT5lcqQ1waaYadNUIOoOJAqu9wP

Sprawdź powiązane rozwiązania: Zobacz pełny 8-etapowy potok przetwarzania i architekturę w opisie Radar Informacji oraz przetestuj wersję demonstracyjną na żywo w RDL Playground AI.

pLLama3.1 8B — czyli średnio-duże a nawet małe GenAI dla Polskiego

2024-12-08T00:00:00Z

pLLama – wygenerowane za pomocą AI

Ostatnio napisaliśmy:

Tak… celowe było błędne zapisanie nie-ko-po-le-i (to nie błąd) jako zapowiedź nie-kolejnej wersji modelu 🙂 między pLlamą3 oraz pLlamą3.2 była też wersja pLLamy3.1 — i to o niej dzisiejszy wpis.

Intro

Kolejna wersja modelu od Mety mówiąca lepiej po polsku! W tym wpisie przedstawiamy model pLLama3.1 w architekturze 8B. Tym razem opublikowaliśmy model -content, który jest mniej gadatliwą wersją modelu, model -chat jako bardziej rozgadana jego wersja, czysty model -base po LoRze, ale również udostępniliśmy eksperymentalny model z transferem warstw adaptacyjnych modelu pLLama3 do modelu pLLama3.1 (o tym niebawem kolejny wpis:)). Wszystkie modele dostępne oczywiście na huggingface (pełna kolekcja modeli 3.1):

Model radlab/pLLama3.1-8B-content : to model po SFT i DPO udziela krótkich i zwięzłych odpowiedzi.
Model radlab/pLLama3.1-8B-chat to bardziej gadatliwa wersja modelu (po SFT i DPO), idealnie nadaje się do rozmowy na czacie.
Model radlab/pLLama3.1-8B-base-ft-16bit to model bezpośrednio po SFT z LoRa.
Eksperymentalny model radlab/pLLama-L31-adapters-MIX-SFT-DPO z transferem warstw adaptacyjnych między modelami.

Dataset, uczenie i wykresy

Wszystkie wersje modeli pLLamy3.1 mają jednego rodzica, mianowicie Llama-3.1-8B-Instruct od Meta.AI w architekturze 8B. Ten model już całkiem dobrze pisze w swojej podstawowej wersji po polsku, jednak dużo brakuje do (przynajmniej) poprawnego pisania. Stąd pomysł: douczmy i ten model 🙂

Do uczenia wykorzystaliśmy zbiór danych opracowany do wcześniejszych modeli. Krótko przypominając jest to ponad 650k instrukcji wygenerowanych automatycznie na podstawie dostępnych zbiorów danych. Każdy zbiór (np. oznaczony częściami mowy), przekształcaliśmy do postaci promtów systemowych na zasadzie pytania i odpowiedzi. W ten sposób powstał zbiór instrukcji, które wykorzystaliśmy jako dane do douczenia modelu. Do DPO również opracowaliśmy zestaw instrukcji na podstawie dostępnych korpusów językowych między innymi NKJP i KPWr.

Ze względu na ograniczenia sprzętowe SFT robiliśmy z wykorzystaniem warstw adaptacyjnych (LoRA) z kwantyzacją liczb do 16 bitów (bits and bytes). Podobnie w DPO, model bazowy ładowany był jako kwantyzowana wersja pLLamy3.1 po SFT i w trakcie DPO douczana również była warstwa adaptacyjna. Dla przypomnienia, w naszym przypadku podczas SFT przekrzywiamy wagi modelu w stronę języka polskiego, zaś w procesie DPO uczymy model poprawnego generowania tekstu — pod względem gramatycznym i interpunkcyjnym. Modele trenowaliśmy na pojedynczych kartach graficznych RTX 4090 (24 GB). SFT (LoRA) trwało 14d 2h 3m 52s. Zaś DPO 2d 15h 2m 42s. Różnica między modelem -content a -chat to kwestia innego sposobu łączenia warstwy adaptacyjnej z modelem (ale o tym będzie osobny wpis). Poniżej dwa wykresy, pierwszy z nich to wartość funkcji straty w SFT, drugi to wartości logitów chosen i rejected podczas DPO.

Funkcja straty podczas SFT z Lorą

I proces DPO:

Outro

Czym różni się model w wersji 3.1 od modelu pLLama3? Przede wszystkim wielkością kontekstu. Model pLLama3 miał ograniczony kontekst do 8k tokenów. Wersja pLLamy3.1 to kontekst o długości 128k tokenów (to wynika z modelu bazowego, czyli w pLLamie 3 douczaliśmy Llamę3 od Mety, zaś w pLLamie3.1 model LLama3.1 od mety). W testach w RAGu pLLama3.1 działa zdecydowanie lepiej od wersji 3 przede wszystkim ze względu na większy kontekst. W tej chwili podczas odpowiadania na pytanie model jest w stanie pomieścić dużo więcej informacji, co mocno zmniejsza częstotliwość jego odpytywania, redukuje mocno problem ze zbyt częstym odpytywaniem modelu, dzieleniem danych do wielkości wejścia (przy okazji redukuje problem składania odpowiedzi końcowej w RAG na podstawie cząstkowych odpowiedzi przy małym kontekście).

A jako dodatek na HF model, który nazwaliśmy L31 (pLLama-L31-adapters-MIX-SFT-DPO) jako pewien eksperyment przy mixowaniu modeli.

Tyle na dziś, dzięki!

pLlama3.2 (1B + 3B) – małe GenAI dla polskiego

2024-10-20T00:00:00Z

pLLama – wygenerowane za pomocą AI

Intro

Cześć Wam!

Dziś bardzo krótki wpis. Wpis o modelu, niewielkim jak na te czasy. Pewnie słyszeliście o LLamie3.2 od MetaAI? Meta udostępniła ostatnio modele do generowania treści (Instruct) ale i obrazów (Vision-Instruct).

Niestety modele Vision-Instruct nie są dostępne w Unii Europejskiej no i przy okazji w naszym kraju.

Zatem…. co nam zostało? Zostało nam douczyć małe modele tekstowe w architekturze 1B oraz 3B na nasz język 😉

Dane i Trening

Do douczania zastosowaliśmy najpierw technikę fine-tuningu, a następnie w procesie DPO trenowaliśmy oba modele na korekcję języka. Dane dokładnie te same, co w przypadku pLLamy3 (Kliknij aby przeczytać artykuł) .Zarówno do fine-tuningu, jak i DPO. Jedynie mała zmiana w hiperparametrach uczenia (batch size, learning rate). Liczba epok w FT to 5, liczba kroków w DPO 50k. A… no i uczenie na 16 bitach 🙂

Zobaczcie sami na wykres funkcji straty zarówno na części treningowej i ewaluacyjnej (to sam proces fine-tuningu na język polski):

I dokładnie taka między nimi jest różnica 🙂

Odczucia

Jako, że modele 1B oraz 3B to destylacja modeli już istniejących zapewne oceniana w większości na danych anglojęzycznych, ciekawy był efekt całego procesu douczania tych modeli. Model w architekturze 1B (zarówno po FT ale i po DPO) to chyba najmniej sprawny model z całej naszej kolekcji — ale statystyki mety pokazują dokładnie to samo. Zaś model w architekturze 3B, to zupełnie inna liga niż 1B. Można powiedzieć, że działa zgodnie z oczekiwaniami 🙂

Porównywanie ich do większych modeli mija się trochę z celem, ponieważ w przypadku 1B i 3B Meta postawiła na możliwość uruchamiania ich na mniej wydajnym sprzęcie, a nawet na komórce 😉 O ile model 1B słabo sobie radzi, o tyle 3B potrafi zaskoczyć.

Modele do pobrania

Zapraszamy oczywiście na nasz HuggingFace, na którym stworzyliśmy kolekcję z modelami pLLama3.2 Models. Wszystkie modele oczywiście udostępniamy publicznie za darmo:

Modele w architekturze 1B: radlab/pLLama3.2-1B – model tylko po fine-tuningu, oraz radlab/pLLama3.2-1B-DPO po FT + DPO
Modele w architekturze 3B: radlab/pLLama3.2-3B model tylko po fine-tuning, oraz radlab/pLLama3.2-3B-DPO po FT + DPO

Częstujcie się 🙂

Co dalej?

Dalej będzie nie-ko-po-le-i: pLLama3.1-8B (to ten zielony wykres) oraz L31 jako pewien ciekawy mix…

pLlama3 (8B + 70B) – GenAI dla polskiego

2024-08-18T00:00:00Z

pLLama – wygenerowane za pomocą AI

Intro

Witajcie!

W ostatnim wpisie wspominaliśmy o modelu GenaAI… Tak! Dzisiaj chcemy przedstawić Wam nasz nowy model, a właściwie to rodzinę modeli douczoną na język polski: pLLama3-8B-chat, pLLama3-8B-creator oraz pLLama3-70B. Tym razem poszliśmy w kierunku douczania modeli od gigantów aby lepiej radziły sobie z naszym językiem.

Na pierwszy strzał poszły Llama-3-8B-Instruct oraz Llama-3-70B-Instruct od Meta.ai. Jest to model instrukcji, który potrafi wykonywać polecenia zadane w prompt’cie do modelu. Oryginalny model nie radzi sobie za dobrze z językiem polskim. Czasami potrafi coś po polsku napisać, jednak ciężko jest na nim wymusić płynną komunikację w naszym języku. Co ciekawe, zaskakująco dobrze potrafi zrozumieć polskie polecenia, jednak nie potrafi skonstruować poprawnej odpowiedzi.

Modele w architekturze 8B udostępniamy w dwóch konfiguracjach:

radlab/pLLama3-8B-creator , model który podaje dość krótkie, konkretne odpowiedzi na zapytania użytkownika;
radlab/pLLama3-8B-chat – model, który jest wersją gadatliwą, odzwierciedlającą zachowanie oryginalnego modelu meta-llama/Meta-Llama-3-8B-Instruct.

Dataset

Fakt, że oryginalny model potrafi rozumieć polskie polecenia był dla nas zapalnikiem do pracy nad modelem. Założyliśmy hipotezę, że wystarczy w takim razie odpowiednio douczyć warstwę językową, jak najmniej ingerując w warstwę instrukcji.

Ale, jak to w przypadku dużych modeli językowych bywa, pojawił się pierwszy problem. Skąd pozyskać dane (szczególnie dostępnych jako zestawy instrukcji/konwersacji na czacie!), aby było ich wystarczająco dużo oraz aby ich jakość była jak najlepsza? Dla języka polskiego, istnieje tak na prawdę jeden, publicznie dostępny zbiór danych do uczenia modelu instrukcji, jest to alpaca-dolly-chrisociepa-instruction-only-polish. Jednak wielkość tego zbioru, nie pozwalała na dostateczne douczenie modelu.

W związku z tym, opracowaliśmy metodę tworzenia zbioru danych w strukturze instrukcji, korzystając z innych, dostępnych w sieci datasetów. Opracowaliśmy zestaw około 650k instrukcji w języku polskim, którymi nakarmiliśmy model podczas uczenia.

Dodatkowo, opracowaliśmy zbiór uczący do procesu DPO, który zawierał 100k przykładów, w których uczyliśmy model wybierać poprawnie zapisane wersje tekstów od tych, które zawierają błędy językowe. Przykłady uczące do DPO zawierały poprawnie zapisaną formę językową (chosen) oraz niepoprawnie zapisaną formę (rejected) tego samego tekstu. Warto zaznaczyć, że danych do DPO budowany był wstecznie — mianowicie dla bardzo dobrej jakości tekstów (chosen), przygotowaliśmy ich odpowiednik zaśmiecony (rejected).

Proces uczenia

Proces uczenia podzielony był na dwa etapy:

Dotrenowywanie ( FT ) na zbiór 650k instrukcji w języku polskim, czas fine-tuningu ustawiony był na 5 epok.
Po etapie FT, dotrenowaliśmy model za pomocą DPO na 100k instrukcji poprawnego pisanie po polsku, w tym przypadku ustawiliśmy czas uczenia na 15k kroków.

Douczanie modelu na 650k miało na celu przeniesienie warstwy językowej dotrenowywanego modelu w stronę języka polskiego. Niestety ze względu na nieidealny zbiór instrukcji

ciekawostka: zbiór instrukcji, generowany był w ~95% automatycznie — wykorzystując wczesną formę uczonego modelu (w architekturze 70B) iteracyjnie, do wspomagania tworzenia zbioru, który utworzyliśmy do uczenia tego modelu docelowego…

model zaczął faktycznie mówić po polsku i reagować na instrukcje, ale czasami popełniał dość sporo literówek. Dlatego postanowiliśmy dotrenować model w DPO. W DPO przede wszystkim chcieliśmy uzyskać poprawę warstwy językowej modelu w stosunku do modelu z FT. Optymalizacja polegała na uczeniu modelu wyboru poprawnej formy językowej, a odrzucaniu niepoprawnej.

Na poniższym wykresie przedstawiona jest funkcja straty podczas całego procesu uczenia (model 8B). Nagły spadek wartości na początku funkcji, może świadczyć o dość szybkim dostosowaniu modelu do języka polskiego. A cały, długotrwały proces uczenia, to de facto poprawianie już szczegółów językowych.

Modele 8B uczyliśmy przez 5 epok, i cały proces uczenia trwał przez ponad 19d 14h na jednej karcie RTX 4090.

Szczegółowe metryki po skończonym fine-tuningu (model 8B):

Metryka	Wartość
eval/loss	0.8690009713172913
eval/runtime	464.5158
eval/samples_per_second	8.611
total_flos	46121863674517000000
train_loss	0.8724352801788304
train_runtime	1695168.0431
train_samples_per_second	1.758
train/epoch	5
train/grad_norm	0.17023593187332153
train/learning_rate	6.584723441615452e-8
train/loss	0.8293

Metryki po procesie uczenia (fine-tuningu)

Zaś metryki DPO przedstawiają się następująco:

eval/logits/chosen: 0.1370937079191208
eval/logits/rejected: 0.07430506497621536
eval/logps/chosen: -454.11962890625
eval/logps/rejected :-764.1261596679688
eval/loss: 0.05717926099896431
eval/rewards/accuracies: 0.9372459053993224
eval/rewards/chosen: -26.75682830810547
eval/rewards/margins: 32.37759780883789
eval/rewards/rejected: -59.134429931640625
eval/runtime: 1,386.3177
eval/samples_per_second: 2.838
eval/steps_per_second: 1.42

Na poniższym wykresie przedstawiona jest funkcja straty podczas całego procesu uczenia modelu w architekturze 70B.

Model 70B uczyliśmy również przez 5 epok, i cały proces uczenia trwał przez ponad 1mo 5d na jednej karcie RTX A6000 ADA 48GB, zaś metryki po skończonym fine-tuningu:

eval/loss:0.7297297716140747
eval/runtime:6,364.4589
eval/samples_per_second:0.628
eval/steps_per_second:0.628

Co po uczeniu?

Nasze modele mają jedną, bardzo ciekawą cechę. W tej chwili potrafią przeczytać tekst w „dowolnym” języku, a odpowiedzieć po polsku. Dlatego jeden z nich, który nazwaliśmy pLLama3-8B-creator zatrudniliśmy do pisania artykułów do pewnego projektu, o którym wkrótce. Inny z nich pLLama3-8B-chat również ma tam swój udział 🙂 Enjoy!

Huggingface

Oczywiście! Model udostępniamy za darmo na naszym huggingface. Poszczególne modele:

radlab/pLLama3-8B-chat pod adresem https://huggingface.co/radlab/pLLama3-8B-chat
radlab/pLLama3-8B-creator dostępny https://huggingface.co/radlab/pLLama3-8B-creator
radlab/pLLama3-70B dostępny: https://huggingface.co/radlab/pLLama3-70B

Smacznego i na zdrowie! 🙂

RAG (i problemy?)

2024-10-20T00:00:00Z

Wstęp

Dzisiejszy wpis będzie nieco inny niż przeważnie. Tym razem nie przybywamy z nowym modelem, ale z opisem metody RAG. Metoda jest ogólnie znana, dlatego ten wpis będzie bardziej w kontekście problemów, które pojawiają się podczas realizacji systemów wykorzystujących RAG’a, niż opis samej metody.

Opowiadając w kilku słowach czym jest RAG, można powiedzieć, że jest to metoda wyszukiwania informacji połączona (w warstwie prezentacji wyników) z modelem generatywnym/modelem instrukcji. Mechanizm wyszukiwania oraz zmiany kolejności wyszukanych wyników jest odpowiedzialny za odnalezienie fragmentów tekstów, w których znajduje się odpowiedź na pytanie zadane przez użytkownika. Następnie, fragmenty tekstów aplikowane są do modelu generatywnego w taki sposób, aby model na ich podstawie odpowiedział na pytanie zadane przez użytkownika. I tyle w skrócie 😉

Do czego, w takim razie, można wykorzystać RAGa? Z racji, że jest to metoda wyszukiwania, to oczywiście do wszelakiego rodzaju wyszukiwarek. Jednak ważnym aspektem, który odróżnia RAGa od standardowego sposobu przeszukiwania kolekcji dokumentów, jest wprowadzenie modelu generatywnego (GenAI) do udzielenia końcowej odpowiedzi dla użytkownika. Dzięki dokładności samej wyszukiwarki oraz zdolności modelu GenAI do odpowiadania na pytania na podstawie kontekstu, RAG idealnie nada się do wyszukiwania i podsumowywania informacji rozproszonej w wielu dokumentach. Dodatkowo, dzięki GenAI oraz ich przeznaczeniu do prowadzenia konwersacji na czacie, mamy możliwość wpływania na końcową postać odpowiedzi przy zadawaniu pytania. Dla przykładu wyobraźmy sobie, że mamy kolekcję dokumentów, w której gromadzimy teksty z różnymi opiniami użytkowników odnośnie różnych produktów. W tym przypadku RAG idealnie nadałby się do odpowiedzenia na pytanie:

Jakie są pozytywne, a jakie negatywne opinie na temat produktu XYZ? Podaj po trzy przykłady pozytywnych i negatywnych opinii oraz zaproponuj odpowiedzi na komentarz klienta.

Jak widać w przykładzie, do RAGa można podać nie tyklo hasło do wyszukania, ale i rozbudowaną instrukcję udzielenia odpowiedzi.

Na Rys. 1 przedstawiliśmy podział procesu RAG na mniejsze i konkretniejsze kroki. Znajduje się tam sześć głównych modułów, które symbolizują zagadnienia w całym potoku RAGa. Za pomocą czerwonej, przerywanej linii i czerwonej strzałki zaznaczona jest minimalna ścieżka w takim potoku. Zielona linia i zielona strzałka pokazuje optymalną ścieżkę w potoku, który można nazwać RAGiem. W tym wpisie, krótko opisaliśmy poszczególne kroki, a ich szczegółowe rozwinięcia będą publikowane w kolejnych wpisach.

Rys.1 Elementy RAG (opracowanie własne)

RAG w kawałkach

Dane

Dane, to podstawowy element każdego systemu, w którym wykorzystywane są metody uczenia maszynowego (ML). W zależności od problemu, który taki system ML realizuje, należy dostarczyć mu odpowiednie dane. W przypadku RAGa – dane, to wszelakiego rodzaju teksty, w których znajdowane będą odpowiedzi. Może się zatem wydawać, że w dzisiejszych czasach w internecie przecież można znaleźć wszystko i brak danych nie powinien być problemem… Po części tak, ale w większej części nie 😉

To właśnie mnogość danych wprowadza problem z ich lokalizacją, dostępnością na odpowiedniej licencji oraz ich jakością dowolnie rozumianą. Selekcja pochodzenia informacji z określonych źródeł, jakości samych danych, ich czytelność oraz szczegółowość, to bardzo istotny element całej układanki. Dodajmy do tego jeszcze różne formaty plików, w których zapisane są informacje (w tym format pdf), wtedy na starcie stajemy przed misją integracji różnych źródeł do wspólnego formatu. Pamiętajmy, że jeżeli do systemu wprowadzimy dane, które zawierają nieprawdziwe informacje, lub zawierają ich za mało, bądź są za mało szczegółowe, to system wykorzystujący metodę RAG będzie właśnie na ich podstawie podawał odpowiedzi, które mogą być błędne.

Warto raz jeszcze podkreślić, że końcowa odpowiedź systemu generowana jest na podstawie dostarczonych danych z wyszukiwarki. Zatem jeżeli w wyszukiwarce znajdą się nierzetelne dane, nieprawdziwe i małomerytoryczne informacje, to takie też odpowiedzi będziemy dostawać. Dlatego warto poświęcić czas na odpowiednie dobranie zbioru/utworzenie kolekcji dokumentów, na której będziemy działać, oraz zadbać o preprocessing danych.

Można zatem śmiało powiedzieć, że jakość odpowiedzi z takiego systemu, jest mocno determinowana jakością danych, z których taki system korzysta.

Preprocessing danych

Bardzo istotnym elementem systemu RAG jest preprocessing danych, czyli ich wstępna obróbka. Zanim dane trafią do dalszego procesu, warto wprowadzić pewien standard co do ich jakości. Wspomniana różnorodność zapisów danych powoduje problem z odpowiednim ich odczytywaniem. Automatyczne przetwarzanie danych pobranych ze stron www, plików docx, pdf wprowadza duży szum w danych. Z perspektywy systemu RAG ważne jest, aby dane zawierały istotne informacje. Przy automatycznym wczytywaniu danych, przykładowo z pliku pdf, odczytamy nie tylko istotne fragmenty, ale całą masę tekstu, łącznie z nagłówkami rozdziałów, poszatkowanymi danymi tabelarycznymi, bądź co gorsze — całkowicie nieczytelne dane, jak np. te (np. kiedy w pliku pdf są obrazki, które również jest ciężko OCRować):

4kV�#4T��##�_#�p��W#�_�|3��-�tg�\S�x�b�X��t�]*���\&/#��/�P�

Oczywiście na taką sytuację ciężko jest coś poradzić, ale warto je wykrywać i nie dopuszczać danych dalej, już na etapie obróbki wstępnej. W naszym wcześniejszym wpisie przedstawiliśmy inny problem z plikami pdf. Po ich odczytaniu, dostajemy mocno zdeformowane dane, cytując przykład z wpisu:

Strona...Tytuł...%6%z%50%|.....Zdecydowana0większość0czerwonych.karłów$należy#do,typu,widmowego%M,%ale%zalicza^się^do^nich^także^wieleHgwiazdHpóźnychHpodtypówHtypuHwidmowegoHKHorazHrzadkoHwystępujące,,najsłabsze,gwiazdy,typu,L.,Maksimum%intensywności%emitowanego%światła%przypada%w%zakresie%światła%czerwonego%lub%nawet%bliskiej%podczerwieni.

A to z perspektywy dalszego przetwarzania bez odpowiedniego wyczyszczenia takich danych, niesie tylko problemy. Indeksacja tekstu, który zawiera aż tak nieczytelne dane, spowoduje, że będą one równie nieczytelne dla samych metod przeszukujących. Ważne jest aby na tym etapie potrafić dane ocenić pod względem ich jakości oraz w miarę możliwości doprowadzić je do postaci zbliżonej do ideału 😉 Czy na tym etapie warto już wprowadzać modele ML do oceny i poprawy — oczywiście, że tak! Oto przykład działania naszego modelu T5, który czyści teksty z takich sytuacji:

Zdecydowana większość czerwonych karłów należy do typu widmowego M, ale zalicza się do nich także wiele gwiazd późnych podtypów typu widmowego K oraz rzadko występujące, najsłabsze gwiazdy typu L. Maksimum intensywności emitowanego światła przypada w zakresie światła czerwonego lub nawet bliskiej podczerwieni.

Może nie idealnie, ale znacznie lepiej od pierwotnej formy 😉

Co zrobić w jeżeli w dokumentach mamy dużo tabel, rysunków/wykresów? Warto rozważyć wykorzystanie modeli, które potrafią je interpretować oraz generować opis, którym następnie można wzbogacić oryginalny tekst.

(…) Ważne jest również identyfikowanie tych dobrych i tych złych jakościowo danych, oraz ich standaryzacja do dalszego przetwarzania.

Indeksowanie danych

To bardzo istotny proces w całym RAGu. Po wstępnej obróbce danych trzeba je zapisać w bazie, w której następnie będą one wyszukiwane. Na tym etapie warto wprowadzić równoległe indeksowanie tekstu zarówno w bazie relacyjnej jak i wektorowej. Baza relacyjna pomoże w ułożeniu dłuższego dokumentu w jego oryginalną strukturę, zaś wektorowa umożliwi semantyczne przeszukiwanie. Bardzo ważnym elementem w procesie indeksowania jest sposób indeksacji. To na tym etapie decydujemy, które informacje z wcześniejszego kroku będą indeksowane, oraz gdzie i jak.

Przede wszystkim należy zastanowić się nad przeznaczeniem systemu RAG (konkretna dziedzina, specjalistyczny agent, ogólne informacje) i dobrać odpowiedni model (embedder), który odpowiednio dobrze „zrozumie” indeksowane treści. To właśnie embedder tworzy wektorowe reprezentacje tekstów, które indeksowane są w bazach wektorowych (np. Milvus), które to następnie są przeszukiwane. Jeżeli na tym etapie transformacja tekstu do wektora będzie niedokładna, czyli innymi słowy, jeżeli źle dobierzemy model embeddera do treści, które indeksujemy, to może to skutkować gorszą/mniej dokładną jakością w procesie ich porównywania. Błąd z indeksowania może zatem być propagowany do dalszych kroków przetwarzania. Ważne jest również dobranie odpowiedniej długości tekstów, które indeksowane są jako pojedynczy fragment. Jeżeli tekst jest za długi, warto podzielić go na mniejsze części zwane chunkami — czyli jeden tekst podzielony jest na kilka mniejszych fragmentów.

Co w sytuacji, kiedy indeksujemy mocno specyficzne treści, do których nie ma dostępnych embedderów? Oczywiście, stajemy przed problemem znalezienia innego, bardziej dopasowanego lub wyuczenia takiego modelu od początku. W jednym z wcześniejszych postów przedstawiliśmy nasz wstępny model embedder, który trenowany był na treściach internetowych.

(…) Istotne jest również dobranie lub wyuczenie specjalistycznego embeddera oraz odpowiednia indeksacja w bazach.

Wyszukiwanie

Można powiedzieć, że sprawa się tutaj nieco upraszcza, ponieważ na etapie wyszukiwania korzystamy z tych samych mechanizmów tłumaczących tekst do reprezentacji wektorowej, co na etapie indeksacji… Nic bardziej mylnego. Dzieje się tak tylko w przypadku, kiedy ograniczamy proces wyszukiwania, tylko do policzenia podobieństwa wektorów reprezentujących pytanie do chunków w bazie. Najczęściej obliczany jest kosinus kąta między wektorem pytania, a wektorami zapisanymi w bazie wektorowej. Tymi wektorami, które zapisaliśmy na etapie indeksowania danych. Jednak, jak wspomnieliśmy wcześniej, zależy jakie informacje indeksujemy, oraz gdzie i jak.

Jeżeli na etapie indeksacji, wzbogacimy informacje o indeksowanych fragmentach o dodatkowe metadane, to właśnie w tym kroku jesteśmy w stanie wstępnie odsiać te chunki, które na 100% są nieprawidłowe. Przykładowo, jeżeli wzbogacimy opis chunku o jego kategorię, wtedy na tym etapie, przed semantycznym porównywaniem za pomocą wyszukiwarki, możemy ograniczyć przestrzeń poszukiwań tylko do tych, które pochodzą ze wskazanej kategorii.

Zatem warto rozważyć opcję, aby semantyczne wyszukiwanie było ograniczane przez dodatkowe wymiary. Czy do tego przydadzą się dodatkowe metody ML? Oczywiście, że tak. To tylko kwestia wyobraźni oraz przeznaczenia danego modelu.

(…) Dodatkowe metainformacje o chunkach mogą mocno pomóc podczas wyszukiwania, np. ograniczenie wyników tylko do dokumentów z określonej kategorii.

Zmiana kolejności rankingu wyników

Ok, a co dalej, jeżeli po odpowiednim filtrowaniu i wyszukaniu informacji nadal mamy problem z wyborem, który z wyszukanych chunków jest najistotniejszy? Wtedy z pomocą nadchodzi proces rerankingowania kolejności wyników zwracanych przez wyszukiwarkę. Jednym ze standardowych podejść jest wykorzystanie modeli typu cross-encoders, które, jeżeli są w odpowiedni sposób nauczone, mogą określić stopień relewantności pytania do wyszukanego chunka. Oczywiście, jak w przypadku embeddera, jeżeli model rerankera nie będzie odpowiednio dobrany do specyfiki danych, wynik może być przeciwny oczekiwanemu 🙂

Co w takiej sytuacji trzeba zrobić? Głównie stosuje się dwa podejścia:

po lepszym zrozumieniu dziedziny oraz dokładniejszym researchu, bardziej świadomie dobiera się inny,
lub samemu trenuje się specjalistyczny reranker dostosowany do problemu.

Zarówno jedno jak i drugie podejście ma zalety i wady. Pierwsze z nich jest szybsze, ale (a) nie ma gwarancji, że w ogóle jest taki model, który potrzebujemy, (b) jeżeli godzimy się na jakiś model, to akceptujemy jego dokładność w naszym problemie. Podejście z uczeniem lub douczaniem własnego, raczej będzie dużo bardziej kosztowne, ze względu na czas potrzebny na jego wytworzenie. Jednak jest duża szansa, że taki model będzie dużo dokładniejszy od dostępnych, co podniesie jakość końcowego systemu RAG. Co zatem wybrać? Zależy od sytuacji… 😉

Oczywiście w procesie rerankingowania nie jesteśmy ograniczeni do operowania tylko na modelach cross-encoders, na tym etapie dostajemy potencjalne fragmenty, które zawierają odpowiedź, więc to jedynie nasza wyobraźnia ogranicza nas tutaj z tym, co można zrobić… Czy warto stosować tutaj modele specjalistyczne? Jak najbardziej.

(…) Dopasowanie relewantności chunku do zadanego pytania jest bardzo istotnym krokiem. Nieodpowiednia zmiana kolejności rankingu dokumentów może spowodować, że teksty z istotną informacją zostaną odrzucone tuż przed samym podaniem do GenAI, co mocno może zepsuć końcowy rezultat.

Generowanie odpowiedzi

I w końcu jesteśmy tutaj, czyli na etapie, który na końcowym użytkowniku wywołuje największe wrażenie. Dopiero na tym etapie do gry wchodzi GenAI — jako element konstruujący odpowiedź, która przedstawiana jest jako odpowiedź dla użytkownika systemu RAG.

Wszystkie wspomniane wcześniej kroki, to potok preprocessingu danych, wyszukania, selekcji i określenie relewantności cząstkowych wyników do zapytania użytkownika. To właśnie te kroki w bardzo dużym stopniu determinują czy końcowa odpowiedź będzie na temat, czy nie. Źle dobrane dane na tym etapie spowodują efekt halucynacji modelu GenAI. Ważne jest również, aby model GenAI, który wykorzystujemy do generowania odpowiedzi był również odpowiednio douczony w zadaniu odpowiadania na pytania. Mówiąc o GenAI, raczej myślimy o modelach instrukcji. Ważne zatem jest, aby taki GenAI nie tylko rozumiał język, potrafił w tym języku odpowiadać, ale również odpowiednio reagować na instrukcję. To jego zadaniem będzie podsumowanie wszystkich fragmentów/chunków zwróconych z wcześniejszych kroków. Więc ważne, aby taki model przede wszystkim potrafił reagować na instrukcje odpowiadania na pytania, na podstawie dostarczonego kontekstu w postaci chunków.

Warto pamiętać o jeszcze jednej, istotniej kwestii takich modeli, mianowicie wielkości wejścia. Każdy model ma określoną wielkość wejścia. Wielkość wejścia oznacza ile danych, mierzonych w liczbie tokenów, taki model jest w stanie przetworzyć. Jeżeli do modelu podamy za dużo danych, najprawdopodobniej będą one pomijane — a tego nie chcemy w RAGu, gdzie przeszukujemy potężne kolekcje i równie dużo odpowiedzi możemy dostać!

Modele instrukcji, to przeważnie bardzo duże modele, zaczynając od tych mniejszych 8B (miliarów), przez 70B, 405B i więcej parametrów. W takim razie stajemy przed kolejnym pytaniem — model u siebie, czy model w chmurze? Oczywiście wszystko zależy od przeznaczenia systemu oraz możliwości przesyłania danych przez internet do serwisów zewnętrznych takich jak ChatGPT. Jeżeli wybór pada na model generatywny odpytywany lokalnie, pozostaje kwestia jak we wszystkich wcześniejszych krokach…. odpowiedni model do wybranego problemu 🙂 A jaki model? To już osobne opowiadanie.

(…) Wcześniejsze kroki są istotne, ale równie istotny jest odpowiedni dobór GenAI, który generował będzie końcową odpowiedź. To on może popsuć całe wrażenie.

Zakończenie

Poskładajmy całość do kupy 😉

Można zatem śmiało powiedzieć, że jakość odpowiedzi z takiego systemu, jest mocno determinowana jakością danych, z których taki system korzysta. Ważne jest również identyfikowanie tych dobrych i tych złych jakościowo danych, oraz ich standaryzacja do dalszego przetwarzania. Istotne jest również dobranie lub wyuczenie specjalistycznego embeddera oraz odpowiednia indeksacja w bazach. Dodatkowe metainformacje o chunkach mogą mocno pomóc podczas wyszukiwania, np. ograniczenie wyników tylko do dokumentów z określonej kategorii. Dopasowanie relewantności chunku do zadanego pytania jest bardzo istotnym krokiem. Nieodpowiednia zmiana kolejności rankingu dokumentów może spowodować, że teksty z istotną informacją zostaną odrzucone tuż przed samym podaniem do GenAI, co mocno może zepsuć końcowy rezultat. Wcześniejsze kroki są istotne, ale równie istotny jest odpowiedni dobór GenAI, który generował będzie końcową odpowiedź. To on może popsuć całe wrażenie.

PPS.

A już niebawem opublikujemy nasz model GenAI — pLLama, model LLama douczony na język polski 🙂

Narzędzia wspomagające architekturę RAG: Aby bezpiecznie kierować ruchem zapytań do modeli lokalnych i chmurowych oraz zabezpieczyć zapytania przed wyciekiem danych osobowych, sprawdź bramę LLM Router oraz system ochrony prywatności PII Masker.

Model bi-encodera i cross-encodera

2024-04-30T00:00:00Z

Wstęp

Możliwości płynące z wykorzystania modeli generatywnych są ogromne, wystarczy spojrzeć na sukces OpenAI i flagowego produktu ChatGPT. Modele generatywne oparte o architekturę transformers dorównują człowiekowi w zakresie tworzenia contentu, czy to tekstowego, czy w formie zdjęć, czy też bardziej skomplikowanych animacji. Pomimo potężnych możliwości generatywnych mają one podstawową wadę: aktualizacja informacji w tych modelach. Odpytując taki model o informacje ze świata codziennego, które wykraczają poza zbiór uczący, praktycznie nie jest możliwe, aby model udzielił prawidłowej odpowiedzi. Jednym z rozwiązań tego problemu, jest podejście oparte o Retrieval Augmented Generation (RAG).

Retrieval Augmented Generation

Idea RAGa polega na odseparowaniu od modelu generatywnego warstwy informacyjnej. Warstwa informacyjna, to jakaś forma bazy danych, w której zapisane są informacje, zaś model generatywny jest wykorzystywany do udzielania odpowiedzi na podstawie wyszukanych w bazie informacji. Co daje takie podejście? Bardzo dużo. Wprowadza to pewien przełom w NLP, gdzie wykorzystywane wcześniej podejścia Retrieval Information (zastąpione przez nowe mechanizmy), połączone z dobrze działającymi modelami generatywnymi, są w stanie udzielać najświeższych informacji. Ponieważ informacje te zapisywane są w bazie, mogą być na bieżąco aktualizowane. W momencie, kiedy jakaś informacja staje się nieaktualna, wystarczy usunąć ją z bazy. W skutek czego, model generatywny przy udzielaniu odpowiedzi nie otrzyma tej informacji jako kontekstu do udzielenia odpowiedzi, co ograniczy halucynacje tego modelu.

Maszyneria

W takim razie co jest potrzebne, aby zrealizować podejście RAG? W najprostszym przypadku jest to kilka działających mechanizmów:

mechanizm konwertujący tekst do postaci wektorowej (dalej zwany embedderem );
baza danych, która umożliwia przechowywanie i przeszukiwanie zaindeksowanych tekstów (np. Milvus );
model generatywny, który będzie udzielał odpowiedzi na podstawie dostarczonego kontekstu (np. LLama3 od MetaAI ).

W bardziej skomplikowanych przypadkach kontroluje się nie tylko proces wyszukiwania informacji, ale również sam zbiór tekstów, które zostały zwrócone przez wyszukiwarkę.

Model embeddera i rerankera

W dzisiejszym wpisie chcemy zaprezentować nasze dwa modele. Pierwszy z nich to embedder, który można wykorzystać do transformacji tekstu w postać wektorową. Drugi, to mechanizm rerankingujący wyniki zwrócone przez wyszukiwarkę semantyczną. Techniczna różnica między embedderem (bi-encoderem), a rerankerem (cross-encoderem) jest bardzo dobrze przedstawiona w tym artykule. W telegraficznym skrócie: model bi-encodera uczymy na proces podobieństwa semantycznego, gdzie funkcja oceny to wskazana odległość semantyczna, w naszym przypadku miara kosinus-kąta. Zaś w przypadku cross-encodera, model uczony jest wartością funkcji straty, wynikającą z korelacji odpowiedzi modelu w stosunku do zbioru testowego.

Do budowy tych modeli wykorzystaliśmy bibliotekę sentence-transformers. Funkcja straty dla modelu bi-encodera, to odległość kosinusowa, dla cross-encodera CECorrelationEvaluator. Jako zbiór danych wykorzystaliśmy istniejące zbiory do information-retrieval np. ipipan/maupqa, które wzbogaciliśmy o nasz zbiór radlab/polish-sts-dataset. Oczywiście w obu przypadkach należało odpowiednio przekształcić te zbiory i dostosować do problemu uczenia bi-encodera i cross-encodera.

bi-encoder

Model bi-encodera, na jednej karcie NVIDIA GeForce RTX 4090 uczył się przez 1 dzień 9 godzin. Wartości korelacji Pearsona i Spearmana, mierzone na zbiorze ewaluacyjnym przedstawiają się następująco:

To, co z naszej perspektywy jest najbardziej interesujące, to korelacja dla Cosine-Similariy. Wartości korelacji są wysokie i w obu przypadkach ich interpretacja jest jako silna i dość silna korelacja. Co oznacza, że odpowiedzi modelu silnie korelują z danymi testowymi. Opublikowany model bi-encodera, posiada uśrednioną warstwą poolingu. Można go wykorzystać do tworzenia embeddingów z tekstu i semantycznego ich porównywania. Link do modelu na huggigface: radlab/polish-bi-encoder-mean.

Przykładowy kod do załadowania modelu za pomocą sentence-transformers, który dla wskazanych tekstów stworzy reprezentację wektorową:

from sentence_transformers import SentenceTransformer
sentences = ['Ala ma kota i psa, widzi dzisiaj też śnieg', 'Ewa ma białe zęby']

model = SentenceTransformer('radlab/polish-bi-encoder-mean')
embeddings = model.encode(sentences)
print(embeddings)

cross-encoder

Udostępniliśmy również model cross-encodera, który zwraca wartość relewantności dwóch tekstów. Można go wykorzystać oczywiście jako reranker np. w wyszukiwarce semantycznej. Jak taki proces może wyglądać? Jak zwykle – prosto 🙂

Jako wynik wyszukiwania semantycznego, dostajemy pewien zbiór tekstów, który uszeregowany jest względem wartości podobieństwa jednego fragmentu tekstu, do innego – tego wyszukiwanego. Ten zbiór jest idealnym wejściem dla modelu, którego celem jest określenie nie tylko podobieństwa między dwoma fragmentami tekstów, ale również stwierdzenie, który fragment lepiej dopasowuje się do wyszukiwanego tekstu.

Gotowy model rerankingujący, również udostępniliśmy na huggingface w repozytorium radlab/polish-cross-encoder Model ten uczony był na jednej karcie NVIDIA GeForce RTX 4090 przez 3 dni i 10 godzin. Korelacja Pearsona i Spearmana na zbiorze testowym:

Pearson Correlation : 0.9360742942528038
Spearman Correlation : 0.8718174291678207

Wartości obu korelacji, podobnie jak w przypadku bi-encodera są interpretowane jako silna i dość silna korelacja odpowiedzi modelu ze zbiorem testowym.

Przykładowy kod (z wykorzystaniem sentence-transformers), który przyporządkowuje odpowiedzi do pytania:

from sentence_transformers.cross_encoder import CrossEncoder

model_path = "radlab/polish-cross-encoder"
model = CrossEncoder(model_path)

questions = [
    "Jaką mamy dziś pogodę? bo Andrzej nic nie mówił.",
    "Gdzie jedzie Andrzej? Bo wczoraj był w Warszawie.",
    "Czy oskarżony się zgadza z przedstawionym wyrokiem?",
]
answers = [
    "Pan Andrzej siedzi w pociągu i jedzie do Wiednia. Ogląda na telefonie zabawne filmiki.",
    "Poada deszcz i jest wilgotno, jednak wczoraj było słonecznie.",
    "Wyrok jest prawomocny i nie podlega dalszym rozważaniom.",
]
for question in questions:
    context_with_question = [(s, question) for s in answers]
    results = sorted(
        {
            idx: r for idx, r in enumerate(model.predict(context_with_question))
        }.items(),
        key=lambda x: x[1],
        reverse=True,
    )

    print(f"QUESTION: {question}")
    print("ANSWERS (sorted):")
    for idx, score in results:
        print(f"\t[{score}]\t{answers[idx]}")
    print("")

Wynik wywołania powyższego kodu, powinien być zbliżony do:

QUESTION: Jaką mamy dziś pogodę? bo Andrzej nic nie mówił.
ANSWERS (sorted):
        [0.016749681904911995]  Poada deszcz i jest wilgotno, jednak wczoraj było słonecznie.
        [0.01602918468415737]   Pan Andrzej siedzi w pociągu i jedzie do Wiednia. Ogląda na telefonie zabawne filmiki.
        [0.016013670712709427]  Wyrok jest prawomocny i nie podlega dalszym rozważaniom.

QUESTION: Gdzie jedzie Andrzej? Bo wczoraj był w Warszawie.
ANSWERS (sorted):
        [0.5997582674026489]    Pan Andrzej siedzi w pociągu i jedzie do Wiednia. Ogląda na telefonie zabawne filmiki.
        [0.4528200924396515]    Wyrok jest prawomocny i nie podlega dalszym rozważaniom.
        [0.17350871860980988]   Poada deszcz i jest wilgotno, jednak wczoraj było słonecznie.

QUESTION: Czy oskarżony się zgadza z przedstawionym wyrokiem?
ANSWERS (sorted):
        [0.8431766629219055]    Wyrok jest prawomocny i nie podlega dalszym rozważaniom.
        [0.6823258996009827]    Poada deszcz i jest wilgotno, jednak wczoraj było słonecznie.
        [0.558414101600647]     Pan Andrzej siedzi w pociągu i jedzie do Wiednia. Ogląda na telefonie zabawne filmiki.

Outro

Oba, przedstawione dzisiaj modele, można bez problemu wykorzystać do budowy systemu opartego o podejście RAG. Można je również wykorzystać jako niezależnie działające modele. Warto jednak zaznaczyć, że wydajność mierzona czasem działania modelu cross-encodera, jest nieporównywalnie niższa od modelu bi-encodera. Dlatego w końcowym rozwiązaniu, zaleca się łączyć oba modele w jeden potok. W pierwszym kroku bazując na embeddingach tekstów, z bazy wyszukuje się najbardziej podobne fragmenty, następnie na zwróconych fragmentach dopasowuje się pytanie do ograniczonego zbioru odpowiedzi.

Oczywiście po więcej modeli zapraszamy na naszego huggingface Smacznego! 😉

Odszumiacz tekstów

2024-04-20T00:00:00Z

Aktualnie świat przetwarzania języka naturalnego został zdominowany przez rozwiązania oparte o modele w architekturze transformers. Różnorodność tych modeli praktycznie zdominowała każdy obszar NLP. Niezależnie jednak od architektury i przeznaczenia mają one wspólną cechę, mianowicie duże zapotrzebowanie na dobrej jakości dane, które wykorzystywane są do treningu tych modeli.

Problem do rozwiązania

Skąd w takim razie wziąć dane? Oczywiście zależy to od konkretnego przypadku i przeznaczenia modelu. A dane, jak to dane, często zapisane są w różnych formatach, w tym jednym z najmniej przystępnych do automatycznego przetwarzania czyli pdf. Koncepcja zapisu w formacie pdf to przede wszystkim prezentacja zapisanej treści, aby w dowolnym czytniku na dowolnym urządzeniu, forma graficzna była taka sama. Jednak podczas automatycznego przetwarzania tych plików można napotkać na problemy z odczytem zawartości.

Przykładowy problem z tekstem, który występuje po odczytaniu złej jakości pliku pdf:

Strona...Tytuł...%6%z%50%|.....Zdecydowana0większość0czerwonych.karłów$należy#do,typu,widmowego%M,%ale%zalicza^się^do^nich^także^wieleHgwiazdHpóźnychHpodtypówHtypuHwidmowegoHKHorazHrzadkoHwystępujące,,najsłabsze,gwiazdy,typu,L.,Maksimum%intensywności%emitowanego%światła%przypada%w%zakresie%światła%czerwonego%lub%nawet%bliskiej%podczerwieni.

Poprawna forma tego tekstu, to:

Zdecydowana większość czerwonych karłów należy do typu widmowego M, ale zalicza się do nich także wiele gwiazd późnych podtypów typu widmowego K oraz rzadko występujące, najsłabsze gwiazdy typu L. Maksimum intensywności emitowanego światła przypada w zakresie światła czerwonego lub nawet bliskiej podczerwieni.

Rozwiązanie problemu

Widząc wiele problemów, które są powtarzalne w dużej skali, opracowaliśmy metodę zaszumiania danych, które przypominają napotkane problemy. Metoda bazuje na prawdopodobieństwach warunkowych oraz odwzorowuje rozkład problemów z przetwarzanych masowo tekstów. Opracowany zbiór zawiera 1M tekstów, z których wylosowaliśmy 100k do procesu uczenia modelu odszumiacza.

Uczenie odszumiacza

Wykorzystaliśmy pretrenowany bazowy model w architekturze T5 allegro/plt5-base, który wyuczyliśmy na problem oczyszczenia danych. Uczenie modelu trwało 5 godzin i 30 minut na jednej karcie NVIDIA GeForce RTX 4090. Wykres loss-function dla zbioru ewaluacyjnego:

Przykład działania

Wyuczony model oczywiście udostępniliśmy na naszym huggingface w repozytorium radlab/polish-denoiser-t5-base.

Wejściem do modelu jest tekst w postaci: denoise: <tekst do odszumienia>. Dla przykładu wyżej, jest to:

denoise: Strona...Tytuł...%6%z%50%|.....Zdecydowana0większość0czerwonych.karłów$należy#do,typu,widmowego%M,%ale%zalicza^się^do^nich^także^wieleHgwiazdHpóźnychHpodtypówHtypuHwidmowegoHKHorazHrzadkoHwystępujące,,najsłabsze,gwiazdy,typu,L.,Maksimum%intensywności%emitowanego%światła%przypada%w%zakresie%światła%czerwonego%lub%nawet%bliskiej%podczerwieni.

Wyjście z modelu wygląda następująco:

Zdecydowana większość czerwonych karłów należy do typu widmowego M, ale zalicza się do nich także wiele gwiazd późnych podtypów typu widmowego K oraz rzadko występujące, najsławsze gwiazdy typu L. Maksimum intensywności emitowanego światła przypada w zakresie światła czerwonego lub nawet bliskiej podczerwieni.

Przykładowy kod, który umożliwia odpalenie modelu dla tekstu z przytaczanego przykładu:

from transformers import T5ForConditionalGeneration, T5Tokenizer

def do_inference(text, model, tokenizer):
    input_text = f"denoise: {text}"
    inputs = tokenizer.encode(
        input_text,
        return_tensors="pt",
        max_length=256,
        padding="max_length",
        truncation=True,
    )

    corrected_ids = model.generate(
        inputs,
        max_length=256,
        num_beams=5,
        early_stopping=True,
    )

    corrected_sentence = tokenizer.decode(corrected_ids[0], skip_special_tokens=True)
    return corrected_sentence

model = T5ForConditionalGeneration.from_pretrained("radlab/polish-denoiser-t5-base")
tokenizer = T5Tokenizer.from_pretrained("radlab/polish-denoiser-t5-base")

text_str = "Strona...Tytuł...%6%z%50%|.....Zdecydowana0większość0czerwonych.karłów$należy#do,typu,widmowego%M,%ale%zalicza^się^do^nich^także^wieleHgwiazdHpóźnychHpodtypówHtypuHwidmowegoHKHorazHrzadkoHwystępujące,,najsłabsze,gwiazdy,typu,L.,Maksimum%intensywności%emitowanego%światła%przypada%w%zakresie%światła%czerwonego%lub%nawet%bliskiej%podczerwieni."

print(do_inference(text_str, model, tokenizer))

Zapraszamy do korzystania, smacznego 🙂

Ochrona i sanitizacja promptów: W potokach produkcyjnych do automatycznego maskowania i anonimizacji danych wrażliwych przed wysłaniem do modeli LLM sprawdź narzędzie PII Masker oraz bramę LLM Router.

Ekstrakcyjne QA – nasz model polish-qa-v2

2024-08-18T00:00:00Z

W dziedzinie przetwarzania języka naturalnego stale pojawiają się innowacyjne rozwiązania, które umożliwiają precyzyjne odpowiadanie na pytania w różnych językach. Prezentujemy model polish-qa-v2, który stanowi krok naprzód w naszych badaniach nad dziedziną kojarzenia pytań z odpowiedziami przy użyciu wielkich modeli językowych.

Model polish-qa-v2 to przykład modelu ekstrakcyjnego QA, który specjalizuje się w wydobyciu najbardziej istotnego fragmentu tekstu celu udzielenia precyzyjnej odpowiedzi na pytanie. W przeciwieństwie do modeli generatywnych, które tworzą odpowiedzi od podstaw, modele ekstrakcyjne ograniczają się do wybierania istniejących fragmentów tekstu jako odpowiedzi na pytania.

Przykład użycia

from transformers import pipeline
model_path = "radlab/polish-qa-v2"
question_answerer = pipeline(
  "question-answering",
  model=model_path
)
question = "Jakie silniki posiadał okręt?"
context = """Okręt był napędzany przez trzy trzycylindrowe maszyny parowe potrójnego rozprężania, które napędzały poprzez wały napędowe trzy śruby napędowe (dwie trójskrzydłowe
zewnętrzne o średnicy 4,5 metra i czteroskrzydłową o średnicy 4,2 metra).
Para była dostarczana przez cztery kotły wodnorurkowe typu Marine,
wyposażone łącznie w osiem palenisk i osiem kotłów cylindrycznych,
które miały łącznie 32 paleniska. Ciśnienie robocze kotłów wynosiło 12 at,
a ich łączna powierzchnia grzewcza 3560 m². Wszystkie kotły były opalane węglem,
którego normalny zapas wynosił 650, a maksymalny 1070 ton.
Nominalna moc siłowni wynosiła 13 000 KM (maksymalnie 13 922 KM przy 108 obr./min),
co pozwalało na osiągnięcie prędkości maksymalnej od 17,5 do 17,6 węzła.
Zasięg wynosił 3420 mil morskich przy prędkości 10 węzłów. Zużycie węgla przy mocy 10 000 KM
wynosiło około 11 ton na godzinę, a przy mocy maksymalnej 16 ton na godzinę.
"""
print(
  question_answerer(
    question=question,
    context=context.replace("\n", " ")
  )
)

Po wykonaniu powyższego kodu, uzyskuje się następujący wynik:

{
  'score': 0.612459123134613,
  'start': 25,
  'end': 84,
  'answer': ' trzy trzycylindrowe maszyny parowe potrójnego rozprężania,'
}

Podstawę eksperymentu stanowi model sdadas/polish-roberta-large-v2, który dotrenowaliśmy na zbiorze danych clarin-pl/poquad. Trening trwał 2 godziny na pojedynczej karcie graficznej RTX 3090 Ti.

polish-qa-v2 dostępny jest na https://huggingface.co/radlab/polish-qa-v2, gdzie istnieje możliwość jego przetestowania, bez potrzeby uruchamiania lokalnie. Dla zainteresowanych udostępniamy pod tym samym linkiem cały model do pobrania.

Nowe modele gpt2!

2024-08-04T00:00:00Z

Dzisiaj udostępniliśmy dwa modele gpt2 trenowane od podstaw. Jeden w architekturze small, drugi w medium. Modele oczywiście dostępne są publicznie na naszym huggingface 😉

model w architekturze small : radlab/polish-gpt2-small-v2
model w architekturze medium : radlab/polish-gpt2-medium-v2

Poniżej po dwa zrzuty ekranu z procesu uczenia (miara accuracy) upublicznionych modeli.

Accuracy modelu w architekturze small:

Accuracy modelu w architekturze medium:

[Q&A] Uczenie GPU/CPU

2024-04-27T00:00:00Z

Q: Jak uruchomić uczenie/inferencję na wybranych GPU?

A: Należy uruchomić program z opcją:

CUDA_VISIBLE_DEVICES=0,1

gdzie 0 i 1 to numery kart graficznych do rozproszonego obliczenia.

Q: Jak włączyć/wyłączyć obsługę NVX dla połączonych kart graficznych mostkiem NVLink?

A: Przy połączonych kartach GPU obsługa NVlink w transformersach jest domyślnie uruchomiona. Aby wyłączyć obsługę NVX dla kart należy dodać do wywołania programu opcję

NCCL_P2P_DISABLE=1

Błędy podczas uczenia i douczania transformatorów

2024-04-27T00:00:00Z

Chcę wykorzystać trainera do fine-tuningowania ale dostaję komunikat CUBLAS_STATUS_ALLOC_FAILED

Problem pojawia się w bibliotece huggingface (transformers-4.3.2) + pytorch (torch-1.7.1) i dotyczy braku pamięci GPU.

(…) /pytorch/aten/src/THCUNN/ClassNLLCriterion.cu:108: cunn_ClassNLLCriterion_updateOutput_kernel: block: [0,0,0], thread: [13,0,0] Assertion `t >= 0 && t < n_classes` failed. (…) torch.autograd.backward(self, gradient, retain_graph, create_graph) File „/usr/local/lib/python3.8/dist-packages/torch/autograd/__init__.py”, line 130, in backward Variable._execution_engine.run_backward( RuntimeError: CUDA error: CUBLAS_STATUS_ALLOC_FAILED when calling `cublasCreate(handle)`

Rozwiązanie: Prawdopodobnie źle ustawiona liczba klas w trainerze. Liczba etykiet w danych oraz zadeklarowanych są różne.

Dostaję informację o braku pamięci na GPU pomimo tego, że mam

Problem pojawia się w bibliotece huggingface (transformers-4.3.2) + pytorch (torch-1.7.1).

RuntimeError: CUDA out of memory. Tried to allocate 120.00 MiB (GPU 0; 11.17 GiB total capacity; 7. 92 GiB already allocated; 145.81 MiB free; 6.56 GiB reserved in total by PyTorch)

Rozwiązanie: Zmniejszyć domyśle wielkości dla długości sekwencji, rozmiaru batcha podczas testowania oraz rozmiaru batcha podczas ewaluacji.

--max_seq_length
--per_device_train_batch_size
--per_device_eval_batch_size

Podczas rozproszonego uczenia (np. clm) dostaję komunikat typu ValueError: expected sequence of length 1024 at dim:

Problem: Podczas uczenia/testowania/walidacji modelu dostaję komunikat

83%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▋ | 5/6 [00:07<00:00, 1.03it/s] Traceback (most recent call last): File „run_clm.py”, line 579, in main() File „run_clm.py”, line 527, in main train_result = trainer.train(resume_from_checkpoint=checkpoint) File „/home/pkedzia/.local/lib/python3.8/site-packages/transformers/trainer.py”, line 1547, in train return inner_training_loop( File „/home/pkedzia/.local/lib/python3.8/site-packages/transformers/trainer.py”, line 1769, in _inner_training_loop for step, inputs in enumerate(epoch_iterator): File „/home/pkedzia/.local/lib/python3.8/site-packages/torch/utils/data/dataloader.py”, line 681, in next data = self._next_data() File „/home/pkedzia/.local/lib/python3.8/site-packages/torch/utils/data/dataloader.py”, line 721, in _next_data data = self._dataset_fetcher.fetch(index) # may raise StopIteration File „/home/pkedzia/.local/lib/python3.8/site-packages/torch/utils/data/_utils/fetch.py”, line 52, in fetch return self.collate_fn(data) File „/home/pkedzia/.local/lib/python3.8/site-packages/transformers/data/data_collator.py”, line 70, in default_data_collator return torch_default_data_collator(features) File „/home/pkedzia/.local/lib/python3.8/site-packages/transformers/data/data_collator.py”, line 136, in torch_default_data_collator batch[k] = torch.tensor([f[k] for f in features]) ValueError: expected sequence of length 1024 at dim 1 (got 393)

Rozwiązanie: Należy dodać parzystą liczbę workerów w preprocessie, czyli:

--preprocessing_num_workers 2

Ciekawostki o transformatorach

2024-04-27T00:00:00Z

BERT (ang. Bidirectional Encoder Representations from Transformers), to nie głęboka sieć neuronowa! To transformator!

Polecamy każdemu zainteresowanemu tematem transfomratorów:

Attention Is All You Need
Transformer: A Novel Neural Network Architecture for Language Understanding
Visualizing A Neural Machine Translation Model (Mechanics of Seq2seq Models With Attention)
The Illustrated Transformer

Narzędzia do tworzenia modeli word2vec

2024-04-27T00:00:00Z

Fasttext

Informacje wstępne

Do pobrania z: https://fasttext.cc/ Samouczek (reprezentacja słów): https://fasttext.cc/docs/en/unsupervised-tutorial.html

Format wejściowy

Wejściem jest plik tekstowy, w którym kolejne wiersze reprezentują kolejne teksty, zdania, frazy. Przykładowo:

 awokado przekrawać na pół usuwać pestka i wydrążać miąższ
 dziś niemiecki i musieć zaliczyć
 gra rozpoczynać jeden z gracz ciągnąć karta z stos karta zakryć lub z stos odkryty

Przykładowe wywołanie

 ./fasttext skipgram -minCount 5 \
   -lr 0.05 -ws 5 -epoch 10 \
   -input input-corpora-file.txt \
   -output output-corpora-file-model

GloVe

https://nlp.stanford.edu/projects/glove/
https://www.aclweb.org/anthology/D14-1162.pdf
https://nlp.stanford.edu/projects/glove/

RadLab — Blog

Zmrożone kopalnie kryptowalut?

Intro

Instalacja HiveOS

Konfiguracja OS

Instalacja LLM Routera

Zobacz log z uruchomienia [KLIK]+

Przykładowa konfiguracja: Ollama + gpt-oss:120b

Konfiguracja LLM Routera do obsługi gpt-oss:120b

Outro

Czy można w prosty sposób wprowadzić bazę wiedzy dla GenAI?

Intro

Indeksacja

Uruchomienie bazy wiedzy w LLM Routerze

Outro

Czy prawa natury można złamać?

Bieliki i Sójki w jednym gnieździe

Metafora Ekosystemu natury

Kilka słów o LLM Routerze

Bieliki i Sójki w LLM Routerze

Podgląd na ekosystem

Outro

Llm-Router – łącznik między aplikacją, a modelami generatywnymi

Login

Eksplozja supernowej

Karton z klockami

Coś dla oka

Logout

Upubliczniamy kody

relgat-projector („z boku”)

plwordnet („z boku”)

ml-utils („z boku”)

Moduły z playgroundu

Zakończenie

Eksplorator Informacji – nie młotek, a skalpel

Intro i Outro

Kombo

Polaryzacja 3c – model z plg na HF

Intro

Proces: dane i uczenie

Uruchomienie i testowanie

Outro

Przeglądarka informacji

O czym jest dzisiejszy wpis?

Jak to działa?

Dla kogo: od Sasa do lasa

Outro

pLLama3.1 8B — czyli średnio-duże a nawet małe GenAI dla Polskiego

Intro

Dataset, uczenie i wykresy

Outro

pLlama3.2 (1B + 3B) – małe GenAI dla polskiego

Intro

Dane i Trening

Odczucia

Modele do pobrania

Co dalej?

pLlama3 (8B + 70B) – GenAI dla polskiego

Intro

Dataset

Proces uczenia

Co po uczeniu?

Huggingface

RAG (i problemy?)

Wstęp

RAG w kawałkach

Dane

Preprocessing danych

Indeksowanie danych

Wyszukiwanie

Zmiana kolejności rankingu wyników

Generowanie odpowiedzi

Zakończenie

Model bi-encodera i cross-encodera

Wstęp

Retrieval Augmented Generation

Maszyneria

Model embeddera i rerankera

bi-encoder

cross-encoder