Jak zbudować prywatnego asystenta AI na własnych danych: od przygotowania korpusu po wdrożenie w produkcji

Po co własny asystent AI, skoro są gotowe chatboty?

Kontrola, poufność i specyfika domeny

Publiczne chatboty ogólnego przeznaczenia świetnie sprawdzają się jako kalkulator tekstu: tłumaczenia, streszczenia, pisanie maili. Zaczynają się jednak sypać, gdy pojawia się pytanie: „Skąd ten model ma wiedzieć, jak my dokładnie to robimy?”. Własny asystent AI na własnych danych rozwiązuje trzy kluczowe problemy: poufność, specyfikę domeny i kontrolę nad odpowiedziami.

Przy danych firmowych dochodzi kwestia tajemnicy przedsiębiorstwa, danych osobowych, wewnętrznych procedur. Wysyłanie takiej treści do publicznego chatbota (zwłaszcza bez umowy powierzenia danych i bez jasnej polityki retencji) bywa po prostu nieakceptowalne prawnie lub wizerunkowo. Prywatny asystent AI może działać w ramach infrastruktury pod Twoją kontrolą – w Twojej chmurze, na Twoim serwerze, a nawet na jednym mocniejszym PC w biurze.

Drugi aspekt to wiedza domenowa. Model ogólny nigdy nie przeczytał Twojego regulaminu, procedury obsługi reklamacji czy repozytorium projektowego. Żeby odpowiadał poprawnie, musi dostać kontekst z konkretnych dokumentów. Tu wchodzi podejście „asystent AI na własnych danych”: model generuje odpowiedzi, ale bazuje na Twoim korpusie, a nie na przypadkowych źródłach z internetu.

Trzeci element to kontrola. Mając własną warstwę danych, możesz logować zapytania, odpowiedzi, źródła dokumentów, z których model skorzystał. Możesz też wymusić twarde ograniczenia: np. asystent nie ma prawa odpowiadać, jeśli nie znajduje wiarygodnych fragmentów w bazie (zamiast halucynować). Tego nie skonfigurujesz w prosty sposób w ogólnodostępnym czacie.

Czego nie zrobisz sensownie na publicznym chatbotcie

Proste kopiuj-wklej do ChatGPT czy innego chatbota bywa wystarczające przy małej ilości tekstu. Gdy jednak danych jest więcej niż kilka stron, takie podejście się rozsypuje. Przykłady zastosowań, które wymagają własnej warstwy danych:

• Obsługa dokumentów firmowych: instrukcje, regulaminy, polityki bezpieczeństwa, dokumentacja produktów, dokumentacja API.
• Kontekst projektów: historia decyzji, notatki ze spotkań, backlogi, opisy architektury, ADR-y (Architecture Decision Records).
• Wiedza domenowa: specyficzne przepisy branżowe, wiedza medyczna kliniki, procedury serwisowe producenta sprzętu, wewnętrzne standardy kodowania.
• Dane operacyjne: raporty incydentów, opisy problemów i ich rozwiązań, wewnętrzne FAQ pierwszej linii wsparcia.

Wysłanie całej takiej bazy jako jeden wielki zlepek tekstu do publicznego chatbota jest nierealne: ograniczenia długości kontekstu, czas, brak automatycznej aktualizacji, brak filtrowania po uprawnieniach. Prywatny asystent AI integruje się z Twoimi źródłami, aktualizuje indeks w tle i pozwala zadawać pytania „zawsze na świeżo”.

Osobisty asystent, mały zespół, większa organizacja

Architektura i koszty bardzo zależą od skali. Dobrze to przemyśleć, zanim wpadnie się w zbyt ciężki lub zbyt prymitywny stack.

Dla osoby lub mikrozespołu (1–5 osób) wystarczy często laptop/mini‑serwer + lekkie narzędzia open‑source. Można postawić jedną aplikację „chat z dokumentami” z prostym interfejsem webowym, wrzucić kilkadziesiąt PDF i DOCX, podpiąć tani model w chmurze albo mały lokalny model z kwantyzacją. Ważniejsze jest szybkie wdrożenie niż perfekcyjna skalowalność.

Dla małego zespołu (5–50 osób) robi się już temat dostępów i utrzymania. Przyda się centralny serwer (VPS lub mała instancja w chmurze) z reverse proxy, autoryzacją (SSO, LDAP, przynajmniej loginy) i prostym mechanizmem ról. Wciąż da się korzystać z SaaSowych API LLM, ale korpus dokumentów i embeddingi lepiej trzymać w swojej bazie wektorowej.

Większa organizacja potrzebuje już integracji z systemami uprawnień, logowania audytowego, wersjonowania dokumentów i być może kilku osobnych asystentów AI dla różnych działów. Na tym poziomie typowe jest osobne środowisko testowe i produkcyjne, pipeline CI/CD i kontrola zmian. Koszty rosną, ale rośnie też zysk czasowy, bo asystent przejmuje dużą część powtarzalnych pytań od pracowników i klientów.

Zestaw minimalnych funkcji prywatnego asystenta

Aby projekt miał sens biznesowy i nie zamienił się w zabawkę, warto celować w „zestaw minimalny”, zamiast budować od razu kosmicznie rozbudowany system:

• Pytania o dokumenty: użytkownik może zapytać „Jak wygląda procedura X?” i dostaje odpowiedź z linkami/fragmentami źródłowych dokumentów.
• Logi decyzji: możliwość późniejszego sprawdzenia, jakie fragmenty dokumentów były podstawą odpowiedzi asystenta, co padło w pytaniu i jaka była treść odpowiedzi.
• Prosty interfejs czatu: przeglądarka, pole na pytanie, obszar z odpowiedzią, przycisk „pokaż źródła”. Bez wodotrysków, ale stabilnie.
• Podstawowe uprawnienia: chociażby podział na przestrzenie: publiczna (np. dokumenty dla całej firmy) i prywatna (np. dla danego działu/projektu).
• Możliwość aktualizacji korpusu: łatwy sposób dodawania nowych dokumentów i reindeksacji, najlepiej w dużej mierze zautomatyzowany.

Ścieżki realizacji: od no‑code po własny stack

Praktycznie da się przyjąć trzy poziomy zaawansowania:

1. Low‑code / no‑code – gotowe platformy „chat z dokumentami”, gdzie wrzucasz PDF-y, łączysz się z chmurą LLM (lub korzystasz z wbudowanej) i dostajesz prosty interfejs czatu. Plusy: błyskawiczny start, brak DevOps. Minusy: ograniczona kontrola, słabsza integracja z systemami uprawnień, często wyższe koszty przy większej skali.

2. Składanie z klocków (API + wektory) – najczęściej najbardziej opłacalna opcja przy niewielkim zespole technicznym. Używasz API LLM (OpenAI, Anthropic, itp.), sam tworzysz embeddingi (SaaS lub open‑source), trzymasz je w wektorowej bazie danych. Warstwę aplikacji (backend + prosty frontend) piszesz w Pythonie, Node, Go albo używasz lekkiego frameworka. Dobrze się skaluje, ma rozsądne koszty i da się utrzymać bez całego działu SRE.

3. Własny stack open‑source – pełen self‑host: serwer(y) z modelem LLM (np. Llama, Mistral, Qwen), lokalna baza wektorowa, własne embeddingi. Duża niezależność, pełna kontrola nad danymi, ale rosną wymagania sprzętowe i kompetencyjne. Ma sens, gdy masz ścisłe wymagania prawne/poufnościowe lub duży wolumen zapytań i chcesz uniknąć opłat za API.

Jakie typy danych nadają się do asystenta i czego unikać

Typowe źródła i te z najwyższym zwrotem

Większość organizacji tonie w dokumentach. Nie wszystkie nadają się na pierwszy wsad do asystenta AI. Najczęstsze źródła:

• PDF: umowy, instrukcje, raporty, prezentacje eksportowane do PDF.
• DOCX/ODT: regulaminy, polityki, specyfikacje, szablony.
• Maile: potwierdzenia decyzji, dyskusje merytoryczne, ustalenia z klientami.
• Systemy ticketowe: Jira, ServiceNow, Zendesk, własne helpdeski – zgłoszenia, rozwiązania, notatki.
• Wiki i bazy wiedzy: Confluence, Notion, GitHub Wiki i podobne narzędzia.
• Pliki kodu: repozytoria Git – szczególnie README, ADR, komentarze, dokumentacja API.
• Arkusze: Excel, Google Sheets – rejestry, tabele konfiguracji, parametry systemów.

Z perspektywy efektu względem wysiłku najbardziej opłacają się dane, które już pełnią funkcję „manuala” dla ludzi:

• FAQ i bazy wiedzy supportu – pytania/odpowiedzi klientów, wewnętrzne notatki działu wsparcia.
• Procedury i checklisty – krok po kroku, co robić w danej sytuacji (np. przy incydencie, reklamacji, wdrożeniu klienta).
• Regulaminy i polityki – asystent może tłumaczyć z „prawniczego” na „ludzki” język z zachowaniem zgodności z oryginałem.
• Repozytoria projektów – decyzje projektowe, architektura, opis integracji z innymi systemami.

To jest złoto: treści już uporządkowane, merytoryczne, wielokrotnie wykorzystywane. Przeniesienie ich do asystenta oznacza realne oszczędności czasu, bo ludzie przestają szukać po dziesięciu systemach albo wypytywać kolegów.

Dane wysokiego ryzyka i kiedy je włączać

Są dane, które kuszą, by je wrzucić do asystenta, ale niosą poważne ryzyka prawne, wizerunkowe i bezpieczeństwa:

• Dane osobowe (imię, nazwisko, adres, PESEL, dane kontaktowe).
• Dane medyczne, informacje o zdrowiu.
• Dane finansowe: numery kont, szczegóły transakcji, raporty finansowe przed publikacją.
• Tajemnice przedsiębiorstwa: plany strategiczne, niepubliczne oferty, pełne kody źródłowe krytycznych systemów.

Dla budżetowego, pragmatycznego podejścia sensownie jest zacząć od danych niskiego ryzyka, które i tak są już dostępne szeroko w organizacji: polityki, FAQ, instrukcje, dokumentacja produktów. Dopiero po udowodnieniu, że asystent działa stabilnie, można myśleć o włączaniu danych wrażliwych – ale pod warunkiem:

• jasnego modelu uprawnień (kto co może widzieć),
• szyfrowania danych w spoczynku i w transmisji,
• kontroli tego, czy dane nie trafiają poza Twoją infrastrukturę (np. do zewnętrznego dostawcy LLM bez umowy),
• zgodności z RODO / lokalnymi regulacjami.

Często bardziej opłaca się na stałe wyłączyć najbardziej wrażliwe dane z asystenta i pozostawić je klasycznym, dobrze zabezpieczonym systemom, niż rozbudowywać architekturę AI tylko po to, by obsłużyć 5% rzadkich zapytań.

Struktura danych a koszty pipeline’u

Im lepiej ustrukturyzowane dane, tym tańsze przetwarzanie i mniejsze frustracje. Dokumenty z nagłówkami, spisami treści, logicznymi sekcjami da się łatwo pociąć na sensowne fragmenty i zaindeksować. Zbiorcze, chaotyczne notatniki bez formatowania sprawiają więcej kłopotów niż są warte.

Dobrą praktyką jest dążenie do prostego standardu:

• Każdy dokument ma tytuł, autora, datę, wersję.
• Struktura opiera się na nagłówkach H1–H3 (w Word/Markdown/Notion odpowiedniki).
• Rozdziały i podrozdziały dotyczą jednego, wyraźnie określonego tematu.

Nawet lekkie uporządkowanie źródeł przed zasileniem asystenta pozwala zredukować ilość „brudnej pracy” w kodzie parserów i skryptów ETL. Zamiast pisać dziesiątki wyjątków dla egzotycznych formatów, można skupić się na kilku dominujących wzorcach.

Ograniczenie zakresu na start

Najczęstsza pokusa: „Zróbmy asystenta do wszystkiego”. Efekt: rozmyty korpus, niespójne odpowiedzi, trudne debugowanie. Lepiej jest wybrać jeden konkretny obszar, dla którego asystent przyniesie największą oszczędność czasu, np.:

• wewnętrzny helpdesk IT,
• procedury działu HR,
• dokumentacja jednego kluczowego produktu,
• standardy bezpieczeństwa i polityki.

Po zbudowaniu „pilota” w wąskiej domenie łatwiej dopracować pipeline, ocenić jakość odpowiedzi, dopisać brakujące funkcje i dopiero wtedy rozszerzać zakres. To tańsze i mniej bolesne niż porządkowanie całej historii firmy tylko po to, by 20% dokumentów realnie było wykorzystywane.

Modele, embeddingi, RAG – krótki, praktyczny fundament techniczny

Trening modelu vs RAG i dlaczego „doklejenie danych” wygrywa

Przy planowaniu asystenta pojawia się od razu słowo „trenowanie modelu”. W praktyce rzadko jest to potrzebne. Pełny trening lub nawet fine‑tuning dużych modeli językowych wymaga:

• mocnej infrastruktury (GPU, dużo RAM, szybka sieć),
• dużej ilości świetnie przygotowanych danych treningowych,
• sporego budżetu i czasu.

W większości zastosowań biznesowych dużo lepszy stosunek efektu do wysiłku daje strategia RAG (Retrieval Augmented Generation), czyli „doklejanie” Twoich danych do zapytań użytkownika w locie. Zamiast wtapiać całą wiedzę firmową w parametry modelu, trzymasz ją w osobnej bazie (najczęściej wektorowej), wyszukujesz najtrafniejsze fragmenty i przekazujesz je do LLM jako kontekst. To oznacza niższy koszt wdrożenia, krótszy czas eksperymentów i możliwość aktualizowania wiedzy praktycznie od ręki – bez żmudnego przeuczania czegokolwiek.

RAG ma jeszcze jedną przewagę: pozwala wymienić dowolny element stacku bez wywracania wszystkiego do góry nogami. Możesz zmienić model LLM (np. z API komercyjnego na open‑source), podmienić silnik wektorowy albo sposób chunkowania dokumentów, a reszta systemu nadal działa. W praktyce biznesowej, gdzie wymagania, budżet i polityka bezpieczeństwa lubią się zmieniać co kilka miesięcy, ta elastyczność często jest ważniejsza niż ostatnie kilka procent jakości odpowiedzi wyciśnięte z fine‑tuningu.

Fine‑tuning ma sens głównie w dwóch sytuacjach: gdy potrzebujesz bardzo specyficznego stylu i formatu odpowiedzi (np. generowanie raportów zgodnych z określonym szablonem) albo gdy asystent ma wykonywać nietypowe zadania, słabo reprezentowane w publicznych danych (np. wewnętrzny język poleceń, skróty, silnie domenowe słownictwo). Nawet wtedy rozsądniej jest zacząć od „tanich” metod: dopracowanego promptu, instrukcji systemowych, kilku przykładów w kontekście (few‑shot), ewentualnie lekkiego fine‑tuningu małego modelu zamiast od razu inwestować w molocha.

Prosty test opłacalności wygląda tak: jeżeli problemy jakościowe z odpowiedziami wynikają głównie z tego, że model „nie wie”, bo nie dostał właściwego fragmentu dokumentu, inwestuj w lepszy RAG (lepsze chunkowanie, filtry, reranking, aktualność indeksu). Jeżeli model dostaje poprawny kontekst, a i tak uparcie popełnia ten sam typ błędu (np. źle interpretuje Twoje wewnętrzne kategorie produktów), dopiero wtedy rozważ dedykowany fine‑tuning lub mały, wyspecjalizowany model pomocniczy.

Cały proces budowy asystenta na własnych danych dobrze traktować jak produkt, a nie jednorazowy projekt: zacząć od wąskiego zakresu, możliwie prostego stacku (API + wektory), kilku kluczowych źródeł wiedzy i sensownego monitoringu jakości odpowiedzi. Później, wraz ze wzrostem obciążenia i apetytu użytkowników, można dokładać kolejne elementy – lepszą segmentację dokumentów, uprawnienia per użytkownik, automatyczne odświeżanie indeksu, a na końcu ewentualnie własny, tańszy w utrzymaniu model. Dzięki temu zamiast jednego wielkiego, ryzykownego wdrożenia masz serię małych kroków, z których każdy realnie poprawia komfort pracy ludzi i nie przepala budżetu.

Dobór modelu LLM: „wystarczająco dobry” zamiast „najlepszy na rynku”

Pokusą jest ściganie się na benchmarki i wybieranie modelu, który ma o kilka punktów więcej w testach akademickich. W praktyce asystenta opartego o RAG znacznie ważniejsze są:

• koszt pojedynczego wywołania (token in/out),
• opóźnienie (czas odpowiedzi),
• dostępność i SLA dostawcy,
• łatwość późniejszej podmiany modelu.

„Wystarczająco dobry” model znanej chmurowej usługi zwykle daje najlepszy stosunek jakości do wysiłku. Modele top‑tier (najdroższe) opłacają się przy specyficznych scenariuszach: dużo generacji kreatywnych, skomplikowane podsumowania długich dokumentów, bardzo subtelne niuanse językowe. W wewnętrznym helpdesku IT czy asystencie do procedur HR często nie widać różnicy między „średnim” a „flagowym” modelem na tyle, by usprawiedliwić wyższy rachunek.

Dobry schemat na start:

• Użyć jednego, prostego w integracji modelu z API (OpenAI, Anthropic, Azure, itp.).
• Owinąć go własną, cienką warstwą abstrakcji (np. prostą klasą lub mikroserwisem).
• Przechowywać w konfiguracji kluczowe parametry: nazwa modelu, maksymalna liczba tokenów, temperatura.

Taka warstwa pośrednia pozwala podmienić dostawcę w jeden weekend zamiast przebudowywać pół systemu. Gdy asystent zacznie realnie zarabiać swój koszt, można myśleć o hybrydach: tańszy model domyślny + droższy tylko do trudnych zadań (wykrywanie przez router promptów, które wymagają „mocniejszego mózgu”).

Modele otwarte vs komercyjne: bezpieczeństwo kontra czas dostarczenia

Decyzja „open‑source czy SaaS” zwykle sprowadza się do kompromisu między kontrolą nad danymi a czasem dostarczenia rozwiązania. Pełne uruchomienie własnego modelu open‑source to:

• koszt GPU (chmura lub własny sprzęt),
• utrzymanie i aktualizacje,
• monitoring wydajności i awarii,
• często niższa jakość w porównaniu z topowymi modelami chmurowymi.

Rozsądny, budżetowy układ dla większości firm wygląda tak:

1. Faza pilotażowa – komercyjny model w chmurze, ograniczony korpus, brak danych wrażliwych. Szybkość jest najważniejsza, bo trzeba w ogóle sprawdzić, czy asystent ma sens.
2. Faza rozwoju – włączanie częściowo wrażliwych danych, twarde kontrole uprawnień, w razie potrzeby dodatkowe umowy z dostawcą (DPA, lokalizacja danych).
3. Faza dojrzała – jeżeli ruch i rachunki za API rosną dynamicznie, warto policzyć, czy własny/hostowany model open‑source (np. w Kubernetesie lub dedykowanym inference serverze) nie wyjdzie taniej w horyzoncie 12–24 miesięcy.

W wielu organizacjach kończy się hybrydą: krytyczne domeny i dane jadą przez model on‑prem albo w prywatnej chmurze, a mniej wrażliwe zastosowania (np. copywriting marketingowy, ogólne research) dalej korzystają z publicznego API.

Embeddingi: jak „spłaszczyć” wiedzę do liczb i nie przepalić budżetu

Embeddingi to wektorowe reprezentacje tekstu, na których operuje silnik wyszukiwania podobieństwa. W praktycznej implementacji asystenta liczą się trzy rzeczy: jakość, koszt i rozmiar wektora.

Droższe embeddingi nie zawsze oznaczają lepszy RAG. Przy przeciętnych dokumentach biznesowych (procedury, opisy produktów, wiki) modele średniej klasy radzą sobie wystarczająco dobrze. Dopiero przy bardzo gęsto technicznych lub prawniczych treściach opłaca się testować specjalizowane embeddingi.

Przy wyborze modelu embeddingów zwróć uwagę na:

Inspiracją dla takich „składanych” rozwiązań mogą być techniczne przewodniki z serwisów o AI i nowych technologiach, takich jak Pirat-Pirat.pl, gdzie mocno akcentuje się praktyczne podejście do stacku i kosztów.

• Wymiar wektora – im większy, tym potencjalnie lepsze rozróżnianie niuansów, ale też więcej RAM, większy indeks i wolniejsze zapytania.
• Koszt przeliczenia 1k tokenów – duży korpus + częste reindeksowanie to realna pozycja w budżecie.
• Dostępność wersji open‑source – pozwala uniezależnić się od jednego dostawcy w przyszłości.

Rozsądne podejście wygląda tak: na start jeden, stabilny model embeddingów od tego samego dostawcy, od którego bierzesz LLM. Gdy architektura się ustabilizuje, możesz przetestować alternatywy (np. mniejszy wymiar, model domenowy) na fragmencie indeksu i porównać jakość wyszukiwania na realnych pytaniach użytkowników.

Silnik wektorowy: od „SQLite świata wektorów” po klaster w chmurze

Baza wektorowa to miejsce, gdzie lądują embeddingi Twoich dokumentów. Na rynku jest wysyp narzędzi: wyspecjalizowane bazy wektorowe, wtyczki do klasycznych baz SQL/NoSQL, biblioteki lokalne. Z punktu widzenia budżetowego pragmatyka liczą się trzy kryteria:

• prostota operacyjna (kto to będzie utrzymywał i jak trudno to zepsuć),
• koszt zasobów (RAM, dysk, ewentualnie opłata SaaS),
• łatwość migracji do czegoś „poważniejszego”.

Na pilota rzadko jest sens stawiać klaster wyspecjalizowanej bazy wektorowej. Często wystarczy:

• lekka biblioteka uruchomiona lokalnie (np. FAISS, hnswlib) z prostym API,
• rozszerzenie istniejącej bazy (Postgres + rozszerzenie wektorowe),
• tani plan chmurowej bazy wektorowej, jeżeli nie chcesz niczego hostować.

Jedna tabela „documents”, druga „chunks” z wektorami, kilka kluczowych metadanych (źródło, data, typ dokumentu, ID uprawnień) i już można obsłużyć pierwszych użytkowników. Gdy liczba zapytań urośnie, dodajesz replikę, cache lub przechodzisz na dedykowane rozwiązanie – ale wtedy już wiesz, za co płacisz.

Prosty przepływ RAG krok po kroku

Bez względu na wybrany stack, klasyczny pipeline RAG sprowadza się do kilku kroków. Po stronie indeksowania (offline):

1. Pobierz dokumenty ze źródeł (API Confluence, eksport z Gita, pliki z dysku).
2. Przekonwertuj je do tekstu (parser PDF/Word/HTML, czyszczenie znaczników).
3. Podziel na fragmenty (chunkowanie) według zasad opisanych dalej.
4. Wylicz embeddingi dla każdego fragmentu.
5. Zapisz fragmenty + wektory + metadane w bazie wektorowej.

Po stronie zapytania użytkownika (online):

1. Przygotuj „oczyszczone” zapytanie (np. usuń szum typu „hej, mam pytanie”).
2. Wylicz embedding zapytania.
3. Wyszukaj N najbliższych fragmentów w bazie wektorowej z ewentualnymi filtrami (np. po dziale, języku, produkcie).
4. Zbuduj prompt: instrukcje systemowe + pytanie użytkownika + wybrane fragmenty jako kontekst.
5. Wywołaj LLM i zwróć odpowiedź, najlepiej z referencjami do źródeł (linki, tytuły dokumentów).

Ten schemat można później komplikować: reranking (drugie sortowanie wyników innym modelem), rozbijanie złożonych pytań na podzapytania, łączenie wyszukiwania pełnotekstowego z wektorowym. Na początek wystarczy jednak podstawowa wersja – kluczowe jest, żeby działała stabilnie i tanio.

Przygotowanie korpusu: selekcja, porządkowanie i sprytne minimum

Filtr „czy to ma szansę się kiedykolwiek przydać?”

Zanim zaczniesz pisać skrypty do integracji z każdym możliwym systemem, dobrze jest na sucho przejść przez listę potencjalnych źródeł danych z jednym pytaniem: „kiedy ostatnio ktoś potrzebował tego typu informacji?”. Jeśli odpowiedź brzmi „rok temu” albo „nie pamiętam”, wrzuć takie źródło na koniec kolejki.

W praktyce najlepiej pracuje się z prostą macierzą priorytetów. Dla każdego rodzaju zawartości oszacuj:

• częstotliwość użycia (jak często ktoś sięga po te informacje),
• koszt dostępu (czy trzeba coś zintegrować, czy da się wyeksportować pliki),
• stopień uporządkowania (czy struktura jest logiczna, czy to „zupa notatek”).

Dane, które ludzie oglądają codziennie, masz do nich prosty dostęp i są w miarę uporządkowane, wpadają do kategorii „MVP”. Chaotyczne zbiory z niskim użyciem – „może kiedyś”. Taki trzystopniowy podział (MVP / później / prawdopodobnie nigdy) pozwala zaoszczędzić tygodnie dłubania przy integracjach, które nie przyniosą zauważalnego efektu.

Ujednolicenie formatów: mniej magii w parserach

Jednym z cichych zabójców projektów RAG jest zoo formatów: PDF z drukarni, stary Word, HTML generowany przez archaiczny CMS, zrzuty ekranów w PNG. Każdy z nich wymaga innego podejścia. Zamiast pisać wyszukane parsowanie dla wszystkiego, lepiej ustalić prostą zasadę: „docelowy format to czysty tekst + podstawowe metadane”.

Praktyczny, tani w utrzymaniu schemat:

1. Wyodrębnij tekst narzędziami gotowymi: biblioteki do PDF/Office, API dostawców, eksport z wiki.
2. Na poziomie ETL przekształć całość do jednego prostego formatu – np. JSON z polami:
   • id,
   • title,
   • body (tekst),
   • headings (lista nagłówków),
   • source (system, z którego pochodzi),
   • metadata (dowolne dodatkowe pola).
3. Wszystkie późniejsze kroki (czyszczenie, segmentacja, embeddingi) pracują na tym jednym formacie.

Dzięki temu zmiana np. biblioteki do PDF uderza tylko w warstwę „importu”, a reszta pipeline’u zostaje nietknięta. Mniej sprzężenia, mniej niespodzianek.

Minimalne metadane, które zwracają się z nawiązką

Dodanie kilku podstawowych metadanych do każdego dokumentu kosztuje niewiele, a ułatwia połowę późniejszych problemów z filtrowaniem, bezpieczeństwem i prezentacją odpowiedzi. Zestaw na start może wyglądać tak:

• Źródło – nazwa systemu lub aplikacji (np. „Confluence”, „GitHub”, „SharePoint”).
• Dziedzina – 1–2 poziomy kategoryzacji (np. „HR / Onboarding”, „Produkt / API”).
• Data aktualizacji – pozwala odfiltrować stare treści albo przynajmniej oznaczyć je użytkownikowi.
• Język – szczególnie, gdy organizacja jest wielojęzyczna.
• Identyfikator właściciela/zespołu – do kierowania pytań, które wymagają interwencji człowieka.

Do tego dochodzi kluczowe pole: poziom dostępu. Można go powiązać z istniejącymi rolami w firmie (np. „publiczny wewnętrznie”, „tylko HR”, „tylko zespół X”). Nie ma potrzeby od razu robić skomplikowanego systemu uprawnień na poziomie każdego akapitu – w większości przypadków wystarczy pilnować dostępu na poziomie dokumentu lub folderu.

Iteracyjne uzupełnianie braków: od realnych pytań użytkowników

Nawet najlepsza selekcja korpusu nie trafi w 100% w potrzeby. Zamiast w nieskończoność „domyślać się”, lepiej szybko udostępnić pilota w małej grupie i zbierać:

• pytania bez odpowiedzi („nie znalazłem nic sensownego” – sygnał brakujących danych),
• pytania z odpowiedzią, ale złym źródłem (np. przestarzały dokument – sygnał do aktualizacji),
• pytania powtarzające się (kandydaci na osobne, dopieszczone artykuły lub FAQ).

W jednej z firm produkcyjnych po miesiącu pilota okazało się, że 80% pytań dotyczy trzech procesów: zgłaszania awarii, urlopów i rozliczania delegacji. Efekt był prosty: priorytet dostało dopracowanie właśnie tych procedur w korpusie, a nie wielomiesięczne integrowanie systemu CRM, do którego nikt nie pytał asystenta choćby raz.

Czyszczenie i segmentacja dokumentów: jak „pokroić” wiedzę

Czyszczenie tekstu: odrzuć szum, zostaw strukturę

Surowy tekst z eksportu rzadko nadaje się od razu do embeddingów. Znaki specjalne, stopki, numery stron, powtarzające się nagłówki – to wszystko zasypuje model śmieciami i obniża trafność wyszukiwania. Z drugiej strony przesadne „pranie” tekstu potrafi usunąć ważne informacje (np. strukturę list czy tabele).

Praktyczny kompromis to kilka prostych zasad:

Najpierw usuń elementy, które z definicji nie pomagają w odpowiadaniu na pytania: numery stron, powielone nagłówki z szablonu, stopki z klauzulami prawnymi, menu nawigacyjne z eksportu HTML. Zamiast pisać skomplikowane reguły, często wystarczy kilka prostych filtrów po słowach kluczowych („Strona 1 z”, „All rights reserved”, nawigacja breadcrumb) i długości wiersza. Taki „gruby filtr” potrafi uciąć kilkanaście procent szumu przy minimalnym nakładzie pracy.

Kolejny krok to normalizacja formatowania bez niszczenia struktury. Zamień wielokrotne spacje, twarde podziały linii w środku zdań i egzotyczne znaki na prostsze odpowiedniki, ale zachowaj puste linie między akapitami, wypunktowania i numerowane listy. W praktyce sprawdza się prosty schemat: czyść agresywnie w poziomie „znaku”, ale ostrożnie w poziomie „linii” – nie sklejaj na siłę wszystkiego w jeden blok, bo model traci informację o hierarchii treści.

Osobny temat to tabele i fragmenty pół-strukturalne (np. parametry techniczne, cenniki). Zamiast porzucać je lub udawać, że są zwykłym tekstem, tanim kompromisem jest spłaszczanie ich do formatu „klucz: wartość” lub prostych list. Zamiast pełnej rekonstrukcji HTML, zrób z tabeli listę linii w stylu: „parametr X – wartość Y, jednostka Z”. To wystarczy, by LLM poprawnie z nich korzystał, a nie wymaga pisania zaawansowanego parsera.

Segmentacja: mniejsze porcje, ale z kontekstem

Najczęstszy błąd przy segmentacji to ślepe cięcie co N znaków. Taki podział jest prosty, ale ignoruje strukturę dokumentu: nagłówki, sekcje, listy. Skutkuje to fragmentami, które zaczynają się w połowie akapitu albo urwanymi listami, które są mało sensowne dla użytkownika i dla modelu. Dużo lepszy efekt daje podejście „najpierw struktura, potem rozmiar”: najpierw logicznie dzielisz dokument po nagłówkach i sekcjach, a dopiero później pilnujesz limitu długości chunku.

Praktyczny, niewymagający rozbudowanych narzędzi schemat segmentacji wygląda tak: najpierw rozbijasz dokument na sekcje po nagłówkach (H1–H3 albo ich tekstowych odpowiednikach), a w każdej sekcji tworzysz fragmenty o maksymalnej długości, np. 500–1000 tokenów. Gdy sekcja jest dłuższa, tniesz po granicach akapitów lub list, starając się, by żaden chunk nie był ani mikroskopijny, ani przesadnie długi. Zazwyczaj sprawdza się zasada: lepiej mieć kilka większych fragmentów niż dziesiątki bardzo małych, z których każdy nic samodzielnie nie znaczy.

Do tego dochodzi prosty „kontekst sąsiedni”. Zamiast trzymać fragmenty w całkowitej izolacji, możesz przy wyszukiwaniu dołączyć do najlepszego matchu także jego poprzednika i następnika, o ile należą do tej samej sekcji. Tani trik: w indeksie przechowujesz identyfikator sekcji i numer fragmentu, a w momencie budowania promptu pobierasz np. trzy kolejne chunki. Użytkownik dostaje wtedy spójny kawałek dokumentu, a nie pojedyncze zdanie wyrwane z większej całości.

W części systemów przydaje się jeszcze „rodzinne” grupowanie fragmentów, czyli przechowywanie referencji do całego dokumentu i ścieżki w nawigacji (np. „Dokumentacja > Moduł płatności > Integracja z bankiem X”). Dzięki temu możesz pokazać użytkownikowi nie tylko samą odpowiedź, ale też sensowne „gdzie dalej kliknąć”, bez inwestowania w wyszukane UI i rekomendacje treści.

Jeżeli korpus jest wybrany z głową, podstawowo wyczyszczony i rozsądnie pocięty, to nawet prosta konfiguracja: nieduży model, darmowa baza wektorowa i kilka skryptów w cronie potrafi realnie odciążyć zespół. Dopiero gdy ten fundament zaczyna się uginać pod rosnącym ruchem i wymaganiami, ma sens dokładanie kolejnych warstw – lepszych modeli, rerankingu czy zaawansowanych przepływów – już z jasnym obrazem, gdzie każde dodatkowe euro i godzina pracy faktycznie poprawiają działanie asystenta.

Budowa pipeline’u RAG: od pytania użytkownika do odpowiedzi

Minimalna architektura, która już działa

Do obsłużenia pierwszych użytkowników nie potrzeba chmury za dziesiątki tysięcy miesięcznie. Wystarczy przejrzysty przepływ i kilka dobrze dobranych klocków. Najprostsza sensowna architektura RAG (Retrieval-Augmented Generation) składa się z:

Do kompletu polecam jeszcze: Odtwarzanie incydentu tylko z logów: praktyczny przewodnik po cyfrowej sekcji zwłok systemu — znajdziesz tam dodatkowe wskazówki.

• warstwy API – mały serwis HTTP, który odbiera pytania, loguje je i składa resztę elementów w całość,
• bazy wektorowej – do trzymania embeddingów i szybkiego wyszukiwania podobnych fragmentów,
• magazynu dokumentów – najczęściej zwykła baza SQL/NoSQL lub nawet pliki, jeśli skala jest mała,
• klienta do LLM – biblioteka lub wrapper do wywoływania modelu generującego odpowiedź,
• pipeline’u ETL – osobny proces/batch, który pobiera nowe dane, czyści, segmentuje i aktualizuje indeks wektorowy.

Ten zestaw spokojnie mieści się na jednym niewielkim serwerze lub w taniej instancji w chmurze. Zamiast projektować mikroserwisy, lepiej zacząć od jednego repozytorium z dwoma aplikacjami: „backend do pytań” i „worker do pipeline’u danych”. Dopiero gdy ruch i zespół rosną, uzasadnione jest rozdzielanie całości na mniejsze kawałki.

Przepływ zapytania krok po kroku

Typowy request użytkownika przechodzi kilka kroków. Jeśli każdy jest prosty i dobrze nazwany, debugowanie przestaje być koszmarem:

1. Odbiór pytania – API przyjmuje tekst pytania, kontekst użytkownika (ID, rola, język) i ewentualne parametry (np. „tryb ekspercki”).
2. Walidacja i logowanie – sprawdzenie, czy pytanie nie jest puste, zbyt długie, niełamie podstawowych zasad. Na tym etapie zapisujesz log (tekst pytania + user + timestamp).
3. Embedding pytania – przeliczasz pytanie na wektor, używając tego samego modelu embeddingowego, który służył do indeksowania dokumentów.
4. Wyszukiwanie w bazie wektorowej – na podstawie wektora pytania pobierasz N najbardziej podobnych fragmentów, z filtrami po metadanych (np. język = PL, poziom dostępu ≤ rola użytkownika).
5. Opcjonalny reranking – jeśli korzystasz z prostszej bazy wektorowej, możesz przepuścić top-k kandydatów przez tani model tekstowy, który lepiej oceni dopasowanie semantyczne do pytania.
6. Budowa promptu – składasz kontekst z najlepszych fragmentów + instrukcję dla modelu + pytanie użytkownika.
7. Wywołanie LLM – odpalasz model (lokalny lub w API), zbierasz odpowiedź i ewentualne metadane (np. przewidywana pewność, użyte tokeny).
8. Postprocessing odpowiedzi – doklejasz źródła (linki do dokumentów), cenzurujesz ewentualne dane wrażliwe, skracasz lub formatujesz wynik.
9. Zwrot do użytkownika i logi – odpowiedź trafia do klienta (chat, Slack, aplikacja), a ty zapisujesz to, co się przyda do analizy: użyte fragmenty, czas odpowiedzi, ocena użytkownika, jeśli taką zbierasz.

Ten schemat da się zaimplementować nawet w jednym pliku, ale dużo wygodniej potraktować każdy z kroków jako osobny moduł. Wtedy później można podmieniać np. bazę wektorową albo dostawcę LLM bez grzebania w całym kodzie.

Dobór bazy wektorowej: nie zawsze trzeba „enterprise”

Rynek baz wektorowych eksplodował, ale na start potrzebne są głównie: szybkie wyszukiwanie kNN, filtry po metadanych i przyzwoita stabilność. Trzy warianty w zależności od budżetu i skali:

• Minimalistycznie: biblioteki typu FAISS lub Annoy, trzymane w plikach lub w pamięci. Plus: brak dodatkowych serwisów, bardzo tani start. Minus: utrudnione aktualizacje w locie, brak wygodnych filtrów, konieczność własnej otoczki.
• Pragmatycznie: hostowany serwis wektorowy (Pinecone, Qdrant Cloud, Weaviate Cloud). Sensowna opcja, gdy nie chcesz administrować storage i replikacji. Koszt rośnie z liczbą wektorów i zapytań, ale na pilota zwykle mieści się w kilku prostych planach.
• „All-in-one”: rozwiązania zintegrowane z bazą dokumentową (np. oparta o Postgresa z rozszerzeniem wektorowym). Łączysz klasyczne przechowywanie treści i wektory w jednym miejscu, co upraszcza architekturę, choć wymaga trochę więcej dbałości o indeksy.

Na pierwsze wdrożenie dobrze jest ograniczyć się do jednego indeksu na język + prostych tagów w metadanych. Złożone podziały na dziesiątki indeksów rzadko się obronią, a mocno utrudniają operacje typu reindeksowanie czy migracja.

Prosty, ale skuteczny schemat budowy promptu

Nawet świetny korpus potrafi zostać „zepsuty” źle złożonym promptem. Kilka elementów, które w praktyce robią różnicę, a nie kosztują tygodni eksperymentów:

• Wyraźna rola asystenta – jedno lub dwa zdania, kim ma być model i czego nie robić (np. „Jesteś asystentem wewnętrznym firmy X, odpowiadasz krótko i konkretnie, nie wymyślasz faktów. Jeśli czegoś nie ma w dostarczonych dokumentach – mów, że nie wiesz.”).
• Instrukcja korzystania z kontekstu – jawne polecenie, że model ma opierać się na załączonych fragmentach i cytować źródła (np. „Używaj wyłącznie treści z dokumentów w sekcji KONTEKST. Na końcu odpowiedzi podaj listę użytych dokumentów.”).
• Oddzielone sekcje – wyraźne bloki typu: <KONTEKST>...</KONTEKST> i <PYTANIE>...</PYTANIE>. Modele o wiele lepiej sobie radzą, gdy struktura promptu jest czytelna.
• Limity i styl – krótkie wytyczne: length („maksymalnie 10 zdań”), styl („język prosty, bez żargonu prawniczego, chyba że pytanie jest techniczne”) i format („jeśli pytanie prosi o listę kroków – odpowiedz w formie listy numerowanej”).

Dobrym nawykiem jest trzymanie historii zmian promptu w repozytorium, jak zwykłego kodu. Zmiana jednego zdania potrafi poprawić albo zepsuć jakość całego systemu, więc możliwość szybkiego porównania wersji jest bezcenna.

Bezpieczeństwo i uprawnienia: jak nie zbudować wycieku danych

Najprostszy model bezpieczeństwa, który da się realnie utrzymać

System RAG ma pechową cechę: jeśli przejdzie do indeksu choć jeden dokument z poufnymi danymi, model może zacząć je zwracać w odpowiedziach. Nie ma tu magii – zabezpieczenia trzeba zrobić przed embeddingami, a nie dopiero przy budowie promptu.

Prosty, ale skuteczny schemat wygląda tak:

1. Filtrowanie źródeł przed importem – na poziomie pipeline’u decydujesz, które foldery, repozytoria czy przestrzenie Confluence w ogóle wchodzą do gry. Lepiej zacząć od „białej listy” niż próbować ogarniać cały chaos firmowy.
2. Mapowanie uprawnień na poziomy dostępu – podczas importu dokument dostaje tag typu access_level (np. „PUBLIC_INTERNAL”, „HR_ONLY”, „TEAM_X”). To nie musi dokładnie odwzorowywać każdej roli z AD – wystarczy kilka klas, które da się ogarnąć mentalnie.
3. Kontrola po stronie wyszukiwania – zanim zapytasz bazę wektorową, przelicz rolę użytkownika na zestaw akceptowalnych poziomów dostępu i dołóż to jako filtr do zapytania. Jeśli baza wektorowa nie wspiera filtrów, lepiej zmienić bazę niż ryzykować ręczne filtrowanie po zwróceniu wyników.
4. Brak „przepuszczania” surowych zapytań do LLM zewnętrznego – do modelu idzie tylko pytanie + wybrane fragmenty. Nigdy nie wysyłaj pełnego korpusu, dumpów baz danych ani innych wrażliwych zasobów.

Taki model nie rozwiąże wszystkich możliwych scenariuszy, ale już odcina zdecydowaną większość ryzyk typu „asystent wypluł poufne dane finansowe z arkusza, który miał widzieć tylko zarząd”.

Redakcja danych wrażliwych i maskowanie

Nawet przy poprawnych poziomach dostępu czasem w dokumentach wiszą dane, których po prostu nie powinno tam być: numery PESEL, prywatne maile, dane klientów. Czekanie, aż ktoś posprząta wszystkie źródła, może zablokować projekt na pół roku. Da się to obejść techniką „delikatnego czarnego markera” w pipeline’ie ETL.

Najprostsze warianty:

• Reguły regex – numery dokumentów, NIP, PESEL, karty płatnicze. Zastępujesz je placeholderem typu [ZREDAGOWANE_PESEL]. Nie idealne, ale łatwe do wdrożenia.
• Listy słów kluczowych – nazwy kilku największych klientów, których nie chcesz ujawniać w żadnym kontekście. Możesz je częściowo maskować (np. „Klient A”).
• Maskowanie maili prywatnych – zamiana adresów w stylu imie.nazwisko@gmail.com na [PRYWATNY_EMAIL], przy zachowaniu adresów firmowych w domenie.

Zastosowanie tych filtrów na poziomie tekstu źródłowego sprawia, że nawet jeśli ktoś wyciągnie dane z wektorów, nie zobaczy surowych wartości. To nie zwalnia z porządnego porządku w źródłach, ale daje bufor bezpieczeństwa, który często ratuje projekt przed blokadą działu prawnego.

Audytowalność: co, kto i dlaczego zobaczył

Drugą stroną bezpieczeństwa jest możliwość odtworzenia, co się wydarzyło. Nie wystarczy ogólne „nie logujemy nic wrażliwego”. Przy wdrożeniach firmowych przydaje się komplet prostych logów:

• log zapytań – ID użytkownika, timestamp, tekst pytania (czasem zanonimizowany), parametry (tryb, kanał),
• log retrievalu – lista ID fragmentów zwróconych przez bazę wektorową, wraz z metadanymi (źródło, poziom dostępu),
• log odpowiedzi – pełny tekst odpowiedzi lub przynajmniej hash/skrót + odwołania do fragmentów, które ją zasiliły.

W praktyce wystarczy jedna tabela/kolekcja „interakcje” i prosta konsola dla administratorów. Gdy któryś dział zgłosi, że „asystent powiedział coś dziwnego”, można prześledzić całą ścieżkę: od pytania, przez segmenty, po odpowiedź modelu. Naprawa błędu zajmuje wtedy godziny, a nie tygodnie domysłów.

Wybór i orkiestracja modeli: ile mocy naprawdę potrzebujesz

Jeden model do wszystkiego czy zestaw specjalistów

Kuszące jest używanie jednego dużego modelu do każdej operacji: embeddingów, odpowiadania, klasyfikacji, streszczania. Dla małej skali to może przejść, ale szybko zaczyna boleć na kosztach i czasie odpowiedzi. Rozsądniejszy, bardziej budżetowy wariant to podział ról:

• model embeddingowy – mniejszy, wyspecjalizowany w wektorach, często open source i odpalony lokalnie,
• model „główny” – do generowania odpowiedzi, zwykle nieco większy lub w formie zewnętrznego API,
• modele pomocnicze – lekkie modele do klasyfikacji typu „czy to pytanie jest o HR czy o IT?”, „czy odpowiedź jest pewna czy niepewna?”.

Ten podział pozwala zbić koszty: małe modele można trzymać blisko danych (on-prem lub w małej instancji GPU), a duży model wywoływać tylko w sytuacjach, które faktycznie go wymagają.

Kiedy zewnętrzne API, a kiedy własny model

Decyzja „hostować samemu czy korzystać z API” ma trzy główne wymiary: koszt, prywatność i elastyczność.

• API dostawców – dobry wybór na start i w małych organizacjach. Płacisz za użycie, odpada administracja infrastrukturą. Problem pojawia się przy dużej liczbie zapytań albo restrykcyjnej polityce danych (klienci z sektora finansowego, medycznego itp.).
• Modele on-prem / self-hosted – wymagają inwestycji w GPU i ludzi, którzy to ogarną, ale dają pełną kontrolę nad danymi i możliwość agresywnej optymalizacji (quantization, distillation, cache’owanie). Opłacają się przy wysokim wolumenie zapytań lub tam, gdzie dane w ogóle nie mogą opuścić organizacji.

Praktycznym kompromisem jest hybryda: mniej wrażliwe scenariusze lecą przez API, a krytyczne (np. dane medyczne, informacje o klientach) przez mniejszy, ale bezpieczny model hostowany lokalnie. Orkiestracją można sterować prostą regułą biznesową w backendzie.

Cache’owanie odpowiedzi i wyników wyszukiwania

W firmowych asystentach pytania lubią się powtarzać. Zamiast za każdym razem liczyć wszystko od zera, można wprowadzić dwa poziomy cache:

• cache odpowiedzi LLM – kluczujesz po treści pytania (ew. po jego „znormalizowanej” wersji) i trybie pracy. Jeśli ktoś zada to samo pytanie drugi raz, backend może od razu zwrócić poprzednią odpowiedź, pomijając cały proces retrievalu i wywołania modelu.
• cache wyników retrievalu – po przeliczeniu embeddingu pytania i zapytaniu bazy wektorowej zapisujesz listę ID fragmentów. Gdy podobne pytanie wróci (embedding blisko w przestrzeni), możesz użyć tych samych segmentów i tylko poprosić model o nową odpowiedź, już bez odpytywania bazy.

Na początek wystarczy prosty cache w Redisie lub nawet w relacyjnej bazie, jeśli ruch jest niski. Największy zysk pojawia się przy powtarzalnych tematach: procedury HR, zasady urlopów, „jak zresetować hasło”. W takich przypadkach różnica między systemem z cache a bez potrafi być dramatyczna zarówno w kosztach, jak i czasie odpowiedzi.

Żeby cache nie zrobił bałaganu, przydaje się kilka prostych reguł: krótki TTL dla treści silnie zależnych od aktualnego stanu (np. „ile mam jeszcze dni urlopu?” – lepiej w ogóle nie keszować) i dłuższy dla wiedzy statycznej. Warto też przewidzieć łatwy mechanizm unieważniania: gdy dział prawny podmieni regulamin, administrator jednym kliknięciem czy komendą czyści powiązane wpisy w cache. Bez tego asystent potrafi jeszcze długo żyć w starym świecie.

Przy większej skali opłaca się dodać warstwę cache po stronie samego LLM – np. embeddings powtarzalnych pytań i promptów. Jeśli backend często woła ten sam model z bardzo podobnym kontekstem, można trzymać wyniki częściowych obliczeń i skrócić czas odpowiedzi o kolejne setki milisekund. Nie trzeba od razu wchodzić w rozbudowane systemy; często prosty słownik w pamięci procesu serwera zamyka 80% potrzeb.

Dobry asystent AI na własnych danych nie musi być ani perfekcyjny, ani „enterprise-class” w każdym detalu. Dużo ważniejsze jest, żeby w rozsądnym czasie i budżecie zaczął rozwiązywać realne problemy ludzi w organizacji – odpowiadać na pytania szybciej niż excelowy guru, ujednolicać interpretację procedur, odciążać ekspertów od powtarzalnych odpowiedzi. Reszta to już iteracje: dokładanie kolejnych źródeł, doczyszczenie korpusu, wymiana modeli na lepsze wtedy, gdy faktycznie brakuje im mocy. Dzięki temu zamiast wiecznego „projektu przyszłości” powstaje narzędzie, które realnie pracuje na swoje utrzymanie.

Monitorowanie jakości: jak sprawdzić, czy asystent naprawdę pomaga ludziom

Proste metryki na start: nie pchaj się od razu w MLOps

Największy błąd przy wdrażaniu asystenta to brak systematycznej obserwacji tego, co ludzie z nim robią. Nie trzeba od razu stawiać rozbudowanej platformy MLOps – wystarczy kilka praktycznych liczników, które da się wyciągnąć z logów.

Minimalny zestaw, który robi realną różnicę:

• liczba unikalnych użytkowników miesięcznie – czy asystent żyje, czy tylko zespół projektowy klika „dla testów”,
• liczba zapytań na użytkownika – czy wraca do narzędzia, czy po pierwszym podejściu porzuca,
• odsetek „przerwanych” konwersacji – np. brak kolejnej interakcji po odpowiedzi na pierwsze pytanie,
• flagi ręczne – przycisk „pomogło / nie pomogło” lub 3‑stopniowa ocena, zbierana choćby w 10–20% przypadków.

Te kilka sygnałów pokazuje, czy asystent realnie rozwiązuje problemy, czy tylko generuje ładny tekst. Na ich podstawie można szybko podjąć decyzję: dosypać treści, poprawić prompt, czy może cały czas aplikacja odpowiada zbyt ogólnie.

Feedback użytkowników: tanie, ale wymagające konsekwencji

Technicznie najprostsze, a psychologicznie najtrudniejsze jest regularne proszenie ludzi o informację zwrotną. W praktyce wystarcza mały panel pod odpowiedzią:

• „Ta odpowiedź była:” – przydatna / częściowo przydatna / nietrafiona,
• krótkie pole komentarza, które otwiera się dopiero po kliknięciu „częściowo / nietrafiona”.

Klucz nie leży w samym UI, tylko w rytualnym „przerabianiu” tych uwag. Dobry, tani schemat na początek to:

1. cotygodniowy przegląd 20–50 najgorszych interakcji – zespół produktowy + ktoś techniczny,
2. prosta klasyfikacja: problem w danych, w retrievalu, w promptach, czy w oczekiwaniach użytkownika,
3. 2–3 małe poprawki tygodniowo (np. dodanie brakujących dokumentów, dopisanie reguły, zmiana promptu) zamiast wielkich „refactoringów raz na kwartał”.

Przy takim podejściu jakość odpowiedzi rośnie wykładniczo tanim kosztem. Ktoś raz doda jeden brakujący dokument do korpusu i poprawa dotknie setek podobnych pytań w przyszłości.

Detekcja halucynacji i „odklejonych” odpowiedzi

Asystent, który zbyt pewnie zmyśla, jest groźniejszy niż taki, który przyznaje, że nie wie. Zamiast opierać się na intuicji, można dodać prosty mechanizm automatycznej oceny pewności.

Praktyczny wzorzec:

• drugi, lekki model oceniający – na wejściu dostaje pytanie, kontekst (fragmenty z retrievalu) i wygenerowaną odpowiedź, na wyjściu zwraca np. etykietę pewne / średnie / ryzykowne,
• zasady biznesowe – jeśli odpowiedź jest „ryzykowna”, aplikacja wyświetla ostrzeżenie („Tej odpowiedzi nie możesz traktować jak porady prawnej / księgowej”) albo zachęca do kontaktu z człowiekiem.

Nie trzeba trenować niczego od zera – taki model można zbudować nawet z gotowego LLM-a w trybie klasyfikacji, dodając kilka przykładów w promptcie. Z czasem, na bazie swoich danych, da się go wymienić na coś szybszego i tańszego.

Regression tests: żeby kolejne „ulepszenia” niczego nie popsuły

Każda zmiana w korpusie, promptach czy modelu może niechcący zepsuć odpowiedzi na pytania, które wcześniej działały dobrze. Żeby nie być zdanym na los, przydaje się mini-zestaw testów regresyjnych.

W tym miejscu przyda się jeszcze jeden praktyczny punkt odniesienia: Przewodnik po wektorowych bazach danych i RAG: jak łączyć modele językowe z własnymi danymi.

Najprostszy wariant:

1. z logów wyciągasz kilkadziesiąt lub kilkaset realnych pytań,
2. dla każdego przechowujesz aktualną „dobrą” odpowiedź (albo opis kryteriów, co znaczy „dobra”),
3. po każdej większej zmianie odpalasz skrypt, który zadaje pytania na nowo i porównuje jakość odpowiedzi.

Ocena może być półautomatyczna: na start wystarczy ręczne przejrzenie niewielkiej próbki i prosta metryka podobieństwa tekstowego (np. BLEU, ROUGE) jako filtr. Chodzi nie o akademicką precyzję, tylko o szybkie wychwytywanie oczywistych wpadek typu „nagły zanik informacji o krytycznej procedurze”.

Iteracyjne rozszerzanie korpusu: jak nie utopić się w dokumentach

Zamiast „wrzucić wszystko naraz” – priorytetyzacja według wartości biznesowej

Kuszący scenariusz: podłączyć wszystkie możliwe źródła – Confluence, SharePoint, dyski sieciowe, maile, CRM – i mieć „pełną wiedzę firmy” w jednym miejscu. W praktyce to recepta na wielomiesięczny projekt, który spali budżet zanim pokaże efekt.

Bardziej pragmatyczne podejście to sekwencja małych rozszerzeń. Na początek identyfikujesz kilka obszarów, gdzie:

• zapytania są powtarzalne (np. urlopy, benefity, procedury zakupowe),
• błędne odpowiedzi nie niosą krytycznego ryzyka (czyli nie prawo, nie medycyna, nie decyzje finansowe dużej skali),
• czas specjalistów jest realnie drogi (np. helpdesk IT, HR pierwszej linii).

Na tej bazie budujesz pierwszą wersję korpusu, często obejmującą mniej niż 10% wszystkich dokumentów w organizacji, ale pokrywającą 60–70% realnych pytań. Reszta może poczekać.

Mechanizm „content backlogu” zamiast jednorazowego importu

Dokumenty będą się pojawiać, zmieniać i znikać przez cały czas. Zamiast jednorazowego „dnia migracji”, lepiej traktować korpus jak produkt, z prostą listą zadań.

Przykładowy prosty workflow:

1. Z logów i feedbacku wyciągasz pytania bez dobrej odpowiedzi.
2. Dla każdego z nich identyfikujesz brakujące źródło wiedzy (konkretny dokument, strona, osoba).
3. Zapisujesz to w backlogu treści (Jira, Trello, arkusz – cokolwiek działa).
4. Co tydzień/kilka dni ktoś z zespołu przerabia 5–10 pozycji: dodaje dokument, aktualizuje, oznacza jako „nie do włączenia” jeśli jest zbyt ryzykowny lub zbyt specyficzny.

Dzięki temu korpus rośnie tam, gdzie widać realne zapotrzebowanie, a nie tam, gdzie najłatwiej wykonać automatyczny import.

Radzenie sobie z rozjazdem wersji dokumentów

Asystent często działa szybciej niż procesy aktualizacji dokumentacji. Nowy regulamin, instrukcja, cennik – wszystko to aktualizuje się w różnym rytmie. Bez kontroli wersji asystent szybko zaczyna cytować „stare prawdy”.

Praktyczny kompromis, tani w utrzymaniu:

• każdy dokument w korpusie ma wersję i datę ważności w metadanych,
• retrieval preferuje najnowszą wersję (np. filtr po dacie + sortowanie po aktualności),
• po publikacji nowej wersji stara jest archiwizowana – dostępna tylko dla administratorów, nie wchodzi do kontekstu modelu.

Nie trzeba budować pełnego systemu zarządzania dokumentami, jeśli organizacja już ma choćby podstawowe repozytorium (DMS, Confluence z wersjami). Wystarczy z niego skorzystać i w ETL-u zadbać o propagację numerów wersji do bazy wektorowej.

Integracja z istniejącymi systemami: asystent tam, gdzie są użytkownicy

Gdzie umieścić interfejs: intranet, Teams, Slack, e‑mail

Technicznie najłatwiej jest wystawić prosty webowy czat pod osobnym adresem. Problem w tym, że większość ludzi nie będzie o nim pamiętać. O wiele skuteczniej działa wpięcie asystenta w miejsca, w których i tak toczy się praca.

Najczęstsze warianty:

• komunikatory (Teams, Slack) – bot kanałowy lub „DM bot”, do którego można napisać jak do kolegi,
• portal pracowniczy / intranet – widżet z polem pytania, najlepiej widoczny na stronie głównej,
• helpdesk / system ticketowy – asystent podpowiada rozwiązania zanim użytkownik utworzy zgłoszenie.

Na start wystarczy jeden dobrze dopracowany kanał. Integracje z kolejnymi kanałami można dodawać stopniowo, używając tego samego backendu RAG, zmieniając tylko warstwę prezentacji i uwierzytelniania.

Autoryzacja i kontekst użytkownika z systemów SSO

Skoro asystent ma respektować uprawnienia, musi wiedzieć, kto pyta. Zamiast wynajdywać koło na nowo, najlepiej oprzeć się na istniejącym SSO (np. Azure AD, Okta, Keycloak).

Praktyczny wzorzec:

1. Warstwa frontowa (apka web, bot w Teams) uwierzytelnia użytkownika przez SSO.
2. Token z SSO trafia do backendu, gdzie jest weryfikowany i mapowany na prosty identyfikator (user_id) i listę ról/grup.
3. Retrieval używa tych danych w filtrach poziomu dostępu w bazie wektorowej (np. „HR-only”, „IT”, „wszyscy”).

Dzięki temu nie trzeba utrzymywać osobnej bazy użytkowników. Jedyny dodatkowy element to mapowanie grup z katalogu (AD/LDAP) na kategorie w metadanych dokumentów. Na początek można to zrobić nawet konfiguracją w pliku.

„Asystent w tle”: podpowiedzi kontekstowe zamiast osobnego czatu

Czat z asystentem to tylko jeden wzorzec. W wielu procesach lepiej działa podejście, w którym narzędzie samo wysuwa się z podpowiedzią w kontekście konkretnego ekranu.

Kilka prostych przykładów:

• formularz wniosku urlopowego – panel boczny z pytaniami i odpowiedziami typu „jak liczone są dni opieki nad dzieckiem?”,
• system CRM – przy otwartym koncie klienta widżet z najczęstszymi pytaniami o zasady rabatów dla danego segmentu,
• aplikacja do obsługi incydentów IT – sugestie kroków diagnostycznych na podstawie opisu zgłoszenia.

Z technicznego punktu widzenia to dalej zwykły RAG. Różnica polega tylko na tym, że część promptu jest generowana automatycznie z kontekstu aplikacji (np. typ wniosku, rodzaj klienta), a użytkownik dopytuje tylko o szczegóły. W efekcie mniej pisze, szybciej dostaje sensowne podpowiedzi, a zespół nie musi prowadzić walidacji „czy ludzie w ogóle wejdą na stronę asystenta?”.

Obsługa wielu języków: od „taniego” dwujęzycznego startu do skali globalnej

Jedna baza wektorowa czy osobna dla każdego języka

W organizacjach działających w kilku krajach pojawia się klasyczny dylemat: tłumaczyć wszystko na jeden język czy trzymać wielojęzyczny korpus. Technicznie oba warianty da się zrealizować, ale różnią się kosztami i ryzykiem.

Dwa proste podejścia:

• osobne korpusy per język – prostsze logicznie (polski → polskie dokumenty, angielski → angielskie), ale wymaga osobnych procesów utrzymania i dublowania wysiłku przy aktualizacjach,
• wspólny korpus wielojęzyczny z embeddingami wielojęzycznymi – pozwala przechowywać dokumenty w oryginalnym języku, a pytania tłumaczyć „w locie” na poziomie wektorów.

Na start, szczególnie przy dwóch językach, zwykle wygrywa wariant z osobnymi korpusami. Mniej magii, łatwiej zapanować nad odpowiedzialnością działów (lokalne HR trzymają swoją dokumentację). Wspólne, wielojęzyczne wektory zaczynają mieć sens przy większej liczbie języków lub silnie wspólnym korpusie (np. globalne polityki bezpieczeństwa).

Automatyczne tłumaczenia – gdzie mają sens, a gdzie robią bałagan

Kopie dokumentów w kilku językach brzmią jak idealne rozwiązanie, dopóki ktoś nie musi tego wszystkiego utrzymywać. Zamiast ręcznie tłumaczyć cały korpus, można wprowadzić prosty miks:

• treści krytyczne i prawnicze – tłumaczone ręcznie lub przez wyspecjalizowaną firmę, wersje językowe powiązane metadanymi,
• treści pomocnicze – np. FAQ, ogólne procedury – tłumaczone automatycznie na etapie wyświetlania odpowiedzi (LLM lub tańszy model MT),
• pytania użytkowników – na wejściu wykrycie języka, opcjonalnie tłumaczenie na „język roboczy korpusu” (np. angielski), retrieval, a na końcu tłumaczenie odpowiedzi z powrotem.

W takiej konfiguracji droższe tłumaczenia kupujesz tylko tam, gdzie realnie zmniejszają ryzyko (regulaminy, umowy, polityki), a całą resztę obsługuje automat. Dodatkowo można ograniczyć koszty, wprowadzając prostą zasadę: automatyczne tłumaczenie jest cache’owane i poprawiane „przy okazji” przez lokalne zespoły, gdy i tak pracują z daną treścią. Nie trzeba robić wielkiego projektu lokalizacyjnego – wystarczy, że system zapisuje poprawione wersje zamiast generować je za każdym razem od zera.

Przy automatycznych tłumaczeniach przydają się dwie techniczne „poręcze”. Po pierwsze, metadane powinny jasno wskazywać język oryginału oraz to, czy dany fragment jest tłumaczeniem maszynowym, czy zatwierdzoną wersją lokalną. Po drugie, interfejs może oferować prostą opcję „pokaż oryginał”, żeby użytkownik widział, skąd wzięła się odpowiedź i mógł szybko wyłapać ewentualne nieścisłości. W środowisku wewnętrznym takie proste zabezpieczenia zwykle wystarczają.

Przy skalowaniu na więcej krajów warto zmienić sposób myślenia: nie „tłumaczymy wszystko na wszystko”, tylko definiujemy jeden lub dwa języki bazowe. Dokumenty regionalne powstają w języku lokalnym, ale globalne polityki i instrukcje są utrzymywane głównie w języku bazowym, a resztę robi automat. Taki układ ułatwia utrzymanie spójności i ogranicza liczbę kombinacji, które trzeba ręcznie kontrolować.

Dobry test dojrzałości takiego rozwiązania jest prosty: nowy kraj dołącza do organizacji, podpinasz go do istniejącego asystenta, konfigurujesz mapowanie języka i uprawnień, a cała reszta „zaskakuje” bez wielkiej przebudowy architektury. Jeśli wymaga to przepisywania połowy pipeline’u, to sygnał, że warstwa językowa za mocno wrosła w logikę biznesową i trzeba ją rozplątać.

Budowa własnego asystenta AI na firmowych danych nie musi być drogim, jednorazowym projektem. Dużo lepsze rezultaty daje spokojne dokładanie klocków: od małego korpusu i prostego RAG-a, przez niewielkie integracje, po selektywne wielojęzyczność i kontrolę wersji. Kluczowe jest, żeby każda kolejna inwestycja – w danych, modelach, integracjach – była odpowiedzią na realny ruch i realne pytania użytkowników, a nie na slajd z roadmapą.

Najczęściej zadawane pytania (FAQ)

Po co mi własny asystent AI, skoro mogę używać ChatGPT lub innych publicznych chatbotów?

Publiczne chatboty są świetne do ogólnych zadań: pisania maili, streszczeń, tłumaczeń. Mają jednak dwie duże słabości w kontekście firmy: brak znajomości Twoich wewnętrznych procedur oraz ryzyko związane z poufnością danych. Model ogólny nie ma dostępu do Twoich regulaminów, dokumentacji projektów ani notatek ze spotkań, więc będzie zgadywał albo odpowiadał „książkowo”, a nie „po waszemu”.

Własny asystent pracuje na Twoim korpusie dokumentów i działa w środowisku, które kontrolujesz (własna chmura, serwer, nawet mocniejszy PC). Dzięki temu możesz bezpiecznie podać mu umowy, polityki, tickety z Jira czy wewnętrzne wiki i mieć pewność, że wiedza nie wypływa na zewnątrz.

Jakie dane najlepiej nadają się na start do trenowania/przygotowania asystenta AI?

Największy zwrot z inwestycji dają materiały, które już teraz służą ludziom jako „instrukcja obsługi firmy”. Chodzi przede wszystkim o: procedury i checklisty (np. obsługa reklamacji, wdrożenie klienta), FAQ działu supportu, wewnętrzne bazy wiedzy (Confluence, Notion) oraz dokumentację produktów i API.

Na początek lepiej wziąć mniejszy, ale dobrze przygotowany zestaw: aktualne regulaminy, instrukcje krok po kroku, odpowiedzi na najczęstsze pytania klientów i pracowników. Rzadko używane, nieaktualne prezentacje sprzed kilku lat czy chaotyczne maile można zostawić na później – robią szum, a mały efekt.

Jaki jest minimalny zestaw funkcji, żeby asystent AI miał sens biznesowy?

Aby projekt nie skończył jako ciekawostka, przydaje się kilka absolutnych podstaw: możliwość zadawania pytań o dokumenty z podglądem źródeł (linki, fragmenty), logi zapytań i odpowiedzi oraz prosty interfejs webowy z czatem dostępny z przeglądarki. To już wystarczy, by oszczędzić realny czas na szukaniu informacji.

Dodatkowo bardzo opłaca się od razu wprowadzić choćby podstawowy podział na przestrzenie (np. dokumenty firmowe vs. dokumenty działu) oraz wygodny mechanizm aktualizacji korpusu – np. synchronizację z wybraną przestrzenią w Confluence czy folderem na serwerze plików, zamiast ręcznego wrzucania każdego PDF.

Od czego zacząć technicznie: no‑code, API czy własny model open‑source?

Najtaniej „na start” wychodzi zwykle platforma low‑code/no‑code typu „chat z dokumentami”. Można w kilka godzin wrzucić PDF-y, podpiąć tani model w chmurze i przetestować, czy ludzie w firmie w ogóle chcą z tego korzystać. To dobry etap pilotażowy przed większymi inwestycjami.

Jeśli pilotaż wypali, rozsądnym kolejnym krokiem jest składanie rozwiązania z klocków: API LLM + własna baza wektorowa + prosty backend. Własny, w pełni self‑hostowany stack z modelami open‑source ma sens głównie wtedy, gdy wolumen zapytań jest duży albo wymogi prawne/poufnościowe są bardzo ostre – inaczej koszty sprzętu i utrzymania mogą zjeść oszczędności na API.

Ile mocy obliczeniowej potrzebuję, żeby uruchomić prywatnego asystenta AI?

Dla osoby lub mikrozespołu często wystarczy jeden laptop lub mini‑serwer z przyzwoitą ilością RAM i dysku. Model generujący możesz trzymać w chmurze (płacisz tylko za zużycie), a lokalnie hostować tylko bazę dokumentów i interfejs. To najprostszy układ kosztowo: minimalny sprzęt na miejscu, reszta „na żądanie”.

Dla kilku–kilkudziesięciu osób przyda się już mały serwer (VPS lub instancja w chmurze) z reverse proxy, autoryzacją i prostą obsługą ról. Własny serwer z dużym GPU opłaca się dopiero przy naprawdę intensywnym użyciu lub mocnych ograniczeniach prawnych – w innych przypadkach elastyczna chmura jest zwykle tańsza i mniej kłopotliwa w utrzymaniu.

Jak zabezpieczyć prywatnego asystenta AI i nie złamać RODO ani tajemnicy przedsiębiorstwa?

Podstawą jest trzymanie korpusu i logów w środowisku, które kontrolujesz oraz świadome dobranie dostawcy modeli (np. umowa powierzenia danych, jasna polityka retencji). Dobrym nawykiem jest też anonimizacja danych osobowych przed wejściem do systemu – szczególnie w ticketach, logach i mailach.

Od strony dostępu warto wdrożyć minimum: logowanie użytkowników (SSO, LDAP albo zwykłe konta) oraz podział na przestrzenie lub role, które ograniczają, kto widzi jakie dokumenty. W aplikacji można też wymusić, żeby asystent nie odpowiadał na pytanie, jeśli nie znajdzie wiarygodnych źródeł w bazie – to zmniejsza ryzyko halucynacji i mylnych decyzji biznesowych.

Czy mogę użyć asystenta AI do kodu i dokumentacji technicznej zespołu IT?

Tak, to jeden z bardziej opłacalnych scenariuszy. Do korpusu można wrzucić README, ADR-y, dokumentację API, a nawet wybrane pliki z repozytorium. Programiści zyskują wtedy „wewnętrzny Stack Overflow” dopasowany do realnej architektury firmy, a nie do ogólnych przykładów z internetu.

Dobrze zadziała też połączenie z systemem ticketowym (Jira, ServiceNow) i wewnętrznymi FAQ działu wsparcia. Asystent może szybko podpowiadać rozwiązania na podstawie historii incydentów i zgłoszeń, co realnie skraca czas analizy powtarzalnych problemów i odciąża bardziej doświadczonych członków zespołu.

Bibliografia

• NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology (2023) – Zarządzanie ryzykiem, poufność i kontrola w systemach AI
• ISO/IEC 23894:2023 Information technology – Artificial intelligence – Guidance on risk management. International Organization for Standardization (2023) – Wytyczne dot. ryzyka, zgodności i nadzoru nad systemami AI
• OECD Principles on Artificial Intelligence. Organisation for Economic Co-operation and Development (2019) – Zasady odpowiedzialnego stosowania AI, przejrzystość i nadzór
• General Data Protection Regulation (GDPR). European Union (2016) – Podstawy prawne przetwarzania danych osobowych, retencja i powierzenie
• Vector Databases: From Embeddings to Applications. O’Reilly Media (2024) – Przegląd baz wektorowych, RAG i architektury asystentów na własnych danych