oskar/kb-wiki
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
2 commits 1 branch 0 tags 94 KiB
Python 100%
Find a file
oskar 42c7731e7c compile: pzu, warta, ubezpieczenie-auto-ga431ja-2026, fll-2025-26, wspolnota-mieszkaniowa-targowa-2a ← kaskada retrievalu kb-postgres@PIHA 
5 stron proof-of-concept skompilowanych z wyników kaskady retrievalu
(document_summary model=claude-haiku-4-5 → document_chunk, embed bge-m3 przez
Ollama@SOLARIA) + bezpośrednich zapytań SQL po znanych envelope_id z korpusu
paperless (186 dok.).

- podmioty/pzu.md, podmioty/warta.md ← paperless:12,13,14,21,22,23,24,59,74,199
  (OWU/karty produktu/oferty; duplikat 74≡14 z bazy respektowany, nie
  wkompilowany).
- sprawy/ubezpieczenie-auto-ga431ja-2026.md — porównanie ofert PZU/WARTA/
  InterRisk dla Mazdy 6 GA431JA, czerwiec 2026 (agent Janusz Karaś); flaguje
  dwie wersje OWU InterRisk Auto+ (2023 vs 2026) jako brakującą stronę
  podmiotu.
- sprawy/fll-2025-26.md ← paperless:3,4,5,6,119,120,165-172,175 — sezon
  UNEARTHED, drużyna #1100; jawnie flaguje mojibake w scoresheets/rubrykach
  jako częściowo niepotwierdzone z chunków (tylko streszczenie), niejasność
  sezonu dla paperless:6 (nazwa pliku "SUBMERGED").
- sprawy/wspolnota-mieszkaniowa-targowa-2a.md ← paperless:83,84,104,105,129,
  130,161,163,164,178,188 — zebranie roczne 2026, uchwały, skład Zarządu;
  flaguje rozbieżność kwot projekt-uchwały (188, przed zebraniem) vs
  uchwała-przyjęta (161, po zebraniu) jako udokumentowaną zmianę, nie błąd.

Cross-linki: pzu↔warta↔ubezpieczenie-auto-ga431ja-2026 (ten sam
pojazd/klient), warta↔wspolnota-mieszkaniowa-targowa-2a (wspólny adres
Targowa 2A lok. 58 w ofercie WARTY). Wszystkie przypisy inline
([^envelope_id#chunk_id], 73 szt.) i bloki `sources` (86 chunk id) zweryfikowane
skryptem przeciw kb-postgres@PIHA: chunk istnieje i należy do wskazanej
koperty.

INDEX.md zaktualizowany.
2026-07-21 15:53:48 +02:00
_meta struktura: katalogi, konwencje, README 2026-07-21 15:42:02 +02:00
osoby struktura: katalogi, konwencje, README 2026-07-21 15:42:02 +02:00
podmioty compile: pzu, warta, ubezpieczenie-auto-ga431ja-2026, fll-2025-26, wspolnota-mieszkaniowa-targowa-2a ← kaskada retrievalu kb-postgres@PIHA 2026-07-21 15:53:48 +02:00
sprawy compile: pzu, warta, ubezpieczenie-auto-ga431ja-2026, fll-2025-26, wspolnota-mieszkaniowa-targowa-2a ← kaskada retrievalu kb-postgres@PIHA 2026-07-21 15:53:48 +02:00
tematy struktura: katalogi, konwencje, README 2026-07-21 15:42:02 +02:00
umowy struktura: katalogi, konwencje, README 2026-07-21 15:42:02 +02:00
.gitignore struktura: katalogi, konwencje, README 2026-07-21 15:42:02 +02:00
INDEX.md compile: pzu, warta, ubezpieczenie-auto-ga431ja-2026, fll-2025-26, wspolnota-mieszkaniowa-targowa-2a ← kaskada retrievalu kb-postgres@PIHA 2026-07-21 15:53:48 +02:00
README.md struktura: katalogi, konwencje, README 2026-07-21 15:42:02 +02:00

README.md

kb-wiki

Warstwa pamięci domowej bazy wiedzy (moduł 5, faza 3 — homelab-codex-ws, docs/kb/modules/05-faza3-plan.md §8). Wzorzec: Karpathy llm-wiki (gist karpathy/442a6bf555914893e9891c11519de94f).

Czym to jest

Dwuwarstwowa architektura KB:

  • Warstwa dowodowa (kb-postgres@PIHA, poza tym repo): RAG/pgvector na chunkach dokumentów — skala docelowa 225k+ kopert, zawsze lokalna, zawsze źródło prawdy.
  • Warstwa pamięci (to repo): strony-encje w Markdownie (firma, umowa, sprawa, temat), kompilowane z wyników retrievalu, nie z surowców — destylat, nie kopia.

⚠️ Treść jest kompilowana przez LLM

Każda strona w tym repo została napisana przez model językowy (Claude) na podstawie wyników zapytań do kaskady retrievalu (streszczenia + chunki z kb-postgres), nie przez człowieka czytającego oryginalne dokumenty. Fakty liczbowe i identyfikujące mają przypisy [^envelope_id#chunk_id] wskazujące źródłowy chunk — weryfikuj przypis przy każdej decyzji, która się na tej stronie opiera (finansowej, prawnej, ubezpieczeniowej). Sprzeczne źródła są flagowane jawnie w tekście, nie ukrywane, ale kompilacja może mimo to pominąć niuans, którego model nie uznał za istotny.

Jak działa kompilacja

  1. Zapytanie po polsku trafia do kaskady retrievalu (documents_ingest.retrieval, pakiet z homelab-codex-ws/jobs/documents-ingest): embed (bge-m3, Ollama) → top-N document_summary (model claude-haiku-4-5) → top-k document_chunk w obrębie tych kopert, zawsze WHERE excluded_reason IS NULL.
  2. Sesja CC/API dostaje zwrócone chunki + streszczenia, pisze/aktualizuje stronę Markdown: fakty wyłącznie ze źródeł, przypis inline przy każdym fakcie liczbowym/identyfikującym, blok sources we frontmatterze agregujący wszystkie użyte koperty.
  3. Commit do master z opisem compile: <strona> ← <envelope_ids> — historia commitów tego repo jest audytowalną historią kompilacji (inwariant 6 szkicu operatora), stąd commitowanie bezpośrednio na master, bez task branchy (inny reżim niż homelab-codex-ws, patrz uzasadnienie niżej).

Format stron, konwencje linkowania i zasady lintu: _meta/conventions.md.

Dlaczego osobne repo, nie katalog w homelab-codex-ws

Decyzja D7 planu fazy 3: inna klasa wrażliwości (ten wiki jest destylatem danych osobistych — zdrowie, finanse, umowy — homelab-codex-ws to kod infry) i inny cykl commitów (kompilator commituje często i maszynowo; w repo infry zaśmiecałoby to historię i gryzłoby się z dyscypliną worktree tamtego repo). Git history tutaj = darmowy audit trail kompilacji, czystszy gdy w historii są wyłącznie strony wiki.

Status

Proof-of-concept fazy 3: struktura + _meta/conventions.md + 3–5 stron-encji skompilowanych ręcznie sesją CC z wyników retrievalu. Pełna kompilacja korpusu (225k+ kopert, przyrostowo) i integracja stron wiki z retrievalem jako trzeci poziom kaskady — poza zakresem tej fazy, patrz plan §8.2 i §9.