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). ↩
\n