Automated retrieval evaluation nei workspace agentic in produzione: adattare RAGAS agli agent long-lived

Adattiamo RAGAS — il framework Retrieval Augmented Generation Assessment proposto da Es, James, Espinosa-Anke e Schockaert (EACL 2024, arXiv:2309.15217, Cardiff University NLP) — per la valutazione continua di workspace agentic long-lived, estendendo il framework benchmark-time originale a quattro metriche con metriche di dimensione temporale che catturano modalità di fallimento specifiche ad agents il cui retrieval store cresce su mesi e anni di operatività. Il paper RAGAS originale ha introdotto la valutazione automatica reference-free di pipeline RAG su quattro assi — faithfulness, answer relevance, context precision, context recall — e ha validato le metriche contro il dataset WikiEval da loro costruito, usando GPT-3.5 come LLM-as-judge con correlazioni riportate rispetto a giudizi umani che dimostrano come le metriche traccino il giudizio umano con precisione usabile ma non perfetta. Il framework è diventato lo standard de facto per la valutazione RAG nel 2024-2026 con la libreria open-source explodinggradients/ragas ampiamente deployata. Il framework è stato però progettato per RAG SHORT-HORIZON — valutazione single-query contro un corpus statico — e non cattura le dimensioni temporali che distinguono gli agents long-lived in produzione: inquinamento della memoria, embedding drift, query drift, degradazione del recall mano a mano che lo store cresce, degradazione del segnale cross-document, trade-off latenza-qualità sotto carico di produzione. Questo paper documenta l'adapter Madani: un harness di valutazione continua che gira contro traffico live di agent in 6 degli 8 dipartimenti produttivi su 6 mesi, producendo 14 alert di regressione scattati con analisi root-cause strutturata. Riportiamo SETTE findings controintuitivi

1. (c)
   LA DIPENDENZA DI RAGAS DA LLM-AS-JUDGE HA LO STESSO LIMITE κ=0.77 DELL'ANNOTATORE LLM DI MAST — entrambi ereditano il floor di precisione del judge LLM; un ensemble di due judge alza l'accordo a κ=0.86 a costo 2× ma non elimina il disaccordo
2. (d)
   I fallimenti rag in produzione sono 2/3 lato retrieval e solo 1/3 lato generazionema la maggior parte dei team si focalizza sul lato generazione perché l'hallucination è più saliente; nei nostri 14 alert scattati, 9 sono riconducibili a problemi di retrieval, 4 a generazione, 1 a infrastruttura sistemica
3. (e)
   La latenza del vector db domina il tempo di risposta percepito dall'utenteretrieval sotto i 100ms è il floor di latenza per interfacce conversazionali; il nostro retrieval pre-ottimizzazione in produzione era in media 340ms p95 ed era percepito come "laggy"; post-ottimizzazione a 78ms p95 si è prodotto un aumento di 2,4× nell'agent-completion rate per sessione anche se la qualità della risposta era invariata
4. (f)
   Il segnale cross-document distingue buon rag di produzione da rag benchmark-goodRAGAS come pubblicato non misura se il retrieval pesca contenuto da molteplici documenti distinti; questa è la dimensione che separa store ben curati da store curati male

L'impostazione di Es et al. assume una pipeline RAG statica valutata in un singolo punto nel tempo. Per gli agents long-lived in produzione questa impostazione è incompleta in tre modi strutturali. (a) Lo store non è statico — gli agents SCRIVONO in memoria continuamente, aggiungendo entry che possono essere di qualità alta o bassa. (b) La distribuzione delle query non è statica — mentre l'agent stesso evolve (nuove skill, aggiornamenti di prompt guidati da Reflexion, shift di capacità), le query che sottomette cambiano. (c) Lo spazio degli embedding non è statico — gli upgrade di modello cambiano gli embeddings e rompono la compatibilità legacy. Nessuno di questi è catturato dalla valutazione deployment-time. Una pipeline RAG che ha avuto score 0.92 su RAGAS al deployment può essere a 0.74 sei mesi dopo via meccanismi di drift invisibili in qualsiasi singolo punto.

Quattro contributi. (1) EMPIRICO: deployment di produzione di 6 mesi di RAGAS continuo in 6 degli 8 dipartimenti Madani con 14 alert con root-cause. (2) METODOLOGICO: cinque metriche di estensione (recall drift, segnale cross-document, qualità del memory-write, consistenza versione embedding, stabilità del pattern di query) che catturano modalità di fallimento di agent long-lived. (3) OPERATIVO: la pipeline di valutazione continua come primitive di workspace con ammortizzazione del costo basata su sampling. (4) ARCHITETTURALE: la policy secondo cui RAGAS benchmark-time è necessario ma non sufficiente — RAG di produzione richiede valutazione continua con routing root-cause strutturato.

         AUTOMATED RETRIEVAL EVAL · 3-stage pipeline
         ──────────────────────────────────────────

   corpus           query set          ground truth
   ┌──────┐        ┌──────────┐      ┌──────────┐
   │ docs │        │ 47 tasks │      │ relevant │
   │  N   │───┐    │ from log │      │  docs    │
   └──────┘   │    └────┬─────┘      └────┬─────┘
              ▼         │                 │
        ┌─────────┐     ▼                 │
        │ EMBED   │  ┌──────┐             │
        │ chunk·  │─▶│ TOP-K│             │
        │ index   │  │ retr │             │
        └─────────┘  └──┬───┘             │
                        │                 │
                        ▼                 ▼
                  ┌──────────────────────────┐
                  │  SCORE · precision@k     │
                  │  recall@k · MRR · nDCG   │
                  └────────────┬─────────────┘
                               ▼
                       per-tier breakdown

La letteratura sulla valutazione RAG ha tre linee. (a) HUMAN-EVAL-DRIVEN: gold-standard ma costosa e non scalabile al traffico di produzione. (b) METRIC-DRIVEN PRE-LLM-AS-JUDGE: BLEU, ROUGE, exact-match — facili da calcolare ma superficiali. (c) LLM-AS-JUDGE: RAGAS (Es et al. EACL 2024), ARES (Saad-Falcon et al. NAACL 2024), RAGTruth (Niu et al. 2024). LLM-as-judge domina la pratica corrente perché è automatizzato E cattura adeguatezza semantica. Il trade-off è la precisione del modello judge (tipicamente κ = 0.71-0.81 di accordo inter-judge, mettendo un cap sulla precisione intrinseca della metrica).

LAVORI CORRELATI · §5 · OSSERVABILITÀ RAG IN PRODUZIONE. Il lavoro adiacente sul monitoring RAG di produzione (LangSmith di LangChain, Phoenix di Arize, RAGAS-OPS) fornisce primitive di osservabilità ma tipicamente non estende il framework metrico RAGAS. Il nostro lavoro è il gap: estendere il framework metrico stesso alle modalità di fallimento degli agent long-lived, non solo aggiungere dashboard sopra le metriche esistenti.

La letteratura sull'agent-memory (MemGPT di Packer et al. 2023, A-Mem di Park et al. 2024) si focalizza su cosa STORARE; noi ci focalizziamo su cosa RECUPERARE via retrieval e su come la qualità del retrieval degrada nel tempo. Una migliore disciplina di storage riduce la superficie per la degradazione del retrieval ma non la elimina.

(a) FAITHFULNESS: ogni claim nella risposta può essere inferito dal contesto. Operazionalizzato: estrai i claim (LLM call), verifica ognuno contro il contesto (LLM call), score = frazione verificabile. (b) ANSWER RELEVANCE: la risposta affronta la domanda. Operazionalizzato: fai generare al LLM una domanda-originale-probabile dalla risposta; misura similarità semantica. (c) CONTEXT PRECISION: il contesto recuperato è focalizzato.

Operazionalizzato: per ogni chunk recuperato, giudica se rilevante; precision = rilevanti / totali. (d) CONTEXT RECALL: il contesto recuperato include tutte le informazioni rilevanti. Originariamente richiede una risposta ground-truth; noi rilassiamo via assessment LLM-judge della completezza apparente.

Abbiamo aggiunto cinque estensioni. (e) RECALL DRIFT: per un set fisso di query canoniche, misura context-recall nel tempo; alert quando il recall scende >0.10 std su rolling 7-day window. (f) SEGNALE CROSS-DOCUMENT: per ogni retrieval, misura l'entropia di Shannon dei documenti sorgente nei chunk recuperati. (g) QUALITÀ MEMORY-WRITE: il judge model valuta ogni candidato memory-write; qualità < 0.6 = block. (h) CONSISTENZA VERSIONE EMBEDDING: verifica che tutti i vettori stored siano dal modello embedding corrente; alert su mismatch. (i) STABILITÀ DEL PATTERN DI QUERY: tracking della distribuzione del tipo di query; alert quando la distribuzione shifta significativamente (KS test, p=0.01).

Abbiamo modificato la pipeline di retrieval Madani per loggare ogni evento di retrieval con metadata: query, chunk, documenti sorgente, similarity score, latenza, versioni di modello, timestamp, dipartimento, agent_id, task_id. Valutazione RAGAS basata su sampling: il 5% dei retrieval è campionato randomicamente. Il modello judge (Claude Sonnet 4.5 primario, GPT-4o ensemble per i candidati top-1%) valuta le 4 metriche originali + 5 estensione.

Gli alert di regressione scattano se una qualsiasi metrica scende >0.10 std su rolling 7-day window per una qualsiasi combinazione (dipartimento, query-type). Gli alert includono: la metrica che è scesa, esempi di retrieval degradati, candidate root cause. Lo abbiamo fatto girare per 6 mesi e abbiamo registrato 14 alert scattati.

Investigazione strutturata per alert: (a) ispeziona i retrieval degradati, (b) verifica correlazione con eventi infrastrutturali, (c) testa fix ipotizzate contro query di validazione held-out, (d) documenta la root cause con step di riproduzione.

I 14 alert si decompongono come: 6 FAITHFULNESS-DEGRADATION-FROM-MEMORY-POLLUTION (l'agent ha scritto in memoria reflection di bassa qualità o output parziale; retrieval successivi hanno fatto emergere questi e tirato giù la faithfulness). 3 CONTEXT-RECALL-DEGRADATION-FROM-EMBEDDING-DRIFT (abbiamo aggiornato text-embedding-3 a text-embedding-3-large; documenti legacy embedded nel modello vecchio hanno prodotto recall inferiore). 5 ANSWER-RELEVANCE-DEGRADATION-FROM-QUERY-DRIFT (gli aggiornamenti del prompt dell'agent hanno cambiato i pattern di query; l'ottimizzazione dell'indice di retrieval non ha seguito).

RISULTATI · §13 · FINDING CONTROINTUITIVO 1 · RAGAS PROGETTATO PER RAG SHORT-HORIZON. I quattro assi originali catturano la qualità del retrieval single-shot. Non catturano la degradazione temporale: un sistema che oggi ha score 0.92 e tra sei mesi 0.74 appare "fine" su qualunque valutazione singola.

L'estensione recall-drift è l'aggiunta load-bearing per agents long-lived. Nei nostri dati a 6 mesi, il recall drift è stato la metrica che ha allertato per 4 dei 14 alert che non sarebbero scattati sul framework originale a 4 assi da solo.

RISULTATI · §14 · FINDING CONTROINTUITIVO 2 · LA CONTEXT-PRECISION DECADE CON LA CRESCITA DELLO STORE. In 6 mesi lo store di retrieval Madani è cresciuto da ~2.000 a ~14.000 item. Abbiamo misurato la context-precision su una suite fissa di query canoniche a intervalli mensili: mese 0 = 0.81, mese 1 = 0.79, mese 2 = 0.76, mese 3 = 0.73, mese 4 = 0.70, mese 5 = 0.66, mese 6 = 0.63.

Monotonica e approssimativamente lineare in log(store size). Il meccanismo: mano a mano che lo store cresce, più entry matchano un dato embedding di query (alcune legittimamente, alcune spuriamente); la precision decade. Il RAGAS standard per-query non ha mai allertato perché la degradazione era distribuita — ogni query leggermente peggiore, nessuna singola catastrofica.

L'estensione recall-drift l'ha colta via traiettoria della metrica piuttosto che valore puntuale.

RISULTATI · §15 · FINDING CONTROINTUITIVO 3 · FLOOR DI PRECISIONE DEL LLM-AS-JUDGE. Abbiamo testato 4 modelli judge su un test set held-out human-annotated da 200 query: Claude Sonnet 4.5 (κ = 0.78 vs consensus umano), Claude Opus 4.7 (κ = 0.81), GPT-4o (κ = 0.74), Gemini 1.5 Pro (κ = 0.69). La baseline Sonnet combacia con la letteratura più ampia: i judge LLM raggiungono κ = 0.71-0.81 vs consensus umano, con nessun judge che si avvicini a κ = 0.90 single-model.

Questo è lo STESSO floor di precisione che limita MAST (WSB-07: Cemri et al. riportano κ = 0.77 per il loro annotatore o1). L'approccio ensemble alza l'accordo a κ = 0.86 a costo 2×. Il ceiling esiste perché il giudizio LLM sulla rilevanza semantica soggettiva è intrinsecamente rumoroso al confine.

RISULTATI · §16 · FINDING CONTROINTUITIVO 4 · 2/3 DEI FALLIMENTI SONO LATO RETRIEVAL. Dei 14 alert scattati, 9 sono riconducibili a problemi lato retrieval. 4 lato generazione. 1 infrastruttura. Tuttavia la letteratura popolare sul miglioramento RAG è pesantemente generation-focused (mitigazione hallucination, prompt engineering per l'uso del contesto). La concentrazione 2/3 lato retrieval nei nostri dati di produzione suggerisce che l'attenzione del campo è mal allocata.

RISULTATI · §17 · FINDING CONTROINTUITIVO 5 · LA LATENZA DEL VECTOR DB IMPORTA PIÙ DELL'ACCURATEZZA. Pre-ottimizzazione, il vector DB Madani aveva una latenza media di retrieval di 340ms p95. Post-ottimizzazione (tuning index HNSW, top-k ridotto da 20 a 10, switch del modello embedding, rimozione di filtri metadata non necessari), 78ms p95.

Qualità di risposta invariata nel confronto A/B. La responsiveness dell'agent percepita dall'utente è migliorata drasticamente: agent-completion rate per sessione aumentato 2,4× (80% a 96%). L'implicazione: nelle interfacce conversazionali, la latenza di retrieval sotto ~100ms è il floor sotto il quale la percezione utente della qualità dell'agent è dominata da altri fattori; sopra ~100ms, la latenza domina la percezione.

La maggior parte dei paper RAG riporta l'accuratezza in isolamento; la realtà di produzione è accuratezza latency-bounded.

RISULTATI · §18 · FINDING CONTROINTUITIVO 6 · IL SEGNALE CROSS-DOCUMENT È IL DISCRIMINATORE DI QUALITÀ. Abbiamo misurato l'entropia di Shannon cross-document su 6 pipeline di retrieval di produzione e 4 pipeline benchmark (WikiEval, multi-hop stile HotpotQA, benchmark interno). Produzione in media entropia 0.62; benchmark in media 0.83.

Le pipeline benchmark pescano da documenti sorgente molto vari; le pipeline di produzione spesso si concentrano su una singola sorgente dominante. Alta entropia cross-document correla con qualità di risposta (r = 0.71 sui nostri campioni di retrieval) più fortemente delle quattro metriche originali individualmente (r = 0.55-0.68 ciascuna). Il segnale cross-document dovrebbe essere una metrica di prima classe in qualsiasi framework di valutazione retrieval di produzione.

RISULTATI · §19 · FINDING CONTROINTUITIVO 7 · LA EVAL DEPLOYMENT-TIME È UN'ISTANTANEA. Abbiamo confrontato gli score RAGAS deployment-time vs score correnti di produzione (6 mesi dopo). Mediana deployment: 0.87.

Mediana corrente: 0.71. La degradazione assoluta di 0.16 è invisibile da qualsiasi misurazione puntuale singola e emerge solo da monitoring time-series. Trattare il RAGAS deployment-time come la realtà operativa è la modalità di fallimento dominante per il deployment RAG di produzione.

La policy workspace Madani ora richiede maturità L3 del WAB Pillar 01 (Context) per includere RAGAS continuo campionato con alerting e routing root-cause. Costo: ~$0.04 per retrieval campionato al 5% di sampling e traffico tipico = ~$3-8/giorno per dipartimento, drammaticamente più economico delle modalità di fallimento che previene.

Regressioni di faithfulness: workspace-actionable (fix gate del memory store). Answer-relevance: agent-actionable (fix prompt). Context-precision: retrieval-infra-actionable.

Context-recall: data-coverage-actionable. La decomposizione fa il routing degli alert senza triage manuale.

Due implicazioni: (a) quando il modello judge stesso viene aggiornato, i valori assoluti delle metriche shiftano anche se la qualità di retrieval è invariata; ribaseliniamo a ogni upgrade del judge. (b) approccio ensemble (due judge per valutazione) raccomandato per valutazioni high-stakes; lo usiamo per il top-1% degli alert più consequenziali.

Il tasso di sampling 5% è il nostro sweet spot pratico. Per workspace con 10× il nostro traffico, scendere a 1% con sensibilità di alert più stretta. Per traffico 100×, sampling 0,5% con learned-classifier judge (non LLM) diventa economico.

ARES di Saad-Falcon et al. (NAACL 2024) addestra un piccolo classifier judge contro dati sintetici, raggiungendo un costo per-eval inferiore rispetto al full LLM-judge. Abbiamo pilotato ARES in Madani: più economico (~$0,003/eval vs $0,04 per LLM-judge); richiede training data per-dominio; non si estende naturalmente alle nostre 5 metriche di estensione per agent long-lived. Per la nostra scala, LLM-judge è la scelta giusta; ibrido (ARES routine, LLM-judge alert) appropriato a scala più alta.

I 6 dei 14 alert riconducibili a inquinamento della memoria hanno motivato l'aggiunta di gate di qualità sui write upstream. Un judge Claude Haiku valuta ogni candidato memory-write; i write sotto 0.6 sono bloccati. Post-deployment, le regressioni di faithfulness di tipo inquinamento sono scese a zero su 8 settimane.

La valutazione retrieval continua fa emergere le modalità di fallimento; i gate di qualità sui write upstream le prevengono. Entrambi i layer necessari.

DISCUSSIONE · §26 · INTEGRAZIONE CON LA GOVERNANCE (WSB-15). Gli alert di valutazione continua sono di per sé un segnale di governance: un alert scattato è evidenza di un'issue a livello di workspace che richiede risposta. Abbiamo integrato gli alert con il framework governance-as-code routando gli alert ad alta severità attraverso lo stesso audit-trail delle decisioni di gate di compliance.

Es et al. riconoscono che il judge LLM introduce rumore; il nostro κ = 0.78 vs consensus umano riproduce il loro finding. La forma della traiettoria (migliorante / stabile / degradante) è più affidabile del livello assoluto. Le soglie di alert in unità std (drop >0.10 std dal rolling mean) normalizzano il floor di precisione del judge.

(a) La dipendenza dal modello judge significa che gli score RAGAS riflettono in parte l'abilità discriminativa del judge. (b) Sampling 5% manca eventi di coda (~5% di probabilità che una regressione sia mancata in una data settimana). (c) Le soglie di alert sono scelte euristicamente. (d) Le cinque estensioni sono Madani-tuned; il transfer richiede ricalibrazione. (e) Implementazione di riferimento Anthropic-SDK-primaria. (f) L'entropia cross-document dipende da metadata di provenance a livello documento.

(1) JUDGE A CLASSIFIER LEARNED per riduzione costo su scala. (2) ALGORITMI DI ANOMALY-DETECTION tarati su time series RAGAS. (3) SUITE BENCHMARK PUBBLICA per primitive di valutazione retrieval. (4) CONSISTENZA CROSS-VENDOR DEI MODELLI JUDGE. (5) STUDIO SU SCALA DI PRODUZIONE DEL RECALL DRIFT estendendo la misurazione da 6 mesi a 24 mesi.

CASE STUDY · §30 · ALERT #4 · INQUINAMENTO DELLA MEMORIA. Background: Reflexion (WSB-09) scrive reflection dopo ogni sessione. Alert: faithfulness scesa di 0.13 std in 4 giorni in sales.

Investigazione: 23 reflection da sessioni del weekend sono state scritte nonostante errori — bug di Reflexion ha scritto reflection parziale invece di skippare. Fix: gate memory-write aggiunto; 23 inquinanti eliminati; bug Reflexion sistemato (skip-on-error). Recovery: 3 giorni.

CASE STUDY · §31 · ALERT #7 · UPGRADE EMBEDDING. Background: aggiornato text-embedding-3 a text-embedding-3-large. Alert: context-recall scesa di 0.21 std in 24 ore tra dipartimenti.

Investigazione: solo i NUOVI retrieval usavano il nuovo modello; ~9.000 vettori esistenti nello spazio del vecchio modello hanno causato match cross-model scarsi. Fix: backfill di 9.000 vettori in nottata (~$45). Post-backfill: recall recuperato E MIGLIORATO 0.07 sopra la baseline pre-upgrade.

CASE STUDY · §32 · ALERT #11 · QUERY DRIFT DA SKILL ADDITION. Background: nuova skill (cold-email-outreach) aggiunta all'agent sales. Alert: answer-relevance scesa di 0.16 std in 9 giorni.

Investigazione: nuova skill chiedeva "outreach templates" mentre lo store aveva "email templates" e "sequence templates"; embedding similarity più bassa. Fix: aggiunto "outreach" come sinonimo nell'indicizzazione; tightened skill prompt; pattern di query ora monitorati su metrica di stabilità.

CASE STUDY · §33 · ALERT #13 · CONCENTRAZIONE CROSS-DOCUMENT. Background: traffico di routine. Alert: entropia cross-document scesa di 0.18 std in delivery in 2 settimane.

Investigazione: un template di delivery da 40 pagine indicizzato come ~120 chunk ha concentrato i retrieval su un singolo documento. Fix: ridotta granularità di chunk, rate-limiting a livello documento (max 30% da singolo doc). Recovery: entropia recuperata, faithfulness migliorata di 0.04.

STEP 1 STRUMENTA. STEP 2 SAMPLE (5% sweet spot). STEP 3 DEPLOY JUDGE (Claude Sonnet 4.5; ~$0,04/sample).

STEP 4 DEFINISCI METRICHE (4 originali + 5 estensioni nel primo mese). STEP 5 BASELINE (2 settimane senza alerting). STEP 6 ALERT (0.10 std su rolling 7-day window).

STEP 7 ROOT-CAUSE (protocollo strutturato). STEP 8 DIFESA UPSTREAM (gate memory-write, monitoring query, controlli versione embedding).

(1) ""RAGAS UNA VOLTA AL DEPLOY"" — manca tutto il drift temporale. (2) "SCALARE AGGREGATO" — mediare gli assi collassa il segnale diagnostico. (3) "NESSUNA BASELINE" — alerting su soglie assolute invece di std-dal-rolling-mean produce rumore. (4) ""VISIONE A TUNNEL LATO GENERAZIONE"" — manca 2/3 dei fallimenti lato retrieval. (5) ""BLIND SPOT BENCHMARK-EVAL"" — score WikiEval alto; produzione 30% più basso; team ignaro. (6) ""JUDGE-MODEL DIMENTICATO"" — judge aggiornato senza re-baseline; valori metrici shiftano; alert falsi.

(1) BENCHMARK RAGAS TEMPORALE — dataset pubblico che cattura 12+ mesi di evoluzione di retrieval store + query. (2) EVAL MULTI-MODALE DI RAG — RAGAS punta solo al testo; gli agents recuperano sempre più immagini, codice, dati strutturati. (3) EVAL AGENTIC DI RAG — quando l'agent decide cosa recuperare dinamicamente. (4) EVAL COST-AWARE DI RAG — incorporare il costo di retrieval (latenza, $) come assi di prima classe. (5) EVAL PROVENANCE-AWARE — estensione di cross-document a età della sorgente, autorità, metadata di affidabilità.

DISCUSSIONE · §37 · PERCHÉ QUESTO IMPORTA OLTRE LE METRICHE. L'insight più profondo da 6 mesi di RAGAS continuo: il retrieval è un SISTEMA VIVENTE, non una configurazione. Trattare il retrieval come una pipeline statica valutata una volta produce fallimento prevedibile.

Trattarlo come un sistema vivente che richiede monitoring continuo e difesa attiva produce qualità durevole. Questo si applica ampiamente: ogni componente dinamico (memoria, prompt, skill, embedding) drifta nel tempo e richiede valutazione continua, non validazione one-time.

Per gli alert più consequenziali al top-1%, usiamo un ensemble a 2 judge (Claude Sonnet 4.5 + GPT-4o) con flagging esplicito del disaccordo. Procedura: entrambi i judge scorano indipendentemente il retrieval campionato; se gli score differiscono di >0.15 (su qualsiasi asse), il caso è escalato a review umana. Tasso di disaccordo: ~5% dei casi ensemble-judged.

Dei casi escalati, la review umana sostiene il judge A 41%, il judge B 38%, nessuno 21% (ambiguità genuina). Il tasso del 21% di ambiguità genuina è informativo: delimita il floor di precisione della metodologia LLM-judge e motiva l'human-in-loop per decisioni high-stakes.

Abbiamo aggiunto un check strutturale che gira ogni ora: interroga i metadata del vector DB per la versione del modello embedding di tutti i vettori stored; alert se un qualsiasi vettore è da una versione diversa dal modello embedding di produzione corrente. Latenza alert da version mismatch a fire: <1 ora. Questo cattura il fallimento più comune di embedding-drift (un backfill parziale che ha mancato alcuni documenti). In 12 mesi abbiamo catturato 4 casi di backfill parziale via questo check, ciascuno riparato entro 24 ore.

Classifichiamo ogni query in uno dei 12 bucket di tipo query via un piccolo classifier (Claude Haiku, ~$0,001 per query). La distribuzione dei bucket è tracciata giornalmente. Test Kolmogorov-Smirnov (soglia p=0.01) sulla distribuzione rolling 14-day vs prior 14-day flagga shift significativi.

Cattura i 3 eventi più recenti di evoluzione agent (nuova skill, aggiornamento prompt, shift capacità) che hanno prodotto drift della distribuzione di query. Latenza da drift ad alert: ~24 ore (il ciclo di aggregazione giornaliero).

CASE STUDY · §41 · ALERT #2 · COLLASSO FAITHFULNESS NEL DIPARTIMENTO SETTING. Background: il dipartimento Setting usa retrieval per lookup di prospect-intent. Alert: faithfulness scesa di 0.27 std (la magnitudine di alert singolo più grande in 6 mesi) in 6 ore.

Investigazione: un singolo risultato di retrieval contenente un trascritto di sales-call fuorviante era stato fortemente pesato su molteplici query. Il trascritto era da un prospect early-stage confuso loggato per errore come cliente convertito nel CRM sorgente. Fix: CRM sorgente corretto, il documento affetto re-indicizzato, aggiunto un gate "transcript source verification" alla pipeline di indicizzazione.

Post-fix: faithfulness recuperata entro 4 ore. Lezione: la verifica source-of-truth appartiene al tempo di indicizzazione, non al tempo di retrieval.

CASE STUDY · §42 · ALERT #9 · QUERY-PATTERN DRIFT IN DELIVERY. Background: il dipartimento Delivery ha aggiunto una nuova skill di project-management a marzo 2026. Alert: answer-relevance scesa di 0.13 std in 11 giorni; query-pattern stability scattata (chi-square p=0.003).

Investigazione: la nuova skill chiedeva "project status" mentre lo store aveva contenuto taggato "project state" e "engagement status". 3 fix applicate: (a) espansione di sinonimi nell'indicizzazione, (b) prompt della skill aggiornato per usare phrasing multi-vocabolario, (c) l'indice è stato riaddestrato sul vocabolario più ampio. Post-fix: relevance recuperata entro 7 giorni. Il pattern è ora generale: le skill-addition triggerano audit di vocabolario automatico.

CASE STUDY · §43 · INVESTIGAZIONE NULL-ALERT · PERCHÉ I FALSI POSITIVI ERANO ACCETTABILI. Background: dei 14 alert, tutti i 14 sono riconducibili a root cause genuine. Dei 6 fire del modulo di audit (separati dagli alert di regressione), 6 erano falsi positivi (contenuto ad alta entropia che matchava l'euristica secret-pattern).

I 6 falsi positivi sono stati ciascuno reviewati da umano in <2 minuti; costo totale operator-time ~12 minuti su 12 mesi. Il costo è accettabile vs il costo catastrofico di un falso negativo (un singolo leak genuino di credentials surclasserebbe il tempo cumulativo di review di falsi positivi). La soglia sul modulo di audit è deliberatamente tarata verso falso-positivo sopra falso-negativo.

Proponiamo una tassonomia per i fallimenti RAG di dimensione temporale osservabili in agents long-lived. (T1) STORE-GROWTH DRIFT: cambiamento precision/recall in funzione della dimensione dello store — più evidente su query legacy con alto overlap. (T2) EMBEDDING DRIFT: mismatch dello spazio cross-model dopo upgrade di modello. (T3) QUERY DRIFT: pattern di query che shiftano più velocemente dell'ottimizzazione dell'indice. (T4) FAITHFULNESS DRIFT: cambiamenti di qualità di contenuto (inquinamento memoria, write accidentali) che producono drift della faithfulness della risposta. (T5) LATENZA DRIFT: creep di latenza senza cambiamento di qualità. La tassonomia a 5 categorie fornisce un vocabolario strutturato di analisi root-cause a cui i 14 alert scattati possono essere mappati.

DISCUSSIONE ESTESA · §45 · GUARDANDO AVANTI · RAG MULTI-MODALE. RAGAS punta a RAG solo testo. I workspace agentic recuperano sempre più immagini (contesto vision-LLM), codice (semantic search su repository sorgente), dati strutturati (BigQuery via linguaggio naturale).

L'estensione di RAGAS (e RAGAS continuo) al multi-modale è aperta. Abbiamo lavoro prototipale su valutazione image-RAG (faithfulness via judge vision-LLM) ma non l'abbiamo deployato su scala. I pattern documentati in questo paper (drift temporale, ensemble di judge, recall drift) dovrebbero generalizzare al multi-modale ma con operazionalizzazioni specifiche per la modalità.

DISCUSSIONE ESTESA · §46 · PERCHÉ IL TASSO DI SAMPLING 5%. Il tasso di sampling 5% non è stato scelto arbitrariamente. È il risultato di un'ottimizzazione: minimizzare il costo del judge sotto un vincolo sulla latenza dell'alert (95% di probabilità di rilevare una regressione di 0.10-std entro 14 giorni). Al sampling 1%, la latenza dell'alert sale a 47 giorni p95; al 10%, il costo del judge sale 2× senza miglioramento significativo di latenza.

Il sampling 5% è il punto della frontiera dominante. Workspace con livelli di traffico diversi hanno bisogno di tassi di sampling diversi; il principio di ottimizzazione è lo stesso.

La pipeline di produzione contenuti Madani opera un sistema di quality-control a 17 layer dove ogni layer interroga una knowledge base domain-specific (brand identity, ICP profile, framework library, corpus di contenuti pregressi). Pre-strumentazione RAGAS, la pipeline tracciava solo pass/fail terminale del QC; la qualità del retrieval era di fatto non osservabile. Abbiamo deployato un harness di strumentazione RAGAS continuo su una finestra di 14 settimane coprendo 2.640 invocazioni di layer.

Il finding principale ha contraddetto l'ipotesi di lavoro del team. Il team aveva assunto che i fallimenti di retrieval si concentrassero sul layer ICP (la knowledge base con più alta cardinalità); in realtà il layer ICP ha ottenuto lo score più alto su faithfulness RAGAS (0.91) e context-precision (0.87). I fallimenti di retrieval dominanti si sono invece concentrati sul layer framework, dove la context-recall ha scorato 0.62 — l'agent recuperava i documenti framework giusti ma solo le sezioni introduttive, mancando i dettagli operativi che vivevano 1.200+ token dentro il documento.

La root cause è stata l'allineamento dei chunk-boundary: i documenti framework erano stati chunked a finestre di 800 token che spezzavano ai confini di sezione, quindi i chunk introduttivi scoravano alto sulla similarity di retrieval ma i chunk operativi scoravano più basso (nessun overlap di keyword con la query originale). Re-chunkare il corpus framework a finestre di 1.500 token con overlap di 300 token, più aggiungere un pass parent-document retrieval che ritorna il documento intero quando un qualsiasi chunk scora sopra soglia, ha alzato la context-recall del layer framework da 0.62 a 0.88 (+26 punti assoluti) in 30 giorni. Effetto downstream sulla pipeline di contenuti: il false-pass rate al Layer 8 (claim-density) è sceso dal 14% al 6% perché il Layer 8 ora recuperava le definizioni operative di claim-density invece del boilerplate framework-overview.

La strumentazione RAGAS continua ha fatto emergere un fix architetturale che nessuna dashboard di pass-rate terminale avrebbe potuto rilevare. Costo engineering 8 engineer-day per il re-chunking + 4 giorni per l'harness RAGAS; payback in 21 giorni in tempo di review manuale risparmiato. Cross-reference WSB-07 §36 documenta l'audit MAST parallelo della stessa pipeline; le due metodologie sono state complementari — MAST classificava COSA falliva, RAGAS quantificava PERCHÉ falliva al layer di retrieval.

L'agent voice-channel di Madani gira una memoria persistente di 18 mesi di interazioni passate con prospect. Pre-strumentazione, il team si affidava a un audit RAGAS snapshot fatto al deployment che aveva scorato faithfulness 0.89, context-precision 0.84, context-recall 0.81 — Grade A. Abbiamo deployato una strumentazione RAGAS continua longitudinale e osservato drift monotonico su tutte e quattro le metriche in 12 mesi.

Al mese 12, la faithfulness era decaduta a 0.71, la context-precision a 0.68, la context-recall a 0.55. Il driver dominante era la corruzione del segnale cross-document: il memory store era cresciuto da 4.200 snippet di interazione al mese 0 a 28.400 al mese 12, e la ricerca per embedding-similarity ora ritornava snippet semanticamente-adiacenti ma contestualmente-stale (es. un prospect che aveva declinato 8 mesi prima veniva ora recuperato come referenza "prospect simile" per un prospect corrente, inquinando il contesto dell'agent con linguaggio di sentiment negativo stale). Questa è la modalità di fallimento recall-drift che il RAGAS snapshot non può rilevare per definizione — emerge solo quando lo stesso workflow è misurato contro un target in movimento.

La remediation è stata triplice: (i) un pesaggio time-decay sulla similarity di retrieval (alpha=0.85 per trimestre); (ii) un job di compattazione memoria che ritirava snippet senza hit di retrieval in 90 giorni; (iii) un pass di re-embedding periodico quando il modello embedding cambiava (cosa che era successa due volte silenziosamente durante i 18 mesi). Post-remediation: faithfulness recuperata a 0.86, context-precision a 0.81, context-recall a 0.77. Il case study dimostra che gli agents long-lived hanno bisogno di RAGAS continuo come invariante operativo; il RAGAS snapshot è approssimativamente inutile per workload di produzione con memoria persistente.

Cross-reference WSB-12 (verbal-RL per agents long-lived) tratta questo dall'angolo della compattazione memoria; questo case study è il companion lato retrieval. La reliability dashboard del team ora elenca le metriche RAGAS con una finestra rolling 30-day come SLO richiesta.

L'agent finance-reconciliation opera su una knowledge base di 1.200+ regole di parsing bank-statement, mapping payment-counterparty e matrici di tax-jurisdiction. Le metriche classiche RAGAS hanno scorato ciascuna 0.84-0.88 (grade A) al deployment. Tuttavia il workflow esibiva un tasso di fallimento del 19% che il team non riusciva a diagnosticare.

Abbiamo aggiunto una quinta metrica RAGAS sperimentale di estensione — cross-document consistency — che misura se molteplici chunk recuperati da documenti diversi concordano sulla risposta. Lo score di cross-document consistency era 0.41, ben sotto la soglia convenzionale di 0.75. La causa era un'ambiguità semantica nota nella terminologia finance: "net" può significare post-tassa in un documento e post-sconto in un altro; "reconciled" può significare tre cose diverse a seconda di quale doc del payment-processor era autoritativo.

Le metriche classiche RAGAS misuravano ogni retrieval contro la domanda indipendentemente e davano score alti; la cross-document consistency ha esposto che i chunk recuperati si contraddicevano l'un l'altro. Remediation: introdurre un tag "primary authority" per documento così che il retrieval preferisca documenti autoritativi quando esistono contraddizioni; aggiungere un pass di contradiction-detection che flagga retrieval a bassa consistenza per review umana. Post-remediation: cross-document consistency salita da 0.41 a 0.78; tasso di fallimento finance-reconciliation sceso dal 19% all'8%.

Questo case study introduce e valida l'estensione cross-document consistency a RAGAS — controintuitiva perché le metriche classiche RAGAS apparivano eccellenti e la modalità di fallimento era invisibile per loro. Cross-reference WSB-11 (catalogo anti-pattern) elenca "high-RAGAS-low-consistency" come anti-pattern AP-22.

DEEP-DIVE EMPIRICO · §50 · VALIDAZIONE STATISTICA DELLE QUATTRO METRICHE CLASSICHE RAGAS. Abbiamo valutato le quattro metriche classiche RAGAS (faithfulness, answer relevance, context precision, context recall) per accordo inter-grader, potenza statistica e robustezza su un benchmark da 480 trace tratto da workflow di produzione su lead-generation, finance, content-production e voice-channel. Due grader addestrati (con una sessione di calibrazione di 6 ore contro la rubrica di Es et al.) hanno codificato ogni metrica su una scala ordinale a 5 punti.

Krippendorff's alpha inter-grader (la generalizzazione multi-coder di Cohen's kappa appropriata per dati ordinali) era 0.81 per faithfulness, 0.76 per answer relevance, 0.79 per context precision, 0.72 per context recall. L'accordo più basso era su context recall, dove il confine tra "abbastanza completo" e "manca informazione critica" è judgment-laden. I disaccordi si concentravano dove la domanda stessa era ambigua, suggerendo che la context recall è in parte una metrica di qualità di domanda, non puramente una metrica di qualità di retrieval.

Potenza statistica: con n=480 e 5 livelli ordinali, il design ha potenza 88% di rilevare una differenza di 0.1 punti tra due qualsiasi metriche a alpha=0.05. Bootstrap 95% confidence interval sulla media per-metrica erano ±0.04 (faithfulness), ±0.05 (answer relevance), ±0.04 (context precision), ±0.06 (context recall). Analisi di sensibilità: abbiamo rifatto l'assessment con l'implementazione RAGAS LLM-grader alternativa (usando un modello GPT-4-class come grader) e trovato correlazione r=0.89 con gli score human-grader, più bassa del r=0.94 riportato in Es et al. (2024), suggerendo che il RAGAS LLM-grader è affidabile ma il RAGAS human-grader è il gold standard per la valutazione high-stakes.

Sensibilità a variazione di chunk-size (abbiamo re-chunkato il corpus sorgente a 500, 1000, 1500, 2000 token) ha mostrato che la context recall è altamente sensibile (range 0.62-0.88 a seconda del chunk size) mentre la faithfulness è robusta (range 0.86-0.91). Questo è consistente con il finding di §47: l'allineamento dei chunk-boundary è una delle scelte di design più consequenziali nei sistemi valutati con RAGAS, e il RAGAS continuo deve includere il chunk-size come variabile tracciata.

ANTI-PATTERN DI IMPLEMENTAZIONE · §51 · CINQUE MODALITÀ DI FALLIMENTO NELLE ADOZIONI RAGAS CHE ABBIAMO AUDITATO. Su 9 team che Madani Lab ha consigliato sull'adozione RAGAS tra Q2 2025 e Q1 2026, cinque anti-pattern ricorrono. (1) ""Audit RAGAS snapshot-only"": i team fanno girare RAGAS una volta al deployment, riportano Grade-A e assumono che lo score sia stabile. Come mostra §48, il recall drift è il fallimento long-horizon dominante per workload con memoria persistente; il RAGAS snapshot è approssimativamente inutile oltre il mese 3.

Remediation: deploya RAGAS continuo con come minimo una rolling window di 30 giorni; alert su drift che eccede 5 punti percentuali. (2) ""RAGAS LLM-grader senza spot-check umano"": i team usano il RAGAS LLM-grader esclusivamente perché è più economico. Non possono rilevare quando la calibrazione del LLM-grader drifta (es. quando il modello LLM-grader sottostante è aggiornato silenziosamente). Remediation: spot-check human-grader su un campione random di 20 trace al mese, valida la correlazione LLM-grader. (3) ""RAGAS come criterio di model selection"": i team interpretano la context recall bassa come evidenza che il LLM è cattivo e propongono di switchare modelli, quando il fallimento è al layer di retrieval (chunk boundaries, modello embedding, soglia similarity).

Come in WSB-07, metriche basse non dovrebbero guidare swap di modello senza aver escluso fix lato retrieval. (4) ""Ignorare l'answer relevance"": i team sovra-indicizzano sulla faithfulness perché l'hallucination è il fallimento high-profile, poi shippano sistemi con faithfulness alta ma answer relevance bassa (l'agent recupera correttamente e non hallucina, ma la risposta non matcha quello che l'utente ha chiesto). Remediation: enforce una soglia minima su tutte e quattro le metriche, non solo faithfulness. (5) ""Assunzione del corpus singolo"": i team fanno girare RAGAS sul corpus originale e assumono che gli score generalizzino quando il corpus è esteso. Non lo fanno — il segnale cross-document degrada non linearmente con la dimensione del corpus.

Remediation: rifai girare RAGAS continuo ogni volta che la dimensione del corpus cresce di >25% o quando nuove sorgenti di documenti sono aggiunte; i chunk boundary potrebbero dover essere ri-tarati.

INTEGRAZIONE CROSS-PILLAR · §52 · DOVE LA RETRIEVAL-EVAL TOCCA GLI ALTRI WAB Pillar. RAGAS come operazionalizzazione del Pillar P01-CONTEXT si integra densamente con cinque Pillar vicini e ha un conflitto notevole. Integrazione complementare con P03 Memory: il RAGAS continuo rileva il drift di retrieval indotto dalla memoria prima che emerga come fallimento di task, fornendo un segnale di early-warning per compattazione memoria o re-embedding.

Integrazione complementare con P06 Reliability: la classificazione MAST dei fallimenti di retrieval (FM-3.1 unhelpful tool output dove lo strumento è il retrieval) feeda back nella prioritizzazione delle metriche RAGAS. I due Pillar fanno cross-validation come in §49: high-RAGAS-low-MAST e low-RAGAS-high-MAST sono entrambi segnali di mis-calibrazione in uno dei due sistemi. Integrazione con P09 Observability: il RAGAS continuo richiede logging strutturato di ogni chiamata di retrieval con i chunk ritornati — un prerequisito P09-L2.

I team che provano a shippare RAGAS continuo senza P09-L2 non possono replay-are retrieval o auditare il drift. Integrazione con P05 Metacognition: la confidence del MetaCogAgent su task retrieval-grounded correla r=0.62 con la corrispondente faithfulness RAGAS; i due segnali possono essere fusi come un 7° fattore nel composite c-score, con peso derivato empiricamente. Integrazione con P11 Auto-Improvement: i findings RAGAS feedano lo stage PROPOSE del ciclo Dreams — context-recall cronicamente bassa propone nuove strategie di chunking, faithfulness cronicamente bassa propone nuove soglie di retrieval.

Conflitto strutturale con P02 Skills: mano a mano che i workflow scalano lo skill count oltre ~30, ogni skill porta la sua knowledge base; far girare RAGAS continuo per-skill diventa costoso (costo lineare nello skill count), forzando un triage: prioritizzare le top-5 skill ad alto traffico per RAGAS continuo full, downsamplare le altre ad audit mensili. Questa è una tensione di budget P02-vs-P01 che non ha risoluzione pulita a L4. La tensione è la giustificazione empirica del perché il peso WAB sul P01 Context è 8,33% invece che più alto: il P01 è necessario a L2 per qualunque workflow di produzione ma il suo costo marginale a L4 scala superlinearmente con lo skill count, quindi un workspace ad alto P02-L4 + medio P01-L3 surclassa l'uniforme-L4 nello scoring cost-adjusted.

(Q1) IPOTESI: per workload sopra una scala di knowledge-base di 10.000 documenti, gli score RAGAS snapshot hanno correlazione inferiore a r=0.30 con gli score RAGAS a 6 mesi futuri; per workload sotto i 1.000 documenti, la correlazione eccede r=0.70. TEST DI FALSIFICAZIONE: misurazione longitudinale RAGAS su 20 workspace stratificati per dimensione del corpus. (Q2) IPOTESI: la cross-document consistency (l'estensione di §49) è la metrica RAGAS più discriminante per workload dove la knowledge base contiene conflitti semantici; gli score RAGAS classici falliscono nel predire successo di task in tali workload. TEST DI FALSIFICAZIONE: confronto appaiato di RAGAS classico vs esteso che predice successo di task su un benchmark di 100 workload tra domini conflict-rich e conflict-poor. (Q3) IPOTESI: la correlazione del RAGAS LLM-grader con il RAGAS human-grader decade al tasso di 0.02 per trimestre mano a mano che il modello LLM-grader sottostante evolve; il RAGAS LLM-grader un-recalibrated diventa inaffidabile entro 12 mesi.

TEST DI FALSIFICAZIONE: studio longitudinale di 24 mesi con spot-check human-grader trimestrali su un benchmark fisso. (Q4) IPOTESI: l'ottimizzazione del chunk-size minimizza la varianza della context recall più di quanto minimizzi la varianza della faithfulness, suggerendo che i chunker RAGAS-aware dovrebbero ottimizzare congiuntamente per entrambi. TEST DI FALSIFICAZIONE: benchmark a 50 corpus, grid search su chunk size, misura della riduzione di varianza di entrambe le metriche. (Q5) IPOTESI: l'efficacia del RAGAS continuo dipende dal tuning della soglia di alert; soglie ipersensibili (alert su drop <2 punti) producono alert fatigue e la remediation non segue gli alert; soglie iposensibili (alert su drop <10 punti) mancano il drift fino a che si verificano fallimenti di task. TEST DI FALSIFICAZIONE: studio A/B di tuning di soglia su 6 team. (Q6) IPOTESI: le metriche RAGAS calcolate su coppie domanda-risposta sintetiche generate da un LLM correlano r>0.80 con le metriche RAGAS calcolate su trace di produzione reali, permettendo benchmarking cost-effective.

TEST DI FALSIFICAZIONE: misurazione RAGAS sintetico-vs-produzione appaiata su 15 workflow. (Q7) IPOTESI: le soglie di cross-document consistency calibrate su un singolo dominio non si trasferiscono; un domain expert del workflow deve settare la soglia per-dominio, e una soglia di default 0.75 mis-fire nel 40% dei nuovi domini. TEST DI FALSIFICAZIONE: studio a 8 domini con deployment default-threshold vs threshold calibrata per-dominio, misura del tasso di mis-fire. (Q8) IPOTESI: per agents long-lived, la causa dominante del decadimento della faithfulness RAGAS non è il bloat di memoria ma l'upgrade del modello embedding — eventi silenziosi di re-embedding introducono drift semantico più grande dell'effetto cumulativo di 12 mesi di crescita di memoria. TEST DI FALSIFICAZIONE: studio appaiato con modello embedding frozen vs modello embedding upgrade-allowed, misura del tasso di decadimento della faithfulness su 12 mesi. (Q9) IPOTESI: aggiungere uno step di self-assessment metacognitivo prima del retrieval (dove l'agent verbalizza la sua incertezza sulla domanda) migliora gli score di context-precision di >5 punti senza affettare la context-recall, perché query incerte triggerano retrieval più ampio.

TEST DI FALSIFICAZIONE: confronto A/B con e senza self-assessment pre-retrieval su un benchmark fisso.

[1] Es S., James J., Espinosa-Anke L., Schockaert S. (2024), RAGAS: Automated Evaluation of Retrieval Augmented Generation, EACL 2024 System Demonstrations, arXiv:2309.15217, Cardiff University NLP. [2] Lewis P. et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS. [3] Gao Y., Xiong Y., Gao X., Jia K., Pan J., Bi Y., Dai Y., Sun J., Wang H., Wang H. (2024), Retrieval-Augmented Generation for Large Language Models: A Survey, arXiv:2312.10997. [4] Saad-Falcon J., Khattab O., Potts C., Zaharia M. (2024), ARES: An Automated Evaluation Framework for RAG Systems, NAACL. [5] Niu C., Wu Y., Zhu J., Xu S., Shum K., Zhong R., Song J., Zhang T. (2024), RAGTruth: A Hallucination Corpus, ACL. [6] Yang Z., Qi P., Zhang S., Bengio Y., Cohen W., Salakhutdinov R., Manning C. (2018), HotpotQA, EMNLP. [7] Packer C., Wooders S., Lin K., Fang V., Patil S.G., Stoica I., Gonzalez J.E. (2023), MemGPT: Towards LLMs as Operating Systems, arXiv:2310.08560. [8] Park J., Cha S., Lee J. (2024), A-Mem: Agentic Memory for LLM Agents. [9] Cemri M., Pan M.Z., Yang S., Agrawal L.A., Chopra B., Tiwari R., Keutzer K., Parameswaran A., Klein D., Ramchandran K., Zaharia M., Gonzalez J.E., Stoica I. (2025), Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657v3, NeurIPS 2025. [10] Cohen J. (1960), A Coefficient of Agreement for Nominal Scales, Educational and Psychological Measurement 20:37-46. [11] Malkov Y.A., Yashunin D.A. (2018), Efficient and Robust Approximate Nearest Neighbor Search Using HNSW, TPAMI. [12] LangChain (2024), LangSmith Documentation. [13] Arize AI (2024), Phoenix: Open-Source LLM Observability. [14] Anthropic (2025), Claude Sonnet 4.5 Technical Report. [15] OpenAI (2024), text-embedding-3-large Documentation. [16] Wang C. & Shu Y. (2026), MetaCogAgent, arXiv:2605.17292v1. [17] Tran D. & Kiela D. (2026), Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning, arXiv:2604.02460. [18] Shinn N. et al. (2023), Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS. [19] Madani Lab (2026), Continuous-RAGAS Reference Implementation v0.3.4 (Python, MIT). [20] explodinggradients (2024), ragas: open-source RAG evaluation framework, github.com/explodinggradients/ragas. [21] Madani Lab (2026), retrieval-pillar-policy.md v1.3. [22] Madani Lab (2026), memory-write-gate skill v1.0.