Trei probleme legate, gasite testand cu capturi reale.
1. RASPUNSURI GENERICE. Cand raspunsul nu era in documente, modelul primea
oricum top-3 chunk-uri si compunea ceva plauzibil — utilizatorul pleca cu
impresia ca a primit ajutor. Acum, daca nu avem acoperire, modelul nu mai e
intrebat deloc: intrebarea pleaca la suport, cu referinta (M-260831-A1B2) si
confirmare onesta — "am trimis" doar daca notificarea chiar a plecat, altfel
"am inregistrat, dar nu am putut trimite". Jurnalul se scrie intotdeauna, in
~/.maria-bridge/escalations/, si se vede in dashboard. Daca a fost o captura,
imaginea insasi se retrimite la suport (endpoint nou /send-image, limitat la
MEDIA_DIR).
2. ORDONARE (rank.py). Un prag pe cosinus nu putea decide "avem raspunsul?":
masurat pe indexul viu, intrebarile bune dau 0,600-0,816 si cele straine
0,534-0,685 — intervale care SE SUPRAPUN. Lipseau codurile: ORA-01722, D406,
CIF sunt tokeni exacti pe care cautarea semantica ii topeste. Acum se ordoneaza
de doua ori — embeddings si BM25 — si se fuzioneaza clasamentele (RRF), iar
decizia de acoperire se ia pe dovezi: cosinus mare, sau cosinus de mijloc cu o
fractiune din termenii distinctivi gasita chiar in chunk-uri. Fractiunea conteaza:
cu un singur termen, "cum imi resetez parola de la Windows" trecea drept
acoperita fiindca "parola" apare in documente.
Pragurile sunt masurate, nu alese: ops/calibrate-rank.py ruleaza un set de cazuri
pe indexul real si matura grila. 15/15 la strong=0.70 weak=0.58 ratio=0.5.
3. DICTIONAR DE ERORI ORACLE. 29 de erori uzuale, scrise pentru utilizatorul din
fata aplicatiei: ce inseamna, ce poate incerca singur, cand sa sune. Fara nume
de servere, IP-uri sau pasi de administrare — Maria e chatbot pentru clienti.
Fisierul din git e SAMANTA: depozitul e oglinda Drive-ului, deci trebuie pus in
document_store ca sa nu dispara la sincronizare.
Pe drum, doua lucruri gasite in log:
- fiecare mesaj din self-chat sosea de DOUA ori, pe @s.whatsapp.net si pe @lid,
deci Maria raspundea de doua ori. Dedup pe key.id in punte.
- reindexarea reface toate embeddings-urile (~7 s fiecare pe CPU): adaugarea unui
document la 170 de chunk-uri insemna 20 de minute. Acum refoloseste vectorii
chunk-urilor nemodificate din indexul precedent, fara vreun fisier nou de stare.
Textul OCR se logheaza acum INTEGRAL, cu interogarea de cautare si sursele alese
cu scorurile lor — fara asta un raspuns gresit nu se poate explica: nu stiai daca
a citit prost captura sau a cautat prost in documente.
6 fisiere de test noi/extinse, 68 pass (de la 42).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4uzvgm7AyJch5WH8QHRhY
Descoperit la prima sincronizare reala din Drive: `maria-sync.timer` a pornit
peste rularea manuala si doua procese faceau embeddings in paralel pe acelasi
Ollama, ambele urmand sa scrie acelasi rag_index.json. Embedding-ul a incetinit
de la ~7s la ~20s din concurenta, iar ultimul care termina ar fi suprascris
munca celuilalt.
- config.exclusive(): lacat `flock` intre procese, luat la intrarea in sync.py si
indexer.py. Nu asteapta — a doua rulare iese curat cu "o reindexare e deja in
curs", fiindca ar reface exact acelasi lucru. Verificat pe procese reale.
- indexer scrie indexul atomic (tmp + os.replace): consumer-ul reciteste fisierul
la 30s si putea prinde un JSON pe jumatate scris.
- build() intoarce `warnings` pentru XML-urile care nu se pot parsa, iar rularea
din linia de comanda le scrie in stderr. Pana acum, un XML invalid se indexa
tacut ca text simplu, cu o singura linie pierduta in log.
Context de performanta, masurat pe LXC 171 fara alta incarcare: un embedding
`nomic-embed-text` ia ~7,3s, deci o reindexare completa a celor 173 de chunk-uri
dureaza ~21 de minute — mai mult decat intervalul timer-ului. Nu e o problema
practica (amprenta reindexeaza doar la schimbare, iar lacatul opreste
suprapunerea), dar explica de ce prima rulare pare blocata.
docs/rclone-google-drive-headless.md: procedura de conectare a unui container
headless la Drive prin `rclone authorize`, cu transcriptul rularii reale de pe
Windows, capcanele (sync e distructiv pe destinatie, connection string in loc de
cale pe nume, unde stau secretele) si de ce nu contul de serviciu. Indexata in
CLAUDE.md.
6 teste noi (lacat, eliberare la exceptie, scriere atomica, avertismente).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4uzvgm7AyJch5WH8QHRhY
Dosarul document_store din Drive are 3 surse .xml pe care depozitul le ignora
complet, fiindca store.py accepta doar .txt/.md. La d406_saft_knowledge exista
ambele formate, iar .xml e cu trei luni mai nou (2026-01-28 vs 2025-10-15) si cu
50% mai mare (64 KB vs 41 KB) — deci indexam varianta mai saraca.
- store.py devine sursa unica pentru extensii (DOC_EXTENSIONS = .txt/.md/.xml).
Cand acelasi nume de baza exista in mai multe formate, la indexare intra unul
singur, cel mai bogat (.xml > .md > .txt); celalalt ramane pe disc, marcat
`shadowed_by`. Fara asta, acelasi raspuns ar aparea de doua ori in rezultate.
`list_documents()` arata tot (dashboard), `documents_for_index()` doar
castigatorii (indexer).
- indexer.py taie XML-ul altfel: un chunk per element de nivel 1, adica o
problema = un chunk, cu <mesaj_eroare> si <rezolvare> impreuna. Taierea pe
linii goale le-ar separa si cautarea ar returna eroarea fara raspuns.
Etichetele raman prefixe lizibile ("mesaj eroare: ..."), fara paranteze
unghiulare care doar dilueaza embedding-ul. XML invalid nu opreste indexarea:
cade pe taierea obisnuita, cu o linie in log. Elementele peste 4000 de
caractere se taie mai departe pe granite de cuvant — `chunk_text` imparte doar
pe linii goale, deci un element scris ca un paragraf lung ar fi ramas intreg
(prins de test).
- sync.py: amprenta si `rclone --include` derivate din DOC_EXTENSIONS.
- dashboard: acelasi filtru si aceeasi preferinta (copie, fiindca nu poate
importa `store` — coliziune de nume pe `config`), plus marcajul "umbrit de X"
in tabelul de documente si numarul de documente chiar indexate.
- README: sectiunea Drive rescrisa pe `rclone authorize` (autorizezi pe o masina
cu browser, muti tokenul) in loc de cont de serviciu — mai putini pasi, fara
consola Google Cloud. Documentat si ca `sync` sterge local ce nu mai e in Drive.
tests/ nou (20 de teste, fara retea si fara Ollama): preferinta de format,
vizibilitatea in dashboard, taierea XML, entitati, comentarii, XML invalid,
elemente uriase. Suita puntii Discord: 426 pass, neafectata.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4uzvgm7AyJch5WH8QHRhY
Move the /tmp prototype (Baileys bridge + RAG consumer) into git as a
proper sibling project to discord-bridge/: own systemd --user units
(whatsapp bridge, rag consumer, dashboard, periodic Drive sync timer),
a filesystem document store with a stdlib control dashboard (start/
stop/restart, document CRUD, reindex, Google Drive sync via rclone),
and an idempotent ops/install.sh following the same conventions.
Co-Authored-By: Claude Agent <noreply@anthropic.com>
