Procedura

Inkrementalna budowa grafu i wersjonowanie

Procedura utrzymania grafu w czasie: diff, update, reindeksacja, regresje, rejestr zmian i rollback.

W skrócie
  • Graf musi być odtwarzalny (reproducibility) i stabilny (ID)
  • Pipeline inkrementalny: diff → update → reindex → regresje
  • Rollback jest elementem bezpieczeństwa, nie luksusem
  • Release notes łączą zmianę z trace
Jeżeli nie potrafisz cofnąć release grafu, to w praktyce nie masz kontroli nad jakością.
Cel operacyjny: graf musi być odtwarzalny. To oznacza: wersjonowane źródła, deterministyczny pipeline i testy regresji.

1. Zasady

  • Reproducibility: ten sam zestaw źródeł + ta sama wersja pipeline = ten sam graf.
  • Stability: identyfikatory są stabilne, merge ma tombstone, a cytowania nie znikają bez śladu.
  • Fail‑closed: brak dowodu / brak polityki dostępu = brak publikacji.

2. Model zdarzeń (co może się zmienić)

Najczęstsze zdarzenia, które powinny uruchamiać aktualizację grafu:

  • nowa wersja dokumentu SSOT (zmiana treści lub statusu),
  • zmiana ontologii (schemat),
  • zmiana reguł polityki dostępu,
  • zmiana konfiguracji ekstrakcji/linkingu (pipeline).

3. Workflow inkrementalny

Cykl: ingest → diff → update graph → reindeksacja → regresje → release notes
  1. Diff: wykryj, co się zmieniło (doc_id@ver, chunk_id, status).
  2. Re‑extract: przelicz kandydatów dla zmienionych fragmentów.
  3. Merge: aktualizuj encje/relacje; usunięcia realizuj przez tombstone, nie przez „ciszę”.
  4. Reindex: przebuduj indeksy zależne (vector + graph traversal cache).
  5. Regresje: golden set, progi, analiza drift.
  6. Release notes: wpis do rejestru zmian + link do trace.

4. Wersjonowanie i rollback

Dla grafu zalecamy wersję „publikacyjną” (np. graph@2026.01.10) oraz możliwość cofnięcia rollout. Rollback nie jest luksusem — jest warunkiem bezpiecznych zmian.

  • Blue/green: dwa indeksy, przełączanie ruchu po przejściu regresji.
  • Canary: część zapytań na nowy graf, z porównaniem metryk.
  • Freeze: przy incydencie blokujemy publikację nowych wersji do czasu diagnozy.

5. Regresje i progi publikacji

Minimalne testy dla GraphRAG to nie tylko „czy odpowiedź brzmi sensownie”. Testujemy:

  • czy ścieżka relacji jest poprawna (path accuracy),
  • czy dowody są kompletne (evidence coverage),
  • czy nie rośnie liczba konfliktów źródeł,
  • czy nie pogarsza się latencja i koszt (budżety).

Szczegóły: Ewaluacja GraphRAG.

6. Monitoring i metryki

  • liczba nowych/zmienionych encji i relacji per release,
  • odsetek relacji bez dowodów (powinien być 0),
  • dystrybucja confidence,
  • latencja planera i traversal,
  • drift: różnica wyników między wersjami grafu.

7. Powiązane

Na tej stronie
Spis
    Wskazówka
    Publikuj graf w trybie blue/green. Canary dopiero wtedy, gdy masz stabilny zestaw regresji.