← Retour au controleur

/paper // The Math

Pourquoi le dispatch fonctionne, meme a 0.726 AUROC

1. Le Dana Theorem — SAT constructif

Toute fonction indicatrice sur un domaine fini discret peut etre encodee comme une instance SAT en temps polynomial. Le bucketing par arbre de decision reduit a un temps lineaire.

f: {0,1}^n → {0,1} ⇒ φ_C en CNF, construction O(n × b × m)
Avec bucketing: O(L × n × b × m) — lineaire en n

Snake ne resout pas SAT — il construit des formules structurees ou les donnees sont l'assignation. La NP-durete de SAT s'applique a la recherche d'assignations pour des formules arbitraires. Snake ne fait jamais ca.

2. Le probleme du dispatch — 7 classes, 8 features

Le controleur doit classifier chaque interaction dans l'une des 7 taches :

TachePrecisionRecallF1AUROC
controle_facture0.6250.5000.5560.747
classification_email0.5290.4500.4870.680
demande_devis0.3750.4500.4090.719
reclamation_client0.7650.6500.7030.826
scoring_prospect0.5290.4500.4870.659
benchmark_offre0.4090.4500.4290.721
negociation_offre0.2960.4000.3400.730

47.9% accuracy sur 7 classes. Random = 14.3%. Le modele est 3.3× random.

Pourquoi c'est difficile

Une facture par email et un devis par email partagent la plupart des features : canal=email, has_montant=1, ton=formel, has_produit_mention=1. Les features discriminantes sont rares :

facture:     has_refs_fournisseur=1, has_montant=1, document_type=facture
devis:       has_refs_fournisseur=0, has_montant=0, has_produit_mention=1
negociation: has_refs_fournisseur=1, has_montant=1, has_objection=1
benchmark:   has_refs_fournisseur=1, has_montant=1, has_objection=0

→ facture vs benchmark: separation sur document_type seul
→ negociation vs facture: separation sur has_objection seul
→ devis vs prospect: quasi-identiques sur 8 features

8 features categoriques/booleennes ne suffisent pas a separer 7 classes avec des profils aussi similaires. Le AUROC (0.726) confirme que le signal existe mais est faible.

3. Dispatch + specialise bat monolithique

P(correct) = P(dispatch correct) × P(specialiste correct)

Dispatch (0.80) × Specialiste (0.95) = 0.76
Monolithique seul = ~0.65

Le dispatcher n'a pas besoin d'etre parfait. Il doit etre assez bon pour que le specialiste prenne le relais. Un dispatcher a 80% qui route vers un classifier a 95% donne 76% combined — mieux qu'un monolithe a 65%.

L'intuition

Quand le dispatcher est sur (confiance > 0.8), il a raison ~90% du temps. Quand il hesite (confiance ~0.3), il a raison ~40%. Le systeme peut exploiter cette calibration :

4. Feature expansion — 8 → 20

Le modele actuel utilise 8 features. Chaque feature supplementaire ajoute du signal dans l'espace de separation :

Feature candidateSignal attenduClasse aidee
word_countProspect = court, facture = longscoring_prospect
sender_domain_typeInterne vs externe vs inconnuclassification_email
n_product_linesFacture/benchmark = multi-lignesbenchmark_offre
montant_rangeBucket 0/petit/moyen/grandnegociation_offre
has_deadlineDevis et reclamation = urgentdemande_devis
language_detectedFR/EN/mixedall
has_attachment_refFacture = PJ PDFcontrole_facture
n_entitiesBenchmark = multi-fournisseursbenchmark_offre
text_lengthEmail court vs document longclassification_email
has_pricing_tableFacture/benchmark structureecontrole_facture
sentiment_urgencyReclamation = negatif/urgentreclamation_client
has_legal_mentionConditions generales = facturecontrole_facture

Target: AUROC > 0.85 avec 20 features. Le Dana Theorem garantit que la construction SAT reste polynomiale quel que soit le nombre de features.

5. Ensemble — Claude + Snake

Claude voit le texte complet et produit tache_detectee. Snake voit 8 features structurees et produit sa propre prediction. Deux signaux independants :

Quand Claude = Snake (estim. ~70% des cas):
  → Confiance maximale, route automatique

Quand Claude ≠ Snake (~30% des cas):
  → Flag pour revue humaine
  → Ou: voter par confiance (Claude prob vs Snake prob)

L'ensemble n'a pas encore ete teste empiriquement. C'est la prochaine etape apres le feature expansion.

Roadmap: 8 features (0.726) → 20 features (~0.85) → ensemble Claude+Snake (~0.92)

6. Dual-mode extraction — graceful degradation

The controleur operates in two modes (/genesis for full details):

Mode 1: Haiku enabled (anthropic=true)
  Text → Claude Bedrock extraction → rich JSON → Snake dispatch
  Latency: ~1-3s | Quality: high | extraction_mode: "haiku"

Mode 2: Regex fallback (anthropic=false, default)
  Text → regex pattern matching → minimal JSON → Snake dispatch
  Latency: ~10-50ms | Quality: viable | extraction_mode: "regex_fallback"

Snake classifies in both modes. The 8 features are derived differently but the model is the same. This means the controleur never fails — it degrades gracefully from LLM-backed extraction to pattern-matched extraction.

Reliability: P(viable response) = 1.0
Quality: P(correct route | haiku) ≈ 0.80, P(correct route | regex) ≈ 0.60
← Retour au controleur