PROJEKT
Automatyzacje dokumentów technicznych
ZAIMPLEMENTOWANE / ROZWIJANE MODUŁY
Zamówienia, skany i atesty wymagają odczytania, przypisania i obsługi wyjątków. Trzy workflowy łączą reguły, lokalny OCR i model językowy, a niepewne przypadki kierują do człowieka. Moduły są zaimplementowane i rozwijane, ale nie mają jeszcze wspólnego panelu ani pomiaru skuteczności.
- Autor
- Kamil Kogut
- Aktualizacja
Problem
Zamówienia, skany i atesty trafiają do różnych skrzynek. Trzeba je odczytać, nazwać, przypisać do właściwego procesu i nie zgubić wyjątków.
Co powstało
Trzy niezależne workflowy — deterministyczne sortowanie zamówień, lokalny OCR z klasyfikacją Bielikiem oraz rejestr wsadów materiałowych z progiem pewności.
Elementy systemu
- Deterministyczne sortowanie zamówień w Pythonie, bez modelu AI
- Lokalny OCR w Swift (Apple Vision) i klasyfikacja przez Bielika w Ollama
- Rejestr wsadów materiałowych z progiem pewności 0.7
- Skrzynki wyjątków i miejsce weryfikacji przez człowieka
- Reakcja na nowe pliki w katalogu wejściowym
Sposób kontroli
Nierozpoznane pliki i wyniki poniżej ustalonego progu nie przechodzą dalej automatycznie. Trafiają do skrzynki, w której decyzję podejmuje człowiek.
Ograniczenia
- Nie ma jeszcze wspólnego panelu, testów całego zestawu ani zatwierdzonego pomiaru skuteczności.
- Jakość OCR zależy od jakości dokumentu źródłowego.
- Po lokalnej analizie część plików trafia do folderów synchronizowanych z chmurą.
Następny krok
Ujednolicenie logów i wyjątków oraz przygotowanie bezpiecznego demonstratora na fikcyjnych dokumentach.
Wspólna zasada architektury
PLIK WEJŚCIOWY
→ ODCZYT LUB OCR
→ REGUŁA ALBO MODEL
→ PRÓG / PRZYPADEK NIEROZPOZNANY
→ KONTROLA CZŁOWIEKA
→ ZAPIS I REJESTRTo rodzina trzech niezależnych workflowów, a nie jedna aplikacja. Łączy je metoda pracy, nie wspólny runtime. AI pojawia się tylko w modułach, w których reguła nie wystarcza — sortowanie zamówień pozostaje procesem deterministycznym.
Podział ról
- Człowiek: definiuje reguły, sprawdza wyjątki i odpowiada za dokument.
- Model: klasyfikuje albo wydobywa dane tylko w dwóch modułach.
- Skrypt: obserwuje katalog, uruchamia kolejne kroki, zapisuje wynik i log.
- Agent: nie jest potrzebny do bieżącego wykonania tych workflowów.
Przykład: atest, który wymaga sprawdzenia
Poniższy przykład jest ilustracją zasady działania na fikcyjnych danych. Nie przedstawia wyniku uruchomienia modułu ani pomiaru jego skuteczności.
Dokument wejściowy. Do skrzynki trafia demonstracyjny skan atestu „ATEST-DEMO-001”. Numer partii jest częściowo nieczytelny.
Odczyt. OCR odczytuje tekst, a model wydobywa dane potrzebne do rejestru. Samo rozpoznanie nazwy dokumentu nie oznacza, że wszystkie pola są poprawne.
Wyjątek. Załóżmy, że wynik otrzymuje pewność 0,6. To mniej niż próg 0,7 stosowany w module wsadów, więc plik pozostaje w skrzynce do sprawdzenia.
Kontrola człowieka. Osoba odpowiedzialna porównuje odczyt ze skanem. Jeżeli numeru partii nie da się potwierdzić, potrzebny jest czytelniejszy dokument. Brakującej wartości nie należy uzupełniać z domysłu.
Wynik tego scenariusza. Dokument czeka na wyjaśnienie. Przepływ zachowuje miejsce na kontrolę zamiast przepuszczać niepewne dane do dalszej pracy.
Jeśli podobny problem występuje u Ciebie, opisz proces i rodzaje dokumentów. Na tej podstawie można ustalić, czy wystarczy reguła, potrzebny jest OCR, czy najpierw należy uporządkować sam obieg informacji.