Jev AI nel RAG: scegliere le fonti prima della risposta

Jev AI può servire nel RAG a valutare i passaggi recuperati prima che un modello generativo scriva la risposta. Il filtro va progettato come una decisione sulle fonti: non sostituisce la ricerca, gli embedding o il controllo dei permessi.

Un documento vicino alla domanda può portare fuori strada

In una knowledge base aziendale convivono manuali, email operative, listini e vecchie procedure. La ricerca può trovare un testo con le parole giuste che però descrive una situazione diversa. Una policy dedicata ai rivenditori, per esempio, non risponde necessariamente alla domanda di un cliente finale. Un documento superato può essere molto simile alla domanda proprio perché usa il vocabolario abituale dell’azienda.

La spiegazione del RAG aiuta a leggere il processo completo. Il punto qui è più circoscritto: dopo aver trovato alcuni candidati, quali passaggi meritano di arrivare alla fase di risposta? Separare questa scelta permette di valutare un problema preciso. Non occorre attribuire al filtro la responsabilità dell’intero chatbot.

Il cookbook ufficiale per i passaggi RAG propone quattro valutazioni: pertinenza, evidenza, contraddizione e presenza di istruzioni sospette. L’applicazione separa evidenze, conflitti e materiali esclusi; un LLM distinto genera la risposta. È un esempio progettuale, non una garanzia che ogni risposta sarà corretta.

Nel nostro progetto, le domande rivolte al filtro devono corrispondere a criteri comprensibili. “È un buon documento?” confonde qualità della scrittura, autorevolezza e utilità. “Questo passaggio descrive le condizioni applicabili alla richiesta?” obbliga invece a chiarire quali condizioni contano. Il responsabile operativo può controllare il criterio prima di vedere qualsiasi risultato del modello.

Disegnare il percorso con responsabilità separate

L’ordine consigliato per questo progetto è: riconoscere l’utente, limitare l’archivio accessibile, recuperare i candidati, controllare i metadati, valutare i passaggi, comporre la risposta e verificarne il supporto. Ogni passaggio dovrebbe avere un motivo per trattenere o scartare un documento. Senza questa separazione, un risultato sbagliato diventa difficile da diagnosticare.

La documentazione State distingue i materiali dalle domande di valutazione: uno stato può contenere testo o strutture JSON. Qui proponiamo campi separati per domanda, passaggio e metadati. È una scelta per rendere ispezionabile il caso, non un payload API pronto da copiare.

La domanda dell’utente va mantenuta nella sua forma concreta. Riscriverla fino a renderla più generica potrebbe far sembrare pertinente un testo che non risponde al problema iniziale. Se il recupero usa una variante della domanda, registra entrambe le versioni per capire quale ha selezionato il candidato.

La documentazione System One descrive Jev come componente che valuta input testuali e non genera conversazioni. Nel flusso qui discusso, quindi, la composizione della risposta resta un lavoro separato. La guida generale a Jev AI chiarisce questa collocazione senza confonderla con un’interfaccia di chat.

Questa è una proposta di architettura. La colonna dei permessi richiede regole del software: non va delegata a un giudizio sul testo. I guardrail degli agenti AI affrontano proprio la distinzione tra classificare un rischio e impedire un’operazione non consentita.

Le quattro valutazioni non devono diventare un voto unico

Un passaggio può essere pertinente e, nello stesso tempo, contraddire un’altra fonte. Se sommi tutto in un unico punteggio, rischi di perdere il motivo per cui quel testo conta. È preferibile conservare gli esiti separati e tradurli in un comportamento deciso dall’azienda.

Per la pertinenza, la domanda utile riguarda oggetto e ambito. Un manuale della stessa famiglia di prodotti può parlare di una versione diversa. Per il sostegno, serve invece il collegamento tra il passaggio e ciò che si intende affermare. Una premessa corretta non autorizza una conclusione più ampia. Per il conflitto, confronta le condizioni: due testi diversi non sono sempre incompatibili.

La quarta valutazione riguarda materiale che tenta di impartire istruzioni. Nel progetto, quel testo viene trattato come dato da esaminare, non come autorità sul funzionamento del sistema. La regola di accesso e la disciplina del generatore devono restare indipendenti anche quando il filtro non segnala nulla.

Decidi poi le uscite: materiale utilizzabile, conflitto da mostrare al responsabile, candidato da escludere e caso da approfondire. La revisione dei giudizi incerti va dimensionata sul lavoro del referente, prima di attivare il filtro. Non serve usare queste stesse etichette nell’interfaccia del cliente. All’operatore interno, però, dovrebbe risultare evidente perché una risposta è stata fermata. Una semplice scritta “nessun risultato” nasconde differenze importanti tra archivio vuoto e fonti discordanti.

Caso ipotetico: ricambi per un produttore lombardo

Una PMI italiana ipotetica produce macchinari e vuole aiutare il postvendita a rispondere sulla compatibilità dei ricambi. Nell’archivio ci sono schede per versioni simili, note di officina e un catalogo aggiornato. La domanda indica il modello, ma non l’anno di produzione.

Il recupero trova due schede vicine. Il responsabile del progetto non chiede al filtro di indovinare quale sia giusta. Imposta prima una regola: per alcune famiglie, la compatibilità richiede anche il codice di revisione. Quando manca, la risposta deve chiedere quel codice. Il filtro può selezionare i passaggi che spiegano la condizione, mentre la scelta definitiva resta sospesa.

Per i casi completi, il catalogo valido ha un ruolo diverso da una nota informale. L’azienda assegna ai documenti un campo di autorità e una relazione con il prodotto. Questo lavoro appartiene alla classificazione dei documenti: se ogni file è soltanto un testo anonimo, il filtro riceve un problema meno definito.

Nel pilota si controllano soprattutto gli accoppiamenti sbagliati tra versioni. Un testo molto pertinente ma applicabile al modello precedente è un errore più interessante di un risultato palesemente estraneo. Il postvendita confronta i passaggi scelti con quelli che avrebbe utilizzato un tecnico. Gli esiti restano ipotetici: non stiamo riportando un test cliente o una percentuale misurata.

Un’altra misura utile è il numero di richieste di integrazione appropriate. Se il sistema chiede sempre un codice anche quando la domanda contiene già tutto, il flusso rallenta. Se non lo chiede nei casi incompleti, prepara una risposta fragile. La qualità si vede nel comportamento finale, non nel solo numero di documenti scartati.

Caso ipotetico: condizioni commerciali di un distributore

Una seconda PMI italiana ipotetica distribuisce materiali per installatori. La knowledge base contiene condizioni standard, eccezioni per alcuni contratti e una vecchia procedura sulle spese di consegna. Un operatore chiede se un ordine può essere spedito senza costi aggiuntivi.

La ricerca recupera un testo che parla di spedizione gratuita, ma la clausola riguarda un’area geografica diversa. Il filtro deve poter segnalare che l’argomento è pertinente senza considerarlo sufficiente a rispondere. La regola deterministica sui metadati verifica area e data; la valutazione del passaggio cerca eventuali condizioni ulteriori nel testo.

Se due procedure applicabili non concordano, il progetto mostra il contrasto all’ufficio commerciale. Il responsabile aggiorna la policy o chiarisce quale prevale. Non basta scegliere la fonte più recente quando la più vecchia rappresenta un’eccezione contrattuale ancora valida. L’autorità del documento è una decisione dell’azienda, non una proprietà ricavabile dalla sua fluidità linguistica.

La risposta preparata usa le fonti autorizzate e indica le condizioni rilevanti. Prima dell’uso esterno, la verifica delle citazioni controlla se quelle condizioni sostengono davvero l’affermazione. I due controlli si completano: scegliere un buon passaggio prima della scrittura non impedisce alla scrittura di estenderne il significato.

Recuperare bene prima di filtrare molto

Un filtro può valutare soltanto ciò che riceve. Se la procedura corretta non entra nell’insieme dei candidati, non potrà essere scelta. Per questo il confronto tra recupero e filtraggio va fatto su due livelli: disponibilità della fonte utile e selezione tra le fonti disponibili.

Nella guida agli embedding e ai PDF il tema è la rappresentazione dei contenuti. Qui il punto operativo è conservare la provenienza dei passaggi. Se una clausola è divisa tra due estratti, un frammento isolato può perdere il suo limite. La dimensione del passaggio dovrebbe essere scelta con esempi reali, guardando dove iniziano e finiscono le condizioni.

Non trasformare questo problema in una richiesta di inviare sempre documenti interi. Una procedura lunga contiene anche sezioni non pertinenti. Prepara estratti con titolo, clausola e contesto vicino, mantenendo il riferimento al file originale. Quando serve un paragrafo precedente per interpretare un’eccezione, includilo consapevolmente.

Il numero di candidati è una scelta di compromesso. Valutarne molti aumenta il lavoro del flusso; valutarne pochi può lasciare fuori la fonte corretta. Nel pilota proponiamo di provare alcune configurazioni sullo stesso insieme di domande, registrando sia qualità sia tempo. Non esiste, in questo articolo, un numero ottimale misurato valido per tutte le PMI.

Apri la scheda di un passaggio da valutare

Domanda: il problema concreto e i dati già disponibili.

Fonte: documento, versione, ambito, proprietario e punto preciso da cui proviene l’estratto.

Esito: utile, insufficiente, incompatibile o da approfondire, secondo criteri aziendali scritti.

Prossima azione: utilizzare il passaggio, cercare una fonte ulteriore oppure coinvolgere il referente.

Conservare il motivo di esclusione senza duplicare l’archivio

Quando un passaggio viene scartato, il progetto dovrebbe conservare una motivazione comprensibile. “Non pertinente” aiuta poco se il problema reale era la versione del prodotto. Una distinzione tra ambito errato, fonte superata, contenuto insufficiente e conflitto consente al proprietario della knowledge base di intervenire nel punto corretto.

Questo registro non deve diventare una seconda copia completa dei documenti. Può contenere identificativo, versione, motivo e riferimento al caso. Il revisore apre il testo nell’ambiente autorizzato quando serve. La scelta delle informazioni da conservare va collegata agli accessi e alla durata del registro.

Proponiamo inoltre una prova di lettura per l’operatore: riceve una domanda, i passaggi trattenuti e i motivi delle esclusioni, poi indica se riesce a ricostruire la decisione. Se deve aprire dieci sistemi o dedurre quale versione è stata usata, la spiegazione del filtro non è ancora utile. Questa prova riguarda l’interfaccia del lavoro, oltre alla classificazione.

Un documento escluso ricorrentemente può avere due destini diversi. Se è valido ma recuperato fuori ambito, occorre migliorare metadati o ricerca. Se è ambiguo e confonde anche i tecnici, occorre riscrivere il contenuto. Non conviene cancellarlo soltanto per far apparire migliori le metriche del filtro: potrebbe servire in altri casi.

Il gruppo può esaminare periodicamente alcune esclusioni e alcune ammissioni. Guarda soprattutto i casi in cui il motivo non corrisponde al giudizio del referente. Questa revisione permette di migliorare il processo senza trasformare ogni singola risposta in una lunga indagine manuale.

Valutare il filtro contro una base di riferimento

Prepara un insieme di domande che rappresenti il lavoro dell’ufficio: casi frequenti, eccezioni, informazioni mancanti e documenti in conflitto. Per ogni domanda, un referente indica i passaggi necessari e le conclusioni ammesse. Non limitarti a segnare quale risposta “suona meglio”. Serve poter spiegare quale condizione è stata rispettata o dimenticata.

Confronta un flusso senza il nuovo filtro e uno che lo utilizza, mantenendo uguali gli altri passaggi. Conta le evidenze utili eliminate, i materiali fuorvianti trattenuti, i conflitti resi visibili e le risposte che avrebbero dovuto fermarsi. Osserva anche il tempo aggiunto e il lavoro richiesto agli operatori. Nessuna di queste misure va sostituita dal numero di citazioni presenti.

Quando un risultato peggiora, individua lo stadio responsabile. Fonte assente nel recupero, metadato sbagliato, filtro troppo restrittivo e risposta troppo ampia richiedono correzioni diverse. Aggiungere una domanda generica al modello non risolve automaticamente le quattro cause.

Il proprietario della knowledge base deve inoltre ricevere le lacune ricorrenti. Se dieci richieste simili richiedono ogni volta una persona perché manca una procedura, la soluzione può essere scrivere quella procedura. Il RAG rende visibile un bisogno organizzativo: non dovrebbe mascherarlo con risposte plausibili.

Per arrivare a un sistema utile, una consulenza AI può partire da fonti, autorizzazioni e domande campione. La decisione di introdurre Jev va presa dopo il confronto, quando è chiaro quale errore corregge e quale costo aggiunge.

Progettiamo il filtro della tua knowledge base e misuriamo il risultato sul lavoro reale dell’ufficio.