---
title: Jak zbudowaliśmy Wirtualnego Asystenta dla Szczecina
description: "Od 15 września mieszkańcy Szczecina pytają e-Urząd własnymi słowami. Co jest pod oknem rozmowy: RAG, porządkowanie wiedzy, testy z BOI i sędziowie AI."
author: Wojciech Kozicki
date: 2026-09-15
tags:
  - ai
  - rag
  - case-study
  - administracja-publiczna
  - chatbot
url: "https://inprojects.ai/blog/jak-zbudowalismy-wirtualnego-asystenta-dla-szczecina/"
audio: "https://galactiv.eu/inpro.mp3"
language: pl
---

# Jak zbudowaliśmy Wirtualnego Asystenta dla Szczecina

> Od 15 września mieszkańcy Szczecina pytają e-Urząd własnymi słowami. Co jest pod oknem rozmowy: RAG, porządkowanie wiedzy, testy z BOI i sędziowie AI.

> RAG w teorii jest prosty: znajdź informacje i poproś AI o odpowiedź. W praktyce trzeba jeszcze wiedzieć, czy system znalazł właściwe źródło, rozpoznał sytuację użytkownika i nie pomylił zasad dotyczących różnych spraw. Pokazujemy, jak podeszliśmy do tego w inProjects, wspólnie z zespołem Urzędu Miasta Szczecin.

*Ilustracja: Plansza z rozmową: pytanie mieszkańca „Marzy mi się ślub nad brzegiem morza” i dopytanie asystenta „Ślub cywilny czy wyznaniowy?”*

*Pytania na planszach są dosłowne i pochodzą z rozmów testowych. Odpowiedzi asystenta pokazujemy w skrócie redakcyjnym.*

## Najważniejsze w dwie minuty

W inProjects przygotowaliśmy Wirtualnego Asystenta, który pomaga odnaleźć informacje w materiałach szczecińskiego e-Urzędu. Użytkownik opisuje swoją sytuację własnymi słowami, a system wyszukuje odpowiednie treści, układa odpowiedź i wskazuje źródła. 15 września 2026 r. Urząd Miasta Szczecin uruchomił asystenta produkcyjnie w serwisie [e-Urząd](https://eurzad.szczecin.pl/). Do końca roku trwa pilotaż: mieszkańcy oceniają odpowiedzi przyciskami w czacie, a my razem z zespołem urzędu analizujemy te sygnały. Zasady korzystania miasto opisało w [komunikacie z 15 września](https://wiadomosci.szczecin.eu/artykul/mieszkancy/szczecin-uruchomil-wirtualnego-asystenta-ai-jak-korzystac-z-bezplatnego-czatu-w-e-urzedzie).

Jak asystent radzi sobie od uruchomienia — jakim językiem mieszkańcy piszą do urzędu, gdzie trzyma granicę i czego brakuje w treściach urzędowych — opisaliśmy w [osobnym artykule](https://inprojects.ai/blog/pierwsze-dni-asystenta-w-e-urzedzie/).

Asystent to dodatkowy kanał informacyjny, a nie elektroniczny urzędnik wydający decyzje. Nie składa wniosków, nie ma dostępu do indywidualnych spraw ani miejskich rejestrów. Korzysta przede wszystkim z opisów procedur, formularzy i odpowiedzi na najczęściej zadawane pytania, czyli FAQ.

Za oknem rozmowy stoi własne oprogramowanie inProjects, baza wiedzy, odpowiednio skonfigurowane modele AI, narzędzia testowe i monitoring. Równie ważna jest współpraca z pracownikami urzędu: to razem z nimi ustalamy, kiedy odpowiedź jest wystarczająca, kiedy trzeba dopytać i gdzie należy poprawić treść źródłową.

Aplikacja, baza wiedzy i rejestry działania są utrzymywane w infrastrukturze miasta. Wybrane obliczenia wykonują zewnętrzne usługi AI. Architekturę rozwijamy tak, aby można było wymieniać komponenty, także na uruchamiane lokalnie. Jesteśmy szczególnie zainteresowani zbudowaniem wersji asystenta, która nie korzysta z usług „big tech”.

### Jak wypróbować asystenta

Wejdź na [eurzad.szczecin.pl](https://eurzad.szczecin.pl/) i kliknij ikonę wiadomości w prawym dolnym rogu ekranu. Czat jest bezpłatny, działa całą dobę i nie wymaga logowania. Opisz sprawę własnymi słowami, bez danych osobowych. AI może się mylić, więc formularz, opłatę i termin sprawdź w materiale, do którego prowadzi odnośnik z odpowiedzi. Dotychczasowe kanały kontaktu z urzędem, w tym infolinia 91 42 45 000, działają bez zmian.

## Masz sprawę do urzędu? Zacznij od rozmowy

https://www.youtube.com/shorts/qZwrc75VdZk

*Film: trzy rozmowy w 38 sekund, nowe auto, ślub nad morzem i przeprowadzka do kupionego domu.*

„**Marzy mi się ślub nad brzegiem morza**”. Takie pytanie mieszkaniec może zadać asystentowi własnymi słowami. Nie musi znać nazwy formularza, symbolu procedury ani właściwego wydziału.

Asystent dopytuje, czy chodzi o ślub cywilny przed kierownikiem Urzędu Stanu Cywilnego, czy o ślub wyznaniowy ze skutkami cywilnymi. To ważne rozróżnienie: podobny opis planowanej uroczystości może prowadzić do różnych informacji urzędowych. Doprecyzowanie pozwala poprowadzić odpowiedź właściwą ścieżką i wskazać odpowiednie materiały.

Ten przykład pokazuje praktyczną wartość asystenta: **człowiek opisuje zamiar swoimi słowami, a system pomaga przejść od codziennego języka do urzędowej informacji.**

*Ilustracja: Plansza z rozmową: pytanie „Ogarnęliśmy z szmulką nową furę, co dalej?” i dopytanie asystenta „Auto z Polski czy z zagranicy?”*

Podobnie wygląda pytanie o zakup domu i przeprowadzkę. Asystent w odpowiedzi wskazuje kilka powiązanych obszarów, między innymi meldunek, podatek od nieruchomości i odpady. Nie oznacza to automatycznego ustalenia wszystkich obowiązków konkretnej osoby. Oznacza pomoc w zorientowaniu się, od czego zacząć i gdzie szukać szczegółów.

*Ilustracja: Plansza z rozmową: pytanie „Kupiłem dom i się przeprowadzam. Co muszę załatwić w urzędzie?” i odpowiedź asystenta „Podatek od nieruchomości. Odpady. Meldunek.”*

## Jak działa RAG i jakich problemów nie rozwiązuje

RAG, czyli *Retrieval-Augmented Generation*, łączy wyszukiwanie informacji z generowaniem odpowiedzi. Zamiast prosić duży model językowy (LLM, od angielskiego *Large Language Model*) o odpowiedź z jego ogólnej wiedzy, dostarczamy mu materiały związane z pytaniem. W naszym przypadku są to udostępnione systemowi i odpowiednio dobrane treści urzędu.

W typowym rozwiązaniu dokumenty dzieli się na fragmenty i tworzy ich reprezentacje liczbowe, nazywane embeddingami lub „wektorami”. Dzięki nim wyszukiwarka potrafi odnajdywać podobne znaczeniowo treści, nawet gdy użytkownik nie powtarza słów z dokumentu. Wybrane materiały trafiają następnie do modelu językowego jako kontekst odpowiedzi. Przystępnie opisuje to Anthropic w tekście o [Contextual Retrieval](https://www.anthropic.com/engineering/contextual-retrieval).

Można wyobrazić sobie embeddingi jako mapę znaczeń. „Wesele”, „ślub” i „ceremonia” mogą znaleźć się w podobnej okolicy tej mapy, choć są innymi słowami. Dzięki temu pytanie napisane potocznym językiem może prowadzić do dokumentu zatytułowanego „Zawarcie małżeństwa”. To istotna zmiana wobec wyszukiwania opartego wyłącznie na zgodności słów: szukamy także podobieństwa znaczenia całych wypowiedzi, a nie tylko tych samych liter.

Ta analogia ma jednak granicę: bliskość na mapie nie oznacza tożsamości spraw. Wesele nie jest tym samym co zawarcie małżeństwa, a ślub cywilny i wyznaniowy mogą wymagać innych informacji. Właśnie dlatego dobry wynik wyszukiwania jest początkiem pracy systemu, nie jej końcem.

Na papierze wygląda to prosto. W praktyce trzeba rozwiązać trzy różne zadania: odnaleźć właściwe materiały, wybrać reguły pasujące do sytuacji użytkownika i przedstawić je bez zmiany znaczenia.

Warunek zapisany przy jednym formularzu nie musi obowiązywać przy drugim. Informacja znajdująca się w bazie nie pomoże, jeżeli nie trafi do kontekstu modelu. Z kolei samo umieszczenie właściwego dokumentu w kontekście nie przesądza, że model poprawnie go wykorzysta.

Dlatego **RAG nie jest jednym promptem ani samą bazą wektorową. Jest całym procesem, który trzeba umieć obserwować, testować i rozwijać.**

## Co zbudowaliśmy pod oknem rozmowy

Własny silnik aplikacji rozwijamy w Pythonie, z interfejsem programistycznym (API) opartym na FastAPI. Korzystamy z Qdrant do wyszukiwania w bazie wiedzy. Osobne modele tworzą reprezentacje znaczeniowe treści, oceniają dopasowanie znalezionych materiałów i generują odpowiedź. LiteLLM pośredniczy w dostępie do usług modeli, a Langfuse służy do rejestrowania i analizowania przebiegu działania.

W szerszym środowisku projektu są również wdrożone n8n, związane z automatyzacją i zasilaniem wiedzy, oraz narzędzia z interfejsem webowym, zapewniające pracownikom dostęp do modeli. Publiczne okno Wirtualnego Asystenta jest odrębnym, dedykowanym interfejsem przeglądarkowym. Rozróżnienie jest istotne: środowisko pracy urzędnika i informacyjny asystent mieszkańca mają inne zadania i pracują w odseparowanych środowiskach.

Modułowa architektura, dostęp do kodu i dokumentacja oznaczają brak vendor lock-in, czyli przymusowego uzależnienia od jednego dostawcy. Miasto może rozwijać usługę bez budowania od nowa całej aplikacji, organizacji wiedzy i zaplecza testowego. Tę samą zasadę stosujemy u siebie, o czym piszemy w innych tekstach na blogu.

### Najpierw porządkujemy wiedzę

Procedura, formularz i odpowiedź FAQ nie są tym samym rodzajem informacji. W strukturze danych rozdzielamy treść główną, załączniki oraz dodatkowe materiały, zachowując powiązania między nimi. Dokumenty mają identyfikatory, tytuły i adresy źródeł. Załącznik pozostaje przypisany do właściwej procedury.

Daje to możliwość wyszukania odpowiedniego opisu sprawy, a następnie dobrania potrzebnych szczegółów. Samo mechaniczne pocięcie wszystkich plików na jednakowe fragmenty nie wystarcza do zachowania tych relacji. Równie istotne jak treść są informacje o tym, czego ona dotyczy i skąd pochodzi.

Punktem wyjścia były dobrze przygotowane materiały Biura Obsługi Interesantów (BOI): uporządkowane, ponumerowane procedury o powtarzalnej strukturze. **To duży wkład zespołu urzędu w ten projekt.** Stała struktura ułatwia zachowanie związku między opisem sprawy, formularzem i odpowiedzialną jednostką.

Nawet tak dobry materiał wymaga pracy, gdy ma zasilać rozmowę z AI. Wspólnie doprecyzowywaliśmy opisy, uzupełnialiśmy informacje i dodawaliśmy FAQ odpowiadające na pytania zadawane codziennym językiem. **Umiejętność przygotowania wiedzy jest równie ważną kompetencją wdrożeniową jak budowa oprogramowania, które z niej korzysta.**

### Pytanie przetwarzamy w kontekście rozmowy

„A ile to kosztuje?” nie jest samodzielnym zapytaniem. System musi ustalić, do czego odnosi się „to”. Dlatego rozwijamy obsługę historii rozmowy i przeformułowania pytania na potrzeby wyszukiwania.

W jednej rozmowie użytkownik może najpierw pytać o opłaty związane z użytkowaniem wieczystym, a chwilę później o rejestrację nowego auta. W drugim pytaniu system powinien rozpoznać zmianę tematu i nie przenosić do odpowiedzi założeń dotyczących nieruchomości. Obsługa historii to zatem nie samo „pamiętanie rozmowy”, lecz także wybór tego, co nadal jest istotne, zwłaszcza że zbyt długa i szeroka historia zwiększa prawdopodobieństwo halucynacji.

Wyszukiwanie może obejmować zarówno oryginalne pytanie, jak i jego doprecyzowany wariant. Wyniki są łączone, a powtarzające się materiały usuwane. Osobne ścieżki obejmują procedury, FAQ i informacje ogólne udostępnione systemowi.

### Oddzielamy wyszukiwanie od wyboru materiałów

Wyszukiwarka znajduje kandydatów. Reranker można porównać do osoby, która szybko przegląda przyniesioną z archiwum stertę teczek i układa najbardziej obiecujące na górze. Jest wyspecjalizowany w ocenie związku pytania z dokumentami, nie w przygotowaniu całej odpowiedzi dla mieszkańca. Potrafi uwzględniać znaczenie i kontekst, więc nie jest tylko sorterem podobnie wyglądających zdań.

Ranking nadal może być mylący. Dokument o zbliżonej terminologii może trafić wysoko, mimo że dotyczy innego uprawnienia albo innego rodzaju wniosku. Wysoka ocena oznacza „warto sprawdzić ten materiał”, a nie „te zasady na pewno dotyczą tej osoby”. **Reranker wybiera kandydatów do odpowiedzi; nie zastępuje sprawdzenia, czy znalezione reguły pasują do sytuacji.**

Następnie system dołącza potrzebny kontekst, w tym powiązane załączniki, i przygotowuje wejście dla modelu generującego odpowiedź.

Nie każda rozmowa wymaga identycznej ścieżki. W kodzie przewidziane są warianty pomijające dodatkowy ranking, a także kontrolowane ponowienia wyszukiwania. To decyzje o jakości, czasie i koszcie, a nie konkurs na największą liczbę wywołań AI.

### Jak łączymy przetwarzanie informacji z bezpieczeństwem

Bezpieczeństwo nie jest pojedynczą instrukcją „odpowiadaj bezpiecznie”. Kod obejmuje kontrolę wielkości i struktury wejścia, ograniczenia częstotliwości zapytań, rozpoznawanie prób manipulowania instrukcjami oraz mechanizmy ograniczające przeciążenie. Inna warstwa dotyczy dostępu do zaplecza, rejestrów i zewnętrznych usług.

*Ilustracja: Schemat działania Wirtualnego Asystenta: przygotowanie wiedzy, obsługa pytania w siedmiu krokach, granica usług zewnętrznych, warstwy bezpieczeństwa oraz osobna pętla rozwoju jakości*

*Schemat ról i granic przetwarzania. Ocena jakości przez sędziów AI i ludzi odbywa się w osobnej pętli; nie oznacza zatwierdzania każdej odpowiedzi przed jej wyświetleniem.*

Publiczny asystent nie ma dostępu do akt indywidualnych spraw ani narzędzi do wykonywania czynności urzędowych. To ważne ograniczenie zakresu: nie powierzamy modelowi decyzji, do których danych albo działań powinien mieć uprawnienia. Krytyczne ograniczenia trzeba egzekwować w aplikacji i infrastrukturze, a nie tylko w prośbie zapisanej w prompcie. Taką zasadę opisuje również OWASP w materiale o [wycieku promptu systemowego (LLM07:2025)](https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/).

Żadna z tych warstw nie gwarantuje pełnej odporności. Ich skuteczność sprawdzamy w testach bezpieczeństwa równolegle do testów merytorycznych.

## Najważniejsza lekcja: sposób testowania też trzeba testować

Początkowo naturalnym punktem odniesienia jest odpowiedź wzorcowa: zapisujemy, co asystent powinien powiedzieć, i porównujemy z tym wynik. Taka referencja jest przydatna, ale nie opisuje wszystkich poprawnych zachowań.

Jeżeli pytanie jest niejednoznaczne, właściwą reakcją może być dopytanie. Jeżeli dostępne materiały nie pozwalają odpowiedzieć, rzetelna informacja o tym jest lepsza niż dopisanie brakujących zasad. Z drugiej strony odmowa nie jest sukcesem, gdy odpowiedź znajduje się w źródłach, a intencja użytkownika jest jasna.

Rozwijany przez nas zestaw, który wewnętrznie nazywamy „tricky” ;-), pozwala zapisywać takie oczekiwania w postaci scenariuszy. Autor określa pytania, dopuszczalny sposób reakcji, wymagane lub niedopuszczalne elementy odpowiedzi oraz źródła. Przypadek może obejmować warianty sformułowania, powtórzenia i rozmowę złożoną z kilku tur.

Ważna jest również forma współpracy. Przypadki można opisywać w arkuszu, bez zmieniania kodu aplikacji. Osoba znająca procedurę może wskazać, co ma znaczenie merytoryczne; inżynier może przełożyć to na odtwarzalny test.

Automatyczne reguły pomagają sprawdzać jednoznaczne elementy, a przypadki wymagające interpretacji mogą trafić do sędziów AI. Narzędzie przewiduje także skierowanie rozbieżnych ocen do człowieka. Nie zastępuje to jednak weryfikacji samych kryteriów: również odpowiedź wzorcowa może być nieaktualna lub błędna.

**Lepszy wynik po zmianie sędziego nie jest jeszcze dowodem, że poprawiliśmy asystenta.** Może oznaczać, że zaczęliśmy trafniej oceniać jego dotychczasowe zachowanie.

### Z BOI wypracowaliśmy wspólny język oceny

Równolegle zmieniał się sposób wymiany uwag między zespołami. Początkowo sama ocena negatywna sygnalizowała, że odpowiedź wymaga uwagi, ale nie wyjaśniała, co należy poprawić. Potrzebowaliśmy komentarza: czy pomylono procedurę, pominięto warunek, czy odpowiedź była po prostu mniej pomocna, niż mogłaby być?

Pojawiło się też ważne rozróżnienie: pracownik urzędu ma wiedzę i doświadczenie wykraczające poza opublikowany opis sprawy. Może udzielić pełniejszej odpowiedzi, ale asystent nie powinien sam dopowiadać informacji, których nie otrzymał. Gdy ekspert wskazuje takie uzupełnienie, powstaje zadanie dla bazy wiedzy, nie automatycznie dla prompta. Nie obniżamy w ten sposób wymagań. Ustalamy, w którym miejscu trzeba je spełnić.

Z czasem doszliśmy do zgłoszeń łączących konkretne pytanie, odpowiedź, wskazanie brakującej lub błędnej informacji oraz właściwe źródło albo propozycję uzupełnienia. To pozwalało odtworzyć sytuację i rozdzielić pracę merytoryczną od technicznej.

| Informacja w zgłoszeniu | Co pozwala ustalić |
|---|---|
| Pytanie i przebieg rozmowy | Jaką sytuację opisał użytkownik i co było już wyjaśnione? |
| Konkretna uwaga do odpowiedzi | Co jest błędne, czego brakuje albo co niepotrzebnie utrudnia rozmowę? |
| Właściwe źródło lub proponowane uzupełnienie | Czy poprawiamy dobór materiałów, ich wykorzystanie, czy samą bazę wiedzy? |
| Oczekiwany sposób reakcji | Po czym w kolejnym teście poznamy, że zmiana pomogła? |

BOI było wymagającym partnerem: przy dobrej, proaktywnej współpracy jasno wskazywało, które zachowania nie spełniają oczekiwań. Wypracowanie wspólnego języka zajęło istotną część projektu. To jedno z najcenniejszych doświadczeń, które wnosimy do kolejnych wdrożeń. Dzisiaj zaczęlibyśmy od tego standardu, zamiast dochodzić do niego dopiero podczas testowania.

## Sędzia AI potrzebuje więcej niż pytania i odpowiedzi

W toku prac wykonaliśmy tysiące prób odpowiedzi. W codziennym cyklu rozwoju korzystaliśmy m.in. z pakietów rzędu stu pytań dotyczących bezpieczeństwa i podobnej liczby scenariuszy merytorycznych. Wielkość i skład serii zmieniały się wraz z etapem projektu; powtórzenie pytania jest kolejną próbą, a nie nowym, unikalnym scenariuszem.

Po zmianie źródeł, prompta, modelu albo logiki wyszukiwania trzeba sprawdzić poprawiany przypadek i upewnić się, że inne odpowiedzi się nie pogorszyły. To testowanie regresji. Ręczna ocena całej takiej serii po każdej zmianie byłaby zbyt wolna, dlatego do hurtowej oceny wykorzystujemy sędziów AI, czyli modele uruchamiane z jasno określonymi kryteriami.

Automatyzacja nie zastąpiła pracy ludzi. Pracownicy BOI i nasi testerzy analizowali konkretne rozmowy, rozstrzygali niejednoznaczne oceny i wskazywali poprawki. Sędzia pomaga objąć kontrolą dużą liczbę prób; ekspert ustala, co w danej sprawie znaczy dobra odpowiedź.

Najbardziej użyteczna ocena nie kończy się na etykiecie „dobrze” albo „źle”. Powinna wskazać, na którym etapie powstała różnica między oczekiwanym a rzeczywistym działaniem. Nasze doświadczenia prowadzą do pięciu uzupełniających się kontroli.

**Kontekst odpowiedzi.** Sprawdzamy, czy w materiałach rzeczywiście przekazanych generatorowi była podstawa do odpowiedzi. Jeżeli tak, analizujemy jej wykorzystanie. Jeżeli nie, trzeba przyjrzeć się wyszukiwaniu, kompletności bazy lub zasadności odmowy. To inne zadania naprawcze. Brak pełnego zapisu kontekstu nie pozwala tej kwestii rzetelnie rozstrzygnąć.

**Dobór i ranking źródeł.** Interesuje nas dokument wskazany w końcowej odpowiedzi, ale też to, jakie materiały były kandydatami i które odrzucono. Wynik podobieństwa wektorowego i wynik rerankera pochodzą z różnych etapów. Żaden z nich nie jest procentowym prawdopodobieństwem poprawności całej odpowiedzi.

**Powtarzalność.** To samo pytanie uruchamiamy wielokrotnie w niezależnych sesjach. Sprawdzamy stabilność istotnych informacji i sposobu reakcji, a nie identyczność każdego zdania. Pojedyncza udana demonstracja nie zastępuje takiego testu.

**Odporność na parafrazy.** Osobno sprawdzamy różne sformułowania tej samej intencji. „Jak zgłosić…?” i „Co muszę zrobić po…?” mogą wymagać sięgnięcia do tych samych materiałów. To inny test niż ponawianie identycznego pytania.

**Przebieg rozmowy.** Dobre dopytanie jest początkiem, nie końcem scenariusza. System powinien wykorzystać odpowiedź użytkownika w kolejnej turze i nie prosić ponownie o podane już informacje. Ocenie podlega również to, czy kolejne wiadomości prowadzą do użytecznej pomocy.

Nie wszystko wykonuje pojedynczy „sędzia”. Powtórzenia i warianty uruchamia narzędzie testowe; przebieg wyszukiwania analizujemy na podstawie zapisów działania; interpretację odpowiedzi wspierają modele i eksperci.

Obsługę wariantów, powtórzeń, rozmów oraz wybranych kontroli źródeł mamy już w narzędziach. **Pełne włączenie rzeczywistego kontekstu generatora do automatycznej oceny semantycznej jest kolejnym kierunkiem rozwoju metodyki.** Nie utożsamiamy obecnych kontroli z kompletnym, automatycznym audytem każdej odpowiedzi.

Podobne znaczenie łączenia oceny automatycznej, przeglądu ekspertów i obserwacji działania usługi opisuje [zespół GOV.UK Chat](https://insidegovuk.blog.gov.uk/2026/05/15/developing-gov-uk-chat-our-data-science-and-ai-engineering-journey/). To dobre odniesienie dla sposobu prowadzenia projektu, nie wspólny ranking skuteczności różnych chatbotów.

## Jakość, użyteczność, czas i koszt muszą być widoczne osobno

Asystent odmawiający odpowiedzi na każde pytanie mógłby unikać wielu pomyłek, ale nie spełniałby swojego zadania. Dlatego obok poprawności trzeba mierzyć zakres rzeczywistej pomocy. Podobnie bardziej rozbudowana odpowiedź nie musi być lepsza, jeżeli wymaga długiego oczekiwania albo zawiera zbędne informacje.

Standard oceny, do którego rozwijamy metodykę, obejmuje następujące miary:

| Co oceniamy | Co konkretnie chcemy wiedzieć |
|---|---|
| Poprawność i kompletność | Ile ocenionych scenariuszy spełnia wymagania merytoryczne? Istotne błędy raportujemy osobno, zamiast ukrywać je w średniej. |
| Użyteczność | Czy użytkownik otrzymał pomoc? Rozróżniamy potrzebne i zbędne dopytania oraz odmowy. |
| Stabilność | Czy powtórzenia i parafrazy zachowują najważniejsze informacje i właściwy sposób reakcji? |
| Czas rozmowy | Jaka jest mediana i p95 czasu odpowiedzi oraz ile tur wymaga uzyskanie pomocy? p95 pokazuje granicę, której nie przekracza 95% zmierzonych czasów. |
| Koszt obsługi | Ile kosztuje cały przebieg, razem z dodatkowymi wywołaniami i ponowieniami, także tymi bez użytecznego rezultatu? |
| Dostępność i oceny użytkowników | Jak często można skorzystać z usługi i jak jest odbierana? Awaria nie jest bezpieczną odmową, a pozytywna ocena nie jest dowodem poprawności. |

Celem rozwoju usługi jest osiąganie 90–95% pozytywnie ocenionych scenariuszy z jej zakresu. Pozytywny wynik wymaga poprawnej, wystarczająco kompletnej i użytecznej pomocy, także po potrzebnym doprecyzowaniu pytania. **Jest to cel rozwoju, nie deklaracja osiągniętego wyniku ani gwarancja dotycząca każdej rozmowy.** Wynik musi być publikowany wraz z zakresem testu, liczbą scenariuszy i sposobem oceniania.

Kolejne wersje należy porównywać przy tych samych kryteriach i znanych wersjach modelu, źródeł oraz konfiguracji. Test kilku szczególnie trudnych pytań służy diagnozie konkretnych zachowań. Nie opisuje automatycznie jakości wszystkich rozmów mieszkańców.

Dodatkowa kontrola lub ponowienie generowania wymagają obliczeń. Nie wynika z tego jednak, że każda poprawa jakości musi wydłużać odpowiedź i podnosić koszt. Lepszy dobór treści albo usunięcie zbędnego wywołania może poprawić kilka miar jednocześnie. Właśnie takich zmian szukamy w pierwszej kolejności.

*Ilustracja: Grafika „Szybko, dobrze, tanio. Wybierz dwa?” z trzema polami: krótki czas, użyteczna odpowiedź, niski koszt, oraz podpisem „Najpierw sprawdź, czy nie robisz trzech zbędnych wywołań modelu”*

*Ten znany żart projektowy jest ciągle aktualny.*

## Czasem najlepszą poprawką jest lepszy opis sprawy

Jednym z najważniejszych wniosków z projektu jest większy nacisk na materiały źródłowe. Model nie powinien sam rozstrzygać sprzeczności między opisami ani dopowiadać warunku, którego nie zapisano.

Gdy widzimy powracającą niejasność, warto sprawdzić, czy należy rozdzielić podobne procedury, doprecyzować wyjątek, uporządkować załączniki lub dopisać FAQ sformułowane językiem użytkownika. Taką zmianę trzeba uzgodnić merytorycznie, a potem ponownie przetestować jej wpływ na odpowiedzi.

Dopisywanie kolejnych wyjątków do ogólnej instrukcji modelu bywa szybkie, lecz poprawka jednego przypadku może zmienić zachowanie w innych sprawach. Nie rezygnujemy z pracy nad promptem. Chcemy jednak, aby reguły odpowiadania pozostawały możliwie ogólne, a wiedza o sprawach znajdowała się przede wszystkim we właściwych źródłach.

Przy okazji testów udało się również wychwycić drobne nieścisłości w materiałach źródłowych i wspólnie je wyjaśnić. To dodatkowy efekt systematycznego zadawania pytań na różne sposoby. Przegląd z perspektywy rozmowy z mieszkańcem pozwala zauważyć szczegół, który wcześniej nie wymagał doprecyzowania.

Ta praca ma dodatkową wartość: poprawiona informacja pomaga nie tylko asystentowi. Korzystają z niej także mieszkańcy czytający stronę i pracownicy, którzy na co dzień wyjaśniają zasady załatwiania spraw.

## Współpraca z urzędem jest częścią rozwiązania

W projekcie spotykają się kompetencje inżynierów inProjects, Biura Obsługi Interesantów i Wydziału Informatyki (WI). BOI współtworzy standard merytoryczny, WI zapewnia współpracę przy środowisku i integracji, a inProjects łączy te wymagania z działaniem oprogramowania. To proces wspólnego dochodzenia do właściwych decyzji, nie przekazanie „gotowej AI”, którą urząd ma po prostu zaakceptować.

*Ilustracja: Plansza „Zbudowane w Szczecinie”: Wirtualny Asystent e-Urzędu Miasta Szczecin, projekt, wdrożenie i utrzymanie inProjects we współpracy z BOI i Wydziałem Informatyki UMS, pilotaż do 31.12.2026*

Ważna lekcja dla kolejnych wdrożeń: granice technologii i kryteria odbioru trzeba uzgodnić na początku. Nie wystarczy ostrzeżenie, że AI może się mylić. Potrzebne są zasady zgłaszania uwag, odpowiedzialność za aktualność treści i sposób sprawdzania, czy zmiany rzeczywiście pomagają. Również zmiana modelu po stronie dostawcy wymaga czujności: testy nie kończą się z dniem odbioru aplikacji.

## Kontrola nad usługą dziś, możliwość lokalnych modeli jutro

Obecne rozwiązanie jest hybrydowe: aplikacja, baza wiedzy i rejestry działania pracują w infrastrukturze miasta, a generowanie odpowiedzi i część przetwarzania treści wykorzystują zewnętrzne usługi AI.

Zgodnie z przyjętym modelem współpracy dostawcom API przekazujemy tylko treści potrzebne do obsługi danego etapu: pytanie, potrzebną historię i wybrane materiały. Adresy IP użytkowników oraz dane kont pracowników nie są dołączane do tych wywołań. Nie jest to jednak gwarancja, że użytkownik sam nie wpisze danych osobowych w wiadomości. Dlatego prosimy, aby tego nie robić.

**Rozwijamy usługę, ale nie trenujemy obcego modelu AI na rozmowach.** Nasza praca polega na poprawianiu źródeł, logiki aplikacji i testów. Zasady przetwarzania danych opisuje informacja dla użytkowników udostępniana przez urząd.

Rozdzielenie komponentów tworzy drogę do wykorzystania modeli uruchamianych w Szczecinie lub w polskiej infrastrukturze. Taka zmiana wymaga jednak dobrania zasobów, integracji i ponownej oceny jakości. Samo przeniesienie generatora nie lokalizuje jeszcze całego systemu: trzeba uwzględnić również embeddingi, reranking i pozostałe zależności.

Podobnie techniczna możliwość zmiany modelu nie oznacza identycznego zachowania po jego wymianie.

## Przyszłość RAG: najpierw wiedzieć, gdzie szukać

Z naszego doświadczenia wynika, że przyszłość takich asystentów nie sprowadza się do wymiany modelu na coraz większy. Ważniejszy staje się wybór miejsca i sposobu szukania informacji, zanim powstanie odpowiedź.

Badanie [On the Theoretical Limitations of Embedding-Based Retrieval](https://arxiv.org/abs/2508.21038v2) pokazuje ograniczenia wyszukiwania, w którym pytania i dokumenty reprezentowane są pojedynczymi wektorami o ustalonej liczbie wymiarów. Nie dowodzi końca RAG ani nie wyznacza procentowego pułapu jakości naszego asystenta. Podważa natomiast założenie, że każdą trudność wyszukiwania rozwiąże większy model embeddingowy.

**Obiecującym kierunkiem jest system, który najpierw wybiera obszar wiedzy i plan poszukiwań, a dopiero potem pobiera konkretne treści.** Gdy użytkownik pyta o sprowadzone auto, model mógłby zacząć od katalogu spraw pojazdowych, rozróżnić rejestrację od innych formalności i sprawdzić właściwe procedury oraz ich załączniki. Gdy pytanie dotyczy przeprowadzki, mógłby zaplanować przeszukanie kilku obszarów, zamiast próbować zmieścić całą intencję w jednym zapytaniu.

To podejście przypomina korzystanie z dobrze opisanego archiwum: nie czytamy wszystkich teczek, lecz orientujemy się, na której półce mogą znajdować się potrzebne materiały. Nie oznacza rezygnacji z embeddingów. Wewnątrz wybranego obszaru nadal przydają się wyszukiwanie znaczeniowe, dokładne nazwy, identyfikatory i reranking. Anthropic opisuje podobne podejście w tekstach o [kontekstowym przygotowaniu fragmentów](https://www.anthropic.com/engineering/contextual-retrieval) i o [dobieraniu kontekstu na żądanie](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents).

*Ilustracja: Schemat kierunku rozwoju RAG: rozpoznanie zamiaru i mapa obszarów wiedzy, wybór obszarów (sprawy pojazdowe, przeprowadzka, inne formalności), wyszukiwanie we właściwych materiałach, sprawdzenie kompletności i odpowiedź; przy niepewności powrót do szerszego wyszukiwania*

*Kierunek rozwoju technologii RAG: najpierw wybór miejsca poszukiwań, potem szukanie treści.*

Dzisiaj mamy osobne ścieżki wyszukiwania i obsługę kontekstu rozmowy. Nie realizujemy jeszcze pełnego schematu nawigowania agenta po tematycznej mapie procedur. Taki krok wymaga sprawdzenia także nowych ryzyk: błędny wybór obszaru może odciąć właściwe źródło, a nadmierna liczba poszukiwań wydłużyć rozmowę. Dlatego nawigacja powinna dopuszczać kilka obszarów i powrót do szerszego wyszukiwania, a jej skuteczność podlegać tym samym testom co obecny system.

Nasza zasada pozostaje praktyczna: dodatkowa autonomia jest uzasadniona wtedy, gdy poprawia ważne scenariusze i mieści się w wymaganiach czasu, kosztu oraz bezpieczeństwa. Nie każda rozmowa potrzebuje bardziej rozbudowanego agenta. Podobnie stawia sprawę Anthropic w tekście [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents).

## Produkt, który rozwijamy również z myślą o kolejnych organizacjach

Wirtualny Asystent to dla inProjects własny silnik aplikacji, integracje z modelami, sposób organizowania wiedzy i narzędzia do dalszego rozwoju jakości. Projekt obejmuje również wdrożenie, dokumentację i utrzymanie. To rozwijany produkt, który możemy wdrażać w kolejnych organizacjach, dostosowując go do ich potrzeb.

Nie oznacza to kopiowania wiedzy urzędu do innych klientów ani obietnicy uruchomienia dowolnej bazy dokumentów bez przygotowania. Kolejna organizacja wnosi własne źródła, zasady i scenariusze odbioru. My wnosimy rozwijane oprogramowanie i doświadczenie zdobyte przy jego rzeczywistym wdrażaniu.

Podobną perspektywę mamy przy tworzeniu rozwiązań dla WERIN, naszej siostrzanej firmy budującej sieci światłowodowe. Patrzymy na technologię także jako użytkownicy własnych narzędzi. Punktem wyjścia jest zadanie do wykonania i osoba, która ma z rozwiązania korzystać, nie sam wybór modelu AI.

Dla mieszkańca najważniejsze jest to, że może zapytać własnymi słowami i otrzymać pomoc w odnalezieniu informacji. Dla urzędu: możliwość rozwijania usługi wspólnie z zespołem, który rozumie jej działanie. Dla kolejnego klienta: produkt oraz doświadczenie obejmujące znacznie więcej niż udaną demonstrację czatu.

*Ilustracja: Grafika konferencji AI-CONNECT 2026: „Widzimy się na konferencji AI-CONNECT 2026, The Human Edge in the Age of AI”, 23 września 2026, Filharmonia w Szczecinie, logo inProjects*

### Spotkajmy się na AI-CONNECT

23 września 2026 r. w Filharmonii w Szczecinie Wojciech Kozicki rozwinie te doświadczenia podczas wystąpienia „Skąd wiesz, że twoje AI nie kłamie? Wdrożenie w administracji publicznej, agenci w firmie i gdzie w tym wszystkim jest człowiek”. W [programie konferencji](https://ai-connect.pl/) prelekcja jest zaplanowana na 15:00–15:30 na scenie technologicznej.

**Planujesz asystenta dla swojej organizacji? [Porozmawiajmy](https://inprojects.ai/kontakt/) o zadaniach, źródłach wiedzy i sposobie mierzenia efektu. Na tej podstawie dobierzemy technologię i zakres wdrożenia.**

---

## Źródła i dalsza lektura

Opis projektu opiera się na dokumentacji, kodzie, materiałach testowych inProjects oraz doświadczeniach współpracy z Urzędem Miasta Szczecin, według stanu na 15 września 2026 r. Poniższe publikacje rozwijają wątki techniczne poruszone w artykule; nie są pomiarem skuteczności szczecińskiego systemu.

- [Urząd Miasta Szczecin: Szczecin uruchomił Wirtualnego Asystenta AI. Jak korzystać z bezpłatnego czatu w e-Urzędzie?](https://wiadomosci.szczecin.eu/artykul/mieszkancy/szczecin-uruchomil-wirtualnego-asystenta-ai-jak-korzystac-z-bezplatnego-czatu-w-e-urzedzie), komunikat z 15.09.2026
- [Anthropic: Introducing Contextual Retrieval](https://www.anthropic.com/engineering/contextual-retrieval), 19.09.2024
- [Government Digital Service: Developing GOV.UK Chat, our data science and AI engineering journey](https://insidegovuk.blog.gov.uk/2026/05/15/developing-gov-uk-chat-our-data-science-and-ai-engineering-journey/), 15.05.2026
- [Orion Weller i in.: On the Theoretical Limitations of Embedding-Based Retrieval](https://arxiv.org/abs/2508.21038v2), arXiv, wersja 2, 12.03.2026
- [Anthropic: Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), 29.09.2025
- [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents), 19.12.2024
- [OWASP: LLM07:2025 System Prompt Leakage](https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/), niezależne egzekwowanie kontroli dostępu
- [Program konferencji AI-CONNECT 2026](https://ai-connect.pl/)
- [inProjects: O nas](https://inprojects.ai/o-nas/)

*Zdjęcia na planszach: Dorota Kowalik, „Szczecin urzad miejski1” i „Szczecin urzad miejski2”, Wikimedia Commons, [CC BY 3.0](https://creativecommons.org/licenses/by/3.0/) (kadrowanie, przyciemnienie, napisy); Lacyec, [Unsplash](https://unsplash.com/license). Plansze, schematy i film: inProjects. Muzyka w filmie: „Make Funk”, HoliznaCC0, [CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/).*