Jak AI naprawiło organizację podróży służbowych

Jeśli należysz do grona osób, które często jeżdżą w podróże służbowe, to wiesz, z jakimi wyzwaniami się to wiąże. Rezerwacja lotów, hoteli, transportu, a także zarządzanie wydatkami i dokumentacją mogą być czasochłonne i stresujące. Zazwyczaj każdą z tych rzeczy trzeba robić w osobnym firmowym systemie, co nierzadko kończy się frustracją i wysłaniem gniewnego maila do działu HR.

Jest to o tyle zastanawiające, że przecież odpowiedzi na większość tych problemów są dostępne i można by je zintegrować w jednym miejscu. „Czy mogę lecieć business class do Berlina?”, „Jaki jest limit na hotel w Londynie?”, „Jakie dokumenty muszę złożyć po powrocie?” – to pytania do polityki firmy, nie do człowieka. Postanowiłem przyjrzeć się temu problemowi z perspektywy AI i zobaczyć, jak można go rozwiązać. Przy okazji udało mi się upiec dwie pieczenie na jednym ogniu – wziąć udział w programie Sii AI Grants (więcej o tym później) i przetestować framework do tworzenia systemów wieloagentowych od Google.

Pomysł: AI użyte do integracji systemów podróży służbowych

W gruncie rzeczy obsługę podróży służbowych można podzielić na 3 główne obszary:

• Rezerwacja i organizacja podróży:
  • Szukam najlepszego połączenia do Los Angeles, najlepiej bezpośredniego, ale nie wiem, czy nasza firma ma jakieś preferencje co do linii lotniczych.
  • Chcę zarezerwować możliwie najlepszy hotel w centrum, ale nie wiem, jaki jest limit na nocleg.
  • Muszę zorganizować skomplikowany, wielopołączeniowy lot, a na miejscu wynajem 2 samochodów służbowych i transport dla całej delegacji.
• Zarządzanie dokumentacją:
  • Chcę dowiedzieć się, jakie dokumenty muszę złożyć po powrocie z podróży służbowej.
  • Szukam informacji, czy mogę przedłużyć mój pobyt o kilka dni, żeby zwiedzić miasto, ale nie wiem, czy muszę złożyć jakieś dodatkowe dokumenty.
  • Nie wiem, kogo z HR zapytać o problem, który mnie trapi.
• Zarządzanie wydatkami:
  • Chcę rozliczyć koszty podróży.
  • Jako pracownik działu HR chcę mieć łatwy dostęp do informacji o wydatkach pracowników, aby móc lepiej zarządzać budżetem.
  • Jako szef działu finansów chcę przygotować raport dotyczący wydatków na podróże służbowe w ostatnim kwartale.

Zauważmy, że te obszary są ze sobą powiązane i często wymagają współpracy różnych systemów oraz działów w firmie. Jest to więc wymarzone pole do zastosowania AI, która może zintegrować je w jednym miejscu.

Ułatwiaj, nie utrudniaj

Aby uniknąć tworzenia dodatkowego systemu, który będzie tylko kolejną aplikacją dla pracowników, postanowiłem podejść do problemu z perspektywy użytkownika. Skoro mamy już w firmie system ticketowy (Atlassian Jira), to może wykorzystajmy go jako główny interfejs do obsługi podróży służbowych? Pracownicy są już przyzwyczajeni do korzystania z tego systemu, więc nie musimy ich uczyć nowej aplikacji. Zamiast tego możemy stworzyć agenta AI, który będzie działał jako „asystent podróży służbowych” i będzie się integrował z Jirą, aby umożliwić pracownikom łatwe zarządzanie podróżami służbowymi.

Tak więc powstała GAIA (skrót od Google, AI, Atlassian) – połączenie Jiry i AI, które umożliwia pracownikom zarządzanie podróżami służbowymi w jednym miejscu. Jest ona pomocą dla wszystkich pracowników:

• tych, którzy wybierają się w podróż,
• tych, którzy ją rozliczają,
• dla działu HR, który może łatwo monitorować i zarządzać wszystkimi podróżami służbowymi w firmie.

Dzięki takiemu rozwiązaniu pracownik nie musi poznawać nowego narzędzia, a jego interakcja z systemem nie różni się niczym od tego, do czego jest przyzwyczajony – zmienia się tylko backend: zamiast człowieka po drugiej stronie skrzynki mailowej odpowiada AI. Umożliwia to także rozwiązanie problemów, które dotychczas zajmowały godziny lub dni, w ciągu kilku minut.

Pracownik zadaje pytanie o ubezpieczenie podróżne, a system automatycznie odpowiada w komentarzu, cytując konkretne dokumenty polityki firmowej.

Sii AI Grants

Projekt GAIA powstał w ramach programu Sii AI Grants, który ma na celu wspieranie innowacyjnych projektów wykorzystujących sztuczną inteligencję – projektów, na które nie ma czasu w ramach codziennych obowiązków, ale które mogą przynieść realną wartość dla firmy.

Przeznaczony jest do testowania nowych technologii, eksperymentowania z różnymi pomysłami i tworzenia prototypów.

W ramach tego programu pracownik otrzymuje 10-dniowy urlop od pracy dla klienta (pełnopłatny, oczywiście), który może wykorzystać na realizację swojego projektu. To świetna okazja, aby spróbować czegoś nowego, rozwinąć swoje umiejętności i przyczynić się do rozwoju firmy. GAIA jest właśnie jednym z takich projektów – powstała dzięki temu, że miałem możliwość poświęcić czas na eksperymentowanie i testowanie różnych pomysłów.

Architektura

Pracownik komunikuje się z systemem przez Jira Service Management. Ticket trafia przez REST API do Orchestratora, który deleguje zadania do wyspecjalizowanych agentów (Policy, Booking, Reporting), z których każdy łączy się z odpowiednim systemem zewnętrznym (Vertex AI RAG, Amadeus.com, BigQuery). W razie potrzeby Orchestrator eskaluje sprawę do człowieka.

Orchestrator

GAIA korzysta z Jiry jako głównego i jedynego interfejsu między nią a użytkownikiem. Pracownik tworzy ticket w Jirze (z dowolnym zapytaniem w języku naturalnym), który następnie jest wysyłany przez REST API do GAII.

GAIA to system wieloagentowy. Na jego czele stoi Orchestrator – główny agent, który zarządza całym procesem obsługi zapytania. Orchestrator analizuje zapytanie i decyduje, które subagenty są potrzebne do jego obsługi. Jako jedyny rozmawia bezpośrednio z użytkownikiem (poprzez komentarze w tickecie w Jirze). Ma dostęp do wszystkich informacji o tickecie (jego treści, autorze, historii komentarzy itp.) i na tej podstawie podejmuje decyzje dotyczące dalszych kroków. Pomagają mu wyspecjalizowani agenci, z których każdy odpowiada za inne zadanie. Mogą komunikować się ze sobą bezpośrednio.

Orchestrator dba także o prawidłowy przebieg komunikacji z użytkownikiem. Dzięki wbudowanym mechanizmom rozumienia intencji jest w stanie wykryć, czy użytkownik jest zadowolony z odpowiedzi, czy też potrzebuje dodatkowych informacji lub wyjaśnień. Ponadto, wyposażony jest w szereg tzw. guardrails, które pomagają mu unikać błędów i nieporozumień. Na przykład, jeśli użytkownik zadaje pytanie, na które Orchestrator nie zna odpowiedzi, zamiast udzielać błędnej informacji, może poprosić o dodatkowe informacje lub przekierować rozmowę do człowieka.

Policy Agent – ekspert od polityki firmy

Policy Agent odpowiada na pytania o zasady, limity i procedury. Skąd bierze wiedzę? Z korpusu dokumentów z politykami firmowymi, udostępnionych mu przez dział HR. Ten korpus jest połączony z RAG-iem w Vertex AI.

Dzięki takiemu rozwiązaniu agent ma dostęp do aktualnych i oficjalnych informacji, które są zawsze zgodne z polityką firmy. Aktualizacja informacji jest prosta – dzięki odpowiedniej konfiguracji wystarczy dodać nowy dokument do bazy danych (w tym przypadku baza danych to określenie na wyrost: HR dodaje dokumenty do folderu na Google Drive – trudno o prostsze rozwiązanie), a agent automatycznie je zaindeksuje i będzie mógł z nich korzystać.

Po znalezieniu odpowiedzi na pytanie agent przekazuje Orchestratorowi zgromadzoną wiedzę, podając odpowiednie cytowania. Oczywiście, jeśli Policy Agent nie jest w stanie znaleźć odpowiedzi na pytanie, może poprosić o dodatkowe informacje lub wprost przyznać się do niewiedzy, zamiast udzielać błędnych informacji.

Reporting Agent – analityk danych

Odpowiada na pytania o dane historyczne i bieżące: ile wydaliśmy na hotele w ostatnim kwartale, które departamenty przekroczyły budżet, kto jest aktualnie na delegacji za granicą.

Agent ten jest połączony z bazą danych w BigQuery, w której przechowywane są wszystkie dane dotyczące podróży służbowych (rezerwacje, wydatki, dokumenty itp.). Przy pracy nad tym agentem przyświecała mi jedna myśl: chcę, żeby był w stanie samodzielnie eksplorować bazę danych i korygować swoje działania. Nie chciałem dostarczać mu gotowych zapytań SQL, które musiałby wykonywać, ponieważ takie podejście w oczywisty sposób ograniczałoby jego możliwości.

Ponadto przyjąłem założenie, że taka baza danych może (i będzie!) zawierać błędy, nieścisłości i luki (np. wydatki na posiłki oznaczone jako „Jedzenie”, „dieta” lub „kolacja”). Co więcej, wspomniana „baza danych” w większości przypadków będzie raczej zbiorem arkuszy kalkulacyjnych, które ktoś ręcznie aktualizuje, niż dobrze zorganizowaną bazą danych.

Stąd też decyzja o podzieleniu Reporting Agenta na 3 pod-agentów, którzy będą pracować iteracyjnie, w pętli refleksji:

• QueryPlanner – analizuje zapytanie użytkownika i planuje podejście w języku naturalnym – może na przykład zdecydować, że należy sprawdzić schemat tabel w bazie danych przed wykonaniem właściwego zapytania.
• QueryExecutor – tłumaczy plan na SQL i wykonuje go w BigQuery. Co ważne – ma dostęp tylko i wyłącznie read-only.
• FeedbackAgent – agent odpowiedzialny za kontrolę jakości i poprawności odpowiedzi. Ocenia, czy odpowiedź jest wystarczająca, czy też wymaga dalszej eksploracji bazy danych. Jeśli uzna, że odpowiedź jest niewystarczająca, może poprosić QueryPlanner o ponowne przeanalizowanie zapytania i zaplanowanie innego podejścia.

Ograniczyłem długość tej pętli do maksymalnie 3 iteracji, aby uniknąć sytuacji, w której agent będzie się zapętlał bez końca. W praktyce jednak większość zapytań jest rozwiązywana już w pierwszej lub drugiej iteracji.

Pytanie użytkownika trafia do QueryPlannera, który planuje podejście; QueryExecutor tłumaczy plan na SQL i wykonuje go w BigQuery; FeedbackAgent ocenia jakość odpowiedzi i decyduje, czy zwrócić ją użytkownikowi, czy wrócić do plannera po lepsze podejście.

Booking Agent – asystent rezerwacji

Booking Agent pomaga użytkownikowi w organizacji podróży służbowej, prowadząc go przez wieloetapową rozmowę, zbierając potrzebne informacje: kto jedzie, dokąd, kiedy, na jak długo. Po zebraniu wszystkich informacji wyszukuje dostępne opcje i przedstawia je użytkownikowi, pomagając mu dokonać wyboru.

Dzięki połączeniu agenta z API Amadeus.com agent jest w stanie sprawdzać rzeczywiste dane dotyczące dostępności hoteli i lotów, co pozwala mu przedstawić użytkownikowi aktualne i precyzyjne informacje. Oczywiście, ostateczna decyzja o rezerwacji należy do użytkownika, a agent służy jedynie jako pomoc w procesie podejmowania decyzji.

W przypadku tego agenta programowo wymusiłem na nim interakcję z Policy Agentem – za każdym razem, przed rozpoczęciem procesu rezerwacji, Booking Agent musi skonsultować się z Policy Agentem, aby upewnić się, że proponowane opcje są zgodne z polityką firmy (np. czy dany hotel mieści się w limicie cenowym, czy dany lot jest akceptowalny itp.). Dzięki temu mamy pewność, że użytkownik zawsze otrzyma propozycje zgodne z polityką firmy, a jednocześnie nie musimy martwić się, że agent będzie proponował opcje niedozwolone.

Google Agent Development Kit

Do stworzenia GAIA wykorzystałem Google Agent Development Kit (ADK) – framework do tworzenia systemów wieloagentowych. Dostarcza narzędzia i biblioteki, które ułatwiają tworzenie, trenowanie i wdrażanie agentów AI, a także zarządzanie ich komunikacją i współpracą.

Co więcej, dzięki temu, że jest to produkt Google, ma on natywną integrację z innymi usługami Google, takimi jak Vertex AI, BigQuery czy Google Drive, co znacznie ułatwiło mi implementację poszczególnych agentów oraz ich integrację z różnymi źródłami danych. Dodatkowo, ADK teoretycznie umożliwia bardzo łatwe wdrażanie i skalowanie systemu poprzez automatyczny deployment w Vertex AI.

Dużą zaletą ADK jest także jego elastyczność i modularność – pozwala on na tworzenie agentów o różnym stopniu skomplikowania, od prostych botów do bardziej zaawansowanych systemów wieloagentowych, takich jak GAIA. Dzięki temu, że ADK jest frameworkiem, a nie gotowym produktem, miałem pełną kontrolę nad architekturą i funkcjonalnością mojego systemu, co pozwoliło mi dostosować go do specyficznych potrzeb i wymagań mojego projektu.

Dostępność narzędzi i gotowych rozwiązań była głównym powodem, dzięki któremu udało mi się stworzyć GAIĘ od początku do końca w ciągu zaledwie 10 dni – wliczając w to wszechstronne testy oraz połączenie z Jirą.

Ale czy to działa?

Zwykło się mówić, że systemy AI to tzw. black boxy – nie wiemy, jak dokładnie działają, a ich działanie jest często nieprzewidywalne. O ile pojedynczy LLM to black box, o tyle system wieloagentowy, taki jak GAIA, jest zestawem black boxów, połączonych nieprzezroczystymi połączeniami, zapakowanym w jeszcze jeden black box.

Jak więc możemy być pewni, że taki system działa poprawnie i spełnia swoje zadanie? Odpowiedź jest prosta: testując go w praktyce. W przypadku systemów AI stosuje się (oprócz standardowych testów jednostkowych i integracyjnych) testy funkcjonalne (tzw. content tests), które polegają na symulowaniu rzeczywistych scenariuszy i sprawdzaniu, czy system reaguje na nie w sposób zgodny z oczekiwaniami. Podejście to często opiera się na hybrydowym zastosowaniu deterministycznych testów oraz podejściu opartym na paradygmacie LLM as a judge.

W przypadku obu rodzajów testów najpierw należy przygotować zestaw scenariuszy testowych, które będą reprezentatywne dla rzeczywistych sytuacji, z którymi system będzie musiał sobie radzić. Następnie trzeba sprawdzić, czy system zachowuje się zgodnie z oczekiwaniami w tych scenariuszach.

W przypadku testów deterministycznych oczekiwania są jasno określone, a system powinien zawsze reagować w ten sam sposób. Przykładem takich testów jest sprawdzanie, czy Policy Agent cytuje odpowiednie paragrafy z dokumentów firmy. Za każdym razem zbiór tych cytowań powinien być podobny – stąd determinizm testów.

W przypadku podejścia LLM as a judge sprawdza się (wykorzystując do tego celu inny, niezależny model LLM), czy odpowiedź systemu jest wystarczająco podobna do oczekiwanej, biorąc pod uwagę, że może ona być sformułowana na wiele różnych sposobów.

Testy

W ramach pracy nad GAIA przygotowałem zestaw ponad 250 content testów, sprawdzających działanie poszczególnych agentów w różnych scenariuszach. Dodatkowo przygotowałem 16 testów zawierających scenariusze z wieloma naprzemiennymi interakcjami między użytkownikiem a systemem, które pozwoliły mi sprawdzić, jak GAIA radzi sobie z bardziej skomplikowanymi sytuacjami wymagającymi współpracy różnych agentów i iteracyjnej komunikacji z użytkownikiem.

W przypadku tych bardziej złożonych scenariuszy LLM as a judge sprawdzał nie tylko zgodność z założoną odpowiedzią, ale również zgodność z oczekiwanym przebiegiem rozmowy – trudno bowiem przewidzieć, jak dokładnie system zareaguje na każde pytanie użytkownika, ale można określić, jakie powinny być ogólne ramy tej rozmowy (np. czy system powinien poprosić o dodatkowe informacje, czy powinien skonsultować się z innym agentem itp.). Dzięki temu, że testy były oparte na rzeczywistych scenariuszach, mogłem mieć pewność, że GAIA będzie w stanie poradzić sobie z prawdziwymi sytuacjami, z którymi będzie musiała się zmierzyć w codziennej pracy.

Warto dodać, że content testy nie służą do jednokrotnego testowania systemu – przeciwnie, podobnie jak unit testy, uruchamiam je po wprowadzeniu każdej większej zmiany w systemie, aby upewnić się, że nadal działa on poprawnie.

Należy jednak zastrzec, że z powodu losowości w działaniu wielkich modeli językowych nie ustaliłem progu zaliczenia testów na 100% – dopuszczam, że w niektórych testach system może nie przejść, mimo że działa poprawnie. Dlatego też ustaliłem próg zaliczenia na 90% – jeśli system przejdzie 90% testów, uznaję, że działa poprawnie (10% niedziałających testów powinno być losowe – w przypadku, gdy system nie może przejść tego samego testu wielokrotnie, należy przyjrzeć się temu testowi i sprawdzić, co jest jego przyczyną).

Wyniki testów

Poniżej średnie metryki z przeprowadzonych testów:

• 96% zapytań obsłużonych przez system bez interwencji człowieka,
• zaledwie 3% przypadków eskalowanych do człowieka,
• maksymalny czas odpowiedzi: 5 minut.

Warto wyjaśnić, co kryje się za tymi 3% eskalacji.

Gdy GAIA nie jest w stanie obsłużyć zapytania samodzielnie – bo problem jest zbyt złożony, dotyczy obszaru poza jej kompetencjami albo wymaga ludzkiego osądu – system w sposób kontrolowany przekazuje rozmowę dalej. Użytkownik dostaje informację, że jego sprawą zajmie się człowiek, a ticket w Jirze zostaje przypisany do odpowiedniej osoby z zespołu obsługi podróży. Nie ma tu cichego „porzucenia” zapytania – przekazanie go człowiekowi jest świadomym, jawnym krokiem systemu.

Multi-agent vs single-agent

Dlaczego zdecydowałem się rozdzielić funkcjonalność między kilka agentów zamiast stworzyć jednego, który będzie robił wszystko? Odpowiedź jest prosta: modularność, specjalizacja i łatwość testowania.

Każdy agent w GAIA ma jasno określoną rolę i specjalizację, co pozwala mu skupić się na konkretnych zadaniach i wykonywać je lepiej. Dzięki temu, że każdy agent jest odpowiedzialny za inny obszar, mogłem zoptymalizować ich działanie i dostosować je do specyficznych potrzeb każdego z tych obszarów.

Ponadto rozdzielenie funkcjonalności na kilka agentów ułatwia zarządzanie i rozwój systemu – jeśli chcę dodać nową funkcjonalność lub poprawić istniejącą, mogę to zrobić w jednym agencie, nie wpływając na działanie pozostałych. Dodatkowo rozdzielenie funkcjonalności na kilka agentów bardzo ułatwia testowanie – mogę testować każdego agenta osobno, a także testować ich współpracę w różnych scenariuszach.

Ostatnim, ale nie mniej ważnym, powodem jest optymalizacja kosztów – każdy agent może być innym modelem. Dzięki temu mogę użyć potężnego modelu do zadań researchowych (np. Reporting Agent), a prostszego, tańszego modelu do zadań, które tego nie wymagają (np. Orchestrator).

Czego się nauczyłem

Wiele LLM-ów to wiele źródeł niespodzianek

W systemach wieloagentowych każdy agent ma własny kontekst i własne założenia. Informacja nie przepływa automatycznie w górę hierarchii. Podczas developmentu stosowałem podejście „mock first”: zaczynamy od zamockowanych odpowiedzi wszystkich narzędzi, potem stopniowo zastępujemy je prawdziwymi implementacjami. Jest to podejście, które pozwala testować logikę agentów, zanim podłączy się zewnętrzne API.

Problem pojawił się, gdy któryś tool był jeszcze zamockowany, a ja o tym zapomniałem. Agent używający tego narzędzia wiedział, że dostaje odpowiedź z mocka – ale nie przekazał tej informacji Orchestratorowi. Użytkownik dostawał odpowiedź wyglądającą na prawdziwą, która de facto pochodziła z mockowanych danych. W systemie wieloagentowym subtelny błąd w jednym miejscu może dać z pozoru prawidłowy wynik na wyjściu.

Wniosek praktyczny: testy automatyczne są krytyczne – nie tylko testy poszczególnych agentów, ale także testy weryfikujące cały pipeline end-to-end. Ręczne sprawdzanie nie wystarczy, gdy błąd jest semantyczny, a nie składniowy.

ADK w fazie eksperymentalnej

Ważne: projekt GAIA powstał na przełomie sierpnia i września 2025

W momencie budowania projektu ADK był młodym, aktywnie rozwijanym frameworkiem. Dokumentacja bywała niekompletna lub opisywała API, które już działało inaczej. Kilka razy sporo czasu zajęło debugowanie czegoś, co okazało się błędem w dokumentacji, nie w kodzie. Auto-deploy na Vertex AI nie działał stabilnie i trudno było to zdebugować – ostatecznie zdecydowałem się na własne REST API na VM w GCP, co dało mi pełną kontrolę nad zarządzaniem i debugowaniem.

Warto być tego świadomym, planując podobny projekt: przy wczesnych wersjach frameworków trzeba zarezerwować czas na taką walkę.

Artificial Intelligence

Dostarczamy rozwiązania AI dopasowane do Twojego biznesu, które zwiększają efektywność i podnoszą produktywność Twojego zespołu.

Oferta AI

Podsumowanie

Projekt GAIA pokazał, że AI może być skutecznym narzędziem w rozwiązywaniu realnych problemów biznesowych, takich jak organizacja podróży służbowych.

Dzięki zastosowaniu systemu wieloagentowego, udało mi się stworzyć rozwiązanie, które integruje różne systemy i źródła danych w jednym miejscu, umożliwiając pracownikom łatwe zarządzanie swoimi podróżami. Projekt ten był także świetną okazją do eksperymentowania z nowymi technologiami i rozwijania swoich umiejętności w dziedzinie AI.

Nie można tutaj nie podkreślić roli ADK – dzięki temu frameworkowi udało mi się stworzyć GAIA w ciągu zaledwie 10 dni.