Pipeline w Drupalu: jak zamienić pliki PDF w treści strukturalne

Ręczne przepisywanie informacji z plików PDF na stronę zajmuje redaktorom czas, który mogliby przeznaczyć na sprawdzenie tych informacji. Żeby ekstrakcja danych z PDF do Drupala działała niezawodnie, samo narzędzie odczytujące dokumenty nie wystarczy. Potrzebny jest proces przetwarzania dokumentów (pipeline), który zapisze każdą wartość we właściwym polu, wychwyci problemy i zapewni osobie weryfikującej kontekst potrzebny do zatwierdzenia wyniku.

Najważniejszym etapem jest mapowanie. Bez niego ekstrakcja daje jedynie blok tekstu przeniesiony w inne miejsce. Dzięki mapowaniu wymiary, materiał i numery certyfikatów produktu stają się danymi, które można wielokrotnie wykorzystywać na stronach, w filtrach, w API i w formatach odczytywanych maszynowo.

Poniżej opisujemy, jak zaprojektować taki proces, w tym etap weryfikacji i postępowanie z dokumentami, których nie da się wiarygodnie przetworzyć automatycznie.

W tym artykule:

• Jak wygląda proces przenoszenia danych z PDF do Drupala?
• Którą metodę ekstrakcji wybrać dla danego dokumentu?
• Jak przypisać wyodrębnione wartości do pól w Drupalu?
• Co walidacja powinna wychwycić, zanim szkic trafi do weryfikacji?
• Jak zorganizować weryfikację przez człowieka bez narastających zaległości?
• Jak oszacować przepustowość i koszt przetworzenia dokumentu?
• Co zrobić, gdy dokumentu nie da się wiarygodnie przetworzyć?
• Od czego zacząć przenoszenie danych z PDF do Drupala?

Jak wygląda proces przenoszenia danych z PDF do Drupala?

Celem biznesowym jest zamiana informacji z dokumentów w treści, które można edytować, bez ręcznego przepisywania każdej wartości. Ekstrakcja jest tylko jednym z etapów tego procesu.

Załóżmy, że dostawcy przesyłają karty specyfikacji produktów w formacie PDF. Strona na Drupalu potrzebuje dla każdego produktu numeru modelu, wymiarów, masy, materiału i numerów certyfikatów. Niektóre pliki opisują jeden produkt, inne zawierają tabelę z kilkoma wariantami.

Proces, który przygotowuje dane do weryfikacji, powinien prowadzić każdy dokument przez następujące etapy:

1. Przyjęcie i rejestracja pliku PDF. Dokument otrzymuje identyfikator, a system zapisuje jego źródło i wersję oraz przechowuje link do oryginału z kontrolą dostępu.
2. Rozpoznanie rodzaju dokumentu. System ustala, czy plik jest znanym typem karty specyfikacji, zeskanowaną tabelą, czy dokumentem w nieznanym formacie.
3. Ekstrakcja proponowanych wartości. System odczytuje tekst, obrazy stron albo strukturę tabeli metodą odpowiednią dla danego dokumentu.
4. Mapowanie wartości na pola Drupala. Każda informacja zostaje przypisana do właściwego produktu, pola i jednostki oraz do miejsca w dokumencie, z którego pochodzi.
5. Walidacja proponowanego rekordu. System sprawdza ograniczenia pól, powiązania oraz potwierdzenie każdej wartości w dokumencie źródłowym.
6. Przekazanie szkicu do weryfikacji. Osoba weryfikująca widzi proponowane wartości obok odpowiednich fragmentów dokumentu.
7. Publikacja po zatwierdzeniu. Zatwierdzona rewizja staje się dostępna w skonfigurowanych kanałach wyjściowych strony.

Przesyłanie pliku powinno trwać krótko. Ekstrakcję może wykonać proces działający w tle (worker) po zakończeniu żądania przesłania pliku. Podstawą przetwarzania w kolejce może być Queue API w Drupalu. Proces w tle musi bezpiecznie obsługiwać ponowne uruchomienie, ponieważ to samo zadanie może zostać wykonane więcej niż raz.

Skrót pliku (hash) pozwala na przykład rozpoznać identyczny plik przesłany ponownie. Identyfikator i wersja dokumentu źródłowego pozwalają odróżnić nową wersję dokumentu od przypadkowego duplikatu. Przed zapisem treści proces w tle powinien sprawdzić, czy dla danego importu i produktu istnieje już proponowany rekord.

Status przetwarzania należy oddzielić od statusu publikacji. „Ekstrakcja zakończona” oznacza, że proces w tle wykonał swoje zadanie. Nie oznacza to jednak, że informacje są gotowe do pokazania czytelnikom. Statusy przetwarzania, takie jak „oczekuje”, „wyodrębniono”, „błąd” i „czeka na poprawkę”, warto śledzić niezależnie od statusów redakcyjnych w Drupalu.

Którą metodę ekstrakcji wybrać dla danego dokumentu?

Dobór metody do rodzaju dokumentu może obniżyć koszty przetwarzania i ograniczyć zbędną weryfikację. Karta specyfikacji wygenerowana cyfrowo może wymagać jedynie zwykłej ekstrakcji tekstu. Sfotografowana tabela wymaga innego podejścia.

Metody można łączyć. OCR może zwrócić tekst wraz ze współrzędnymi, które następnie interpretuje narzędzie analizujące układ strony. LLM może przypisać niespójne etykiety stosowane przez dostawców do stałego schematu ekstrakcji. Porównanie narzędzi do ekstrakcji tekstu z dokumentów opisujemy w artykule Z PDF do tekstu dla AI. Jak wybrać odpowiednie narzędzie do ekstrakcji danych?.

Prace warto zacząć od analizy dokumentu źródłowego. Możliwość zaznaczenia tekstu w pliku nie gwarantuje, że tekst jest poprawny: zeskanowany PDF może zawierać starą warstwę OCR z błędami rozpoznawania. Zanim wyodrębniony tekst zostanie uznany za wiarygodny, trzeba sprawdzić, czy jest zgodny z tym, co widać na stronie dokumentu.

Szczególnej uwagi wymagają tabele. Tabela zapisana jako obraz wymaga OCR albo interpretacji wizualnej, zanim jej wartości staną się ustrukturyzowanymi danymi. Nawet wtedy poprawne odczytanie wartości „240” to dopiero połowa zadania. Proces przetwarzania musi też ustalić, w którym wierszu produktu i w której kolumnie wymiaru znajduje się ta wartość.

Przy ekstrakcji wspieranej przez LLM warto poprosić model, aby pozostawiał brakujące wartości puste, i wymagać dla każdej proponowanej informacji fragmentu źródłowego albo numeru strony. To potwierdzenie również należy zweryfikować. Cytat wygenerowany przez model nadal jest tylko propozycją, a nie dowodem.

Tekst dokumentu również należy traktować jako dane wejściowe. Polecenia umieszczone w pliku PDF nie mogą sterować narzędziami procesu w tle, jego danymi uwierzytelniającymi ani działaniami związanymi z publikacją.

Przed wysłaniem plików do zewnętrznej usługi trzeba sprawdzić warunki przechowywania danych, miejsca ich przetwarzania, kontrolę dostępu oraz to, czy dostawca wykorzystuje przesłane dane do trenowania modeli. Poufne pliki źródłowe wymagają też zabezpieczonego przechowywania we własnym systemie.

Jak przypisać wyodrębnione wartości do pól w Drupalu?

Na tym etapie model treści pokazuje swoją wartość. Definicje pól opisane w artykule Modelowanie treści w Drupalu pod odpowiedzi kupujących: pola zamiast prozy stają się docelowym schematem importu. Określają, co oznacza każda wartość, jak Drupal ją przechowuje i jakie wartości strona akceptuje.

„Masa: 2,4 kg” to czytelny tekst. Pole liczbowe dziesiętne z wyraźnie określoną jednostką to dane, które można wielokrotnie wykorzystywać.

Dla przykładowej karty specyfikacji mapowanie mogłoby wyglądać tak. Wartości i numery stron w tabeli są przykładowe.

Numer certyfikatu w pliku PDF potwierdza jedynie to, co deklaruje źródło. Nie dowodzi to jednak, że certyfikat jest autentyczny, aktualny i dotyczy tego produktu. Jeśli te kwestie mają znaczenie dla publikacji, należy przewidzieć dla nich osobny etap walidacji albo weryfikacji.

Równie przemyślanych reguł wymagają daty i liczby. Niejednoznaczna data, taka jak 03/04/2026, wymaga znanej konwencji źródła albo decyzji osoby weryfikującej. Separatory dziesiętne i przeliczanie jednostek również zależą od konwencji przyjętych w dokumencie. Warto przechowywać zarówno wartość oryginalną, jak i znormalizowaną propozycję, aby redaktor mógł prześledzić zmianę.

Kilka decyzji dotyczących mapowania wymaga wyraźnie zdefiniowanych reguł:

• Powtarzające się wiersze: każdy wiersz, który opisuje odrębną wartość albo relację, powinien trafić do osobnego rekordu.
• Wiele produktów w jednym pliku: każdą wyodrębnioną informację należy przypisać do identyfikatora produktu, zanim powstaną szkice produktów.
• Nieznane terminy: niedopasowane etykiety taksonomii powinny trafiać do weryfikacji, zamiast automatycznie rozszerzać słownik.
• Brakujące wartości: stan „nie podano” należy przechowywać osobno od zera, wartości fałszywej i stanu „nie dotyczy”.
• Sprzeczne wartości: system powinien zachować obie propozycje wraz z miejscem ich wystąpienia w dokumencie, zamiast wybierać jedną z nich bez wiedzy redakcji.

Potwierdzenie w dokumencie warto przechowywać przy każdym proponowanym polu albo w powiązanym rekordzie importu. Dostęp do tych rekordów powinien być ograniczony, ponieważ wewnętrzne fragmenty dokumentów i notatki z weryfikacji nie powinny automatycznie trafiać do publicznych API.

Skonfigurowany importer albo niestandardowy proces w tle może tworzyć szkice encji przez API encji w Drupalu i przed zapisem wyraźnie wywołać walidację. Zapis przez API nie zastępuje wywołania walidacji. Jeśli proponowany rekord nie spełnia ograniczeń docelowej encji, należy zachować go w rekordzie roboczym poza docelową encją do czasu poprawy.

Podobne podejście pokazuje projekt kategoryzacji dokumentów z AI dla BetterRegulation. System mapuje informacje z dokumentów na istniejące odwołania do taksonomii w Drupalu, a redaktorzy mogą poprawić uzupełnione pola przed zapisem. Ten przykład ilustruje ustrukturyzowane mapowanie i kontrolę redakcyjną, a nie cały opisany tutaj proces przetwarzania plików PDF.

Co walidacja powinna wychwycić, zanim szkic trafi do weryfikacji?

Walidacja powinna zdjąć z osoby weryfikującej tę część sprawdzania, którą można zautomatyzować. Redaktor nie powinien samodzielnie wyszukiwać każdego brakującego identyfikatora czy nieobsługiwanej jednostki.

Na początek warto rozdzielić dwa pytania:

• Czy wartość jest poprawna pod względem struktury? Ma oczekiwany typ, format i dozwoloną wartość.
• Czy wartość poprawnie odzwierciedla źródło? Należy do właściwego produktu, etykiety i wersji dokumentu.

Poprawny składniowo JSON sam w sobie nie odpowiada na żadne z tych pytań. Dodatnia liczba dziesiętna nadal może być wysokością produktu z kolejnego wiersza tabeli.

W procesie przetwarzania kart specyfikacji automatyczne kontrole mogą obejmować wymagane identyfikatory, formaty liczb, dozwolone jednostki, dopasowanie terminów taksonomii i odwołań oraz formaty dat. Tam, gdzie pozwala na to rodzaj dokumentu, warto dodać kontrole zależności między polami. Grupa wymiarów wymaga na przykład jasno określonej kolejności wymiarów i jednostki, zanim proces przetwarzania będzie mógł bezpiecznie uzupełnić szerokość, wysokość i głębokość.

Kontrole potwierdzenia w dokumencie mogą sprawdzić, czy wskazana strona istnieje i czy fragment zawiera zgłoszoną wartość. Trudniejsze zależności, na przykład to, czy przypis pod tabelą zmienia znaczenie wartości, mogą nadal wymagać oceny człowieka.

Różne błędy powinny mieć różne skutki. Brak identyfikatora produktu może blokować utworzenie szkicu produktu. Nieznana etykieta materiału w polu opcjonalnym może pozwolić na zapis w rekordzie roboczym poza docelową encją, ale wymagać decyzji redaktora. W obu przypadkach rekord powinien pozostać poza publikacją, dopóki wykryte problemy nie zostaną usunięte.

Pomiar nakładu pracy przy poprawkach

Nie istnieje uniwersalny wskaźnik poprawek, na którym można oprzeć budżet. Warto przygotować pilotażowy zestaw dokumentów, który odzwierciedla pliki rzeczywiście otrzymywane od dostawców, w tym trudne skany, gęste tabele, karty z wieloma produktami i nieznane układy.

Wyniki należy porównać z wartościami sprawdzonymi przez człowieka. Warto mierzyć:

• Odsetek dokumentów wymagających poprawek: udział zweryfikowanych dokumentów, w których trzeba było poprawić co najmniej jedną wartość.
• Odsetek błędnych pól: udział sprawdzonych pól z wartością niepoprawną, brakującą albo przypisaną do niewłaściwego produktu.
• Czas poprawek: czas aktywnej pracy osób weryfikujących nad poprawianiem propozycji, w podziale na rodzaje dokumentów.
• Odsetek wyjątków: udział dokumentów, których nie da się obsłużyć w standardowym procesie weryfikacji.

Błędy identyfikatorów warto liczyć osobno od drobnych zmian formatowania, ponieważ mają inne konsekwencje.

Dokument z jednym błędnym identyfikatorem produktu może być groźniejszy niż dokument z kilkoma nieszkodliwymi różnicami w spacjach. Warto rejestrować zarówno błędy wychwycone przed weryfikacją, jak i te znalezione przez osoby weryfikujące. Dzięki temu pomiary pokażą, który etap procesu wymaga poprawy.

Wyniki pilotażu pozwalają zaplanować obsadę i koszty. Należy je ponownie sprawdzić, gdy pojawią się nowi dostawcy albo nowe układy dokumentów.

Jak zorganizować weryfikację przez człowieka bez narastających zaległości?

Dobrze zaprojektowany ekran weryfikacji sprawia, że redaktor nie musi przeszukiwać całego pliku PDF przy każdym polu. Proponowane wartości powinny być widoczne obok fragmentów źródłowych albo linków do stron dokumentu, nieudane kontrole powinny być wyróżnione, a oryginalny plik powinien być łatwo dostępny.

Osoba weryfikująca potrzebuje czterech jasno określonych działań: zatwierdzenia propozycji, jej poprawienia, zlecenia ponownej ekstrakcji albo przekazania dokumentu do ręcznej obsługi.

Skonfigurowane rewizje oraz moduły Workflows i Content Moderation w Drupalu pozwalają obsłużyć stany szkicu, weryfikacji i publikacji. Porównanie z dokumentem źródłowym obok formularza, wyświetlanie statusu importu i potwierdzenia na poziomie pól mogą wymagać prac developerskich.

W opisywanym procesie przetwarzania kart specyfikacji każda propozycja przechodzi weryfikację przez człowieka przed publikacją. Takie podejście rekomendujemy w tym przypadku, zwłaszcza gdy błędne wymiary albo numery certyfikatów mogłyby wprowadzić kupujących w błąd.

Zatwierdzenie powinno dotyczyć dokładnie tej rewizji, którą sprawdziła osoba weryfikująca. Jeśli kolejna próba ekstrakcji zmieni wartość, zaktualizowana rewizja wymaga ponownej weryfikacji. Uprawnienia do przejść między stanami i działanie procesu w tle należy skonfigurować tak, aby zadanie ekstrakcji nie mogło nadpisać zatwierdzonej treści ani samodzielnie opublikować nowej wersji.

Opcjonalne wzbogacanie treści przez AI to inny proces pracy. W projekcie streszczeń dokumentów z AI dla Better Regulation system w tle generuje streszczenia i wyodrębnia obowiązki, zapisuje wyniki w przeznaczonych do tego polach Drupala, a do oceny wyników wykorzystuje weryfikację próbek i informacje zwrotne. W tym podejściu redaktorzy nie zatwierdzają ręcznie każdego wygenerowanego streszczenia. Różni się ono też od opisanego wcześniej procesu kategoryzacji.

Osoba odpowiedzialna za kolejkę

Szybkie narzędzie do ekstrakcji może wydłużyć kolejkę dokumentów czekających na redakcję. Warto monitorować liczbę przychodzących dokumentów, liczbę ukończonych weryfikacji, czas aktywnej weryfikacji i czas oczekiwania pozycji w kolejce. Kolejka potrzebuje osoby odpowiedzialnej. Dzięki temu trudne dokumenty nie czekają bez końca, podczas gdy prostsze są obsługiwane na bieżąco.

Warto też zarezerwować czas na wyjątki. Znana karta z jednym produktem i blady skan z kilkoma wariantami wymagają innego nakładu pracy, nawet jeśli oba liczą się jako jeden plik PDF.

Po zatwierdzeniu ustrukturyzowane pola mogą zasilać skonfigurowane strony HTML, dane JSON-LD, odpowiedzi JSON:API i inne eksporty. Drupal pozwala kontrolować te kanały wyjściowe, ale każdy z nich wymaga przemyślanej konfiguracji. Sama struktura pól nie decyduje o tym, co jest publiczne, aktualne albo widoczne dla asystentów AI.

Jak oszacować przepustowość i koszt przetworzenia dokumentu?

Mierzyć należy cały proces, a nie tylko szybkość ekstrakcji.

Czas od przesłania pliku do zatwierdzenia pokazuje, jak długo firma czeka na dane. Czas aktywnego przetwarzania i weryfikacji pokazuje, na co wykorzystywane są zasoby. Dokument może wymagać niewiele czasu obliczeniowego, a mimo to czekać kilka dni na redaktora.

Liczbę dokumentów publikowanych dziennie warto śledzić razem z czasem oczekiwania w kolejce. Gdy jeden plik PDF może zawierać kilka produktów, liczbę zatwierdzonych rekordów produktów należy raportować osobno.

Do bieżących kosztów operacyjnych należy wliczyć:

• opłaty za OCR i przetwarzanie dokumentów,
• koszty korzystania z modeli,
• infrastrukturę procesów w tle i przechowywanie plików,
• ponowienia i nieudane próby,
• czas osób weryfikujących,
• ręczną obsługę dokumentów, których nie udało się przetworzyć automatycznie.

Na podstawie zmierzonej partii dokumentów można obliczyć:

Koszt zatwierdzonego dokumentu = całkowity koszt operacyjny partii ÷ liczba zatwierdzonych dokumentów z tej partii

Do licznika należy wliczyć pieniądze i czas pracy wydane na nieudane próby. W przeciwnym razie dokumenty, które zużyły zasoby, ale nie zostały zatwierdzone, znikają z obliczeń. Dla partii, której przetwarzanie jeszcze trwa, wynik należy oznaczyć jako wstępny. Jeśli żaden dokument nie został jeszcze zatwierdzony, lepiej podać łączny koszt i liczbę nieudanych prób niż koszt w przeliczeniu na zatwierdzony dokument.

Koszty przygotowania i utrzymania warto oddzielić od bieżących kosztów przetwarzania. Przygotowanie mapowań, konfiguracja moderacji treści i dostosowanie procesu do zmienionego układu dokumentów dostawcy wpływają na uzasadnienie biznesowe inwestycji. Połączenie ich z kosztami operacyjnymi w jedną wartość utrudnia jednak porównania.

W podobny sposób można oszacować, ile dokumentów zespół jest w stanie zweryfikować:

Dzienna liczba weryfikacji = dostępny czas na weryfikację w minutach ÷ średni czas weryfikacji jednego dokumentu w minutach

Tę wartość należy obliczać osobno dla rodzajów dokumentów, które wymagają różnej liczby poprawek. Trzeba uwzględnić czas potrzebny na pozycje przekazane innym osobom i na ponowne weryfikacje, a także zostawić zapas na trudne przypadki.

Przepustowość całego procesu ogranicza najwolniejszy etap. Zwiększenie liczby procesów w tle nie skróci kolejki, która czeka na decyzje ludzi.

Na koniec warto porównać nowy proces z obecnym procesem ręcznym na tym samym zestawie dokumentów i przy tych samych kryteriach akceptacji. Oba warianty należy zmierzyć, zanim firma obieca oszczędności. Może się okazać, że automatyzacja powtarzalnego formatu specyfikacji ma sens, a rzadkie, nieregularne dokumenty taniej jest wprowadzać ręcznie.

Co zrobić, gdy dokumentu nie da się wiarygodnie przetworzyć?

Niektóre pliki PDF wymagają innego sposobu obsługi. Blada tabela, sprzeczne etykiety produktów albo brakujące strony mogą uniemożliwić wiarygodną ekstrakcję niezależnie od narzędzia.

Dla takich dokumentów warto utworzyć kolejkę wyjątków. Każda pozycja powinna mieć jasno podany powód, plik źródłowy, historię prób i wskazaną osobę odpowiedzialną. Nierozstrzygnięte rekordy powinny pozostać poza procesem publikacji.

Kolejne działanie zależy od problemu z dokumentem źródłowym:

Trzeba ustalić limity ponowień i warunki zatrzymania. Chwilowa awaria usługi może uzasadniać kolejną próbę tą samą metodą. Nieczytelna tabela zwykle wymaga zmiany pliku wejściowego albo metody. Powtarzanie tego samego żądania zużywa budżet i nie przynosi nowych informacji.

Niepewność należy zachować na każdym etapie. Pola bez potwierdzenia w dokumencie powinny pozostać puste albo oznaczone, zamiast być uzupełniane przez model wiarygodnie brzmiącymi wartościami. Jeśli kluczowe pole pozostaje nierozstrzygnięte, rekord nie powinien zostać opublikowany.

Najlepiej zacząć od małej skali. Wystarczy wybrać jeden powtarzalny rodzaj dokumentu, określić jego pola docelowe i kryteria akceptacji, a następnie zmierzyć liczbę poprawek, czas weryfikacji i koszt. Taki pilotaż daje rzetelną podstawę do decyzji, w których obszarach warto rozszerzyć automatyzację.

Od czego zacząć przenoszenie danych z PDF do Drupala?

Na pierwszą rozmowę wystarczą reprezentatywne pliki PDF, obecny model pól w Drupalu i przewidywana liczba dokumentów.

Porozmawiajmy o pilotażu, który pozwoli przetestować metody ekstrakcji, oszacować nakład pracy przy weryfikacji i ustalić sposób publikacji, w którym redaktorzy zachowują kontrolę nad treścią. Więcej o naszej pracy można przeczytać na stronie poświęconej usługom AI dla Drupala.