Reklamacje zaginięć rozpatrywane według reguł, a nie uznania modelu
Usługa oceniająca reklamacje zagubionych przesyłek w sieci kurierskiej: pozwala modelowi odpowiedzieć na trzy wąskie pytania, wykonuje wszystkie weryfikacje w ustalonej kolejności i albo zatwierdza roszczenie, albo przekazuje je człowiekowi z pełną listą powodów.
Kontekst
Gdy przesyłka ginie, klient biznesowy (nadawca) składa reklamację, a zespół ds. roszczeń ją weryfikuje: czy została zgłoszona w terminie wynikającym z umowy danego klienta, czy paczka rzeczywiście zaginęła, czy sieć ponosi odpowiedzialność za dany rodzaj towaru, jaka jest kwota wypłaty i który oddział (depot) zostaje nią obciążony. Każda reklamacja to kilka pól formularza oraz opis towaru w formie tekstu swobodnego - wcześniej każdą z nich musiał przeczytać człowiek. Sieć chciała, aby jednoznaczne sprawy były rozstrzygane automatycznie, a pozostałe trafiały do pracowników z wykonaną już pracą analityczną.
Ograniczenia
- Każda decyzja musiała być w pełni wytłumaczalna dla konkretnej reklamacji. „Model tak uznał” nie jest uzasadnieniem, na którym może oprzeć się zespół reklamacyjny czy audytor.
- Umowy różnią się w zależności od klienta: terminy składania reklamacji i klauzule odpowiedzialności są zapisane otwartym tekstem i nadpisują ustawienia domyślne.
- Opisy towarów bywają niejednoznaczne. „Galaxy” może oznaczać tabliczkę czekolady albo telefon - a jeden z tych przedmiotów znajduje się na liście towarów zakazanych.
- Wszystko, czego usługa nie była w stanie rozstrzygnąć z odpowiednio wysoką pewnością, musiało trafić do człowieka wraz z uzasadnieniem, zamiast polegać na domysłach.
- Dane odbiorcy nie są potrzebne do podjęcia decyzji, dlatego nigdy nie są wykorzystywane.
Co zbudowaliśmy
Usługę FastAPI na Cloud Run, która przyjmuje reklamację i zwraca jeden z dwóch wyników - zatwierdzenie lub skierowanie do weryfikacji ręcznej - wraz z dziennikiem decyzyjnym każdego wykonanego sprawdzenia. Reklamacje spływają codziennie z systemu zgłoszeniowego, dane odbiorcy są odrzucane już na wejściu, a skolejkowane sprawy są przetwarzane przez Cloud Tasks z punktami kontrolnymi (checkpointami) w Cloud SQL. Dzięki temu ponowienie po błędzie wznawia proces od przerwanego kroku, zamiast zaczynać od początku.
Fakty pochodzą z dwóch źródeł odpytywanych bezpośrednio przez kod, bez udziału modelu: historia przesyłki, skany doręczeń, kontakt z klientem, oddziały i przeadresowania są pobierane przez jeden serwer MCP, a warunki umowy klienta przez drugi. Model Gemini na Vertex AI otrzymuje dokładnie trzy pytania, i to wyłącznie wtedy, gdy wymaga tego tekst: czym w rzeczywistości jest opisany towar i czy znajduje się na liście towarów zakazanych (z wykorzystaniem wyszukiwarki internetowej przy niejednoznacznych opisach oraz oceną pewności odpowiedzi); ile dni na złożenie reklamacji przewiduje umowa, jeśli podaje konkretną liczbę; oraz czy w umowie wskazano specjalny adres do rozliczeń.
Następnie przepływ LangGraph wykonuje weryfikacje w ściśle określonej kolejności, a model nigdy nie decyduje o kolejnym kroku:
- Zgłoszenie w terminie umownym.
- Przyjęcie odpowiedzialności przy pewności identyfikacji towaru powyżej progu.
- Brak potwierdzenia doręczenia po dacie złożenia reklamacji.
- Brak skanu sugerującego zamianę etykiet (cross-label).
- Przypisany oddział rozliczeniowy.
- Brak przeadresowania lub przepakowania ze zmianą etykiety.
- Brak specjalnych warunków płatności.
- Kwota w granicach limitu automatycznej wypłaty.
Jeśli wszystkie punkty zostaną spełnione, reklamacja jest zatwierdzana. Jeśli którykolwiek zakończy się niepowodzeniem, sprawa trafia do weryfikacji ręcznej ze wskazaniem każdego niespełnionego warunku oraz wyliczonym już oddziałem rozliczeniowym i obciążeniem zwrotnym dla weryfikatora. Decyzje trafiają do BigQuery, a każda ocena jest śledzona w LangSmith.
Rezultat
Od początku 2026 roku system ocenia około 200 reklamacji dziennie, a do każdej z nich generuje log, który weryfikator może przeczytać w minutę. Gdy pewność modelu jest niska, sprawa trafia do człowieka, a gdy zewnętrzna usługa jest niedostępna, dany krok jest automatycznie ponawiany. System został zbudowany, wdrożony i jest utrzymywany przez Jakuba.
Technologia
Python, FastAPI na Cloud Run, LangGraph, Gemini na Vertex AI z wyszukiwarką internetową, dwa serwery MCP do danych przesyłek i umów, Cloud Tasks, Cloud SQL, BigQuery, LangSmith.