Scoring Methodology

Le Moteur de Décision RAG vs Fine-Tuning évalue quatre classes d'architecture — RAG, Fine-Tuning, Long-Context et Hybrid — par rapport à neuf dimensions de votre cas d'usage. Cette page explique comment chaque dimension est pondérée, comment les estimations de coût sont dérivées et comment la confiance et le risque sont rapportés.

1. Les neuf dimensions de scoring

Chaque dimension contribue par des points positifs ou négatifs à une ou plusieurs classes d'architecture. Les points ne sont pas des pourcentages — ce sont des signaux additifs. La classe avec le score total le plus élevé l'emporte. La marge entre la première et la deuxième classe détermine la confiance.

  • Fraîcheur des données

    À quelle fréquence vos données sources changent. Les données en temps réel (1) favorisent fortement RAG car les modèles fine-tuned ne peuvent pas incorporer de nouvelles informations sans cycle de ré-entraînement. Les données statiques (5) suppriment l'avantage clé de RAG.

  • Volume de documents

    La taille de votre corpus de connaissances. De petits corpus (<10K docs, score 1) peuvent tenir dans une fenêtre long-context. Des corpus massifs (>10M docs, score 5) excluent long-context et favorisent fortement la récupération vectorielle.

  • Volume mensuel de requêtes

    Total des appels d'inférence par mois. À très haut volume (>1M/mois), les coûts de récupération par requête s'accumulent et peuvent rendre fine-tuning plus économique. À faible volume (<10K/mois), la surcharge d'infrastructure penche la balance vers long-context.

  • Précision des citations

    Si votre cas d'usage nécessite des références vérifiables. Citation de niveau audit (4) favorise fortement RAG ou hybrid, car les modèles fine-tuned hallucinent la provenance — ils ne peuvent pas citer des sources qu'ils n'ont pas vues à l'entraînement.

  • SLA de latence

    Votre budget de latence end-to-end en millisecondes. RAG ajoute un saut de récupération de 100–400 ms. Si votre SLA est inférieur à 500 ms, fine-tuning (sans récupération) peut être nécessaire. Long-context ajoute du surcoût TTFT à grand nombre de tokens.

  • Sensibilité des données

    Classification réglementaire et de confidentialité de vos données. Haute sensibilité (4–5) limite quels fournisseurs API hébergés vous pouvez utiliser pour la récupération, et peut nécessiter une infrastructure d'embedding et d'inférence auto-hébergée.

  • Spécificité du domaine

    Comment spécialisé est votre vocabulaire de domaine et format de sortie. Les domaines hautement spécialisés (4–5) avec jargon propriétaire, schémas de sortie ou voix de marque bénéficient plus de l'adaptation au niveau des poids du fine-tuning que de la simple récupération.

  • Capacité ML

    Votre maturité d'ingénierie ML interne (1 = pas d'équipe ML, 5 = de classe mondiale). Les architectures fine-tuning et hybrid nécessitent une expertise ML pour concevoir, entraîner, évaluer et maintenir. Les équipes de basse capacité devraient utiliser RAG ou long-context par défaut.

  • Plafond de budget

    Dépense mensuelle maximale. Si le coût estimé de l'approche leader dépasse 120 % de votre plafond, le moteur applique une pénalité. Budget < 2K $ exclut généralement hybrid ; <5K $ peut exclure fine-tuning quand l'entraînement est amorti.

2. Signaux composés

Au-delà des scores individuels par dimension, le moteur applique des signaux composés qui capturent les interactions entre dimensions :

  • Haut volume + citations strictes : Si requêtes mensuelles ≥ 1M et citations = 4, Hybrid reçoit +20 supplémentaires car RAFT amortit le coût d'entraînement tout en préservant la précision de citation.
  • Faible volume + budget bas + non isolé : Long-context reçoit +15 car déployer une infrastructure vectorielle n'est pas économiquement justifié.
  • On-premises ou isolé : Fine-Tuning et Hybrid reçoivent +15/+10 car ils peuvent être déployés auto-hébergés, tandis que long-context (qui requiert des appels API hébergés) est pénalisé −20.
  • Pénalité de budget : Si le coût mensuel estimé d'une approche dépasse 120 % de votre plafond, cette approche reçoit −15 points.

3. Méthodologie d'estimation des coûts

Les estimations de coût sont dérivées de votre volume mensuel de requêtes, des comptes moyens de tokens et des données de prix LLM en direct récupérées de notre base de modèles. La formule pour chaque classe :

RAG (mensuel)

Coût unique d'embedding (amorti sur 6 mois) + frais de Vector DB (en paliers selon volume du corpus) + tokens de récupération (prix d'entrée modèle de génération) + tokens d'entrée et de sortie de génération + 15 % de surcharge opérationnelle.

Fine-Tuning (mensuel)

Coût d'entraînement (1 200–25 000 $, selon spécificité) amorti sur 6 mois + inférence fine-tuned à 1,2× le prix du modèle de base + réserve de ré-entraînement (2× coût initial / an).

Long-Context (mensuel)

Tokens de document par requête × prix d'entrée du modèle de génération + tokens de sortie × prix de sortie, moins économies de prompt-cache (votre taux de cache × 70 % de remise) et économies de batch-API (votre taux éligible × 50 % de remise).

Hybrid / RAFT (mensuel)

Tous les coûts RAG + 60 % des coûts Fine-Tuning (reflète la réalité que RAFT requiert à la fois infrastructure de récupération et un cycle d'entraînement, mais l'inférence en temps de requête est plus efficace que RAG pur).

Le prix Vector DB est en paliers selon le volume du corpus (échelle 1–5 mappée à 70–3 000 $/mois), basé sur les prix observés de pgvector, Pinecone, Weaviate et Qdrant au T1 2026. Les prix de tokens LLM sont récupérés en direct de notre base de modèles et basculent sur des défauts conservateurs (3 $/1M entrée, 12 $/1M sortie) si la base est indisponible.

4. Marge de confiance

La confiance est déterminée par la marge de points entre la classe gagnante et le second :

  • Confiance haute : marge ≥ 25 points — une approche domine clairement.
  • Confiance moyenne : marge 10–24 points — un leader clair mais le second est viable.
  • Confiance basse : marge < 10 points — plusieurs approches sont étroitement appariées ; un proof-of-concept avec les deux est recommandé.

Si le score gagnant est inférieur à 40, le moteur active aussi un « drapeau de redéfinition » indiquant qu'aucune approche ne domine — typiquement un signe que la portée du cas d'usage devrait être réduite avant d'engager une infrastructure.

5. Registre des risques

Le moteur évalue sept déclencheurs de risque contre vos entrées et la recommandation gagnante. Chaque risque a un niveau de sévérité (haut, moyen ou bas) et une recommandation de mitigation :

  • Risque de Citations Hallucinées (haut) : Fine-Tuning recommandé + citations ≥ 3.
  • Plafond de Budget en Risque (moyen) : Coût estimé > 90 % de votre plafond déclaré.
  • Risque de Violation de Résidence des Données (haut) : résidence UE ou haute sensibilité + Long-Context recommandé.
  • Écart de Capacité ML (moyen) : Capacité ≤ 2 + Fine-Tuning ou Hybrid recommandé.
  • Données de Prix Périmées (bas) : Données de prix Vector DB de plus de 90 jours.
  • Risque de Dérive du Corpus (moyen) : Fraîcheur ≤ 2 + Fine-Tuning recommandé.
  • Budget de Latence en Risque (haut) : SLA de latence < 500 ms + RAG ou Hybrid recommandé.

6. Limitations et hypothèses

  • Les estimations de coût sont indicatives uniquement. Les coûts réels dépendent du fournisseur, de la taille du modèle, de la configuration d'infrastructure et des prix négociés.
  • Le modèle de scoring est délibérément opinable et basé sur des patterns de production observés chez des clients Buzzi au T1 2026. Il ne remplace pas une revue architecturale par un ingénieur ML expérimenté.
  • Le moteur ne modélise pas le multi-tenancy, la surcharge des tests A/B, le coût du pipeline d'évaluation ou le coût d'étiquetage des données pour le fine-tuning.
  • Le coût Hybrid / RAFT suppose un seul cycle de ré-entraînement par fenêtre de 6 mois. Les équipes avec des besoins de ré-entraînement plus fréquents devraient augmenter le diviseur d'amortissement de l'entraînement.