Ewaluacja multimodalna: jak testować modele, które czytają obrazy, wykresy i skany umów

1. Wprowadzenie: czym jest ewaluacja multimodalna i dlaczego różni się od tekstowej

Ewaluacja multimodalna to ocena modeli, które przetwarzają jednocześnie więcej niż jeden typ danych wejściowych — najczęściej tekst oraz obraz w różnych odmianach: zdjęcia, zrzuty ekranu, wykresy, tabele, skany dokumentów czy formularze. W praktyce oznacza to sprawdzanie nie tylko tego, czy model „dobrze pisze”, ale przede wszystkim, czy potrafi poprawnie zinterpretować informacje wizualne, powiązać je z pytaniem i wygenerować odpowiedź, która jest zgodna z tym, co faktycznie znajduje się na obrazie.

W przypadku modeli tekstowych ewaluacja koncentruje się na jakości rozumowania, zgodności z faktami (w obrębie dostarczonego kontekstu) oraz spójności językowej. W świecie multimodalnym dochodzi dodatkowa warstwa: percepcja. Model musi „zobaczyć” właściwe elementy (np. wartość w komórce tabeli, podpis osi, numer paragrafu na skanie) i nie pomylić ich z elementami podobnymi lub mylącymi (np. przypisem, legendą, nagłówkiem, pieczątką). To sprawia, że błąd może wynikać z różnych przyczyn: złego odczytu, błędnej lokalizacji informacji, niewłaściwej interpretacji, a dopiero na końcu z problemu stricte językowego.

Kluczowe różnice względem ewaluacji tekstowej wynikają z tego, że w danych wizualnych znaczenie jest silnie zależne od układu i kontekstu przestrzennego. Ten sam tekst na obrazie może oznaczać coś innego w zależności od położenia (nagłówek vs treść), relacji z innymi elementami (etykieta osi vs wartość serii), czy formy zapisu (przekreślenie, dopisek odręczny, pieczęć). Modele muszą też radzić sobie z cechami, które w czystym tekście prawie nie występują: zmienną jakością skanu, czcionkami, zniekształceniami, tłem, kompresją, rotacją czy zasłonięciami.

W efekcie „poprawna odpowiedź” w zadaniach multimodalnych bywa trudniejsza do jednoznacznego zdefiniowania. Czasem chodzi o dokładną wartość (np. liczba z faktury), czasem o wybór właściwej kategorii (np. czy wykres pokazuje trend rosnący), a czasem o streszczenie fragmentu dokumentu z zachowaniem kluczowych warunków. Ocena musi więc uwzględniać zarówno poprawność merytoryczną, jak i wierność względem materiału źródłowego — czyli to, czy odpowiedź jest zakotwiczona w tym, co naprawdę widać na obrazie, a nie w domysłach.

Multimodalna ewaluacja jest szczególnie istotna w zastosowaniach biznesowych i regulowanych, gdzie błędy mają koszt: automatyzacja pracy z dokumentami i umowami, analiza raportów i wykresów, obsługa formularzy, kontrola zgodności czy wsparcie zespołów prawnych i finansowych. W takich scenariuszach nie wystarczy, że model brzmi przekonująco — musi działać przewidywalnie, poprawnie odczytywać dane i unikać nadinterpretacji. Dlatego testowanie multimodalne kładzie nacisk na to, czy model widzi to, co powinien, czy rozumie relacje między elementami oraz czy potrafi ograniczyć odpowiedź do informacji dostępnych w materiale.

• Tekst: oceniamy głównie rozumienie treści i generację.
• Multimodalność: oceniamy dodatkowo percepcję, układ, odczyt i interpretację elementów wizualnych.
• Ryzyko błędu: rośnie przez degradacje jakości, złożone układy dokumentów oraz wieloznaczność wykresów i tabel.
• Wymóg praktyczny: odpowiedzi muszą być zgodne z dowodami widocznymi w materiale, nie tylko językowo poprawne.

2. Definicja zakresu i taksonomia zadań

Zanim da się sensownie ocenić model multimodalny, trzeba precyzyjnie ustalić zakres: jakie typy danych wejściowych obsługujemy, jakie zadania uznajemy za „poprawnie wykonane” oraz jaki rodzaj odpowiedzi ma być produkowany (tekst swobodny, wartości liczbowe, pola strukturalne). W multimodalności źródłem niejednoznaczności jest to, że „obraz” może oznaczać zarówno scenę fotograficzną, jak i skan dokumentu czy wykres, a każde z tych źródeł wymusza inne oczekiwania wobec modelu i inne sposoby testowania. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

2.1. Klasy wejść: obrazy, wykresy, dokumenty

• Obrazy naturalne (np. zdjęcia): nacisk pada na rozpoznawanie obiektów, relacji przestrzennych, atrybutów (kolor, liczność, położenie) i kontekstu. Odpowiedzi są często opisowe lub oparte na wnioskowaniu z widocznych elementów.
• Wykresy i wizualizacje danych: kluczowe jest odczytanie encji „danych” ukrytych w grafice (osie, skala, legenda, serie), a nie tylko opis wyglądu. Zastosowania obejmują odczyt wartości, trendów, porównań i anomalii; błędy bywają subtelne (np. zła interpretacja skali, mylenie serii).
• Dokumenty i skany umów: dominują układ strony, hierarchia (nagłówki, sekcje), elementy formularzy, tabele, przypisy oraz język formalny. Często celem jest odnalezienie konkretnych pól (strony, paragrafy) i zapewnienie zgodności z treścią źródłową.

W praktyce te kategorie się mieszają: umowa może zawierać tabelę, pieczęć i odręczny dopisek; raport może zawierać wykresy i przypisy. Dlatego zakres warto określać także przez komponenty wizualne (tekst drukowany, tekst odręczny, tabele, podpisy, pieczęcie, wykresy) oraz przez warunki pozyskania (skan vs zdjęcie, jakość, perspektywa).

2.2. Poziomy „rozumienia” i typy wyjść

Taksonomia zadań powinna rozróżniać, czy model ma:

• Rozpoznać treść (co jest napisane/namalowane) i zreprodukować ją w tekście.
• Zrozumieć strukturę (gdzie co jest) i odtworzyć relacje: nagłówek–sekcja, komórka–kolumna, etykieta–wartość.
• Zinterpretować znaczenie (co z tego wynika): np. czy wartość spełnia warunek, czy klauzula jest obecna, czy trend rośnie.

Równolegle trzeba ustalić format odpowiedzi: swobodna odpowiedź (opis), krótka odpowiedź (wartość/liczba), klasyfikacja (tak/nie, wybór), albo ekstrakcja do pól (zestaw atrybutów). Te różnice determinują, co uznaje się za błąd: literówka w OCR to inny problem niż błędna interpretacja osi na wykresie.

2.3. OCR vs VQA vs ekstrakcja informacji

W ewaluacji multimodalnej często pojawiają się trzy rodziny zadań, które łatwo pomylić, a powinny być rozdzielone, bo mierzą inne kompetencje modelu:

• OCR (rozpoznawanie tekstu): celem jest możliwie wierne przepisanie tekstu widocznego na obrazie. Minimalizuje się „kreatywność” modelu: liczy się dokładność znaków, zachowanie cyfr, znaków specjalnych i formatów (np. dat, kwot). OCR bywa elementem większego pipeline’u, ale jako zadanie testowe powinien być oceniany osobno, bo nie wymaga rozumowania semantycznego.
• VQA (Visual Question Answering): model odpowiada na pytania dotyczące obrazu. Pytania mogą dotyczyć zarówno treści tekstowej (jeśli na obrazie jest tekst), jak i elementów nienapisanych (np. „ile jest elementów”, „jaki jest kolor”, „czy słupek A jest wyższy od B”). VQA testuje połączenie percepcji i rozumowania w kontekście pytania, a nie tylko odczyt.
• Ekstrakcja informacji (z dokumentów/umów/wykresów): celem jest wydobycie konkretnego zestawu pól lub faktów w ustalonej postaci, często z zachowaniem odniesienia do źródła (np. nazwa strony, data obowiązywania, numer paragrafu, wartości z tabeli, wartości z punktów wykresu). To zadanie zwykle obejmuje: lokalizację właściwego fragmentu, odczyt (OCR), normalizację (np. format daty), a czasem walidację logiczną (np. spójność kwot).

Istotne jest rozgraniczenie, czy test ma sprawdzać sam odczyt (OCR), odpowiedź na pytanie (VQA), czy wydobycie i ustrukturyzowanie danych (ekstrakcja). Mieszanie tych celów w jednym teście utrudnia diagnozę: nie wiadomo wtedy, czy błąd wynika z nieczytelnego tekstu, braku zrozumienia pytania, czy z błędnej normalizacji.

2.4. Zadania specyficzne dla wykresów

Wykresy zasługują na osobne potraktowanie, bo ich „semantyka” jest zakodowana w konwencjach graficznych. Typowe klasy zadań obejmują:

• Odczyt wartości (np. wartość słupka, punkt na wykresie liniowym) oraz odczyt z niepewnością (gdy skala jest gęsta lub rozdzielczość niska).
• Porównania i relacje: większe/mniejsze, różnica, ranking, przecięcia serii.
• Trendy: wzrost/spadek, stabilność, zmiana dynamiki.
• Zrozumienie encji: mapowanie legendy na serię, rozróżnienie osi, jednostek i skali (liniowa vs logarytmiczna).

W zakresie należy jasno zaznaczyć, czy model ma odpowiadać „na oko” (przybliżenia), czy wymagane są wartości precyzyjne, oraz czy dopuszcza się odpowiedzi opisowe, czy wyłącznie liczby.

2.5. Zadania specyficzne dla dokumentów i umów

W dokumentach biznesowych i umowach testy najczęściej dotyczą:

• Klasyfikacji dokumentu (typ, kompletność, obecność załączników) i rozpoznania sekcji (np. warunki płatności, czas trwania, odpowiedzialność).
• Wydobycia pól: stron, dat, kwot, numerów identyfikacyjnych, danych stron umowy, listy obowiązków, limitów, kar umownych.
• Ekstrakcji z tabel i formularzy: pary etykieta–wartość, wiersze pozycji, sumy, stawki.
• Weryfikacji obecności klauzul lub cech (np. czy dokument zawiera określony zapis), gdzie istotna jest ostrożność językowa: podobne brzmienia mogą nieść inne skutki.

W definicji zakresu warto też rozróżnić, czy model ma zwracać cytaty/dowody (dokładne fragmenty), czy wystarczy sama odpowiedź. To rozróżnienie wpływa na to, jak rozumieć „poprawność” w przypadku parafraz lub odpowiedzi częściowych.

2.6. Granice zadania: co jest „widziane”, a co „wywnioskowane”

W multimodalności szczególnie ważne jest ustalenie, czy pytania i wymagania dotyczą wyłącznie informacji jawnie obecnych w obrazie/dokumencie, czy dopuszczają wnioskowanie (np. interpretację skutków zapisu umowy). W testach produktów i systemów zwykle oddziela się:

• Fakty z obrazu: odpowiedzi muszą wynikać bezpośrednio z treści wizualnej.
• Wnioskowanie na podstawie faktów: dopuszcza się logiczne przekształcenia (np. obliczenie sumy, porównanie wartości).
• Wiedzę zewnętrzną: interpretacje wymagające wiedzy spoza dokumentu (np. ocena zgodności prawnej) powinny być oznaczone jako osobny zakres, bo inaczej zaciera się granica między „czyta” a „doradza”.

Taka taksonomia porządkuje projekt testów: wiadomo, czy oceniamy percepcję, rozumienie struktury, ekstrakcję danych, czy bardziej złożone rozumowanie. Bez tego trudno porównywać modele i trudno wyciągać wnioski z błędów.

3. Budowa datasetu testowego: źródła danych, adnotacje, ground truth, podział train/val/test i kontrola jakości

Dataset testowy w ewaluacji multimodalnej musi odzwierciedlać to, co model zobaczy w produkcji: jakość skanów, różne układy dokumentów, typy wykresów, artefakty OCR oraz realne rozkłady klas. W przeciwieństwie do czysto tekstowych benchmarków, tu kluczowe są: warstwa wizualna (piksele), warstwa transkrypcji (OCR) i warstwa semantyczna (odpowiedź/ekstrakcja). Dobrze zaprojektowany dataset pozwala mierzyć nie tylko „czy model odpowiedział”, ale też czy odpowiedział na podstawie właściwego fragmentu obrazu/dokumentu i w jakich warunkach dane przestają być czytelne.

3.1 Źródła danych: skąd brać obrazy, wykresy i dokumenty

Najlepsze źródła to te, które dają legalną możliwość użycia oraz reprezentują różnorodność formatów. W praktyce warto łączyć kilka strumieni danych, aby uniknąć datasetu „ładnych przykładów” i uzyskać trudne przypadki brzegowe.

• Dane własne/produkcyjne (po anonimizacji) – najbardziej realistyczne: skany umów, załączniki, zrzuty ekranów, wykresy z raportów. Zaleta: zgodność z domeną; wada: koszt anonimizacji i ryzyko wycieku danych wrażliwych.
• Dane publiczne – dokumenty urzędowe, publikacje naukowe, raporty PDF, materiały edukacyjne. Zaleta: łatwiejsza zgodność prawna; wada: mogą mieć inny „styl” niż dokumenty firmowe.
• Dane syntetyczne – generowane dokumenty, wykresy, tabele, skany z kontrolowanymi zniekształceniami. Zaleta: kontrola pokrycia przypadków; wada: ryzyko zbyt „czystych” wzorców i braku realizmu.
• Dane mieszane – np. realne tła/układy + syntetycznie wstawiane wartości, podpisy, pieczęcie (z zachowaniem zasad prywatności). To często kompromis między realizmem a kontrolą.

3.2 Projekt pokrycia: co musi znaleźć się w zbiorze

Zanim zacznie się adnotacje, warto spisać minimalne „pokrycie” datasetu, czyli listę cech, które mają wystąpić w testach. W multimodalności to zwykle matryca: typ materiału × typ zadania × poziom jakości.

• Typ materiału: zdjęcia/scan, wykresy (słupkowe/liniowe/kołowe), tabele, dokumenty wielostronicowe, załączniki (np. aneksy), podpisy/pieczęcie.
• Struktura: jedno- vs wielokolumnowe układy, stopki/nagłówki, pola formularzy, sekcje numerowane, przypisy, drobny druk.
• Język i format zapisu: polskie znaki, formaty dat/kwot, separatory tysięcy, waluty, skróty prawne.
• Trudność wizualna: niska rozdzielczość, cienie, krzywe skany, szum, kompresja, częściowe zasłonięcie.

Na tym etapie ustala się też jednostkę testową: pojedynczy obraz, strona PDF, fragment (crop), czy cały dokument (np. 10 stron). Jednostka determinuje koszt adnotacji i sposób liczenia wyników.

3.3 Adnotacje: jak opisać prawdę referencyjną (ground truth)

Adnotacja w datasetach multimodalnych zwykle obejmuje kilka warstw. Dobrą praktyką jest rozdzielenie faktów (co jest na dokumencie) od formatu odpowiedzi (jak model ma to zwrócić), aby móc później testować różne style promptów bez przepisywania prawdy referencyjnej.

• Warstwa treści: wartości pól (np. numer umowy, data, strony, kwoty), odpowiedzi na pytania, odczytane wartości z osi wykresu.
• Warstwa lokalizacji (opcjonalnie, ale bardzo przydatna): bounding boxy, poligony lub wskazanie strony/sekcji. Ułatwia kontrolę, czy model „patrzył tam, gdzie trzeba”.
• Warstwa normalizacji: ujednolicone formaty (daty ISO, liczby jako wartości numeryczne), słowniki klas, reguły dla jednostek.
• Warstwa niepewności: oznaczenie, że fragment jest nieczytelny/niejednoznaczny, oraz jak to ma być oceniane (np. dopuszczalne „unknown”).

W praktyce przydaje się jedno, spójne „źródło prawdy” w postaci rekordu JSON na przykład. Przykładowy minimalny schemat (orientacyjny):

{
  "id": "doc_000123_p02",
  "modality": "document_scan",
  "source": {"type": "pdf", "page": 2},
  "tasks": [
    {
      "type": "field_extraction",
      "field": "contract_date",
      "ground_truth": {"value": "2024-01-15"},
      "evidence": {"page": 2, "bbox": [120, 340, 420, 390]}
    },
    {
      "type": "qa",
      "question": "Jaki jest okres wypowiedzenia?",
      "ground_truth": {"value": "30 dni"},
      "evidence": {"page": 2, "bbox": [80, 710, 520, 780]}
    }
  ]
}

Ważne: jeśli w procesie używasz OCR, rozważ przechowywanie zarówno obrazu, jak i wyniku OCR (tekst + pozycje), by móc oddzielnie mierzyć: błędy OCR vs błędy rozumienia. To pozwala też budować zestawy testowe „OCR-on” i „OCR-off”.

3.4 Ground truth: reguły zapisu i tolerancje

Ground truth w multimodalności często wymaga reguł tolerancji, bo dane z obrazów bywają zaszumione, a odpowiedzi mogą mieć równoważne formy. Już podczas tworzenia datasetu warto ustalić:

• Normalizację liczb: np. „1 200,00” = 1200.00; waluta jako osobne pole.
• Normalizację dat: różne formaty wejściowe mapowane do jednego standardu.
• Warianty tekstowe: słowniki synonimów dla krótkich odpowiedzi, dopuszczalne skróty.
• Braki danych: kiedy poprawną odpowiedzią jest „brak w dokumencie” lub „nieczytelne”.

Te decyzje determinują później metryki, ale na poziomie datasetu chodzi o to, by ground truth był jednoznaczny i sprawdzalny oraz żeby różni anotatorzy mogli go zapisać w ten sam sposób.

3.5 Podział train/val/test: jak uniknąć przecieków i zawyżonych wyników

W multimodalności „przeciek” między zbiorami występuje nie tylko przez identyczny tekst, ale też przez podobne szablony, te same dokumenty w innych wersjach albo niemal identyczne wykresy. Podział powinien odzwierciedlać to, co uznajesz za generalizację.

• Podział po źródle: jeśli masz wiele typów nadawców/formatów, nie mieszaj ich losowo; rozważ trzymanie części źródeł wyłącznie w test.
• Podział po „rodzinie” dokumentu: ten sam dokument w różnych rozdzielczościach/rotacjach powinien trafić do jednego splitu (żeby test nie zawierał wariantu treningowego).
• Podział po szablonie/layoutcie: jeśli celem jest odporność na nowe układy, trzymaj niektóre layouty tylko w teście.
• Stabilny test set: wersjonuj test (np. v1, v2) i nie zmieniaj go przy każdym eksperymencie; wprowadzaj nowe paczki jako dodatkowe benchmarki.

Typowy, praktyczny układ to: train do uczenia/fitowania (jeśli dotyczy), val do iteracji promptów/reguł i doboru hiperparametrów, test jako „zamknięty” zestaw do raportowania. W projektach stricte ewaluacyjnych (bez treningu) nadal warto utrzymać rozdział na dev (do strojenia) i holdout (do porównań).

3.6 Kontrola jakości: spójność, powtarzalność i audytowalność

Kontrola jakości datasetu multimodalnego to nie tylko sprawdzenie literówek. Celem jest zapewnienie, że wynik testu będzie powtarzalny, a błędy da się zdiagnozować.

• Instrukcja adnotacji: krótkie, jednoznaczne zasady (formaty, tolerancje, co robić z nieczytelnością).
• Podwójna adnotacja próbek: losowa część przykładów opisana przez dwie osoby; rozbieżności trafiają do adjudykacji.
• Walidatory automatyczne: sprawdzanie schematu JSON, zakresów bbox, poprawności dat/liczb, zgodności jednostek.
• Przegląd trudnych przypadków: osobna kolejka dla przykładów z niską czytelnością, nietypowym layoutem lub wieloznacznością.
• Wersjonowanie: dataset, adnotacje i instrukcje powinny mieć wersje; każda zmiana w ground truth musi być śledzona.

Minimalny przykład walidacji schematu (uzupełniająco) można oprzeć o testy jednostkowe, np. sprawdzające format dat i obecność wymaganych pól:

def is_iso_date(s: str) -> bool:
    import re
    return bool(re.fullmatch(r"\d{4}-\d{2}-\d{2}", s))

def validate_record(rec: dict):
    assert "id" in rec
    for t in rec.get("tasks", []):
        gt = t.get("ground_truth", {}).get("value")
        if t.get("field") == "contract_date":
            assert is_iso_date(gt)
        ev = t.get("evidence")
        if ev and "bbox" in ev:
            x1, y1, x2, y2 = ev["bbox"]
            assert x2 > x1 and y2 > y1

Efektem tych działań powinien być dataset, który ma udokumentowane pochodzenie, jednoznaczne adnotacje, sensowny podział bez przecieków i kontrole jakości pozwalające zaufać wynikom ewaluacji.

4. Metryki i kryteria oceny

Ewaluacja multimodalna wymaga metryk, które mierzą nie tylko „czy odpowiedź jest poprawna”, ale też czy model poprawnie odczytał sygnał z obrazu/dokumentu oraz czy jego odpowiedź jest poparta widocznymi dowodami. W praktyce warto rozdzielić ocenę na kilka warstw: (1) jakość rozpoznania/ekstrakcji, (2) poprawność merytoryczną odpowiedzi, (3) zgodność z dowodami (ground truth i/lub wskazany fragment), (4) niezawodność probabilistyczną (kalibracja) oraz (5) pokrycie i brak odpowiedzi w sytuacjach niepewnych. Zespół trenerski Cognity zauważa, że właśnie ten aspekt (zgodność z dowodami i rozdzielanie błędów odczytu od błędów interpretacji) sprawia uczestnikom najwięcej trudności.

4.1. Dokładność ekstrakcji: OCR i pola strukturalne

W zadaniach opartych o dokumenty (skany umów, faktury, formularze) częstym celem jest ekstrakcja pól (np. numer umowy, data, NIP, kwota, termin wypowiedzenia). Metryki powinny odzwierciedlać to, że „prawie dobrze” bywa równie kosztowne jak „źle”, a tolerancja błędu zależy od typu pola.

• Dokładność na poziomie znaków/słów: np. Character Error Rate (CER) i Word Error Rate (WER) dla wyników OCR albo dla tekstu wyekstrahowanego z konkretnego obszaru. Dobre do oceny „czystego odczytu” bez interpretacji.
• Exact match (EM) dla pól: odsetek rekordów, w których pole jest identyczne z ground truth. Najbardziej rygorystyczne; przydatne dla identyfikatorów (numery, kody), mniej dla nazw własnych z wariantami zapisu.
• Metryki z tolerancją: dla dat (różne formaty), kwot (separatory, waluty), adresów (skróty). Typowo stosuje się normalizację (np. kanonizacja dat) przed policzeniem EM.
• Precision/Recall/F1 dla ekstrakcji encji: gdy pole może wystąpić wielokrotnie (np. lista stron umowy, załączniki). Ocena na poziomie zestawu wartości, a nie pojedynczego stringa.

4.2. Poprawność odpowiedzi i „zgodność z dowodami”

Modele multimodalne często generują odpowiedzi płynnie, ale błędnie: mogą halucynować treści niewidoczne na skanie/wykresie albo opierać się na domyślnych schematach. Dlatego oprócz oceny odpowiedzi warto mierzyć, czy odpowiedź jest uziemiona w materiale wejściowym.

• Accuracy/EM dla pytań zamkniętych: np. pytania typu „tak/nie”, wybór z listy, dopasowanie etykiety. Proste i porównywalne między modelami.
• F1 / token-level F1 dla odpowiedzi krótkich: gdy dopuszczalne są warianty zapisu (np. „1 200,00” vs „1200”). Pomaga tam, gdzie EM jest zbyt surowe.
• Metryki zgodności z dowodem (evidence-grounded):
  • Evidence match rate: odsetek przypadków, w których model wskazuje poprawny fragment (np. cytat z OCR, wiersz tabeli, zakres na wykresie) zgodny z ground truth.
  • Attribution precision: jak często wskazany fragment rzeczywiście wspiera odpowiedź (unikanie „losowych cytatów”).
  • Answer-with-evidence: odpowiedź uznaje się za poprawną tylko, jeśli jednocześnie jest poprawna merytorycznie i posiada poprawne uzasadnienie w danych (metryka złożona, przydatna w zastosowaniach regulowanych).

Kluczowe jest rozdzielenie błędów: model źle odczytał vs dobrze odczytał, ale źle zinterpretował. Te dwie klasy wymagają innych działań naprawczych, więc metryki powinny umożliwiać taki podział (np. osobne raportowanie OCR/ekstrakcji i odpowiedzi końcowej).

4.3. Metryki dla tabel

Tabele w dokumentach są problematyczne, bo błąd może dotyczyć struktury (scalenia komórek, nagłówki, relacje wiersz–kolumna) nawet wtedy, gdy sam tekst w komórkach jest poprawny. Dlatego ocenia się zwykle zarówno treść, jak i strukturę.

• Cell-level accuracy / F1: zgodność wartości komórek po dopasowaniu do współrzędnych (wiersz, kolumna) lub do kluczy (np. nagłówek → wartość).
• Row/record accuracy: czy cały rekord (np. pozycja na fakturze) został poprawnie odtworzony. Surowsze, ale bliższe zastosowaniom.
• Schema/structure match: miara zgodności układu (np. poprawne wykrycie liczby kolumn, nagłówków, relacji). W praktyce często raportowana osobno od treści, bo struktura decyduje o tym, czy dane są w ogóle używalne.

4.4. Metryki dla wykresów i danych liczbowych

Wykresy wprowadzają dodatkowy poziom: model musi zmapować piksele na wartości liczbowe lub relacje (trend, maksimum, punkt przecięcia). Metryki powinny rozróżniać błędy „opisowe” od „numerycznych”.

• MAE/RMSE: dla zadań, gdzie odpowiedzią jest liczba (np. odczyt wartości z osi). Sensowne, gdy dopuszczalny jest błąd przybliżenia.
• Relative error (%): szczególnie gdy skala wartości jest szeroka; porównywalne między wykresami.
• Accuracy dla relacji: np. „czy seria A rośnie?”, „która seria ma najwyższą wartość w Q3?”. Działa dobrze dla pytań rankingowych i logicznych.
• Metryki progowe: odsetek odpowiedzi mieszczących się w tolerancji (np. ±2% lub ±1 jednostka osi). Łatwe do interpretacji biznesowej.

4.5. Kalibracja: czy model wie, kiedy nie wie

W zastosowaniach na skanach umów i dokumentach księgowych ważne jest nie tylko to, czy model ma rację, ale czy prawidłowo komunikuje niepewność. Kalibracja pozwala ocenić, czy deklarowane prawdopodobieństwa (lub skorowane confidence) odpowiadają rzeczywistej trafności.

• ECE (Expected Calibration Error): mierzy rozjazd między pewnością a rzeczywistą trafnością w koszykach confidence.
• Brier score: kara za niekalibrowane prawdopodobieństwa; niższy jest lepszy.
• Reliability diagram: wykres diagnostyczny pokazujący, gdzie model jest nadmiernie pewny lub zbyt ostrożny.

W praktyce kalibrację warto liczyć osobno dla typów zadań (OCR/ekstrakcja/QA), bo profile błędów i skale confidence bywają inne.

4.6. Pokrycie (coverage) i selektywność: metryki „odmowy”

W środowisku produkcyjnym często wprowadza się mechanizm: model odpowiada tylko, gdy jest wystarczająco pewny, w przeciwnym razie przekazuje przypadek do weryfikacji lub prosi o lepszy skan. Wtedy liczy się kompromis między trafnością a pokryciem.

• Coverage: odsetek przypadków, w których model udzielił odpowiedzi (powyżej progu pewności).
• Selective accuracy: trafność liczona tylko na przypadkach, na które model się zdecydował odpowiedzieć.
• Risk–coverage curve: pokazuje, jak maleje ryzyko błędu, gdy zmniejszamy pokrycie (podnosimy próg).
• False accept / false reject: szczególnie ważne w automatyzacji dokumentów: lepiej „odrzucić” trudny przypadek niż zaakceptować błędne dane do systemu.

4.7. Szybkie porównanie: jakie metryki do jakich zadań

Dobrze zaprojektowany zestaw metryk łączy miary zadaniowe (czy model daje właściwy wynik), miary dowodowe (czy wynik wynika z danych) oraz miary decyzyjne (czy model potrafi się wstrzymać). Dzięki temu porównanie modeli jest bardziej odporne na „ładnie brzmiące” odpowiedzi, które nie mają oparcia w obrazie, tabeli czy skanie.

5. Testy odporności i degradacje

Modele multimodalne działają na danych, które w praktyce rzadko są „laboratoryjnie czyste”. Zdjęcia dokumentów bywają krzywe i poruszone, wykresy skompresowane przez komunikatory, a skany umów częściowo zasłonięte pieczątką lub palcem. Testy odporności sprawdzają, czy model utrzymuje akceptowalną jakość odpowiedzi mimo takich zakłóceń oraz gdzie znajduje się granica, po której wynik przestaje być użyteczny.

W odróżnieniu od degradacji w zadaniach stricte tekstowych (np. literówki), tu zaburzenia wpływają na cały łańcuch: widzenie (detekcja/segmentacja), OCR (jeśli używany), rozumienie układu (layout), a dopiero na końcu na wnioskowanie. Dlatego odporność należy testować osobno dla typów materiałów (obrazy, wykresy, dokumenty) i dla klas degradacji.

5.1. Po co robić testy degradacji (i co one mówią)

• Walidacja warunków brzegowych: jakie minimalne DPI/ostrość/kontrast są potrzebne, by model nadal poprawnie wyciągał kluczowe pola z umowy.
• Ocena „graceful degradation”: czy jakość pogarsza się stopniowo (przewidywalnie), czy następuje nagły spadek.
• Wykrywanie kruchych zachowań: np. model radzi sobie z lekką rotacją na zdjęciach, ale kompletnie gubi oś Y na wykresach po kompresji.
• Projektowanie wymagań wejściowych: rekomendacje dla aplikacji (np. „unikaj trybu nocnego”, „wymagany auto-crop”, „wymagana minimalna szerokość 1200 px”).
• Ustalanie strategii fallback: kiedy uruchomić dodatkowy preprocessing (odszumianie, deskew), a kiedy poprosić użytkownika o ponowne zdjęcie.

5.2. Główne rodzaje degradacji i ich typowe skutki

5.3. Jak projektować testy odporności (minimalny, praktyczny zestaw)

Najbardziej użyteczne są testy, które systematycznie zwiększają poziom degradacji i pokazują krzywą jakości. W praktyce warto zacząć od kilku kontrolowanych „gałek” i sprawdzić ich wpływ na różne typy wejść:

• Poziomy intensywności: np. 3–5 stopni blur/kompresji/rotacji, aby zobaczyć punkt załamania.
• Scenariusze realistyczne: osobno „telefon w słabym świetle” (szum + blur), osobno „wysłane przez komunikator” (kompresja + zmniejszenie rozdzielczości).
• Różne obszary krytyczne: degraduj tylko fragment z kwotą i datą, tylko tabelę z opłatami, tylko legendę wykresu — bo awarie często są lokalne.
• Powtarzalność: degradacje muszą być deterministyczne (seed), żeby porównania między wersjami modelu były uczciwe.
• Testy mieszane: pojedyncza degradacja bywa zbyt łagodna; w realu często występują naraz.

5.4. Specyfika dla obrazów, wykresów i dokumentów

• Obrazy (VQA / opis): wrażliwe na zasłonięcia kluczowych obiektów i na kompresję w rejonach z tekstem (np. etykiety na opakowaniach). W testach warto rozróżnić pytania „globalne” (co widać) od „lokalnych” (jaki numer/napis).
• Wykresy: krytyczne są cienkie linie, znaczniki punktów, osie i legenda. Kompresja i blur częściej niszczą dokładność odczytu wartości niż ogólne rozpoznanie trendu, więc degradacje powinny celować w elementy osi/siatki/etykiet.
• Dokumenty/umowy: największe ryzyko to błędne przypisanie wartości do pól (layout) oraz zniekształcenia typowe dla zdjęć (perspektywa, nierówne oświetlenie). Zmiany układu dokumentu są tu równie ważne jak „szumy wizualne”.

5.5. Degradacje layoutu: co testować w dokumentach

„Zmiana układu” nie jest klasycznym szumem obrazu, ale w praktyce to jeden z najczęstszych powodów błędów w ekstrakcji. Podstawowe kategorie, które warto symulować lub zbierać w danych testowych:

• Reflow i łamanie wierszy: ta sama treść, ale inne zawijanie tekstu, inne podziały akapitów.
• Wielokolumnowość: przejście z 1 kolumny na 2–3 kolumny (nagłówki, stopki, przypisy).
• Różne wzorce tabel: scalone komórki, brak ramek, nagłówki wielowierszowe.
• Przestawione sekcje: np. dane stron umowy na końcu zamiast na początku.
• Elementy rozpraszające: logotypy, pieczątki, podpisy, odręczne dopiski w marginesach.

5.6. Minimalny „harness” do generowania degradacji (uzupełniająco)

Poniższy szkic pokazuje ideę: przygotować zestaw transformacji, uruchamiać je w kilku poziomach i porównywać wyniki modelu na tych samych przykładach. To nie jest pełny pipeline, ale ułatwia standaryzację testów.

# Pseudokod (Python-like)
TRANSFORMS = [
  {"name": "rotate", "levels": [0, 2, 5, 10]},
  {"name": "blur", "levels": [0, 1, 2, 3]},
  {"name": "jpeg", "levels": [95, 75, 50, 30]},
  {"name": "occlude", "levels": [0.0, 0.1, 0.2]},
]

for example in test_set:
  base = load_image(example)
  for t in TRANSFORMS:
    for level in t["levels"]:
      img = apply_transform(base, t["name"], level, seed=123)
      out = model_answer(img, example.prompt)
      log(example.id, t["name"], level, out)

5.7. Pułapki interpretacyjne w testach odporności

• Mylenie odporności z „umiejętnością zgadywania”: model może odpowiadać płynnie mimo braku dowodów w obrazie; w testach degradacji to szczególnie częste przy zasłonięciach i mocnym blur.
• Uśrednianie maskuje awarie: średni wynik może wyglądać dobrze, ale krytyczne pola (np. kwota, termin) mogą mieć dramatyczny spadek jakości.
• Brak kontroli rozdzielczości: rotacja czy kompresja często zmieniają efektywną czytelność; warto pilnować, czy nie zmieniamy niechcący skali/rozmiaru.
• Nierealistyczne degradacje: zbyt „syntetyczne” zakłócenia mogą nie odzwierciedlać prawdziwych problemów (np. nierówne oświetlenie, cienie, perspektywa).

Dobrze zaprojektowane testy odporności pozwalają szybko odpowiedzieć na pytania wdrożeniowe: kiedy model działa stabilnie, kiedy wymaga preprocessing’u oraz kiedy powinien odmówić lub poprosić o lepszy skan/zdjęcie.

6. Human review i audyt błędów: procedury przeglądu, inter-annotator agreement, klasyfikacja błędów i feedback loop

W ewaluacji multimodalnej automatyczne metryki często nie wystarczają, bo model może udzielić odpowiedzi pozornie poprawnej językowo, ale niezgodnej z obrazem/wykresem/skanem, albo opartej na nieczytelnych fragmentach. Human review (przegląd ekspercki) i audyt błędów domykają lukę między „co model napisał” a „czy miał do tego podstawę w materiale wejściowym”. Celem nie jest wyłącznie wystawienie oceny, lecz wykrycie wzorców usterek, ryzyk i miejsc, gdzie potrzebne są lepsze dane, prompty lub ograniczenia użycia.

6.1. Procedury przeglądu: jak oceniać odpowiedzi, gdy źródłem jest obraz

Dobrze zaprojektowany przegląd ma jasne kryteria, minimalizuje subiektywność i pozostawia ślad audytowy. W praktyce stosuje się lekką „kartę oceny” (rubrykę) i ustandaryzowany workflow.

• Próbkowanie do review: nie tylko losowo — także przypadki graniczne (niska jakość skanu, nietypowy układ, gęste wykresy), oraz próbki z niską pewnością/dużą rozbieżnością między modelami.
• Zasada „evidence-first”: recenzent ocenia, czy odpowiedź jest uzasadniona materiałem wejściowym (np. widoczny fragment umowy, etykieta osi wykresu). Jeśli dowodu nie da się wskazać, odpowiedź nie przechodzi, nawet gdy „brzmi rozsądnie”.
• Oddzielenie oceny treści od formy: osobno poprawność merytoryczna, osobno kompletność i zgodność formatu (np. JSON, pola w tabeli), osobno zgodność z instrukcją (np. „odpowiadaj wyłącznie na podstawie dokumentu”).
• Ścieżka eskalacji: przypadki sporne trafiają do drugiego recenzenta lub arbitra; warto logować powód sporu (np. nieczytelny fragment, niejednoznaczny zapis w umowie).
• Redakcja danych wrażliwych: recenzenci powinni widzieć tyle, ile konieczne; w dokumentach prawnych typowe jest maskowanie danych osobowych, przy zachowaniu elementów potrzebnych do oceny.

6.2. Inter-annotator agreement: mierzenie zgodności recenzentów

W multimodalnych zadaniach recenzenci mogą się różnić w interpretacji: czy dany zapis w umowie „wystarcza” jako dowód, czy wykres daje się odczytać, czy model mógł pomylić legendę z etykietą osi. Dlatego mierzy się inter-annotator agreement (IAA), czyli zgodność ocen między osobami.

• Po co IAA? Wysoka zgodność sugeruje, że kryteria są jasne i zadanie da się oceniać powtarzalnie. Niska zgodność zwykle oznacza nieprecyzyjne wytyczne, zbyt trudne/niejednoznaczne próbki lub źle zdefiniowane kategorie błędów.
• Jak stosować praktycznie? Wystarczy stały odsetek próbek oceniany podwójnie oraz cykliczne kalibracje zespołu (krótka sesja: przykłady + dyskusja różnic).
• Na co uważać? Zgodność może być sztucznie „wysoka”, gdy większość przypadków jest banalna; dlatego próba do IAA powinna zawierać też trudne i brzegowe przykłady.

6.3. Klasyfikacja błędów: wspólny język do diagnozy

Sam wynik „źle” niewiele mówi. Potrzebna jest taksonomia błędów, która pozwala odróżnić pomyłkę OCR od błędu rozumowania, oraz błąd interpretacji wykresu od problemu z formatem wyjścia. Klasyfikacja powinna być na tyle prosta, by recenzenci stosowali ją konsekwentnie, i na tyle informacyjna, by prowadziła do działań naprawczych.

• Błędy percepcji: model „nie widzi” elementu (np. drobny druk, rozmycie, słaby kontrast) lub myli obiekty (np. kolumny w tabeli, legendę na wykresie).
• Błędy ekstrakcji: treść jest widoczna, ale przeniesiona błędnie (np. literówka w numerze, pomyłka waluty, zgubiony znak „%”).
• Błędy ugruntowania w dowodach (grounding): odpowiedź nie ma oparcia w materiale wejściowym albo powołuje się na fragmenty, których nie ma.
• Błędy interpretacji: elementy są poprawnie odczytane, ale źle zinterpretowane (np. odczyt osi czasu jako wartości, mylenie wartości skumulowanych z chwilowymi).
• Błędy instrukcji/zgodności formatu: model odpowiada nie w tym formacie, dodaje nieproszone wnioski, nie stosuje się do ograniczeń („tylko na podstawie dokumentu”).
• Błędy bezpieczeństwa i zgodności: ujawnienie danych wrażliwych, zbyt daleko idące wnioski prawne/finansowe bez podstawy w dokumencie.

W praktyce każda etykieta błędu powinna mieć: krótką definicję, 1–2 przykłady „zalicz/nie zalicz”, oraz wskazówkę, jakiego typu działania naprawcze zwykle pomagają (np. poprawa jakości skanów, doprecyzowanie promptu, zmiana walidacji wyjścia).

6.4. Feedback loop: jak zamienić audyt w poprawę modelu i procesu

Największa wartość human review ujawnia się wtedy, gdy wyniki wracają do zespołu w formie konkretnych zadań. Feedback loop powinien łączyć obserwacje recenzentów z priorytetyzacją i weryfikacją, czy poprawki realnie zmniejszają liczbę podobnych błędów.

• Triaging: grupowanie błędów według wpływu (ryzyko biznesowe/prawne), częstości i łatwości naprawy.
• Backlog usprawnień: osobne ścieżki dla (a) zmian promptów i instrukcji, (b) walidacji/parsowania odpowiedzi, (c) doboru danych i przykładów, (d) polityk odmowy odpowiedzi, gdy brak dowodu.
• Regresja: po zmianach uruchamia się ponownie zestaw kontrolny skupiony na wykrytych klasach błędów, aby upewnić się, że poprawa nie psuje innych zachowań.
• Biblioteka przypadków: repozytorium „trudnych” próbek z opisem błędu i oczekiwanym zachowaniem — do szybkiej weryfikacji kolejnych wersji.

// Minimalny szkic rekordu do audytu błędu (format przykładowy)
{
  "sample_id": "...",
  "task_type": "document_extraction | chart_qa | image_vqa",
  "model_output": "...",
  "review_verdict": "pass | fail",
  "error_tags": ["perception", "grounding"],
  "evidence_locator": "strona 3, tabela 'Opłaty', wiersz 2",
  "review_notes": "Model podał kwotę 1 200, w dokumencie jest 12 000.",
  "severity": "low | medium | high"
}

Kluczowe jest, by feedback loop nie kończył się na „naprawie modelu”. Często równie skuteczne są poprawki procesu: lepsze wytyczne dla użytkowników, wymuszenie cytowania dowodu (np. wskazanie strony/sekcji), albo automatyczne flagowanie odpowiedzi, gdy model nie potrafi wskazać podstawy w obrazie.

7. Przykłady zadań testowych i benchmarków: scenariusze, prompty, oczekiwane odpowiedzi i typowe pułapki

W ewaluacji multimodalnej same „pytania o obrazek” to za mało. Dobre testy łączą różne formaty wejścia (zdjęcie, skan, wykres, tabela) z różnymi typami odpowiedzi (krótka odpowiedź, wartości liczbowe, cytat z dokumentu, decyzja zgodności). Poniżej znajdują się przykładowe scenariusze, które najczęściej ujawniają realne ograniczenia modeli: gdzie mylą oś wykresu z legendą, gubią kontekst w umowach albo „domyślają” brakujące fragmenty zamiast przyznać niepewność.

7.1. VQA na obrazach: rozpoznanie treści vs wnioskowanie

Scenariusz: model dostaje zdjęcie/ilustrację i ma odpowiedzieć na konkretne pytanie. Celem jest odróżnienie prostego odczytu od rozumowania opartego na tym, co widać.

• Prompt: „Na obrazie widać kilka znaków drogowych. Jaki jest limit prędkości?”
• Oczekiwana odpowiedź: krótka wartość, np. „50 km/h”, bez dopowiadania dodatkowych przepisów.
• Typowe pułapki: mylenie podobnych symboli, odpowiadanie „zwyczajowe” (np. 50 w mieście) mimo braku czytelnego znaku, ignorowanie jednostek.

• Prompt: „Ile osób jest na zdjęciu?”
• Oczekiwana odpowiedź: liczba zgodna z widocznymi sylwetkami (uwaga na odbicia w lustrach i plakaty).
• Typowe pułapki: liczenie manekinów/zdjęć na ścianie jako osób, pomijanie częściowo zasłoniętych postaci.

Wskazówka benchmarkowa: zestawy VQA są dobre do testowania „co model widzi”, ale łatwo je przeuczyć na schematach pytań. W praktycznych benchmarkach warto mieszać pytania literalne (odczyt) z kontrolnymi (czy model potrafi powiedzieć „nie da się stwierdzić”).

7.2. OCR i czytanie dokumentów: skan jako źródło prawdy

Scenariusz: model dostaje skan pisma lub formularza, a zadanie polega na odczycie danych. Tu najważniejsze jest rozdzielenie: co jest w tekście, a co jest interpretacją.

• Prompt: „Wypisz numer faktury i datę wystawienia z dokumentu. Zwróć dokładnie tak jak na skanie.”
• Oczekiwana odpowiedź: dwa pola, w dokładnym brzmieniu (format daty, separatory, spacje).
• Typowe pułapki: normalizacja mimo prośby o wierność (np. zmiana 01/02/2024 na 2024-02-01), pomylenie „0” z „O”, „1” z „I”, zgadywanie zamazanych znaków.

• Prompt: „Czy na skanie jest podpis? Jeśli tak, wskaż w którym miejscu (np. 'dół po prawej').”
• Oczekiwana odpowiedź: „tak/nie” oraz opis lokalizacji w prostych słowach.
• Typowe pułapki: branie pieczątki za podpis, nadinterpretacja bazgrołów, mylenie parafki z podpisem.

7.3. Umowy i skany prawne: ekstrakcja, QA i zgodność z zapisami

Scenariusz: model ma pracować na skanie umowy (często wielostronicowej) i odpowiadać na pytania prawne lub ekstraktować kluczowe warunki. Test mierzy, czy model potrafi wskazać właściwy fragment i nie tworzy „prawdopodobnych” zapisów.

• Prompt: „Jaki jest okres wypowiedzenia? Odpowiedz cytatem z umowy oraz krótkim streszczeniem.”
• Oczekiwana odpowiedź: cytat (dosłownie) + jednozdaniowa interpretacja, zgodna z cytatem.
• Typowe pułapki: pomylenie okresu umowy z okresem wypowiedzenia, łączenie fragmentów z różnych paragrafów w jeden „nowy” zapis, ignorowanie wyjątków (np. inne terminy dla różnych stron).

• Prompt: „Czy umowa dopuszcza indeksację wynagrodzenia? Jeśli tak, na jakiej podstawie?”
• Oczekiwana odpowiedź: „tak/nie” + wskazanie podstawy (np. konkretny wskaźnik/klauzula), tylko jeśli występuje w dokumencie.
• Typowe pułapki: odpowiedź „tak, inflacja/CPI” z przyzwyczajenia, mimo że dokument tego nie zawiera; nieuwzględnienie aneksu/załącznika.

Wskazówka benchmarkowa: w testach umów warto mieć pytania „negatywne” (odpowiedź powinna brzmieć „brak informacji w dokumencie”) oraz pytania na rozróżnienie podobnych pojęć (kara umowna vs odsetki, termin płatności vs termin realizacji).

7.4. Tabele i formularze: struktura ma znaczenie

Scenariusz: model odczytuje tabelę na skanie lub w raporcie. Tu błędy często wynikają z utraty struktury (kolumny/wiersze) i mylenia nagłówków.

• Prompt: „Jaka jest wartość w wierszu 'Razem' w kolumnie 'Brutto'?”
• Oczekiwana odpowiedź: jedna liczba z właściwej komórki.
• Typowe pułapki: wzięcie wartości netto zamiast brutto, przesunięcie o jedną kolumnę przy tabelach z łączonymi komórkami, pomylenie sum częściowych z końcową.

• Prompt: „Wymień wszystkie pozycje, których ilość jest większa niż 10.”
• Oczekiwana odpowiedź: lista nazw pozycji spełniających warunek, bez dopisywania brakujących.
• Typowe pułapki: zgubienie relacji nazwa–ilość, odczyt „10” jako „10,0” i błędna interpretacja, ignorowanie jednostek.

7.5. Wykresy: odczyt osi, legenda i wartości przybliżone

Scenariusz: model analizuje wykres słupkowy/liniowy i odpowiada na pytania o trendy lub konkretne wartości. Kluczowe jest, czy potrafi czytać osie, skale (w tym logarytmiczne) i legendę.

• Prompt: „W którym roku seria A osiąga maksimum?”
• Oczekiwana odpowiedź: konkretny rok z osi X.
• Typowe pułapki: pomylenie serii A z inną z legendy, wskazanie maksimum na podstawie intuicji trendu, a nie faktycznej wartości.

• Prompt: „Jaka jest wartość w punkcie 2022 dla serii B? Jeśli nie da się odczytać dokładnie, podaj przybliżenie i zaznacz, że to estymacja.”
• Oczekiwana odpowiedź: liczba + informacja o przybliżeniu, gdy brak siatki/etykiet.
• Typowe pułapki: podawanie „dokładnej” liczby bez podstawy, niezważanie na skalę osi (np. tysiące vs miliony), pomijanie przerwy na osi.

7.6. Diagramy i schematy: pytania o relacje i kierunek

Scenariusz: model dostaje schemat blokowy, diagram procesu albo mapę zależności i ma odpowiedzieć na pytania o kolejność kroków lub połączenia.

• Prompt: „Jaki jest następny krok po 'Weryfikacja'?”
• Oczekiwana odpowiedź: nazwa bloku wynikowego zgodnie ze strzałką.
• Typowe pułapki: ignorowanie kierunku strzałek, wybór sąsiedniego bloku zamiast następnego w przepływie, pomylenie gałęzi warunkowych.

7.7. Zadania „z dowodem”: odpowiedź musi wynikać z obrazu

Scenariusz: model ma nie tylko odpowiedzieć, ale też wskazać podstawę w materiale (cytat, fragment, opis miejsca). To ogranicza halucynacje i ułatwia ocenę.

• Prompt: „Podaj termin płatności i wskaż zdanie, z którego to wynika.”
• Oczekiwana odpowiedź: termin + dosłowny fragment z dokumentu (lub jednoznaczny opis lokalizacji, jeśli cytat nie jest możliwy).
• Typowe pułapki: wybór fragmentu „podobnego tematycznie”, który nie zawiera odpowiedzi; cytowanie z błędami; podawanie terminu bez wskazania źródła.

7.8. Testy mieszane: łączenie tekstu z obrazem

Scenariusz: użytkownik podaje pytanie w tekście, a odpowiedź wymaga odczytu z obrazu i jednocześnie zastosowania warunku z promptu (np. filtrowanie, porównanie, prosta logika).

• Prompt: „Na podstawie tabeli na skanie: wypisz produkty, których cena jednostkowa jest niższa niż 20, ale tylko jeśli mają oznaczenie 'dostępny'.”
• Oczekiwana odpowiedź: lista produktów spełniających oba warunki.
• Typowe pułapki: spełnienie tylko jednego warunku, mylenie kolumn, nieuwzględnienie przypisów (np. 'dostępny' tylko dla wybranego wariantu).

7.9. Najczęstsze „pułapki benchmarkowe”, które warto mieć w zestawie

• Ambiwalentna czytelność: fragment jest częściowo nieczytelny; poprawna odpowiedź to ograniczenie się do tego, co da się potwierdzić.
• Konflikt źródeł: inna wartość w tabeli i w przypisie; model powinien zauważyć rozbieżność zamiast wybierać losowo.
• Wiele podobnych pól: np. kilka dat (wystawienia, sprzedaży, płatności) — testy powinny wymuszać precyzję.
• Jednostki i skale: tys./mln, %, punkty bazowe, waluty; błędy tu bywają kosztowniejsze niż błąd o 1 znak w OCR.
• Negacje i wyjątki: „z wyjątkiem…”, „nie później niż…” — modele często gubią takie fragmenty w dłuższych dokumentach.
• Strony i załączniki: odpowiedź bywa w aneksie, stopce lub na kolejnej stronie; benchmark powinien sprawdzać wyszukiwanie w obrębie całości.

Tak skonstruowane przykłady pozwalają testować nie tylko „czy model coś odpowie”, ale czy odpowie w sposób weryfikowalny, zgodny z materiałem wizualnym i odporny na typowe źródła pomyłek: strukturę tabel, skalę wykresu, oraz niejednoznaczności skanów i dokumentów.

8. Pipeline automatyzacji ewaluacji: generowanie wariantów, uruchamianie testów, scoring, raporty i CI/CD

W ewaluacji multimodalnej samo „odpalenie zestawu pytań” rzadko wystarcza. Pipeline automatyzacji porządkuje cały proces: od przygotowania wariantów tych samych bodźców (obrazu, wykresu, skanu), przez uruchomienie modeli w kontrolowanych warunkach, aż po powtarzalny scoring i raportowanie wyników. Celem jest porównywalność wersji modelu i promptów, śledzenie regresji oraz transparentność (co dokładnie było testowane i na jakich danych).

Generowanie wariantów danych wejściowych

Automatyzacja zaczyna się przed samym testem: od tworzenia ustandaryzowanych wariantów wejść, które odzwierciedlają typowe sytuacje produkcyjne. Dla obrazów i dokumentów oznacza to przygotowanie wielu „widoków” tego samego przykładu, tak aby sprawdzić stabilność odpowiedzi w różnych warunkach.

• Warianty formatów i rozdzielczości: różne DPI, konwersje PNG/JPEG/PDF, różne profile kompresji.
• Warianty prezentacji: przycięcie marginesów, skalowanie, zmiana orientacji, renderowanie stron PDF do obrazów.
• Warianty kontekstu: dodanie lub usunięcie elementów otoczenia (np. nagłówków/stopki), alternatywne kadrowanie, wersje jedno- i wielostronicowe.
• Warianty promptów: kontrolowane permutacje instrukcji (np. wymóg cytowania dowodów, format odpowiedzi), aby oddzielić wpływ promptu od wpływu obrazu.

Kluczowe jest, aby warianty były deterministyczne (ten sam seed/konfiguracja daje identyczne wejścia) i śledzone (każdy wariant ma identyfikator oraz metadane: źródło, transformacje, parametry).

Orkiestracja uruchomień testów

Warstwa uruchomieniowa pipeline’u odpowiada za spójne wykonywanie testów w różnych środowiskach i dla różnych modeli. W multimodalności dochodzą aspekty specyficzne: limity rozmiaru wejścia, czas renderowania, wrażliwość na kolejność stron, a także zależności od OCR lub narzędzi pośrednich.

• Konfiguracje eksperymentów: wersja modelu, parametry generacji, strategia dostarczania obrazów (pojedynczo, paczką, stronicowanie), limity tokenów i czasu.
• Tryby wykonania: batch (nocne przebiegi pełne) oraz smoke (krótkie testy przy zmianach).
• Izolacja i powtarzalność: kontrola wersji zależności, spójne biblioteki renderujące PDF, identyczne ustawienia preprocessingu.
• Obsługa błędów: retry dla błędów sieciowych, klasyfikacja awarii (timeout, błąd dekodowania, błąd wejścia), aby nie mieszać problemów infrastruktury z jakością modelu.

Dobrą praktyką jest rozdzielenie etapów: przygotowanie wejścia → wywołanie modelu → postprocessing odpowiedzi → scoring. Dzięki temu łatwiej porównywać modele, a także podmieniać komponenty bez rozbijania całego procesu.

Postprocessing i normalizacja odpowiedzi

Odpowiedzi modeli multimodalnych bywają niejednorodne: wolny tekst, listy, wartości liczbowe, pseudo-JSON, a czasem mieszanka kilku formatów. Pipeline powinien ujednolicać wyjścia tak, by scoring był możliwie stabilny.

• Normalizacja liczb: separator dziesiętny, waluty, jednostki, zaokrąglenia, zapis procentów.
• Normalizacja struktury: mapowanie do oczekiwanego schematu (np. pola umowy), tolerancja na różne nazwy kluczy, kolejność elementów.
• Walidacja: wykrywanie odpowiedzi niekompletnych, sprzecznych lub niezgodnych z wymaganym formatem i oznaczanie ich jako przypadki do osobnej analizy.

Istotne jest zachowanie zarówno „surowej” odpowiedzi, jak i wersji znormalizowanej, aby później łatwo audytować błędy i rozumieć, czy problem wynika z modelu czy z parsera.

Scoring i agregacja wyników

Automatyczny scoring powinien działać na poziomie pojedynczego przykładu, wariantu oraz całego zestawu. W praktyce oznacza to kilka warstw wyników: wynik globalny, wyniki per typ zadania, a także wyniki per typ wejścia (np. wykres vs skan umowy).

• Skoring wielokryterialny: oddzielne wyniki dla poprawności merytorycznej, kompletności i zgodności z wymaganym formatem.
• Segmentacja: rozbicie wyników wg źródła danych, jakości skanu, języka, domeny dokumentu, rodzaju wykresu.
• Analiza regresji: porównanie do „baseline” (poprzedniej wersji), z progami akceptacji oraz listą przykładów, na których wynik się pogorszył.

W pipeline warto utrzymywać spójne identyfikatory: test-run, wersja modelu, wariant wejścia i wersja zestawu testowego. To umożliwia wiarygodne porównania w czasie oraz szybkie odtworzenie wyników.

Raporty: od dashboardów po „pakiet dowodowy”

Raportowanie w multimodalności powinno pokazywać nie tylko liczby, ale też kontekst. Same metryki mogą ukrywać typowe problemy, np. poprawne wartości bez poprawnego źródła, albo odwrotnie: poprawne wskazanie miejsca w dokumencie, ale błędna ekstrakcja.

• Raport syntetyczny: najważniejsze wskaźniki, zmiana vs baseline, lista regresji i „top poprawy”.
• Raport diagnostyczny: przykłady z najsłabszym wynikiem, pogrupowane według kategorii wejścia i typu błędu.
• Pakiet reprodukcji: linki/identyfikatory do obrazów i wariantów, prompty, parametry uruchomienia, surowe odpowiedzi, wersja preprocessingu.

Warto też raportować metryki operacyjne (czas odpowiedzi, odsetek timeoutów, koszty), bo w systemach multimodalnych to często równie istotne jak sama jakość.

Integracja z CI/CD i bramki jakości

Największą wartość pipeline daje wtedy, gdy staje się częścią procesu wytwórczego. Integracja z CI/CD pozwala automatycznie wykrywać regresje jakości po zmianie modelu, promptu, komponentu OCR lub preprocessingu obrazów.

• Testy warstwowe: krótkie testy przy każdym wdrożeniu oraz pełne przebiegi cykliczne (np. nocne), aby równoważyć czas i pokrycie.
• Bramki jakości: minimalne progi akceptacji dla kluczowych zadań oraz limit dopuszczalnej regresji względem baseline.
• Polityki wyjątków: możliwość warunkowego dopuszczenia zmian (np. akceptacja regresji w mniej krytycznych obszarach, jeśli poprawa w krytycznych jest znacząca), zawsze z odnotowaniem decyzji.
• Śledzenie trendów: wykresy jakości w czasie dla różnych podzbiorów (np. „słabe skany”, „wykresy z małą czcionką”), aby zauważyć powolne dryfy.

Pipeline powinien wspierać zarówno rozwój (szybkie iteracje), jak i kontrolę ryzyka (stabilność w produkcji). W multimodalności szczególnie ważne jest, by bramki jakości obejmowały także zmiany w przetwarzaniu wejścia, bo nawet drobna modyfikacja renderowania czy skalowania potrafi wywołać istotną zmianę wyników.

Na zakończenie – w Cognity wierzymy, że wiedza najlepiej działa wtedy, gdy jest osadzona w codziennej pracy. Dlatego szkolimy praktycznie.

Rekomendacje następnego kroku w aplikacji: agent vs klasyczny ML (bandyty, sekwencje, reguły) 24 kwietnia 2026

Dataviz dla ESG: jak pokazywać emisje, cele i luki bez greenwashingu na wykresach 22 kwietnia 2026