docs(kb): zamkniecie Etapu B fazy mailowej + session log 2026-08-06
Pelny korpus gmail zchunkowany i zembedowany: 389 012 chunkow,
0 nie-excluded bez wektora. Weryfikacja plastrami 0-4 (wszystkie EXIT 0)
plus fix bajtu NUL (4ec0b78). Krok 6 -> WYKONANE, Krok 7 (przyrostowka
IMAP/JMAP) oznaczony jako next.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
oskar
parent
4ec0b7876c
commit
83bb7ab130
65
docs/sessions/2026-08-06-kb-etapb-backfill.md
Normal file
65
docs/sessions/2026-08-06-kb-etapb-backfill.md
Normal file
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue