RAG per sviluppatori: quando serve davvero

RAG significa recuperare pezzi rilevanti da una base di conoscenza e inserirli nel prompt. È utile quando il contesto è troppo grande o cambia spesso. Non è una magia e non è sempre necessario.

Perché questa lezione conta

Molti team passano da “incollo tutto nel prompt” a “serve un RAG” troppo presto. Un sistema RAG porta costi: indicizzazione, chunking, embedding, ranking, aggiornamento, sicurezza e valutazione.

La scelta corretta dipende dal problema.

Quando serve

RAG è sensato quando:

• hai molta documentazione;
• il materiale cambia;
• più utenti fanno domande simili;
• il modello non può ricevere tutto il contesto;
• vuoi citare fonti interne;
• devi ridurre copia-incolla manuale.

Esempio: documentazione tecnica interna, knowledge base prodotto, ADR, changelog, runbook.

Quando non serve

RAG è eccessivo quando:

• la repo è piccola;
• i file rilevanti sono pochi;
• il contesto entra facilmente nel prompt;
• il materiale cambia a ogni commit;
• non hai modo di valutare la qualità del retrieval.

In questi casi bastano file di regole, README, ricerca con rg e letture mirate.

Le scelte che contano

Chunking

Spezzare male i documenti rovina il retrieval. Un chunk deve contenere informazione completa: titolo, contesto, contenuto, eventuale fonte.

Ranking

Recuperare il testo semanticamente simile non basta. Devi recuperare il testo utile al task.

Verifica

Misura se i chunk giusti vengono trovati. Senza eval, non sai se il RAG sta aiutando o distraendo.

Laboratorio guidato

Prendi 20 documenti Markdown o pagine README. Definisci 10 domande realistiche.

Per ogni domanda annota:

• quali documenti dovrebbero essere recuperati;
• quali chunk sono davvero utili;
• quali chunk sono rumorosi;
• cosa manca.

Poi confronta tre approcci:

1. contesto manuale;
2. ricerca testuale;
3. RAG minimo.

Output atteso

Una decisione documentata:

Per questo progetto usiamo:
- contesto manuale per task piccoli;
- AGENTS.md per regole stabili;
- RAG solo per documentazione interna sopra una certa dimensione;
- eval di retrieval prima di usarlo in produzione.

Checklist di verifica

• so spiegare quale problema risolve il RAG;
• ho esempi di query reali;
• so misurare se il retrieval trova chunk utili;
• ho considerato sicurezza e aggiornamento dell’indice;
• non uso RAG per evitare di progettare il contesto.

Errori comuni

RAG come moda. Se non misuri il retrieval, stai solo spostando il problema.

Chunk troppo piccoli. Perdono contesto e generano risposte frammentarie.

Recuperare dati non fidati come istruzioni. Il contenuto recuperato deve restare dato, non comando.

Collegamenti

• Modulo: Contesto e memoria nel progetto — lezione 22 del corso.
• Lezione precedente: File di regole.
• Prossima lezione: Codebase indexing e agenti che leggono i file.