Doua greseli din grupul "Maria Test", 2026-09-01, pe care 27409fb le-a atenuat dar
nu le-a rezolvat.
1. La o reclamatie vaga Maria cauta, in loc sa intrebe. "Buna . Am si eu o factura
pe luna august cu eroare in spv la trimitere AUTO SULE" nu spune CE eroare e —
n-are ce cauta in documente si n-are ce trimite la suport, fiindca programatorul
ar pune exact aceeasi intrebare. Gardul (triaj.prea_vag) exista, dar cerea text
sub 12 cuvinte; mesajul are 14. Gresea si invers: "nu pot incarca factura in SPV,
imi da eroare de certificat" are 9 cuvinte si ARE raspuns in documente, si era
oprita degeaba. Lungimea nu masoara cat de precis e mesajul.
-> gardul nu mai numara cuvinte si se aplica DUPA cautare, doar cand nu exista
acoperire. O singura data pe fir: daca nici intrebat omul nu spune mai mult,
mesajul pleaca la suport.
2. Textul si captura, trimise una dupa alta, erau tratate ca doua probleme fara
legatura. `este_continuare` rupea firul la ORICE imagine — dar cazul frecvent e
tocmai omul care scrie problema si trimite captura imediat dupa, sau care
raspunde la "trimite-mi o captura". Textul se pierdea, captura se cauta doar pe
OCR-ul ei, se deschideau doua fire si se puteau deschide doua escaladari pentru
aceeasi problema.
-> o captura in primele FIR_IMAGINE_MIN (5) minute continua firul: textul citit
din ea intra in ancora (cu tot cu coduri), cautarea se face pe mesaj +
captura, iar pe o escaladare deschisa pleaca la aceeasi referinta — cu
imaginea, nu doar cu textul citit din ea (_notifica_suport ia si media).
Si, ca urmare a lui (2): RANK_STRONG_COSINE dispare. Interogarea pe un fir e ancora
plus mesajul nou, deci cosinusul urca la fiecare replica fara sa apara vreo dovada
noua — aceeasi captura da 0,778 singura si 0,836 cu mesajul de dinainte, adica peste
0,80 pus ieri. Orice prag fix de sus e trecut de o discutie destul de lunga. Acoperirea
ramane pe dovada lexicala (termenii distinctivi ai intrebarii chiar in chunk-uri),
care e stabila la lungime. Niciun caz cu raspuns in documente nu avea nevoie de
scurtatura.
ops/calibrate-rank.py: 26/26, cu interogarea combinata adaugata la set. Teste: 102 pass.
Verificat end-to-end pe scenariul real (mesaj, apoi captura la 10 secunde): intrebare
de detalii, apoi o singura escaladare care poarta si textul si captura.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4uzvgm7AyJch5WH8QHRhY
Grupul "Maria Test", 2026-09-01, ambele mesaje au primit raspunsuri inventate:
- "am si eu o factura pe luna august cu eroare in spv la trimitere AUTO SULE"
(cosinus 0,768) — mesajul nu spune CE eroare e; Maria a explicat cum se reface
o factura stearsa si a trimis omul sa verifice drepturile pe CIF in SPV.
- captura cu `<Error errorMessage="CUI cumparator incorect"/>` (0,778) — eroarea
nu exista in niciun document; Maria a inventat o procedura cu "ID de descarcare",
Borderou eFactura si retrimitere manuala.
Cauza: `RANK_STRONG_COSINE=0,70` inseamna "cosinusul singur e destul", dar toate
chunk-urile eFactura seamana intre ele — la 0,7x cosinusul nu mai distinge "e in
documente" de "e despre eFactura". Aceeasi greseala ca la codurile Oracle
(ORA-06550 vs ORA-12541, b7d75f0), doar ca fara cod pe care sa te sprijini.
- RANK_STRONG_COSINE 0,70 -> 0,80: peste atat trec doar potrivirile aproape
textuale, restul cad pe dovada lexicala (termenii rari ai intrebarii chiar in
chunk-uri). Ambele mesaje escaladeaza acum la suport.
- LLM_TEMPERATURE=0 la apelul modelului. Fara el llama.cpp foloseste 0,8 —
creativitate exact acolo unde vrem doar ce scrie in context.
- Cele doua cazuri reale sunt adaugate in ops/calibrate-rank.py: 25/25.
Teste: 99 pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4uzvgm7AyJch5WH8QHRhY
O captura cu ORA-06550 / PLS-00906 primea raspunsul despre ORA-12541 (TNS no
listener) si nu pleca la suport. Cauza: doua erori Oracle diferite se scriu
aproape la fel ("[Oracle][ODBC][Ora]ORA-..."), asa ca chunk-ul gresit a iesit la
cosinus 0,736 — peste RANK_STRONG_COSINE, care scurtcircuita orice alta dovada.
Chunk-ul corect din dictionar exista, dar statea pe pozitia 4, in afara TOP_K:
OCR-ul unei ferestre intregi aduce zeci de tokeni de zgomot, iar BM25 ineca tocmai
codul.
- `rank.codes()` scoate codurile de oriunde din text, nu doar ca token intreg —
OCR-ul le lipeste de ce e langa ("OraJORA-06550").
- `rank.by_codes()` e un al treilea clasament in fuziune: chunk-ul care poarta
codul cerut urca peste cele care doar seamana. Acum iese primul.
- `rank.assess()`: cand intrebarea are coduri, decid doar ele. Niciun cod gasit =
escaladare la suport, oricat de mare ar fi cosinusul.
- `consumer.search()` judeca acoperirea pe cosinusul chunk-urilor date chiar
modelului, nu pe cel mai bun din tot indexul.
Calibrare 21/21 (cele 19 cazuri + captura reala + ORA-00600, cod care nu e in
documente si trebuie sa plece la suport). Teste: 79 pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4uzvgm7AyJch5WH8QHRhY
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
