Quando si parla di AI applicata al software, il discorso finisce quasi sempre su Python. È normale: training, data science e ricerca gravitano da anni attorno a quell’ecosistema, d'altra parte l'ecosistema AI è nato principalmente in Python, inoltre chi sviluppa modelli AI normalmente non è uno sviluppatore backend enterprise, ma proviene da matematica / fisica / data science / machine learning.
Python è molto più semplice da imparare rispetto a C# o Java ed è diventato lo standard di fatto.
Quando esce una nuova tecnica o un nuovo modello, la prima implementazione è quasi sempre in Python.
Ma integrare funzionalità AI in un’applicazione aziendale è un problema diverso. Quindi forse la domanda da porsi è: Per sviluppare applicazioni AI serve davvero Python? In questo articolo analizziamo gli strumenti disponibili in .NET
Se il tuo stack è già basato su ASP.NET Core, C# e servizi backend ben strutturati, oggi puoi sviluppare applicazioni AI mantenendo lo stesso approccio architetturale. Dependency injection, logging, configurazione, middleware e servizi applicativi restano gli stessi. Cambiano i componenti che colleghi al sistema.
In questo scenario Microsoft.Extensions.AI è particolarmente interessante, perché introduce astrazioni comuni per interagire con modelli e provider diversi senza diffondere nel codice applicativo dettagli proprietari.
Per fare AI non è necessario cambiare stack
Questo non significa che .NET sostituisca ogni altro strumento. Significa però che per molti casi d’uso tipici delle software house — assistenti aziendali, ricerca semantica, classificazione, generazione guidata, RAG, tool calling — l’ecosistema Microsoft è ormai sufficientemente maturo.
- puoi mantenere il dominio applicativo in C#;
- puoi isolare il provider dietro interfacce e servizi;
- puoi usare la dependency injection nativa di ASP.NET Core;
- puoi integrare logging, retry, metriche e caching;
- puoi collegare il modello a funzioni .NET senza fargli toccare direttamente il database.
Il punto chiave
Per integrare l’AI in un’applicazione enterprise, il problema non è soltanto chiamare un modello. Il problema è farlo in modo coerente con sicurezza, architettura, autorizzazioni e manutenibilità del sistema.
Che cos’è Microsoft.Extensions.AI
Microsoft.Extensions.AI è una raccolta di astrazioni condivise per componenti di AI generativa. L’obiettivo è permettere a un’applicazione .NET di lavorare con provider differenti attraverso contratti comuni.
In pratica significa poter modellare il codice applicativo intorno a interfacce come IChatClient e IEmbeddingGenerator, invece di dipendere direttamente da uno specifico SDK.
public sealed class DocumentAssistant
{
private readonly IChatClient _chatClient;
public DocumentAssistant(IChatClient chatClient)
{
_chatClient = chatClient;
}
public async Task<string> SummarizeAsync(
string content,
CancellationToken cancellationToken)
{
var response = await _chatClient.GetResponseAsync(
$"Riassumi il seguente testo:\n\n{content}",
cancellationToken: cancellationToken);
return response.Text;
}
}Questa impostazione aiuta soprattutto a mantenere pulito il confine tra dominio applicativo e tecnologia di inferenza.
Tool calling: esporre funzioni .NET come strumenti
Uno degli scenari più utili è il tool calling: il modello può selezionare uno strumento, proporre parametri e ricevere il risultato restituito da una funzione .NET.
Il vantaggio non è l’automazione in sé, ma il controllo. Le funzioni disponibili restano esplicite, i parametri possono essere validati e l’applicazione continua a gestire permessi, regole e audit.
- il modello interpreta la richiesta;
- l’applicazione espone un set limitato di strumenti;
- il backend valida i parametri;
- la funzione .NET esegue l’operazione autorizzata;
- il risultato rientra nel flusso conversazionale.
È una differenza importante rispetto all’idea, molto più rischiosa, di permettere a un modello di interagire liberamente con il database o con API non controllate.
Embeddings, vector store e ricerca semantica
Quando l’obiettivo è recuperare contenuti simili per significato, entrano in gioco gli embeddings. L’astrazione IEmbeddingGenerator aiuta a generare rappresentazioni vettoriali riutilizzabili in più componenti dell’applicazione.
Da qui il passo successivo è il vector store. Con Microsoft.Extensions.VectorData Microsoft propone un livello di astrazione per leggere, scrivere e interrogare dati vettoriali senza vincolare tutto il progetto a un singolo database o servizio.
Il risultato pratico è una base più pulita per costruire funzionalità come:
- ricerca semantica su documenti;
- recupero di contenuti per sistemi RAG;
- raccomandazioni basate sul significato;
- collegamento tra query in linguaggio naturale e knowledge base aziendale.
Data ingestion: preparare i contenuti per il RAG
Recuperare documenti pertinenti è utile soltanto se i contenuti sono stati preparati correttamente. La qualità di un sistema RAG dipende molto dalla pipeline di ingestion: estrazione, pulizia, suddivisione in chunk, metadati e indicizzazione.
In quest’area Microsoft mette a disposizione componenti e concetti descritti nella documentazione sulla data ingestion per .NET. È un tema meno spettacolare del prompt engineering, ma spesso molto più determinante per il risultato finale.
Errore comune
Attribuire al modello problemi che in realtà derivano da documenti disordinati, chunk troppo grandi, metadati assenti o fonti non aggiornate.
Valutazione: la parte che spesso manca
Un altro elemento interessante è l’area evaluation. Con le librerie descritte nella documentazione di Microsoft.Extensions.AI.Evaluation è possibile impostare verifiche più ripetibili sulla qualità delle risposte.
Questo è importante perché una demo convincente non basta. In produzione conviene misurare:
- aderenza della risposta alle fonti;
- completezza;
- rilevanza del retrieval;
- correttezza del formato;
- tasso di rifiuto corretto quando i dati non sono sufficienti;
- latenza e costo.
Quando si aggiornano modello, prompt o pipeline di recupero, una base di test ripetibile aiuta a capire se il sistema stia davvero migliorando.
Quando usare Semantic Kernel
Nel panorama Microsoft c’è poi Semantic Kernel, che si colloca a un livello più alto rispetto alle astrazioni fondamentali di Microsoft.Extensions.AI.
Se Microsoft.Extensions.AI aiuta a costruire fondamenta pulite e provider-independent, Semantic Kernel aggiunge plugin, orchestrazione, memoria e pattern più adatti a scenari agentici o più evoluti.
Non serve sempre partire da lì. In molti casi un servizio applicativo ben progettato, con IChatClient, embeddings e un retrieval controllato, è più che sufficiente. Semantic Kernel diventa interessante quando le esigenze di orchestrazione iniziano a crescere.
Un esempio concreto: l’assistente AI che ho sviluppato per SmartestTour
Un esempio concreto di utilizzo dell’AI in un’applicazione ASP.NET Core è SmartestTour, una piattaforma multitenant che ho progettato e sviluppato per aiutare piccoli Tour Operator e guide locali a pubblicare il proprio catalogo e raccogliere richieste di preventivo.
All’interno della piattaforma ho integrato un assistente AI che utilizza come contesto le informazioni realmente presenti nel catalogo del singolo operatore: descrizioni, itinerari, destinazioni, caratteristiche e dettagli disponibili.
Dal punto di vista architetturale, ASP.NET Core continua a gestire tenant, catalogo, utenti e regole applicative. Il componente AI si occupa invece di interpretare la domanda, recuperare il contesto disponibile e generare una risposta entro limiti definiti dall’applicazione.
Perché questo esempio è rilevante
Per realizzare il chatbot non ho dovuto introdurre uno stack applicativo separato. Ho integrato le funzionalità AI direttamente nell’architettura .NET esistente, mantenendo il controllo sui dati forniti al modello, sui limiti delle risposte e sul comportamento dell’assistente.
Puoi approfondire il progetto nella scheda portfolio di SmartestTour oppure visitare direttamente la piattaforma.
Che cosa questi strumenti non risolvono automaticamente
L’ecosistema è maturo, ma non è magico. Le librerie non sostituiscono alcune decisioni progettuali che restano fondamentali:
- quali dati possono essere inviati al modello;
- come applicare le autorizzazioni;
- come evitare prompt injection e input ostili;
- come validare output e azioni proposte;
- quando fermarsi e dichiarare che le informazioni non sono sufficienti;
- quali metriche utilizzare per valutare la qualità.
In altre parole: gli strumenti facilitano l’integrazione, ma architettura e governo del sistema restano responsabilità dell’applicazione.
In quali casi ha senso usare questi strumenti
| Esigenza | Strumento | Valore pratico |
|---|---|---|
| Chiamare un modello chat | Microsoft.Extensions.AI | Astrazione comune e codice più pulito |
| Generare embedding | IEmbeddingGenerator | Ricerca semantica e RAG |
| Esporre funzioni C# al modello | Tool calling | Integrazione controllata con il backend |
| Astrarre un vector store | Microsoft.Extensions.VectorData | Minore accoppiamento con il provider |
| Preparare documenti per il retrieval | Data ingestion | Pipeline RAG più solida |
| Valutare le risposte | AI Evaluation | Test ripetibili e miglioramento continuo |
| Gestire plugin e scenari agentici | Semantic Kernel | Orchestrazione di livello più alto |
FAQ
Per usare l’AI in .NET devo abbandonare C#?
No. Per molti scenari applicativi puoi integrare modelli generativi, embeddings e retrieval direttamente in C#, mantenendo lo stack .NET esistente.
Microsoft.Extensions.AI sostituisce Semantic Kernel?
No. I due strumenti si collocano su livelli diversi. Microsoft.Extensions.AI fornisce astrazioni fondamentali, mentre Semantic Kernel aggiunge plugin e pattern più evoluti.
Con questi strumenti posso costruire un sistema RAG?
Sì, ma la qualità dipende anche da ingestion, metadati, retrieval, autorizzazioni e valutazione. Le librerie aiutano, ma non sostituiscono il lavoro progettuale.
Microsoft.Extensions.AI evita il lock-in?
Riduce l’accoppiamento con il provider, ma non elimina tutte le differenze tra modelli e servizi. L’obiettivo è rendere il codice applicativo più stabile e manutenibile.
Perché citare SmartestTour in questo contesto?
Perché è un esempio reale di integrazione AI realizzata in ASP.NET Core, utile a mostrare che questi concetti possono essere applicati in un prodotto sviluppato e gestito in prima persona.
In sintesi
Con .NET puoi costruire applicazioni AI senza rinunciare alla tua architettura.
Microsoft.Extensions.AI e le librerie collegate non sostituiscono il lavoro progettuale, ma rendono molto più concreto integrare chat, embeddings, tool calling, vector store e valutazione dentro un’applicazione .NET moderna.
Guide correlate
Vuoi integrare funzionalità AI in un progetto .NET esistente?
Posso supportare software house e team di sviluppo nella progettazione dell’architettura, nella scelta degli strumenti Microsoft più adatti e nell’integrazione controllata di modelli AI, RAG, API e workflow all’interno di applicazioni .NET.