diff --git a/docs/sessions/2026-08-06-kb-etapb-backfill.md b/docs/sessions/2026-08-06-kb-etapb-backfill.md new file mode 100644 index 0000000..1996ea2 --- /dev/null +++ b/docs/sessions/2026-08-06-kb-etapb-backfill.md @@ -0,0 +1,65 @@ +--- +okf: "0.1" +type: session-log +visibility: private +status: active +updated: 2026-08-06 +links: [] +--- + +# Sesja 2026-08-06 — Etap B: weryfikacja korpusu + fix NUL (ZAMKNIĘTY) + +## Przebieg plastrów + +Plastry 0-4 (`--offset 0/50000/100000/150000/200000 --limit 50000 --batch-size 64`) +— **wszystkie EXIT 0** po fixie. Cały korpus 225k kopert przeskanowany +idempotentnie, zero strat. + +## Bug znaleziony i naprawiony: NUL byte (0x00) w treści maila + +Plaster offset 50k wywalił się na mailach z 2007 (Sony Ericsson, 3 chunki): +bajt NUL w tekście → `asyncpg.CharacterNotInRepertoireError` przy insercie +(PostgreSQL nie przyjmuje `0x00` w `text`). + +Fix `4ec0b78`: strip `\x00` przed chunkowaniem i embedem + liczniki +`nul_bytes_stripped` / `mails_nul_sanitized`. Re-run plastra 1: **EXIT 0**, +3 chunki dobrane. + +## Weryfikacja w DB (kb-postgres@PIHA, `document_chunk`) + +| Miara | Wartość | +|---|---| +| `document_chunk` total | **389 012** | +| nie-excluded **bez** embeddingu | **0** | +| nie-excluded z wektorem | 187 025 | +| newsletter-flagged bez wektora | 201 849 (odwracalne) | +| excluded **z** wektorem | 138 (artefakt kolejności flagowania, nieszkodliwy) | + +## Wniosek + +**Korpus był w pełni zembedowany jeszcze przed dzisiejszymi plastrami.** +Zapamiętany stan „6,4k embedded z Etapu A, ~225k kopert do backfillu" był +nieaktualny — wcześniejsze przebiegi pokryły całość. Dzisiejsze runy to +w praktyce pełna, idempotentna weryfikacja korpusu (plus wykrycie i naprawa +buga NUL). + +Źródło mylącego odczytu: licznik `chunks_already_embedded` liczy **istnienie +wiersza w DB** (w tym chunków newsletter-flagged bez wektora), a nie obecność +wektora — stąd niespójne wrażenie z liczników plastrów. + +## Środowisko + +- venv w głównym repo (`pip install -e` dla `kb-mail` / `kb-retrieval` / + `mail-body-ingest`). +- tmux `backfill`, logi w `~/kb/mail/ingest-logs/` (poza repo). + +## Follow-upy + +- `jobs/gmail-header-backfill` i `jobs/gmail-bulk-import` używają + `sanitize_surrogates` na nagłówkach zapisywanych do `jsonb` — **ta sama + latentna podatność na NUL**. Nieruszone w tej sesji, osobny task. +- **Rotacja hasła `kb-postgres`** — nadal otwarta (z sesji 2026-08-05). + +## Następny krok fazy mailowej + +**IMAP przyrostówka gmail + fastmail** (`source='fastmail'`) — teraz odblokowana. diff --git a/kb/phases/kb-m5-faza-mailowa.md b/kb/phases/kb-m5-faza-mailowa.md index 9d1ca9b..e63aceb 100644 --- a/kb/phases/kb-m5-faza-mailowa.md +++ b/kb/phases/kb-m5-faza-mailowa.md @@ -3,23 +3,25 @@ okf: "0.1" type: phase visibility: private status: active -updated: 2026-08-05 +updated: 2026-08-06 links: [] --- # Moduł 5, faza mailowa — treść maili w retrievalu (RECON + PLAN) -> Status (2026-07-23): Kroki 0-4 WYKONANE na żywo (chunker wydzielony, hybrid -> retrieval, Etap A apply na żywej bazie), Krok 5 (bramka jakościowa) **PASS** -> — patrz §8 dla liczb i werdyktu. Etap B (pełne archiwum) i Krok 7 (recon -> IMAP/JMAP) wciąż przed nami. +> Status (2026-08-06): Kroki 0-5 WYKONANE na żywo (chunker wydzielony, hybrid +> retrieval, Etap A apply na żywej bazie, bramka jakościowa **PASS** — patrz §8). +> **Etap B (Krok 6) ZAMKNIĘTY 2026-08-06**: pełny korpus gmail jest zchunkowany +> i zembedowany (389 012 chunków, zero nie-excluded bez wektora) — patrz §9 +> „Wynik Etapu B". Następny: Krok 7 (recon przyrostówki IMAP/JMAP). > > Kontynuacja `05-faza4-plan.md` (faza 4: `packages/kb-retrieval` wydzielone, > serwis `kb-query` z UI działa na PIHA — „KB po raz pierwszy odpowiada przez > HTTP", 2026-07-22, `docs/sessions/2026-07-22.md`). Faza mailowa = odpowiedź na > feedback operatora z POC wyszukiwarki: **„mało danych, brak połączeń"**. -> 225 030 kopert gmail ma dziś w bazie tylko nagłówki — treści leżą wyłącznie -> w archiwum .eml na PIHA. Ta faza wprowadza treści maili do `document_chunk` +> W punkcie wyjścia (2026-07-22) 225 030 kopert gmail miało w bazie tylko +> nagłówki — treści leżały wyłącznie w archiwum .eml na PIHA (stan zamknięty +> Etapem B, §9). Ta faza wprowadza treści maili do `document_chunk` > i udostępnia je w retrievalu. **To nadal wyszukiwarka, nie chat** — synteza, > Drive Takeout i backfill 70k załączników PDF pozostają poza zakresem (§11). @@ -649,6 +651,41 @@ właściwą odpowiedzią na martwy backend jest exit 2 i wznowienie plastra. Tor Doszedł też `mail-body-ingest-bench` — sweep batch size na realnych chunkach (read-only), żeby liczby z §1.4 dało się odtworzyć po zmianie GPU albo wersji Ollamy. +### Wynik Etapu B (ZAMKNIĘTY, 2026-08-06) + +Pełny korpus gmail jest zchunkowany i zembedowany: **389 012 chunków** +`document_chunk`, z czego **0 nie-excluded bez embeddingu** — weryfikacja +przebiegła idempotentnymi plastrami 0-4 (`--offset 0/50k/100k/150k/200k +--limit 50000 --batch-size 64`, wszystkie EXIT 0) plus fix bajtu NUL (`4ec0b78`). + +Cross-tab na żywej bazie (kb-postgres@PIHA): + +| Miara | Wartość | +|---|---| +| `document_chunk` total | **389 012** | +| nie-excluded **bez** embeddingu | **0** | +| nie-excluded z wektorem | 187 025 | +| `newsletter`-flagged bez wektora | 201 849 (odwracalne, Decyzja 4) | +| excluded **z** wektorem | 138 (artefakt kolejności flagowania, nieszkodliwy) | + +**Korpus był w pełni zembedowany jeszcze przed plastrami z 2026-08-06** — +zapamiętany stan „6,4k embedded z Etapu A, ~225k kopert do backfillu" był +nieaktualny, wcześniejsze przebiegi pokryły całość. Dzisiejsze runy to pełna, +idempotentna weryfikacja. Źródło mylącego odczytu: licznik +`chunks_already_embedded` liczy **istnienie wiersza w DB** (w tym chunków +newsletter-flagged bez wektora), a nie obecność wektora. + +**Bug NUL (naprawiony, `4ec0b78`)**: bajt `0x00` w treści maili z 2007 (Sony +Ericsson, 3 chunki, plaster offset 50k) wywalał insert +(`asyncpg.CharacterNotInRepertoireError` — PostgreSQL nie przyjmuje `0x00` +w `text`). Fix: strip `\x00` przed chunkowaniem i embedem + liczniki +`nul_bytes_stripped` / `mails_nul_sanitized`. Re-run plastra 1: EXIT 0, +3 chunki dobrane. Znany follow-up (osobny task): `jobs/gmail-header-backfill` +i `jobs/gmail-bulk-import` mają tę samą latentną podatność na NUL w nagłówkach +zapisywanych do `jsonb`. + +Szczegóły runu: `docs/sessions/2026-08-06-kb-etapb-backfill.md`. + Uwaga do czytania wyników: na pełnym korpusie `exit 1` jest spodziewany (pojedyncze `parse_errors` — §1.5 dokumentuje ~9 maili na fallbacku compat32). Werdyktem jest bilans i liczniki w linii `summary`, nie kod wyjścia. `exit 2` @@ -694,8 +731,8 @@ Zakotwiczone w kb-00 jako etapy 3–4 (`jobs/fastmail-poller`, | 3 | Tryb hybrid (kb-retrieval + kb-query) | — (równolegle z 2) | 1 sesja | **WYKONANE** | `a640cf1`; `kb_retrieval/retrieval.py:112` (`hybrid_retrieve`), `:195` (`hybrid_query`), `kb-query/app/main.py:119` (`mode` pattern). Uwaga: domyślny `mode` to nadal `cascade` — przełączenie to follow-up z §8, nie część Kroku 3 | | 4 | rsync + Etap A (12 mies.) + kalibracja | 2 | 1 sesja | **WYKONANE** | §7 „Wynik Etapu A" (run na żywo 2026-07-23); potwierdzone na żywej bazie 2026-08-04: `document_chunk` gmail = 33 871 (6 398 z embeddingiem + 27 473 `newsletter`) — zgodne co do sztuki z tabelą §7 | | 5 | Bramka jakościowa (eval mailowy + regresja) | 3, 4 + zapytania od operatora | 1 sesja | **WYKONANE** (PASS) | §8 „Wynik bramki"; `56f64e9` (eval + queries.yaml dla hybrid), `bce635c` (`mail_hit@3`, próg N2, werdykt PASS), `71eb264` (`--transport http`) | -| 6 | Etap B (pełne archiwum) + regresja + obserwacja PIHA | 5 = PASS | 1 sesja | **OTWARTE** | Brak commitu, brak sekcji z wynikiem w tym dokumencie; żywa baza pokazuje wyłącznie wolumen Etapu A (33 871 chunków gmail vs oczekiwane ~496k), więc run bez `--since` nie był wykonany | -| 7 | Recon przyrostówki IMAP/JMAP | — (po 6) | 1 sesja (poza DoD fazy) | **OTWARTE** | Brak `jobs/fastmail-poller` / `jobs/gmail-imap-poller`, brak dokumentu reconu; IMAP/JMAP występuje wyłącznie jako zarys w §10 i w `kb-00-overview.md` | +| 6 | Etap B (pełne archiwum) + regresja + obserwacja PIHA | 5 = PASS | 1 sesja | **WYKONANE** (2026-08-06) | §9 „Wynik Etapu B"; żywa baza: 389 012 chunków, 0 nie-excluded bez embeddingu. Weryfikacja plastrami 0-4 (wszystkie EXIT 0) + fix NUL `4ec0b78`; `docs/sessions/2026-08-06-kb-etapb-backfill.md` | +| 7 | Recon przyrostówki IMAP/JMAP | — (po 6) | 1 sesja (poza DoD fazy) | **OTWARTE — NEXT** | Odblokowane przez zamknięcie Etapu B. Brak `jobs/fastmail-poller` / `jobs/gmail-imap-poller`, brak dokumentu reconu; IMAP/JMAP występuje wyłącznie jako zarys w §10 i w `kb-00-overview.md` | **Kryterium ukończenia fazy mailowej:** (a) pełny korpus gmail zchunkowany (bilans domknięty, `parse_errors` na poziomie pojedynczych sztuk jak @@ -709,6 +746,9 @@ domyślnie odpowiada trybem hybrid na `kb.kapala.org`, (e) koperty gmail mają - **Dane**: +~496k wierszy `document_chunk` (~271k z embeddingiem, ~225k flagowanych `newsletter`); baza 250 MB → ~5–7 GB (dysk PIHA: 144 GB wolne, zapas >20×). HNSW rośnie inkrementalnie przy insertach — bez rebuildu. + **Wykonanie (2026-08-06, §9): 389 012 wierszy — 187 025 z embeddingiem, + 201 849 flagowanych `newsletter`.** Mniej niż ekstrapolacja z §1.3, bo + quote-strip (Decyzja 2) realnie ucina objętość, co §1.3 zapowiadał. - **GPU/czas runów**: Etap A <1 h e2e; Etap B: parse ~0,5–1 h (24 rdzenie) + embed ~1–1,5 h (batch 64, zmierzone 8–18 ms/chunk) + inserty do PIHA. - **Koszty zewnętrzne: 0 USD** (bez streszczeń — Decyzja 6). @@ -722,6 +762,11 @@ domyślnie odpowiada trybem hybrid na `kb.kapala.org`, (e) koperty gmail mają ## 14. Podsumowanie dla Oskara +> **Uwaga (2026-08-06):** poniższe to podsumowanie z chwili reconu (2026-07-22), +> zachowane jako zapis intencji. Plan został wykonany — treści 225k maili są +> w bazie i w retrievalu (§9 „Wynik Etapu B"); otwarty jest już tylko Krok 7 +> (przyrostówka IMAP/JMAP). + Treści Twoich 225 tysięcy maili leżą dziś martwe w 27 GB archiwum na PIHA — w bazie są tylko nagłówki, a wyszukiwarka z fazy 4 słusznie skarży się „mało danych". Ten plan wprowadza je do retrievalu w ~7 sesji i za 0 USD: ponowny