Dane: obrazy to często PII (twarze, dokumenty). Redakcja i retencja są obowiązkowe.
Testy: multimodal wymaga golden set (zaskakująco łatwo o „pewne” błędy).
Multimodal działa stabilnie tylko przy kontrakcie: normalizacja wejścia, jasna intencja, format wyjścia i ślad audytowy.
1. Zakres: co jest „multimodalne” w praktyce
Multimodalność nie polega na „proszeniu modelu o opis obrazka”. W produkcji chodzi o to, by model
wykonał jednoznaczną pracę na niejęzykowym sygnale (obraz, audio) i zwrócił wynik w formacie, który da się
automatycznie zwalidować, zlogować i przetestować.
Opis — syntetyzacja: „co widać / co słychać” w granicach danych.
Ekstrakcja — strukturyzacja: pola, etykiety, obiekty, tabelki, elementy formularza.
Weryfikacja — kontrola: „czy spełnia kryterium?” / „czy brak elementu X?”
Reguła konserwatywna: jeden krok = jedna intencja. Łączenie „opisz + wyciągnij + sprawdź”
daje wynik pozornie bogaty, a w praktyce trudny do audytu i regresji.
2. Kontrakt wejścia i wyjścia
W multimodalnym promptowaniu największe błędy powstają nie w samym promptcie, ale w opakowaniu danych:
brak wersji obrazka, brak informacji o skali, brak referencji do fragmentu, brak formatu odpowiedzi.
Wejście (minimalne metadane)
id obiektu (np. image_id) + źródło (kanał, system)
wariant (resize/crop) + parametry
klasa danych (PII/sekrety/„public”)
cel zadania (opis / ekstrakcja / weryfikacja)
Wyjście (kontrakt)
format (najczęściej JSON) + walidacja
referencje do elementów („R1”, „pole: invoice_total”)
confidence/prog decyzyjny (jeśli dotyczy)
tryb „no‑answer” / eskalacja przy braku pewności
3. Wzorzec promptu: instrukcja + format + weryfikacja
Poniższy demonstrator pokazuje trzy typowe tryby pracy. W praktyce warto utrzymywać je jako szablony
w bibliotece promptów, z wersjonowaniem i testami.
Demonstrator: trzy tryby promptowania
Kliknij tryb — zmieni się prompt oraz oczekiwany format wyniku.
Prompt
W wersji produkcyjnej prompt jest parametryzowany (np. nazwy pól, progi, słowniki).
Oczekiwany wynik
Wynik powinien przechodzić walidację i mieć ślad audytowy (trace_id, wersja polityki).
4. Typowe błędy i jak im zapobiegać
Brak referencji: model „wie”, ale nie da się wskazać gdzie. Rozwiązanie: wymagaj referencji („R1…Rn”).
Zbyt szeroki opis: „opisz wszystko” generuje ozdobniki. Rozwiązanie: lista pól/pytań + format.
Nieciągłość pipeline: obraz w UI ≠ obraz w modelu (resize/crop). Rozwiązanie: wersjonuj warianty wejścia.
Brak trybu no‑answer: model wymyśla. Rozwiązanie: jawna zasada odmowy i eskalacji.
5. Bezpieczeństwo i dane
Materiał multimodalny ma wyższe ryzyko prywatności niż tekst: łatwo przeoczyć PII w tle, numery dokumentów,
identyfikatory, twarze. Standard powinien wymuszać:
klasyfikację danych przed przetworzeniem,
redakcję i minimalizację (w tym retencję),
kontrolę dostępu (ACL) do źródeł.
Praktyka firmowa: w trybach wysokiego ryzyka (dokumenty, dane klientów) multimodalny model działa
wyłącznie na zaufanych źródłach, a wyniki przechodzą przez bramki (DLP/Policy/Approval).
6. Checklist wdrożeniowy
Szablony: opis / ekstrakcja / weryfikacja — rozdzielone i wersjonowane.
Walidacja formatu (np. JSON Schema) + obsługa błędów.
Golden set: trudne przypadki (mały tekst, rozmazanie, cień, nietypowy układ).
Redakcja danych + polityka retencji materiału źródłowego.
Ślad: trace_id, wersja polityki, wersja promptu i wariantu wejścia.