„Va fi calitatea propunerilor ca după corecturile mele manuale?”
Întrebarea ta, pusă după ce ai reparat de mână două propuneri într-o singură zi. Răspunsul măsurat pe 152 de apeluri reale și 54 de rulări Hermes în staging.
Și ăsta e rezultatul corect. Schimbarea nu face modelul mai deștept — face sistemul să nu mai pretindă că știe ce nu știe. Munca ta de legare nu dispare; devine vizibilă și corect atribuită, în loc să fie ascunsă sub o certitudine falsă.
Actualizare 28 iulie, iterația a doua (ADR-0105). După ce am reconstituit cum a lucrat sesiunea ta de corectură, am găsit golul real — contextul, nu modelul — și l-am închis. Pe apelul substanțial, extracția produce acum autonom forma corecturii tale. Detaliile în actul 07, mai jos.
Telefonul spune cine sună, nu a cui e afacerea
Când intră un apel prin ClickPhone, sistemul caută numărul în agendă. Găsește un client — și de aici încolo tratează acel client ca fiind subiectul de business al conversației. Pentru majoritatea apelurilor e corect. Pentru Ioana, nu.
Ioana e puntea de comunicare pentru cafeneaua Ginei. Potrivirea pe telefon e corectă ca persoană de contact și greșită ca subiect de business. Apasă fiecare câmp.
În toată istoria: 152 de apeluri, din care 136 legate doar la un client, fără proiect. Asta e forma normală, nu excepția.
Ce a spus modelul vs. ce s-a salvat
Pe apelul de 24 de minute din 27 iulie, modelul a făcut exact ce trebuia: a refuzat să aleagă o țintă. Sistemul a salvat altceva.
Ce a returnat modelul
blocker: primary_business_target_missing
rezumat: „apelul e clar despre Maine Coon Cafe; Ioana e doar intermediar”
modificări propuse: 0
Ce a persistat sistemul
primaryEntityId: Ioana
confidence: high
rationale: „The Call Artifact is already linked to this Client.”
Nu e un caz izolat. Din 183 de propuneri din toată producția, 113 poartă exact acea țintă fabricată cu încredere „high”.
Drumul principal, nu o ratare rară. De asta merită reparat.
Prima variantă a avertismentului era 92% zgomot
Reparația evidentă: pune un avertisment când ținta nu a fost confirmată de nimeni. Am scris-o, apoi am măsurat-o pe corpusul real — și m-a contrazis.
Un client Necesit e creat din cererea care purta acel număr de telefon. Acolo potrivirea pe telefon este identitatea clientului — apelul nu poate fi despre altcineva. Un avertisment acolo te învață să ignori linia, și atunci nu-l mai vezi nici pe cel real.
Cu excluderea, avertismentul selectează exact cele 6 apeluri unde un contact cunoscut vorbește despre afacerea altcuiva: puntea Maine Coon (4 apeluri, din 16 iunie, deci recurent, nu un incident) și cele 2 apeluri cu reprezentanții Necesit.
Testul: 27 de apeluri, două brațe, Hermes real
Snapshot de producție restaurat într-o bază izolată, docs copiate, CLI-urile de provider înfundate, automatizările oprite. Aceleași apeluri rulate de două ori: cod actual vs. cod cu schimbarea. 54 de rulări.
| Grup | n | blocate B→F | tip identic | avertisment nou |
|---|
Grupul de control — 16 apeluri obișnuite de lead Necesit — a ieșit identic ca tip de propunere, cu zero avertismente și zero blocări în plus. Asta era grija principală: că schimbarea face modelul fricos peste tot. Nu o face.
Răspunsul direct: cât de aproape ajunge de mâna ta
Cele două apeluri pe care le-ai reparat tu pe 27 iulie, în trei variante: ce scotea codul vechi singur, ce scoate codul nou singur, și ce ai făcut tu.
Pe apelul substanțial, codul nou ajunge foarte aproape de corectura ta singur — leagă apelul de proiect și actualizează task-ul existent, exact ca tine. Depășește ținta cu un candidat de plată pe care tu l-ai lăsat deliberat doar ca avertisment.
Pe apelul scurt, nu ajunge. Tu ai știut din context că e vorba de Maine Coon; transcriptul nu numește nimic. Codul nou blochează și îți spune de ce. Codul vechi inventa un task plutitor.
Deci: nu, calitatea nu devine egală cu a corecturilor tale. Ce se schimbă e altceva — sistemul nu mai produce lucruri care arată corecte și sunt greșite. Trece de la „am hotărât, cu încredere mare” la „nu știu, uite ce am, decide tu”.
Ce am construit și am aruncat
Ai cerut să nu supraadaptez. Am construit și o a treia bucată — proiecția de candidați, care ar fi oferit modelului proiectul Maine Coon derivat din apelurile anterioare de la același număr. Măsurată, apoi ștearsă.
Cât de des se declanșa
nu pentru că puntea e rară, ci pentru că legăturile la proiect sunt rare: 13 din 152.
Ce schimba pe acel apel
ambele brațe au blocat, aceleași zero acțiuni, aceleași 5 fapte. Modelul a văzut candidatul și l-a refuzat corect — transcriptul nu numea afacerea.
Actualizare: golul era contextul, și s-a închis
Corectura ta manuală era tot Hermes. Diferența: sesiunea ta de corectură a tras context la cerere — a căutat „Maine Coon”, a deschis packet-ul proiectului, a citit task-ul — pe când extracția primea un blob static legat de clientul potrivit pe telefon. Blockerul modelului chiar o spunea: „packet-ul nu mi-a dat ID-ul Maine Coon”. Avea numele, nu ID-ul.
Packet-ul primește acum un director de business: toate proiectele active și oportunitățile deschise, cu clientul și task-urile lor deschise (la scara instanței: 9 + 24 intrări, 12% din packet). Orice nume citit în transcript devine un ID acționabil. Plus: câmpurile de clasificare au devenit legale în output — contractul strict le interzicea, deși schema le accepta.
| Variantă | Rezultat | Clasificare | Țintă |
|---|---|---|---|
| Cod vechi | blocat, 0 acțiuni | other (fallback) | client greșit, „high” fabricat |
| + onestitate (ADR-0104) | blocat, 0 acțiuni | other (fallback) | „low”, onest |
| + director | link Maine Coon + update task exact | other (fallback) | „low”, onest |
| + clasificare | link + update task exact | maintenance_upsell | proiect, „high” cu motivația modelului |
Regresia: 16 apeluri obișnuite de lead — zero link-uri cross-client greșite, zero blocări noi, 15/16 identice. Singura diferență: un link same-client benefic cu reconciliere de task. Cross-link-urile au apărut doar pe cele două apeluri unde erau corecte.
Deci răspunsul final la întrebarea din titlu: da, acolo unde informația există în sistem — și exact asta era teza ta: tot contextul era în sistem, trebuia doar folosit la momentul potrivit.
Își merită locul?
Bara ta e cea mai curată soluție, complexitate minimă, niciodată construit înainte de primul consumator real. Aplicată aici:
Ce câștigi concret: pe cele 6 apeluri de tip punte primești o linie în Telegram care spune că nimeni nu a confirmat ținta — înainte să aprobi. Pe restul de 146, nu se schimbă nimic pentru tine. Iar propunerile nu mai afirmă niciodată o țintă pe care modelul a refuzat-o explicit.