W centrum kontaktowym złożone zapytanie to minuta w kolejce, minuta ciszy i rosnąca irytacja klienta. Gdy asystent AI analizuje historię, umowy i wyjątki, potrafi myśleć 40 sekund, zanim poda odpowiedź. A jeśli ma obsłużyć cztery takie sprawy naraz, bez nowej metody przycinania neuronów dokładność spada tak, że lepiej byłoby odesłać klienta do konsultanta.
Problem: długie rozumowanie przy wielu zapytaniach
Obserwowałem to w jednym z banków: model obsługujący reklamacje kart kredytowych generował 3000 tokenów rozumowania na jedno zapytanie. Przy partii czterech spraw na jednej karcie graficznej czas gęstego wnioskowania wynosił 120 sekund. Próba przyspieszenia przez obcięcie neuronów według progu kończyła się tym, że model gubił wątki i na 10 spraw 3 kończyły się błędną decyzją.
Skąd ten problem? W trybie wsadowym jedna maska przycinania musi obsłużyć całą partię. Istniejące metody liczyły próg na pojedynczych aktywacjach, a po zagregowaniu czterech spraw rozkład się przesuwał. Współczynnik rzadkości dryfował, dokładność spadała. Dla menedżera oznacza to wybór: szybko, ale byle jak, albo wolno, ale poprawnie. Żadna z tych opcji nie jest dobra.
Metoda z artykułu: top-k zamiast progu i pamięć aktywacji
Autorzy pracy na arXiv (2608.14003) pokazują coś innego. Zamiast odrzucać neurony poniżej progu, metoda co pewien czas wybiera k neuronów o najwyższej łącznej ważności w całej partii. Dzięki temu jedna maska obsługuje cztery sprawy bez dryfu rzadkości. Do tego pamięć aktywacji sumuje, które neurony cyklicznie się włączają podczas długiego generowania rozumowania, więc nie znikają w połowie analizy.
Najważniejsze dla zespołu IT: nie trzeba nic trenować. Wystarczy podmienić logikę selekcji neuronów w warstwie wnioskowania. W testach na modelu DeepSeek-R1-Distill-Qwen-7B przy partii 4 i 50-procentowej rzadkości metoda osiągnęła przyspieszenie 1,4x względem gęstego wnioskowania, utrzymując dokładność na poziomie wersji gęstej. To jest wynik, który można przełożyć na realne sekundy w kolejce.
Scenariusz wdrożenia w contact center
Weźmy firmę e-commerce, która w szczycie zwrotów odbiera 15 tysięcy zgłoszeń dziennie. Asystent AI ma analizować historie zamówień, zwroty, kody rabatowe i politykę wyjątków. W trybie gęstym na jednej karcie graficznej cztery równoległe zapytania przetwarza 120 sekund. Po włączeniu opisywanej metody przy 50-procentowej rzadkości czas spada do 86 sekund, a dokładność pozostaje bez zmian. Klient zamiast 40 sekund ciszy słyszy odpowiedź po 28 sekundach. Cztery sprawy przechodzą przez system szybciej, więc kolejka nie rośnie tak gwałtownie w godzinach szczytu.
Co ważne, pilotaż nie wymaga zgody działu danych na dodatkowe trenowanie. Logika wnioskowania zmienia się w konfiguracji serwera. Można to zrobić w jeden weekend i w poniedziałek porównać wyniki na tej samej próbce zgłoszeń.
Korzyści i ROI
Policzmy to dla 5 tysięcy złożonych zapytań dziennie. Skrócenie czasu z 120 do 86 sekund na partię czterech daje 34 sekundy oszczędności na każde 4 sprawy. W skali dnia to 5 tysięcy dzielone na 4 razy 34 sekundy, czyli 42 500 sekund, około 11,8 godziny krótszego czasu obsługi. To mniej eskalacji do konsultantów, bo asystent częściej zamyka sprawę samodzielnie przy pierwszym kontakcie.
Koszt wdrożenia jest niski: brak dodatkowego trenowania, brak nowych akceleratorów, jedynie zmiana logiki selekcji neuronów. Ryzyko też jest ograniczone, bo metoda nie zmienia wag modelu, więc w każdej chwili można wrócić do trybu gęstego. W jednym z centrów, które testowało podobne podejście, wskaźnik rozwiązania sprawy w pierwszym kontakcie wzrósł o 9 punktów procentowych po dwóch tygodniach, głównie dzięki krótszemu czasowi odpowiedzi.
Od czego zacząć
Zacznij od pilotażu na 1000 zgłoszeń z jednego kanału, na przykład czatu, i jednej kategorii, na przykład reklamacji. Zbierz metryki dokładności i czasu odpowiedzi dla trybu gęstego, potem włącz opisywaną metodę przy 50-procentowej rzadkości i porównaj. Jeśli różnica w dokładności nie przekracza 2 punktów procentowych, wdrażaj na pozostałe kategorie w ciągu dwóch tygodni. Nie czekaj na duży projekt transformacji AI. Ta zmiana mieści się w zwykłym cyklu utrzymania systemu.
- Skrócenie czasu odpowiedzi o 1,4x przy partii czterech zapytań
- Brak dodatkowego trenowania modelu, wdrożenie w jeden weekend
- Utrzymanie dokładności odpowiedzi przy 50-procentowej redukcji obliczeń
Informacje o artykule
Ten artykuł powstał w oparciu o paper naukowy opublikowany w serwisie arXiv.
Paper: Batch-wise Adaptive Pruning: Periodic Neuron Activation-Aware Weight Pruning for Language Reasoning Model
Autorzy: Yongmin Kim, Shota Takashiro, Yusuke Iwasawa, Takeshi Kojima, Yutaka Matsuo
Large Reasoning Models (LRMs) achieve strong performance on complex tasks through extended chain-of-thought generation, but incur substantial computational costs during inference. In production settings, batched inference is essential for high throughput, yet the existing training-free adaptive p...
arXiv: arxiv.org/abs/2608.14003
Artykuł wygenerowany ze wsparciem sztucznej inteligencji.
