Migracja 003 (UNIQUE+model, excluded_reason) zastosowana na żywej bazie kb-postgres@PIHA (2683 chunki, bez DELETE). Kalibracja heurystyki ocr_junk (3 sygnały z planu §3.1) ujawniła realną sprzeczność z planem: sygnał 1 (dowolny znak kontrolny) fałszywie łapał paperless:119 (wymagany aktywny) i legalny angielski tekst — próg doprecyzowany do >=5 wystąpień na podstawie rozkładu na korpusie. 8 chunków oflagowanych ocr_junk po odjęciu potwierdzonych fałszywych alarmów (kalendarz, mikro-fragmenty referencyjne). Dedup: SQL z planu (exact content hash) znalazł 2 pary, ale nie wykrył znanego z pilota duplikatu paperless:14≡74 (różne OCR, 99.2% chunków identycznych treściowo) — dodany fuzzy check na potwierdzenie. Odrzucono 3 kandydatury o wysokim nakładaniu jako różne wersje/typy dokumentów dzielące boilerplate PZU, nie duplikaty. 130 chunków oflagowanych duplicate + entities[duplicate_of] na 3 kopertach. chunk_embed.py: heurystyka is_ocr_junk() przed embedem (junk -> insert bez wywołania Ollamy, embedding=NULL), ON CONFLICT rozszerzony o model, nowy licznik chunks_junk_flagged w bilansie, testy (kody kreskowe, mojibake nie-junk, dot-leader, idempotencja, model w kluczu konfliktu). Weryfikacja: 7 zapytań eval-setu z WHERE excluded_reason IS NULL — żadne trafienie nie degraduje, kontrole negatywne bez zmian (>0.55), śmieć zniknął z top-5 zapytania 2, paperless:119 pozostał aktywnym trafieniem. Bilans: 2545 aktywne / 130 duplicate / 8 ocr_junk. Co najmniej 3 decyzje wymagały zatrzymania i potwierdzenia z Oskarem w sesji (kalibracja progu sygnału 1, dołączenie 14≡74 mimo braku exact-hash matcha, odrzucenie 3 fałszywych kandydatur dedup) — plan przewidywał, że heurystyka będzie się mylić; wszystkie decyzje udokumentowane w transkrypcie sesji. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| init | ||
| docker-compose.yml | ||
| env.example | ||
| healthcheck.sh | ||
| README.md | ||
| service.yaml | ||
kb-postgres
Postgres 16 + pgvector — KB spine on PIHA (Raspberry Pi 5, always-on). Stores the frozen envelope schema shared by all KB pillars (mails, documents, photos, transactions).
Runs here because the KB store must answer queries 24/7; SOLARIA (GPU/compute) is powered down intermittently. Embeddings/models still run on SOLARIA's GPU — only the Postgres+pgvector store lives on PIHA. The pgvector/pgvector:pg16 image is multi-arch and runs natively on arm64 (the Pi 5).
Port: 5433 on PIHA (Tailscale-accessible to other nodes).
Standard deploy (from SATURN)
# On SATURN — pushes to master, then deploy.sh SSHes to PIHA and runs deploy-node.sh
git push origin master
scripts/deploy/deploy.sh piha
deploy-node.sh on PIHA automatically picks up the per-host override:
docker compose \
-f services/kb-postgres/docker-compose.yml \
-f hosts/piha/runtime/kb-postgres/docker-compose.override.yml \
up -d --remove-orphans
The PIHA override caps memory (mem_limit: 1g) and tunes Postgres for a tight,
HA-shared RAM budget. Data lives in the kb_postgres_data named volume, which
must land on the NVMe (Docker data-root on /home), never the SD card —
verify before first deploy (see the override file's DATA PLACEMENT note):
# On PIHA
docker info -f '{{.DockerRootDir}}' # expect an NVMe path
df -h "$(docker info -f '{{.DockerRootDir}}')" # confirm it's the NVMe
First-time setup on PIHA (before first deploy)
The .env file must exist at services/kb-postgres/.env in the PIHA repo checkout
(alongside the compose file — that's where env_file: .env resolves to):
# On PIHA
cd ~/homelab-codex-ws
cp services/kb-postgres/env.example services/kb-postgres/.env
# Edit .env: set POSTGRES_PASSWORD to something strong
.env is gitignored (*.env rule in root .gitignore) — it will never be committed.
Manual one-off (debugging / first boot)
# On PIHA, from repo root
docker compose \
-f services/kb-postgres/docker-compose.yml \
-f hosts/piha/runtime/kb-postgres/docker-compose.override.yml \
up -d
Verify after first boot
# Host-side healthcheck
./services/kb-postgres/healthcheck.sh
# Inside the container
docker exec kb-postgres psql -U kb -d kb -c '\d envelope'
docker exec kb-postgres psql -U kb -d kb \
-c "SELECT extname FROM pg_extension WHERE extname = 'vector';"
Expected \d envelope output:
Table "public.envelope"
Column | Type | Nullable | Default
----------+--------------------------+----------+-----------
id | text | not null |
source | text | not null |
ts | timestamp with time zone | not null |
geo | jsonb | |
raw_ref | text | not null |
entities | jsonb | not null | '[]'::jsonb
Indexes:
"envelope_pkey" PRIMARY KEY, btree (id)
"envelope_source_idx" btree (source)
"envelope_ts_idx" btree (ts)
Schema contract
The envelope table is the frozen cross-source envelope (see docs/kb/kb-00-overview.md §Zasady przekrojowe). Adding columns is OK; removing or renaming existing ones is NOT.
Future migrations go in init/ as 002_*.sql, 003_*.sql, …. Postgres runs initdb scripts only on a fresh volume — for existing instances apply migrations with psql directly.
Connection string
postgresql://kb:<POSTGRES_PASSWORD>@piha:5433/kb
Set KB_TEST_DSN to this value when running integration tests from packages/kb-mail/
(host = piha over Tailscale).