Scoring Methodology

Il RAG vs Fine-Tuning Decision Engine valuta quattro classi di architettura — RAG, Fine-Tuning, Long-Context e Hybrid — contro nove dimensioni del tuo caso d'uso. Questa pagina spiega come ogni dimensione è ponderata, come vengono derivate le stime di costo e come vengono riportati confidenza e rischio.

1. Le nove dimensioni di scoring

Ogni dimensione contribuisce con punti positivi o negativi a una o più classi di architettura. I punti non sono percentuali — sono segnali additivi. La classe con il punteggio totale più alto vince. Il margine tra prima e seconda classe determina la confidenza.

  • Freschezza dei dati

    Con quale frequenza cambiano i tuoi dati sorgente. I dati in tempo reale (1) favoriscono fortemente RAG perché i modelli fine-tuned non possono incorporare nuove informazioni senza un ciclo di re-training. I dati statici (5) eliminano il vantaggio chiave di RAG.

  • Volume documenti

    La dimensione del tuo corpus di conoscenza. Corpus minuscoli (<10K documenti, punteggio 1) possono entrare in una finestra long-context. Corpus massicci (>10M documenti, punteggio 5) escludono long-context e favoriscono fortemente il retrieval basato su vettori.

  • Volume mensile di query

    Chiamate di inferenza totali al mese. A volumi molto alti (>1M/mese), i costi di retrieval per query si compongono e possono rendere il fine-tuning più conveniente. A volumi bassi (<10K/mese), l'overhead di infrastruttura inclina la bilancia verso long-context.

  • Accuratezza delle citazioni

    Se il tuo caso d'uso richiede riferimenti verificabili. Citazione di livello audit (4) favorisce fortemente RAG o hybrid, perché i modelli fine-tuned allucinano la provenienza — non possono citare fonti che non hanno visto al momento del training.

  • SLA di latenza

    Il tuo budget di latenza end-to-end in millisecondi. RAG aggiunge un hop di retrieval di 100–400 ms. Se il tuo SLA è sotto 500 ms, fine-tuning (senza retrieval) può essere necessario. Long-context aggiunge overhead TTFT a grandi conteggi di token.

  • Sensibilità dei dati

    Classificazione regolatoria e di confidenzialità dei tuoi dati. Alta sensibilità (4–5) limita quali provider API hosted puoi usare per il retrieval, e può richiedere infrastruttura di embedding e inferenza self-hosted.

  • Specificità del dominio

    Quanto è specializzato il tuo vocabolario di dominio e formato di output. Domini altamente specializzati (4–5) con gergo proprietario, schemi di output o voce del brand traggono più beneficio dall'adattamento a livello di pesi del fine-tuning che dal solo retrieval.

  • Capacità ML

    La tua maturità di engineering ML interno (1 = nessun team ML, 5 = world-class). Le architetture fine-tuning e hybrid richiedono expertise ML per progettare, addestrare, valutare e mantenere. I team a bassa capacità dovrebbero usare RAG o long-context come default.

  • Limite di budget

    Spesa mensile massima. Se il costo stimato dell'approccio leader supera il 120% del tuo limite, il motore applica una penalità. Budget < $2K esclude generalmente hybrid; <$5K può escludere fine-tuning quando il training è ammortizzato.

2. Segnali composti

Oltre ai punteggi individuali per dimensione, il motore applica segnali composti che catturano interazioni tra dimensioni:

  • Alto volume + citazioni rigorose: Se le query mensili ≥ 1M e citazioni = 4, Hybrid riceve +20 aggiuntivi perché RAFT ammortizza il costo di training preservando l'accuratezza delle citazioni.
  • Basso volume + basso budget + non air-gapped: Long-context riceve +15 perché far decollare un'infrastruttura vettoriale non è economicamente giustificato.
  • On-premises o air-gapped: Fine-Tuning e Hybrid ricevono +15/+10 perché possono essere distribuiti self-hosted, mentre long-context (che richiede chiamate ad API hosted) è penalizzato di −20.
  • Penalità di budget: Se il costo mensile stimato di un approccio supera il 120% del tuo limite dichiarato, quell'approccio riceve −15 punti.

3. Metodologia di stima dei costi

Le stime di costo sono derivate dal tuo volume mensile di query, conteggi medi di token e dati di pricing LLM live recuperati dal nostro database modelli. La formula per ogni classe:

RAG (mensile)

Costo una tantum di embedding (ammortizzato su 6 mesi) + tariffa Vector DB (a scaglioni per volume del corpus) + token di retrieval (prezzo input modello generazione) + token input e output di generazione + 15% di overhead operativo.

Fine-Tuning (mensile)

Costo della corsa di training ($1.200–$25.000, guidato dalla specificità) ammortizzato su 6 mesi + inferenza fine-tuned a 1,2× il prezzo del modello base + riserva di re-training (2× costo iniziale / anno).

Long-Context (mensile)

Token documento per query × prezzo input modello generazione + token output × prezzo output, meno risparmi di prompt-cache (il tuo tasso di hit della cache × 70% di sconto) e risparmi di batch-API (il tuo tasso eligible × 50% di sconto).

Hybrid / RAFT (mensile)

Tutti i costi RAG + 60% dei costi Fine-Tuning (riflette la realtà che RAFT richiede sia infrastruttura di retrieval che una corsa di training, ma l'inferenza in fase di query è più efficiente del RAG puro).

Il pricing Vector DB è a scaglioni per volume del corpus (scala 1–5 mappata a $70–$3.000/mese), basato sui prezzi osservati di pgvector, Pinecone, Weaviate e Qdrant al Q1 2026. I prezzi dei token LLM sono recuperati live dal nostro database modelli e ricadono su default conservativi ($3/1M input, $12/1M output) se il database non è disponibile.

4. Margine di confidenza

La confidenza è determinata dal margine di punti tra la classe vincitrice e la seconda classificata:

  • Confidenza alta: margine ≥ 25 punti — un approccio domina chiaramente.
  • Confidenza media: margine 10–24 punti — un leader chiaro ma il secondo è praticabile.
  • Confidenza bassa: margine < 10 punti — più approcci sono strettamente accoppiati; si raccomanda un proof-of-concept con entrambi.

Se il punteggio vincitore è sotto 40, il motore imposta anche un "flag di re-scoping" che indica che nessun singolo approccio domina — tipicamente un segno che l'ambito del caso d'uso dovrebbe essere ristretto prima di impegnare l'infrastruttura.

5. Registro dei rischi

Il motore valuta sette trigger di rischio contro i tuoi input e la raccomandazione vincitrice. Ogni rischio ha un livello di severità (alto, medio o basso) e una raccomandazione di mitigazione:

  • Rischio Citazioni Allucinate (alto): Fine-Tuning raccomandato + citazioni ≥ 3.
  • Limite di Budget a Rischio (medio): Costo stimato > 90% del tuo limite dichiarato.
  • Rischio Violazione Residenza Dati (alto): residenza UE o alta sensibilità + Long-Context raccomandato.
  • Gap di Capacità ML (medio): Capacità ≤ 2 + Fine-Tuning o Hybrid raccomandato.
  • Dati di Pricing Obsoleti (basso): Dati di pricing Vector DB più vecchi di 90 giorni.
  • Rischio Drift Corpus (medio): Freschezza ≤ 2 + Fine-Tuning raccomandato.
  • Budget Latenza a Rischio (alto): SLA di latenza < 500 ms + RAG o Hybrid raccomandato.

6. Limitazioni e assunzioni

  • Le stime di costo sono solo indicative. I costi effettivi dipendono da fornitore, dimensione del modello, configurazione dell'infrastruttura e prezzi negoziati.
  • Il modello di scoring è intenzionalmente opinionato e basato su pattern di produzione osservati presso clienti Buzzi al Q1 2026. Non sostituisce una revisione architetturale da parte di un ML engineer esperto.
  • Il motore non modella multi-tenancy, overhead di test A/B, costo della pipeline di valutazione o costo di etichettatura dati per il fine-tuning.
  • Il costo Hybrid / RAFT assume un singolo ciclo di re-training per finestra di 6 mesi. I team con esigenze di re-training più frequenti dovrebbero aumentare il divisore di ammortamento del training.