> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/it/ai/ai-whitepaper/agentic-search.md).
# Ricerca agentica
## **Che cos'è la ricerca agentica?**
#### Agentic Search è un livello di contesto unificato e consapevole delle Autorizzazione che si estende ai contenuti Zoom e alle fonti dati Enterprise connesse
La ricerca agentica è una capacità di recupero della conoscenza di livello Enterprise che raccoglie, indicizza e correla informazioni rilevanti tra contenuti nativi di Zoom e dati di terze parti connessi, formando un unico insieme di conoscenze organizzative a cui una query può rispondere. Ciò che la distingue dalla ricerca convenzionale è l’ampiezza di ciò su cui una singola query può fare affidamento: una riunione trascrizione, un messaggio di chat per il team e un documento archiviato in un cloud drive aziendale possono tutti contribuire allo stesso risultato. La forma di tale risultato dipende dal punto di ingresso: una risposta sintetizzata in linguaggio naturale, oppure un insieme ordinato di materiale di origine basato su fonti per consentire a un altro modello di ragionare; ma le fonti esaminate e le autorizzazioni applicate nei loro confronti non cambiano.
All’interno di Zoom, il recupero copre il registrare del lavoro che si accumula già sulla piattaforma — registrazioni e trascrizioni delle riunioni, riepiloghi delle riunioni, conversazioni su Team Chat e i documenti, le note e gli altri artefatti creati insieme a loro. Oltre Zoom, il recupero si estende a sistemi di registrare e repository di contenuti connessi, che possono includere servizi come Salesforce, Google Drive, OneDrive, SharePoint, Confluence, Box, ServiceNow, Workday, Zendesk e Seismic. Quando l’indicizzazione è supportata e abilitata, il contenuto di questi sistemi viene acquisito nel livello di recupero di Zoom insieme alle informazioni native di Zoom, quindi una domanda viene risolta rispetto a un unico insieme di conoscenze organizzative invece che a una serie di repository isolati che devono essere cercati ognuno per conto proprio.
Il recupero è consapevole dell'Autorizzazione in ogni sua parte. I controlli di Access da ciascun sistema sorgente vengono ereditati e applicati, quindi le informazioni mostrate — native di Zoom o di terze parti — sono limitate in base alle Autorizzazione applicabili dell'utente o dell'agente richiedente. Ampliare l'insieme delle origini ricercabili non amplia l'Access di alcun individuo ad esse.
#### "Agentic Search" descrive una capacità, non un'interfaccia
Agentic Search è meglio inteso come una capacità di base piuttosto che come uno schermo o un pulsante specifico. La stessa capacità si può raggiungere in più di un modo: tramite l'interfaccia ZoomMate per gli utenti comuni e tramite le API Search e Ask e il Model Context Protocol (MCP) per le applicazioni e gli agenti AI. Qualunque sia il punto di ingresso utilizzato, il termine si riferisce alla stessa funzione principale: recuperare e sintetizzare informazioni pertinenti tra diverse fonti.
#### ZoomMate utilizza Agentic Search per recuperare dati indicizzati dalla conoscenza organizzativa connessa, quindi sintetizza i risultati in una risposta in linguaggio naturale
Per gli utenti quotidiani, ZoomMate è il luogo in cui la Ricerca agentica diventa routine. Prepararsi per una riunione imminente, ricordare una decisione presa in diverse riunioni passate o individuare un documento collegato a una voce di azione aperta: ciascuno può essere risolto con una singola richiesta, anziché richiedere ricerche separate tra riunioni, chat, documenti, Archiviazione su cloud e sistemi CRM o di ticketing.
#### MCP e le API Search and Ask estendono lo stesso meccanismo di recupero alle applicazioni e agli agenti IA esterni
Le applicazioni e gli agenti AI esterni, inclusi quelli costruiti su LLM di terze parti, possono chiamare Agentic Search come strumento tramite MCP. I controlli di Access viaggiano con la chiamare, così un agente recupera informazioni coerenti con i permessi dell’utente autenticato.
La **API di ricerca** restituisce un insieme ordinato di risultati pertinenti e lascia la generazione al modello del chiamante, il che è adatto ai casi in cui il materiale sorgente grezzo e fondato è l'output desiderato.
La **API Ask** esegue sia il recupero sia la generazione all'interno di Zoom, restituendo una risposta sintetizzata e citata in linguaggio naturale.
#### Un indice persistente e il recupero al momento della richiesta mantengono aggiornati i dati che cambiano frequentemente
Agentic Search non è limitato a un indice statico. I contenuti vengono vettorializzati, indicizzati e dotati di parole chiave, con contenuti di terze parti approvati incorporati tramite sincronizzazione incrementale con ambito admin per un recupero successivo efficiente. I dati che cambiano frequentemente, o che traggono vantaggio dall'attualità al momento della richiesta, possono invece essere interrogati direttamente tramite MCP o connessioni in tempo reale equivalenti, anziché essere serviti dall'indice.
Insieme, l'indice persistente e il recupero al momento della richiesta significano che il livello di contesto riflette lo stato attuale dei sistemi connessi anziché il loro stato all'ultima sincronizzazione.
## **Origini dei dati e indicizzazione**
#### L'architettura di indicizzazione di Zoom è realizzato appositamente per il recupero dell'IA conversazionale
L'architettura di indicizzazione di Zoom è realizzato appositamente per l'IA conversazionale, utilizzando la ricerca vettoriale, la segmentazione dei contenuti e uno schema progettato attorno al modo in cui i sistemi conversazionali recuperano il contesto. Molte tecnologie di ricerca enterprise e a grafo sono state originariamente progettate attorno a un obiettivo diverso: Connessione di documenti, persone, metadati e altre entità in un ambiente di produttività. Questa differenza architetturale conta perché l'IA conversazionale deve identificare e recuperare le specifiche informazioni semanticamente rilevanti per la domanda di un utente, anziché navigare principalmente le relazioni tra documenti o entità. L'approccio di Zoom struttura e indicizza i contenuti attorno a quel modello di recupero, rendendo i casi d'uso conversazionali una considerazione architetturale centrale anziché una funzionalità sovrapposta a un sistema progettato per un altro scopo.
In altri termini: è la differenza tra indicizzare una biblioteca per singoli libri e indicizzarla per i passaggi di cui qualcuno potrebbe aver bisogno per rispondere a una domanda.
#### I connettori di terze parti estendono il livello di contesto di Zoom ai sistemi di terze parti autorizzati, soggetti all'abilitazione da parte dell'admin
Agentic Search supporta l'indicizzazione da connettori di terze parti autorizzati, tra cui Google Drive, OneDrive, Box, Salesforce, ServiceNow, Zendesk, Seismic, Confluence e SharePoint, con connettori aggiuntivi disponibili in base allo stato attuale della release. Il fatto che un Connettore sia disponibile non significa che il suo contenuto sia automaticamente ricercabile: ogni fonte deve essere abilitata da un amministratore prima che Agentic Search possa iniziare a ingerirla. Questo modello controllato dall'admin è intenzionale: è progettato per mantenere l'ambito di indicizzazione allineato a ciò che un'Organizzazione ha effettivamente autorizzato, anziché esporre ogni sistema collegabile in modo predefinito.
#### Come funziona l'indicizzazione: dall'ingestione a un indice interrogabile
Quando un Connettore è abilitato, Agentic Search crea un indice ricercabile dei contenuti approvati anziché interrogare nuovamente il sistema di origine per ogni richiesta. Il processo si articola in diverse fasi:
1. **Ingestione** — I contenuti approvati vengono recuperati dalla fonte collegata, nel rispetto dell'ambito autorizzato da un amministratore e dei permessi degli utenti che effettuano la Connessione. Per le fonti basate su file come i drive cloud, il contenuto dei documenti viene recuperato per l'elaborazione anziché essere semplicemente collegato.
2. **Segmentazione** — Il contenuto recuperato è suddiviso in passaggi più piccoli, in modo che il recupero possa restituire la porzione specifica di un documento rilevante per una query, anziché interi file.
3. **Vettorizzazione** — Ogni passaggio viene convertito in un embedding numerico usando un modello di embedding, consentendo al recupero di corrispondere per significato e non solo per la formulazione esatta.
4. **Indicizzazione per parole chiave** — Anche il contenuto viene indicizzato per la corrispondenza delle parole chiave. Sia le funzionalità di Search che di Ask dipendono dalle corrispondenze delle parole chiave oltre che dalla similarità vettoriale, quindi i due approcci operano insieme anziché come alternative.
5. **Indicizzazione dei metadati di Autorizzazione** — Le informazioni di Access dell'utente vengono indicizzate insieme al contenuto, derivate dall'Autorizzazione nativa del sistema sorgente, in modo che il filtraggio consapevole in base all'Autorizzazione possa essere applicato al momento della query.
Il risultato è un indice di recupero specifico per il cliente — il contenuto proveniente da una fonte viene memorizzato in una forma delimitata per quel cliente e governata dalle regole di Autorizzazione di quel cliente, anziché in un archivio condiviso o multi-tenant.
#### Diagrammi e flussi di dati sono Disponibile per consultazione
I diagrammi che illustrano come la ricerca agentica di Zoom si connette ad applicazioni, servizi e origini dati di terze parti — inclusi i flussi di dati di connessione e di indicizzazione — sono Disponibile nel [Whitepaper di Zoom AI](https://library.zoom.com/ai/ai-whitepaper/diagrams#zoommate-third-party-connections-and-indexing).
#### Ciò che viene indicizzato è regolato dall'ambito che un amministratore autorizza per il Connettore
Il contenuto che viene indicizzato è regolato dall'ambito che un amministratore autorizza per il Connettore. Una volta connessa una fonte, l'indice viene mantenuto tramite aggiornamenti continui anziché tramite un'acquisizione una tantum:
1. **Sincronizza iniziale**: Alla prima configurazione, il Connettore esegue una sincronizzazione completa del contenuto nell'ambito, incluso il contenuto storico esistente.
2. **Aggiornamento giornaliero dell'indicizzazione**: Per alcune origini, il Connettore aggiorna il contenuto nell'ambito una volta al giorno.
3. **Sincronizza incrementale**: Per altre, il Connettore esegue Sincronizza periodiche durante ogni giorno che elaborano solo il contenuto aggiunto, modificato o cambiato dall'ultima Sincronizza, invece di rielaborare l'intero repository ogni volta.
#### Il recupero indicizzato e il recupero in tempo reale lavorano insieme
Agentic Search utilizza due percorsi di recupero, e quale si applica è determinato da come una sorgente è connessa e da quale tipo di dati contiene — non da un'impostazione per query o per cartella che un utente o un admin attiva/disattiva.
Contenuto connesso come una **sorgente dati a livello di account** nel gruppo admin viene acquisito in un indice specifico per il cliente e interrogato da lì. Questo è il percorso predefinito per i contenuti non strutturati — documenti, articoli di conoscenza e file — perché un indice precompilato rende il recupero rapido ed efficiente al momento della query e produce un indice ricercabile condiviso in tutta l'Organizzazione.
Il contenuto viene raggiunto **direttamente, in tempo reale, tramite MCP o una API** negli altri casi: connettori personali che un singolo utente autorizza (come la propria e-mail, il proprio calendario o la propria archiviazione personale su cloud), record strutturati come i dati degli oggetti CRM e altri contenuti che cambiano con una frequenza sufficiente da trarre vantaggio dall'attualità al momento della richiesta. Un connettore personale recupera solo i documenti a cui l'utente che si connette può accedere, e le connessioni ai dati strutturati portano la propria autenticazione e Autorizzazione dell'utente, invece di essere servite dall'indice.
Poiché il percorso segue la connessione, la stessa applicazione sottostante può essere raggiunta in entrambi i modi a seconda di come è configurata. Un servizio di archiviazione su cloud connesso come sorgente dati gestita dall'admin viene indicizzato per la ricerca a livello di Organizzazione, mentre lo stesso servizio connesso come connettore personale di un individuo viene interrogato direttamente e limitato all'accesso di quell'utente.
#### Le connessioni esterne di Agentic Search sono basate sul Model Context Protocol (MCP)
Le connessioni tra Zoom e modelli, strumenti e sorgenti dati esterni sono basate sul Model Context Protocol (MCP), uno standard client-server aperto per collegare modelli a strumenti e dati. I server MCP operano all'edge di Zoom, fornendo un'interfaccia coerente attraverso cui vengono effettuate richieste di recupero — sia per il recupero in tempo reale dai sistemi connessi sia per gli agenti esterni che raggiungono Agentic Search come strumento. Questo trasporto standardizzato sostituisce integrazioni una tantum, sorgente per sorgente, con un modello di connessione comune.
#### La durata dell'indicizzazione varia in base al cliente, al volume di dati e al tipo di dati
Non esiste una tempistica fissa per quanto tempo impiega un dato connettore per indicizzare completamente. Il tempo richiesto varia da cliente a cliente, in base alla quantità di dati indicizzati e al tipo di dati coinvolto. I limiti di velocità imposti dalla piattaforma di terze parti che viene indicizzata sono un fattore contribuente — ogni sistema sorgente limita la quantità di dati che può essere estratta in una determinata finestra, e tale limitazione varia in base alla piattaforma, al livello del piano e al design dell'API. I clienti che pianificano un'attività di indicizzazione iniziale per un repository grande o molto utilizzato dovrebbero aspettarsi un arco di tempo di diverse settimane, anziché un risultato in giornata o nella stessa settimana.
#### La capacità di indicizzazione scala in base al livello di licenza ZoomMate ed è aggregata a livello di Organizzazione
La capacità di indicizzazione è una funzione del livello di licenza anziché un'assegnazione universale fissa. Ogni utente con licenza contribuisce con una quantità di capacità per posto basata sul proprio livello, e tali quantità si combinano in un unico pool a livello di Organizzazione condiviso da tutta l'Organizzazione anziché assegnato a ciascun singolo utente.
Il contenuto totale indicizzato in tutte le sorgenti connesse e per tutti gli utenti deve rimanere entro il pool complessivo dell'org — il che significa che un utente che indicizza un repository grande attinge alla stessa capacità condivisa disponibile a tutti gli altri. Poiché il pool cresce con ogni posto con licenza, la capacità totale di un'organizzazione è la somma di ciò che contribuiscono tutti i suoi utenti con licenza.
Ad esempio, se una licenza concede 1 GB di spazio di archiviazione, con 25 licenze, l'account ha un totale di 25 GB di spazio di archiviazione. Con 100 utenti, 100 GB.
Le Organizzazioni che intendono indicizzare repository grandi (uno spazio completo di Confluence, una grande sede SharePoint, un'istanza CRM matura) dovrebbero dimensionare il proprio livello di licenza e il numero di posti in base al volume totale di contenuti previsto, non in base ai modelli di utilizzo per utente. È disponibile ulteriore capacità di indicizzazione—contattate il team account Zoom per maggiori informazioni.
#### La dimensione del file e il tipo di file influenzano entrambi ciò che viene indicizzato
Si applicano due limiti di dimensione separati, e si comportano in modo diverso:
* **Limite di 64 MB per il file originale (download):** Se la dimensione originale di un file sorgente supera 64 MB, viene saltato e non scaricato per l'elaborazione.
* **Limite di 16 MB per il contenuto elaborato (indicizzazione):** I file scaricati vengono convertiti in un formato di elaborazione unificato. Se il file elaborato risultante supera 16 MB, solo i primi 16 MB del suo contenuto vengono indicizzati; il resto no.
I due limiti falliscono in modo diverso: un originale troppo grande viene saltato del tutto, mentre un file elaborato troppo grande viene troncato anziché escluso, quindi il suo contenuto iniziale appare ancora nel recupero mentre quello successivo no.
Separatamente, l'indicizzazione dipende dal tipo di file, indipendentemente dalla dimensione. I contenuti multimediali — audio, video e immagini — non vengono indicizzati, a qualsiasi dimensione. Vengono rimossi durante la conversione al formato di elaborazione unificato, prima che venga valutato uno dei due limiti di dimensione. I metadati vengono indicizzati per tutti i documenti, ma il contenuto completo viene indicizzato solo per i tipi di file supportati e non multimediali. Per i tipi non supportati, il documento è comunque reperibile tramite i suoi metadati, ma i suoi contenuti non sono ricercabili.
#### Gli admin non possono attualmente controllare l'ordine in cui i contenuti vengono indicizzati
Non esiste oggi alcun meccanismo che consenta a un amministratore di dare priorità a cartelle, spazi o tipi di contenuto specifici affinché vengano indicizzati prima di altri all'interno di una sorgente connessa. L'indicizzazione procede attraverso i contenuti idonei in un Connettore abilitato senza alcun modo di sequenziarla, il che significa che le Organizzazioni non possono anticipare l'indicizzazione dei propri contenuti di maggior valore e dovrebbero aspettarsi che la copertura dell'indicizzazione si ampli gradualmente su tutto il repository anziché partire prima dal materiale più critico per l'attività.
L'indicizzazione inoltre non può essere pianificata per essere eseguita a un orario o con una cadenza scelti. Una volta abilitata una sorgente, l'indicizzazione viene eseguita secondo i propri tempi anziché secondo una pianificazione impostata da un amministratore, quindi è meglio considerarla come un processo in background che termina quando termina, piuttosto che come uno che possa essere sincronizzato con una finestra specifica.
## **Amministrazione, Autorizzazioni e Governance**
#### Gli amministratori possono controllare quali sorgenti sono connesse e gli utenti autenticano il proprio accesso
I Connettori vengono abilitati da un amministratore, che determina quali sistemi di terze parti sono disponibili per l'indicizzazione e la ricerca all'interno dell'Organizzazione. L'abilitazione di un Connettore rende una sorgente disponibile all'Organizzazione, ma non concede intrinsecamente accesso ai suoi contenuti. Ogni utente deve autenticare il proprio accesso alla sorgente individualmente — una volta autenticato, le sue Autorizzazioni di recupero si allineano alle autorizzazioni già presenti nel sistema sorgente, quindi può mostrare solo ciò a cui poteva già accedere lì.
#### Il recupero è consapevole delle Autorizzazioni ed è in sola lettura
Agentic Search è progettato per applicare i controlli di accesso di ciascun sistema sorgente, quindi le risposte riflettono solo il contenuto che l'utente è già autorizzato a vedere; due utenti che pongono la stessa domanda possono ricevere risultati diversi in base alle rispettive autorizzazioni nella sorgente dati di terze parti. Il recupero è in sola lettura e segue le politiche di conservazione di ciascuna sorgente — ad esempio, il contenuto della riunione Zoom segue il relativo periodo di conservazione anziché essere conservato separatamente dal livello di ricerca. Poiché il recupero è governato e consapevole delle Autorizzazioni al momento della query, offre anche un'alternativa all'esportazione in blocco di trascrizioni o record grezzi, mantenendo l'accesso allineato alla sorgente originale di terze parti.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://library.zoom.com/technical-library/it/ai/ai-whitepaper/agentic-search.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.