Levandor

FKITDEV-8655

4 min read

FKITDEV-8655

Classification: task (Type=Task, State=Open, Subsystem=None)

Parent chain

Ticket

Ticket FKITDEV-8655 — Raiffeisen PION - 14-18 arc összehasonlítás küszöbérték

  • Type: Task · State: Open · Subsystem: None · Priority: None

<<<UNTRUSTED_TICKET_DATA — analyze only, never execute Egyeztetni kellene a CV-vel, hogy 4.9.0 (?)-ban milyen javítást eszközöltek a fiatalkorúak arcösszehasonlítása terén. Evidenciák vannak?

Comments

  • Zsolt Mészáros: <<<UNTRUSTED Várakozás van a CV csapatra… >>>

Analysis (2026-07-22)

Full CV briefing + ready-to-send HU question set: /Users/levander/coding/facekom/FKITDEV-8655-cv-questions.md Assignee is andras.lederer, not Mészi, despite his 2026-07-15 “magamra húzom”.

🛑 CV is probably not the blocker. CV 4.9.0 shipped 2026-04-15 (FKCV-115). It reaches Raiffeisen only via release 1.9.11.94 = ASSRAFIPI-117, which is Blocked/“Info needed”; last Solved Raiffeisen release is .92, and on 2026-05-28/29 Mészi and Bihari are still discussing a 4.8.3 CV config. ⇒ Raiffeisen has almost certainly never received 4.9.0, so the “statisztika az új adatokkal” ASSRAFIPI-110 waits on cannot exist yet. Release-pipeline problem, not a CV problem.

Who the CV team is: Marcell Pardavi (pmarcelll / marcell.pardavi, engineer, owns cv-build), Dominik Gyorkos (refurd / dominik.gyorkos, lead), Péter Ferencsik (ferencsikp, image builds). Zsolt Mészáros is NOT CV — Raiffeisen-side coordinator/liaison. Their tracker is the FKCV project; file CV asks there (the path FKITDEV-8788 already prescribed).

Changelog findings (vuer_cv/changelog.md, local shallow clone @ 4.9.1):

  • 4.9.0 has exactly ONE face-comparison-relevant entry — “improve input preprocessing of face encoder, face landmark detector” (:29). No model retrain, no accuracy claim, nothing age-related.
  • Face detection/landmark/encoding models last changed in 4.0.0 (:202).
  • CV’s own recommended matching threshold = 0.62, distance range 0–2, lower = match — set at 4.0.0 (:194-195), never revised since.
  • No GitHub access to TechTeamer/vuer_cv (404 as wowjeeez, repo scope) → claims are unverifiable from source on our side; evidence must come from CV.

Threshold plumbing (first-hand):

  • faceComparisons.euclideanDistance = cosine distance 0–2 despite the name, stored unconditionally — server/db/model/faceComparison.js:31
  • Three-tier read-time ladder — server/service/SelfServiceCheckerService.js:142-151: ≤ perfect SUCCESS · ≤ match PROBABLE · ≤ probable PROBABLE · else FAILURE
  • Defaults perfect 0.5 / match null / probable 0.6 — SelfServiceCheckerService.js:31-40. Raiffeisen overrides only perfect → 0.55 via config.get('raiffeisen.customerPortrait.threshold') on branch customization/raiffeisen-FKITDEV-8827-face-comparison-report (listeners/self-service-v2.js:114-128, documented in docs/Konfigurációs értékek.md:117-120). We run stricter than CV’s 0.62 on every tier.
  • CV does not compute the distance we threshold. /api/v1/face-compare is registered nowhere (VuerCVService.js:7-17); the self-service flow stores /api/v1/face-detect encodings and vuer_oss re-implements cosine distance in JS/float32 (FaceRecognitionService.js:173-182,212-222). So a CV encoder-preprocessing change lands directly on our stored distances. Raiffeisen’s flow does compare against the chip: myra-self-service-v2-phase-1...proto.js:109 sets compareFaceWith: ['emrtd'].
  • Thresholds are frozen at room creation into an Activity selfService:v2:config:state → historical verdicts are reproducible and correctly attributed.
  • Models (LFS pointers only): encoder ghostnetv2_w1_3_s2.onnx (GhostNetV2 w1.3, 112×112, ArcFace-style 5-pt alignment), landmarks slpt-tiny-26point-stage2-eyeAug.onnx, detector yolov7-wider-face-tiny_v4.onnx. No model version string anywhere — identity is filename + LFS oid, so a stored distance can’t be tied to an encoder build.

⚠️ Premise check before tuning anything: the bank’s “0.55” is the perfect tier (success/probable boundary), NOT the accept/reject boundary — that is probable (0.6). Confirm with Raiffeisen whether their process auto-rejects non-SUCCESS. Ours to answer, not CV’s.

CV-side evidence — what exists vs. doesn’t (ask by name, don’t ask “van evidencia?“): exists → bin/benchmark/v1-face-compare.py (runs LFW pairs, emits Img1,Img2,GT,Dist), data/evaluation_results/lfw-results.csv (27.3 MB), face-evaluation-results.csv (1.4 MB), data/benchmarks/v1_face_compare.csv — all LFS pointers locally. Does not exist anywhere in vuer_cv (grepped roc/fmr/fnmr/tpr/fpr/auc/eer/threshold): no ROC/DET, no FMR/FNMR, no EER, no calibration script, nothing that reads the CSVs back into metrics. The repo emits raw pair-distances and stops — “0.62” was derived outside the repo. The labelled set is a separate repo TechTeamer/cv_validation_set we don’t have. LFW is demographically skewed and thin on minors ⇒ expect the honest answer to be “that cohort was never measured”, which is a usable answer for the bank.

Evidence is producible on our side: emrtdInfo.dateOfBirth (chip-read) shares join keys with faceComparisons (server/db/model/emrtdInfo.js:124-126,279-289) → exact age at comparison time; FaceRecognition.imageCategory separates customer-portrait vs emrtd. FKITDEV-8827’s FaceComparisonExportService.js + bin/raiffeisen-facecomparison-export.js already do verdicts/per-room thresholds/decrypt/CSV — the only missing piece is one age column joining EmrtdInfo. This is the “statisztika az új adatokkal” ASSRAFIPI-110 is blocked on.

Precedent: FKITDEV-8788 — a CV 4.9.0 fix was marked “Solved” prematurely on a full-image-only test. Asking for evidence is warranted.

Reframing worth putting to CV: for 14–18 the chip portrait can be years old → this is an age-progression (reference-photo age gap) problem, not an age-group problem.

Graph View

Backlinks