Tip
\nChcesz uruchomić ten kod samemu? Wszystkie przykłady z tego posta znajdziesz w gotowym notatniku Jupyter: jak-komputer-czyta-tekst.ipynb
\nW dwóch poprzednich wpisach zbudowaliśmy sobie solidny fundament. W pierwszym rozłożyliśmy język na czynniki pierwsze - fonetyka, morfologia, składnia, semantyka, pragmatyka. W drugim zapytaliśmy: "OK, ale czy LLM w ogóle rozumie to, co generuje?" i doszliśmy do wniosku, że LLM jest maszyną znaków, nie umysłem.
\nAle zostało mi jedno fundamentalne pytanie, na które nie odpowiedziałem: jak komputer w ogóle "bierze" tekst do środka?
\nBo przecież komputer nie widzi liter. Nie widzi słów. Komputer widzi liczby. Więc jak to się dzieje, że wpisujesz "Kot siedzi na macie" i ChatGPT jakoś to przetwarza? Jaka jest droga od tekstu do liczby, od liczby do "rozumienia"?
\nTa droga to fascynująca historia ewolucji - od najprostszego liczenia słów, przez coraz sprytniejsze triki matematyczne, aż po wektory, które potrafią uchwycić podobieństwa znaczeniowe. Każdy krok na tej drodze był odpowiedzią na ograniczenia poprzedniego.
\nTo jest trzeci wpis z serii "zrozumiec LLM". Dzisiaj zmieniamy perspektywę z lingwistycznej i filozoficznej na techniczną. Ale bez obaw - dalej będzie dużo przykładów, dużo "aha!" i zero wzorów, których nie da się zrozumieć ;-)
\ngraph LR\n T["✂️ Tokenizacja<br/><i>tniemy tekst</i>"] --> B["🔢 BoW / TF-IDF<br/><i>liczymy słowa</i>"]\n B --> N["🔗 N-gramy / Markow<br/><i>dodajemy kontekst</i>"]\n N --> NB["📊 Bayes<br/><i>klasyfikujemy</i>"]\n NB --> W["📐 Word2Vec<br/><i>wektory znaczeń</i>"]\n \n style T fill:#ff9999,color:#000\n style B fill:#ffcc99,color:#000\n style N fill:#ffff99,color:#000\n style NB fill:#ccff99,color:#000\n style W fill:#99ccff,color:#000\nNarracja tego wpisu: "Najpierw tniesz tekst na kawałki, potem liczysz, potem rozumiesz." Proste? Zobaczymy ;-) Zaczynamy od cięcia.
\nWyobraźcie sobie, że jesteście komputerem. Ktoś wam pokazuje tekst:
\n\n\n"Ala ma kota."
\n
Co widzicie? Literki? Słowa? Nie. Widzicie ciąg bajtów: 65 6c 61 20 6d 61 20 6b 6f 74 61 2e. Zero pojęcia, gdzie zaczyna się jedno słowo, a kończy drugie. Zero pojęcia, że "kot" to zwierzak, a nie trzy losowe znaki.
Żeby komputer cokolwiek mógł zrobić z tekstem, musi go najpierw pociąć na kawałki. I ten proces nazywa się tokenizacją.
\nTokenizacja to krok zerowy. Bez niej nie ma TF-IDF, nie ma n-gramów, nie ma embeddingów, nie ma LLM. Wszystko zaczyna się od cięcia.
\nNajprostszy pomysł: dzielimy tekst po spacjach.
\n"Ala ma kota." → ["Ala", "ma", "kota."]\nZauważyliście? "kota." ma kropkę przyklejoną. To nie jest słowo "kot" w dopełniaczu - to jest słowo "kota" z interpunkcją. A co z takimi tekstami:
\nKrótko: cięcie po spacjach nie działa. Świat jest za skomplikowany na tak proste reguły.
\nW pierwszym poście poznaliśmy morfemy - najmniejsze jednostki znaczące. "Nieszczęśliwy" to trzy morfemy: "nie-szczęśliw-y". A teraz uwaga: token to nie to samo co morfem.
\ngraph LR\n subgraph "Lingwista widzi:"\n A["nieszczęśliwy"] --> A1["nie + szczęśliw + y<br/><i>morfemy</i>"]\n end\n subgraph "GPT-4o widzi (tokeny BPE):"\n B["nieszczęśliwy"] --> B1["nie + -s + zcz + ę + śli + wy"]\n end\n \n style A1 fill:#99ff99,color:#000\n style B1 fill:#ff9999,color:#000\nToken to po prostu kawałek tekstu wyznaczony przez tokenizator. Może być całym słowem, może być częścią słowa, może być pojedynczym znakiem. Zależy od algorytmu.
\nNote
\nTrzy poziomy cięcia tekstu:
\nI tu wchodzi BPE (Byte Pair Encoding) - najpopularniejszy algorytm tokenizacji, używany przez GPT-2, GPT-3, GPT-4, Llama, i wiele innych modeli.
\nIdeę BPE można sprowadzić do jednego zdania: szukamy najczęstszej pary znaków i łączymy ją w jeden token. I powtarzamy.
\nBrzmi prosto? Bo jest proste ;-) Zobaczmy to na przykładzie.
\nMamy mały korpus z pięcioma polskimi słowami i ich częstotliwościami:
\n"las" ×10 "lak" ×5 "lat" ×12\n"bat" ×4 "lasy" ×5\n("las" = las, "lak" = lak do pieczęci, "lat" = lat (od "rok"), "bat" = bicz, "lasy" = po prostu lasy)
\nKrok 0: Dzielimy wszystko na pojedyncze znaki:
\nl a s ×10 l a k ×5 l a t ×12\nb a t ×4 l a s y ×5\nNasz początkowy słownik to: ["a", "b", "k", "l", "s", "t", "y"] - po prostu wszystkie unikalne znaki.
Krok 1: Znajdujemy najczęstszą parę sąsiadujących znaków:
\nŁączymy (l, a) → "la". Nasz słownik rośnie o jeden token:
\nSłownik: ["a", "b", "k", "l", "s", "t", "y", "la"]\n\nla s ×10 la k ×5 la t ×12\nb a t ×4 la s y ×5\nKrok 2: Znowu szukamy najczęstszej pary:
\nŁączymy (la, s) → "las":
\nSłownik: ["a", "b", "k", "l", "s", "t", "y", "la", "las"]\n\nlas ×10 la k ×5 la t ×12\nb a t ×4 las y ×5\nKrok 3: Najczęstsza para to teraz (la, t) = 12 razy. Łączymy → "lat":
\nSłownik: [..., "la", "las", "lat"]\n\nlas ×10 la k ×5 lat ×12\nb a t ×4 las y ×5\nKrok 4: Najczęstsza para to (la, k) = 5 razy. Łączymy → "lak":
\nSłownik: [..., "la", "las", "lat", "lak"]\n\nlas ×10 lak ×5 lat ×12\nb a t ×4 las y ×5\nKrok 5: Najczęstsza para to (las, y) = 5 razy. Łączymy → "lasy":
\nSłownik: [..., "la", "las", "lat", "lak", "lasy"]\n\nlas ×10 lak ×5 lat ×12\nb a t ×4 lasy ×5\nI tak dalej, aż osiągniemy docelowy rozmiar słownika. W prawdziwych modelach:
\nTo ważne pytanie, bo odpowiedź brzmi: zawsze. Na obu etapach.
\ngraph LR\n subgraph "TRENING"\n TC["📚 Korpus treningowy"] --> TT["✂️ Tokenizer"] --> TI["🔢 Token IDs"]\n TI --> TM["🧠 Trenujesz model"]\n end\n subgraph "PROMPTOWANIE (inferencja)"\n PC["💬 Twój prompt"] --> PT["✂️ Tokenizer"] --> PI["🔢 Token IDs"]\n PI --> PM["🤖 Model generuje"] --> PO["🔢 Nowe token IDs"]\n PO --> PD["📤 Decoder"] --> PF["💬 Odpowiedź"]\n end\n \n TT -.->|"ten sam!"| PT\n style TT fill:#ff9999,color:#000\n style PT fill:#ff9999,color:#000\nTrening: najpierw trenujesz tokenizer na ogromnym korpusie (uczy się, które pary scalać). Potem tokenizujesz CAŁY korpus treningowy na ID-ki. Model uczy się na tych ID-kach.
\nPromptowanie: kiedy piszesz do ChatGPT, twój tekst przechodzi przez ten SAM tokenizer → ID-ki → model generuje nowe ID-ki → decoder zamienia z powrotem na tekst.
\nKluczowe: tokenizer jest trenowany osobno, przed modelem. Potem jest "zamrożony" - nie zmienia się już nigdy. GPT-2 ma swój tokenizer (słownik 50K), GPT-4 ma swój (słownik 100K). I to jest powód, dla którego polski jest cięty gorzej w GPT-2 - bo tokenizer GPT-2 był trenowany głównie na angielskim, więc mało polskich ciągów znaków zostało scalonych. Model sam mógłby "rozumieć" polski lepiej, ale tokenizer już mu pociął tekst na drobne kawałki.
\nTip
\nEksperyment dla was: Wejdźcie na tiktokenizer.vercel.app, wpiszcie jakiś tekst po polsku i zobaczcie, jak model GPT-2 tnie go na tokeny. Zobaczycie, że polskie znaki (ą, ę, ł, ś, ć) często zajmują po 2-3 tokeny! Bo GPT-2 był trenowany głównie na angielskim, więc polski jest dla niego "egzotyczny".
\nKluczowa rzecz: każdy model ma swój własny tokenizator. Ten sam tekst może być pocięty zupełnie inaczej:
\nimport tiktoken \n\ntext = "Nieprawdopodobnie szczęśliwy" \n\ngpt2 = tiktoken .get_encoding ("gpt2" )\ngpt4 = tiktoken .get_encoding ("cl100k_base" )\n\nprint ("GPT-2:" , gpt2 .encode (text ))\nprint ("GPT-4:" , gpt4 .encode (text ))\n\nprint ("GPT-2:" , [gpt2 .decode ([t ]) for t in gpt2 .encode (text )])\nprint ("GPT-4:" , [gpt4 .decode ([t ]) for t in gpt4 .encode (text )])GPT-2 prawdopodobnie potnie polski tekst na mnóstwo małych fragmentów (bo nie "zna" polskiego dobrze), a GPT-4 zrobi to o wiele efektywniej (bo widział więcej polskiego tekstu).
\ngraph TD\n subgraph "GPT-2 (angielski BPE):"\n G2["Nieprawdopodobnie szczęśliwy"] --> G2T["N + ie + p + raw + d + op + od + ob + nie + s + z + cz + ⍰ + ⍰ + ⍰ + ⍰ + li + wy<br/><i>18 tokenów!</i>"]\n end\n subgraph "GPT-4o (multilingual BPE):"\n G4["Nieprawdopodobnie szczęśliwy"] --> G4T["Nie + p + rawd + op + odob + nie + szcz + ę + śli + wy<br/><i>10 tokenów</i>"]\n end\n subgraph "Polish RoBERTa (polski SentencePiece):"\n PR["Nieprawdopodobnie szczęśliwy"] --> PRT["Nie + prawdopodobnie + szczęśliwy<br/><i>3 tokeny!</i>"]\n end\n \n style G2T fill:#ff9999,color:#000\n style G4T fill:#ffcc99,color:#000\n style PRT fill:#99ff99,color:#000\nIstnieją modele trenowane specjalnie na polskim tekście - i ich tokenizatory tną polski znacznie lepiej:
\nfrom transformers import AutoTokenizer \n\ntext = "Nieprawdopodobnie szczęśliwy" \n\nherbert = AutoTokenizer .from_pretrained ("allegro/herbert-base-cased" )\nprint ("HerBERT (Allegro, polski WordPiece):" , herbert .tokenize (text ))\n\nroberta = AutoTokenizer .from_pretrained ("sdadas/polish-roberta-base-v2" )\nprint ("Polish RoBERTa (polski SentencePiece):" , roberta .tokenize (text ))HerBERT (Allegro, polski WordPiece): ['Nie', 'prawdopodobnie</w>', 'szczęśliwy</w>'] → 3 tokeny\nPolish RoBERTa (polski SentencePiece): ['▁Nie', 'prawdopodobnie', '▁szczęśliwy'] → 3 tokeny\nTrzy tokeny! "prawdopodobnie" i "szczęśliwy" to dla polskiego tokenizera pojedyncze tokeny. Bo ten tokenizer "widział" te słowa na polskim korpusie tyle razy, że scalił je w całe jednostki.
\nDwa polskie tokenizery, które warto znać:
\n| Tokenizer | \nTwórca | \nAlgorytm | \nZaimplementowany w | \n
|---|---|---|---|
| HerBERT | \nAllegro | \nWordPiece | \npolski BERT na KGR10 korpusie | \n
| Polish RoBERTa | \nsdadas | \nSentencePiece (Unigram) | \npolski RoBERTa na dużym korpusie | \n
Note
\nDlaczego polskie modele tną lepiej? Bo ich tokenizery były trenowane na polskim tekście. "prawdopodobnie" występowało w polskim korpusie tysiące razy, więc BPE/SentencePiece scalił je w jeden token. GPT-2 widział głównie angielski, więc "prawdopodobnie" mu się nie scaliło - i tnie je na kawałki. To jest też powód, dla którego GPT-4o (trenowany na dużo bardziej wielojęzycznym korpusie) tnie polski lepiej niż GPT-2 - ale nadal gorzej niż typowo polskie modele.
\nSkoro już rozumiemy, jak BPE działa, spróbujmy wytrenować własny tokenizer na polskim tekście. Użyjemy biblioteki tokenizers od HuggingFace (nie mylić z tiktoken):
from tokenizers import Tokenizer \nfrom tokenizers .models import BPE \nfrom tokenizers .trainers import BpeTrainer \nfrom tokenizers .pre_tokenizers import Whitespace \n\ntokenizer = Tokenizer (BPE (unk_token = "[UNK]" ))\ntokenizer .pre_tokenizer = Whitespace ()\n\ntrainer = BpeTrainer (vocab_size = 300 , special_tokens = ["[UNK]" ])\n\ncorpus = [\n "Ala ma kota i psa" ,\n "Kot siedzi na macie" ,\n "Pies biega po parku" ,\n "Ala ma kota i kota i jeszcze raz kota" ,\n "Kot lubi mleko i kot lubi spać" ,\n "Pies lubi biegać po parku i gonić kota" ,\n "Szczęśliwy kot to kot który ma dużo mleka" ,\n "Nieprawdopodobnie szczęśliwy pies biega po parku" ,\n "Szczęśliwy Ala ma kota i psa i szczęśliwy dom" ,\n "Dom to miejsce gdzie mieszka szczęśliwa rodzina" ,\n]\n\ntokenizer .train_from_iterator (corpus , trainer )\nprint (f"Rozmiar słownika: { tokenizer . get_vocab_size () } " )\n\ntest = "Nieprawdopodobnie szczęśliwy" \nencoding = tokenizer .encode (test )\nprint (f'" { test } " → { encoding . tokens } ' )Rozmiar słownika: 130\n"Nieprawdopodobnie szczęśliwy" → ['Nieprawdopodobnie', 'szczęśliwy']\nDwa tokeny! Bo nasz mały korpus jest po polsku - i "Nieprawdopodobnie" oraz "szczęśliwy" wystąpiły wystarczająco często, żeby BPE scalił je w pojedyncze tokeny.
\nAle chwila - co właściwie znaczą te parametry w kodzie?
\n| Parametr | \nCo robi | \nPrzykład | \n
|---|---|---|
vocab_size | \nMaksymalna liczba tokenów w słowniku. BPE będzie scalał pary, aż słownik osiągnie ten rozmiar. Im większy, tym dłuższe tokeny (całe słowa). Im mniejszy, tym mniejsze kawałki (pojedyncze litery). | \nGPT-2: 50 257, nasz: 300 | \n
special_tokens | \nTokeny o specjalnym znaczeniu dla modelu. Zawsze są w słowniku, niezależnie od treningu. | \n[UNK], <PAD>, <S> (start), </S> (koniec) | \n
unk_token | \nToken "nieznany" - zastępuje każdy znak, którego tokenizer nie potrafi rozpoznać. Np. jeśli w tekście pojawi się emoji, a tokenizer nie ma go w słowniku, wstawi [UNK]. | \n[UNK] = "nie wiem co to jest" | \n
Prosta analogia: vocab_size to grubość waszego słownika - ile haseł się w nim zmieści. unk_token to hasło oznaczające "nie ma takiego słowa". A special_tokens to "strony zarezerwowane" - zawsze są w słowniku, niezależnie od tego, czego nauczysz tokenizer.
Tip
\nEksperyment: Skopiujcie ten kod, zmieńcie vocab_size na np. 50 i zobaczcie, co się stanie. Zobaczycie, że przy mniejszym słowniku tokenizer tnie słowa na mniejsze kawałki - bo ma mniej "miejsca" na scalenia. To jest dokładnie to, o czym mówiliśmy: rozmiar słownika to hiperparametr, i to od niego zależy, jak drobno tekst jest cięty.
Warning
\nDlaczego to ma znaczenie? Bo LLM ma limit tokenów w oknie kontekstowym. GPT-3 ma 4K tokenów, GPT-4 Turbo ma 128K. Ale "token" to nie "słowo"! W angielskim ~1 token ≈ 0.75 słowa. W polskim, zwłaszcza z GPT-2, to może być ~1 token ≈ 0.4 słowa. Czyli polski tekst "zjada" więcej tokenów i szybciej wyczerpuje limit.
\nBPE to nie jedyny gracz w mieście. Oto krótkie zestawienie:
\n| Algorytm | \nKto używa | \nJak działa | \nKluczowa różnica | \n
|---|---|---|---|
| BPE | \nGPT, Llama, many others | \nScala najczęstszą parę | \nProsty, od dołu | \n
| WordPiece | \nBERT, DistilBERT, Electra | \nScala parę z najwyższym "score" | \nScore = freq(pary) / (freq(a) × freq(b)) | \n
| Unigram | \nT5, Pegasus, ALBERT | \nZaczyna od dużego słownika, usuwa najmniej przydatne | \nProbabilistyczny, może dawać różne tokenizacje | \n
| SentencePiece | \nWielojęzyczne modele | \nBPE lub Unigram na surowym tekście (nawet bez spacji!) | \nDziała z językami bez spacji (chiński, japoński) | \n
Różnica między BPE a WordPiece jest subtelna: BPE scala po prostu najczęstszą parę. WordPiece scala parę, która jest najbardziej zaskakująca - czyli występuje razem częściej niż by wynikało z częstotliwości poszczególnych elementów. To trochę jak związek, który jest "bardziej niż suma części" ;-)
\nNote
\nNawiązanie do posta 1: Pamiętacie, jak mówiliśmy, że polska morfologia to koszmar dla LLM? 7 przypadków, fleksja, mnóstwo końcówek... No to teraz widzicie dlaczego. Tokenizator nie "wie", że "domu", "domowi", "domem" to odmiany tego samego słowa. Dla niego to po prostu różne sekwencje znaków. To "zrozumienie" relacji między formami - tego model musi się nauczyć sam, w trakcie treningu.
\nMamy nasze scalenia z powyższego przykładu: l+a→la, la+s→las, la+t→lat, la+k→lak, las+y→lasy. Jak BPE podzieli te nowe słowa?
\nOK, mamy tokeny. Ale skąd tokenizator wie, które pary znaków scalać? Z korpusu! BPE uczy się najczęstszych połączeń z tekstu. I żeby zrobić cokolwiek z tokenami - policzyć je, znaleźć wzorce, wytrenować model - też potrzebujemy korpusu.
\nKorpus to po prostu zbiór tekstów. Może to być:
\nKażdy pojedynczy tekst w korpusie nazywamy dokumentem. Proste?
\ngraph TD\n C["📚 KORPUS<br/><i>zbiór dokumentów</i>"] --> D1["📄 Dokument 1<br/>Ten film jest świetny"]\n C --> D2["📄 Dokument 2<br/>Ten film jest beznadziejny"]\n C --> D3["📄 Dokument 3<br/>Świetna książka, polecam"]\n \n style C fill:#9999ff,color:#fff\n style D1 fill:#ffcc99,color:#000\n style D2 fill:#ffcc99,color:#000\n style D3 fill:#ffcc99,color:#000\nI to są właśnie zbiory danych, na których trenuje się prawdziwe modele - i tokenizery, i same modele:
\n| Korpus | \nCo zawiera | \nRozmiar | \nCiekawostka | \n
|---|---|---|---|
| Wikitext | \nArtykuły z Wikipedii (angielskiej) | \n~500 MB | \nStandardowy benchmark do ewaluacji modeli językowych | \n
| Wiki-40B | \nWikipedia w 59 językach (w tym polskim!) | \n~40 GB | \nPierwszy krok wielu modeli wielojęzycznych | \n
| EuroParl | \nTranskrypcje z parlamentu UE (21 języków) | \n~2 GB | \nWysokiej jakości teksty oficjalne, świetny do tłumaczeń | \n
| Common Crawl | \nZrzuty treści ze stron internetowych | \npetabajty (PB!) | \nNajwiększy publicznie dostępny korpus webowy. Większość LLM-ów z niego korzysta | \n
| OpenWebText | \nKopia linków z Reddita z >3 punktami oceny | \n~38 GB | \nZ niego trenowano GPT-2. Filtrowana "jakość" z Reddita | \n
| The Pile | \nMix 22 źródeł (arXiv, GitHub, Wikipedia, książki...) | \n~825 GB | \nStworzony przez EleutherAI jako zbiór "do wszystkiego" | \n
| RedPajama | \nOtwarta replika danych treningowych LLaMA | \n~1.2 TB | \nTo dlatego LLaMA jest tak dobra - trenowana na ogromnym, różnorodnym zbiorze | \n
| OSCAR | \nZrzuty z internetu, filtrowane po językach | \n~6.5 TB | \nMa osobne podzbiory dla każdego języka, w tym polski OSCAR | \n
A polskie korpusy? Oto najważniejsze:
\ngraph LR\n subgraph "Skąd biorą się dane treningowe LLM"\n CC["🌐 Common Crawl<br/><i>petabajty z internetu</i>"] --> MIX\n WP["📚 Wikipedia<br/><i>49 GB, 59 języków</i>"] --> MIX\n GH["💻 GitHub<br/><i>kod źródłowy</i>"] --> MIX\n BK["📖 Książki<br/><i>Project Gutenberg etc.</i>"] --> MIX\n AX["📄 ArXiv<br/><i>publikacje naukowe</i>"] --> MIX\n \n MIX["🧹 Filtrowanie<br/><i>usuwanie spamu, duplikatów</i>"] --> CORPUS["📊 Czysty korpus<br/><i>setki GB - TB</i>"]\n CORPUS --> TOK["✂️ Trening tokenizera"]\n CORPUS --> LLM["🧠 Trening modelu"]\n end\n \n style CC fill:#ff9999,color:#000\n style MIX fill:#ffff99,color:#000\n style CORPUS fill:#99ff99,color:#000\n style TOK fill:#ffcc99,color:#000\n style LLM fill:#9999ff,color:#fff\nKluczowa obserwacja: ten sam korpus służy do trenowania tokenizera i modelu. Najpierw trenujesz tokenizer na korpusie (uczy się, które pary znaków scalać), potem tokenizujesz cały korpus za pomocą tego tokenizera, i na tych tokenach trenujesz model.
\nNote
\nDlaczego to jest ważne? Jeśli twój korpus ma mało polskiego tekstu (np. GPT-2 trenowany głównie na angielskim), to tokenizer nie scali polskich słów, a model nie nauczy się polskiego dobrze. Dlatego polskie modele (HerBERT, Polish RoBERTa) używają korpusów z dużą ilością polskiego tekstu - np. NKJP + polski OSCAR + polską Wikipedię.
\nMamy korpus. Teraz chcemy zamienić każdy dokument na liczby, żeby komputer mógł z tym coś zrobić.
\nNajprostszy sposób: Bag-of-Words (BoW) - torba słów. Liczymy, ile razy każde słowo występuje w dokumencie.
\nPrzykład. Mamy trzy krótkie recenzje filmu:
\nDokument 1: "Ten film jest świetny"\nDokument 2: "Ten film jest beznadziejny"\nDokument 3: "Świetny film polecam"\nBudujemy słownik wszystkich unikalnych słów:
\n{ten, film, jest, świetny, beznadziejny, polecam}\nI teraz każdy dokument zamieniamy na wektor zliczeń:
\n| \n | ten | \nfilm | \njest | \nświetny | \nbeznadziejny | \npolecam | \n
|---|---|---|---|---|---|---|
| Dok 1 | \n1 | \n1 | \n1 | \n1 | \n0 | \n0 | \n
| Dok 2 | \n1 | \n1 | \n1 | \n0 | \n1 | \n0 | \n
| Dok 3 | \n0 | \n1 | \n0 | \n1 | \n0 | \n1 | \n
Każdy dokument to teraz po prostu ciąg liczb. Komputer jest happy.
\nAle my nie do końca ;-) Bo zauważcie problem:
\n\n\nDokument 1: "Ten film jest świetny" → [1, 1, 1, 1, 0, 0]
\n
\nDokument 2: "Ten film jest beznadziejny" → [1, 1, 1, 0, 1, 0]
Te wektory są prawie identyczne! Różnią się na jednej pozycji. A przecież jeden mówi "świetny", a drugi "beznadziejny" - zupełnie inne znaczenie.
\nI jest drugi problem: "Dog bites man" i "Man bites dog" dadzą dokładnie ten sam wektor BoW. BoW kompletnie ignoruje kolejność słów.
\nNote
\nDlaczego po polsku to nie działa tak samo? Bo polski ma przypadki! "Pies gryzie człowieka" i "Człowiek gryzie psa" to dla BoW różne zdania - bo "pies" ≠ "psa" i "człowieka" ≠ "człowiek". To są inne słowa. Angielski nie ma przypadków, więc "dog" to zawsze "dog" niezależnie od roli w zdaniu - i dlatego BoW nie odróżnia "dog bites man" od "man bites dog". To jest właśnie ta polska morfologia z pierwszego posta, która czasem nam pomaga, a czasem przeszkadza ;-)
\nWarning
\nBag-of-Words w pigułce:
\nfrom sklearn .feature_extraction .text import CountVectorizer \nimport pandas as pd \n\ncorpus = [\n "Ten film jest świetny" ,\n "Ten film jest beznadziejny" ,\n "Świetny film polecam" ,\n]\n\nvectorizer = CountVectorizer ()\nX = vectorizer .fit_transform (corpus )\n\ndf = pd .DataFrame (\n X .toarray (),\n columns = vectorizer .get_feature_names_out (),\n index = ["Dok 1" , "Dok 2" , "Dok 3" ]\n)\nprint (df )Wynik:
\n beznadziejny film jest polecam świetny ten\nDok 1 0 1 1 0 1 1\nDok 2 1 1 1 0 0 1\nDok 3 0 1 0 1 1 0\nDokładnie ta sama tabela, co wyżej - tylko teraz wygenerowana przez kod. Zauważcie: "film" jest wszędzie (wartość 1 w każdym wierszu), a "beznadziejny" tylko w Dokumencie 2. To jest cała magia BoW - proste zliczanie.
\nImportant
\nCzy BoW potrafi generować nowe teksty? Nie. BoW to tylko sposób reprezentacji tekstu (tekst → liczby). Służy do analizy, porównywania i klasyfikacji dokumentów, ale nie generuje nic nowego. Nie przewiduje też, jakie słowo powinno pojść po "Kot siedzi na...". Żeby generować tekst, potrzebujemy czegoś, co rozumie kolejność słów i potrafi przewidywać następne. I to jest dokładnie to, do czego dochodzimy za chwilę przy n-gramach i łańcuchach Markowa ;-)
\nBoW traktuje każde słowo tak samo. Ale przecież nie każde słowo jest tak samo ważne!
\nSłowo "jest" występuje w niemal każdym polskim zdaniu. Słowo "semiotyka" - raczej rzadko. Które jest bardziej informatywne? Oczywiście "semiotyka" - bo jeśli widzisz to słowo w dokumencie, to dużo więcej mówi ci o jego treści niż "jest".
\nTF-IDF (Term Frequency - Inverse Document Frequency) to sposób, żeby to uchwycić.
\nPrzypomnijmy nasz korpus - trzy krótkie recenzje filmu:
\nDokument 1: "Ten film jest świetny" (4 słowa)\nDokument 2: "Ten film jest beznadziejny" (4 słowa)\nDokument 3: "Świetny film polecam" (3 słowa)\nPoliczmy TF-IDF dla słowa "świetny" w Dokumencie 1:
\nTF (Term Frequency) - jak często słowo występuje w jednym dokumencie:
\nTF("świetny", Dokument 1) = 1 / 4 = 0.25\n(1 wystąpienie w 4-słowowym dokumencie)
\nIDF (Inverse Document Frequency) - jak "rzadkie" jest słowo w całym korpusie:
\nIDF("świetny") = log(3 / 2) = 0.176\n(3 dokumenty w korpusie, 2 z nich zawierają "świetny")
\nTF-IDF = TF × IDF:
\nTF-IDF("świetny", Dokument 1) = 0.25 × 0.176 = 0.044\nA słowo "jest", które jest WSZĘDZIE?
\nIDF("jest") = log(3 / 2) = 0.176 (też w 2 z 3 dokumentów)\nIDF("film") = log(3 / 3) = 0 (we WSZYSTKICH dokumentach!)\n"Film" dostaje zero w IDF! Bo jeśli słowo jest w każdym dokumencie, to nie wnosi żadnej informacji, która pomogłaby odróżnić jeden dokument od drugiego.
\nTip
\nIntuicja za TF-IDF w jednym zdaniu: Słowo jest ważne dla danego dokumentu, jeśli często tam występuje (wysokie TF), ale rzadko w innych dokumentach (wysokie IDF). Czyli: "Czy jesteś wyjątkowy?"
\nSpróbujcie sami. Oto kompletny przykład w Pythonie:
\nfrom sklearn .feature_extraction .text import TfidfVectorizer \nimport pandas as pd \n\ncorpus = [\n "Ten film jest świetny" ,\n "Ten film jest beznadziejny" ,\n "Świetny film polecam" ,\n]\n\nvectorizer = TfidfVectorizer ()\ntfidf_matrix = vectorizer .fit_transform (corpus )\n\ndf = pd .DataFrame (\n tfidf_matrix .toarray (),\n columns = vectorizer .get_feature_names_out (),\n index = ["Dok 1" , "Dok 2" , "Dok 3" ]\n)\nprint (df .round (2 ))Wynik będzie wyglądał mniej więcej tak:
\n beznadziejny film jest polecam świetny ten\nDok 1 0.00 0.37 0.49 0.00 0.37 0.49\nDok 2 0.58 0.35 0.46 0.00 0.00 0.46\nDok 3 0.00 0.41 0.00 0.54 0.41 0.00\nZauważcie: "film" ma niskie wartości wszędzie (bo jest wszędzie). "beznadziejny" ma wysoką wartość tylko w Dokumencie 2 (bo tylko tam występuje). TF-IDF działa!
\nTip
\nEksperyment dla was: Pomyślcie o waszych notatkach ze studiów (albo z pracy). Jakie słowa miałyby wysokie TF-IDF? Prawdopodobnie terminy fachowe - "rekurencja", "entropy", "backpropagation". A jakie miałyby niskie? "I", "jest", "na", "że" - bo są wszędzie.
\nTF-IDF ma jedno super praktyczne zastosowanie: przeszukiwanie tekstu. To jest właściwie to, jak działały pierwsze wyszukiwarki internetowe.
\nIdea jest prosta: zamieniasz zapytanie użytkownika na wektor TF-IDF, i szukasz dokumentu, którego wektor jest do niego najbardziej podobny (tzw. podobieństwo kosinusowe).
\nfrom sklearn .feature_extraction .text import TfidfVectorizer \nfrom sklearn .metrics .pairwise import cosine_similarity \nimport numpy as np \n\ncorpus = [\n "Ten film jest świetny" ,\n "Ten film jest beznadziejny" ,\n "Świetny film polecam" ,\n]\n\nvectorizer = TfidfVectorizer ()\ntfidf_matrix = vectorizer .fit_transform (corpus )\n\nquery = "świetny film" \nquery_vec = vectorizer .transform ([query ])\n\nsimilarities = cosine_similarity (query_vec , tfidf_matrix )[0 ]\nranked = sorted (zip (corpus , similarities ), key = lambda x : - x [1 ])\nfor i , (doc , sim ) in enumerate (ranked , 1 ):\n print (f' { i } . " { doc } " → { sim :.3f } ' )Zapytanie: "świetny film"\n\n1. "Świetny film polecam" → 0.694 ← najlepszy wynik!\n2. "Ten film jest świetny" → 0.667\n3. "Ten film jest beznadziejny" → 0.229\nDokument 3 wygrywa - bo "świetny" i "film" to dla niego słowa-klucze o wysokim TF-IDF. Dokument 2 ma "film", ale nie ma "świetny" - więc jego podobieństwo jest niskie.
\nNote
\nPodobieństwo kosinusowe mierzy kąt między dwoma wektorami. Jeśli wektory wskazują w tym samym kierunku (podobne proporcje słów) - podobieństwo jest bliskie 1. Jeśli w przeciwnych - bliskie 0. Nie przejmujcie się matematyką - intuicja jest prosta: "jak bardzo te dwa wektory są do siebie podobne?"
\nTF-IDF jest lepszy niż czysty BoW, bo przynajmniej waży słowa według ważności. Ale nadal traktuje każde słowo osobno. Nie wie, że "nie" + "lubię" = coś zupełnie innego niż "lubię" samo.
\nAlbo przykład z angielskiego, który świetnie pokazuje problem:
\nSame słowa są te same! Ale kolejność zmienia wszystko. BoW i TF-IDF tego nie widzą.
\nN-gram to po prostu ciąg N kolejnych elementów (zwykle słów albo znaków).
\nPrzykład ze zdaniem "Ala ma kota":
\n| Typ | \nN | \nWynik | \n
|---|---|---|
| Unigramy | \n1 | \nAla, ma, kota | \n
| Bigramy | \n2 | \nAla ma, ma kota | \n
| Trigramy | \n3 | \nAla ma kota | \n
I teraz magia: zamiast liczyć pojedyncze słowa, liczymy pary słów (bigramy). I nagle:
\nMożna też łączyć n-gramy z TF-IDF! W sklearn wystarczy zmienić jeden parametr:
\nfrom sklearn .feature_extraction .text import TfidfVectorizer \nimport pandas as pd \n\ncorpus = [\n "Ten film jest świetny" ,\n "Ten film jest beznadziejny" ,\n "Świetny film polecam" ,\n]\n\nvectorizer = TfidfVectorizer (ngram_range = (1 , 2 ))\ntfidf_matrix = vectorizer .fit_transform (corpus )\n\ndf = pd .DataFrame (\n tfidf_matrix .toarray (),\n columns = vectorizer .get_feature_names_out (),\n index = ["Dok 1" , "Dok 2" , "Dok 3" ]\n)\nprint (df .round (2 )) beznadziejny film film jest film polecam jest jest beznadziejny jest świetny polecam ten ten film świetny świetny film\nDok 1 0.00 0.29 0.37 0.0 0.37 0.00 0.49 0.0 0.37 0.37 0.37 0.0\nDok 2 0.46 0.27 0.35 0.0 0.35 0.46 0.00 0.0 0.35 0.35 0.00 0.0\nDok 3 0.00 0.30 0.00 0.5 0.00 0.00 0.00 0.5 0.00 0.00 0.38 0.5\nZobaczcie, co się stało - słownik cech urósł! Oprócz pojedynczych słów ("film", "jest", "świetny") mamy teraz pary: "film jest", "jest świetny", "jest beznadziejny", "świetny film", "ten film", "film polecam". Każda para to osobna kolumna z własnym TF-IDF.
\nDzięki temu model widzi, że "jest świetny" (Dok 1) i "jest beznadziejny" (Dok 2) to różne rzeczy - bo to różne bigramy z różnymi wartościami TF-IDF.
\nNote
\nN-gramy to kompromis. Im większe N, tym więcej kontekstu łapiesz, ale tym więcej danych potrzebujesz. Z trigramami masz 3× więcej kombinacji niż z unigramami. Z 4-gramami - jeszcze więcej. I szybko dochodzisz do momentu, gdzie większość n-gramów występuje w korpusie tylko raz, co nie jest przydatne.
\nSame n-gramy to tylko zliczenia - tak jak BoW, nie generują tekstu. Ale jeśli dodamy do nich prawdopodobieństwa przejść, nagle zyskujemy coś, co generuje nowy tekst.
\nPomysł jest prosty: dla każdego słowa patrzymy, jakie słowa najczęściej po nim następują. I wybieramy następne słowo probabilistycznie.
\nWeźmy mały korpus:
\n"ala ma kota ala ma psa kot lubi mleko ala lubi kota"\nLiczymy bigramy i prawdopodobieństwa przejść:
\n| Słowo | \nNastępne słowo | \nPrawdopodobieństwo | \n
|---|---|---|
| ala | \nma | \n2/3 = 67% | \n
| ala | \nlubi | \n1/3 = 33% | \n
| ma | \nkota | \n1/2 = 50% | \n
| ma | \npsa | \n1/2 = 50% | \n
| kot | \nlubi | \n1/1 = 100% | \n
| lubi | \nmleko | \n1/2 = 50% | \n
| lubi | \nkota | \n1/2 = 50% | \n
To jest właśnie łańcuch Markowa - model, w którym prawdopodobieństwo następnego stanu zależy tylko od obecnego stanu (albo kilku ostatnich).
\ngraph LR\n A["ala"] -->|"67%"| B["ma"]\n A -->|"33%"| L["lubi"]\n B -->|"50%"| E["kota"]\n B -->|"50%"| F["psa"]\n L -->|"50%"| M["mleko"]\n L -->|"50%"| E\n \n style A fill:#9999ff,color:#fff\n style B fill:#ffcc99,color:#000\n style E fill:#99ff99,color:#000\n"ala" → najczęściej "ma" (67%) → "kota" albo "psa" (po 50%). Czyli generujemy np.: "ala ma kota". Albo "ala ma psa". Albo "ala lubi kota". Wszystkie te zdania są "nowe" - nie wystąpiły jako całości w korpusie - ale model skleił je z prawdopodobieństw przejść.
\nZanim przejdziemy do kodu, prześledźmy cały proces na palcach. Mamy ten sam korpus:
\n"ala ma kota ala ma psa kot lubi mleko ala lubi kota"\nKrok 1: Budujemy słownik trigramów. Przesuwamy "okienko" o 3 słowa i patrzymy, co jest za nim:
\n| Okno (trigram) | \nNastępne słowo | \n
|---|---|
| ala ma kota | \nala | \n
| ma kota ala | \nma | \n
| kota ala ma | \npsa | \n
| ala ma psa | \nkot | \n
| ma psa kot | \nlubi | \n
| psa kot lubi | \nmleko | \n
| kot lubi mleko | \nala | \n
| lubi mleko ala | \nlubi | \n
| mleko ala lubi | \nkota | \n
Każdy trigram ma dokładnie jedno możliwe następne słowo (bo nasz korpus jest malutki).
\nKrok 2: Generujemy. Zaczynamy od trigramu startowego ("ala", "ma", "kota"):
Important
\nTen trigram startowy to nasz "prompt"! Tak samo jak w ChatGPT wpisujesz tekst i model kontynuuje - tu wpisujemy "ala ma kota" i generator dobiera kolejne słowa. Jedyna różnica to skala: ChatGPT ma kontekst na tysiące tokenów, a my na 3 słowa.
\nStart: ala ma kota\nKrok 1: ala ma kota [ala] ← po (ala,ma,kota) następuje "ala"\nKrok 2: ala ma kota ala [ma] ← po (ma,kota,ala) następuje "ma"\nKrok 3: ala ma kota ala ma [psa] ← po (kota,ala,ma) następuje "psa"\nKrok 4: ... ma psa [kot] ← po (ala,ma,psa) następuje "kot"\nKrok 5: ... psa kot [lubi] ← po (ma,psa,kot) następuje "lubi"\nKrok 6: ... kot lubi [mleko] ← po (psa,kot,lubi) następuje "mleko"\nKrok 7: ... lubi mleko [ala] ← po (kot,lubi,mleko) następuje "ala"\nKrok 8: ... mleko ala [lubi] ← po (lubi,mleko,ala) następuje "lubi"\nKrok 9: ... ala lubi [kota] ← po (mleko,ala,lubi) następuje "kota"\nKrok 10: STOP ← trigram (ala,lubi,kota) nie jest w słowniku\nWynik: "ala ma kota ala ma psa kot lubi mleko ala lubi kota" - dokładnie nasz korpus, tylko "przeklejony" od środka. Na większym korpusie wynik byłby inny za każdym razem.
Oto kompletny (i naprawdę krótki!) generator tekstu w Pythonie:
\nimport random \n\ncorpus = "ala ma kota ala ma psa kot lubi mleko ala lubi kota" \ntokens = corpus .split ()\n\ntrigrams = {}\nfor i in range (len (tokens ) - 3 ):\n key = (tokens [i ], tokens [i + 1 ], tokens [i + 2 ])\n next_word = tokens [i + 3 ]\n if key not in trigrams :\n trigrams [key ] = []\n trigrams [key ].append (next_word )\n\ncurrent = ("ala" , "ma" , "kota" ) # ← to jest nasz "prompt"! \noutput = list (current )\n\nfor _ in range (10 ):\n if tuple (output [- 3 :]) not in trigrams :\n break \n possibilities = trigrams [tuple (output [- 3 :])]\n output .append (random .choice (possibilities ))\n\nprint (" " .join (output ))Możliwy wynik: "ala ma kota ala ma psa kot lubi mleko ala ma kota ala ma psa"
Note
\nDlaczego za każdym razem wychodzi to samo? Bo nasz korpus jest tak mały, że większość trigramów ma tylko jedno możliwe następne słowo. random.choice nie ma z czego wybierać! Na większym korpusie (np. całej polskiej Wikipedii) ten sam kod generowałby za każdym razem inny tekst - bo prawie każdy trigram miałby kilka możliwych kontynuacji o różnych prawdopodobieństwach. I to jest właśnie moment, kiedy generowanie staje się interesujące.
Nic wielkiego, prawda? Ale to dlatego, że nasz korpus jest mikroskopijny. Na prawdziwym korpusie (np. całej Wikipedii) generator trigramowy potrafi produkować zdania, które brzmią sensownie, choć nie wystąpiły nigdy wcześniej.
\nImportant
\nŁańcuchy Markowa to pierwsze "modele językowe"! Przewidywanie następnego słowa na podstawie kontekstu - to jest DOKŁADNIE to, co robi ChatGPT. Oczywiście GPT używa o wiele bardziej zaawansowanej metody (Transformer + attention na tysiącach tokenów kontekstu), ale fundamentalna idea jest ta sama: prawdopodobieństwo następnego tokenu. LLM to potomek łańcuchów Markowa. Na sterydach ;-)
\nŁańcuchy Markowa są super do generowania tekstu. Ale w praktyce często chcemy coś innego: przypisać tekst do kategorii.
\nI tu wchodzi Naive Bayes - jeden z najprostszych, a zarazem najużyteczniejszych algorytmów klasyfikacji tekstu.
\nBez wzorów, samym przykładem:
\nWyobraźcie sobie, że idzie do was kolega i mówi: "Kaszlę." Jakie jest prawdopodobieństwo, że ma przeziębienie?
\nZależy! Jeśli jest listopad i wszyscy w biurze chorują - wysokie. Jeśli jest lipiec i kaszle raz - niskie.
\nTwierdzenie Bayesa to formalny sposób myślenia o takich sytuacjach: aktualizujemy naszą wiedzę na podstawie nowych dowodów.
\nA teraz przełóżmy to na tekst. Pytanie brzmi:
\n\n\n"Jeśli dokument zawiera słowo 'viagra', jakie jest prawdopodobieństwo, że to spam?"
\n
graph LR\n D["📧 Nowy mail:<br/>'Kup viagra tanio!'"] --> Q["P(spam | 'kup viagra tanio') = ?"]\n Q --> S["📊 P(spam) × P('kup'|spam) × P('viagra'|spam) × P('tanio'|spam)"]\n Q --> H["📊 P(nie-spam) × P('kup'|nie-spam) × P('viagra'|nie-spam) × P('tanio'|nie-spam)"]\n S --> C{"Które<br/>prawdopodobieństwo<br/>jest większe?"}\n H --> C\n C -->|Spam!| R["🗑️ SPAM"]\n \n style D fill:#ffcc99,color:#000\n style C fill:#9999ff,color:#fff\n style R fill:#ff9999,color:#000\nMamy mały zbiór maili:
\n| Treść | \nEtykieta | \n|
|---|---|---|
| 1 | \n"Kup viagra tanio teraz" | \nSpam | \n
| 2 | \n"Viagra darmowa oferta" | \nSpam | \n
| 3 | \n"Spotkanie jutro o 10" | \nNie-spam | \n
| 4 | \n"Prześlij mi raport jutro" | \nNie-spam | \n
Przychodzi nowy mail: "Viagra jutro spotkanie". Spam czy nie?
\nNaive Bayes liczy:
\nP(Spam | "viagra jutro spotkanie") ∝ 0.5 × 1.0 × 0.0 × ... = 0!
\nP(Nie-spam | "viagra jutro spotkanie") ∝ 0.5 × 0.0 × 1.0 × ... = 0!
\nUps. Obecność "jutro" (słowo z nie-spamu) wyzerowało spam, a obecność "viagra" (słowo spamowe) wyzerowało nie-spam. Ten konkretny mail jest trudny ;-)
\nW praktyce stosuje się tzw. Laplace smoothing (dodajemy 1 do każdego licznika), żeby uniknąć zerowania:
\nTeraz: P(Spam | mail) ∝ 0.5 × 0.214 × 0.048 × 0.048 ≈ 0.000246\nP(Nie-spam | mail) ∝ 0.5 × 0.048 × 0.143 × 0.143 ≈ 0.000490
\nNie-spam wygrywa! Bo "jutro" i "spotkanie" silnie wskazują na normalny mail.
\nBo zakładamy, że słowa są niezależne. Czyli: prawdopodobieństwo wystąpienia "viagra" nie zależy od tego, czy "tanie" też występuje. Oczywiście to nie jest prawda! "Viagra" i "tanie" występują razem częściej niż przypadkiem. Ale model i tak działa zaskakująco dobrze...
\nTo jest trochę jak założenie, że pogoda w Warszawie nie zależy od pogody w Krakowie. Oczywiście trochę zależy! Ale jeśli chcesz szybko oszacować, czy potrzebujesz parasola, to założenie niezależności daje ci w miarę dobrą odpowiedź ;-)
\nSkoro już rozumiemy matematykę, zróbmy to w kilku linijkach kodu. Biblioteka scikit-learn ma gotowy klasyfikator Naive Bayes:
CountVectorizer - zamienia tekst na wektor zliczeń słów (czyli nasz BoW z poprzedniej sekcji)MultinomialNB - to jest właśnie Naive Bayes, tzw. "wielomianowy" (bo liczy prawdopodobieństwa słów), z alpha=1.0 czyli Laplace smoothingfrom sklearn .naive_bayes import MultinomialNB \nfrom sklearn .feature_extraction .text import CountVectorizer \n\nemails = [\n "Kup viagra tanio teraz" ,\n "Viagra darmowa oferta" ,\n "Spotkanie jutro o 10" ,\n "Prześlij mi raport jutro" ,\n "Tanie leki online kup teraz" ,\n "Raport z wczoraj prześlij" ,\n]\nlabels = [1 , 1 , 0 , 0 , 1 , 0 ] # 1=spam, 0=nie-spam \n\nvectorizer = CountVectorizer ()\nX = vectorizer .fit_transform (emails )\n\nclassifier = MultinomialNB (alpha = 1.0 )\nclassifier .fit (X , labels )\n\nnew_email = vectorizer .transform (["Viagra jutro spotkanie" ])\nprediction = classifier .predict (new_email )\nprint ("Spam!" if prediction [0 ] == 1 else "Nie-spam." )Tip
\nEksperyment dla was: Stwórzcie 5 pozytywnych zdań o filmie ("Ten film był niesamowity!", "Wspaniała akcja!", ...) i 5 negatywnych ("Nudny jak flaki z olejem", "Strata czasu", ...). Wypiszcie słowa, które występują TYLKO w pozytywnych i TYLKO w negatywnych. To jest intuicja Naive Bayes - każde słowo "głosuje" na jedną z kategorii.
\nWarning
\nOgraniczenie: Naive Bayes widzi słowa, ale nie kontekst. "Film jest NIESAMOWITY... żesz beznadziejny" - model zobaczy "niesamowity" i powie "pozytywny". Nie ogarnia ironii ani złożonych konstrukcji. Potrzebujemy czegoś, co rozumie relacje między słowami. I tu wchodzimy w świat wektorów...
\nWszystkie metody, które dotąd poznaliśmy, mają jeden wspólny problem: traktują słowa jako dyskretne, niezależne byty. W BoW "kot" jest na pozycji 47 w wektorze, "pies" na pozycji 138. Nie ma między nimi żadnej relacji.
\nA przecież MY wiemy, że "kot" i "pies" są do siebie podobne - oba to zwierzęta domowe. "Kot" i "samochód" - zupełnie różne. Jak sprawić, żeby komputer też to "wiedział"?
\nOdpowiedź z 2013 roku, od zespołu Tomáša Mikolova w Google: zamieńmy słowa w punkty w przestrzeni wielowymiarowej. Słowa podobne znaczeniowo będą blisko siebie. Słowa różne - daleko.
\nTo jest Word2Vec. I to jest przełom.
\nZanim Word2Vec, standardem było tzw. one-hot encoding - każde słowo to wektor z jedynką na swojej pozycji i zerami wszędzie indziej:
\n"kot" → [0, 0, 0, 1, 0, 0, ...] (1 na pozycji 3)\n"pies" → [0, 0, 1, 0, 0, 0, ...] (1 na pozycji 2)\n"samochód" → [1, 0, 0, 0, 0, 0, ...] (1 na pozycji 0)\nProblem? Każde słowo jest w takiej samej odległości od każdego innego. Odległość między "kot" a "pies" jest taka sama jak między "kot" a "samochód". Zero informacji o znaczeniu.
\ngraph LR\n subgraph "One-hot: wszystko jest tak samo daleko"\n O1["kot<br/>[0,0,1,0]"] ---|"="| O2["pies<br/>[0,1,0,0]"]\n O1 ---|"="| O3["samochód<br/>[1,0,0,0]"]\n end\n \n style O1 fill:#9999ff,color:#fff\n style O2 fill:#ffcc99,color:#000\n style O3 fill:#ff9999,color:#000\nWord2Vec opiera się na genialnej intuicji lingwistycznej: słowa, które występują w podobnym kontekście, mają podobne znaczenie.
\nJeśli widzisz: "___ biega po parku i goni gołębie", to co tam wpadnie? Pies? Kot? Raczej nie "samochód" ani "demokracja". Kontekst definiuje słowo.
\ngraph TD\n subgraph "Kontekst słowa 'pies'"\n P1["___ biega po parku"]\n P2["Mój ___ szczeka na listonosza"]\n P3["Karmię ___ karmą"]\n end\n subgraph "Kontekst słowa 'kot'"\n K1["___ śpi na kanapie"]\n K2["Mój ___ łapie myszy"]\n K3["Karmię ___ karmą"]\n end\n \n P3 -.->|"wspólny kontekst!"| K3\n \n style P3 fill:#ffff99,color:#000\n style K3 fill:#ffff99,color:#000\n"Karmię ___ karmą" - zarówno pies, jak i kot pasują. To znaczy, że kontekst tych słów jest częściowo wspólny. I to jest właśnie to, co Word2Vec wykorzystuje.
\nPamiętacie Saussure'a z drugiego posta? Znaczenie jest relacyjne. "Kot" znaczy to, co znaczy, bo NIE jest "psem", NIE jest "domem". Word2Vec to matematyczna implementacja tej idei!
\nWord2Vec ma dwa warianty. Zobaczmy oba:
\nCBOW (Continuous Bag of Words): z kontekstu zgadujemy słowo środkowe.
\n"Kot ___ na macie" → siedzi? leży? śpi?
Skip-gram: ze słowa środkowego zgadujemy kontekst.
\n"siedzi" → kot? na? macie?
graph TD\n subgraph "CBOW: kontekst → słowo"\n C1["Kot"] --> H1["🧠 Ukryta warstwa<br/>(uśrednione wektory)"]\n C2["na"] --> H1\n C3["macie"] --> H1\n H1 --> O1["siedzi ✅"]\n end\n \n subgraph "Skip-gram: słowo → kontekst"\n S1["siedzi"] --> H2["🧠 Ukryta warstwa"]\n H2 --> O2["Kot?"]\n H2 --> O3["na?"]\n H2 --> O4["macie?"]\n end\n \n style H1 fill:#9999ff,color:#fff\n style H2 fill:#ff9999,color:#000\nJak to działa wewnątrz? Sieć neuronowa z jedną ukrytą warstwą:
\nBrzmi skomplikowanie? Zróbmy to w kodzie - od zera, bez żadnych bibliotek ML:
\nimport numpy as np \n\nnp .random .seed (42 )\n\n# --- 1. Słownik i one-hot encoding --- \ncorpus = "kot siedzi na macie i śpi pies siedzi na dywanie i śpi kot biega po pokoju pies biega po parku" .split ()\nvocab = list (set (corpus ))\nword2idx = {w : i for i , w in enumerate (vocab )}\nvocab_size = len (vocab )\n\ndef one_hot (word ):\n vec = np .zeros (vocab_size )\n vec [word2idx [word ]] = 1 \n return vec \n\nprint (f'One-hot "kot": { one_hot ( "kot" ) } ' )\n# [0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 1.] - tylko jedna jedynka! \n\n# --- 2. Macierz wag (to będą nasze embeddingi) --- \nembed_dim = 5 # w prawdziwym Word2Vec to 100-300 \nW1 = np .random .randn (vocab_size , embed_dim ) * 0.01 # słownik → embedding \nW2 = np .random .randn (embed_dim , vocab_size ) * 0.01 # embedding → słownik \n\n# --- 3. Pary treningowe (CBOW: kontekst → środek) --- \nwindow = 2 \npairs = []\nfor i in range (window , len (corpus ) - window ):\n context = corpus [i - window :i ] + corpus [i + 1 :i + window + 1 ]\n target = corpus [i ]\n pairs .append ((context , target ))\n\nprint (f'Kontekst: { pairs [ 0 ][ 0 ] } → Cel: { pairs [ 0 ][ 1 ] } ' )\n# Kontekst: ['kot', 'siedzi', 'macie', 'i'] → Cel: na \n\n# --- 4. Trening (gradient descent) --- \ndef softmax (x ):\n e = np .exp (x - np .max (x ))\n return e / e .sum ()\n\nfor epoch in range (500 ):\n loss = 0 \n for context_words , target_word in pairs :\n context_idx = [word2idx [w ] for w in context_words ]\n target_idx = word2idx [target_word ]\n\n # forward: uśrednione embeddingi kontekstu → przewidujemy środek \n hidden = np .mean (W1 [context_idx ], axis = 0 )\n output = softmax (hidden @ W2 )\n loss -= np .log (output [target_idx ] + 1e-8 )\n\n # backward: aktualizujemy wagi \n grad = output .copy ()\n grad [target_idx ] -= 1 \n W2 -= 0.05 * np .outer (hidden , grad )\n grad_hidden = grad @ W2 .T \n for idx in context_idx :\n W1 [idx ] -= 0.05 * grad_hidden / len (context_idx )\n\n# --- 5. Wynik: embeddingi! --- \nfor word in ["kot" , "pies" , "siedzi" , "biega" ]:\n print (f" { word } : { W1 [ word2idx [ word ]]. round ( 3 ) } " )\n\n# --- 6. Podobieństwo kosinusowe --- \ndef cosine (a , b ):\n return np .dot (a , b ) / (np .linalg .norm (a ) * np .linalg .norm (b ) + 1e-8 )\n\nprint (f'kot ↔ pies: { cosine ( W1 [ word2idx [ "kot" ]], W1 [ word2idx [ "pies" ]]):.3f } ' )\nprint (f'kot ↔ siedzi: { cosine ( W1 [ word2idx [ "kot" ]], W1 [ word2idx [ "siedzi" ]]):.3f } ' )\nprint (f'kot ↔ biega: { cosine ( W1 [ word2idx [ "kot" ]], W1 [ word2idx [ "biega" ]]):.3f } ' )One-hot "kot": [0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 1.]\nKontekst: ['kot', 'siedzi', 'macie', 'i'] → Cel: na\nkot: [-2.866 -0.264 -0.225 -1.822 2.783]\npies: [-1.133 0.678 -1.537 1.989 2.241]\nsiedzi: [ 1.524 -0.023 1.804 -2.355 -0.788]\nbiega: [ 2. 4.098 -0.315 2.971 0.815]\nkot ↔ pies: 0.378\nkot ↔ siedzi: -0.177\nkot ↔ biega: -0.407\nZauważcie: kot i pies (0.378) są bardziej podobne niż kot i biega (-0.407). Sieć sama odkryła, że "kot" i "pies" to zwierzęta, bo występują w podobnym kontekście. Zero etykiet, zero nadzoru - tylko tekst i matematyka.
\nNote
\nTo jest cały Word2Vec w ~30 linijkach. Prawdziwy Word2Vec dodaje jeszcze negative sampling (bo softmax na 50 000 słów jest wolny) i optymalizacje, ale zasada jest dokładnie ta sama.
\nNote
\n"Fake task": Interesuje nas nie to, co sieć przewiduje, ale wagi ukrytej warstwy. Sieć trenujemy na "sztucznym" zadaniu przewidywania kontekstu, ale to, co chcemy wyciągnąć, to macierz W - nasze embeddingi. To trochę jak trenowanie kogoś do rozwiązywania krzyżówek nie po to, żeby dobrze rozwiązywał krzyżówki, ale po to, żeby poszerzył słownik ;-)
\n| \n | CBOW | \nSkip-gram | \n
|---|---|---|
| Kierunek | \nKontekst → Słowo środkowe | \nSłowo środkowe → Kontekst | \n
| Szybkość | \nSzybszy | \nWolniejszy | \n
| Rzadkie słowa | \nRadzi sobie gorzej | \nRadzi sobie lepiej | \n
| Częste słowa | \nRadzi sobie lepiej | \nRadzi sobie gorzej | \n
| Kiedy użyć | \nDuży korpus, częste słowa | \nMały korpus, rzadkie słowa | \n
Według oryginalnej pracy Mikolova et al.: Skip-gram jest lepszy dla rzadkich słów i małych zbiorów danych. CBOW jest szybszy i lepszy dla częstych słów.
\nPo wytrenowaniu Word2Vec, każde słowo to wektor (np. 300 liczb). I ta przestrzeń ma niezwykłe właściwości:
\nSłowa podobne są blisko:
\nodległość("kot", "pies") < odległość("kot", "samochód")\nodległość("Polska", "Niemcy") < odległość("Polska", "banan")\nAnalogie działają jak dodawanie i odejmowanie wektorów:
\nwektor("król") - wektor("mężczyzna") + wektor("kobieta") ≈ wektor("królowa")\nDlaczego? Bo wektor "króla" koduje wiele wymiarów znaczeniowych - w jednym z nich jest informacja o "rodzaju" (mężczyzna/kobieta), w innym o "władzy" (monarchia). Odejmując "mężczyznę" i dodając "kobietę", zmieniamy wymiar rodzaju, zachowując pozostałe.
\nInne przykłady analogii:
\nPolska - Warszawa + Berlin ≈ Niemcy\nmały - mniejszy + duży ≈ większy\nłódź - woda + powietrze ≈ samolot\ngraph TD\n K["👑 król<br/>[0.50, 0.68, ...]"] -->|"odjąć 'mężczyzna'"| KM["[0.35, 0.55, ...]<br/><i>monarcha, ale bez rodzaju</i>"]\n M["👨 mężczyzna<br/>[0.15, 0.13, ...]"]\n W["👩 kobieta<br/>[0.12, 0.20, ...]"]\n KM -->|"dodać 'kobieta'"| Q["👸 królowa<br/>[0.38, 0.64, ...]"]\n \n K -.- M\n Q -.- W\n \n style K fill:#ff9999,color:#000\n style M fill:#ffcc99,color:#000\n style W fill:#ccff99,color:#000\n style Q fill:#99ccff,color:#000\nTo jest to, o czym mówiliśmy w pierwszym poście przy okazji semantyki. Teraz widzicie, jak to działa pod spodem.
\nNajpierw wytrenujmy własny model na małym korpusie, żeby zobaczyć jak to działa od zera:
\nfrom gensim .models import Word2Vec \n\ncorpus = [\n ["kot" , "siedzi" , "na" , "macie" , "i" , "śpi" ],\n ["pies" , "siedzi" , "na" , "dywanie" , "i" , "śpi" ],\n ["kot" , "biega" , "po" , "pokoju" ],\n ["pies" , "biega" , "po" , "parku" ],\n ["kot" , "i" , "pies" , "bawią" , "się" , "w" , "ogrodzie" ],\n ["kot" , "je" , "karmę" , "z" , "miski" ],\n ["pies" , "je" , "karmę" , "z" , "miski" ],\n ["kot" , "łapie" , "mysz" , "w" , "domu" ],\n ["pies" , "goni" , "kota" , "po" , "ogrodzie" ],\n ["ptak" , "siedzi" , "na" , "gałęzi" , "drzewa" ],\n ["ryba" , "pływa" , "w" , "akwarium" ],\n ["samochód" , "jeździ" , "po" , "drodze" ],\n ["rower" , "jeździ" , "po" , "ścieżce" ],\n ["kot" , "mruczy" , "gdy" , "głaszczesz" , "go" ],\n ["pies" , "merda" , "ogonem" , "gdy" , "widzi" , "pana" ],\n]\n\nmodel = Word2Vec (\n sentences = corpus ,\n vector_size = 10 , # wymiar wektora (mały = edukacyjny) \n window = 3 , # rozmiar okna kontekstowego \n min_count = 1 , # ignoruj słowa rzadsze niż N \n sg = 0 , # 0 = CBOW, 1 = Skip-gram \n epochs = 200 , # ile przejść po danych \n)\n\nprint (model .wv .most_similar ("kot" , topn = 3 ))\n# [('pies', 0.96), ('śpi', 0.95), ('na', 0.95)] \n\nprint (model .wv .similarity ("kot" , "pies" )) # ~0.96 \nprint (model .wv .similarity ("kot" , "samochód" )) # ~0.83 Note
\nZauważcie: nasz korpus jest MALUTKI (15 zdań), więc wyniki są dalekie od idealnych — "kot" i "samochód" mają aż 0.83 podobieństwa, co jest bez sensu. Ale model poprawnie stawia "pies" najbliżej "kot"! Na prawdziwych korpusach (miliardy zdań) te wektory stają się bardzo dokładne.
\nA tak korzystamy z gotowego modelu wytrenowanego na miliardach słów:
\nfrom gensim .downloader import load \n\nmodel = load ("glove-wiki-gigaword-50" )\n\nresult = model .most_similar (\n positive = ["king" , "woman" ],\n negative = ["man" ],\n topn = 5 \n)\n\nfor word , score in result :\n print (f" { word } : { score :.3f } " )\n\n# queen: 0.852 \n# throne: 0.737 \n# ... Możecie też sprawdzić podobieństwo między słowami:
\nprint (model .similarity ("cat" , "dog" )) # ~0.92 \nprint (model .similarity ("cat" , "car" )) # ~0.15 "Cat" i "dog" - podobieństwo 0.92. "Cat" i "car" - 0.15. Model "wie", że kot jest bliżej psa niż samochodu.
\nTip
\nEksperyment: Wejdźcie na TensorFlow Embedding Projector - to interaktywna wizualizacja przestrzeni wektorowej. Możecie wpisywać słowa i widzieć, co jest blisko. To jest JEDNA z najpiękniejszych wizualizacji w całym ML. Serio, sprawdźcie!
\nWarning
\nUwaga na uprzedzenia: Word2Vec uczy się z danych. Jeśli w danych treningowych "programista" częściej występuje blisko "mężczyzna" niż "kobieta" - to model to wyłapie. Słynny przykład: wektor("programista") - wektor("mężczyzna") + wektor("kobieta") ≈ "gospodyni domowa". To jest uprzedzenie ukryte w danych, które model bezrefleksyjnie reprodukuje. Pamiętacie semiosferę z drugiego posta? Semiosfera nie jest neutralna - i dane treningowe też nie są.
Zróbmy jeszcze raz porównanie, żeby to sobie utrwalić:
\ngraph LR\n subgraph "BoW / TF-IDF: rzadki wektor"\n R["'Kot siedzi na macie'"] --> RV["[0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, ...]<br/>Długość = rozmiar słownika<br/>Większość to ZERA"]\n end\n subgraph "Word2Vec: gęsty wektor"\n D["'kot'"] --> DV["[0.23, -0.45, 0.67, 0.12, -0.89, ...]<br/>Długość = 300<br/>Wszystkie wartości NIEZEROWE"]\n end\n \n style RV fill:#ff9999,color:#000\n style DV fill:#99ff99,color:#000\n| \n | BoW / TF-IDF | \nWord2Vec | \n
|---|---|---|
| Typ | \nRzadki (sparse) | \nGęsty (dense) | \n
| Długość wektora | \n= rozmiar słownika (może być 100 000+) | \n= wymiar embeddingu (zwykle 100-300) | \n
| Wartości | \nGłównie zera | \nWszystkie niezerowe | \n
| Podobieństwo | \nTrudno uchwycić | \nKosinusowe podobieństwo działa super | \n
| Kontekst | \nBrak | \nUchwycony przez okno kontekstowe | \n
| Analogie | \nNie ma | \nDziałają (król - mężczyzna + kobieta ≈ królowa) | \n
Nie. Word2Vec tworzy mapę znaczeń — mówi ci, że "kot" jest blisko "pies", ale nie potrafi ułożyć z tego zdania. To jak słownik synonimów: wiesz co jest podobne, ale nie napiszesz wiersza.
\nAle... co jeśli połączymy Word2Vec z łańcuchami Markowa? Łańcuch Markowa wybiera następne słowo na podstawie częstotliwości. A jeśli zamiast losować równie, sprawimy, że słowa bardziej podobne do kontekstu będą miały większą szansę?
\nfrom gensim .models import Word2Vec \nimport numpy as np \nfrom collections import defaultdict \nimport random \n\ncorpus = [\n "kot siedzi na macie i śpi" ,\n "pies siedzi na dywanie i śpi" ,\n "kot biega po pokoju" ,\n "pies biega po parku" ,\n "kot i pies bawią się w ogrodzie" ,\n "kot je karmę z miski" ,\n "pies je karmę z miski" ,\n "kot łapie mysz w domu" ,\n "pies goni kota po ogrodzie" ,\n "ptak siedzi na gałęzi drzewa" ,\n "kot patrzy przez okno i mruczy" ,\n "pies szczeka na listonosza" ,\n "kot śpi cały dzień na kanapie" ,\n]\n\ntokenized = [sentence .split () for sentence in corpus ]\n\nw2v_model = Word2Vec (sentences = tokenized , vector_size = 10 , window = 3 , min_count = 1 , epochs = 200 )\n\n# budujemy macierz przejść (jak w łańcuchach Markowa) \ntransitions = defaultdict (list )\nfor sentence in tokenized :\n for i in range (len (sentence ) - 1 ):\n transitions [sentence [i ]].append (sentence [i + 1 ])\n\ndef generate (start , length = 6 ):\n words = [start ]\n for _ in range (length ):\n current = words [- 1 ]\n if current not in transitions :\n break \n\n candidates = transitions [current ]\n\n # uśredniony wektor ostatnich słów = kontekst \n context_vector = np .mean (\n [w2v_model .wv [w ] for w in words [- 3 :] if w in w2v_model .wv ],\n axis = 0 ,\n )\n\n # punktujemy kandydatów za podobieństwo do kontekstu \n scored = []\n for candidate in candidates :\n if candidate in w2v_model .wv :\n similarity = np .dot (context_vector , w2v_model .wv [candidate ]) / (\n np .linalg .norm (context_vector ) * np .linalg .norm (w2v_model .wv [candidate ]) + 1e-8 \n )\n scored .append ((candidate , similarity ))\n\n if scored :\n # losujemy, ale z wagami — podobne słowa mają większą szansę \n weights = [score + 1 for _ , score in scored ]\n chosen = random .choices ([w for w , _ in scored ], weights = weights , k = 1 )[0 ]\n words .append (chosen )\n else :\n words .append (random .choice (candidates ))\n return " " .join (words )\n\nfor _ in range (5 ):\n print (generate ("kot" ))kot siedzi na macie i śpi\nkot patrzy przez okno i mruczy\nkot je karmę z miski\nkot śpi cały dzień na kanapie\nkot łapie mysz w domu\nNie jest to Szekspir, ale teksty są bardziej spójne niż czysty losowy Markow. Idea jest prosta:
\nTo jest malutki krok w kierunku tego, co robią dzisiejsze LLM-y. One też przewidują następne słowo, ale zamiast prostej macierzy przejścia mają wielowarstwowe sieci Transformer z mechanizmem uwagi. Tam "punktowanie kandydatów" jest o wiele, wiele bardziej zaawansowane.
\nImportant
\nKluczowa różnica: Word2Vec daje każdemu słowu JEDEN wektor. Ale "zamek" w "zamek w drzwiach" i "zamek na wzgórzu" to zupełnie inne znaczenia! Word2Vec nie rozróżnia — dlatego w kolejnych wpisach wejdziemy w Transformer-y, gdzie kontekst zmienia znaczenie każdego słowa.
\nOto nasza mapa drogowa, od cięcia tekstu do geometrii znaczeń:
\n| Metoda | \nCo robi | \nKontekst? | \nCzego nie umie | \n
|---|---|---|---|
| Tokenizacja (BPE) | \nTnie tekst na kawałki | \nNie | \nNie rozumie, co tnie | \n
| BoW / TF-IDF | \nLiczy słowa, waży rzadkością | \nNie | \nIgnoruje kolejność | \n
| N-gramy | \nPatrzy na sekwencje słów | \nLokalny (2-3 słowa) | \nKrótki kontekst, szybko rosnący słownik | \n
| Naive Bayes | \nKlasyfikuje na podstawie prawdopodobieństwa | \nNie (słowa "niezależne") | \nNie łapie zależności między słowami | \n
| Word2Vec | \nZamienia słowa w wektory znaczeniowe | \nTak (okno kontekstowe) | \nJedno słowo = jeden wektor (ignoruje wieloznaczność) | \n
graph TD\n subgraph "Ewolucja: od liczenia do rozumienia"\n T["✂️ Tokenizacja<br/><i>tekst → kawałki</i>"] -->|"jak policzyć?"| B["🔢 BoW / TF-IDF<br/><i>kawałki → liczby</i>"]\n B -->|"brak kontekstu!"| N["🔗 N-gramy / Markow<br/><i>dodajemy kolejność</i>"]\n N -->|"chcemy klasyfikować!"| NB["📊 Naive Bayes<br/><i>prawdopodobieństwo klas</i>"]\n NB -->|"słowa to nie liczby!"| W["📐 Word2Vec<br/><i>geometria znaczeń</i>"]\n W -->|"co dalej?"| LLM["🤖 Transformers / LLM<br/><i>kontekst + attention + skala</i>"]\n end\n \n style T fill:#ff9999,color:#000\n style B fill:#ffcc99,color:#000\n style N fill:#ffff99,color:#000\n style NB fill:#ccff99,color:#000\n style W fill:#99ccff,color:#000\n style LLM fill:#9999ff,color:#fff\nI kluczowa perspektywa: z każdej z tych metod LLM wziął coś dla siebie.
\nLLM nie spadł z nieba. Stoi na barkach gigantów.
\nImportant
\nCo w następnym wpisie? Wejdziemy w to, co dzieje się, gdy te wszystkie pomysły połączymy z mechanizmem uwagi (attention) i sieciami Transformer. Bo od Word2Vec (2013) do "Attention Is All You Need" (2017) do ChatGPT (2022) jest "tylko" kilkanaście lat i kilka przełomowych pomysłów ;-)
\nWiem, że tego posta jest dużo, ale chciałem, żeby ta droga od "tnięcia tekstu" do "wektorów znaczeń" była pełna i zrozumiała.
\nMam nadzieję, że chociaż kilka razy powiecie "aha!". Jeśli coś jest niejasne - napiszcie w komentarzach, postaram się wyjaśnić. A jeśli macie lepsze przykłady analogii Word2Vec - tym bardziej dajcie znać.
\nKtóra metoda was najbardziej zaskoczyła? Czy wiedzieliście, że ChatGPT "myśli" w tokenach, nie w słowach? I że jego "myślenie" to tak naprawdę potomek łańcuchów Markowa?
\nDo następnego!
\nŹródła i ciekawe linki:
\nJeśli chcecie wejść głębiej, oto materiały, z których korzystałem:
\nOdpowiedzi do quizu tokenizacyjnego: 1) "klasa" → ["k", "las", "a"] (l+a→la, la+s→las, ale "k" nie pasuje do żadnego scalenia) 2) "lata" → ["lat", "a"] (l+a→la, la+t→lat) 3) "laska" → ["las", "k", "a"] (l+a→la, la+s→las, ale "las"+"k" nie ma w scaleniach, więc zostaje podzielone). ↩
\nW poprzednim wpisie zbudowaliśmy naszą językową cebulkę - pięć warstw, od fonetyki po pragmatykę, i zobaczyliśmy, jak LLM radzi sobie z każdą z nich. Ale po napisaniu tamtego posta zostało mi jedno wielkie "ale..." w głowie.
\nBo przecież - czy LLM w ogóle "rozumie" to, co generuje? Czy ma jakiś wewnętrzny model świata? Czy myśli?
\nI wtedy wpadłem na semiotykę. I okazuje się, że semiotyka daje nam genialną ramę do myślenia o LLM - nie jako o sztucznym umyśle, ale jako o maszynie znaków. I nagle wszystko zaczyna mieć sens. Albo przynajmniej ma bardziej sens niż wcześniej ;-)
\nTo jest drugi wpis z serii "zrozumiec LLM". Dzisiaj zmieniamy perspektywę: zamiast patrzeć na warstwy języka, patrzymy na samą naturę tego, czym są znaki i jak znaczenie w ogóle powstaje. I dlaczego to jest kluczowe do zrozumienia, czym LLM jest - i czym nie jest.
\nZanim wejdziemy w LLM, musimy załatwić podstawy. Bo semiotyka to jedno z tych słów, które brzmi mądrze, ale co właściwie znaczy?
\nSemiotyka to nauka o znakach i o tym, jak znaki tworzą znaczenie. To wszystko. Nie brzmi już tak strasznie, prawda? ;-)
\nA "znak" w semiotyce to wszystko, co coś oznacza. Coś, co stoi za czymś innym. Proste przykłady:
\nKażdy z tych znaków reprezentuje coś innego. I to "reprezentowanie" to jest właśnie to, co semiotyka bada.
\nTip
\nEksperyment: Rozejrzyjcie się wokół siebie - ile znaków widzicie w tej chwili? Ja w tym momencie widzę: ikonę WiFi (mam internet), powiadomienie na telefonie (ktoś napisał), logo na kubku z kawą (marka). Trzy znaki i nawet nie wstałem z krzesła.
\nW poprzednim wpisie mieliśmy semantykę - badanie znaczenia słów i zdań. Więc czym semiotyka się różni?
\nKrótko:
\n| \n | Co pyta | \nPrzykład | \n
|---|---|---|
| Semantyka | \n"Co to znaczy?" | \nCo znaczy słowo "zamek"? | \n
| Semiotyka | \n"Jak ten znak w ogóle działa?" | \nJak to się dzieje, że czerwone światło OZNACZA "stop"? | \n
Semantyka pyta o konkretne znaczenia. Semiotyka pyta o mechanizm znaczenia - jak to się dzieje, że cokolwiek cokolwiek oznacza.
\nI właśnie dlatego semiotyka jest tak ważna dla zrozumienia LLM. Bo pytanie nie brzmi "co LLM znaczy", ale "jak LLM operuje na znakach".
\nW semiotyce są dwie główne tradycje, które musicie znać. Dwa podejścia, dwa sposoby myślenia o znakach. I uwaga - oba są ważne dla zrozumienia LLM, ale każdy z innej strony.
\nSaussure (szwajcarski lingwista, żył na przełomie XIX i XX wieku) powiedział: znak składa się z dwóch części.
\ngraph LR\n Z["SIGN<br/><i>znak</i>"] --> SI["SIGNIFIANT<br/><i>znaczące</i><br/>forma: dźwięk, tekst"]\n Z --> SE["SIGNIFIE<br/><i>znaczone</i><br/>koncept, pojęcie"]\n \n style Z fill:#9999ff,color:#fff\n style SI fill:#ffcc99,color:#000\n style SE fill:#99ff99,color:#000\nI kluczowa rzecz: relacja między znaczącym a znaczonym jest arbitralna. Nie ma żadnego logicznego powodu, dla którego ciąg liter "k-o-t" oznacza właśnie tego zwierzaka. Po prostu... tak się przyjęło. W angielskim to "cat", w niemieckim "Katze", w japońskim "猫" (neko) - każdy język ma inny ciąg dźwięków/liter na to samo pojęcie.
\nAle Saussure mówi coś jeszcze ważniejszego: znaczenie słowa wynika z jego relacji do innych słów w systemie. "Kot" znaczy to, co znaczy, bo NIE jest "psem", NIE jest "domem", NIE jest "samochodem". Znaczenie jest różnicowe - wynika z różnicy.
\n\n\nTo brzmi abstrakcyjnie, ale za chwilę zobaczycie, że to jest dokładnie to, co robią embeddingi w LLM. Naprawdę ;-)
\n
Peirce (amerykański filozof, trochę wcześniej niż Saussure, ale mniej więcej w tym samym czasie) miał inne podejście. Dla niego znak nie jest statyczną parą, ale dynamicznym procesem.
\ngraph TD\n R["REPRESENTAMEN<br/><i>znak</i><br/>forma, którą widzisz"] --> O["OBJECT<br/><i>obiekt</i><br/>to, do czego znak się odnosi"]\n R --> I["INTERPRETANT<br/><i>interpretacja</i><br/>efekt w umyśle odbiorcy"]\n I -.->|"tworzy nowy znak"| R2["NOWY REPRESENTAMEN"]\n \n style R fill:#ff9999,color:#000\n style O fill:#99ff99,color:#000\n style I fill:#9999ff,color:#fff\nTriada Peirce'a:
\nI to jest kluczowa różnica: u Saussure'a znak jest statyczny (para), u Peirce'a - dynamiczny, żywy, będący procesem. Znaczenie nie jest "zawarte" w znaku - ono powstaje w procesie interpretacji.
\nPeirce podzielił znaki na trzy kategorie, które są super intuicyjne:
\n| Typ | \nOpis | \nPrzykłady | \n
|---|---|---|
| Ikona | \nPodobieństwo między znakiem a obiektem | \nPortret, mapa, emoji 😺 (wygląda trochę jak kot), ikona folderu na komputerze | \n
| Indeks | \nZwiązek przyczynowo-skutkowy lub fizyczny | \nŚlady stóp na piasku (ktoś tu przeszedł), dym (ogień), kaszel (choroba), termometr (temperatura) | \n
| Symbol | \nKonwencja, umowa społeczna | \nSłowo "kot", flaga państwowa, czerwone światło = stop, matematyczne "=" | \n
Note
\nSłowo "symbol" w codziennym języku znaczy coś innego niż w semiotyce Peirce'a! W semiotyce symbol to znak oparty wyłącznie na konwencji - nie przypomina obiektu (jak ikona) i nie jest z nim fizycznie związany (jak indeks). Flaga Polski nie "przypomina" Polski i nie jest z nią fizycznie połączona - po prostu się umówiliśmy, że te kolory oznaczają to państwo.
\nSprawdźcie się - jaki to typ znaku?1
\nDavid Manheim, badacz AI, użył pięknej metafory pochodzącej od semiotyki Peirce'a. Nazwał to "Hall of Mirrors Problem" - problemem hali luster.
\nWyobraźcie sobie: jesteście w pokoju pełnym luster. Widzicie odbicia odbić odbić... i nigdzie nie ma okna na zewnątrz. Nie widzicie prawdziwego świata - widzicie tylko... więcej luster.
\nTo jest dokładnie to, co robi LLM.
\ngraph LR\n W["🌍 Świat<br/><i>rzeczywistość</i>"] -->|"doświadczenie"| C["🧑 Ludzie<br/><i>piszą teksty</i>"]\n C -->|"tworzą"| T["📝 Teksty<br/><i>dane treningowe</i>"]\n T -->|"uczy się na"| LLM["🤖 LLM"]\n LLM -->|"generuje"| T2["📝 Nowe teksty"]\n T2 -->|"trafiają do"| T\n \n style W fill:#99ff99,color:#000\n style C fill:#ffcc99,color:#000\n style T fill:#ffff99,color:#000\n style LLM fill:#ff9999,color:#000\n style T2 fill:#ffff99,color:#000\nSpójrzmy na to przez pryzmat triady Peirce'a:
\nLLM nigdy nie widział świata. Nigdy nie poczuł smaku truskawki, nie dotknął lodu, nie usłyszał śmiechu. Całą swoją "wiedzę" o świecie czerpie z tekstu - z tego, co inni ludzie napisali o świecie.
\nWięc kiedy LLM pisze "truskawki są słodkie" - on nie wie, że są słodkie. On wie, że w tekstach, na których był trenowany, słowo "truskawki" często występuje blisko słowa "słodkie". To jest różnica. I to jest właśnie semiotyczna różnica.
\nWarning
\nParadoks: LLM potrafi napisać piękny opis zachodu słońca, choć nigdy nie widział słońca. Ale potrafi też napisać piękny opis zachodu słońca na Marsie - choć tam jeszcze nikt nie widział zachodu słońca. Skąd "wie"? Z tekstu science fiction. Czyli: znaki odnoszą się do znaków, które odnoszą się do znaków... hala luster ;-)
\nOK, teraz to, co obiecałem - zobaczmy, jak teoria Saussure'a realizuje się w kodzie. Bo to jest naprawdę fascynujące.
\nPamiętacie, co mówił Saussure? Znaczenie słowa wynika z jego relacji do innych słów. "Kot" znaczy to, co znaczy, bo nie jest "psem", nie jest "domem" itd. Znaczenie jest relacyjne.
\nA teraz pomyślcie o word embeddings (osadzeniach słów) - które poznaliśmy w poprzednim wpisie. Każde słowo jest reprezentowane jako wektor w wielowymiarowej przestrzeni. I słowa o podobnym znaczeniu są blisko siebie w tej przestrzeni.
\nTo jest dokładnie relacyjna teoria znaku Saussure'a, tylko zaimplementowana w matematyce!
\nfrom gensim .downloader import load \n\nmodel = load ("glove-wiki-gigaword-50" )\n\nking = model ["king" ]\nqueen = model ["queen" ]\nman = model ["man" ]\nwoman = model ["woman" ]\n\nresult = king - man + woman \n\nfrom gensim .models import KeyedVectors \nsimilarities = model .cosine_similarities (result , [queen ])\nprint (f"Podobieństwo do 'queen': { similarities [ 0 ]:.3f } " )Wypisze coś w stylu: Podobieństwo do 'queen': 0.850
Ale spójrzcie na to z perspektywy Saussure'a:
\ngraph TD\n subgraph "Saussure: znak = pozycja w systemie relacji"\n S1["'king' nie jest 'queen'<br/>'king' nie jest 'man'<br/>'king' nie jest 'woman'"] --> S2["znaczenie = różnica"]\n end\n subgraph "Word2Vec: słowo = wektor w przestrzeni relacyjnej"\n V1["king = [0.50, 0.68, ...]<br/>queen = [0.38, 0.64, ...]<br/>man = [0.31, 0.43, ...]"] --> V2["znaczenie = pozycja wektora<br/>względem innych wektorów"]\n end\n \n S2 -.->|"to samo!"| V2\n \n style S2 fill:#9999ff,color:#fff\n style V2 fill:#ff9999,color:#000\nZarówno Saussure, jak i Word2Vec mówią to samo: znaczenie nie jest w samym znaku - jest w jego relacji do innych znaków. Saussure wymyślił to jako teorię języka. Programiści Google wymyślili Word2Vec jako algorytm. I doszli do tego samego wniosku.
\nNo... prawie. Bo jest jeden haczyk. Saussure zakładał, że za znaczącym (forma) stoi znaczone (koncept). W embeddingach mamy tylko pozycję w przestrzeni - mamy relacje, ale czy mamy "koncept"? Czy wektor [0.50, 0.68, ...] jest konceptem "króla"?
To jest właśnie to pytanie, które doprowadza nas do kolejnego semiotyka...
\nJacques Derrida (francuski filozof, lata 60. i 70. XX wieku) zrobił coś odważnego. Spojrzał na całego Saussure'a i powiedział: "Chwila. A dlaczego uważacie, że mowa jest ważniejsza od pisma?"
\nSaussure (i cała zachodnia tradycja filozoficzna) traktował mowę jako "pierwotną" - bliższą myśli, bliższą znaczeniu. Pismo było "pochodne" - tylko zapis mowy, "znak znaku". Derrida nazwał to logocentryzmem - przekonaniem, że na końcu łańcucha znaków jest jakaś "obecność", "myśl", "intencja", która nadaje znaczenie.
\nI Derrida odwrócił to do góry nogami: pismo nie jest podrzędne wobec mowy. Pismo jest systemem samym w sobie.
\nDlaczego to jest ważne dla LLM? Bo Elad Vromen w swoim artykule "Language Models as Semiotic Machines" zauważył coś genialnego:
\n\n\nLLM trenuje na piśmie (tekst). Tworzy model pisma. Generuje nowe pismo. Nigdzie w tym procesie nie ma "mowy", "umysłu" ani "intencji". Cała hierarchia Saussure'a - mowa > pismo - zostaje odwrócona. Pismo jest jedyną rzeczywistością, jaką LLM zna.
\n
graph LR\n subgraph "Tradycyjny model (logocentryzm)"\n A1["🌍 Świat"] --> A2["🧠 Myśl"]\n A2 --> A3["🗣️ Mowa"]\n A3 --> A4["📝 Pismo"]\n end\n \n subgraph "Model LLM (odwrócenie Derridy)"\n B1["📝 Pismo<br/><i>dane treningowe</i>"] --> B2["🧮 Model<br/><i>statystyka znaków</i>"]\n B2 --> B3["📝 Nowe pismo<br/><i>output LLM</i>"]\n end\n \n style A4 fill:#ff9999,color:#000\n style B1 fill:#99ff99,color:#000\n style B2 fill:#9999ff,color:#fff\n style B3 fill:#99ff99,color:#000\nWięc kiedy pytamy "czy LLM rozumie język?" - zadajemy złe pytanie. To jak pytanie "czy książka rozumie to, co jest w niej zapisane?" Książka nie "rozumie" - ale zawiera znaki, które my - czytelnicy - interpretujemy. LLM jest czymś pośrednim: nie jest książką (bo generuje nowy tekst), ale nie jest też umysłem (bo nie ma dostępu do znaczeń poza tekstem).
\nImportant
\nDerrida w pigułce dla LLM: LLM nie modeluje "umysłu" ani "świata". LLM modeluje pismo - system znaków, który ma własną logikę, własne reguły, własną spójność. I to pismo jest wystarczające, żeby generować tekst, który dla nas ma znaczenie. Ale to my nadajemy mu znaczenie - nie model.
\nTo też wyjaśnia pewien fenomen, który pewnie zauważyliście: LLM czasami mówi rzeczy, które są statystycznie poprawne, ale nonsensowne. Bo w systemie pisma, w którym operuje model, te słowa dobrze pasują do siebie. Ale my - jako ludzie z dostępem do świata (obiektów w sensie Peirce'a) - widzimy, że to nie ma sensu. Model nie ma tego "zakotwiczenia" w rzeczywistości.
\nDerrida w swoim słynnym eseju "Signature Event Context" mówił o iterowalności znaków - o tym, że znak może być powtórzony w nowym kontekście i nabierać nowego znaczenia. Słowo "dobry" może być komplementem, ironią albo frazą w "dobry wieczór" - kontekst zmienia wszystko.
\nI to jest właśnie to, co widzimy w LLM: ten sam prompt w innym kontekście daje inną odpowiedź. Model nie "rozumie" kontekstu - ale statystycznie wyłapuje wzorce kontekstowe z danych treningowych. Czyli: iterowalność znaków w czystej, matematycznej postaci.
\nTeraz wchodzimy na bardzo praktyczny grunt. Bo jeśli LLM jest maszyną znaków, to prompt - to, co do niego wpisujecie - jest aktem semiotycznym. Nie po prostu "komendą". Ale aktem, który tworzy ramę dla znaczenia.
\nSpójrzmy na interakcję z LLM przez pryzmat triady Peirce'a:
\ngraph TD\n P["📝 PROMPT<br/><i>representamen</i><br/>znak wejściowy"] --> LLM["🤖 LLM<br/><i>przetwarzanie znaków</i>"]\n LLM --> O["💬 ODPOWIEDŹ<br/><i>nowy representamen</i>"]\n O --> U["🧑 UŻYTKOWNIK<br/><i>interpretant</i><br/>nadaje znaczenie"]\n U -.->|"nowy prompt"| P\n \n style P fill:#ff9999,color:#000\n style LLM fill:#ffcc99,color:#000\n style O fill:#ffff99,color:#000\n style U fill:#9999ff,color:#fff\nCzyli:
\nZauważcie: znaczenie powstaje dopiero w kroku 3. LLM generuje ciąg tokenów, ale to Wy nadajecie mu sens. To jest dokładnie to, o czym mówił Umberto Eco z koncepcją "dzieła otwartego" - tekst nie ma jednego, ustalonego znaczenia. Tekst jest "ramą", którą czytelnik wypełnia interpretacją.
\nSpróbujcie sami. Odpalcie ChatGPT (albo Claude, Gemini - co macie) i wyślijcie te trzy prompty, każdy w nowej rozmowie:
\n"Wyjaśnij, czym jest grawitacja.""Wyjaśnij grawitację pięciolatkowi.""Wyjaśnij grawitację w stylu sonetu Szekspira."Każdy prompt dotyczy tego samego tematu (grawitacja). Ale każdy zmienia ramę semiotyczną - zmienia ton, rejestr, gatunek, oczekiwaną formę odpowiedzi.
\n| Prompt | \nZmienia się... | \nRama semiotyczna | \n
|---|---|---|
| "Wyjaśnij grawitację" | \n- | \nNeutralna, encyklopedyczna | \n
| "...pięciolatkowi" | \nOdbiorca, prostota języka | \nEdukacyjna, dostosowana do wieku | \n
| "...w stylu Szekspira" | \nGatunek, forma, styl | \nLiteracka, artystyczna | \n
To jest dokładnie to, co Picca nazywa "semiotyczną umową" (semiotic contract). Kiedy tworzycie prompt, nie "prosicie o informację" - ustanawiacie warunki, w jakich znaczenie będzie konstruowane. Prosicie o grawitację w trybie Szekspira? Otrzymujecie hybrydę fizyki i poezji. To nie jest "prawdziwa" grawitacja ani "prawdziwy" Szekspir - to jest semiotyczny kolaż, nowa konfiguracja znaków.
\nTip
\nEksperyment bonusowy: Spróbujcie: "Wyjaśnij pojęcie entropii używając metafor z bajek." Zobaczycie, jak LLM łączy dwie zupełnie różne strefy semiotyczne - fizykę i baśnie. To jest właśnie to, co semiotyka nazywa translacją między kodami kulturowymi.
\nJeszcze jedno pojęcie, które warto znać. Jurij Lotman, rosyjski semiotyk, wymyślił koncept semiosfery.
\nSemiosfera to przestrzeń, w której żyją znaki. To ekologia znaczeń - sieć kodów kulturowych, gatunków, dyskursów, ideologii, które wchodzą ze sobą w interakcje. Podobnie jak biosfera to przestrzeń, w której żyją organizmy, semiosfera to przestrzeń, w której żyją znaki.
\ngraph TD\n subgraph "Semiosfera"\n N["📰 Media<br/><i>news, artykuły</i>"]\n L["📚 Literatura<br/><i>powieści, poezja</i>"]\n S["🔬 Nauka<br/><i>publikacje, podręczniki</i>"]\n I["💬 Internet<br/><i>fora, social media</i>"]\n K["🎭 Kultura<br/><i>film, sztuka, muzyka</i>"]\n P["⚖️ Prawo<br/><i>ustawy, orzeczenia</i>"]\n end\n \n D["📊 Dane treningowe LLM"] -.-> N\n D -.-> L\n D -.-> S\n D -.-> I\n D -.-> K\n D -.-> P\n \n LLM2["🤖 LLM"] -->|"nawiguje po<br/>strefach semiosfery"| D\n \n style D fill:#ffff99,color:#000\n style LLM2 fill:#ff9999,color:#000\nDane treningowe LLM są niczym innym jak gigantycznym przekrojem semiosfery. Kiedy model czyta Wikipedię, twittera, książki, artykuły naukowe, kody źródłowe - przyswaja (statystycznie!) całą tę różnorodność kodów kulturowych.
\nI dlatego potrafi pisać w stylu Szekspira, tłumaczyć z niemieckiego, żartować jak komik i cytować przepisy prawa - bo wszystko to jest w semiosferze, a model "widział" próbki z każdej strefy.
\nAle jest i druga strona medalu: model przyswaja też uprzedzenia, stereotypy i dominujące narracje zawarte w semiosferze. Bo semiosfera nie jest neutralna - to przestrzeń kulturowa z historią, z władzą, z ideologią. I LLM, operując na znakach z tej przestrzeni, reprodukuje je w swoich outputach.
\nWarning
\nDlaczego LLM czasem mówi głupoty? Bo semiosfera jest pełna sprzeczności. Na jednej stronie internetu "ziemia jest okrągła", na innej "ziemia jest płaska". Model widzi oba znaki i nie ma dostępu do "obiektu" (rzeczywistej ziemi), żeby zdecydować, który znak jest prawdziwy. Operuje w hali luster - znaki odnoszą się do znaków, a nie do rzeczywistości.
\nSprawdźcie, który semiotyk lepiej wyjaśnia te zjawiska LLM. Przypominam:
\nKto lepiej wyjaśnia, że...?2
\nOto nasza semiotyczna mapa w pigułce:
\n| Semiotyk | \nKluczowy koncept | \nCo to mówi o LLM | \n
|---|---|---|
| Saussure | \nZnaczenie = relacja między znakami | \nEmbeddingi realizują relacyjną koncepcję znaku | \n
| Peirce | \nTriada znak-obiekt-interpretant | \nLLM nie ma dostępu do obiektu, tylko do znaków (hala luster) | \n
| Derrida | \nPismo jako system sam w sobie | \nLLM modeluje pismo, nie umysł; dane treningowe = jedyne źródło | \n
| Lotman | \nSemiosfera - ekologia znaków | \nDane treningowe to przekrój semiosfery; LLM nawiguje po strefach | \n
| Eco | \nDzieło otwarte | \nOutput LLM nie ma jednego znaczenia - wymaga Waszej interpretacji | \n
graph TD\n subgraph "Semiotyczna perspektywa na LLM"\n SAU["Saussure<br/> znaczenie = relacja"] --> EMB["Embeddingi<br/>wektory = pozycje relacyjne"]\n PEI["Peirce<br/>znak → obiekt → interpretant"] --> HOM["Hall of Mirrors<br/>brak dostępu do obiektu"]\n DER["Derrida<br/>pismo jest fundamentem"] --> DAT["Dane treningowe<br/>= pismo, nie umysł"]\n LOT["Lotman<br/>semiosfera"] --> NAV["LLM nawiguje<br/>po strefach semiosfery"]\n ECO["Eco<br/>dzieło otwarte"] --> INT["Output wymaga<br/>interpretacji człowieka"]\n end\n \n style SAU fill:#ff9999,color:#000\n style PEI fill:#ffcc99,color:#000\n style DER fill:#ffff99,color:#000\n style LOT fill:#99ff99,color:#000\n style ECO fill:#9999ff,color:#fff\nWięc: LLM nie ma umysłu. Ale to nie znaczy, że nie robi nic interesującego. LLM operuje na znakach - rekonfiguruje je, łączy strefy semiosfery, tworzy nowe konfiguracje znaków. I te nowe konfiguracje dla nas - jako interpretatorów - mają znaczenie.
\nTo jest semiotyczna odpowiedź na pytanie "czy LLM rozumie?". LLM nie "rozumie" w ludzkim sensie. Ale generuje znaki, które wchodzą w naszą semiosferę i stają się częścią naszego procesu interpretacji. I ten proces jest prawdziwy, ważny i potężny.
\nWiem, że semiotyka na początku brzmi jak coś z innej planety, ale mam nadzieję, że teraz widzicie, jak to się łączy z LLM.
\nKórą koncepcję semiotyczną uważacie za najbardziej przydatną do zrozumienia LLM? Saussure i jego relacyjność? Peirce i jego hala luster? A może Derrida i jego "pismo"?
\nBo szczerze mówiąc - ja się dopiero uczę tej perspektywy. Ale czuję, że to jest ten moment, gdzie lingwistyka, filozofia i programowanie spotykają się w jednym miejscu i tworzą coś naprawdę fascynującego.
\n\n\nCo w następnym wpisie? Przechodzimy od teorii do praktyki: Jak komputer czyta tekst - od liczenia słów do wektorów. Zobaczymy jak tokenizacja, TF-IDF, łańcuchy Markowa i Word2Vec realizują w kodzie to, o czym mówili Saussure (znaczenie jest relacyjne!) i Derrida (pismo jest systemem samym w sobie!).
\n
Do następnego!
\nŹródła i ciekawe linki:
\nJeśli chcecie wejść głębiej, oto materiały, z których korzystałem:
\nOdpowiedzi: 1) indeks (przyczynowo-skutkowy - temperatura powoduje rozszerzenie cieczy), 2) ikona (podobieństwo do psa), 3) symbol (czysta konwencja), 4) indeks (fizyczny ślad kogoś, kto tu przeszedł), 5) ikona (podobieństwo do osoby na wózku). ↩
\nMoje odpowiedzi: 1) Peirce - model nie ma dostępu do obiektu (doświadczenia poezji), ale generuje representameny (tekst), które interpretujemy. 2) Saussure - to jest czysta relacyjność! Król jest definiowany przez to, czym nie jest. 3) Peirce - kontekst zmienia interpretację, a interpretant tworzy nowy znak. 4) Peirce - brak obiektu w triadzie. 5) Peirce + Lotman - model reprodukuje znaki z semiosfery medycznej bez dostępu do rzeczywistego obiektu (ciała pacjenta). Diagnoza jest znakiem bez zakotwiczenia. ↩
\nLLM (Large Language Models, czyli takie ChatGPT, Claude, Gemini i spółka) jest już z nami od jakiegoś czasu i stwierdziłem, że zacznę głębiej wchodzić w ten temat i pojawiło się jedno wielkie pytanie: ale jak to w ogóle działa, że model "rozumie" język? Bo przecież pod spodem to tylko "matematyka i statystyka", prawda? No... tak i nie ;-)
\nI wtedy wpadłem na lingwistykę. I okazało się, że żeby naprawdę zrozumieć, co LLM robi z językiem, trzeba najpierw zrozumieć, z czego ten język się składa. A że programista próbujący czytać o lingwistyce to dość zabawny obrazek, to pomyślałem: podzielę się tym z wami ;-)
\nTo jest pierwszy wpis z serii, w której będziemy przeglądać różne poziomy analizy języka i patrzeć, jak to wszystko łączy się z LLM. W dzisiejszym wpisie zbudujemy fundament - poznamy pięć głównych warstw języka i zobaczymy, dlaczego każda z nich jest ważna dla modeli językowych.
\nZanim wejdziemy w szczegóły, wyobraźcie sobie język jako taką... cebulę. Albo tort warstwowy, jeśli wolicie słodkie metafory :D
\nKażda warstwa to inny poziom, na którym język "działa". Od najniższej - dźwięków - do najwyższej - tego, co naprawdę chcieliśmy powiedzieć, nawet jeśli powiedzieliśmy coś zupełnie innego.
\ngraph TD\n A["🔊 Fonetyka i fonologia<br/><i>dźwięki i system dźwięków</i>"] --> B["🧩 Morfologia<br/><i>budowa słów</i>"]\n B --> C["📐 Składnia<br/><i>budowa zdań</i>"]\n C --> D["💡 Semantyka<br/><i>znaczenie</i>"]\n D --> E["🎭 Pragmatyka<br/><i>znaczenie w kontekście</i>"]\n \n style A fill:#ff9999,color:#000\n style B fill:#ffcc99,color:#000\n style C fill:#ffff99,color:#000\n style D fill:#99ff99,color:#000\n style E fill:#9999ff,color:#000\nPięć warstw, pięć sposobów, na jakie język jest "analizowany". I uwaga - LLM musi sobie z każdym z tych poziomów radzić, żeby wydawać się sensownym rozmówcą. Oczywiście nie robi tego świadomie - ale struktury, których uczy się w trakcie treningu, jakoś te warstwy "łapią".
\nNote
\nPięć warstw języka w pigułce:
\nOK, przejdźmy do rzeczy. Zaczynamy od dołu naszej cebulki ;-)
\nFonetyka bada dźwięki mowy jako zjawiska fizyczne. Mówiąc najprościej: jak produkujemy dźwięki, jak one podróżują przez powietrze i jak je odbieramy.
\nMa trzy gałęzie:
\n| Gałąź | \nCo bada | \nPrzykład | \n
|---|---|---|
| Artykulacyjna | \nJak narządy mowy produkują dźwięki | \nGdzie jest język, gdy mówisz "sz"? | \n
| Akustyczna | \nFizyczne właściwości fal dźwiękowych | \nCzęstotliwość, amplituda | \n
| Audytywna | \nJak ucho i mózg odbierają dźwięki | \nJak ślimak przetwarza fale na sygnał nerwowy | \n
Fonologia to poziom wyżej. Nie interesują jej same dźwięki jako fizyczne zjawiska, ale jak dźwięki są zorganizowane w konkretnym języku.
\nKluczowe pojęcie: fonem - to najmniejsza jednostka dźwiękowa, która odróżnia znaczenie słów.
\nProsty przykład po polsku:
\nAlbo po angielsku:
\nTip
\nEksperyment: Wymów na głos "kot" raz jako zwykłe zdanie ("Mój kot śpi."), a raz jako pytanie z zaskoczeniem ("Kot?!" z uniesionymi brwami). Ten sam wyraz, ale intonacja, akcent i melodia całkowicie zmieniają to, co "słyszy" odbiorca. To jest właśnie fonologia w działaniu - dźwięki + ich organizacja w system.
\nNo właśnie - LLM dostaje tekst, nie dźwięk. Nigdy nie usłyszał wymowy. A mimo to...
\nCzyli model jakoś przyswaja informacje fonologiczne z samych danych tekstowych. Trochę jakbyś nigdy nie widział oceanu, ale przeczytał o nim tyle książek, że potrafisz go opisać ;-)
\nNo ale oczywiście są ograniczenia. LLM tekstowy nie rozróżnia homofonów (słów, które brzmią tak samo, ale znaczą co innego) na podstawie fonetyki - radzi sobie z nimi czysto na poziomie semantycznym (o czym za chwilę).
\nI tu ciekawostka: modele typu Whisper (speech-to-text od OpenAI) już łączą fonetykę z tekstem. Ale to temat na osobny wpis w tej serii ;-)
\nWarning
\nParadoks: LLM nigdy nie słyszał żadnego dźwięku, ale z danych treningowych "wie" o rymach, grach słownych i wzorcach brzmieniowych. To trochę jak osoba głucha od urodzenia, która potrafi pisać wiersze z rymami - bo przeczytała ich miliony.
\nMorfologia bada budowę słów - jak są one składane z mniejszych, sensownych kawałków zwanych morfemami.
\nMorfem to najmniejsza jednostka języka, która niesie ze sobą znaczenie. Nie da się jej podzielić na coś jeszcze mniejszego, co miałoby znaczenie.
\nPrzykład z angielskiego, często używany w podręcznikach:
\nunhappiness = un + happy + ness\n ↑ ↑ ↑\n „nie" „szczęśliwy" rzeczownik\nAlbo po polsku:
\nnieszczęśliwy = nie + szczęśliw + y\n ↑ ↑ ↑\n „nie" „szczęście" rodzaj męski\nAlbo jeszcze bardziej:
\nnieprzystojny = nie + przy + stoj + ny\nKażdy z tych kawałków ma swoje znaczenie. To są właśnie morfemy.
\n| Typ | \nOpis | \nPrzykłady | \n
|---|---|---|
| Wolne | \nMogą stać samodzielnie jako słowo | \nkot, dom, biegnie | \n
| Związane | \nMuszą być dołączone do innego morfemu | \nnie-, -ek, -owie, -ować | \n
A wśród morfemów związanych mamy afiksy:
\nTo ważne rozróżnienie:
\nFleksja (odmiana) - zmienia formę gramatyczną, ale nie tworzy nowego słowa:
\nSłowotwórstwo (derywacja) - tworzy nowe słowo, często zmieniając część mowy:
\nWarning
\nPolska morfologia to koszmar dla LLM! Język polski jest silnie fleksyjny - mamy 7 przypadków, 2 liczby, 3 rodzaje, aspekty czasowników, i mnóstwo wyjątków. Dla porównania: w angielskim odmiana rzeczownika to max. dodanie -s. W polskim? "Dom, domu, domowi, dom, domem, domu, domie, domy, domów..." i tak dalej :D
\nTu jest ciekawostka. LLM nie "wie" czym są morfemy. Używa tokenizacji BPE (Byte Pair Encoding), która dzieli tekst na tokeny - ale tokeny to nie to samo co morfemy.
\ngraph LR\n subgraph "Lingwista widzi:"\n A["nie-szczęśliw-y"] --> A1["nie + szczęśliw + y"]\n end\n subgraph "GPT-4o widzi (tokenizacja BPE):"\n B["nie-szczęśliw-y"] --> B1["nie + -s + zcz + ę + śli + wy"]\n end\n \n style A1 fill:#99ff99,color:#000\n style B1 fill:#ff9999,color:#000\nTokenizator BPE dzieli tekst na podstawie częstotliwości występowania w danych treningowych, a nie na podstawie struktury językowej. Czasem to się pokrywa z morfemami, a czasem nie.
\nTo znaczy, że model nie uczy się morfologii "od strony" - on uczy się jej pośrednio, przez statystykę. I jakoś mu to działa ;-)
\nTip
\nZabawa dla was: Potraficie rozbić te słowa na morfemy?
\nSkładnia to zbiór reguł, które określają, jak słowa są łączone w zdania. To dzięki składni wiemy, że "Kot siedzi na macie" to poprawne zdanie, a "Kot macie na siedzi" to bełkot.
\nProste? No... bardziej albo mniej ;-)
\nW różnych językach obowiązują różne zasady porządku słów:
\n| Język | \nPodstawowy szyk | \nPrzykład | \n
|---|---|---|
| Angielski | \nSVO (Subject-Verb-Object) | \nThe cat sits on the mat | \n
| Polski | \n"Elastyczny" SVO, ale... | \nKot siedzi na macie / Na macie siedzi kot / Siedzi kot na macie | \n
| Japoński | \nSOV | \n猫がマットの上に座っている | \n
| Łacina | \nWolny (bo końcówki mówią wszystko) | \nFelix in tapete sedet | \n
Polski jest fajny, bo mamy dość dużą swobodę w szyku zdania. O ile w angielskim "On the mat sits the cat" brzmi poetycko albo nienaturalnie, o tyle u nas to normalne zdanie ;-)
\nZdania mają strukturę hierarchiczną - słowa grupują się w frazy, a frazy w większe frazy. Można to narysować jako drzewo:
\ngraph TD\n S["S (zdanie)"] --> NP1["NP (fraza rzeczownikowa)"]\n S --> VP["VP (fraza czasownikowa)"]\n NP1 --> N1["Kot"]\n VP --> V["siedzi"]\n VP --> PP["PP (fraza przyimkowa)"]\n PP --> P["na"]\n PP --> NP2["NP (fraza rzeczownikowa)"]\n NP2 --> N2["macie"]\n \n style S fill:#9999ff,color:#fff\n style NP1 fill:#99ff99,color:#000\n style VP fill:#ffcc99,color:#000\n style PP fill:#ff9999,color:#000\nTo jest proste zdanie "Kot siedzi na macie" i już ma swoją hierarchię! A wyobraźcie sobie zdania z podrzędnymi, imiesłowami, okolicznikami...
\nTo słynny przykład Noama Chomsky'ego (w oryginale: "Colorless green ideas sleep furiously").
\nZdanie jest składniowo poprawne - ma podmiot, orzeczenie, prawidłową strukturę. Ale semantycznie to kompletny absurd - idee nie mogą być zielone ani spać.
\nI to jest właśnie dowód na to, że składnia i semantyka to dwa różne poziomy. Można mieć perfekt składnię i zero sensu ;-)
\nImportant
\nSkładnia to supermoc LLM. Model uczy się przewidywać następny token na podstawie ogromnej ilości danych tekstowych. W trakcie tego procesu przyswaja wzorce składniowe - wie, że po "Kot siedzi na..." spodziewamy się rzeczownika, a po "Szybko..." czasownika. To jest fundament tego, dlaczego LLM generuje poprawne gramatycznie zdania.
\nSprawdźcie się - które zdania są składniowo poprawne?1
\nJeśli składnia pyta "jak to jest zbudowane?", to semantyka pyta: "co to znaczy?"
\nSemantyka bada znaczenie słów, fraz i zdań. I od razu się okazuje, że to wcale nie jest takie proste.
\nKlasyczny polski przykład: zamek
\nTo samo słowo, cztery zupełnie różne znaczenia. Jak LLM wie, o który chodzi? Z kontekstu. I to jest właśnie to, co robi dobrze - bo widział miliony zdań, gdzie "zamek" występował w różnych kontekstach.
\nAlbo inny klasyk - wieloznaczność w jednym zdaniu:
\n\n\n"Moja droga, ta droga jest bardzo droga."
\n
Trzy razy to samo słowo, trzy różne znaczenia: droga (zwrócenie się do kogoś), droga (ulica/szlak), droga (tania -> droga, przymiotnik). Kontekst zmienia wszystko ;-)
\nPrawie. Ale nie do końca:
\nSemantyka bada te subtelne różnice - zarówno denotację (dosłowne znaczenie), jak i konotację (skojarzenia, nacechowanie emocjonalne).
\nTu wchodzi koncept word embeddings (osadzeń słów). W dużym uproszczeniu: każde słowo jest reprezentowane jako wektor - ciąg liczb - w wielowymiarowej przestrzeni. Słowa o podobnym znaczeniu są "blisko" siebie w tej przestrzeni.
\nSłynny przykład, który prawdopodobnie widzieliście:
\nwektor("król") - wektor("mężczyzna") + wektor("kobieta") ≈ wektor("królowa")\nCzyli: model "wie", że relacja między "król" a "mężczyzna" jest analogiczna do relacji między "królowa" a "kobieta". I to z samych danych, nikt go tego nie uczył!
\nMożemy to nawet pokazać w kodzie. Oto prosty przykład z biblioteką gensim w Pythonie:
from gensim .downloader import load \n\nmodel = load ("glove-wiki-gigaword-50" )\n\nresult = model .most_similar (\n positive = ["king" , "woman" ],\n negative = ["man" ],\n topn = 3 \n)\n\nprint (result )\n# [('queen', 0.85), ...] -- na pierwszym miejscu: queen! Tip
\nJeśli chcecie to przetestować sami: zainstalujcie gensim (pip install gensim) i odpalcie powyższy kod. Oczywiście potrzebujecie trochę RAM-u - model GloVe nie jest mały. Ale efekt jest naprawdę satysfakcjonujący ;-)
Jedno z najważniejszych pojęć w semantyce: znaczenie zdania jest wynikiem znaczeń poszczególnych słów + zasad ich łączenia.
\nCzyli: "Czerwony kot siedzi na macie" = [czerwony] + [kot] + [siedzi] + [na] + [macie] + zasady składniowe.
\nBrzmi banalne, ale to potężna zasada. Dzięki niej potrafimy zrozumieć nieskończoną liczbę zdań, nawet takich, których nigdy wcześniej nie słyszeliśmy. I dzięki niej LLM potrafi generować nowe, niespotykane zdania, które i tak mają sens.
\nWarning
\nAle uwaga: "Zrozumiałem, że nie zrozumiałeś, że to nie było zrozumiałe." - każde słowo jest proste, ale zdanie jako całość wymaga przeanalizowania warstwy po warstwie. Kompozycyjność to potężne narzędzie, ale ma swoje granice.
\nI tak dochodzimy do najciekawszej (według mnie) warstwy. Pragmatyka bada to, jak kontekst wpływa na znaczenie wypowiedzi - co naprawdę chcemy powiedzieć, często mówiąc coś zupełnie innego.
\nJeśli semantyka pyta "co to znaczy?", pragmatyka pyta: "co autor miał na myśli w tej konkretnej sytuacji?"
\nScenka 1: "Zimno tu."
\nSemantycznie: informacja o temperaturze w pomieszczeniu.
\nPragmatycznie: "Zamknij okno!" albo "Zwiększ ogrzewanie!" albo "Daj mi koc."
Każdy z was zrozumie, że kiedy ktoś mówi "Zimno tu" w momencie, gdy stoi przy otwartym oknie - nie pytasz o stopnie Celsjusza, tylko zamykasz okno.
\nScenka 2: "Mógłbyś podać sól?"
\nSemantycznie: pytanie o twoją zdolność podania soli.
\nPragmatycznie: prośba o podanie soli.
Odpowiedź "Tak, mógłbym" (i nic więcej) jest semantycznie poprawna, ale pragmatycznie... no, jesteś trochę niemiły ;-)
\nScenka 3: Ironia
\n\n\n"No gratulacje, znowu to zepsułeś."
\n
Semantycznie: gratulacje.
\nPragmatycznie: ironia, krytyka, rozczarowanie.
Czy LLM łapie ironię? Czasem tak, czasem nie. To wciąż otwarty problem badawczy.
\nFilozof J.L. Austin wymyślił coś genialnego: wypowiedzi nie tylko opisują rzeczywistość, ale też coś robią.
\n| Typ aktu mowy | \nOpis | \nPrzykład | \n
|---|---|---|
| Lokucyjny | \nSamo wypowiedzenie | \nMówisz "Zamykam okno" | \n
| Illokucyjny | \nIntencja wypowiedzi | \nObiecanie, że zamkniesz okno | \n
| Perlokucyjny | \nEfekt na odbiorcę | \nSłuchacz czuje ulgę | \n
Inne przykłady aktów mowy:
\nPaul Grice, inny filozof języka, zauważył, że w rozmowie obowiązuje zasada współpracy - mówimy rzeczy, które są istotne, prawdziwe, jasne i na temat.
\nKiedy ktoś tę zasadę łamie, szukamy implikatury - ukrytego znaczenia.
\nPrzykład:
\n\n\nA: "Idziesz na imprezę?"
\n
\nB: "Mam egzamin jutro."
B nie odpowiedział "tak" ani "nie". Ale z kontekstu A rozumie: nie idę, bo muszę się uczyć. To jest implikatura konwersacyjna.
\nWarning
\nTo jest najtrudniejsza warstwa dla LLM. I to nie jest tylko moje zdanie - badacze z całego świata pracują nad benchmarkami testującymi pragmatykę modeli językowych.
\nProblemy:
\nAle z drugiej strony - GPT-4 i nowsze modele radzą sobie coraz lepiej. Dlaczego? Bo ogromna ilość danych treningowych zawiera pragmatykę w praktyce - dialogi z filmów, książek, forów internetowych. Model "widział" miliony przykładów ironii, grzeczności, próśb.
\nTip
\nEksperyment dla was: Otwórzcie ChatGPT (albo Claude, albo co tam macie pod ręką) i przeprowadźcie ten krótki test:
\nNapiszcie modelowi:
\n"Właśnie strzeliłem sobie w palca gwoździem."
\nA potem od nowej rozmowy:
\n"No gratulacje, znowu strzeliłem sobie w palca gwoździem!"
\nZobaczcie, czy model zauważy, że w drugim przypadku "gratulacje" to ironia, czy jednak zacznie wzywać pogotowie?
\nOto nasze pięć warstw, w pigułce:
\n| Warstwa | \nCo bada | \nPrzykład | \nJak radzi sobie LLM | \n
|---|---|---|---|
| Fonetyka i fonologia | \nDźwięki i system dźwięków | \n/kot/ vs /lot/ | \nNie słyszy, ale "wie" z danych tekstowych | \n
| Morfologia | \nBudowa słów z morfemów | \nnie-szczęśliw-y | \nTokenizacja BPE ≠ morfemy, ale jakoś działa | \n
| Składnia | \nPorządek słów w zdaniu | \nKot siedzi na macie | \nSupermoc modelu - świetnie radzi sobie z gramatyką | \n
| Semantyka | \nZnaczenie słów i zdań | \n"zamek" - który? | \nWord embeddings + kontekst | \n
| Pragmatyka | \nZnaczenie w kontekście | \n"Zimno tu" = zamknij okno | \nNajtrudniejsza warstwa, wciąż otwarty problem | \n
graph LR\n subgraph "Jak LLM przetwarza język"\n F["Fonetyka<br/>❌ nie słyszy"] --> M["Morfologia<br/>⚠️ przez pryzmat tokenów"]\n M --> S["Składnia<br/>✅ bardzo dobrze"]\n S --> Sem["Semantyka<br/>✅ dobrze, z wyjątkami"]\n Sem --> P["Pragmatyka<br/>❓ najtrudniejsza"]\n end\nW kolejnym wpisie zmieniamy perspektywę - zamiast patrzeć na warstwy języka, patrzymy na samą naturę znaków i znaczenia:
\n\n\nJeśli dotarliście aż tu - dzięki! ;-) Naprawdę doceniam, że poświęciliście czas na przeczytanie tego potworka.
\nMam nadzieję, że choć trochę przybliżyłem wam temat. Jeśli coś jest niejasne - napiszcie w komentarzach, postaram się wyjaśnić. A jeśli macie lepsze przykłady (bo na pewno macie!) - tym bardziej dajcie znać.
\nKtóra warstwa was najbardziej zaskoczyła? Która jest waszym zdaniem najciekawsza w kontekście AI?
\nDo następnego wpisu!
\nŹródła i ciekawe linki:
\nJeśli chcecie wejść głębiej, oto materiały, z których korzystałem przy pisaniu tego wpisu:
\nOdpowiedzi do quizu: zdania 1-3 i 5 są poprawne (różnią się szykiem, ale polski na to pozwala; 5 to pytanie z słówkiem "czy"). Zdanie 4 ("Pies listonosza na szczeka") jest niepoprawne składniowo - szyk jest tak zaburzony, że nie spełnia zasad polskiej gramatyki. ↩
\n