Se il suo sistema RAG non ha un eval set, ogni modifica al prompt è una release a sensazione. La buona notizia: può costruire un eval set utile in una settimana. Non perfetto — utile. La perfezione è la trappola che impedisce ai team di avere evals tout court.
Ecco la ricetta che usiamo negli engagement in cui il cliente ha 0–5 evals al primo giorno e ne deve avere 200 entro fine settimana.
La forma
Servono tre cose:
- Un corpus congelato — i documenti reali su cui il sistema fa retrieval, fotografati in un momento preciso.
- 200 domande che un utente reale potrebbe porre, con risposte di verità e citazioni.
- Un held-out set — 30 di quelle 200, messe sotto chiave, mai usate per tunare nulla.
L'held-out set è il più importante e il più spesso saltato. Ci torneremo.
Giorni 1–2: Estragga domande reali
Salti i workshop "cosa chiederebbero gli utenti?". Producono domande che nessun utente ha mai posto davvero. Vada alle sue fonti:
- Ticket di supporto che menzionano qualunque argomento coperto dal RAG.
- Log di ricerca dalla sua barra di ricerca esistente, se ne ha una.
- Canali Slack dove le persone si pongono la domanda internamente.
- I log di chat del suo attuale sistema LLM, se ne ha uno in funzione.
Punti a 250 domande grezze. Deduplichi, normalizzi la formulazione, scarti quelle palesemente fuori scope. Atterrerà su ~200.
Giorno 3: Tagging per difficoltà e topic
Suddivida ogni domanda in bucket:
- Difficoltà: triviale (la risposta è in un paragrafo), media (la risposta richiede di sintetizzare 2–3 documenti), difficile (richiede di capire una procedura o una regola).
- Area tematica — di solito 5–15 bucket, a seconda del dominio.
- Flag adversarial — domande progettate per innescare modalità di fallimento note (fuori scope, informazioni contraddittorie, informazioni aggiornate di recente).
Vuole un mix. Una suite composta al 90% da domande triviali le dirà che il sistema è ottimo, e lei rilascerà una regressione perché i casi medi e difficili si saranno rotti.
Giorno 4: Verità di riferimento
Per ogni domanda, le serve:
- La risposta attesa — scritta, 1–3 frasi, la risposta che darebbe un esperto di dominio.
- I passaggi di supporto — puntatori (doc ID, range di righe, chunk ID) alle parti del corpus che dovrebbero essere recuperate per rispondere alla domanda.
Questa è la parte lenta. Pianifichi ~3 minuti per domanda = ~10 ore per 200 domande. Due persone in parallelo, mezza settimana. Usi un esperto di dominio.
Ne vale la pena. È la parte che trasforma "l'LLM ha detto qualcosa di plausibile" in "l'LLM ha citato la fonte giusta e ha dato la risposta giusta."
Giorno 5: Baseline + metriche
Esegua il suo sistema attuale (o uno stub se non ne ha uno) contro le 170 domande visibili. Registri:
- Retrieval@k: i top-k chunk recuperati includevano i passaggi di supporto attesi?
- Correttezza della risposta: valutata da un LLM judge contro la risposta attesa, con il riferimento held-out. Calibri il judge contro ~30 valutazioni umane per essere sicuro che non si limiti a timbrare.
- Precisione delle citazioni: delle citazioni restituite, quale frazione supporta davvero la tesi?
Ora ha delle baseline. Ogni futura modifica al prompt o al retrieval si manifesta come un delta rispetto a queste.
Il set "da non ottimizzare"
Le 30 domande held-out esistono per una sola ragione: per coglierla in fallo.
Ogni team che costruisce un eval set prima o poi inizia a tunare il sistema contro l'eval set. Nuova revisione del prompt, esegui gli evals, il punteggio è salito, rilascia. Tre mesi dopo, il punteggio in-suite è al 95% e la soddisfazione utenti è invariata perché ha fatto overfitting.
Le 30 domande held-out vengono eseguite solo durante i controlli di salute trimestrali. Se regrediscono mentre il resto della suite migliora, è l'allarme antincendio dell'overfitting. Sono un controllo sul controllo.
Non le guardi. Non ne aggiunga. Non sostituisca con equivalenti. Le chiuda in cassaforte.
Cosa le porta tutto questo
- Un segnale riproducibile che fa da gate alle modifiche su prompt e retrieval.
- Una baseline da confrontare quando valuta nuove versioni di LLM.
- Una risposta difendibile alla domanda "come fa a sapere che il suo RAG è valido?"
Costruisca la v1 in una settimana. Iteri le domande mensilmente. Sostituisca l'held-out set una volta l'anno.
Non avrà mai il tempo di costruire l'eval set perfetto. Ha assolutamente il tempo di costruire quello utile.