Research tłumaczeniowy i przygotowanie danych w czasach AI

Research tłumaczeniowy to zbieranie informacji, terminologii, źródeł i kontekstu przed przekładem lub w jego trakcie. Choć dziś coraz częściej odbywa się z pomocą modeli językowych, musi być zawsze poparty zewnętrzną weryfikacją źródeł.

Tradycyjnie opierał się na czterech filarach: fizycznych źródłach (słownikach, publikacjach branżowych), wiedzy ekspertów dziedzinowych, zasobach elektronicznych (pamięciach tłumaczeń, bazach terminologicznych) i Internecie. Modele językowe dołączyły do tej listy stosunkowo niedawno, i zrobiły to z takim impetem, że wielu tłumaczy kusi, by wyrzucić wszystkie poprzednie narzędzia.

To byłby błąd.

Problem: LLM jako jedyne źródło prawdy

Nie ulega wątpliwości, że modele językowe mają imponujące możliwości. Potrafią generować terminologię w dziesiątkach dziedzin, tłumaczyć kontekst, streszczać artykuły. Mają jednak fundamentalny problem, który szerzej opisujemy w artykule o halucynacjach: nie wiedzą, kiedy się mylą, i same tego nie rozpoznają.

W kontekście researchu tłumaczeniowego przekłada się to na konkretne typy błędów: termin brzmiący wiarygodnie, ale nieużywany w branży; link do artykułu, który nie istnieje lub zawiera zupełnie inną treść; „cytat", który nigdy nie pojawił się w podanym źródle.

Od procesu niedeterministycznego do deterministycznego

Odpowiedź to ten sam schemat, co w ogólnym procesie deterministycznym: LLM jest tylko jednym z wielu kroków i nigdy nie jest krokiem, który samodzielnie decyduje o wiarygodności danych.

Weryfikacja zewnętrzna, czyli coś, co nie polega na kolejnym zapytaniu do modelu, musi tu być deterministyczna. W praktyce oznacza to skrypt sprawdzający, czy podany URL istnieje i czy szukana fraza rzeczywiście się na nim znajduje. Nie wystarczy więc sprawdzić, czy URL podawany jako źródło istnieje: trzeba też potwierdzić, że cytowana treść rzeczywiście jest pod tym adresem.

Agenty AI w praktyce: co nie działa tak, jak myślisz

Agenty AI to systemy zdolne do autonomicznego przeszukiwania Internetu i podejmowania kolejnych kroków bez ingerencji użytkownika. Brzmi to jak idealne narzędzie do researchu. I jest w tym sporo prawdy, ale warto rozumieć ograniczenia i zagrożenia.

Wiele wartościowych źródeł blokuje automatyczny dostęp przez robots.txt lub paywalle. Agent często nie poinformuje o tym, a jedynie odnotuje brak dostępu i przejdzie dalej, co łatwo przeoczyć w złożonym procesie. Osobny problem to fałszywe strony i treści generowane przez AI: szacuje się, że już ponad połowa treści w Internecie powstaje już przy udziale modeli językowych (ten artykuł nie, naprawdę!). Agenty nie rozróżniają tekstu „napisanego przez eksperta" od „wygenerowanego na farmie contentu". Bez dodatkowych kryteriów jakości cały pipeline jest tak wiarygodny jak jego najsłabsze ogniwo, czyli źródło.

Stąd zasada dotycząca formatów pośrednich: zamiast prosić agenta o „wyszukaj terminologię dziedziny X", poproś go o dane ustrukturyzowane w formatach JSON, CSV lub tabelę z konkretnymi kolumnami. Formaty pośrednie wymuszają precyzję i znacząco ułatwiają późniejszą możliwość weryfikacji i filtrowania danych bez angażowania LLM-ów.

Jeśli nie chcesz pisać skryptów, Excel lub CSV to rewelacyjny punkt kontrolny: możesz szybko przejrzeć wyniki etapu pośredniego ręcznie, zanim agenty pójdą dalej. Jeśli jednak możesz coś zweryfikować skryptem bez udziału LLM-a, nawet się nie zastanawiaj.

Trzeba tu jednak zaznaczyć: najnowsze generacje modeli (np. rodzina Fable/Mythos czy Opus) radzą sobie z tym już wyraźnie lepiej. Przy wielu iteracjach i użyciu sub-agentów model coraz częściej sam odsiewa źródła wiarygodne od wątpliwych. To nie zwalnia nas jednak z projektowania procesu: wciąż my decydujemy, które kroki wymagają zewnętrznej weryfikacji, niezależnie od tego, jak dobry jest model pod spodem.

Praktyka: budowanie glosariusza krok po kroku

Zerknijmy na przykład. Chcemy zbudować glosariusz narzędzi dentystycznych (EN↔PL), który ma zawierać wyłącznie zweryfikowane terminy z rzetelnych źródeł.

Krok 1: prompt dla modelu wyszukującego

Rozsądnie skonstruowany prompt określa nie tylko co chcemy, ale jak to zweryfikować już na etapie zbierania danych:

Zbuduj glosariusz narzędzi dentystycznych. Dla każdego terminu zapisz: a) termin w języku angielskim, b) link do strony medycznej lub artykułu, gdzie termin jest użyty, c) dokładny cytat ze zdaniem, w którym termin występuje, d) tłumaczenie na polski, e) link i cytat dla wersji polskiej, f) synonimy w osobnych wierszach. Zapisz wynik w CSV i JSON. Minimum 30 terminów. Na końcu oceń wiarygodność każdego źródła i odrzuć terminy, których jedynym źródłem jest Wikipedia.

Dwa elementy są tu kluczowe. Po pierwsze cytat. Nie sam link, ale fragment tekstu, w którym termin faktycznie jest użyty. Po drugie kryterium odrzucenia: Wikipedia to za mało, potrzebujemy recenzowanych artykułów, baz medycznych, oficjalnych słowników. Chcemy w ten sposób wyeliminować część śmieci zanim w ogóle zobaczymy wyniki.

Krok 2: weryfikacja skryptem

Nawet najlepszy prompt nie gwarantuje, że linki istnieją i że cytowany fragment rzeczywiście istnieje pod docelowym adresem. Tu właśnie ma sens skrypt: dziś wygenerujemy go w niemal dowolnym modelu lub z poziomu środowiska programistycznego z wbudowaną asystą AI (Cursor, Codex, Claude Code/Cowork):

Napisz skrypt, który: 1) sprawdza, czy adresy URL z pliku JSON istnieją (odpowiedź 200 OK), 2) szuka cytatu z pliku na danej stronie, 3) usuwa terminy z niską oceną wiarygodności. Dla każdego terminu wynik to pass/fail.

Skrypt uruchamiamy na wyjściu z kroku 1. Terminy z wynikiem „fail" są usuwane z proponowanej listy. Eliminujemy w ten sposób ryzyko oceny wiarygodności przez model. Zamiast tego mamy deterministyczny kod (zawsze ten sam wynik dla tych samych danych wejściowych), który albo znajdzie cytat na stronie, albo nie. I tu jest pies pogrzebany.

Krok 3: czyszczenie i uzupełnianie

Po odfiltrowaniu zostają terminy z potwierdzonymi źródłami. Dopiero teraz warto je ewentualnie uzupełnić ręcznie, wzbogacić o metadane (dziedzina, specjalizacja) i przekonwertować do formatu docelowego, np. XLIFF, TMX lub TBX, jeśli dane trafiają do środowiska CAT. Tylko tutaj nie wolno popełnić błędu przerzucania danych przez LLM-a do konwersji, ponieważ znowu wprowadzilibyśmy ryzyko halucynacji i wszystkie dotychczasowe wysiłki spełzną na niczym. Bezpieczniejszy wariant: poproś model o wygenerowanie skryptu konwertującego, a dopiero skrypt uruchom na danych. Skrypt nie zmieni treści terminów; model działający bezpośrednio na danych może.

Podsumowanie

Zasada jest prosta: im mniej modelu językowego w procesie weryfikacji, tym bardziej przewidywalny wynik. LLM-y są rewelacyjne do generowania wstępnych danych i do zadań, gdzie błąd jest akceptowalny. Jak jednak widać z wcześniejszych przykładów, nie są dobrym narzędziem do sprawdzania własnych odpowiedzi.

Dobry proces zbudowany wokół researchu tłumaczeniowego wygląda tak: sprecyzowany cel → ustrukturyzowane zbieranie danych przez agenta → weryfikacja zewnętrzna (skrypt, nie LLM) → czyszczenie i metadane → wdrożenie. Na każdym etapie znane są dane wejściowe i wyjściowe. I to jest moment, gdy AI przestaje być loterią, a zaczyna być narzędziem produkcyjnym.