Funkcjonalności
Użytkownicy i konta
Aplikacja umożliwia rejestrację i logowanie, zarządzanie profilem oraz pracę w modelu opartym na kredytach i limitach przestrzeni dyskowej. Każda operacja przetwarzania zużywa konfigurowalną liczbę kredytów, a system sprawdza ich dostępność przed rozpoczęciem pracy. Zużycie przestrzeni dyskowej jest śledzone i ograniczane osobno dla każdego użytkownika, w obrębie wszystkich typów zasobów.
Przetwarzanie obrazów
Przetwarzanie obrazów obsługuje przesyłanie w popularnych formatach (JPG, PNG, WEBP), zarówno pojedynczo, jak i wsadowo. Użytkownicy mogą uruchomić OCR w trzech trybach jakości: Niski (szybki, oparty na PaddleOCR), Średni (zbalansowany, z rozpoznawaniem struktury dokumentu przez PaddleOCRVL) oraz Wysoki (najwyższa jakość, DeepSeek-OCR). W trybach średnim i wysokim system może zwracać ustrukturyzowane wyniki (tabele, nagłówki, akapity). Ekstrakcję można ograniczyć do regionu wskazanego przez użytkownika.
Przetwarzanie wideo
Obsługa wideo obejmuje przesyłanie, ekstrakcję metadanych (czas trwania, rozdzielczość, liczba klatek na sekundę) oraz automatyczne generowanie miniatury podglądu. Napisy wbudowane w obraz są wykrywane i wyodrębniane przez analizę wyłącznie tych klatek, w których zmienia się ich treść; system generuje pliki SRT i obsługuje ponowne przetwarzanie. Pliki z napisami mogą być również przesyłane i zarządzane niezależnie, edytowane z wersjonowaniem oraz pobierane w wersji oryginalnej lub przetłumaczonej.
AI i tłumaczenie
Funkcje AI obejmują tłumaczenie wyodrębnionego tekstu i napisów na wybrany język — z opcjonalnym kontekstem poprawiającym jakość — oraz integrację z API dużych modeli językowych (np. Gemini). System potrafi korygować typowe błędy OCR przy zachowaniu struktury tekstu, a także generować objaśnienia rozpoznanych treści. Zadania tłumaczeniowe obsługują pełną kontrolę cyklu życia (Zatrzymaj, Wznów, Ponów), zachowują już przetłumaczone segmenty i ponawiają jedynie te, które się nie powiodły.
Wyniki i historia
Użytkownicy mogą pobierać przetworzone wyniki (tekst i pliki SRT), a system stosuje zasady retencji do automatycznego usuwania plików po upływie skonfigurowanego czasu. Historia aktywności jest rejestrowana i wyświetlana dla wideo, obrazów i napisów, z możliwością filtrowania i sortowania według typu zasobu i daty. Panel administracyjny daje uprzywilejowanym użytkownikom dostęp do zarządzania kontami i statystyk systemu.
Stos technologiczny
Warstwa orkiestracji
Warstwa orkiestracji jest zaimplementowana w Laravelu (PHP). Laravel obsługuje uwierzytelnianie, autoryzację, walidację, routing i abstrakcję przechowywania danych, a zarazem czytelnie rozdziela obsługę żądań, logikę biznesową w serwisach i zlecanie zadań w tle. MySQL pełni rolę głównego trwałego magazynu danych dla użytkowników, metadanych plików, wyników zadań i rozliczeń kredytów; relacyjny model danych dobrze pasuje do relacji użytkownik–plik oraz do wymogu integralności transakcyjnej przy operacjach na kredytach i limitach.
Broker komunikatów i koordynacja
Redis pełni rolę wielofunkcyjnego komponentu działającego w pamięci operacyjnej: brokera komunikatów dla kolejek zadań, szybkiego magazynu tymczasowych kluczy statusu, mechanizmu śledzenia postępu w czasie rzeczywistym przez publish/subscribe oraz narzędzia do rozproszonej koordynacji dostępu do współdzielonych zasobów GPU. Workery pobierają zadania z kolejek Redisa i publikują aktualizacje statusu z powrotem przez Redisa oraz za pomocą wywołań zwrotnych HTTP do backendu.
Warstwa przetwarzania
Warstwa przetwarzania jest zaimplementowana w Pythonie, który skupia w sobie większość narzędzi OCR, widzenia komputerowego i wnioskowania modelowego. Workery Pythona działają jako bezstanowe procesy pobierające zadania z Redisa, uruchamiające potoki OCR i wideo, a wyniki przekazują przez API backendu. Wymiana plików odbywa się przez kontrolowane punkty końcowe pobierania i przesyłania, a nie przez współdzielony dysk — workery mogą więc działać na odrębnych maszynach.
Frontend
Frontend zbudowano z użyciem React, Inertia.js i Tailwind CSS. Inertia utrzymuje routing i kontrolery po stronie serwera w Laravelu, jednocześnie renderując komponenty React, co zapewnia responsywny interfejs bez potrzeby pełnoprawnego wdrożenia SPA i eliminuje duplikację logiki routingu oraz autoryzacji.
Decyzje techniczne
Architektura asynchroniczna
System wykorzystuje dwuetapowy asynchroniczny przepływ pracy: warstwa webowa przyjmuje żądania, utrwala metadane i umieszcza zadania przetwarzania w kolejce; dedykowane procesy workerów wykonują te zadania i raportują wyniki. Ten podział, inspirowany architekturą mikroserwisów, utrzymuje długotrwałe operacje OCR i wideo poza ścieżką HTTP i umożliwia poziome skalowanie workerów bez ingerencji w podstawową logikę biznesową.
Bezpieczeństwo
Bezpieczeństwo jest realizowane wielowarstwowo: uwierzytelnianie sesyjne dla interfejsu webowego, szczegółowe uprawnienia egzekwowane w politykach (każda operacja sprawdza własność zasobu i wymagane prawa dostępu) oraz współdzielony sekret dla komunikacji backend-to-backend, dzięki czemu workery uwierzytelniają się w API Laravela bez ujawniania danych uwierzytelniających użytkowników. Dostęp do plików jest ograniczony przez dysk i ścieżkę, a nazwy plików są reprezentowane przez UUID, co eliminuje ryzyko stosowania niebezpiecznych nazw kontrolowanych przez użytkownika.
Obsługa plików
Obsługa plików jest traktowana jako zagadnienie pierwszoplanowe. Przestrzeń dyskowa jest podzielona na przestrzenie nazw per użytkownik na potrzeby egzekwowania limitów i czyszczenia danych. Pliki są najpierw zapisywane w lokalizacji tymczasowej, a następnie przenoszone atomowo do ścieżki docelowej. Współdzielona pamięć podręczna plików z eksmisją w stylu LRU i zliczaniem referencji zapobiega powielaniu pobrań i uniemożliwia usunięcie plików, które są wciąż w użyciu. Redis służy do koordynacji blokad pobierania, tak aby ten sam plik nie był pobierany równocześnie przez kilka workerów.
Zarządzanie zasobami GPU
Pojemnością GPU zarządza rozproszony ResourceManager oparty na Redisie. Jeden globalny licznik całkowity śledzi zarezerwowaną pamięć GPU w MB; przed rozpoczęciem pracy intensywnie korzystającej z GPU worker atomowo zwiększa ten licznik o koszt swojego trybu (niski, średni, wysoki). Jeśli wynik przekroczyłby skonfigurowany budżet, inkrementacja jest wycofywana, a zadanie trafia ponownie do kolejki z krótkim opóźnieniem. Po zakończeniu lub niepowodzeniu zadania worker dekrementuje licznik i usuwa swój rekord alokacji. Workery mogą działać na różnych hostach, a nieaktualne alokacje pozostałe po awarii workera mogą zostać wyczyszczone. Workery mogą też z góry rezygnować z rejestrowania usług OCR w trybie średnim lub wysokim, gdy dostępny budżet jest zbyt niski.
Planowanie zadań workerów
Workery stosują planowanie w stylu kameleonowym, aby ograniczyć narzut związany z rozgrzewaniem modeli. Każdy worker ma stan (np. zimny, gotowy do OCR, ciężki) i licznik bezwładności; gdy trwa przetwarzanie OCR i kolejka obrazów zawiera oczekujące zadania, worker preferuje kontynuowanie OCR w celu ponownego wykorzystania załadowanych modeli, zamiast przełączać się na inny typ zadań. Zadania są grupowane w taki sposób, aby workery minimalizowały przełączanie kontekstu.
Potoki OCR i wideo
Przetwarzanie OCR i wideo jest podzielone według odpowiedzialności. Zadania obrazowe są wysyłane z trybem przetwarzania i opcjonalnym regionem ekstrakcji; worker rozwiązuje plik wejściowy (przez URL lub ścieżkę lokalną), wybiera odpowiednią usługę OCR i zwraca płaski tekst z poziomem pewności albo ustrukturyzowane bloki. Metadane wideo (w tym miniatura) są obsługiwane przez odrębną kolejkę. Ekstrakcja napisów wykorzystuje zewnętrzne narzędzie do wykrywania klatek kandydujących, uruchamia OCR równolegle na zredukowanym zestawie obrazów i buduje plik SRT ze znacznikami czasu. Potok może nakładać na siebie wykrywanie klatek i strumieniowe OCR, a do unikania odczytu częściowo zapisanych klatek stosuje proste heurystyki (np. sprawdzanie stabilności rozmiaru pliku).
Kredyty i limity
Kredyty są potrącane dopiero w momencie, gdy zasób przechodzi do stanu ukończonego, co wyklucza naliczanie opłat za nieudane zadania. Limit przestrzeni dyskowej jest egzekwowany przez dedykowany serwis, który agreguje zużycie w obrębie obrazów, wideo i napisów, a następnie porównuje je z limitem użytkownika przed zaakceptowaniem nowych przesyłań. Wszystkie krytyczne zmiany stanu i aktualizacje rozliczeniowe są owinięte w transakcje bazodanowe, co gwarantuje spójność danych w warunkach asynchronicznego wykonywania.
Konfiguracja i obserwowalność
Konfiguracja jest sterowana zmiennymi środowiskowymi, dzięki czemu ta sama baza kodu może być dostrajana per wdrożenie bez modyfikacji kodu źródłowego. Logowanie jest ustrukturyzowane z myślą o środowiskach wieloprocesowych, a status zadań jest publikowany w czasie rzeczywistym, co pozwala interfejsowi użytkownika prezentować postęp i ukończenie bez polegania wyłącznie na odpytywaniu. Projekt priorytetyzuje responsywność pod obciążeniem, poziome skalowanie workerów, izolację pracy intensywnie korzystającej z GPU oraz przejrzystą rozliczalność danych i kredytów użytkownika — kosztem wyższej złożoności operacyjnej i spójności ostatecznej, adresowanej przez jawne pola statusu i staranne modelowanie stanu w interfejsie użytkownika.