Język modelu nie jest językiem społeczeństwa

Model wielojęzyczny nie jest uczciwy, bo jego interfejs wymienia wiele języków. Zasięg językowy to kwestia instytucjonalna, kulturowa i bezpieczeństwa, a...

Język modelu nie jest językiem społeczeństwa

Szesnaście języków to początek, nie wyrok

22 lipca 2026 r. Dyrekcja Generalna ds. Tłumaczeń Komisji Europejskiej opublikowała EU MMLU, benchmark mający testować duże modele językowe w europejskich kontekstach językowych i kulturowych. Publikacja była niezwykle szczera co do luki, którą próbowano wypełnić. Wiele zbiorów ewaluacyjnych powstało w języku angielskim. Model może osiągać w nich dobre wyniki, a mimo to słabo radzić sobie w języku francuskim, węgierskim czy maltańskim. Nowy zbiór obejmuje szesnaście języków urzędowych UE, siedem obszarów tematycznych i ponad tysiąc pytań przetłumaczonych i zrewidowanych przez prawie 250 studentów z 21 europejskich uczelni.

Najważniejsza część tego ogłoszenia to nie lista języków. To zdanie pod nią: zachowania modelu nie można wnioskować z języka, w którym wydaje się najbardziej płynny. To powinno być oczywiste. A jednak to właśnie to założenie stoi za ogromną częścią zamówień publicznych, badań i debaty publicznej. Wciąż mówimy o modelu językowym tak, jakby miał jeden umysł, a potem prosimy go, by nosił różne języki jak płaszcze. Płaszcz się zmienia. Umysł, dowody, ślepe plamy i kontekst społeczny traktujemy jako stałe.

Nie są stałe. Język to miejsce, w którym człowiek spotyka instytucję. To w nim mieszczą się warunki świadczenia, ton odwołania, różnica między poradą a instrukcją, kształt żartu, nazwa miejsca i założenia wpisane w formularz. Gdy system lepiej radzi sobie z jednym językiem niż z innym, nie chodzi tylko o mniej eleganckie zdanie. Może to zmienić to, kto zostanie zrozumiany, komu uwierzono, kto może zakwestionować wynik, a kto zrezygnuje, zanim trafi we właściwe drzwi.

Praktyczny wniosek jest prosty. Wielojęzyczna sztuczna inteligencja to nie funkcja tłumaczenia dodawana po zbudowaniu modelu. To kwestia dostępu, dowodów i wiarygodności. Europejska praca nad technologiami językowymi, danymi językowymi i wielojęzyczną ewaluacją jest cenna, ponieważ traktuje ten problem jak infrastrukturę. Ta praca wciąż trwa. Benchmark to nie gwarancja, a szesnaście języków to nie cała Europa. Ale kierunek jest właściwy: przestańmy pytać, czy model mówi danym językiem, a zacznijmy pytać, co może w tym języku bezpiecznie zrobić, dla kogo, w jakich warunkach i na podstawie jakich dowodów.

Pokrycie językowe jest wiarygodne tylko wtedy, gdy źródło, kontekst, przegląd i deklaracje dotyczące usługi pozostają ze sobą powiązane.

Język to granica dostępu

Europa uczyniła z języka fakt instytucjonalny, a nie prywatną preferencję. Artykuł 22 Karty praw podstawowych stanowi, że Unia szanuje różnorodność kulturową, religijną i językową. Polityka językowa Komisji w zakresie technologii językowych sytuuje ten obowiązek obok praktycznego ostrzeżenia: technologie językowe wymagają bezstronnego użycia, jeśli prawa i zasady mają przetrwać kontakt z oprogramowaniem. To nie są dekoracyjne zobowiązania. Opisują granicę, na którą natrafia system publiczny, gdy mieszkaniec nie może przeczytać obwieszczenia, nie może zrozumieć, dlaczego podjęto decyzję, albo nie może wyrazić istotnego faktu w języku, w którym ten fakt istnieje.

Tej granicy łatwo nie zauważyć, gdy zespół mierzy wyłącznie to, czy tłumaczenie powstało. Zdanie może trafić do odbiorcy w zamówionym języku i wciąż zawieść osobę, która go potrzebuje. Tłumaczenie może spłaszczyć rozróżnienie prawne, zmienić poziom uprzejmości, który sygnalizuje, czy urzędnik pyta, czy nakazuje, albo użyć terminu o znaczeniu potocznym, ale też specjalistycznym w danym urzędzie. Rozpoznawanie mowy może zamienić regionalną wymowę na inne słowo. Streszczenie może usunąć zastrzeżenie, które niesie odpowiedzialność. Płynność nie mówi nam, czy transakcja pozostała nienaruszona.

Wyobraźmy sobie publiczną służbę informacyjną, która oferuje tę samą informację o kryteriach uprawnień po niderlandzku, francusku i w języku regionalnym. Dwie pierwsze ścieżki zostały wytrenowane i przetestowane na materiale administracyjnym, pismach odwoławczych i rozmowach z ekspertami dziedzinowymi. Trzecia ścieżka ma doskonałą prozę ogólną, ale nie ma żadnej rzetelnej ewaluacji na terminologii właściwej dla tej usługi. Pulpit może pokazywać trzy zielone wskaźniki językowe. Mieszkańcy nie otrzymują trzech równoważnych usług. Jedna grupa otrzymuje wyjaśnienie; inna otrzymuje przybliżenie; trzecia otrzymuje wypolerowaną niepewność, która wygląda na oficjalną, bo ma właściwe logo.

Ten przykład jest celowo hipotetyczny. Nie jest twierdzeniem o żadnej konkretnej gminie ani dostawcy. Jego celem jest ujawnienie błędu projektowego. Wsparcie językowe często liczy się na poziomie interfejsu, podczas gdy rzeczywisty obowiązek leży dalej w łańcuchu. System musi wiedzieć, jakie dane wspierają dany język, które zadania zostały poddane ewaluacji, kto sprawdzał błędy, jak użytkownicy mogą je poprawić i kiedy dana ścieżka musi odmówić odpowiedzi. Jeśli tych szczegółów brakuje, wybór języka jest obietnicą bez umowy.

Mapa modelu nie jest mapą społeczeństwa

Model uczy się z mapy języka, którą udostępniają jego dane i proces treningu. Społeczeństwo żyje na znacznie większej mapie. Mapa modelu zawiera teksty, nagrania, etykiety, tłumaczenia i ewaluacje, które zostały dopuszczone. Mapa społeczeństwa zawiera ludzi, którzy mówią inaczej w domu i w pracy, przełączają rejestry bez zapowiedzi, zapożyczają słowa przez granicę, używają języka mniejszości w lokalnej instytucji albo piszą w piśmie, którego nie uwzględnił benchmark. Jedna mapa jest artefaktem technicznym. Druga jest układem żyć, praw i obowiązków.

Ta różnica ma znaczenie nawet dla języków z dużymi korpusami publicznymi. Język narodowy nie jest jednym jednolitym strumieniem. Formularze urzędowe, orzeczenia sądów, mowa w klasie, porady zdrowotne, wiadomości tekstowe i rozmowa między sąsiadami używają różnych słowników i różnych progów tolerancji dla niejednoznaczności. Model może być kompetentny w prozie informacyjnej, a słaby w odwołaniu od decyzji o świadczeniu. Może radzić sobie ze standardową pisownią, a mieć trudności z dialektem. Może przetłumaczyć zdanie dosłownie i nie uchwycić znaczenia pragmatycznego niesionego przez uprzejmą formułę. Nazywanie całego języka wspieranym zaciera granicę zadania.

Technologia językowa potrzebuje zatem bardziej precyzyjnego słownictwa. Powinniśmy odróżniać obecność języka w danych treningowych od zadania ocenianego w tym języku. Powinniśmy odróżniać tłumaczenie benchmarkowe od samodzielnie napisanego elementu testowego. Powinniśmy odróżniać czytanie pisma od rozumienia rejestru danej społeczności. Powinniśmy odróżniać zdolność systemu do generowania tekstu od jego uprawnień do doradzania, klasyfikowania lub podejmowania decyzji. Każde z tych rozróżnień to drobny element dokumentacji. Razem uniemożliwiają złożenie szerokiego twierdzenia z wąskich dowodów.

Istnieje instytucjonalny powód, by być rygorystycznym. Usługi publiczne nie mogą swobodnie wybierać najłatwiejszego języka i nazywać wyniku efektywnym. Bank, szpital, pracodawca czy dostawca oprogramowania może mieć różne obowiązki prawne, ale każdy z nich decyduje, ile wysiłku musi włożyć osoba, aby zostać zrozumianą. Trasa wielojęzyczna, która zawodzi po cichu, przenosi koszt na użytkownika. Użytkownik musi znaleźć tłumacza, powtórzyć swoją historię, zaakceptować gorszy wynik lub porzucić cały proces. System raportuje sukces, ponieważ zwrócił ciąg znaków. Człowiek doświadcza wykluczenia w nienagannej gramatyce.

Co naprawdę oznacza niski poziom zasobów

Niski poziom zasobów często traktuje się jako cechę języka, jakby niektóre języki przyszły do modelu z mniejszą liczbą zasobów i powinny przepraszać za niedogodność. Bardziej użyteczne jest traktowanie tego jako cechy zadania, zbioru danych i decyzji zarządczych. Język może mieć znaczny dorobek literacki, ale niewiele oznaczonych danych dla klasyfikatora medycznego. Może mieć teksty równoległe, ale prawie żadnych nagrań mowy. Może być reprezentowany w korpusie bez praw lub metadanych potrzebnych do konkretnego wdrożenia. Może mieć dane w standardowej formie, podczas gdy osoby, których to dotyczy, używają odmiany regionalnej.

Polityka Komisji Europejskiej dotycząca technologii językowych nazywa to wprost. Dane językowe są fundamentem narzędzi językowych, a wiedza ludzka jest niezbędnym elementem udanego rozwoju. Model potrzebuje tekstu lub mowy, algorytmów, mocy obliczeniowej oraz ludzi, którzy rozumieją język i dziedzinę. Usunięcie któregokolwiek z tych elementów zmienia system. Większa moc obliczeniowa nie stworzy brakującej rozmowy. Więcej przykładów nie naprawi etykiety mylącej dwie kategorie prawne. Większy model nie zdecyduje, które źródło społeczność uznaje za wiarygodne.

Praca nad językami o niskim poziomie zasobów nie jest zatem zaproszeniem do obniżenia standardów. To powód, aby uczynić standard widocznym. Jeśli zadanie ma mało materiału ewaluacyjnego, powiedz to wprost. Jeśli metryka jest niestabilna dla danej pary językowej, zgłoś tę niestabilność. Jeśli przegląd ludzki był niewielki, określ zakres przeglądu zamiast przedstawiać go jako ogólną gwarancję. Jeśli trasa jest przydatna do szkicowania, ale nie do podejmowania decyzji, umieść tę granicę tam, gdzie kupujący i użytkownik mogą ją zobaczyć. Uczciwy niedobór jest bezpieczniejszy niż cisza sprawiająca wrażenie obfitości.

Krajobraz językowy Europy czyni tę dyscyplinę nieuniknioną. Komisja opisuje złożony zestaw języków urzędowych, regionalnych i mniejszościowych oraz wspierała inicjatywy takie jak European Language Grid, agenda European Language Equality i Common European Language Data Space. Projekty te nie są jednym rozwiązaniem i nie powinny być tak opisywane. Są elementami ekosystemu, w którym dane, narzędzia, prawa, wiedza i instytucje publiczne mogą się spotkać. Kształt instytucjonalny jest równie ważny jak model w jego wnętrzu.

Warstwa praw pojawia się przed benchmarkiem

Kuszące jest mówienie o modelach językowych tak, jakby język był neutralnym kanałem wejściowym. Nie jest. Dane wejściowe mogą zawierać dane osobowe, cechę chronioną, lokalną nazwę miejscowości, dane medyczne lub zapis rozmowy osoby proszącej o pomoc. Źródło może być objęte prawem autorskim lub podlegać zastrzeżeniu. Przetłumaczony wynik może zostać wykorzystany w decyzji, nawet jeśli ścieżka tłumaczenia nigdy nie została oceniona pod kątem tego kontekstu. Problem językowy modelu jest już problemem praw człowieka, zanim ktokolwiek wybierze wynik.

Wytyczne Komisji dotyczące technologii językowych łączą dane językowe zarówno z prawem autorskim, jak i ochroną danych. To powiązanie powinno zmienić sposób, w jaki zespoły projektują potoki przetwarzania. Korpus to nie tylko stos zdań. Ma tożsamość źródła, warunki pozyskania, status licencji lub praw, metadane języka i skryptu, sygnały jakości, cel i zasady przechowywania. Jeśli element zostanie poprawiony lub wycofany, organizacja musi wiedzieć, które pochodne artefakty zostały nim objęte. W przeciwnym razie późniejszy model może powtórzyć stary błąd z pewnością świeżo wydrukowanego formularza.

W tym miejscu fraza pochodzenie danych pokazuje swoją wartość. Pochodzenie danych to nie przypis mówiący, że dane skądś pochodzą. To zbiór relacji, które pozwalają osobie weryfikującej przejść od wyniku do istotnych dowodów i z powrotem. W pracy wielojęzycznej te relacje muszą przetrwać tłumaczenie, transkrypcję, normalizację, segmentację i ocenę. Zdanie przetłumaczone na potrzeby benchmarku nie jest zamienne ze zdaniem źródłowym. Etykieta stworzona przez recenzenta nie jest zamienna z etykietą odziedziczoną z innego języka. Przekształcenie jest częścią dowodów.

Nie ma wymogu, aby każdy użytkownik widział rejestr badań. Jest wymóg, aby organizacja potrafiła odpowiedzieć na poważne pytanie, gdy takie się pojawi. Która wersja zasobu językowego została użyta? Jakie zadanie wspierała? Którzy eksperci językowi ją recenzowali? Co zrobił system, gdy pewność była niska? Czy skarga została potraktowana jako korekta jednej odpowiedzi, czy jako możliwa klasa błędów? Ścieżka językowa staje się godna zaufania, gdy te pytania mają właścicieli i zapisy.

Europa buduje infrastrukturę językową, a nie tylko przyciski do tłumaczenia

Opis Wspólnej Europejskiej Przestrzeni Danych Językowych autorstwa Komisji Europejskiej jest użyteczny, ponieważ nie sprowadza projektu do wydania modelu. Celem jest platforma i rynek do gromadzenia, udostępniania i ponownego wykorzystywania wielojęzycznych i multimodalnych danych językowych, przy jednoczesnym zachowaniu kontroli przez organizacje i osoby, które te dane wytwarzają. To sformułowanie wskazuje na inne rozumienie postępu. Praca nie polega tylko na tworzeniu lepszego zdania. Chodzi o to, aby zasoby językowe były wykrywalne, świadome praw, możliwe do ponownego wykorzystania i rozliczalne w administracji publicznej, nauce i przemyśle.

Europejska Siatka Językowa (European Language Grid) zrobiła podobny krok, gromadząc specjalistyczne narzędzia i zasoby technologii językowych we wspólnym katalogu. Katalog nie dowodzi, że każda usługa działa w każdym zadaniu. Ułatwia jednak sprawdzenie ukrytej zależności. Zespół może zapytać, co robi narzędzie, jaki język obsługuje, skąd pochodzą jego dane i czy licencja odpowiada zamierzonemu zastosowaniu. To niepozorna infrastruktura. To także sposób, w jaki kontynent z wieloma instytucjami unika odtwarzania tej samej zdolności językowej w odizolowanych pomieszczeniach.

Infrastruktura ma znaczenie, ponieważ długi ogon pracy językowej nie jest rozwiązywany przez jeden flagowy model. Instytucja publiczna może potrzebować rozpoznawania mowy dla regionalnego akcentu, ekstrakcji terminologii dla wyspecjalizowanej dziedziny, pamięci tłumaczeniowej dla ustawodawstwa, rozpoznawania nazw własnych dla nazw miejscowości lub sposobu porównania dwóch wersji dokumentu bez utraty znaków diakrytycznych. Firma może potrzebować wdrożenia lokalnego, ponieważ materiał nie może opuścić jej jurysdykcji. Grupa badawcza może potrzebować zbioru danych z jasnym pochodzeniem, a nie kolejnego anonimowego wyniku.

W tym podejściu kryje się cichy wybór polityczny. Dane i narzędzia traktowane są jako możliwości, które Europa powinna móc kontrolować i kształtować, a nie jako usługa, która dociera z niewidzialnego skądinąd miejsca. Nie oznacza to, że systemy europejskie są automatycznie dobre albo że komercyjni dostawcy z innych miejsc nie mogą być użyteczni. Oznacza to, że język jest zbyt ważny, aby pozostawić go bez publicznego słownictwa dla jego danych, jego luk i jego oceny. Suwerenność zaczyna się od wiedzy o tym, czego system nie widzi.

Tłumaczenie to nie neutralna instalacja hydrauliczna

Tłumaczenie często umieszcza się między dwoma komponentami na diagramie architektury, jakby było rurą, która przenosi znaczenie z jednej strony na drugą. Prawdziwe tłumaczenie to ciąg decyzji. Który tekst źródłowy jest wiążący? Które słowa muszą pozostać dokładne? Którą niejednoznaczność należy zachować? Które odniesienie kulturowe wymaga wyjaśnienia? Który rejestr jest odpowiedni dla publicznego ogłoszenia? Którego bytu nie wolno tłumaczyć? Którą datę, liczbę lub jednostkę należy zapisać zgodnie z konwencją czytelnika? Model może podejmować te decyzje szybko. Szybkość nie czyni ich niewidzialnymi.

Rozważ różnicę między tłumaczeniem zdania o pogodzie a tłumaczeniem ogłoszenia o terminie. W pierwszym przypadku drobny błąd stylistyczny może być irytujący. W drugim liczba lub czasownik modalny mogą zmienić to, co dana osoba uważa za swój obowiązek. Podstawowy model językowy może mieć ten sam budżet tokenów i ten sam wskaźnik pewności. Konsekwencje społeczne nie są takie same. Ocena musi zatem podążać za zadaniem, a nie zatrzymywać się na ogólnym wyniku językowym.

Strona Komisji na temat jej własnego używania języków przedstawia tę kwestię bez dramatyzmu. Tłumaczenie maszynowe może dać podstawowe pojęcie, ale jakość i dokładność znacznie się różnią w zależności od tekstu i pary językowej. To użyteczne zdanie publiczne, ponieważ odmawia zamiany usługi w wyrocznię. Daje czytelnikowi pozwolenie na użycie tłumaczenia jako punktu orientacyjnego, jednocześnie zachowując powód, aby szukać wersji ludzkiej lub autorytatywnej, gdy konsekwencje tego wymagają.

Dla zespołów produktowych implikacją jest zestaw wyraźnych ścieżek. Tłumaczenie o niskich konsekwencjach może być zwrócone bezpośrednio z jasnym statusem. Ścieżka prawna lub medyczna może wymagać przeglądu przez człowieka, linku do źródła lub odmowy. Wewnętrzny szkic może zachować źródło obok tłumaczenia. Interfejs głosowy może powtórzyć krytyczną nazwę i poprosić o potwierdzenie. Wybór nie jest między pełną automatyzacją a brakiem automatyzacji. Jest między potokiem, który ujawnia swoje przekazania, a takim, który ukrywa je za płynnym akapitem.

Zdanie przetrwa, sytuacja nie

Modele pracują na reprezentacjach. Społeczeństwa pracują na sytuacjach. Gdy tłumaczenie przechodzi z jednego na drugie, drobne szczegóły mogą stać się całym znaczeniem. Fraza uprzejma w jednym języku może w innym brzmieć wymijająco. Termin odróżniający ustawowe prawo od uznaniowej usługi może zostać sprowadzony do ogólnego słowa oznaczającego pomoc. Idiom można przetłumaczyć dosłownie i stanie się bezsensowny, albo przetłumaczyć swobodnie i stracić odniesienie, które identyfikuje społeczność. Żadna z tych porażek nie wymaga absurdalnego wyniku. Niebezpieczna odpowiedź to ta, która wygląda zwyczajnie.

Wydanie EU MMLU wskazuje dokładnie na ten obszar. Jego kryteria jakości wymagają, aby wielojęzyczne benchmarki testowały nie tylko znaczenie i trudność, ale także idiomy, humor, odniesienia kulturowe, formaty dat i liczb oraz różnice w oczekiwanym tonie lub uprzejmości. To ważne poszerzenie celu oceny. Model językowy nie jest pytany tylko o to, czy potrafi wyprodukować poprawne gramatycznie zdanie. Jest pytany o to, czy zdanie pasuje do sytuacji, w której człowiek będzie na jego podstawie działać.

Wzmianka o humorze nie jest zaproszeniem do tego, aby benchmark był zabawny. Uznaje ona, że humor jest testem stresowym dla kontekstu. Tłumaczenie dosłowne może zachować słowa i zniszczyć żart. Tłumaczenie zaadaptowane kulturowo może zachować efekt, zmieniając odniesienie. W publicznej służbie informacyjnej ten sam mechanizm pojawia się bez śmiechu. Przysłowie, lokalna nazwa miejsca czy formalne powitanie mogą sygnalizować, kto mówi i jaką relację komunikat tworzy.

Gdy zespoły mówią, że model rozumie język, powinny zapytać, którą warstwę mają na myśli. Czy rozpoznaje pismo? Poprawnie segmentuje słowa? Identyfikuje byty? Tłumaczy propozycję? Zachowuje moc prawną? Stosuje się do lokalnej konwencji? Utrzymuje poziom pewności mówiącego? Radzi sobie z niestandardową pisownią? Odpowiada we właściwym rejestrze? To osobne możliwości. Jedna etykieta zwana wielojęzycznością ukrywa pracę potrzebną do ustanowienia każdej z nich.

Dlaczego ewaluacja musi podróżować z językiem

Ewaluacja jest często dodawana na końcu, ponieważ zespoły chcą mieć liczbę do przypisania modelowi. Systemy wielojęzyczne czynią taką kolejność niemożliwą. Dane testowe decydują o tym, co uznaje się za błąd. Język decyduje o tym, jak zdanie może zawieść. Dziedzina decyduje o tym, która porażka ma znaczenie. Użytkownik decyduje o tym, czy odpowiedź systemu jest pomocą, czy przeszkodą. Ewaluacja musi podróżować ze wszystkimi czterema.

Europejski artykuł naukowy Towards Multilingual LLM Evaluation for European Languages pokazuje skalę problemu. Autorzy oceniają 40 modeli językowych w 21 językach europejskich, badają przetłumaczone wersje pięciu powszechnie używanych benchmarków i publikują framework obejmujący EU20-MMLU, EU20-HellaSwag, EU20-ARC, EU20-TruthfulQA i EU20-GSM8K. Artykuł nie twierdzi, że przetłumaczenie istniejącego benchmarku automatycznie czyni go sprawiedliwym. Traktuje usługi tłumaczeniowe, konstrukcję benchmarku i porównywalność międzyjęzykową jako rzeczy do zbadania.

To właściwa postawa. Przetłumaczony element testu może odziedziczyć zmianę trudności, założenie kulturowe lub wskazówkę, która nie istniała w oryginale. Model może uzyskać wyższy wynik, ponieważ przetłumaczone sformułowanie ułatwia odpowiedź, a nie dlatego, że model stał się bardziej zdolny. Może uzyskać niższy wynik, ponieważ konstrukcja gramatyczna jest nienaturalna w języku docelowym, mimo że leżące u podstaw rozumowanie jest poprawne. Oba wyniki są dowodem dotyczącym zarówno testu, jak i modelu.

Przegląd ludzki pozostaje konieczny, ale przegląd ludzki również potrzebuje umowy. Kto dokonał przeglądu elementu? Czy recenzenci byli rodzimymi użytkownikami języka, specjalistami dziedzinowymi, czy jednym i drugim? Czy przeglądali izolowane zdania, czy zadanie w kontekście? Czy zarejestrowano rozbieżności? Czy benchmark zachował alternatywne akceptowalne odpowiedzi? Ekspert językowy może nam powiedzieć, że fraza jest błędna. Ekspert dziedzinowy może nam powiedzieć, dlaczego błędność zmienia decyzję. Wiarygodna ewaluacja często potrzebuje obu i musi powiedzieć, którego miała.

Nie chodzi o to, aby każdy system przeszedł niekończący się egzamin, zanim ktokolwiek będzie mógł go użyć. Chodzi o to, aby zapobiec pomyleniu wąskiego testu z szerokim twierdzeniem. Jeśli model został oceniony na krótkich pytaniach faktycznych w standardowym języku pisanym, należy to zgłosić. Nie pozwól, aby wynik po cichu stał się twierdzeniem o interakcji mówionej, redagowaniu aktów prawnych, samorządzie lokalnym, dzieciach, osobach starszych czy każdym rejestrze w języku.

Wynik staje się użyteczny, gdy widoczna pozostaje granica zadania, języka, kontekstu i przeglądu ludzkiego.

Lekcja z maltańskiego i baskijskiego

Artykuł przedstawiony na konferencji LREC-COLING w 2024 roku badał ocenę tłumaczenia maszynowego z angielskiego na maltański i z hiszpańskiego na baskijski. Autorzy przeanalizowali metrykę oceny COMET, zebrali bezpośrednie oceny ludzkie i sprawdzili, jak dobrze metryka zachowuje się po dostosowaniu do tych dwóch par językowych. Ich wniosek jest skromny, ale istotny: skuteczność metryki może się poprawić dzięki dostrojeniu, a jednocześnie może być bardzo wrażliwa na rozkład wyników w danych treningowych, zwłaszcza w warunkach ograniczonych zasobów.

To nie jest opowieść o tym, że jedna metryka zawiodła. To opowieść o tym, od czego zależy wynik. Metryka wytrenowana na jednym rozkładzie może zachowywać się inaczej, gdy poprosi się ją o ocenę innego. Para językowa z mniejszą ilością materiału do oceny może sprawić, że wynik będzie wyglądał na bardziej rozstrzygający, niż jest w rzeczywistości. System, który wygodnie porównywać, może być słabym przybliżeniem tego, co użytkownicy uznają za dobre tłumaczenie. Oceny ludzkie nie czynią ewaluacji doskonałą, ale ujawniają miejsca, w których automatyczna miara przyjmuje założenia.

Kolejne badanie z 2024 roku, Benchmarking Low-Resource Machine Translation Systems, porównuje publicznie dostępne systemy na czterech zbiorach danych i 26 językach, a wyniki publikuje za pośrednictwem BENG, platformy FAIR do testów porównawczych generowania języka naturalnego. I tutaj wkład nie polega na uniwersalnym rankingu. Chodzi o bardziej przejrzyste porównanie. Wydajność i skuteczność są rozpatrywane razem, a lista języków jest widoczna. Czytelnik może zapytać, czy test porównawczy obejmuje trasę, która ma znaczenie, zamiast przyjmować pojedynczą liczbę w nagłówku.

Te badania dają europejską lekcję powściągliwości. Trudna część nie polega na wymyśleniu kolejnego wyniku. Chodzi o zbudowanie ewaluacji, która pozwala czytelnikowi zobaczyć, czyj język, czyje zadanie i czyja definicja jakości wyprodukowały ten wynik. Gdy brakuje tego kontekstu, liczba staje się przekroczeniem granicy bez paszportu. Może przejść przez prezentację, ale nikt nie jest w stanie ustalić, skąd pochodzi.

Pokrycie językowe może być właściwością bezpieczeństwa

Dyskusje o bezpieczeństwie często skupiają się na treści, której system powinien odmówić, atakach, którym powinien się oprzeć, lub błędach, które powinien wychwycić. Język dodaje kolejne pytanie: czy system potrafi rozpoznać, kiedy znajduje się poza obszarem swoich kompetencji? Trasa, która działa w jednym języku, w innym może zawieść częściej, zachowując przy tym ten sam pewny ton. Jeśli interfejs nie ujawnia tej różnicy, użytkownicy nie mogą skalibrować swojego zaufania.

Jest to szczególnie istotne, gdy język stanowi część interakcji krytycznej dla bezpieczeństwa. Pacjent może opisać objaw w regionalnej odmianie języka. Pracownik może zgłosić zagrożenie, używając lokalnego terminu. Mieszkaniec może złożyć odwołanie, stosując konwencję pisowni, którą normalizator traktuje jako szum. Model może być technicznie dokładny w swoim benchmarku, a operacyjnie niebezpieczny dla tej trasy. Istotne pytanie nie brzmi, czy system potrafi wygenerować prawdopodobną odpowiedź. Brzmi ono: czy mechanizmy bezpieczeństwa zostały ocenione pod kątem języka i sytuacji, z którymi system się styka.

Bezpieczeństwo nie wymaga traktowania każdej trasy językowej jako szczególnego zagrożenia. Wymaga dopasowania mechanizmu kontroli do konsekwencji. Wynik wyszukiwania niskiego ryzyka może ujawnić swoje źródła i zachęcać do korekty. Interfejs segregacji medycznej może kierować niejednoznaczne dane językowe do przeszkolonego specjalisty. System obsługi dokumentów prawnych może trzymać źródło i tłumaczenie obok siebie oraz wymagać zatwierdzenia przed publikacją. System głosowy może poprosić użytkownika o powtórzenie nazwiska, zamiast po cichu wybierać najbliższą znaną encję. To zwykłe decyzje inżynieryjne, gdy język traktuje się jako część granicy systemu.

Sama odmowa wymaga zaprojektowania językowego. Poinformowanie użytkownika, że system nie potrafi odpowiedzieć, to za mało, jeśli odmowa jest nieprzejrzysta, protekcjonalna lub niedostępna w języku użytkownika. System powinien powiedzieć, czego nie udało się ustalić, jakie informacje byłyby pomocne oraz jaka trasa ludzka lub autorytatywna jest dostępna. W przeciwnym razie mechanizm bezpieczeństwa staje się kolejną barierą dostępu. Europejska zasada językowa jest testowana najwyraźniej wtedy, gdy system nie może udzielić żądanej odpowiedzi.

Projekt operacyjny usługi wielojęzycznej

Godna zaufania usługa wielojęzyczna ma kształt operacyjny, który łatwo opisać, a zaskakująco trudno utrzymać. Po pierwsze, nazywa zadanie. Tłumaczenie, transkrypcja, klasyfikacja, wyszukiwanie, streszczanie i generowanie nie są wymienne. Po drugie, nazywa trasę językową, w tym pismo oraz wszelkie istotne granice regionalne lub dziedzinowe. Po trzecie, rejestruje materiał źródłowy i przekształcenia, którym został poddany. Po czwarte, określa ścieżkę przeglądu i eskalacji. Po piąte, informuje użytkownika, co system może, a czego nie może twierdzić.

Te kroki nie są żądaniem stworzenia wielkiej biurokracji. To minimum potrzebne do tego, aby obietnica językowa była weryfikowalna. Jeśli dostawca twierdzi, że model obsługuje fiński, nabywca powinien móc zapytać, czy oznacza to generowanie tekstu, rozpoznawanie mowy, tłumaczenie z których języków, czy też wszystko powyższe. Jeśli zespół produktowy twierdzi, że obsługuje język regionalny, powinien określić, czy wsparcie opiera się na danych rodzimych, danych tłumaczonych, małym zestawie ewaluacyjnym czy przeglądzie eksperckim. Jeśli odpowiedź jest nieznana, status „nieznane” jest ważny.

Usługa potrzebuje również polityki zmian. Nowy materiał szkoleniowy, nowy tokenizator, nowy model tłumaczenia, nowa lista terminologiczna czy nowa grupa użytkowników mogą zmienić zachowanie językowe. Wydanie, które poprawia jedną trasę, może pogorszyć inną. Wynik benchmarku z zeszłego roku nie opisuje automatycznie dzisiejszego systemu. Rejestry wersji, testy porównawcze i ścieżka zgłaszania błędów językowych sprawiają, że usługa jest możliwa do utrzymania, a nie tylko ceremonialna.

Utrzymanie ma ludzki wymiar. Eksperci językowi potrzebują sposobu, aby zobaczyć błędy wpływające na ich społeczności. Zespoły dziedzinowe potrzebują sposobu, aby odróżnić błąd tłumaczenia od niejednoznaczności polityki. Operatorzy potrzebują sposobu, aby wstrzymać trasę bez czekania, aż dostawca modelu zinterpretuje skargę. Użytkownicy potrzebują sposobu, aby powiedzieć, że system źle zrozumiał słowo, kontekst lub imię osoby. Usługa wielojęzyczna nie jest kompletna, gdy model zostanie wdrożony. Jest wystarczająco kompletna, aby być odpowiedzialna, gdy pojawi się kolejny problem językowy.

Proweniencja w potoku językowym

Pochodzenie staje się konkretne, gdy prześledzimy jeden fragment znaczenia przez cały system. Zacznij od akapitu źródłowego. Zapisz jego język, pismo, autora lub instytucję, jeśli są znane, prawa i cel. Jeśli tekst został podzielony na segmenty, zachowaj relację do oryginału. Jeśli został przetłumaczony, zachowaj informację o źródle oraz tłumaczu lub procesie tłumaczenia. Jeśli recenzent zmieni sformułowania, zapisz to jako nowy stan, a nie jako cichą podmianę. Jeśli akapit stanie się elementem testu porównawczego, przenieś wraz z nim zadanie, klucz odpowiedzi, język i zapis recenzji.

W czasie działania systemu ta sama dyscyplina obowiązuje w odwrotnym kierunku. Zapisz, która ścieżka językowa obsłużyła zapytanie, która wersja modelu lub narzędzia została uruchomiona, jakie dowody źródłowe pobrano, do jakiego stanu niepewności lub odmowy doszło oraz jakie działanie człowieka nastąpiło później. Zapis nie musi ujawniać prywatnych treści każdemu operatorowi. Musi jednak udostępniać istotne fakty upoważnionemu recenzentowi. Bez nich incydent językowy staje się sporem o wrażenia.

W tym miejscu pochodzenie wielojęzyczne różni się od ogólnego dziennika audytu. Znacznik czasu i nazwa modelu mówią nam, że coś się wydarzyło. Nie mówią nam, czy źródło zostało przetłumaczone, czy odpowiedź zmieniła format liczby, czy nazwa własna została znormalizowana albo czy recenzent pracował w języku docelowym. Ścieżka przekształceń jest dowodem. Krótka odpowiedź może ukrywać długi łańcuch decyzji.

Jest w tym podejściu mała holenderska cnota: prowadź rejestr na tyle nudno, żeby ktoś mógł z niego skorzystać we wtorkowe popołudnie. Zapis pochodzenia nie powinien być etykietą muzealną napisaną pod audyt, który może nigdy nie nadejść. Ma pomóc operatorowi odpowiedzieć na następne pytanie, zatrzymać właściwą ścieżkę i wyjaśnić wynik osobie, która nie ma żadnego interesu w twoim schemacie architektury. Dobre zarządzanie językiem jest odrobinę nudne. To właśnie znak, że może przetrwać kontakt z pracą.

Ukryte wybory w tłumaczeniu

Każdy system tłumaczący niesie ze sobą wybory, które zasługują na nazwanie. Tokenizacja decyduje, jak dzielone są dane wejściowe. Normalizacja decyduje, które rozróżnienia są zachowywane, a które odrzucane. Dopasowanie decyduje, które części dwóch tekstów są traktowane jako równoważne. Terminologia decyduje, które słowa są stabilne. Dekodowanie decyduje, jak wybierany jest wynik. Post-processing decyduje o tym, co widzi czytelnik. Żaden z tych kroków nie jest z natury błędny. Każdy może stworzyć awarię specyficzną dla języka, niewidoczną w ogólnym demo.

Weźmy nazwę własną. System może ją przetłumaczyć, transliterować, zachować lub zastąpić znajomą pisownią. W przypadku wiersza kilka wyborów może być uzasadnionych. W przypadku dokumentu tożsamości tylko jeden może być dopuszczalny i ten jeden może zależeć od organu wydającego. Weźmy jednostkę lub datę. Wartości mogą pozostać matematycznie równoważne, podczas gdy forma stanie się niejednoznaczna dla czytelnika. Weźmy rzeczownik lub zaimek rodzajowy. Tłumaczenie może wprowadzić informację, której źródło nie ujawniło, albo zatrzeć rozróżnienie, które źródło celowo uczyniło.

Odpowiedzią projektową nie jest zamrożenie języka. Jest nią określenie polityki i uczynienie wyjątku widocznym. Lista terminologiczna może chronić terminy prawne. Reguła nazw własnych może zapobiec przekształceniu miasta w osobę. Widok zachowujący źródło może pozwolić recenzentowi porównać oryginał z wynikiem. Eskalacja do człowieka może być wyzwalana przez nazwę o niskiej pewności, niezgodność między ścieżkami lub zadanie sklasyfikowane jako obarczone wysokimi konsekwencjami. Model pozostaje użyteczny, ponieważ jego granice są częścią przepływu pracy.

Duże modele językowe utrudniają dostrzeżenie błędnych wyborów, ponieważ ich wyniki są płynne. Płynny wynik to wspaniały interfejs, ale zawodne wyjaśnienie. System może wygenerować zdanie, które brzmi naturalnie, a jednocześnie wybrać błędne znaczenie słowa. Może zachować ogólny temat, ale pominąć zaprzeczenie. Może przetłumaczyć lokalne wyrażenie na standardowy zwrot, który zmienia stanowisko mówiącego. Dlatego jakości języka nie można opisywać wyłącznie przez gramatykę. Znaczenie ma kształt społeczny.

Pisma, dialekty, rejestry i instytucje

Wsparcie językowe jest często ogłaszane na poziomie nazwy języka, ale czytelnicy spotykają się z pismami, odmianami i rejestrami. System, który radzi sobie ze współczesną standardową pisownią, może mieć trudności z dokumentami historycznymi. Rozpoznawanie mowy może działać na nagraniach studyjnych, a zawieść na zatłoczonym dworcu. Chatbot obsługujący klientów może odpowiadać formalnym rejestrem, podczas gdy użytkownik potrzebuje prostego języka. Instytucja może używać terminu, który różni się od mowy potocznej z powodów istotnych prawnie.

To nie są przypadki brzegowe w lekceważącym znaczeniu. To miejsca, w których język styka się ze światem. Nazwa regionalna może przesądzać o tym, czy adres jest poprawny, a przesyłka dotrze. Słowo dialektalne może być jedynym słowem, jakie dana osoba zna na określenie objawu. Formalne sformułowanie może sygnalizować, że wiadomość ma skutek prawny. Wariant pisma może decydować o tym, czy dokument da się przeszukać. Jeśli benchmark pomija te ścieżki, może być nadal użyteczny, ale nie może zastąpić całego języka.

Testowanie wszystkich odmian nie zawsze jest możliwe. Uczciwą odpowiedzią jest opisanie obsługiwanego podzbioru i zaproszenie do przedstawiania dowodów na temat reszty. System może opublikować informację, że został oceniony pod kątem streszczania informacji publicznych w standardowym niderlandzkim piśmiennym, bez roszczeń co do regionalnego rozpoznawania mowy. Może dodać test dla fryzyjskiego lub baskijskiego, nie udając, że ten dodatek rozwiązuje wszystkie kwestie języków regionalnych i mniejszościowych. Precyzja nie jest słabością. Mówi użytkownikom, gdzie jest granica.

Instytucje powinny też opierać się przekonaniu, że jedna narodowa ścieżka językowa jest automatycznie neutralna. Język administracyjny może być niedostępny dla osób mówiących tym samym językiem. Dostępność i wielojęzyczność nakładają się na siebie, ponieważ obie dotyczą pytania, czy czytelnik może zrozumieć i działać. Prace językowe Komisji obejmują narzędzia do upraszczania i teksty dostępne właśnie z tego powodu. Zdanie może być poprawne językowo, a mimo to bezużyteczne instytucjonalnie.

Gdy interfejs jest płynny, ale błędny

Najtrudniejsze błędy językowe nie są spektakularne. To odpowiedzi, które przechodzą test wzrokowy. Streszczenie zawiera właściwe nazwy, ale zmienia osobę odpowiedzialną. Tłumaczenie zachowuje rzeczowniki, ale zamienia zalecenie w polecenie. Klasyfikator rozumie temat, ale pomija zaprzeczenie. System głosowy rozpoznaje słowa, ale nie wahanie mówiącego. Użytkownik czyta wynik we własnym języku i zakłada, że płynność świadczy o staranności.

Powinniśmy projektować z myślą o tej klasie błędów, zamiast czekać, aż jakiś kuriozalny przykład trafi na nagłówki. Porównuj źródło i wynik w przypadku treści o dużym znaczeniu. Zachowuj znaczniki niepewności. Utrzymuj cytowania i odniesienia do dokumentów. Proś o potwierdzenie, gdy liczba, nazwa lub termin są kluczowe. Udostępnij operatorowi widoczność ścieżki. Zapewnij mechanizm korekty, który nie wymaga od użytkownika wiedzy, który komponent zawiódł. Te mechanizmy są drobne, ale zamieniają tłumaczenie w transakcję, którą można sprawdzić.

Recenzji ludzkiej nie należy opisywać jako magicznej ostatniej linii obrony. Recenzenci mają ograniczenia czasowe, luki w wiedzy dziedzinowej i własne założenia językowe. Przydatny interfejs recenzyjny daje im źródło, wynik, kontekst i powód eskalacji. Odnotowuje rozbieżności zamiast je zacierać. Jeśli recenzenci wielokrotnie poprawiają dany termin, organizacja może ulepszyć terminologię lub zmienić zakres zadania. Jeśli rozbieżność ujawni, że samo źródło jest niejednoznaczne, właściwym działaniem może być zapytanie autora, a nie intensywniejsze trenowanie modelu.

Operatorzy potrzebują też sposobu na zobaczenie negatywnych dowodów. Które języki nie zostały ocenione? Które zadania nie mają recenzji ludzkiej? Które prośby zostały odrzucone? Którzy użytkownicy opuścili ścieżkę po tłumaczeniu? Brak może być sygnałem. Zielony wykres pokrycia, który pomija nieudane ścieżki, jest mapą powierzchni marketingowej, a nie usługi.

Wiedza ekspercka człowieka nie jest przyciskiem awaryjnym

Europejska polityka dotycząca technologii językowych stawia lingwistów, naukowców danych, inżynierów komputerowych i specjalistów dziedzinowych w jednym zdaniu. To wymóg projektowy, a nie lista zawodów do zaproszenia na spotkanie inauguracyjne. Każda z tych osób widzi inny rodzaj błędu. Lingwista widzi nienaturalną konstrukcję lub utracone rozróżnienie. Inżynier widzi problem z segmentacją lub routingiem. Specjalista dziedzinowy widzi niebezpieczny błąd kategoryzacji. Operator widzi kolejkę, za którą nikt nie chce odpowiadać. Osoba korzystająca z usługi doświadcza decyzji, która przestaje mieć sens.

Wiedza ekspercka człowieka powinna zostać włączona, zanim benchmark zostanie zamrożony. Ekspert językowy może pomóc w doborze materiału testowego reprezentującego rzeczywiste rejestry, a nie tylko czyste zdania. Ekspert dziedzinowy może wskazać terminy, które nie mogą się zmieniać. Przedstawiciel społeczności może powiedzieć zespołowi, które sformułowania brzmią urzędowo, swojsko lub obraźliwie. Opiekun danych może wyjaśnić, jakie pochodzenie danych jest dostępne, a jakie nie. Te wkłady kształtują kontrakt systemu. Nie są ozdobą po dokonaniu wyborów technicznych.

Oczywiście jest koszt. Dobra recenzja wymaga czasu i płaci ludziom za wiedzę, która często jest traktowana jako niewidzialna. Ten koszt jest częścią wsparcia językowego. Alternatywą jest przerzucenie go na użytkowników, którzy płacą zamieszaniem i odwołaniami, lub na pracowników, którzy nieformalnie tłumaczą i naprawiają ścieżkę. System, który wydaje się tani, bo ignoruje wiedzę językową, nie jest wydajny. Po prostu przeniósł rachunek gdzie indziej.

Co musi ujawniać uczciwy benchmark

Wielojęzyczny benchmark powinien zaczynać się od twierdzenia na tyle wąskiego, by można je było przetestować. Twierdzenie może głosić, że system potrafi odpowiadać na pytania dotyczące informacji publicznej w zestawie języków, zachowywać daty i liczby oraz odmawiać odpowiedzi, gdy brakuje dowodów źródłowych. Może głosić, że ścieżka tłumaczenia obsługuje konkretną parę języków i dziedzinę na określonym poziomie jakości. Może głosić, że rozpoznawanie mowy potrafi transkrybować określoną odmianę języka w określonych warunkach akustycznych. Benchmark jest kontraktem dla tego twierdzenia.

Kontrakt potrzebuje czegoś więcej niż listy języków. Powinien ujawniać zadanie, źródło, dziedzinę, rejestr, pismo, kierunek, długość kontekstu, warunki wejściowe, odpowiedzi referencyjne, dopuszczalne warianty, metryki, recenzję ludzką i niepewność. Powinien określać, czy pozycje zostały pierwotnie napisane w danym języku, czy przetłumaczone. Powinien odnotowywać, kto je poprawił i jakie rozbieżności pozostały. Powinien oddzielać wyniki zagregowane od wyników dla poszczególnych języków. Powinien pokazywać wystarczająco dużo przykładów, aby czytelnik mógł zrozumieć, co mierzy wynik.

Kryteria EU MMLU są przydatne, ponieważ poszerzają znaczenie słowa „uczciwy”. Jedną z ich części jest zrównoważona reprezentacja języków urzędowych UE. Inną jest zachowanie znaczenia, trudności i wartości testowej w różnych językach. Testowanie wartości i kontekstów kulturowych UE, w tym idiomów, humoru, odniesień, formatów dat i liczb, tonu i uprzejmości, czyni z tego benchmarku instrument społeczny, a nie tylko techniczny. Kryteria nie eliminują oceny. Sprawiają, że ocena ta jest możliwa do sprawdzenia.

Twórcy benchmarków powinni publikować przekroje błędów, a nie tylko średnie. Model może mieć dobrą średnią punktację, a jednocześnie nie zdawać żadnego zadania dotyczącego konkretnego rejestru lub typu liczb. Trasa może być wydajna w jednym kierunku, a w drugim wolna lub kosztowna. Metryka może korelować z oceną ludzką w jednym języku, a w innym stać się niestabilna. Widoki per język i per zadanie nie są luksusem. To sposób, w jaki kupujący unika zakupu średniej, a wdrażania wyjątku.

Na koniec benchmark powinien określić, czego nie może nam powiedzieć. Test pisemny nie dowodzi sprawności w mowie. Wynik tłumaczenia nie dowodzi niezawodności prawnej. Zestaw języków urzędowych nie dowodzi wsparcia dla języków regionalnych lub mniejszościowych. Wysoki wynik nie dowodzi, że dana osoba może zakwestionować decyzję. To ograniczenie nie jest powodem do wstydu. To krawędź mapy, którą użytkownicy muszą zobaczyć, zanim wypłyną.

Wynik to legenda mapy, a nie terytorium

Liczby są przydatne, ponieważ wymuszają porównanie. Są niebezpieczne, ponieważ zachęcają do wyciągania wniosków szerszych niż sam pomiar. Wynik może nam powiedzieć, jak system zachował się na zdefiniowanej próbce przy użyciu zdefiniowanej metody. Nie może nam powiedzieć, jak społeczność odbierze system bez pomostu założeń. Pomost ten może być solidny. Musi być jednak nazwany.

Zakładając, że system poprawia się w wielojęzycznym benchmarku po dostrojeniu. To dowód lepszych wyników w tej konkretnej ewaluacji. Nie jest to automatycznie dowód, że system jest bezpieczniejszy w usłudze publicznej. Usługa może korzystać z innej terminologii, dłuższego kontekstu, wprowadzania mowy, innego rejestru lub dalszego procesu, który zamienia sugestię w decyzję. Benchmark nadal może być wartościowy. Staje się bardziej wartościowy, gdy organizacja określa, którą część usługi reprezentuje.

Ta sama dyscyplina dotyczy energii, szybkości i kosztów. Trasa dla języka o niskich zasobach może wymagać większego przeglądu przez człowieka lub większego kontekstu wyszukiwania. To nie jest wada, którą należy ukrywać w średniej. To właściwość usługi, która powinna wpływać na projekt. Instytucje europejskie od dziesięcioleci budują usługi tłumaczeniowe i językowe, ponieważ praktyczny koszt różnorodności językowej jest realny. System AI nie znosi tego kosztu, szybko generując tekst.

Nie ma wstydu w wyborze węższej trasy. Zespół może dobrze obsługiwać mniej zadań, opublikować granicę i dodawać języki w miarę gromadzenia dowodów. To lepsze niż deklarowanie każdego języka i pozostawienie użytkownikom odkrywania luk. Europejski instynkt do standardów jest najsilniejszy, gdy łączy się z holenderskim instynktem sprawdzania, czy coś działa w zwykłą środę.

Projektuj dla 24, testuj poza 24

Unia Europejska ma 24 języki urzędowe i robocze, a służba tłumaczeniowa Komisji działa we wszystkich z nich. Liczba ta stanowi użyteczną podstawę dla infrastruktury publicznej. Nie definiuje jednak życia językowego Europy. Języki regionalne, mniejszościowe, nieterytorialne i migracyjne również kształtują społeczności i instytucje. System zaprojektowany dla 24 języków może nadal wykluczać osoby, które nie korzystają z żadnej z tych tras lub które używają języka urzędowego w formie, której system nie ocenił.

Budowanie dla 24 języków to zatem odpowiedzialność, aby punkt wyjścia był realny, a nie przyzwolenie na zatrzymanie się. Trasa językowa powinna nieść ze sobą własne dowody. Instytucja publiczna powinna móc określić, które języki urzędowe są objęte obsługą i dla jakich zadań, jaka kontrola ludzka istnieje oraz gdzie użytkownicy mogą uzyskać wersję autorytatywną. Powinna też mieć sposób na uczenie się z języków spoza początkowego zestawu, bez zamieniania społeczności w nieodpłatne laboratorium testowe.

Testowanie wykraczające poza 24 języki to coś więcej niż dodanie egzotycznego języka do demonstracji. Oznacza pracę z użytkownikami, instytucjami i badaczami nad ustaleniem, czym jest zadanie, do czego mogą być wykorzystywane materiały źródłowe oraz co stanowi szkodliwy błąd. Proces ten może przynieść niewielką, starannie zakreśloną funkcjonalność. To wciąż postęp. Skromna trasa z jasną umową może być cenniejsza niż imponująca deklaracja, której żaden operator nie jest w stanie obronić.

Co staramy się uczynić jawnym

W Dweve podchodzimy do tego tematu od strony infrastruktury. Loom jest opisany w naszych publicznych materiałach produktowych jako model poznawczy kompilujący zadania, którego komponenty językowe tworzą zarządzany graf wyników, podczas gdy uczenie ograniczeń, kompozycja grafów, solvery i weryfikacja ponoszą odpowiedzialność decyzyjną. To stanowisko architektoniczne, a nie deklaracja możliwości wielojęzycznych. Nie czyni ono trasy językowej poprawną. Sprawia jednak, że trudno ukryć jeden obowiązek: wynik językowy nie powinien być jedynym miejscem, w którym istnieją rozumowanie i dowody systemu.

Nasza praca nad Ground Truth ukazuje tę samą kwestię w bardziej ludzkiej skali. Ludzie potrzebują wystarczająco wspólnego słownictwa, aby odróżnić model od przepływu pracy, przewidywanie od dowodu i płynną odpowiedź od wyniku sprawdzonego. W systemach wielojęzycznych to słownictwo potrzebuje jeszcze jednego słowa: trasa. Odpowiedź po niderlandzku, po francusku i po baskijsku nie jest jedynie odwzorowaniem jednego wewnętrznego zdarzenia, jeśli dowody, terminologia, kontrola i zachowanie w przypadku błędu się różnią. Trasa jest częścią deklaracji.

To stanowisko jest celowo mniej ekscytujące niż stwierdzenie, że jeden model rozumie Europę. Jest też bardziej użyteczne. Chcemy, aby system pokazywał, co otrzymał, jakie źródła i ograniczenia mógł wykorzystać, czego nie był w stanie ustalić oraz kiedy człowiek powinien przejąć kontrolę. Język jest powierzchnią, przez którą człowiek spotyka się z tą pracą. Powierzchnia powinna być przejrzysta, ale nie wolno jej pozwolić na zatarcie struktury pod spodem.

Nie jesteśmy zwolnieni ze standardów opisanych tutaj. Pole pochodzenia nie naprawia brakujących danych. Deterministyczna ścieżka nie dowodzi, że tłumaczenie jest rzetelne. Europejska granica przetwarzania nie nadaje kompetencji językowych. Jedynym uczciwym sposobem na złożenie deklaracji wielojęzycznej jest ciągłe testowanie, publikowanie ograniczeń i pozwalanie ekspertom językowym na kwestionowanie trasy. Nazwa produktu nie jest dowodem. Dowodem jest zapis.

Praktyczny standard dla zespołów

Zespoły decydujące o wprowadzeniu wielojęzycznej funkcji AI mogą zacząć od krótkiego zestawu pytań. Co dokładnie system musi robić w każdym języku? Którzy ludzie ucierpią, jeśli się pomyli? Które materiały źródłowe są autorytatywne? Jak powstały elementy testowe i kto je stworzył? Jakie rejestry, pisma, dialekty i dziedziny mieszczą się w deklaracji? Co robi system, gdy nie może ustalić znaczenia? Kto może wstrzymać trasę? Jak użytkownik może poprawić odpowiedź, nie stając się nieodpłatnym lingwistą projektu?

Pytania stają się konkretne, gdy powiąże się je z artefaktami. Prowadź kartę trasy językowej z zadaniem, obsługiwanymi odmianami językowymi, rodzinami źródeł, statusem praw, wersjami modelu i narzędzi, wynikami oceny, znanymi trybami awarii i osobą odpowiedzialną za kontrolę. Przechowuj przykłady błędów wraz z ich kontekstem, nie tylko wyniki liczbowe. Trzymaj źródło obok tłumaczenia o wysokich konsekwencjach. Zachowaj zrozumiały dla operatora powód eskalacji. Prowadź rejestr zmian, gdy zmienia się tokenizer, lista terminologiczna, benchmark lub model.

Zespoły zakupowe mogą prosić dostawców o wyniki w podziale na języki i zadania, zamiast jednej wielojęzycznej średniej. Mogą pytać, czy benchmark został przetłumaczony, czy napisany natywnie, czy dostępne są oceny ludzkie, jak obsługiwane są trasy dla języków o małych zasobach oraz czy dostawca może wyeksportować dowody potrzebne do przeglądu. Mogą pytać, co się dzieje, gdy język nie jest obsługiwany, ponieważ odmowa i ciche przejście na język zastępczy mają bardzo różne konsekwencje.

Zespoły produktowe mogą zaprojektować interfejs tak, aby pokazywał trasę i poziom pewności, bez udawania, że liczba pewności jest prawdopodobieństwem prawdy. Mogą zachowywać linki do źródeł, używać prostego języka w odmowach i czynić działania przeglądowe widocznymi. Mogą unikać sformułowania „obsługuje wszystkie języki”, chyba że potrafią zdefiniować ten czasownik. „Obsługuje” może oznaczać wyświetla tekst, przyjmuje dane wejściowe, tłumaczy, streszcza, odpowiada, klasyfikuje, mówi lub obsługuje regulowany proces. Selektor języka nie jest specyfikacją.

Zespoły badawcze mogą publikować zbiory danych z informacją o pochodzeniu i ścieżkami poprawek. Mogą uwzględniać wyniki negatywne i raportować, gdy metryka nie przenosi się dobrze na inne konteksty. Mogą zapraszać społeczności językowe do oceny, zanim model zostanie uznany za gotowy, i płacić za tę wiedzę specjalistyczną. Mogą opierać się presji, aby przekształcać wąski wynik w uniwersalne twierdzenie. Najcenniejszy benchmark może być tym, który sprawia, że zespół usuwa zdanie ze swojej strony produktowej.

Społeczeństwo stojące za modelem

Model językowy może być bardzo dobry w tworzeniu języka, nie wiedząc, co język robi w społeczeństwie. Może przewidzieć frazę, przetłumaczyć akapit i odpowiedzieć na pytanie, jednocześnie pomijając instytucjonalną relację niesioną przez słowa. Ta luka nie jest dowodem na to, że model jest bezużyteczny. Jest dowodem na to, że język to coś więcej niż typ danych.

Odpowiedzią Europy nie powinien być wyścig w liczeniu języków w karcie modelu. Powinien to być trwały wysiłek, aby dane językowe, prawa, wiedza specjalistyczna, ocena i kontrola publiczna stały się częścią tej samej infrastruktury. Prace Komisji nad technologiami językowymi, Language Data Space, European Language Grid i benchmark EU MMLU wskazują w tym kierunku. Europejscy badacze testują, co się dzieje, gdy przetłumaczone benchmarki traktuje się jako pytania badawcze, a nie jako niekwestionowane narzędzia. Ta praca zasługuje na uwagę, ponieważ czyni stary fakt polityczny widocznym technicznie: ludzie nie doświadczają Unii w jednym języku.

Następnym razem, gdy dostawca powie, że model jest wielojęzyczny, zapytaj, co zawiera to twierdzenie. Które języki? Które zadania? Które społeczności? Które źródła? Jaki przegląd? Jaka odmowa? Jaki rejestr zmian? To pytanie nie jest wrogie. To zwykły początek odpowiedzialności.

Społeczeństwo nie staje się sprawiedliwe, ponieważ maszyna potrafi powtarzać jego słowa. Staje się bardziej sprawiedliwe, gdy ludzie mogą wchodzić do jego instytucji, rozumieć, co się dzieje, kwestionować wynik i być wysłuchani w języku, który niesie ich życie. Model może wspierać tę pracę. Nie może jej definiować. Język modelu to zdolność techniczna. Język społeczeństwa to wspólna odpowiedzialność.

Źródła