Context Engineering per LLM

Context Engineering per LLM

Indice dei Contenuti – Context Engineering per LLM

1. Introduzione: dal Prompt Engineering al Context Engineering
2. Cos’è il Context Engineering: definizione e architettura
3. Le quattro strategie fondamentali
4. Esempio pratico 1: RAG con LangChain e ChromaDB
5. Esempio pratico 2: Gestione della memoria multi-turn
6. Tool Loadout dinamico: ottimizzare l’accesso agli strumenti
7. Il problema del Context Rot
8. Best Practice: pro e contro del Context Engineering
9. Strumenti e framework nel 2026
10. Conclusioni e formazione continua

1. Introduzione: dal Prompt Engineering al Context Engineering

Fino a qualche anno fa, il lavoro dello sviluppatore che integrava un LLM nella propria applicazione si concentrava quasi esclusivamente sul prompt engineering: trovare le parole giuste, il tono corretto, la struttura ideale per ottenere dal modello la risposta desiderata. Era un’attività artigianale, efficace per casi semplici ma strutturalmente limitata.

Nel 2025-2026 il panorama è cambiato radicalmente. I sistemi AI in produzione non si limitano a rispondere a domande singole: orchestrano flussi di lavoro complessi, gestiscono conversazioni multi-turn, recuperano documenti da knowledge base aziendali, chiamano API esterne e prendono decisioni autonome. In questo scenario, il prompt è solo uno dei tanti ingredienti. Ciò che conta davvero è l’intera architettura informativa che circonda il modello.

Andrej Karpathy, ex direttore dell’AI di Tesla e ricercatore OpenAI, ha sintetizzato il concetto con una metafora efficace: “L’LLM è la CPU, e la context window è la RAM.” Questa è l’essenza del Context Engineering: progettare, selezionare e strutturare ciò che entra nella context window per massimizzare la qualità dell’output del modello.

2. Cos’è il Context Engineering: definizione e architettura

Il Context Engineering è la disciplina che si occupa di progettare e gestire l’insieme di informazioni fornite a un LLM durante l’inferenza, al fine di massimizzare la qualità, l’accuratezza e la rilevanza dell’output. Va ben oltre la formulazione di un singolo prompt: riguarda la gestione dell’intera pipeline informativa che alimenta il modello.

Mentre il Prompt Engineering risponde alla domanda “Come devo formulare la mia richiesta?”, il Context Engineering risponde a una domanda molto più ampia: “Cosa deve sapere il modello, in che ordine, in che formato e con quale livello di dettaglio, prima di generare la risposta?”

Il contesto che un LLM riceve in una chiamata tipica è composto da:

• System prompt: istruzioni di comportamento e personalità
• Cronologia della conversazione: i turni precedenti del dialogo
• Documenti recuperati (RAG): testi estratti da knowledge base esterne
• Definizioni degli strumenti (tool schemas): i tool a disposizione dell’agente
• Output intermedi: risultati di chiamate precedenti a tool o sub-agenti
• Preferenze utente: contesto personale o aziendale rilevante

A differenza dei sistemi statici, gli LLM sono stateless: non hanno memoria tra una chiamata e l’altra. Ogni richiesta ricomincia da zero, e tutto ciò che il modello deve “sapere” deve essere esplicitamente incluso nel contesto. Questo rende il Context Engineering una competenza di ingegneria a tutti gli effetti, non solo un’abilità redazionale.

3. Le quattro strategie fondamentali

Dalla ricerca e dalla pratica di produzione del 2025-2026 sono emerse quattro macro-strategie consolidate:

3.1 Write (Scratchpad e memoria persistente)

Analogamente a un essere umano che prende appunti mentre lavora su un problema complesso, gli agenti AI possono utilizzare uno scratchpad per preservare informazioni intermedie. La memoria viene esternalizzata in un database (Redis, PostgreSQL, Pinecone) e recuperata quando necessaria, invece di essere tenuta “in testa” al modello.

3.2 Select (Selezione e ranking)

Non si inietta tutto nel contesto: si seleziona solo ciò che è rilevante per la query specifica. Questo avviene tramite ricerca semantica (embedding + cosine similarity), re-ranking e filtraggio per metadati. La selezione intelligente è il cuore del pattern RAG.

3.3 Compress (Compressione e sintesi)

Quando il contesto disponibile supera il token budget, è necessario comprimere. Tecniche come la summarizzazione estrattiva, il pruning con LLMLingua e la deduplicazione semantica permettono di ridurre il volume preservando le informazioni chiave. Come regola empirica: un contesto focalizzato di 300 token spesso supera in qualità un contesto generico di 113.000 token.

3.4 Isolate (Architetture multi-agente)

Invece di caricare tutto il contesto in un unico modello, si distribuisce il lavoro su più agenti specializzati, ognuno con il proprio contesto ottimizzato. Questo pattern è alla base di framework come LangGraph, AutoGen e CrewAI.

4. Esempio pratico 1: RAG con LangChain e ChromaDB

Il pattern RAG (Retrieval-Augmented Generation) è oggi lo standard de facto per le applicazioni LLM in produzione. Ecco un esempio concreto in Python che mostra come costruire una pipeline di context engineering con LangChain e ChromaDB:

# Installazione: pip install langchain langchain-openai chromadb

from langchain_openai import OpenAIEmbeddings, ChatOpenAI

from langchain_community.vectorstores import Chroma

from langchain.text_splitter import RecursiveCharacterTextSplitter

from langchain.schema import Document

from langchain_core.prompts import ChatPromptTemplate

# 1. Prepara i documenti (knowledge base aziendale)

docs = [

    Document(page_content='La politica ferie prevede 26 giorni lavorativi annui.',

             metadata={'fonte': 'HR_policy_2026'}),

    Document(page_content='Il rimborso spese richiede scontrino entro 30 giorni.',

             metadata={'fonte': 'expense_policy'}),

]

# 2. Splitting intelligente (chunk ottimizzati per il retrieval)

splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)

chunks = splitter.split_documents(docs)

# 3. Indicizzazione vettoriale

embeddings = OpenAIEmbeddings(model='text-embedding-3-small')

vectorstore = Chroma.from_documents(chunks, embeddings)

retriever = vectorstore.as_retriever(search_kwargs={'k': 3})

# 4. Pipeline RAG con context engineering esplicito

SYSTEM_PROMPT = '''Sei un assistente HR aziendale.

Usa SOLO le informazioni nel contesto fornito.

Se la risposta non e' nel contesto, dillo chiaramente.

Contesto: {context}'''

prompt = ChatPromptTemplate.from_messages([

    ('system', SYSTEM_PROMPT),

    ('human', '{question}')

])

llm = ChatOpenAI(model='gpt-4o', temperature=0)

def rag_query(question: str) -> str:

    # Recupera i chunk rilevanti (context selection)

    relevant_docs = retriever.invoke(question)

    context = '\n\n'.join(d.page_content for d in relevant_docs)

    # Assembla il contesto e chiama il modello

    chain = prompt | llm

    response = chain.invoke({'question': question, 'context': context})

    return response.content

print(rag_query('Quanti giorni di ferie ho diritto?'))

Nota chiave: il parametro k=3 del retriever è una decisione di context engineering: stiamo scegliendo di iniettare solo i 3 chunk più rilevanti, evitando il rumore che degraderebbe la qualità della risposta.

5. Esempio pratico 2: Gestione della memoria multi-turn

Un secondo pattern fondamentale è la gestione della conversazione nel tempo. Dato che gli LLM sono stateless, la cronologia deve essere gestita lato applicazione:

from anthropic import Anthropic

from typing import List, Dict

client = Anthropic()

class ContextManagedChat:

    def __init__(self, max_tokens_history: int = 4000):

        self.history: List[Dict] = []

        self.max_tokens = max_tokens_history

        self.system = 'Sei un assistente tecnico per sviluppatori Python.'

    def _trim_history(self):

        # Context Engineering: pruning della cronologia

        # Mantieni solo gli ultimi N messaggi se il budget e' superato

        while len(str(self.history)) > self.max_tokens * 4 and len(self.history) > 2:

            self.history.pop(0)  # rimuovi il messaggio piu' vecchio

    def chat(self, user_message: str) -> str:

        self.history.append({'role': 'user', 'content': user_message})

        self._trim_history()

        response = client.messages.create(

            model='claude-sonnet-4-6',

            max_tokens=1024,

            system=self.system,

            messages=self.history

        )

        assistant_msg = response.content[0].text

        self.history.append({'role': 'assistant', 'content': assistant_msg})

        return assistant_msg

chat = ContextManagedChat(max_tokens_history=4000)

print(chat.chat('Come faccio un list comprehension in Python?'))

print(chat.chat('Puoi mostrarmi un esempio con dizionari?'))

Il metodo _trim_history() incarna il principio di context compression: invece di far crescere la cronologia indefinitamente fino a saturare la context window, manteniamo solo ciò che è necessario per il ragionamento corrente.

6. Tool Loadout dinamico: ottimizzare l’accesso agli strumenti

Gli agenti LLM possono avere accesso a decine di strumenti. Tuttavia, esporre troppi tool contemporaneamente degrada le prestazioni: ricerche interne mostrano che superati circa 30 tool, il modello fatica a scegliere quello corretto. La soluzione è il Tool Loadout dinamico:

import numpy as np

from openai import OpenAI

# Libreria di tutti i tool disponibili (50+ in produzione)

ALL_TOOLS = [

    {'name': 'schedule_meeting', 'description': 'Pianifica una riunione nel calendario'},

    {'name': 'send_email', 'description': 'Invia una email a un destinatario'},

    {'name': 'query_database', 'description': 'Esegue una query SQL sul database aziendale'},

    {'name': 'create_ticket', 'description': 'Crea un ticket nel sistema di supporto'},

    # ... altri 46 tool

]

def get_relevant_tools(user_query: str, top_k: int = 5) -> list:

    '''

    Context Engineering: seleziona dinamicamente solo i tool rilevanti

    per la query dell utente, invece di esporre l intero catalogo.

    '''

    client = OpenAI()

    # Embedding della query

    query_emb = client.embeddings.create(

        input=user_query, model='text-embedding-3-small'

    ).data[0].embedding

    # Scoring semantico dei tool (semplificato)

    scored = []

    for tool in ALL_TOOLS:

        tool_emb = client.embeddings.create(

            input=tool['description'], model='text-embedding-3-small'

        ).data[0].embedding

        score = np.dot(query_emb, tool_emb)

        scored.append((score, tool))

    scored.sort(key=lambda x: x[0], reverse=True)

    return [t for _, t in scored[:top_k]]

query = 'Pianifica una call con il team di design per domani'

relevant = get_relevant_tools(query, top_k=3)

print([t['name'] for t in relevant])  # ['schedule_meeting', 'send_email', ...]

Questo approccio ha dimostrato di migliorare le performance di function calling di Llama 3.1 8B del 44% in benchmark dedicati, riducendo al contempo i costi per token.

  Vuoi padroneggiare queste tecniche nella pratica?

RAG, agenti LLM, context window management, tool calling: nel Corso Sviluppo Applicazioni LLM di Innovaformazione trovi tutto questo in un percorso pratico e aggiornato al 2026, pensato per sviluppatori con esperienza.

  Scrivi a info@innovaformazione.net oppure chiama il 347 101 2275 per un preventivo personalizzato.  

7. Il problema del Context Rot

Uno dei fenomeni più critici del 2025-2026 è il Context Rot: la degradazione della qualità delle risposte al crescere della lunghezza del contesto. Un’ampia ricerca condotta da Chroma nel 2025 su 18 modelli frontier (tra cui GPT-4.1, Claude e Gemini) ha dimostrato che tutti i modelli testati peggiorano le loro prestazioni all’aumentare dell’input, con alcuni che crollano dal 95% al 60% di accuratezza superata una certa soglia.

Le cause principali del Context Rot sono:

• Lost in the Middle: i modelli tendono a prestare meno attenzione alle informazioni collocate nella parte centrale del contesto
• Attention Budget: ogni token “consuma” risorse di attenzione; informazioni irrilevanti seppelliscono quelle importanti
• Distrazione cognitiva: il modello viene “distratto” da contenuti correlati ma non pertinenti

Le strategie difensive contro il Context Rot includono: posizionare le informazioni critiche all’inizio e alla fine del contesto (primacy e recency bias), applicare aggressivamente context trimming e usare architetture multi-agente per isolare le informazioni per dominio.

8. Best Practice: pro e contro del Context Engineering

Di seguito una sintesi operativa delle best practice consolidate nel 2026, con un’analisi onesta dei vantaggi e dei limiti dello strumento.

8.1 Vantaggi (Pro)

• Riduzione delle allucinazioni: fornire contesto fattualistico preciso e documentato riduce drasticamente le risposte inventate.
• Nessun re-training necessario: si aggiorna la knowledge base senza toccare i pesi del modello, con risparmio di tempo e costi enormi.
• Ottimizzazione dei costi: un context engineering intelligente riduce i token consumati del 50-90% mantenendo la qualità dell’output.
• Scalabilità: le architetture multi-agente con context isolato scalano orizzontalmente su carichi di lavoro complessi.
• Adattabilità real-time: il contesto può includere dati freschi (API, sensori, news) senza attendere un nuovo ciclo di training.
• Trasparenza e tracciabilità: le risposte sono ancorate a fonti recuperate e verificabili, favorendo audit e compliance.

8.2 Svantaggi e Rischi (Contro)

• Complessità architetturale: progettare pipeline di context engineering robuste richiede competenze avanzate in information retrieval, vettorizzazione e gestione della memoria.
• Latenza aumentata: il retrieval semantico aggiunge latenza rispetto a una chiamata LLM diretta; da mitigare con caching e pre-fetching.
• Garbage in, garbage out: se i dati nella knowledge base sono obsoleti o errati, il modello produrrà risposte ugualmente errate, ma con apparente sicurezza.
• Bias da contesto: iniettare selettivamente certe fonti può introdurre bias sistematici nei risultati; è necessario un presidio editoriale della knowledge base.
• Costi infrastrutturali: vettorstore, pipeline di embedding e sistemi di memoria persistente hanno costi operativi da pianificare.
• Rapida evoluzione degli standard: framework e protocolli (come MCP) evolvono velocemente; il team deve aggiornarsi continuamente.

8.3 Regole d’oro per il 2026

• Tratta il context budget come una risorsa finita e preziosa: ogni token deve guadagnarsi il suo posto
• Posiziona le informazioni critiche all’inizio e alla fine del contesto (primacy/recency bias)
• Usa il caching aggressivo per contesti ricorrenti: i risparmi sui costi sono sostanziali
• Valuta sempre con metriche (precision@k, faithfulness, answer relevancy) e non a occhio
• Preferisci architetture multi-agente per task complessi: separa le preoccupazioni
• Monitora attivamente il context rot in produzione con test di regressione

9. Strumenti e framework nel 2026

L’ecosistema del Context Engineering si è consolidato attorno a un set di strumenti che nel 2026 sono considerati standard di industria:

• LangChain / LangGraph: orchestrazione di flussi agentici con context management esplicito
• LlamaIndex: data ingestion, indexing gerarchico e query engine per knowledge base complesse
• ChromaDB / Pinecone / Weaviate: vettorstore per retrieval semantico ad alta scalabilità
• Model Context Protocol (MCP): standard aperto (ora sotto Linux Foundation / Agentic AI Foundation) per la connessione di agenti a strumenti enterprise; conta oltre 97 milioni di download mensili SDK
• LangSmith: osservabilità e debugging delle pipeline LLM
• Ragas: framework di valutazione per sistemi RAG (faithfulness, context recall, answer relevancy)

Gartner prevede che il 40% delle applicazioni enterprise includerà agenti AI task-specific entro fine 2026 (rispetto a meno del 5% nel 2025): tutti questi agenti richiederanno solide competenze di context engineering.

10. Conclusioni e formazione continua

Il Context Engineering non è una moda passeggera: è la competenza tecnica fondamentale per chiunque costruisca applicazioni LLM in produzione nel 2026. Come abbiamo visto, non basta saper scrivere un buon prompt: occorre progettare pipeline di retrieval, gestire la memoria, ottimizzare il token budget e costruire architetture multi-agente resilienti.

Il mercato dell’AI generativa è in continua e rapida evoluzione: nuovi modelli, nuovi framework e nuovi pattern architetturali emergono ogni trimestre. In questo scenario, l’unico modo per mantenere il proprio team competitivo è la formazione continua. Un team che non si aggiorna rischia di lavorare con pratiche obsolete, perdendo efficienza e qualità rispetto ai competitor che investono nello sviluppo delle competenze.

Se stai costruendo applicazioni AI con LLM, ti consigliamo il Corso Sviluppo Applicazioni LLM di Innovaformazione: un percorso pratico e aggiornato che copre prompt engineering avanzato, context engineering, RAG, agenti AI, deployment in produzione e le best practice del 2026. Il corso è pensato specificamente per sviluppatori software e ingegneri informatici con esperienza, che vogliono padroneggiare l’intera catena del valore delle applicazioni AI generativa. Un’altra alternativa è il Corso Agenti AI ed MCP.

Finanziamento tramite Fondimpresa

Le aziende con dipendenti possono accedere a Fondimpresa per finanziare la formazione professionale dei propri team, azzerando o riducendo significativamente il costo del corso. InnovaFormazione supporta le aziende in tutto il processo di accesso ai fondi interprofessionali. Contattaci per verificare la tua eligibilità.

Contatti e informazioni

Per richiedere informazioni sul corso, un preventivo personalizzato o per verificare le possibilità di accesso ai fondi interprofessionali, contatta direttamente:

Dario Carrassi | InnovaFormazione

Email: info@innovaformazione.net

Telefono: 347 101 2275

Sito: innovaformazione.net

Non aspettare che il tuo team resti indietro. Il prossimo aggiornamento del mercato AI potrebbe essere quello che fa la differenza. Richiedici subito un preventivo!

(fonte) (fonte) (fonte)