Wrzucasz zdjęcie faktury i dostajesz poprawnie wyciągnięte dane. Wygląda na jedną rzecz. Pod spodem mogą być dwie zupełnie różne architektury i różnica jest niewidoczna z zewnątrz — dopóki nie trafisz na przypadek, w którym jedna działa, a druga nie.
To rozróżnienie mylone jest najczęściej ze wszystkich w tej serii, więc zacznijmy od postawienia go wprost.
Modalność to cecha modelu, nie warstwa nad nim
Model natywnie multimodalny przyjmuje obraz, dźwięk i tekst w jednej przestrzeni wektorowej, bo tak został wytrenowany. Obraz nie jest w nim nigdzie opisywany słowami. Jest zamieniany na wektory i model „widzi” go równie bezpośrednio jak zdanie.
Pipeline modeli jednomodalnych to co innego. Agent wysyła obraz do osobnego modelu wizyjnego, dostaje opis tekstowy, podaje go modelowi językowemu. Tu faktycznie istnieje warstwa narzędzi — ale należy ona do agenta, nie do modelu.
Obie architektury odpowiadają na „co jest na tym zdjęciu?”. Tylko jedna z nich naprawdę je widziała.
Jak obraz wchodzi do modelu
W artykule o tokenizacji ustaliliśmy, że tekst jest cięty według stałego słownika zbudowanego na statystyce. Przy obrazie jest inaczej i ta różnica jest ciekawsza, niż się wydaje.
Nie ma żadnego słownika. Obraz jest dzielony na kwadraciki po stałej siatce — czysto mechanicznie, bez żadnej listy. Każdy kwadracik trafia prosto do wyuczonych wag, które robią z niego wektor. Nie istnieje coś takiego jak „token numer 5847 oznacza ten fragment obrazu”.
Konsekwencja jest bardzo praktyczna: liczba tokenów obrazu wynika z rozdzielczości, nie z tego, co na obrazie widać. Pusta biała kartka w wysokiej rozdzielczości kosztuje więcej niż gęsty wykres w niskiej. Przy tekście płacisz za treść, przy obrazie za piksele.
To jest miejsce, w którym najłatwiej przepalić budżet, nie zauważając tego. Zdjęcia z telefonu wysyłane w oryginale potrafią zjeść wielokrotność tego, co byłoby potrzebne — a różnicy w jakości odpowiedzi często nie ma żadnej, bo dokument i tak jest czytelny w połowie rozmiaru.
Co ginie w pipelinie
Wróćmy do dwóch architektur, bo teraz widać, na czym polega różnica.
W pipelinie modelowi językowemu zostaje cudzy opis obrazu, a nie obraz. O tym, co przetrwa, decyduje model pośredni — a on nie wie, o co zapyta użytkownik. Opis powstał, zanim padło pytanie.
Ginie więc wszystko, czego opisujący nie uznał za warte wymienienia. Układ dokumentu, kiedy liczy się to, która kwota stoi w której kolumnie. Niepokojący szczegół na zdjęciu, o który nikt nie prosił. Ton głosu w nagraniu. Wrażenie, że z wykresem coś jest nie tak, choć wszystkie liczby są poprawne.
Pipeline ma za to trzy zalety, które w produkcji ważą sporo. Jest tańszy, bo model wizyjny może być mały i wyspecjalizowany. Jest wymienialny — można podmienić OCR bez ruszania reszty. I jest audytowalny: widzisz dokładnie, co poszło dalej, co przy dokumentach regulowanych bywa wymogiem, a nie wygodą.
W praktyce większość wdrożeń produkcyjnych jest hybrydą: model multimodalny w rdzeniu, plus narzędzia jednomodalne tam, gdzie są dokładniejsze albo tańsze. Klasyczny OCR wciąż bije modele multimodalne w wiernym przepisywaniu długiego tekstu — model rozumie dokument lepiej, ale przepisuje go mniej dosłownie.
Wyjście też nie musi być tekstem
Warto tu poprawić sformułowanie, które w obiegu funkcjonuje jako oczywistość.
„Tekst wchodzi, tekst wychodzi” jest prawdziwe wyłącznie dla klasycznego modelu językowego. Modele generujące obraz czy mowę nie wypluwają opisu — zwracają tokeny, które osobny dekoder zamienia w piksele albo w falę dźwiękową. Symetrycznie do enkodera na wejściu.
Niezmiennik jest inny i przetrwa wszystkie modalności: model przewiduje kolejny element ciągu. Zmienia się to, co ten ciąg reprezentuje. Nie zmienia się to, co model z nim robi.
I stąd bierze się też fakt, o którym wspominaliśmy w artykule pierwszym: „language” w nazwie to relikt po pierwszych modelach obsługujących wyłącznie tekst. Nazwa została, zakres dawno się rozszerzył.
Trzy rzeczy, o których warto wiedzieć przed wdrożeniem
Obraz jest kanałem ataku. To najważniejsza rzecz w tym artykule i najczęściej pomijana. Skoro model natywnie odczytuje tekst z obrazu, to tekst umieszczony na obrazie ma dokładnie ten sam status co twój prompt — jest ciągiem tokenów w tej samej sekwencji. Instrukcja napisana drobnym drukiem na skanie faktury trafia do modelu tak samo jak polecenie od użytkownika. Filtrowanie treści tekstowych nie zobaczy jej w ogóle. To rozszerzenie problemu opisanego w artykule o zatrutym kontekście na kanał, którego zwykle nikt nie sprawdza.
Halucynacje działają tak samo na obrazie. Model równie przekonująco odczyta kwotę, której na dokumencie nie ma, jak zmyśla parametr funkcji. Wszystko z poprzedniego artykułu stosuje się bez zmian — z tą różnicą, że sprawdzenie wymaga zajrzenia w oryginał, a to bariera, której ludzie zwykle nie przekraczają.
Rozdzielczość to decyzja kosztowa. Warto ją podejmować świadomie: zmniejszać obrazy przed wysłaniem, testować, przy jakim rozmiarze jakość odpowiedzi jeszcze nie spada, i nie wysyłać oryginałów z aparatu, jeśli nie ma po temu powodu.
A co ze stroną internetową
Jest tu wniosek, który wypada wprost z mechanizmu, a dotyczy tego, co robisz na co dzień.
Agent odwiedzający twoją stronę widzi ją przez tekst — pobiera dokument, nie zrzut ekranu. Cała treść zamknięta w obrazkach jest dla niego niewidoczna, chyba że ktoś świadomie wyśle grafikę do modelu multimodalnego, co kosztuje i rzadko dzieje się automatycznie.
Infografika z kluczowymi danymi, cennik jako obrazek, schemat wyjaśniający produkt, tekst wtopiony w baner — to wszystko w praktyce nie istnieje. Opis alternatywny i podpis przestają być kwestią dostępności, a stają się jedynym kanałem, którym ta treść w ogóle dociera dalej.
To ta sama zasada, o której pisaliśmy przy tokenizacji, tylko od drugiej strony: nie chodzi o to, żeby treści było mniej, tylko żeby była w formie, którą da się przeczytać.
Jak to sprawdzić u siebie
Ćwiczenie pokazuje, że płacisz za piksele, nie za treść. Ten sam obraz w dwóch rozmiarach, porównanie liczby tokenów wejściowych.
import base64, io
from PIL import Image
from openai import OpenAI
client = OpenAI()
def tokeny(sciezka, szerokosc):
img = Image.open(sciezka)
skala = szerokosc / img.width
img = img.resize((szerokosc, int(img.height * skala)))
bufor = io.BytesIO()
img.save(bufor, format="PNG")
b64 = base64.b64encode(bufor.getvalue()).decode()
r = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": [
{"type": "text", "text": "Opisz jednym zdaniem, co to za dokument."},
{"type": "image_url",
"image_url": {"url": f"data:image/png;base64,{b64}"}},
]}],
max_tokens=60,
)
return r.usage.prompt_tokens, r.choices[0].message.content.strip()
for szerokosc in [1600, 1000, 640]:
t, opis = tokeny("faktura.png", szerokosc)
print(f"{szerokosc}px {t:5} tokenów {opis[:60]}")Podstaw własny dokument. Zobaczysz, jak liczba tokenów spada wraz z rozdzielczością — i najprawdopodobniej zobaczysz też, że odpowiedź pozostaje poprawna znacznie niżej, niż zakładałeś.
Drugie ćwiczenie, jeśli chcesz zobaczyć różnicę między architekturami: przepuść ten sam dokument przez zwykły OCR, a jego wynik tekstowy podaj modelowi. Potem zadaj oba razy pytanie o coś, co wynika z układu strony, a nie z samych słów — na przykład która pozycja stoi w kolumnie z rabatem. Model natywny zwykle odpowie, pipeline zgadnie.
Co dalej
Wiemy już, co wchodzi do modelu i co z tego wychodzi. Pozostaje policzyć, ile to kosztuje przy dłuższych przebiegach — i zobaczyć mechanizm, dzięki któremu generowanie długiej odpowiedzi w ogóle jest wykonalne, a który jednocześnie odpowiada za to, że długi kontekst tak boli.
O tym jest artykuł dziewiąty: Dlaczego długi kontekst jest drogi — KV cache i koszt kwadratowy.
