Przejdź do treści

DevStyle - Strona Główna
Z kamerą wśród LLM-ów: Trenowanie, Modele i Wnioskowanie

Z kamerą wśród LLM-ów: Trenowanie, Modele i Wnioskowanie

Tomasz Ducin

16 października 2025

Tools

TL;DR: przyjrzenie się anatomii i architekturze wewnętrznej modeli i agentów daje istotną przewagę w efektywnym wykorzystywaniu narzędzi LLM.

Z jednej strony zalewani jesteśmy “marketingowymi” hasłami o możliwościach AI i LLM-ów – i faktycznie – w tej technologii drzemie doprawdy ogromny potencjał… ALE:

  1. nic nie jest za darmo – każde narzędzie ma swoje ograniczenia i pułapki. Albo może przede wszystkim: kompromisy (trade-offy)
  2. nie wszystkim (niestety 😞 ) chce się zajrzeć pod maskę – wygodniej jest traktować “kolejny fajny model” jako black box. Ale to – jak z każdą technologią – stawia dość nisko sufit, powyżej którego ciężko się wznieść. “Nowy model” ma tyle a tyle parametrów, vendor (ten czy inny) twierdzi to i owo… ale co to oznacza w praktyce?

Niniejszy wpis to pierwszy z serii, w których przyjrzymy się kilku aspektom LLM-ów “od kuchni”. Trochę, aby zaspokoić ciekawość 😉 – ale przede wszystkim, aby lepiej rozumieć: co ma sens, co jest bez sensu – i gdzie są niewiadome.

LLM-y ♥ Matematykę

Trwają nieskończone debaty: na ile można mówić o “inteligencji” w odniesieniu do AI, na ile modele potrafią “rozumować”, co to jest “nauka” itp…

Oczywiście wszystko zależy od definicji. Przykładowo, wg Arthura Samuela, pioniera w dziedzinie uczenia maszynowego, ML to “Pole badań, które daje komputerom zdolność uczenia się bez bycia jawnie zaprogramowanym”. Filozofowie mieliby inną perspektywę, a neurobiolodzy – jeszcze inną. I zostawmy to im.

Na etapie, w którym obecnie się znajdujemy, duże modele językowe to kombinacja: analizy matematycznej i algebry liniowej, stosowanych na naprawdę ogromną skalę.

W turbo uproszczeniu: model składa się z dużej liczby bardzo dużych tensorów (“macierzy”), które mają wagi (czyli liczby) i na podstawie których odbywają się obliczenia.

I mamy tu zasadniczo 2 rodzaje aktywności:

  • trenowanie modelu (machine learning per se) – czyli dostosowywanie wag w oparciu o dane treningowe,
  • inferencja (pol. wnioskowanie 😆 ) – czyli wykorzystywanie wytrenowanego modelu do generowania odpowiedzi.

Możemy traktować “model” jako swoisty “artefakt”, punkt styku między jednym a drugim. Sprawa jest jednak znacznie bardziej złożona…

Trening

Trenowanie to proces “wykluwania” się wag (liczb), lub może raczej – ich “dostrajania” wskutek “przepuszczania” przez model ogromnych ilości danych treningowych.

– czy chcesz mi powiedzieć, że skutkiem treningu są gigabajty liczb?

– Fizycznie – dokładnie tak.

Ale jest tu znacznie więcej niuansów.

Po pierwsze, trening to proces iteracyjny. Model “przepuszcza” przez siebie dane treningowe wiele razy, za każdym razem dostosowując wagi, m.in. (bo nie tylko) w oparciu o to, jak bardzo jego odpowiedzi odbiegają od oczekiwanych.

W zależności od taktyki, można by powiedzieć, że m_1 (model w wersji pierwszej) wskutek kolejnych faz treningu “dostraja swoje wagi” wskutek czego powstaje m_2, a potem m_3, itp… Najczęściej mają one tę samą strukturę (wielkość, liczbę warstw, itp) ale różnią się zawartością – czyli wagami (liczbami, które potem są kluczowe w fazie wnioskowania).

– czy powstaje zatem finalna wersja m_final której wreszcie można używać?

– i tak, i nie 🙃 modelu można używać na każdym etapie, choć – wiadomo – z różnym skutkiem. Ale
nawet jeśli ktoś “wypuści model” do użytku, to potem i tak można poddać go kwantyzacji

– kwanty…co? 😲

– w tym punkcie nauka dostaje kopa w tyłek i z butami wchodzi biznes – ale o tym innym razem 😅

Kluczowe jest to – trening można przedstawić jako proces:

m_1 --(trening)--> m_2 --(trening)--> m_3 --(trening)--> ... --(trening/lub kwantyzacja)--> m_final -> ...

gdzie:

  • struktura jest najczęściej stabilna
  • zmieniają się wagi, co podczas wnioskowania ma doprowadzić do zwiększenia jakości generowanych odpowiedzi i/lub optymalizacji cost effective (kosztem tej jakości 😅 – to tu wjeżdża biznes)

Model językowy

Model językowy FIZYCZNIE można by przyrównać zatem do “archiwum” (analogicznie jak .zip, .tar) które zawiera:

  1. najpierw meta-definicje definiujące kształt i strukturę modelu (liczba warstw, liczba neuronów w warstwie i masę innych szczegółów 🙃 ), powiedzmy, taki quasi-HEAD-a,
  2. a potem quasi-BODY – ogromne ilości liczb (wag), które są “sercem” modelu.

model.gguf

(źródło)

I dzięki danym o strukturze (rozmiarach tensorów) “interpreter” (młyn, który będzie wnioskował) potrafi “zwyczajnym wskaźnikiem” (rodem z C/C++) zmontować sobie odpowiednie macierze i wektory – i uskuteczniać na nich operacje matematyczne.

Fizycznie” rezultatem trening jest model, który jest paczką zawierającą odpowiednio ustrukturyzowane gigabajty liczb.

Wnioskowanie

“Interpreter” to “po prostu” 😉 program, który rozpakowuje sobie to “archiwum” i potrafi – w uproszczeniu – przyjąć prompta i nam na niego odpowiedzieć. Lepiej lub gorzej 😅 . Interpretery są przeróżne: vendorzy się swoimi raczej nie chwalą (no shit, Sherlock!) ale powstał już niemały ekosystem rozwiązań OSS, w którym prym wiedzie llama-cpp, a także jego “nakładka” (z prostym agentem) – ollama.

chiński otwarty model deepseek kluczy unikając odpowiedzi na pytanie o wydarzenia z placu Tiananmen z 1989 r.

(Na screenie widzimy jak chiński otwarty model deepseek kluczy unikając odpowiedzi na pytanie o wydarzenia z placu Tiananmen z 1989 r. 😉 WARTO PAMIĘTAĆ ŻE technologia i nauka NIE ŻYJĄ W PRÓŻNI).

Siła ekosystemu LLM-owego tkwi w tym, że modele można pobierać:

(bardzo przyjazny UI z HuggingFace/HF)

… i uruchamiać (wnioskowanie) lokalnie za darmo i bardzo łatwo:

bielik, Pan Tadeusz

(Nasz polski LLM 🤍 ♥ Bielik 🤍 ♥ opowiada co wie o “Panu Tadeuszu” 😅 )

Z drugiej strony, słabość ekosystemu tkwi w tym, że modele otwarte są nieporównywalnie słabsze niż te, w których trenowanie giganty technologiczne inwestują miliardy dolarów (nie przesadzając), dopuszczając się przy tym wątpliwych etycznie praktyk (to temat na inną rozmowę 😅).

I tu też jest lekcja dla nas, programistów. W świecie AI i w świecie software’u działa ta sama zasada: rozumienie kosztu i kompromisu. W Developerze Jutra pokazujemy, jak podejmować decyzje projektowe nie na bazie mody, tylko świadomości – gdzie coś warto robić „open”, a gdzie lepiej zainwestować w jakość.

W następnym odcinku przyjrzymy się, dlaczego RAG jest fundamentem oraz o co chodzi w knowledge cutoff – a także jak zarządzać KONTEKSTEM, żeby nie przepalać tokenów jak głupi. 🤪

Zobacz również