AI w naszych projektach: konkretne zastosowania i kontrola wyniku

AI jest przydatne wtedy, gdy pomaga wykonać określone zadanie i można sprawdzić jego rezultat. W naszych projektach takim zadaniem może być odczyt dokumentu, uporządkowanie sygnału albo pomoc przy zmianie kodu. Każdy z tych przypadków wymaga innego sposobu kontroli.

KSeFv: od obrazu do danych do sprawdzenia

Paragon lub skan faktury jest dla użytkownika czytelnym dokumentem, lecz aplikacja potrzebuje konkretnych pól: daty, kontrahenta, kwoty i pozycji. Odczyt OCR pomaga przygotować te dane. W projekcie KSeFv są ścieżki analizy dokumentu, podglądu wyniku i pracy z załącznikiem kosztu.

Wartość takiego narzędzia polega na ograniczeniu przepisywania. Nadal potrzebny jest przegląd wyniku: niewyraźny skan, nietypowy układ czy pomylony znak mogą zmienić znaczenie pola. Dlatego odczyt i zatwierdzenie kosztu są odrębnymi krokami.

StockLive24: analiza wymaga źródeł i kontekstu

Projekt StockLive24 łączy dane rynku, ocenę setupów, import sygnałów i historię decyzji. W kodzie są również moduły raportów i analizy tekstu. Użyteczność takiej analizy zależy od aktualności danych, konfiguracji dostawców i sposobu wyjaśnienia wyniku.

Sam wynik punktowy nie mówi, skąd pochodzi informacja ani dlaczego określony scenariusz został oceniony wysoko. Dlatego prezentacja projektu obejmuje diagnostykę źródeł, historię zdarzeń, plan ryzyka i dziennik. Obecność modułu w repozytorium nie jest potwierdzeniem skuteczności strategii ani aktywnej integracji na produkcji.

Wsparcie przy kodzie zaczyna się od kontekstu

Podczas pracy nad ECMI korzystamy z pomocy AI przy przeglądzie repozytoriów, szukaniu powiązań i przygotowaniu zmian. Dobrym przykładem jest katalog naszych projektów: opisy powstały po odczytaniu lokalnej dokumentacji, kontrolerów i widoków. Nazwa projektu sama w sobie nie wystarczała do określenia jego przeznaczenia.

Przegląd wykazał też różnice między planem a implementacją. OddamBilet nie obsługuje płatności za cenę biletu, choć ma kod usług płatnych. Niektóre dokumenty LekcjaGo były starsze od dostępnych kontrolerów. Takie rozbieżności trzeba wyjaśnić przed opisaniem produktu.

Wynik musi mieć sposób sprawdzenia

Przy treści oznacza to porównanie opisu ze źródłami. Przy kodzie — przegląd zmiany i uruchomienie odpowiednich kontroli. Przy danych z dokumentu — sprawdzenie pól przed zatwierdzeniem. Kryterium oceny zależy od zadania, ale powinno być ustalone, zanim wynik zostanie użyty.

• Źródło: wiadomo, na jakich danych lub dokumentach opiera się odpowiedź.
• Zakres: funkcje planowane są oddzielone od zaimplementowanych.
• Kontrola: test albo przegląd odnosi się do rzeczywistego rezultatu.
• Obsługa błędu: użytkownik może poprawić dane lub ponowić operację bez pozornego sukcesu.
• Decyzja: wiadomo, kto zatwierdza wynik przed dalszym działaniem.

Nie każda automatyzacja jest AI

Przypomnienie o terminie, reguła cyklicznej faktury i filtr wyszukiwarki mogą działać bez modelu AI. Opisując produkt, warto nazywać te mechanizmy zgodnie z tym, co robią. Prosta, sprawdzalna reguła często wystarcza do rozwiązania problemu.

Nie przypisujemy też projektom efektów, których nie potwierdziliśmy: gwarantowanych oszczędności czasu, bezbłędnego OCR czy przewidywalnych wyników finansowych. Użytkownik powinien widzieć możliwość narzędzia i rozumieć, gdzie pozostaje etap sprawdzenia.

Od konkretnego problemu do konkretnego narzędzia

Rozwijamy osobne produkty, więc zakres wykorzystania AI różni się między nimi. Nie wszystkie potrzebują tej samej warstwy analizy. KSeFv porządkuje dokumenty, StockLive24 proces analityczny, a pełne portfolio pokazuje także projekty o innych potrzebach.

---

Wszystkie aktualności →