Le problème de la prémisse initiale.
Le dépôt a commencé comme bot Telegram « psychologue ». Il conservait des conversations sensibles et présentait ses réponses générées comme plus proches d’un soin que le logiciel ne pouvait le justifier.
J’ai gardé une question technique utile : comment un petit classificateur apprend-il, et où échoue-t-il ? J’ai supprimé les comptes, les transcriptions, les diagnostics et les allégations thérapeutiques. Le nouveau projet expose le modèle, la partition des données, la politique de calibration et la limite de sécurité.
Ce qu’exige une expérience crédible.
La refonte devait rendre les fuites d’évaluation et l’incertitude plus difficiles à cacher :
- Les prompts apparentés restent groupés pour empêcher les paraphrases de passer entre entraînement et test.
- Calibration, sélection de politique, test in-distribution et test out-of-distribution ont des rôles de données séparés.
- Une preuve faible doit produire une abstention, pas une étiquette forcée.
- Les implémentations web et Rust vérifient le même artefact versionné et le même contrat d’inférence.
De l’exactitude d’une démo à un protocole.
Un seul score train/test ne répond pas aux questions essentielles : familles de prompts traversant la partition, seuils réglés sur le test final ou comportement hors du domaine d’entraînement.
Le protocole v3 gèle donc des partitions conscientes des groupes et sépare entraînement, calibration, sélection de la politique d’abstention et évaluation finale. Les types Rust excluent les tests finaux des API de sélection.
Le pipeline open-set.
Une validation TSV stricte alimente une partition déterministe par groupes. Un vocabulaire TF-IDF limité à l’entraînement et une régression logistique multinomiale produisent les probabilités ; le temperature scaling les calibre, puis une politique choisie séparément décide de l’abstention.
Pourquoi ces technologies.
La stack privilégie une expérience reproductible et inspectable plutôt qu’une capacité apparente maximale.
Rust pour le pipeline et la CLI.
- Pourquoi
- Les types, les builds verrouillés et un binaire portable rendent les rôles des données explicites et les parcours de vérification reproductibles.
- Ce que j’ai écarté
- Un notebook ou un pipeline uniquement Python faciliteraient l’exploration, mais laisseraient davantage d’état implicite et de dérive d’environnement.
- Ce que cela a coûté
- Nous acceptons un effort d’implémentation supérieur et un écosystème ML moins vaste.
TF-IDF avec régression logistique multinomiale.
- Pourquoi
- Cette approche est proportionnée à un petit corpus synthétique et permet d’inspecter poids, marges et calibration.
- Ce que j’ai écarté
- Un transformer serait plus opaque, plus coûteux et surdimensionné au regard des preuves disponibles.
- Ce que cela a coûté
- Nous acceptons une compréhension sémantique et une couverture linguistique limitées.
Un protocole imbriqué conscient des groupes.
- Pourquoi
- Il garde les familles de prompts ensemble et sépare choix du modèle, calibration et test final.
- Ce que j’ai écarté
- Une partition aléatoire laisserait passer des paraphrases apparentées et produirait des métriques artificiellement optimistes.
- Ce que cela a coûté
- Nous acceptons 506 entraînements, davantage de suivi expérimental et des intervalles d’incertitude visibles.
Une abstention calibrée.
- Pourquoi
- Un système open-set doit pouvoir refuser une preuve faible ou hors distribution au lieu de simuler la certitude.
- Ce que j’ai écarté
- Forcer une classe fournirait une réponse même lorsqu’aucune étiquette n’est étayée par les données.
- Ce que cela a coûté
- Nous acceptons une couverture moindre, un choix de seuil plus complexe et ne prétendons pas que l’abstention supprime le risque.
Les choix qui préservent l’honnêteté du résultat.
Le protocole d’évaluation fait partie du logiciel.
Limiter les conclusions aux données synthétiques
Résultats, intervalles et erreurs décrivent exclusivement les fixtures synthétiques versionnées de l’expérience. Ils ne sont pas étendus aux conversations réelles, aux contextes cliniques ni à une couverture linguistique générale.
Le compromisLa conclusion est plus étroite et moins spectaculaire, mais reste proportionnée aux preuves effectivement observées.
Publier tout le parcours de sélection
Bundle, plan des partitions, probabilités out-of-fold, affectations des folds et classement des candidats sont gelés et reliés par SHA-256 afin que le résultat retenu puisse être reconstruit.
Le compromisL’artefact demande davantage de travail à produire et à relire, mais empêche une seule métrique finale de masquer le parcours de sélection.
Expliquer la marge réelle
Les prédictions exposent probabilités, confiance, marge des deux premières classes et contributions reconstruisant l’écart des logits gagnants.
Le compromisCette attribution explique le calcul du modèle linéaire, pas le sens ou l’intention humaine.
Vérifications de reproduction et de publication.
Modèle, politique, métriques et plan de partition résident dans un bundle lié par SHA-256. La CLI peut le reconstruire, vérifier les contrats et exécuter une inférence batch bornée. Une précision de reporting déclarée maintient le bundle v3 identique octet pour octet sur les cibles prises en charge.
Rust et le navigateur exécutent des fixtures de parité sur le même modèle. Un rapport de sélection séparé, lié par SHA-256, publie chaque probabilité out-of-fold, affectation de fold et rang de candidat ; le navigateur recalcule ses métriques et échoue si les octets ou les agrégats changent.
Ce que démontre le projet.
ELIZA Lab démontre un workflow complet pour petit modèle : sélection imbriquée par groupes, calibration, choix de politique open-set, test gelé, vérification d’artefact et inférence locale.
Ce n’est ni un thérapeute, ni un détecteur de crise, ni un modèle de langage de production. Sa valeur tient à une expérience inspectable et reproductible plutôt qu’à une démo opaque.
Registre des preuves.
Les artefacts vérifiés présentent ensemble le résultat de sélection, le test gelé et les cas faibles :
- Protocole de sélection
- 385 lignes d’entraînement et de développement réparties en 77 familles passent par 11 folds externes et 5 internes groupés, soit 506 modèles ajustés.
- Résultat de sélection
- L’exactitude out-of-fold est de 62,597 % et le macro-F1 de 62,640 % ; l’intervalle à 95 % par famille pour l’exactitude va de 57,143 à 68,571 %.
- Test ID gelé
- Exactitude de 82,857 % et macro-F1 de 82,278 % sur 70 lignes synthétiques en anglais.
- Résultat open-set
- La politique gelée couvre 62,857 % des lignes ID et 11,11 % des lignes OOD ; l’AUROC OOD est de 0.80278 et le FPR à 95 % de TPR de 0.7778.
- Faiblesse connue
- La fixture de contraste de 28 lignes atteint 42,86 % d’exactitude par paire ; le projet ne masque pas cet échec.
Version publiée vérifiée v1.6.0 Vérification du
Cette étude de cas décrit la version immuable v1.6.0 au commit cacd4448. Le tag signé et les 20 artefacts attestés couvrent Linux x64, Windows x64, macOS Intel et Apple Silicon. Le corpus synthétique n’établit ni validité clinique, ni large couverture linguistique, ni aptitude à la production.