[Intum Dev](https://intum.dev.md) / [Używanie AI](https://intum.dev/ai-w-praktyce.md)

# [RAG pipeline — jak budować sugerowanie odpowiedzi AI z bazy wiedzy](https://intum.dev/ai-w-praktyce/rag-pipeline-jak-budowac-sugerowanie-odpowiedzi-ai-z-bazy-wiedzy.md)

> 💡 **Nie musisz tego budować sam\!** Wszystko opisane w tym artykule jest już wdrożone i działa w [Intum](https://intum.pl). Możesz mieć własną [bazę wiedzy](https://intum.pl/pomoc/baza-wiedzy) i [system ticketów z AI](https://intum.pl/pomoc/helpdesk), 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

1. **Pierwsze wywołanie** — cache MISS, płacisz pełną cenę (+ 25% za zapis do cache)
2. **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

1. **RAG** wyciąga trafne chunki przez pgvector
2. Zamiast surowych chunków, dociągnij **pełne artykuły** z których pochodzą
3. 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

1. **Rola** — "Jesteś asystentem helpdesku firmy X"
2. **Zasady** — odpowiadaj tylko na podstawie KB, nie zgaduj, bądź konkretny
3. **Ton** — przyjazny ale profesjonalny, per "Ty", bez nadmiernej formalności
4. **Gdy zna odpowiedź** — odpowiedz + podaj źródło (tytuł artykułu)
5. **Gdy NIE zna odpowiedzi** — eskalacja z podsumowaniem tematu (nie zgaduj!)
6. **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

1. **Start** — RAG z pgvector, text-embedding-3-small, chunki 500 tokenów, TOP_K = 5
2. **Optymalizacja** — skalibruj progi na prawdziwych pytaniach, dodaj pełne artykuły zamiast chunków
3. **Cache** — włącz prompt caching jeśli masz dużą KB i duży ruch na jednym tenancie
4. **Auto-odpowiedzi** — po kilku tygodniach, gdy sugestie są dobre, włącz automatyczne wysyłanie dla odpowiedzi z wysoką pewnością
5. **Multi-model** — testuj tańsze modele (GPT-4.1 Mini, Gemini Flash) dla prostszych pytań, droższe dla złożonych

---

**Źródła:**
- [Dokumentacja Prompt Caching — Anthropic](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching)
- [OpenAI Embeddings](https://platform.openai.com/docs/guides/embeddings)
- [pgvector — PostgreSQL vector similarity search](https://github.com/pgvector/pgvector)


---

## Powiązane

- [Jak pisać prompty do helpdesku AI — przykład, porównanie modeli i pułapki](https://intum.dev/ai-w-praktyce/jak-pisac-prompty-do-helpdesku-ai-przyklad-porownanie-modeli-i-pulapki.md)
- [Claude Sonnet 4.6 z 1M kontekstu — cennik, porównanie modeli i praktyczne wnioski](https://intum.dev/modele-ai/claude-sonnet-4-6-z-1m-kontekstu-cennik-porownanie-modeli-i-praktyczne-wnioski.md)