Przewodnik • Wiedza i źródła

RAG — Retrieval‑Augmented Generation

RAG podnosi rzetelność odpowiedzi, ale tylko wtedy, gdy jest traktowany jak system: SSOT, kontrakt cytowań, metryki jakości i operacje.

Powiązane: Chunking i indeksowanie Powiązane: Ewaluacja RAG Powiązane: ADR RAG vs fine‑tuning
Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Wiedza i źródła i ma formę Przewodnik. Poniższe dopowiedzenie ma jeden cel: przełożyć treść na działania, które da się wdrożyć, zmierzyć i utrzymać.

Checklista

  • Ustal SSOT i hierarchię źródeł (co jest kanoniczne, co pomocnicze).
  • Zaprojektuj retrieval: filtry, hybryda (keyword+semantics), reranking.
  • Wprowadź cytowania i atrybucję (proweniencja w odpowiedzi).
  • Zadbaj o świeżość i konflikty źródeł (zasady rozstrzygania).
  • Monitoruj jakość retrieval (trafność, pokrycie, dryft).
  • Zastosuj uprawnienia, redakcję danych i logowanie zapytań.

Najczęstsze pułapki

  • RAG bez cytowań – nie da się audytować, skąd wzięła się teza.
  • Chunking „na oko” – zbyt duże lub zbyt małe fragmenty psują trafność.
  • Brak polityki świeżości – model miesza stare i nowe wersje informacji.
  • Ignorowanie uprawnień – wycieki danych przez zbyt szeroki kontekst.

Artefakty w Luage

context_packet sources:ssot citations_contract retrieval_metrics access_policy

Standard działa dopiero wtedy, gdy ma właściciela, wersję, ślad (trace) oraz test regresyjny.

W skrócie
  • RAG podnosi rzetelność, ale tylko przy kontrakcie cytowań i bramkach dowodowych.
  • Jakość to nie „trafność” — to pokrycie, atrybucja i stabilność w czasie.
  • Bezpieczeństwo: ACL, poisoning, prompt injection przez dokumenty, redakcja danych.
  • Operacje: reindeks, monitoring, regresje i kontrola kosztu.
RAG: bez wiedzy vs z retrieval i cytowaniami
RAG nie „ulepsza” modelu — dostarcza mu kontekst i wymusza atrybucję. Cała reszta to inżynieria kontraktu.

1. Definicja: co RAG rozwiązuje (a czego nie)

Retrieval‑Augmented Generation (RAG) to praktyka, w której odpowiedź modelu jest kondycjonowana przez fragmenty dokumentów pobrane z kontrolowanego korpusu (SSOT). RAG jest sensowne wtedy, gdy:

  • wiedza się zmienia (freshness),
  • odpowiedź musi być weryfikowalna (cytowania),
  • obowiązują ograniczenia prawne/umowne (ACL, licencje),
  • nie chcemy (lub nie możemy) trenować modelu na danych organizacji.
RAG nie zastępuje jakości źródeł. Jeśli SSOT jest niespójny, przeterminowany albo nie ma kanoniczności, retrieval będzie jedynie szybciej dostarczać sprzeczne fragmenty.

2. Kiedy RAG ma sens

Najczęstsze przypadki użycia: support, dokumentacja, procedury, compliance, on‑boarding i szkolenia. Sygnały, że RAG jest właściwym kierunkiem:

  • pytania użytkowników powtarzają się, ale odpowiedź zależy od wersji dokumentu, produktu lub regionu,
  • potrzebna jest ścieżka dowodowa („skąd to wynika?”),
  • koszt błędu jest wysoki (regulacje, finanse, bezpieczeństwo).

3. Minimalna architektura RAG

Minimalny pipeline ma pięć kroków. Każdy z nich ma własne metryki i tryby awarii:

  1. Ingest — pozyskanie i normalizacja dokumentów (format, metadane, ACL).
  2. Index — chunking, embedding, indeks (wektorowy / hybrydowy), wersjonowanie.
  3. Retrieve — wyszukiwanie, filtrowanie po metadanych (np. tenant, region).
  4. Rerank — porządkowanie fragmentów (często kluczowe dla jakości).
  5. Compose — złożenie kontekstu, odpowiedź i cytowania.
Brak kontraktu cytowań zwykle kończy się „ładną odpowiedzią”, której nie da się obronić. W Compendium cytowania są traktowane jak interfejs — teza musi mieć dowód.

4. Jakość: metryki i test harness

RAG testuje się inaczej niż klasyczne wyszukiwanie. Minimalny zestaw:

  • Coverage: czy odpowiedź znajduje właściwe źródło?
  • Attribution: czy cytowanie naprawdę wspiera tezę?
  • Faithfulness: czy model nie dodaje treści spoza kontekstu?
  • Stability: czy wynik nie „pływa” po zmianie indeksu lub modelu?

W praktyce nie wystarczy „accuracy”. Potrzebny jest golden set i regresje po każdej zmianie: chunking, embedding, reranker, prompt, polityka cytowań.

5. Bezpieczeństwo i zgodność

RAG otwiera nowy wektor ataku: dokument staje się częścią kontekstu. Trzeba kontrolować:

  • ACL: retrieval musi respektować uprawnienia użytkownika/tenantu.
  • Poisoning: złośliwe treści w korpusie mogą sterować odpowiedzią (prompt injection „w dokumencie”).
  • PII: redakcja danych i retencja — źródła często mają dane osobowe.
  • Link rot: jeśli cytowania odwołują się do URL, trzeba mieć kanoniczność i wersje.

6. Operacje: świeżość i monitoring

RAG żyje w czasie. Minimalny standard operacyjny:

  • reindeks i rollback (indeks@ver),
  • monitoring driftu jakości i kosztu,
  • trace dla retrieval (query, filtry, top‑k, źródła),
  • replay trudnych przypadków (bez danych wrażliwych).

7. Checklist wdrożeniowy

  • SSOT: kanoniczność, wersjonowanie, świeżość, metadane, ACL.
  • Pipeline: chunking + embeddings + retrieval + rerank + compose.
  • Cytowania: kontrakt teza → dowód + tryb no‑answer.
  • Testy: golden set + regresje, mierzenie coverage/attribution.
  • Operacje: monitoring, reindeks, rollback, audyt.
Powiązane
Na tej stronie
Spis
    Nawigacja
    ← Poprzedni Następny →
    Status merytoryczny
    Metryka (wersja, owner, terminy przeglądu) jest wypełniana automatycznie na podstawie manifestu.