Chatbot na dokumentach firmy, który podaje źródło każdej odpowiedzi

Problem

Wiedza firmy rzadko ginie. Ona się rozprasza. Część siedzi w dokumentacji technicznej, część w materiałach szkoleniowych w PDF-ach, część w opisach procedur, których nikt nie czytał od miesięcy. Formalnie wszystko jest opisane. Praktycznie odpowiedzi na konkretne pytanie szuka się kwadrans, a najczęściej po prostu pyta się kolegi, który akurat pamięta.

Zadanie brzmiało: asystent, któremu można zadać pytanie po polsku i dostać odpowiedź opartą wyłącznie na dokumentach firmy, z podanym źródłem. Ten drugi warunek jest ważniejszy, niż wygląda. Asystent bez cytowania źródeł jest nie do sprawdzenia, a przez to nie do użycia w niczym, za co ktoś odpowiada. Z cytatem odpowiedź da się zweryfikować w dziesięć sekund.

Co zbudowałem

Trzy powiązane ze sobą automatyzacje i własną bazę wiedzy. Pierwsza wczytuje dokumenty i dzieli je na fragmenty, druga odpowiada na pytania, trzecia pilnuje aktualności. Do tego baza, która potrafi szukać po znaczeniu, a nie po dosłownych słowach — pytanie „czy mogę oddać sprzęt po terminie” ma znaleźć akapit o zwrotach, nawet jeżeli nie pada w nim ani jedno słowo z pytania.

Do środka trafiły trzy rodzaje materiałów:

• 19 stron dokumentacji technicznej,
• materiały szkoleniowe w PDF-ach,
• opisy własnych procesów i procedur.

Razem 390 fragmentów — tyle kawałków tekstu, wśród których asystent szuka odpowiedzi. To niedużo w kategoriach technicznych i dokładnie tyle, ile ma typowa mała firma, która nigdy nie uznała swojej dokumentacji za „bazę wiedzy”.

Co poszło nie tak — i dlaczego oczywista diagnoza była błędna

Pierwsza wersja odpowiadała fatalnie. Pytania po polsku o dokumenty pisane po angielsku dawały 0 trafnych odpowiedzi na 5. Nie „przeciętne” — zerowe. Asystent uprzejmie informował, że nie znalazł informacji, mimo że informacja leżała w bazie.

Odruchowa diagnoza w takiej sytuacji brzmi: „słabo działa sortowanie wyników”. W tego typu rozwiązaniu jest bowiem drugi etap, który dostaje kilkadziesiąt kandydatów i układa je od najtrafniejszego. Naturalne podejrzenie: układa źle.

Zmierzyłem to i podejrzenie okazało się fałszywe. Sortowanie działało bardzo dobrze — ocena trafności wynosiła 0,798, czyli układało kandydatów sensownie. Problem polegał na tym, że dostawało do posortowania złych kandydatów.

Prawdziwa przyczyna leżała etap wcześniej. Model odpowiedzialny za rozumienie znaczenia tekstu nie łączył polskiego z angielskim. Polskie pytanie i angielski akapit o tym samym były dla niego dwiema niepowiązanymi rzeczami. Właściwe fragmenty nie wchodziły nawet do pięćdziesiątki najlepszych kandydatów — a skoro nie weszły, sortowanie nie miało szans ich pokazać.

Zamiana na model wielojęzyczny, który rozumie oba języki w tej samej przestrzeni znaczeń, dała 5 trafnych odpowiedzi na 5. To samo pytanie, ta sama baza, ten sam mechanizm sortowania. Zmienił się jeden element na początku łańcucha.

Efekt

• 0 na 5 → 5 na 5 trafnych odpowiedzi na pytania po polsku o anglojęzyczne dokumenty,
• 15 sekund na pełne przeliczenie całej bazy wiedzy, przy koszcie rzędu ułamka grosza,
• każda odpowiedź z podanym źródłem, czyli możliwa do sprawdzenia,
• 390 fragmentów z trzech różnych rodzajów materiałów w jednym miejscu do zapytania.

Co z tego ma firma, która nie jest firmą technologiczną

Ten sam mechanizm działa wszędzie tam, gdzie ludzie zadają sobie nawzajem te same pytania: procedury dla nowych pracowników, warunki umów i regulaminy, instrukcje serwisowe, ustalenia z klientami rozrzucone po mailach. Nie chodzi o to, żeby zastąpić kogokolwiek — chodzi o to, żeby jedna osoba w firmie przestała pełnić rolę wyszukiwarki dla wszystkich pozostałych.

Dwie rzeczy, o które warto pytać każdego, kto proponuje taki system: czy odpowiedź podaje źródło (bez tego nie da się jej sprawdzić) i ile trwa aktualizacja wiedzy po zmianie dokumentów (bez sensownej odpowiedzi na to pytanie system zestarzeje się w kwartał).

Stack: n8n jako warstwa wykonawcza, PostgreSQL z rozszerzeniem pgvector (indeks HNSW, 1024 wymiary), wielojęzyczny model osadzeń bge-m3, sortowanie wyników przez cohere rerank-4-fast, DeepSeek V4 Flash jako model odpowiadający, pamięć rozmowy trzymana w bazie. Wdrożenie na własnej infrastrukturze.

Inne case studies