💡 Nie musisz tego budować sam! Wszystko opisane w tym artykule jest już wdrożone i działa w Intum. Możesz mieć własną bazę wiedzy i system ticketów z AI, który automatycznie sugeruje odpowiedzi na pytania klientów. Zacznij korzystać bez wgłębiania się w technologię — my zajęliśmy się tym za Ciebie.
Poniższy artykuł to rozważania techniczne dla tych, którzy chcą zrozumieć jak tego typu rozwiązania mogą działać pod spodem.
Cel
Jak zbudować system sugerowania odpowiedzi na pytania klientów (helpdesk, tickety, czat) z wykorzystaniem bazy wiedzy i modeli AI. Od najprostszego podejścia do optymalnego — z konkretnymi rekomendacjami dotyczącymi modeli, chunkingu, cachowania i kosztów.
Trzy podejścia — od prostego do optymalnego
1. Wrzuć całą bazę wiedzy do kontekstu
Jeśli baza wiedzy nie jest gigantyczna (kilkaset artykułów, do ~500K tokenów), można ją po prostu wstawić do system promptu. Przy modelach z 1M kontekstem to realnie ~700 tysięcy słów.
Zalety: zero infrastruktury, brak chunkingu, nie trzeba utrzymywać embeddingów.
Wady: koszt rośnie z każdym requestem, model może “gubić” artykuły ze środka kontekstu.
2. Wyszukaj, potem wstrzyknij (RAG z full-text search)
Przed wywołaniem modelu wyszukaj w bazie wiedzy artykuły pasujące do pytania klienta (np. przez PostgreSQL tsvector / pg_search). Wstrzyknij tylko trafne artykuły — 5-10 zamiast całej bazy.
Zalety: niski koszt, szybkie odpowiedzi, łatwe do wdrożenia.
Wady: full-text search nie rozumie semantyki — “nie mogę się zalogować” nie trafi w artykuł “problemy z dostępem do konta”.
3. Semantic search z embeddingami (RAG z pgvector)
Zamień artykuły na wektory (embeddingi) i szukaj po podobieństwie semantycznym. Pytanie “nie działa logowanie” trafi w artykuł o “resetowaniu hasła” mimo braku wspólnych słów.
To rekomendowane podejście — najlepsza jakość trafień przy rozsądnym koszcie i złożoności.
Chunking — jak dzielić artykuły
Nie wrzucaj całego artykułu jako jednego wektora. Duże chunki rozmywają semantykę i similarity search traci precyzję. Dziel artykuły na mniejsze fragmenty.
Rekomendowane parametry
| Parametr | Wartość | Uwagi |
|---|---|---|
| Rozmiar chunka | 400-600 tokenów (~300-450 słów) | Sweet spot dla artykułów 1-3 stron |
| Overlap (nakładka) | 50-100 tokenów (~15-20% chunka) | Zapobiega urywaniu myśli na granicy |
| Tytuł artykułu | Dodawaj do każdego chunka | Model wie skąd pochodzi informacja |
Typowe problemy po audycie chunkingu
- Chunk urywa się w środku zdania/procedury → zwiększ overlap
- Chunk bez kontekstu (“Tak, można to zrobić w ustawieniach” — ale czego?) → dodawaj tytuł artykułu do treści chunka
- Chunki za krótkie (poniżej 100 znaków) → prawdopodobnie śmieci, do usunięcia
- Chunki za długie (powyżej 2000 znaków) → dziel dalej
Model embeddingu — który wybrać
| Model | Wymiary | Koszt | Kiedy używać |
|---|---|---|---|
| text-embedding-3-small (OpenAI) | 1536 | ~20x tańszy od large | Domyślny wybór — dobra jakość, niski koszt |
| text-embedding-3-large (OpenAI) | 3072 | wyższy | Duża baza, artykuły o podobnej tematyce |
Limit dla text-embedding-3-small to 8191 tokenów — technicznie zmieścisz cały artykuł, ale nie powinieneś — mniejsze chunki dają lepsze trafienia.
Ile chunków wyszukiwać (TOP_K)
| TOP_K | Kiedy używać |
|---|---|
| 3 | Baza dobrze ustrukturyzowana, pytania konkretne |
| 5 | Domyślnie — dobry balans (rekomendacja na start) |
| 8-10 | Pytania złożone, artykuły krótkie, tematy się pokrywają |
Progi podobieństwa (cosine distance)
Zamiast stałego TOP_K, lepiej filtrować po progu:
| Cosine distance | Znaczenie |
|---|---|
| < 0.2 | Bardzo podobne — pewne trafienie |
| 0.2 - 0.35 | Powiązane — warto wziąć |
| > 0.4 | Luźno powiązane — raczej nie bierz |
Rekomendacja na start: próg < 0.35 z limitem 5 chunków + fallback do 3 chunków bez progu gdy nic nie pasuje.
Progi warto skalibrować po kilku tygodniach na prawdziwych pytaniach — sprawdź czy model odpowiada “nie wiem” za często (próg za niski) albo halucynuje (bierzesz za mało podobne chunki).
Prompt caching — cachowanie bazy wiedzy
Modele z dużym kontekstem (Claude, GPT) oferują prompt caching. Wysyłasz bazę wiedzy raz, system ją cachuje, a kolejne requesty płacą ułamek za tę część.
Jak to działa
- Pierwsze wywołanie — cache MISS, płacisz pełną cenę (+ 25% za zapis do cache)
- Kolejne wywołania — cache HIT, cachowana część kosztuje 10% normalnej ceny
Cennik z cachowaniem (Claude Sonnet 4.6)
| Operacja | Cena za 1M tokenów |
|---|---|
| Bez cache | $3 |
| Cache write (pierwsze wywołanie) | $3.75 |
| Cache read (kolejne) | $0.30 |
Opłaca się już od 2. requestu. Przy 1000 ticketów dziennie i KB 100K tokenów:
- Bez cache: ~$300/dzień
- Z cache: ~$30/dzień (oszczędność 90%)
Ograniczenia cache
- TTL 5 minut od ostatniego użycia — odświeża się przy każdym trafieniu. Przy stałym ruchu żyje cały czas
- Minimum 1024 tokeny żeby blok był cachowany
- Cache jest per prefix — zmiana czegokolwiek w KB = cache miss i nowy zapis
- Osobny cache per tenant — jeśli każdy klient ma swoją bazę wiedzy, każda to osobny cache
Cała KB w cache vs RAG — co daje lepsze wyniki?
| Podejście | Jakość | Koszt | Złożoność |
|---|---|---|---|
| Cała KB w cache (1M) | ★★★★ | $$ (przy dużym ruchu) | Niska |
| RAG (pgvector top-5) | ★★★★ | $ | Średnia |
| Hybrydowy (RAG + pełne artykuły) | ★★★★★ | $$ | Wysoka |
Dlaczego cała KB nie zawsze wygrywa
Badania pokazują, że modele degradują się przy długich kontekstach — skupiają się nieproporcjonalnie na treściach z początku i końcu okna, zaniedbując środek (“lost in the middle”). Przy 500K tokenów bazy wiedzy model może “nie zauważyć” artykułu ze środka.
Selektywne podawanie kontekstu (RAG) zamiast wszystkiego naraz poprawia trafność odpowiedzi — w niektórych testach z 35% do 67%.
Optymalne podejście — hybrydowe
- RAG wyciąga trafne chunki przez pgvector
- Zamiast surowych chunków, dociągnij pełne artykuły z których pochodzą
- Wyślij pełne artykuły jako kontekst
To daje precyzję RAG (trafiasz we właściwe artykuły) + pełny kontekst artykułu (nie urwany chunk).
System prompt — jak go skonstruować
Dobry system prompt dla helpdesku powinien zawierać:
Struktura
- Rola — “Jesteś asystentem helpdesku firmy X”
- Zasady — odpowiadaj tylko na podstawie KB, nie zgaduj, bądź konkretny
- Ton — przyjazny ale profesjonalny, per “Ty”, bez nadmiernej formalności
- Gdy zna odpowiedź — odpowiedz + podaj źródło (tytuł artykułu)
- Gdy NIE zna odpowiedzi — eskalacja z podsumowaniem tematu (nie zgaduj!)
- Zakazy — nie obiecuj rzeczy spoza KB, nie podawaj cen/terminów których nie znasz, nie zdradzaj że jesteś AI
Kluczowe elementy
- Separator eskalacji — np. “ESKALACJA:” na początku odpowiedzi pozwala automatycznie rozróżnić odpowiedź od prośby o pomoc człowieka
- Źródło odpowiedzi — “Źródło: [tytuł artykułu]” na końcu pozwala agentowi zweryfikować trafność
- Pole pewności — opcjonalnie model może dodać “PEWNOŚĆ: wysoka/niska”, co pozwala automatycznie wysyłać odpowiedzi z wysoką pewnością, a niską kierować do zatwierdzenia
Porównanie modeli do sugerowania odpowiedzi
| Cecha | Claude Sonnet 4.6 | GPT-4.1 Mini | Gemini 2.5 Flash |
|---|---|---|---|
| Cena input/output | $3 / $15 | $0.40 / $1.60 | $0.15 / $0.60 |
| Trzymanie się KB | Bardzo dobre | Dobre | Czasem wychodzi poza KB |
| Format odpowiedzi | Niezawodny | Niezawodny | Czasem ignoruje format |
| Polski język | Naturalny | Naturalny | Dobry |
| Prompt caching | Tak (10% ceny) | Tak | Tak |
Na start: Claude Sonnet lub GPT-4.1 Mini — najbardziej posłuszne co do formatu. Gemini 2.5 Flash jest najtańszy, ale wymaga więcej pracy przy promptowaniu.
Ważne: treść promptu jest uniwersalna między modelami. Różni się tylko sposób przekazywania (Claude ma osobny parametr system, OpenAI/Gemini używają roli system w messages).
Ile można zautomatyzować?
Realistyczne oczekiwania dla SaaS z dobrym RAG:
- 30-50% ticketów rozwiązanych automatycznie bez udziału człowieka
- Kolejne 30-40% — sugestia odpowiedzi którą agent weryfikuje i wysyła (przyspieszenie 2-3x)
- Reszta — wymaga człowieka (problemy techniczne, emocje klienta, edge cases, decyzje biznesowe)
Co się dobrze automatyzuje
- Pytania powtarzalne (“jak wystawić korektę”, “jak zmienić hasło”)
- Odpowiedzi w nocy i weekendy
- Pierwszy draft odpowiedzi
Gdzie ludzie pozostają niezastąpieni
- Problemy techniczne wymagające zajrzenia w dane klienta
- Niezadowolony klient — emocje, eskalacje, negocjacje
- Pytania spoza bazy wiedzy — edge cases, nowe funkcje
- Decyzje biznesowe — wyjątki od regulaminu, zwroty
Rekomendowana ścieżka wdrożenia
- Start — RAG z pgvector, text-embedding-3-small, chunki 500 tokenów, TOP_K = 5
- Optymalizacja — skalibruj progi na prawdziwych pytaniach, dodaj pełne artykuły zamiast chunków
- Cache — włącz prompt caching jeśli masz dużą KB i duży ruch na jednym tenancie
- Auto-odpowiedzi — po kilku tygodniach, gdy sugestie są dobre, włącz automatyczne wysyłanie dla odpowiedzi z wysoką pewnością
- Multi-model — testuj tańsze modele (GPT-4.1 Mini, Gemini Flash) dla prostszych pytań, droższe dla złożonych
Źródła: