Panoramica della distribuzione per Agentic Retrieval in Foundry Local

Il recupero agentico porta le funzionalità di IA agentica negli ambienti perimetrali e ibridi. Implementa una piattaforma sicura, scalabile e intelligente per agenti di IA che utilizza i tuoi dati. Implementa l'intera piattaforma Agentic Retrieval oppure implementa separatamente solo l'Agentic Layer o il Knowledge Layer, in base alle tue esigenze. Questo articolo offre una panoramica del processo di distribuzione, dei componenti chiave e del flusso di lavoro per distribuire il recupero agentico con Azure Arc.

Per provare Il recupero agentico senza la necessità di hardware locale, vedere Avvio rapido: Installare il recupero agentico.

Architettura e componenti del recupero agentico

Il diagramma seguente mostra i componenti chiave e l'architettura ottenuti dopo aver preparato l'ambiente e distribuito Agentic Retrieval. Include risorse di Azure, infrastruttura locale e punti di integrazione.

Le risorse e i componenti nel diagramma costituiscono l'infrastruttura di base per il recupero agentico:

• Risorse di Azure: Microsoft Entra ID e Azure Arc forniscono identità, accesso e gestione ibrida.

• Infrastruttura locale: Questi componenti forniscono le risorse di calcolo, rete, bilanciamento del carico e archiviazione necessarie per eseguire l'estensione Recupero agentico e per accedere al recupero agenti in locale:

  • Azure Locale*
  • Cluster del servizio Azure Kubernetes (AKS) in Azure Localee*
  • MetalLB
  • Pool di nodi del servizio Azure Kubernetes
  • Server NFS (Network File System)
  • Macchina driver (host di gestione locale)

  * Il recupero agentico viene convalidato in Azure Localee.

• Livello agentico (se distribuito in modalità combinata o agente):

  • Runtime degli agenti (porta 8080): thread, messaggi, esecuzioni, streaming della crittografia del servizio di archiviazione
  • Knowledge Base Manager (porta 8080) - gestione delle knowledge base (GET, PATCH, PUT)
  • Servizio Knowledge Sources (porta 3005) - Registrazione della connessione al server MCP
  • MCP Server (porta 8080) - 6 strumenti di ricerca predefiniti su Model Context Protocol

• Livello di conoscenza (se distribuito in modalità combinata o in modalità di conoscenza):

  • API di inserimento (porta 8000): analisi dei documenti, suddivisione in blocchi, incorporamento
  • API di inferenza (porta 3001) - Completamento della chat RAG
  • API Collections (porta 3002) - gestione dei dati vettoriali
  • Incorporamento di modelli (BGE-M3, CLIP ViT-L/14) in esecuzione su 2 GPU
  • Docling parser : in esecuzione sulla CPU
  • Database vettoriale Milvus + archivio metadati PostgreSQL

• Endpoint del modello linguistico

  • Foundry Local on Azure Locale (scelta consigliata)
  • Endpoint esterno Bring Your Own Model (BYOM) che supporta un'API per il completamento delle chat compatibile con OpenAI, ad esempio come uno distribuito in Microsoft Foundry

  Usare una macchina driver (host di gestione locale) per semplificare la gestione del cluster Kubernetes supportato da Azure Arc su Azure Localee. Per ulteriori informazioni, vedere Preparare il cluster AKS in Azure Locale per Agentic Retrieval e Configurare il computer per gestire il cluster Kubernetes abilitato per Azure Arc.

Questa configurazione consente di eseguire una soluzione di chat sicura, scalabile e basata sull'intelligenza artificiale che usa i dati dell'utente in modalità edge.

Opzioni di configurazione chiave

Quando si implementa Agentic Retrieval, impostare diverse opzioni di configurazione per adattare la soluzione all'ambiente e ai requisiti.

• Endpoint del modello linguistico (obbligatorio): Il recupero agentico non aggrega i modelli linguistici. È necessario fornire un endpoint LLM personalizzato che espone un'API di completamento della chat compatibile con OpenAI. L'opzione consigliata è un Foundry Local nell'endpoint Azure Locale. In alternativa, usare un endpoint BYOM (Bring Your Own Model) esterno, ad esempio uno distribuito in Microsoft Foundry per i modelli ospitati nel cloud.
• Modalità di distribuzione: Scegliere i livelli da distribuire usando il layerSelection parametro :
  • combined (impostazione predefinita): piattaforma completa con entrambi i livelli
  • agentic — agenti, knowledge base, KT/KS, solo server MCP (nessuna GPU necessaria)
  • knowledge — acquisizione, inferenza, solo per le raccolte (2 GPU necessarie)
• Configurazione SSL e dominio: configurare un certificato di terminazione TLS (Transport Layer Security) e un dominio per consentire l'accesso sicuro all'endpoint della chat.
• Accesso e autenticazione: Configura l'ID applicazione di Microsoft Entra e assegna ruoli a utenti e gruppi.
• Configurazione dell'origine dati: Assicurarsi che l'origine dati, una condivisione NFS, sia raggiungibile e contenga i file necessari in formati supportati.

Se colleghi Agentic Retrieval a Foundry Local tramite identità gestita (foundryClientId), prevedi di configurare i ruoli nella sezione seguente.

Ruoli richiesti per l'inferenza di Foundry Local

Se distribuisci l'estensione Agentic Retrieval per usare un endpoint locale di Foundry (foundryClientId), assegna i tre ruoli seguenti prima di testare la chat o eseguire traffico di inferenza. Questi ruoli consentono a ogni parte della richiesta di superare i controlli di sicurezza e, se ne manca uno, le richieste possono avere esito negativo con gli errori 401 o 403. Questo modello di autorizzazione si applica solo quando si usa Foundry Local con foundryClientId. Non si applica all'autenticazione della chiave API BYOM.

Flusso di richiesta

Quando agenti e strumenti chiamano l'endpoint locale Foundry con un token di identità gestita, la richiesta passa attraverso tre controlli di autorizzazione:

• Livello 1 - Ruolo dell'app Entra: la registrazione dell'app Foundry verifica che l'identità gestita del chiamante abbia il ruolo FoundryInferenceAccess dell'app. Senza di esso, il token è valido ma manca l'attestazione richiesta roles .
• Layer 2 - Reader ARM: Il pod di inferenza di Foundry interroga Azure Resource Manager (ARM) per verificare le assegnazioni di ruolo del chiamante. L'identità gestita del cluster connesso deve disporre del ruolo Reader nella risorsa del cluster stesso affinché questa ricerca vada a buon fine.
• Layer 3 - Azure RBAC: ARM verifica che il chiamante disponga dei ruoli Azure necessari (Cognitive Services OpenAI User e Reader) a livello di sottoscrizione o del gruppo di risorse.

Riepilogo del livello

Tempistica dell'assegnazione di ruoli basata sull'identità

Le assegnazioni di ruolo richiedono ID entità che esistono solo dopo che le risorse sono state distribuite. Assegna ogni livello non appena è disponibile la relativa identità:

È anche possibile rinviare tutte le assegnazioni di ruolo fino a quando tutte le estensioni vengono installate e assegnate insieme. Per i passaggi relativi all'assegnazione dei ruoli, vedi Configurare l'autenticazione per l'inferenza locale di Foundry per Agentic Retrieval.

I ruoli di Azure RBAC da soli non sono sufficienti. Il file collaterale di autenticazione Foundry convalida i ruoli dell'app Microsoft Entra ID, non solo il controllo degli accessi in base al ruolo di Azure. Senza l'assegnazione di ruolo dell'app FoundryInferenceAccess , i token di identità gestita sono validi, ma non hanno mancano l'attestazione roles.

Processo di distribuzione per Agentic Retrieval

Il processo di distribuzione di Agentic Retrieval è costituito dai seguenti passaggi di alto livello:

Contenuti correlati

• Requisiti per il recupero agentico
• Elenco di controllo dei prerequisiti per la distribuzione
• Distribuire l'estensione recupero agentico
• Panoramica delle operazioni disconnesse su Azure Locale
• Aggiungere un'origine dati per Agentic Retrieval
• Configurazione del livello di conoscenza