Architettura di riferimento alla chat di Azure AI Foundry di base

Servizio OpenAI di Azure

Azure Machine Learning

Servizio app di Azure

Azure Key Vault

Monitoraggio di Azure

Questo articolo offre un'architettura di base che consente di apprendere come eseguire applicazioni di chat usando i modelli di linguaggio Azure AI Foundry e Azure OpenAI. L'architettura include un'interfaccia utente client eseguita nel servizio app di Azure. Per recuperare i dati di base per il modello linguistico, l'interfaccia utente usa un agente di Intelligenza artificiale di Azure per orchestrare il flusso di lavoro dalle richieste in ingresso agli archivi dati. L'architettura è progettata per funzionare da una singola area.

Importante

Questa architettura non è destinata alle applicazioni di produzione. Si tratta di un'architettura introduttiva per scopi di apprendimento e modello di verifica.it's an introductory architecture for learning and proof-of-concept (POC). Quando si progettano le applicazioni di chat aziendali di produzione, usare l'architettura di riferimento alla chat di Baseline AI Foundry, che aggiunge decisioni di progettazione di produzione a questa architettura di base.

Importante

Un'implementazione di esempio supporta queste linee guida. Include i passaggi di distribuzione per un'implementazione di chat end-to-end di base. È possibile usare questa implementazione come base per il modello di verifica per usare le applicazioni di chat che usano gli agenti di Azure AI Foundry.

Architettura

Una sottosezione separata denominata monitoraggio contiene Application Insights e Monitoraggio di Azure. Questa sottosezione è contrassegnata come numero 6.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

Il flusso di lavoro seguente corrisponde al diagramma precedente:

1. Un utente dell'applicazione interagisce con un'applicazione Web che contiene funzionalità di chat. Emettono una richiesta HTTPS al dominio predefinito del servizio app in azurewebsites.net. Questo dominio punta automaticamente all'indirizzo IP pubblico predefinito del servizio app. La connessione Transport Layer Security viene stabilita dal client direttamente al servizio app. Azure gestisce completamente il certificato.

2. La funzionalità del servizio app denominata Easy Auth garantisce che l'utente che accede al sito Web venga autenticato tramite Microsoft Entra ID.

3. Il codice dell'applicazione distribuito nel servizio app gestisce la richiesta ed esegue il rendering di un'interfaccia utente di chat per l'utente dell'applicazione. Il codice dell'interfaccia utente della chat si connette alle API ospitate anche nella stessa istanza del servizio app. Il codice API si connette a un agente di intelligenza artificiale di Azure in Azure AI Foundry usando Azure AI Persistent Agents SDK.

4. Il servizio agente di Azure AI Foundry si connette a Ricerca di intelligenza artificiale di Azure per recuperare i dati di base per la query. I dati di base vengono aggiunti al prompt inviato al modello OpenAI di Azure nel passaggio successivo.

5. Il servizio Foundry Agent si connette a un modello OpenAI di Azure distribuito in Azure AI Foundry e invia il prompt che include i dati di base e il contesto di chat pertinenti.

6. Application Insights registra informazioni sulla richiesta originale al servizio app e sulle interazioni dell'agente di chiamata.

Componenti

Molti componenti di questa architettura sono gli stessi dell'architettura di base dell'applicazione Web del servizio app perché l'interfaccia utente della chat si basa su tale architettura. In questa sezione vengono evidenziati i servizi dati, i componenti che è possibile usare per creare e orchestrare i flussi di chat e i servizi che espongono modelli linguistici.

• Azure AI Foundry è una piattaforma usata per compilare, testare e distribuire soluzioni e modelli di intelligenza artificiale come servizio (MaaS). Questa architettura usa Azure AI Foundry per distribuire un modello OpenAI di Azure.

  • I progetti di Azure AI Foundry stabiliscono connessioni alle origini dati, definiscono gli agenti e richiamano i modelli distribuiti, inclusi i modelli OpenAI di Azure. Questa architettura include un solo progetto Azure AI Foundry all'interno dell'account Azure AI Foundry.

  • Foundry Agent Service è una funzionalità ospitata in Azure AI Foundry. Gli sviluppatori usano questo servizio per definire e ospitare agenti per gestire le richieste di chat. Gestisce i thread di chat, orchestra le chiamate degli strumenti, applica la sicurezza dei contenuti e si integra con i sistemi di identità, rete e osservabilità. In questa architettura il servizio Foundry Agent orchestra il flusso che recupera i dati di base da un'istanza di Ricerca di intelligenza artificiale e lo passa insieme alla richiesta al modello Azure OpenAI distribuito.

    Gli agenti definiti nel servizio agente Foundry sono senza codice ed effettivamente non deterministici. Il prompt di sistema, combinato con temperature i parametri e top_p , definisce il comportamento degli agenti per le richieste.

  • I modelli di Azure AI Foundry consentono di distribuire modelli di punta, inclusi i modelli OpenAI, dal catalogo di Intelligenza artificiale di Azure in un ambiente ospitato da Microsoft. Questo approccio è considerato una distribuzione MaaS. Questa architettura distribuisce i modelli usando la configurazione Standard globale con una quota fissa.

• ricerca di intelligenza artificiale è un servizio di ricerca cloud che supporta ricerca full-text, ricerca semantica, ricerca vettorialee ricerca ibrida. Questa architettura include la ricerca di intelligenza artificiale perché viene comunemente usata nelle orchestrazioni dietro le applicazioni di chat. È possibile usare Ricerca di intelligenza artificiale per recuperare i dati indicizzati rilevanti per le query utente dell'applicazione. Ricerca di intelligenza artificiale funge da archivio conoscenze per il modello Di generazione aumentata di recupero . Questo modello estrae una query appropriata da un prompt, esegue query sulla ricerca di intelligenza artificiale e usa i risultati come dati di base per un modello OpenAI di Azure.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Questa architettura di base non è destinata alle distribuzioni di produzione. L'architettura favorisce la semplicità e l'efficienza dei costi rispetto alle funzionalità, in modo da poter imparare a creare applicazioni di chat end-to-end usando Azure AI Foundry e Azure OpenAI. Le sezioni seguenti descrivono le carenze di questa architettura di base e descrivono raccomandazioni e considerazioni.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

L'elenco seguente illustra le funzionalità di affidabilità critiche che questa architettura omette:

• Questa architettura usa il livello Basic del servizio app, che non supporta la zona di disponibilità di Azure . L'istanza del servizio app non è più disponibile se si verificano problemi con l'istanza, il rack o il data center che ospita l'istanza. Quando si passa all'ambiente di produzione, seguire le indicazioni sull'affidabilità per le istanze del servizio app.

• Questa architettura non abilita la scalabilità automatica per l'interfaccia utente client. Per evitare problemi di affidabilità a causa di risorse di calcolo inefficienti, effettuare l'overprovisioning delle risorse per l'esecuzione sempre con risorse di calcolo sufficienti per gestire la capacità massima simultanea.

• Questa architettura distribuisce il servizio Foundry Agent come soluzione completamente ospitata da Microsoft. In questa configurazione Microsoft ospita un database Azure Cosmos DB, un contenitore dell'account di archiviazione di Azure e un indice di ricerca di intelligenza artificiale per conto dell'utente. La sottoscrizione non mostra queste risorse dipendenti. Non si ha alcun controllo sull'affidabilità del servizio Foundry Agent o sulle relative dipendenze. È possibile acquisire il controllo di queste dipendenze per eseguire azioni come implementare una strategia di continuità aziendale e ripristino di emergenza. Per indicazioni sull'inserimento di dipendenze personalizzate, vedere l'architettura di base.

  Annotazioni

  L'istanza di Ricerca di intelligenza artificiale nella sezione dei componenti e nel diagramma è diversa dall'istanza che è una dipendenza del servizio Foundry Agent. L'istanza nella sezione Componenti archivia i dati di base. La dipendenza esegue la suddivisione in blocchi in tempo reale dei file caricati all'interno di una sessione di chat.

• Per un'architettura di base destinata all'apprendimento, è possibile usare il tipo di distribuzione del Global Standard modello. Quando si passa all'ambiente di produzione, è consigliabile avere un'idea migliore dei requisiti di velocità effettiva e residenza dei dati. Dopo aver compreso i requisiti di velocità effettiva, è consigliabile usare la velocità effettiva con provisioning scegliendo un Data Zone Provisioned tipo di distribuzione o Global Provisioned . Se si hanno requisiti di residenza dei dati, scegliere il Data Zone Provisioned tipo di distribuzione.

• Questa architettura usa il livello Basic di Ricerca di intelligenza artificiale, che non supporta le zone di disponibilità di Azure. Per ottenere la ridondanza della zona, distribuire il piano tariffario standard di ricerca di intelligenza artificiale o versione successiva in un'area che supporta le zone di disponibilità e distribuire tre o più repliche.

Per altre informazioni, vedere Architettura di riferimento della chat foundry per intelligenza artificiale di base.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

In questa sezione vengono descritte le raccomandazioni chiave implementate da questa architettura. Queste raccomandazioni includono il monitoraggio dei contenuti e gli abusi, la gestione delle identità e degli accessi e il controllo degli accessi in base al ruolo. Questa architettura non è progettata per le distribuzioni di produzione, quindi questa sezione include anche la sicurezza di rete. La sicurezza di rete è una funzionalità di sicurezza chiave che questa architettura non implementa.

Monitoraggio di filtri e abusi sui contenuti

Azure AI Foundry include un sistema di filtro del contenuto che usa una combinazione di modelli di classificazione. Questo filtro rileva e blocca categorie specifiche di contenuto potenzialmente dannoso nelle richieste di input e nei completamenti di output. Questo contenuto potenzialmente dannoso include categorie di odio, contenuto sessuale, autolesionismo, violenza, volgarità e jailbreak (contenuto progettato per ignorare le restrizioni del modello linguistico). È possibile configurare la rigidità di filtro per ogni categoria usando opzioni basse, medie o elevate. Questa architettura di riferimento usa il filtro contenuto durante la DefaultV2 distribuzione dei modelli. È possibile modificare le impostazioni in base alle proprie esigenze.

Gestione delle identità e degli accessi

Le indicazioni seguenti illustrano le linee guida per la gestione delle identità e degli accessi nell'architettura di base del servizio app. L'interfaccia utente della chat usa l'identità gestita per autenticare il codice dell'API dell'interfaccia utente della chat nel servizio Foundry Agent usando Azure AI Persistent Agents SDK.

Il progetto Azure AI Foundry ha anche un'identità gestita. Questa identità esegue l'autenticazione ai servizi, ad esempio ricerca di intelligenza artificiale tramite definizioni di connessione. Il progetto rende disponibili tali connessioni al servizio agente Foundry.

Un account Azure AI Foundry può contenere più progetti di Azure AI Foundry. Ogni progetto deve usare la propria identità gestita assegnata dal sistema. Se diversi componenti del carico di lavoro richiedono l'accesso isolato alle origini dati connesse, creare progetti di Azure AI Foundry separati all'interno dello stesso account ed evitare di condividere le connessioni tra di esse. Se il carico di lavoro non richiede l'isolamento, usare un singolo progetto.

Ruoli di accesso in base al ruolo

Si è responsabili della creazione delle assegnazioni di ruolo necessarie per le identità gestite assegnate dal sistema. La tabella seguente riepiloga l'assegnazione di ruolo che è necessario aggiungere al servizio app, al progetto Azure AI Foundry e ai singoli utenti che usano il portale:

Conto risorse	Ruolo	Ambito
Servizio app	Utente di Intelligenza artificiale di Azure	Account Azure AI Foundry
Progetto Azure AI Foundry	Lettore di dati dell'indice di ricerca	Ricerca IA
Utente del portale (per ogni utente)	Sviluppatore di Azure per intelligenza artificiale	Account Azure AI Foundry

Sicurezza della rete

Per semplificare l'esperienza di apprendimento per la creazione di una soluzione di chat end-to-end, questa architettura non implementa la sicurezza di rete. Usa l'identità come perimetro e usa costrutti di cloud pubblico. I servizi come Ricerca di intelligenza artificiale, Azure AI Foundry e Servizio app sono raggiungibili da Internet. Questa configurazione aumenta la superficie di attacco dell'architettura.

Questa architettura non limita anche il traffico in uscita. Ad esempio, un agente può essere configurato per connettersi a qualsiasi endpoint pubblico in base alla specifica OpenAPI dell'endpoint. Pertanto, non è possibile impedire l'esfiltrazione di dati privati tramite i controlli di rete.

Per altre informazioni sulla sicurezza di rete come perimetro aggiuntivo nell'architettura, vedere Rete.

Difensore

Per questa architettura di base, non è necessario abilitare i piani di protezione del carico di lavoro cloud di Microsoft Defender per i servizi. Quando si passa all'ambiente di produzione, seguire le indicazioni sulla sicurezza nell'architettura di base per Microsoft Defender, che usa più piani per coprire il carico di lavoro.

Governance tramite criteri

Questa architettura non implementa la governance tramite Criteri di Azure. Quando si passa all'ambiente di produzione, seguire le raccomandazioni sulla governance nell'architettura di base. Questi consigli aggiungono Criteri di Azure nei componenti del carico di lavoro.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Questa architettura di base non rappresenta i costi per una soluzione pronta per la produzione. Non include anche controlli per evitare sovraccarichi dei costi. Le considerazioni seguenti descrivono le funzionalità cruciali che questa architettura non include. Queste funzionalità influiscono sui costi.

• Questa architettura presuppone che il modello Azure OpenAI distribuito riceva chiamate limitate. È quindi consigliabile usare il Global Standard tipo di distribuzione per i prezzi con pagamento in base al consumo anziché un tipo di distribuzione con velocità effettiva con provisioning. Quando si passa a una soluzione di produzione, seguire le linee guida per l'ottimizzazione dei costi nell'architettura di base.

• Il servizio agente foundry comporta costi per i file caricati durante le interazioni di chat. Non rendere disponibile la funzionalità di caricamento dei file agli utenti dell'applicazione se non fa parte dell'esperienza utente desiderata. Le connessioni di conoscenza aggiuntive, ad esempio il grounding con lo strumento Bing, hanno strutture di determinazione dei prezzi specifiche.

  Foundry Agent Service è una soluzione senza codice, il che significa che non è possibile controllare in modo deterministico gli strumenti o le origini delle informazioni richiamate da ogni richiesta. Nella modellazione dei costi presupporre il massimo utilizzo di ogni connessione.

• Questa architettura usa il piano tariffario Basic del servizio app in una singola istanza, che non fornisce protezione da un'interruzione della zona di disponibilità. L'architettura del servizio app di base consiglia di usare piani Premium con tre o più istanze di lavoro per la disponibilità elevata. Questo approccio influisce sui costi.

• Questa architettura usa il piano tariffario Basic di Ricerca di intelligenza artificiale senza repliche aggiunte. Questa topologia non può resistere a un errore della zona di disponibilità di Azure. L'architettura di chat end-to-end di base consiglia di distribuire il carico di lavoro con il piano tariffario Standard o superiore e di distribuire tre o più repliche. Questo approccio può influire sui costi man mano che si passa alla produzione.

• Questa architettura non include controlli di governance o contenimento dei costi. Assicurarsi di proteggersi da processi o utilizzi non governativi che potrebbero comportare costi elevati per i servizi con pagamento in base al consumo, ad esempio i modelli distribuiti in Azure AI Foundry.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Monitoraggio

Questa architettura configura la diagnostica per tutti i servizi. Tutti i servizi ad eccezione del servizio app e dei log di acquisizione di Azure AI Foundry. Il servizio app acquisisce AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogse AppServicePlatformLogs. Azure AI Foundry acquisisce RequestResponse. Durante la fase di verifica, è necessario comprendere quali log e metriche sono disponibili per la raccolta. Quando si passa all'ambiente di produzione, rimuovere le origini di log che non aggiungono valore e creano solo rumore e costi per il sink di log del carico di lavoro.

Per usare le funzionalità di monitoraggio in Azure AI Foundry, connettere una risorsa di Application Insights al progetto Azure AI Foundry.

Questa integrazione consente il monitoraggio dei dati seguenti:

• Monitoraggio in tempo reale dell'utilizzo dei token, inclusi prompt, completamento e token totali
• Telemetria dettagliata della risposta alle richieste, tra cui latenza, eccezioni e qualità della risposta

È anche possibile tracciare gli agenti usando OpenTelemetry.

Operazioni del modello

Questa architettura è ottimizzata per l'apprendimento e non è destinata all'uso in produzione, quindi le linee guida operative come GenAIOps non rientrano nell'ambito. Quando si passa all'ambiente di produzione, seguire le linee guida per il modello di Azure AI Foundry.

Sviluppo

Per l'architettura di base, è possibile creare agenti usando l'esperienza basata su browser nel portale di Azure AI Foundry. Quando si passa all'ambiente di produzione, seguire le linee guida per lo sviluppo e il controllo del codice sorgente nell'architettura di base. Quando non è più necessario un agente, assicurarsi di eliminarlo. Se l'agente eliminato è l'ultimo che usa una connessione, rimuovere anche la connessione.

Valutazione

È possibile valutare l'applicazione generativa in Azure AI Foundry. È consigliabile imparare a usare gli analizzatori per valutare le applicazioni di intelligenza artificiale generative. Questa procedura consente di garantire che il modello scelto soddisfi i requisiti di progettazione dei clienti e dei carichi di lavoro.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Questa architettura non è progettata per le distribuzioni di produzione, quindi omette le funzionalità critiche per l'efficienza delle prestazioni:

• I risultati del modello di verifica dovrebbero essere utili per scegliere il prodotto del servizio app appropriato per il carico di lavoro. Progettare il carico di lavoro per soddisfare in modo efficiente la domanda tramite il ridimensionamento orizzontale. È possibile usare il ridimensionamento orizzontale per regolare il numero di istanze di calcolo nel piano di servizio app. Non progettare un sistema che richiede di modificare il prodotto di calcolo in modo che sia allineato alla domanda.

• Questa architettura usa il modello a consumo o con pagamento in base al consumo per la maggior parte dei componenti. Il modello di consumo è un modello di lavoro ottimale e potrebbe introdurre problemi di prossimità rumorosi o altri stressatori sulla piattaforma. Determinare se l'applicazione richiede velocità effettiva di cui è stato effettuato il provisioning mentre si passa all'ambiente di produzione. La velocità effettiva con provisioning consente di riservare la capacità di elaborazione per le distribuzioni del modello OpenAI di Azure. La capacità riservata offre prestazioni prevedibili e velocità effettiva per i modelli.

Altri consigli di progettazione

Gli architetti devono progettare carichi di lavoro di intelligenza artificiale e machine learning, ad esempio questo, tenendo presenti i carichi di lavoro di intelligenza artificiale di Well-Architected Framework in Azure. Man mano che si passa dall'ideazione e dal modello di verifica alla progettazione, combinare informazioni dettagliate da questa architettura specifica con le procedure consigliate per l'intelligenza artificiale e l'apprendimento automatico più ampie in Well-Architected Framework.

Distribuire lo scenario

Distribuire un'implementazione di riferimento che applica queste raccomandazioni e considerazioni.

Passo successivo

Architettura di riferimento per la chat Baseline AI Foundry

" output is necessary.)

• Una prospettiva di Well-Architected Framework sui carichi di lavoro di intelligenza artificiale in Azure
• Distribuire modelli di intelligenza artificiale nel portale di Azure AI Foundry
• Esplorare i modelli di Azure AI Foundry
• Che cos'è il servizio agente Foundry?

Questo articolo offre un'architettura di base che consente di apprendere come eseguire applicazioni di chat usando i modelli di linguaggio Azure AI Foundry e Azure OpenAI. L'architettura include un'interfaccia utente client eseguita nel servizio app di Azure. Per recuperare i dati di base per il modello linguistico, l'interfaccia utente usa un agente di Intelligenza artificiale di Azure per orchestrare il flusso di lavoro dalle richieste in ingresso agli archivi dati. L'architettura è progettata per funzionare da una singola area.

Importante

Questa architettura non è destinata alle applicazioni di produzione. Si tratta di un'architettura introduttiva per scopi di apprendimento e modello di verifica.it's an introductory architecture for learning and proof-of-concept (POC). Quando si progettano le applicazioni di chat aziendali di produzione, usare l'architettura di riferimento alla chat di Baseline AI Foundry, che aggiunge decisioni di progettazione di produzione a questa architettura di base.

Importante

Un'implementazione di esempio supporta queste linee guida. Include i passaggi di distribuzione per un'implementazione di chat end-to-end di base. È possibile usare questa implementazione come base per il modello di verifica per usare le applicazioni di chat che usano gli agenti di Azure AI Foundry.

Architettura

Una sottosezione separata denominata monitoraggio contiene Application Insights e Monitoraggio di Azure. Questa sottosezione è contrassegnata come numero 6.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

Il flusso di lavoro seguente corrisponde al diagramma precedente:

1. Un utente dell'applicazione interagisce con un'applicazione Web che contiene funzionalità di chat. Emettono una richiesta HTTPS al dominio predefinito del servizio app in azurewebsites.net. Questo dominio punta automaticamente all'indirizzo IP pubblico predefinito del servizio app. La connessione Transport Layer Security viene stabilita dal client direttamente al servizio app. Azure gestisce completamente il certificato.

2. La funzionalità del servizio app denominata Easy Auth garantisce che l'utente che accede al sito Web venga autenticato tramite Microsoft Entra ID.

3. Il codice dell'applicazione distribuito nel servizio app gestisce la richiesta ed esegue il rendering di un'interfaccia utente di chat per l'utente dell'applicazione. Il codice dell'interfaccia utente della chat si connette alle API ospitate anche nella stessa istanza del servizio app. Il codice API si connette a un agente di intelligenza artificiale di Azure in Azure AI Foundry usando Azure AI Persistent Agents SDK.

4. Il servizio agente di Azure AI Foundry si connette a Ricerca di intelligenza artificiale di Azure per recuperare i dati di base per la query. I dati di base vengono aggiunti al prompt inviato al modello OpenAI di Azure nel passaggio successivo.

5. Il servizio Foundry Agent si connette a un modello OpenAI di Azure distribuito in Azure AI Foundry e invia il prompt che include i dati di base e il contesto di chat pertinenti.

6. Application Insights registra informazioni sulla richiesta originale al servizio app e sulle interazioni dell'agente di chiamata.

Componenti

Molti componenti di questa architettura sono gli stessi dell'architettura di base dell'applicazione Web del servizio app perché l'interfaccia utente della chat si basa su tale architettura. In questa sezione vengono evidenziati i servizi dati, i componenti che è possibile usare per creare e orchestrare i flussi di chat e i servizi che espongono modelli linguistici.

• Azure AI Foundry è una piattaforma usata per compilare, testare e distribuire soluzioni e modelli di intelligenza artificiale come servizio (MaaS). Questa architettura usa Azure AI Foundry per distribuire un modello OpenAI di Azure.

  • I progetti di Azure AI Foundry stabiliscono connessioni alle origini dati, definiscono gli agenti e richiamano i modelli distribuiti, inclusi i modelli OpenAI di Azure. Questa architettura include un solo progetto Azure AI Foundry all'interno dell'account Azure AI Foundry.

  • Foundry Agent Service è una funzionalità ospitata in Azure AI Foundry. Gli sviluppatori usano questo servizio per definire e ospitare agenti per gestire le richieste di chat. Gestisce i thread di chat, orchestra le chiamate degli strumenti, applica la sicurezza dei contenuti e si integra con i sistemi di identità, rete e osservabilità. In questa architettura il servizio Foundry Agent orchestra il flusso che recupera i dati di base da un'istanza di Ricerca di intelligenza artificiale e lo passa insieme alla richiesta al modello Azure OpenAI distribuito.

    Gli agenti definiti nel servizio agente Foundry sono senza codice ed effettivamente non deterministici. Il prompt di sistema, combinato con temperature i parametri e top_p , definisce il comportamento degli agenti per le richieste.

  • I modelli di Azure AI Foundry consentono di distribuire modelli di punta, inclusi i modelli OpenAI, dal catalogo di Intelligenza artificiale di Azure in un ambiente ospitato da Microsoft. Questo approccio è considerato una distribuzione MaaS. Questa architettura distribuisce i modelli usando la configurazione Standard globale con una quota fissa.

• ricerca di intelligenza artificiale è un servizio di ricerca cloud che supporta ricerca full-text, ricerca semantica, ricerca vettorialee ricerca ibrida. Questa architettura include la ricerca di intelligenza artificiale perché viene comunemente usata nelle orchestrazioni dietro le applicazioni di chat. È possibile usare Ricerca di intelligenza artificiale per recuperare i dati indicizzati rilevanti per le query utente dell'applicazione. Ricerca di intelligenza artificiale funge da archivio conoscenze per il modello Di generazione aumentata di recupero . Questo modello estrae una query appropriata da un prompt, esegue query sulla ricerca di intelligenza artificiale e usa i risultati come dati di base per un modello OpenAI di Azure.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Questa architettura di base non è destinata alle distribuzioni di produzione. L'architettura favorisce la semplicità e l'efficienza dei costi rispetto alle funzionalità, in modo da poter imparare a creare applicazioni di chat end-to-end usando Azure AI Foundry e Azure OpenAI. Le sezioni seguenti descrivono le carenze di questa architettura di base e descrivono raccomandazioni e considerazioni.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

L'elenco seguente illustra le funzionalità di affidabilità critiche che questa architettura omette:

• Questa architettura usa il livello Basic del servizio app, che non supporta la zona di disponibilità di Azure . L'istanza del servizio app non è più disponibile se si verificano problemi con l'istanza, il rack o il data center che ospita l'istanza. Quando si passa all'ambiente di produzione, seguire le indicazioni sull'affidabilità per le istanze del servizio app.

• Questa architettura non abilita la scalabilità automatica per l'interfaccia utente client. Per evitare problemi di affidabilità a causa di risorse di calcolo inefficienti, effettuare l'overprovisioning delle risorse per l'esecuzione sempre con risorse di calcolo sufficienti per gestire la capacità massima simultanea.

• Questa architettura distribuisce il servizio Foundry Agent come soluzione completamente ospitata da Microsoft. In questa configurazione Microsoft ospita un database Azure Cosmos DB, un contenitore dell'account di archiviazione di Azure e un indice di ricerca di intelligenza artificiale per conto dell'utente. La sottoscrizione non mostra queste risorse dipendenti. Non si ha alcun controllo sull'affidabilità del servizio Foundry Agent o sulle relative dipendenze. È possibile acquisire il controllo di queste dipendenze per eseguire azioni come implementare una strategia di continuità aziendale e ripristino di emergenza. Per indicazioni sull'inserimento di dipendenze personalizzate, vedere l'architettura di base.

  Annotazioni

  L'istanza di Ricerca di intelligenza artificiale nella sezione dei componenti e nel diagramma è diversa dall'istanza che è una dipendenza del servizio Foundry Agent. L'istanza nella sezione Componenti archivia i dati di base. La dipendenza esegue la suddivisione in blocchi in tempo reale dei file caricati all'interno di una sessione di chat.

• Per un'architettura di base destinata all'apprendimento, è possibile usare il tipo di distribuzione del Global Standard modello. Quando si passa all'ambiente di produzione, è consigliabile avere un'idea migliore dei requisiti di velocità effettiva e residenza dei dati. Dopo aver compreso i requisiti di velocità effettiva, è consigliabile usare la velocità effettiva con provisioning scegliendo un Data Zone Provisioned tipo di distribuzione o Global Provisioned . Se si hanno requisiti di residenza dei dati, scegliere il Data Zone Provisioned tipo di distribuzione.

• Questa architettura usa il livello Basic di Ricerca di intelligenza artificiale, che non supporta le zone di disponibilità di Azure. Per ottenere la ridondanza della zona, distribuire il piano tariffario standard di ricerca di intelligenza artificiale o versione successiva in un'area che supporta le zone di disponibilità e distribuire tre o più repliche.

Per altre informazioni, vedere Architettura di riferimento della chat foundry per intelligenza artificiale di base.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

In questa sezione vengono descritte le raccomandazioni chiave implementate da questa architettura. Queste raccomandazioni includono il monitoraggio dei contenuti e gli abusi, la gestione delle identità e degli accessi e il controllo degli accessi in base al ruolo. Questa architettura non è progettata per le distribuzioni di produzione, quindi questa sezione include anche la sicurezza di rete. La sicurezza di rete è una funzionalità di sicurezza chiave che questa architettura non implementa.

Monitoraggio di filtri e abusi sui contenuti

Azure AI Foundry include un sistema di filtro del contenuto che usa una combinazione di modelli di classificazione. Questo filtro rileva e blocca categorie specifiche di contenuto potenzialmente dannoso nelle richieste di input e nei completamenti di output. Questo contenuto potenzialmente dannoso include categorie di odio, contenuto sessuale, autolesionismo, violenza, volgarità e jailbreak (contenuto progettato per ignorare le restrizioni del modello linguistico). È possibile configurare la rigidità di filtro per ogni categoria usando opzioni basse, medie o elevate. Questa architettura di riferimento usa il filtro contenuto durante la DefaultV2 distribuzione dei modelli. È possibile modificare le impostazioni in base alle proprie esigenze.

Gestione delle identità e degli accessi

Le indicazioni seguenti illustrano le linee guida per la gestione delle identità e degli accessi nell'architettura di base del servizio app. L'interfaccia utente della chat usa l'identità gestita per autenticare il codice dell'API dell'interfaccia utente della chat nel servizio Foundry Agent usando Azure AI Persistent Agents SDK.

Il progetto Azure AI Foundry ha anche un'identità gestita. Questa identità esegue l'autenticazione ai servizi, ad esempio ricerca di intelligenza artificiale tramite definizioni di connessione. Il progetto rende disponibili tali connessioni al servizio agente Foundry.

Un account Azure AI Foundry può contenere più progetti di Azure AI Foundry. Ogni progetto deve usare la propria identità gestita assegnata dal sistema. Se diversi componenti del carico di lavoro richiedono l'accesso isolato alle origini dati connesse, creare progetti di Azure AI Foundry separati all'interno dello stesso account ed evitare di condividere le connessioni tra di esse. Se il carico di lavoro non richiede l'isolamento, usare un singolo progetto.

Ruoli di accesso in base al ruolo

Si è responsabili della creazione delle assegnazioni di ruolo necessarie per le identità gestite assegnate dal sistema. La tabella seguente riepiloga l'assegnazione di ruolo che è necessario aggiungere al servizio app, al progetto Azure AI Foundry e ai singoli utenti che usano il portale:

Conto risorse	Ruolo	Ambito
Servizio app	Utente di Intelligenza artificiale di Azure	Account Azure AI Foundry
Progetto Azure AI Foundry	Lettore di dati dell'indice di ricerca	Ricerca IA
Utente del portale (per ogni utente)	Sviluppatore di Azure per intelligenza artificiale	Account Azure AI Foundry

Sicurezza della rete

Per semplificare l'esperienza di apprendimento per la creazione di una soluzione di chat end-to-end, questa architettura non implementa la sicurezza di rete. Usa l'identità come perimetro e usa costrutti di cloud pubblico. I servizi come Ricerca di intelligenza artificiale, Azure AI Foundry e Servizio app sono raggiungibili da Internet. Questa configurazione aumenta la superficie di attacco dell'architettura.

Questa architettura non limita anche il traffico in uscita. Ad esempio, un agente può essere configurato per connettersi a qualsiasi endpoint pubblico in base alla specifica OpenAPI dell'endpoint. Pertanto, non è possibile impedire l'esfiltrazione di dati privati tramite i controlli di rete.

Per altre informazioni sulla sicurezza di rete come perimetro aggiuntivo nell'architettura, vedere Rete.

Difensore

Per questa architettura di base, non è necessario abilitare i piani di protezione del carico di lavoro cloud di Microsoft Defender per i servizi. Quando si passa all'ambiente di produzione, seguire le indicazioni sulla sicurezza nell'architettura di base per Microsoft Defender, che usa più piani per coprire il carico di lavoro.

Governance tramite criteri

Questa architettura non implementa la governance tramite Criteri di Azure. Quando si passa all'ambiente di produzione, seguire le raccomandazioni sulla governance nell'architettura di base. Questi consigli aggiungono Criteri di Azure nei componenti del carico di lavoro.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Questa architettura di base non rappresenta i costi per una soluzione pronta per la produzione. Non include anche controlli per evitare sovraccarichi dei costi. Le considerazioni seguenti descrivono le funzionalità cruciali che questa architettura non include. Queste funzionalità influiscono sui costi.

• Questa architettura presuppone che il modello Azure OpenAI distribuito riceva chiamate limitate. È quindi consigliabile usare il Global Standard tipo di distribuzione per i prezzi con pagamento in base al consumo anziché un tipo di distribuzione con velocità effettiva con provisioning. Quando si passa a una soluzione di produzione, seguire le linee guida per l'ottimizzazione dei costi nell'architettura di base.

• Il servizio agente foundry comporta costi per i file caricati durante le interazioni di chat. Non rendere disponibile la funzionalità di caricamento dei file agli utenti dell'applicazione se non fa parte dell'esperienza utente desiderata. Le connessioni di conoscenza aggiuntive, ad esempio il grounding con lo strumento Bing, hanno strutture di determinazione dei prezzi specifiche.

  Foundry Agent Service è una soluzione senza codice, il che significa che non è possibile controllare in modo deterministico gli strumenti o le origini delle informazioni richiamate da ogni richiesta. Nella modellazione dei costi presupporre il massimo utilizzo di ogni connessione.

• Questa architettura usa il piano tariffario Basic del servizio app in una singola istanza, che non fornisce protezione da un'interruzione della zona di disponibilità. L'architettura del servizio app di base consiglia di usare piani Premium con tre o più istanze di lavoro per la disponibilità elevata. Questo approccio influisce sui costi.

• Questa architettura usa il piano tariffario Basic di Ricerca di intelligenza artificiale senza repliche aggiunte. Questa topologia non può resistere a un errore della zona di disponibilità di Azure. L'architettura di chat end-to-end di base consiglia di distribuire il carico di lavoro con il piano tariffario Standard o superiore e di distribuire tre o più repliche. Questo approccio può influire sui costi man mano che si passa alla produzione.

• Questa architettura non include controlli di governance o contenimento dei costi. Assicurarsi di proteggersi da processi o utilizzi non governativi che potrebbero comportare costi elevati per i servizi con pagamento in base al consumo, ad esempio i modelli distribuiti in Azure AI Foundry.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Monitoraggio

Questa architettura configura la diagnostica per tutti i servizi. Tutti i servizi ad eccezione del servizio app e dei log di acquisizione di Azure AI Foundry. Il servizio app acquisisce AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogse AppServicePlatformLogs. Azure AI Foundry acquisisce RequestResponse. Durante la fase di verifica, è necessario comprendere quali log e metriche sono disponibili per la raccolta. Quando si passa all'ambiente di produzione, rimuovere le origini di log che non aggiungono valore e creano solo rumore e costi per il sink di log del carico di lavoro.

Per usare le funzionalità di monitoraggio in Azure AI Foundry, connettere una risorsa di Application Insights al progetto Azure AI Foundry.

Questa integrazione consente il monitoraggio dei dati seguenti:

• Monitoraggio in tempo reale dell'utilizzo dei token, inclusi prompt, completamento e token totali
• Telemetria dettagliata della risposta alle richieste, tra cui latenza, eccezioni e qualità della risposta

È anche possibile tracciare gli agenti usando OpenTelemetry.

Operazioni del modello

Questa architettura è ottimizzata per l'apprendimento e non è destinata all'uso in produzione, quindi le linee guida operative come GenAIOps non rientrano nell'ambito. Quando si passa all'ambiente di produzione, seguire le linee guida per il modello di Azure AI Foundry.

Sviluppo

Per l'architettura di base, è possibile creare agenti usando l'esperienza basata su browser nel portale di Azure AI Foundry. Quando si passa all'ambiente di produzione, seguire le linee guida per lo sviluppo e il controllo del codice sorgente nell'architettura di base. Quando non è più necessario un agente, assicurarsi di eliminarlo. Se l'agente eliminato è l'ultimo che usa una connessione, rimuovere anche la connessione.

Valutazione

È possibile valutare l'applicazione generativa in Azure AI Foundry. È consigliabile imparare a usare gli analizzatori per valutare le applicazioni di intelligenza artificiale generative. Questa procedura consente di garantire che il modello scelto soddisfi i requisiti di progettazione dei clienti e dei carichi di lavoro.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Questa architettura non è progettata per le distribuzioni di produzione, quindi omette le funzionalità critiche per l'efficienza delle prestazioni:

• I risultati del modello di verifica dovrebbero essere utili per scegliere il prodotto del servizio app appropriato per il carico di lavoro. Progettare il carico di lavoro per soddisfare in modo efficiente la domanda tramite il ridimensionamento orizzontale. È possibile usare il ridimensionamento orizzontale per regolare il numero di istanze di calcolo nel piano di servizio app. Non progettare un sistema che richiede di modificare il prodotto di calcolo in modo che sia allineato alla domanda.

• Questa architettura usa il modello a consumo o con pagamento in base al consumo per la maggior parte dei componenti. Il modello di consumo è un modello di lavoro ottimale e potrebbe introdurre problemi di prossimità rumorosi o altri stressatori sulla piattaforma. Determinare se l'applicazione richiede velocità effettiva di cui è stato effettuato il provisioning mentre si passa all'ambiente di produzione. La velocità effettiva con provisioning consente di riservare la capacità di elaborazione per le distribuzioni del modello OpenAI di Azure. La capacità riservata offre prestazioni prevedibili e velocità effettiva per i modelli.

Altri consigli di progettazione

Gli architetti devono progettare carichi di lavoro di intelligenza artificiale e machine learning, ad esempio questo, tenendo presenti i carichi di lavoro di intelligenza artificiale di Well-Architected Framework in Azure. Man mano che si passa dall'ideazione e dal modello di verifica alla progettazione, combinare informazioni dettagliate da questa architettura specifica con le procedure consigliate per l'intelligenza artificiale e l'apprendimento automatico più ampie in Well-Architected Framework.

Distribuire lo scenario

Distribuire un'implementazione di riferimento che applica queste raccomandazioni e considerazioni.

Passo successivo

Architettura di riferimento per la chat Baseline AI Foundry

" output is necessary.)

• Una prospettiva di Well-Architected Framework sui carichi di lavoro di intelligenza artificiale in Azure
• Distribuire modelli di intelligenza artificiale nel portale di Azure AI Foundry
• Esplorare i modelli di Azure AI Foundry
• Che cos'è il servizio agente Foundry?