Indice

• Perché costruire un dataset ad hoc
• Cosa abbiamo provato e cosa abbiamo imparato
• La soluzione in breve
• Struttura del dataset (char‑based, chunk‑agnostic)
• Generazione domande
• Easy
• Medium
• Generazione risposte e passaggi
• Easy
• Medium (multi-hop e wide)
• Dataset pubblico: D\&D SRD 5.2.1
• Limiti attuali e miglioramenti futuri
• Conclusioni e prossimi passi

Perché costruire un dataset ad hoc

Se vogliamo testare RAG o anche una sola sua componente, come retrieval o generazione, abbiamo bisogno di dataset che riflettano le difficoltà reali. Solo così tramite metriche precise otteniamo risultati che ci dicano non solo se una soluzione è migliore di un’altra, ma anche quando e perché lo è. In particolare, vogliamo mettere alla prova:

• multi‑hop con molti step, dove la risposta richiede un recupero a catena di informazioni;
• domande wide, che coinvolgono più documenti e fonti eterogenee;
• struttura agnostica standardizzata, che ci permetta di testare diverse strategie di chunking e di preprocessing dei documenti

Cosa abbiamo provato e cosa abbiamo imparato

Abbiamo esplorato diversi dataset pubblici:

• LegalBench: benchmark collaborativo per il legal reasoning degli LLM su decine di compiti eterogenei (statuti, contratti, case law, ecc.), con livelli di difficoltà vari e contributi dalla community legale. Overview
• MultiHop‑RAG: dataset per valutare RAG su domande multi‑hop che richiedono recupero e ragionamento su più documenti; include migliaia di query con evidenze distribuite su 2–4 documenti e metadati. GitHub · Hugging Face
• LoCoMo: benchmark per memoria e ragionamento in conversazioni a lungo termine (multi‑sessione, talvolta multimodale), con annotazioni per QA e sintesi di eventi; utile per testare long‑term conversational memory. GitHub

Tuttavia, spesso è capitato che nostre soluzioni che performavano bene su dataset pubblici tendessero ad avere risultati deludenti sui dataset dei nostri clienti.

Per questo, volevamo dataset che si allineassero meglio ai nostri obiettivi: spesso mancano casi di multi‑hop con molti step e reasoning intenso, funzionalità che invece si rivelano necessarie per affrontare gli use case dei clienti. Inoltre, la maggior parte adotta schemi chunk‑based o annotazioni poco granulari, o anche schemi flessibili ma diversi tra un dataset e l’altro, limitando la portabilità tra sistemi.

La soluzione in breve

Abbiamo creato due dataset interni di evaluation, entrambi di domini che permettono di mettere in difficoltà modelli e strategie di frontiera (comprendendo quindi casi di multi‑hop, reasoning, copertura ampia del dominio), e un terzo dataset pubblico basato su DnD SRD 5.2.1. La chiave è una struttura char‑based standardizzata che rende il dataset agnostico al chunking.

Obiettivi di design

• Chunk‑agnostic: intervalli a carattere indipendenti dalla strategia di chunking adottata. Qualunque splitter possiamo scegliere a valle, gli span rimangono validi, e possiamo verificare se un chunk contiene la porzione necessaria.
• Riproducibile: riferimenti stabili a start_char/end_char sui file markdown della KB.
• Esperto di dominio: controllo di qualità sistematico con approvazione/modifica/scarto per ogni entry.
• Difficoltà controllata: livelli easy e medium per coprire diverse casistiche e isolarne le performance.

Struttura del dataset (char‑based, chunk‑agnostic)

Ogni elemento del dataset ha:

• id
• domanda
• risposta
• passaggi: lista di evidenze testuali, ognuna con
• documento_origine (file markdown della KB)
• start_char, end_char (intervalli nel testo sorgente)
• contenuto (lo span estratto)

Nel concreto, tutti i documenti del dataset sono in formato markdown, ognuno dei quali è stato estratto facendo parsing dei PDF originali”

Gli start_char/end_char sono riferimenti nei testi normalizzati, così da massimizzare riproducibilità e portabilità.

Generazione delle domande

Easy

Per le domande easy automatizziamo: selezioniamo un documento markdown casuale dalla KB e chiediamo a un LLM di generare una domanda puntuale su quel documento. A ogni iterazione passiamo anche le domande già prodotte su quel file, per evitare duplicati.

Questo processo permette di produrre domande puntuali su un singolo documento, ma non cross-documento.

Medium

Per le medium serve fin da subito l’esperto di dominio. Vogliamo includere domande cross‑documento o con ragionamenti non banali: passare tutta la KB a un LLM può non essere realistico in alcuni casi e produce domande troppo facili o poco utili. Qui l’esperto scrive le domande da zero. Abbiamo scelto D\&D come flavour perché è un dominio dove abbiamo expertise; in aggiunta manteniamo anche due dataset interni coperti da NDA.

Generazione di risposte e passaggi

Easy

Dati la domanda e il documento di partenza, facciamo una chiamata LLM per produrre la risposta e identificare i passaggi necessari con relativi span. Ogni tripletta domanda‑risposta‑passaggi è input di un controllo di qualità da parte dell’esperto umano che può accettare, scartare o correggere.

Medium (multi‑hop e wide)

A differenza delle domande "easy", in cui la risposta può essere trovata in un singolo documento e in porzioni di testo sostanzialmente contigue, per realizzare un dataset di difficoltà media abbiamo dovuto immaginare casi in cui le informazioni necessarie sono disseminate.

Abbiamo identificato due scenari principali che caratterizzano questa difficoltà media: le domande multi‑hop, dove la risposta richiede una catena di ragionamento che attraversa più documenti (ad esempio, trovare prima una regola generale in un documento, poi una specifica eccezione in un altro, e infine applicare entrambe a un caso particolare descritto in un terzo), e le domande wide, dove la risposta completa richiede di aggregare informazioni da molteplici documenti senza necessariamente seguire una catena di ragionamento complessa, ma piuttosto raccogliendo pezzi di informazione sparsi che contribuiscono tutti alla risposta finale.

Il loop generale per la generazione di domande è (solo per le domande medium):

1. L’esperto formula la domanda e fornisce eventuali primi hint.
2. Il sistema produce risposta + passaggi.
3. L’esperto verifica e, se non soddisfatto, aggiunge hint aggiuntivi (es. restringere il dominio, suggerire documenti plausibili, chiarire condizioni).
4. Si ripete finché la risposta e gli span risultano soddisfacenti.

Per generare le risposte alle domande di difficoltà medium le abbiamo divise in questi due gruppi, e per ognuna abbiamo identificato una strategia dedicata.

Per generare le risposte alle domande di difficoltà medium le abbiamo divise in questi due gruppi, e per ognuna abbiamo identificato una strategia dedicata.

• Multi‑hop complessi → Claude Skills: le Skills sono uno strumento recentemente introdotto da Anthropic in questo post. Abbiamo costruito una skill custom contenente:
• un manuale in markdown che dà una generale overview dei documenti
• la knowledge base in markdown
• due tool Python: uno per cercare pattern testuali specifici nei documenti e uno per espandere il contesto attorno ai match trovati, permettendo di recuperare il contenuto circostante e ottenere informazioni sulla struttura del documento

L'obiettivo era creare una Claude Skill che mimasse il comportamento di una RAG parecchio evoluta, privilegiando la qualità di risposta rispetto a costi e latenza. Queste ultime due variabili, sebbene difficilmente accettabili in molte applicazioni, sono un problema di minore importanza nella creazione di un dataset.

La skill opera sulla nostra knowledge base completa in markdown (per il dataset D\&D, si tratta di 20 file markdown estratti dal SRD 5.2.1). L'esperto di dominio fornisce una domanda già creata ad hoc, e la skill esegue i seguenti passi:

1. La skill accede a un documento markdown aggiuntivo contenente una overview generale della KB—come interpretarla, come esplorarla, convenzioni di naming, struttura dei documenti, ecc.
2. La skill utilizza i tool di ricerca per esplorare i documenti e ottenere informazioni. Questo step può essere ripetuto più volte: se la skill determina che servono ulteriori informazioni, effettua nuove ricerche, affina i criteri, o esplora documenti correlati.
3. Tutte le informazioni raccolte durante i vari step di ricerca vengono aggregate.
4. La skill produce una risposta completa sulla base di tutte le informazioni raccolte, documentando con precisione tutti i passaggi utilizzati.

Questo approccio è molto forte nei casi multi‑hop. Tuttavia i costi non sono trascurabili. Dopo aver utilizzato questo approccio per svariate domande, dai nostri esperimenti emerge che il costo medio è stato ~$2 per domanda, con picchi fino a $11.

• Domande "wide" → LLM Retriever: per le domande wide abbiamo adottato un approccio non basato su similarità semantica, in quanto questa tende a fare da collo di bottiglia a livello di qualità dei risultati. Abbiamo quindi scelto di usare LLM come retriever di passaggi, seguendo una tecnica simile a quella del LLM Retriever di LlamaIndex, che prendono in contesto un intero documento. Questo permette di ottenere passaggi molto più accurati, ovviamente ad un costo nettamente più alto che, come già specificato per le skill, non rappresenta un problema nella fase di creazione di un dataset. Non abbiamo voluto usare le skill per le domande wide in quanto i costi sarebbero stati eccessivamente elevati.

Per ogni domanda, gli step sono:

1. invochiamo un retriever LLM per documento in parallelo;
2. ogni istanza, ricevuto l'intero documento e la domanda, ritorna i passaggi candidati per la risposta.
3. un LLM aggregatore unisce le evidenze e formula la risposta finale, documentando tutti i passaggi effettivamente utilizzati.

Anche questo approccio tende ad essere costoso, in particolare:

• È più efficiente delle Claude Skills a livello di costo su domande wide
• Performa male su domande multi-hop in quanto fa un singolo passaggio di estrazione

Abbiamo escluso dal dataset domande eccessivamente generiche o ambigue, come "Quando posso utilizzare abilità X invece di Y?". Questo tipo di domande tende a generare risposte insoddisfacenti con entrambi gli approcci (Claude Skills e LLM Retriever), in quanto spesso richiede interpretazione contestuale o ammette risposte multiple valide, rendendole inadatte per una valutazione oggettiva.

Dataset pubblico: DnD SRD 5.2.1

Con questo framework abbiamo creato un dataset pubblico basato sul D\&D SRD 5.2.1, che raccoglie un sottoinsieme dei contenuti della quinta edizione di D\&D (Player’s Handbook, DM Guide, Monster Manual). Il System Reference Document (SRD) è rilasciato sotto la licenza Creative Commons, motivo per cui possiamo renderlo pubblico. Il dataset segue la struttura sopra, è chunk‑agnostic grazie alle annotazioni char‑based e include domande easy e medium.

Il controllo qualità viene effettuato dall’esperto di dominio e avviene in tre stadi:

• Validazione semantica: la risposta è corretta rispetto alle evidenze? c’è copertura completa dei passaggi?
• Validazione span: gli intervalli start_char/end_char sono allineati e riproducibili sui file della KB?
• Rilevanza e difficoltà: la domanda appartiene davvero alla classe easy/medium prevista?

In caso di esito negativo, l’item viene scartato o nel caso di domande medium viene possibilmente revisionato con ulteriori hint.

Statistiche del Dataset

• Domande Totali: 56
• Livello Facile: 25 domande
• Livello Medio: 31 domande
• Documenti Sorgente: 20 file markdown da D\&D SRD 5.2.1
• Dominio: Regole e meccaniche di gioco di ruolo da tavolo

Il dataset completo, insieme al codice per la generazione e validazione, è disponibile pubblicamente nella repository GitHub del progetto e su HuggingFace.

Limiti attuali e miglioramenti futuri

• Obbligatorie vs opzionali: oggi non distinguiamo tra passaggi obbligatori e opzionali nella valutazione. Ciò può penalizzare sistemi che trovano risposte corrette con percorsi alternativi (es. agent‑style o skills complesse), in particolare può penalizzare Claude Skills quando segue percorsi di ricerca non lineari. Miglioreremo la tassonomia dei passaggi.
• RAG agentica avanzata: intendiamo sperimentare pipeline di deep research (multi‑fase, verifiche, self‑consistency) per rafforzare la generazione delle medium e arricchire le annotazioni.
• Domande hard: vogliamo mettere in piedi un sistema che ci permetta di formulare un terzo livello di difficoltà per i dataset, superiore alle domande medium attuali, per poter fare evaluation di RAG particolarmente complesse e di sistemi di deep research. Queste domande combineranno sia caratteristiche multi-hop che wide.
• Multimodalità: Essendo il dataset basato sulla posizione dei caratteri, il sistema non valuta ancora eventuali abilità riguardo il trovare correttamente immagini e/o grafici significativi.

Conclusioni e prossimi passi

Abbiamo presentato una metodologia pratica per costruire dataset di evaluation per vari step di una RAG: struttura char‑based, livelli di difficoltà, generazione semi‑automatica con controllo umano, e strumenti specifici per multi‑hop e wide. Abbiamo rilasciato un dataset pubblico basato su DnD SRD 5.2.1 per favorire valutazioni trasparenti e riproducibili. Il dataset e il codice per la generazione e validazione è disponibile pubblicamente nella repository GitHub del progetto e su HuggingFace.

A breve condivideremo un post dedicato alla Contextual Retrieval di Anthropic, in cui verrà fatto uso di questi dataset per valutarne i miglioramenti rispetto ad una forma classica di retrieval.

***

*Raul Singh -* GitHub - LinkedIn - AI R\&D Engineer - Datapizza

*Ling Xuan “Emma” Chen -* GitHub - LinkedIn - AI R\&D Engineer - Datapizza

*Francesco Foresi -* GitHub - LinkedIn - GenAI R\&D Team Lead - Datapizza