RAG — czym jest i kiedy ma sens?

Co to daje firmie?

Każdy model językowy — GPT, Claude, Gemini — zna tylko to, na czym był trenowany. Nie zna Twojego cennika, procedur reklamacji ani notatek z wdrożeń. Gdy zapytasz go o coś z tej wiedzy, zrobi jedną z dwóch rzeczy: odmówi albo zmyśli.

RAG (Retrieval-Augmented Generation) rozwiązuje ten problem w prosty koncepcyjnie sposób: zanim model odpowie, system wyszukuje w Twoich dokumentach fragmenty pasujące do pytania i dokleja je do zapytania. Model nie musi niczego „wiedzieć” — dostaje materiał źródłowy przy każdym pytaniu, tak jak pracownik, któremu podsuwasz właściwy segregator.

W praktyce oznacza to asystenta, który odpowiada na pytania o Twoje umowy, Twoją dokumentację techniczną i Twoje zgłoszenia — i potrafi wskazać, z którego dokumentu wzięła się odpowiedź.

Jak to działa?

Cały system składa się z dwóch przepływów: przygotowania wiedzy (raz, potem aktualizacje) i odpowiadania na pytania (za każdym razem).

Kluczowe pojęcia po kolei:

Fragmenty (chunki). Dokumentów nie wrzuca się do bazy w całości. Tnie się je na kawałki po kilkaset tokenów — na tyle małe, żeby wyszukiwanie było precyzyjne, i na tyle duże, żeby fragment niósł sens bez otoczenia.

Embeddingi. Każdy fragment jest zamieniany na wektor liczb, który reprezentuje jego znaczenie. Teksty o podobnym sensie mają podobne wektory — dzięki temu pytanie „ile trwa zwrot towaru” znajdzie fragment „reklamacje rozpatrujemy w 14 dni”, mimo że nie dzielą ani jednego słowa.

Baza wektorowa. Przechowuje embeddingi i umie błyskawicznie znaleźć wektory najbliższe wektorowi pytania. W małych projektach wystarczy rozszerzenie pgvector w PostgreSQL, którego i tak używasz.

Jak to wygląda w kodzie?

Minimalny szkielet zapytania RAG wygląda tak:

// 1. Embedding pytania — ten sam model co przy indeksowaniu dokumentów
const queryEmbedding = await embed(userQuestion);

// 2. Wyszukanie najbliższych fragmentów w bazie wektorowej
const fragments = await db.query(
  `SELECT tresc, zrodlo FROM dokumenty
   ORDER BY embedding <=> $1
   LIMIT 5`,
  [queryEmbedding],
);

// 3. Model dostaje fragmenty jako kontekst — i twarde reguly
const answer = await llm.complete({
  system:
    "Odpowiadasz WYLACZNIE na podstawie przekazanych fragmentow. " +
    "Jesli fragmenty nie zawieraja odpowiedzi, powiedz to wprost. " +
    "Zawsze wskazuj zrodlo.",
  messages: [
    {
      role: "user",
      content: `Fragmenty:\n${fragments.map((f) => f.tresc).join("\n---\n")}\n\nPytanie: ${userQuestion}`,
    },
  ],
});

Dwie rzeczy w tym kodzie są ważniejsze, niż wyglądają:

Gdzie projekty RAG się wykładają?

Z naszego doświadczenia problemy prawie nigdy nie leżą w modelu językowym:

To jest powód, dla którego wdrożenie RAG to w 70 procentach praca na danych, a w 30 na kodzie. Sama pętla zapytań jest prosta — jakość robi przygotowanie wiedzy.

Kiedy RAG ma sens, a kiedy nie?

RAG jest właściwym narzędziem, gdy:

• odpowiedzi mają wynikać z wewnętrznej, zmieniającej się wiedzy (procedury, oferty, dokumentacja, baza zgłoszeń),
• potrzebujesz wskazywania źródeł — w firmie odpowiedź bez źródła jest bezwartościowa,
• wiedza zmienia się zbyt często, żeby myśleć o trenowaniu modelu.

RAG nie jest właściwym narzędziem, gdy:

• pytania dotyczą wiedzy ogólnej — model radzi sobie bez dodatkowej bazy,
• „dokumentów” jest kilkanaście stron — wtedy prościej wkleić całość do kontekstu,
• problemem jest format odpowiedzi, nie wiedza — to rozwiązuje prompt, nie baza wektorowa.

Najczęstszy zdrowy początek to jeden wąski przypadek: regulaminy i procedury dla zespołu obsługi albo baza ofert dla handlowców. Działa, mierzy się efekt, dopiero potem rozszerza zakres.