How Anthropic enables self-service data analytics with Claude
Retrospettiva ingegneristica del team Data Science & Data Engineering di Anthropic (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry) pubblicata il 3 giugno 2026 sul blog Anthropic (categoria Enterprise AI, focus su Claude Code). Risultato principale: "il 95% delle query di analytics aziendali è automatizzato da Claude, con un'accuratezza di ~95% in aggregato" (fino a ~99% in alcuni domini). Problema centrale: l'analytics non è codice — "spesso esiste una sola risposta corretta usando un'unica fonte corretta" — richiede di mappare la domanda dell'utente su entità precise e aggiornate nel modello dati.
#self-service analytics#agentic data analytics#Claude Code#single correct answer#mapping question to entities#data model#failure modes#concept-entity ambiguity
Riassunto
Pubblicata il 3 giugno 2026 sul blog Anthropic, questa retrospettiva ingegneristica del team Data Science & Data Engineering (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry) racconta come Anthropic ha reso il proprio analytics self-service con Claude: 95% delle query aziendali automatizzate, ~95% di accuratezza in aggregato (fino a ~99% in alcuni domini).
Il punto di partenza è che l'analytics non è codice: "spesso esiste una sola risposta corretta usando un'unica fonte corretta". La sfida non è la creatività generativa ma la capacità di mappare una domanda su entità precise e aggiornate nel modello dati. Tre modalità di fallimento minacciano questo obiettivo: ambiguità concetto↔entità (cosa sono gli "utenti attivi"? si escludono i frodatori? quale finestra temporale?), obsolescenza (staleness) degli asset e della conoscenza dell'agente, e fallimento del retrieval — l'80% delle query fallite aveva comunque l'informazione presente nel corpus. Il peggiore di tutti è il fallimento silenzioso: una risposta sbagliata ma plausibile, usata senza obiezioni.
La risposta è uno "stack di agentic analytics" a quattro livelli. (1) Fondamenta dati: modellazione dimensionale, dataset canonici"single source-of-truth", metadati trattati "come prodotto di prima classe", integrità via CI/CD. (2) Fonti di verità in ordine decrescente di affidabilità: un semantic layer che l'agente è "strutturalmente obbligato (per istruzione della skill) a utilizzare per primo", poi il lineage, un corpus di query distillato in documenti (non retrieval grezzo), e un grafo di conoscenza di business (roadmap, log decisionali, organizzazione). (3) Skills — la leva decisiva: "senza skills … non si superava il 21% … Aggiungendo skills questi numeri salgono costantemente oltre il 95%". Sono organizzate in coppie: una Knowledge skill router (~30 file di riferimento) e una Unbook skill che codifica il flusso di lavoro dell'analista senior (chiarire, trovare fonti, eseguire, revisione avversariale). La manutenzione è colocata: un hook di revisione segnala ogni modifica al modello che non include una modifica alle skill — ~90% delle PR sui dati ora include una skill nello stesso diff. (4) Validazione: eval offline con soglia (~90% per autorizzare un agente), ablation testing, e salvaguardie online (revisione avversariale: +6% di accuratezza ma +32% token e +72% latenza; footer di provenienza; raccolta di correzioni da parte di agenti pianificati).
Due risultati negativi plasmano la dottrina: dare accesso a grep grezzo su migliaia di file SQL sposta l'accuratezza "di meno di un punto" (il collo di bottiglia è la struttura, non l'accesso), e lasciare che l'LLM definisca le metriche è stato "net-negative" — da cui la regola: documentazione generata, definizioni possedute dagli umani. Per iniziare: una manciata di dataset canonici, qualche dozzina di eval, una thin knowledge skill.
Punti chiave
Data / fonte.3 giugno 2026, blog Anthropic (claude.com/blog, Enterprise AI). Autori: il team Data Science & Data Engineering di Anthropic (Chang, Peng, Leder, Jiao, Cherry).
Risultato principale.95% delle query di analytics aziendali automatizzate, ~95% di accuratezza in aggregato (fino a ~99% in alcuni domini).
Tesi. analytics ≠ codice — "un'unica risposta corretta usando un'unica fonte corretta" → la sfida è mappare la domanda sulle entità giuste e aggiornate, non generare. ### 3 modalità di fallimento 1. Ambiguità concetto↔entità — centinaia di opzioni; es. "utenti attivi" (quali azioni? escludere i frodatori? quale finestra di lookback?). 2. Obsolescenza (staleness) — asset e conoscenza dell'agente diventano "sottilmente sbagliati" (schemi/definizioni cambiano continuamente). 3. Fallimento del retrieval — l'80% delle query fallite aveva comunque l'informazione presente nel corpus.
Pericolo ultimo = fallimento silenzioso: "la risposta è sbagliata, ma sembra plausibile e viene usata senza obiezioni". ### Stack agentico a 4 livelli
L1 — Fondamenta dati. modellazione dimensionale, dataset canonici (single source-of-truth, posseduti, pronti per il consumo), metadati "prodotto di prima classe", integrità cross-layer via CI/CD.
L2 — Fonti di verità. (affidabilità ↓): semantic layer (obbligatorio per primo) → grafo di lineage/trasformazione → corpus di query (distillato in documenti, non retrieval grezzo) → contesto di business (grafo di conoscenza: roadmap, log decisionali, organizzazione).
L3 — Skills. (la leva): 21% → 95%+. Coppie: Knowledge skill (router → ~30 file di riferimento) + Unbook skill (flusso di lavoro dell'analista senior: chiarire → fonti → eseguire → revisione avversariale; pattern riutilizzabili: curve di retention, scomposizione dei tassi, funnel). Scheletro tipico del documento: Riferimento rapido / Dimensioni & tabelle chiave / Gotchas / Best practice & pattern di query / Riferimenti cross-domain.
L4 — Validazione. eval offline (soglia ~90% per autorizzare un agente, obiettivo ~100%, ground truth fissata su uno snapshot, "memorizzare i risultati come telemetria"), ablation testing, online (revisione avversariale, footer di provenienza, controlli di qualità dei dati, raccolta di correzioni da agenti pianificati). ### Risultati notevoli (numeri & ablation)
Senza skills ≤ 21%. ; con skills > 95% (≈99% in alcuni domini).
Revisione avversariale.+6% di accuratezza, ma +32% di token e +72% di latenza (un compromesso da accettare).
Ablation con grep grezzo. (migliaia di file SQL resi accessibili): l'accuratezza si muove "di meno di un punto" → il collo di bottiglia è la struttura, non l'accesso.
Definizioni generate dall'LLM. = "net-negative" (codificano proprio le ambiguità che si volevano eliminare) → definizioni possedute dagli umani.
Retrieval non strutturato. su migliaia di query: guadagno < 1 punto → il corpus va distillato, non recuperato grezzo.
Manutenzione. hook di code-review → ~90% delle PR sui dati tocca un file di skill nello stesso diff. ### Da sfruttare in engagement / presentazioni
Blueprint di un agente di analytics in produzione. , trasponibile: data governance + semantic layer obbligatorio + skills + eval con soglia.
Punto di partenza minimo. (da riutilizzare così com'è): "una manciata di dataset canonici, qualche dozzina di eval offline, e una thin knowledge skill" catturano "la maggior parte del vantaggio".
Argomenti anti-naive-RAG. i due risultati negativi (grep grezzo, retrieval non strutturato) = munizioni contro la visione "basta dare tutto all'agente".
Metrica di governance vivente."il 90% delle PR include una skill" = prova che documentazione e codice evolvono insieme (anti-obsolescenza).
Si collega a: skills (Shihipar/Anthropic), semantic layer/ontologia (Talisman, Seale), Context Engineering (Debois/Tessl), systems around the model (Dropbox), dati knowledge graph (Netflix UDA).
Dati chiave
il 95% delle richieste analytics aziendali automatizzate tramite Claude