Narrow AI: czym jest wąska AI i kiedy ją stosować

Chcesz automatycznie kierować zgłoszenia do właściwego zespołu. Czy potrzebujesz rozbudowanego asystenta, który rozmawia o wszystkim? Wąska AI ma sens wtedy, gdy zadanie jest jasno ograniczone i można sprawdzić wynik. Najważniejsza jest trafność działania w tym zakresie, a nie liczba tematów, o których system potrafi wygenerować tekst.

Narrow AI, czyli wąska AI, opisuje systemy przeznaczone do określonego zadania lub zestawu zadań. Takie znaczenie podaje IBM. Pojęcie nie oznacza automatycznie małego modelu ani taniego wdrożenia.

Zakres zadania jest ważniejszy od rozmiaru modelu

Wąski system może wykorzystywać reguły, model klasyfikacyjny lub model językowy. O tym, czy zadanie jest ograniczone, decyduje projekt zastosowania.

Rozpoznawanie kategorii zgłoszenia, wykrywanie określonej wady na zdjęciu i prognozowanie zapotrzebowania to różne zadania. Każde potrzebuje własnych danych, miar i kontroli. Sukces w jednym nie dowodzi przydatności w pozostałych.

Nie utożsamiaj również wąskiego zakresu z brakiem ryzyka. Błędne skierowanie pilnej sprawy może mieć istotny skutek, nawet jeśli wynik modelu składa się z jednej etykiety.

Zacznij od kontraktu zadania

Opisz wejście, dozwolone wyniki i sposób obsługi niepewności. Jeśli człowiek nie potrafi jednoznacznie przypisać części spraw, model także potrzebuje możliwości przekazania ich do oceny.

Element	Przykład dla zgłoszeń
Wejście	Treść zgłoszenia i dozwolone dane kontekstowe
Wynik	Jedna z ustalonych kategorii
Wyjątek	Brak danych lub kilka równorzędnych kategorii
Dalsza operacja	Skierowanie do kolejki albo propozycja dla pracownika
Kontrola	Osobna ścieżka dla błędu o dużych konsekwencjach

Nie dodawaj automatycznego priorytetu tylko dlatego, że model potrafi go wygenerować. To odrębna decyzja wymagająca kryterium i odbioru.

Granice powinny być widoczne również dla użytkownika. Osoba obsługująca wyjątek musi wiedzieć, czy system jedynie proponuje etykietę, czy już wykonał operację.

Przykład, w którym wysoka trafność myli

Załóżmy syntetyczny zbiór 100 zgłoszeń. Wśród nich 90 należy do kategorii „pozostałe”, a 10 wymaga pilnej obsługi. Model przypisujący wszystkim kategorię „pozostałe” uzyska 90% trafności ogólnej.

Jednocześnie przeoczy wszystkie pilne sprawy. Taki wynik pokazuje, dlaczego jedna średnia nie wystarcza.

Miara	Wynik w przykładzie
Wszystkie zgłoszenia	100
Poprawnie przypisane	90
Trafność ogólna	90%
Wykryte pilne sprawy	0 z 10
Udział wykrytych pilnych spraw	0%

Nie są to wyniki istniejącego produktu. To własny przykład obliczeniowy pokazujący wpływ nierównego rozkładu danych.

Przy odbiorze oceniaj grupy istotne dla procesu. Sprawdź zarówno przeoczenia, jak i błędne alarmy. Nadmiar alarmów może przeciążyć zespół, ale ich ograniczenie kosztem pomijania krytycznych spraw nie jest automatycznie poprawą.

Przygotuj dane, które reprezentują pracę

Zbiór testowy powinien zawierać zwykłe przypadki, literówki, skróty i niepełne opisy. Nie oczekuj dobrego wyniku w rzeczywistej kolejce, jeśli model był oceniany wyłącznie na starannie napisanych przykładach.

Oddziel dane do przygotowania rozwiązania od danych do końcowej oceny. Wielokrotne poprawianie systemu pod ten sam zestaw może sprawić, że przestanie on reprezentować nowe sprawy.

Ustal także jakość etykiet. Jeśli dwie osoby inaczej klasyfikują to samo zgłoszenie, najpierw wyjaśnij zasadę. Trenowanie na nieuzgodnionych ocenach może utrwalić spór zamiast go rozwiązać.

Nie musisz zaczynać od wielkiego projektu. Pierwsza próba może ujawnić, że najważniejszą pracą jest uproszczenie kategorii albo dopisanie brakującego pola.

Porównaj AI z prostszą regułą

Jeżeli do skierowania sprawy wystarcza jedno jawne pole, reguła może być lepszym punktem wyjścia. Łatwiej wtedy wyjaśnić decyzję i sprawdzić wyjątek.

Model może pomóc, gdy potrzebujesz interpretacji zmiennej treści. Nie powinien jednak zastępować sprawdzenia, które da się wykonać jednoznacznie, na przykład poprawności identyfikatora klienta.

Przygotuj wynik bazowy obecnego procesu. Porównaj nie tylko trafność, lecz również czas obsługi, poprawki i koszt utrzymania. Wdrożenie AI jest uzasadnione dopiero wtedy, gdy pomaga w konkretnym zadaniu.

Oddziel propozycję od działania

W pilotażu system może sugerować kategorię, a pracownik ją zatwierdzać. Tak zbierzesz przykłady niezgodności i zobaczysz, czy błąd jest zrozumiały.

Nie zakładaj, że obecność człowieka automatycznie zapewnia kontrolę. Osoba powinna widzieć dane potrzebne do oceny i mieć czas na zmianę propozycji. Masowe zatwierdzanie bez sprawdzania nie daje tego samego zabezpieczenia.

Po dopuszczeniu automatyzacji zachowaj możliwość poprawienia błędnej klasyfikacji i odtworzenia jej skutków. Ustal, kto odpowiada za zaległą sprawę, gdy system przestanie działać.

Platforma nie zastępuje kryteriów odbioru

W środowisku Microsoft aktualna dokumentacja opisuje Microsoft Foundry jako platformę modeli i aplikacji AI. Źródło: Microsoft Foundry.

Możesz korzystać z narzędzi zarządzanych lub własnych komponentów. W obu wariantach potrzebujesz danych, kontroli dostępu i pomiaru jakości. Sama nazwa usługi nie potwierdza poprawności klasyfikacji.

Połączenie funkcji z procesem rozwija Inteligentny System Operacyjny Firmy. System powinien wiedzieć, gdzie kończy się jego zakres i do kogo trafia wyjątek.

Ustal także odpowiedzialność za poprawione etykiety. Korekta użytkownika może być cenna, ale nie powinna automatycznie zmieniać zasad dla całego systemu bez weryfikacji. W przeciwnym razie pojedynczy nieuzgodniony wyjątek może wpłynąć na przyszłe sprawy.

Kiedy nie potrzeba modelu

W klasyfikacji zgłoszeń zacznij od próbki i prostej reguły bazowej. Jeżeli większość spraw ma jednoznaczny kod produktu oraz ustrukturyzowany powód kontaktu, reguła może być tańsza i łatwiejsza do wyjaśnienia niż model. Model warto rozważyć dopiero dla spraw, w których opis klienta wnosi informację niewidoczną w polach formularza.

Przed wyborem zapisz trzy liczby z tej samej próbki: poprawnie przypisane sprawy, przypadki skierowane do człowieka i koszt błędnego przypisania. Jeśli model poprawia tylko pierwszy wskaźnik kosztem zwiększenia liczby trudnych błędów, nie jest ulepszeniem procesu. Następny krok to porównanie modeli i ich licencji, nie zakup platformy na podstawie samej definicji „wąskiej AI”.

Zaplanuj kontrolę po uruchomieniu

Rodzaj zgłoszeń może się zmienić po wprowadzeniu nowego produktu. Sprawdzaj próbki, powody korekt i udział przypadków spoza zakresu. Dobrze działająca wersja nie pozostaje automatycznie dobra dla każdych przyszłych danych.

Jeżeli rozważasz model dostępny publicznie, poradnik Hugging Face pomaga ocenić zasób razem z warunkami użycia.

W poniedziałek wybierz jedno zadanie klasyfikacyjne. Zapisz dozwolone wyniki, najdroższy rodzaj błędu i ścieżkę wyjątków. Dopiero wtedy porównaj regułę i model. Potrzebujesz sprawdzalnego wyniku, nie koniecznie najbardziej wszechstronnej aplikacji.