ADR • Wiedza i źródła

ADR: RAG vs fine‑tuning

Kiedy wybrać RAG, kiedy fine‑tuning, a kiedy hybrydę — wraz z kryteriami decyzji i konsekwencjami operacyjnymi.

Powiązane: RAG Powiązane: Monitoring retrieval
ADR w skrócie
Architecture Decision Record utrwala decyzję, jej powody i konsekwencje. Jest „pamięcią organizacji” — szczególnie przy zmianach modeli i wiedzy.
  • Decyzja: wybór RAG vs fine‑tuning zależy od świeżości i ścieżki dowodowej.
  • Ryzyko: fine‑tuning utrudnia audyt i odwracalność zmian.
  • W praktyce: często kończy się hybrydą (RAG + małe dostrojenie).
Metadane ADR
Status
Accepted (dla domeny „wiedza i procedury”)
Data
2025‑10‑10 (pierwotna decyzja), uaktualniona 2026‑01‑10
Owner
Architektura / ML Platform
Zakres
Systemy odpowiedzi oparte o dokumenty i procedury (support, compliance, docs)

1. Kontekst

Organizacja potrzebuje systemu, który odpowiada na pytania na podstawie firmowej wiedzy. Wiedza zmienia się, musi być wersjonowana, a odpowiedzi muszą być audytowalne (kto, kiedy, na jakiej podstawie).

2. Kryteria decyzji (drivers)

  • Świeżość: jak często zmienia się treść?
  • Atrybucja: czy potrzebne są cytowania i dowód?
  • Odwracalność: czy można wycofać zmianę szybko i bezpiecznie?
  • Koszt: tokeny vs koszt treningu i utrzymania pipeline’u.
  • Compliance: gdzie są dane, jak je usunąć, jak audytować.

3. Opcje

Opcja Plusy Minusy Kiedy ma sens
RAG świeżość • cytowania • łatwy rollback jakość zależy od SSOT i retrieval wiedza zmienna, wymagany audyt
Fine‑tuning styl i format mogą być stabilniejsze trudniejszy audyt • trudniejszy rollback • ryzyko „starych faktów” powtarzalne formaty, klasyfikacja, ekstrakcja
Hybryda RAG dla faktów + tuning dla formatu większa złożoność operacyjna gdy potrzeba i dowodu, i stabilnego stylu

4. Decyzja

Dla domeny „wiedza i procedury” wybieramy RAG jako domyślny mechanizm faktów. Fine‑tuning dopuszczamy tylko, gdy:

  • celem jest format/klasyfikacja, a nie świeże fakty,
  • dane treningowe są czyste i zgodne (privacy/compliance),
  • jest plan wersjonowania i rollbacku modelu.

5. Konsekwencje

  • Inwestujemy w SSOT: kanoniczność, wersje, reindeks.
  • Wprowadzamy kontrakt cytowań i bramkę „no‑answer”.
  • Traktujemy retrieval jako element krytyczny (monitoring, metryki, testy).

6. Follow‑ups

  • Ustalić minimalne metryki coverage/attribution dla domeny.
  • Zdefiniować politykę retencji embeddingów i logów retrieval.
  • Opracować standard „hybrydy” dla przypadków formatu (structured outputs).
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.