> 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/sv/ai/ai-whitepaper/agentic-search.md).
# Agentisk sökning
## **Vad är agentisk sökning?**
#### Agentic Search är ett enhetligt, behörighetsmedvetet kontextlager som spänner över Zoom-innehåll och anslutna Enterprise-datakällor
Agentic Search är en kunskapshämtningsförmåga i Enterprise-klass som samlar in, indexerar och korrelerar relevant information över Zoom-native-innehåll och anslutna tredjepartskällor, och bildar en enda sammanhängande kunskapsbas för en organisation som en fråga kan avgöra mot. Det som skiljer den från konventionell sökning är bredden i vad en enda fråga kan dra nytta av: en möte avskrift, ett Team Chat-meddelande och ett dokument som ligger i en företagsmoln-disk kan alla bidra till samma resultat. Formen på det resultatet beror på ingångspunkten — ett syntetiserat svar på naturligt språk, eller en rangordnad uppsättning underbyggt källmaterial som en annan modell kan resonera utifrån — men de källor som spänner över och de behörigheter som tillämpas mot dem kan inte ändras.
Inom Zoom sträcker sig hämtningen till att spela in den arbetsdokumentation som redan samlas på plattformen — mötesinspelningar och transkriptioner, mötessammanfattningar, Team Chat-konversationer och dokumenten, anteckningarna och andra artefakter som skapas tillsammans med dem. Utöver Zoom omfattar hämtningen anslutna registersystem och innehållsarkiv, som kan inkludera tjänster som Salesforce, Google Drive, OneDrive, SharePoint, Confluence, Box, ServiceNow, Workday, Zendesk och Seismic. När indexering stöds och är aktiverad matas innehåll från dessa system in i Zooms hämtningslager tillsammans med Zoom-infödd information, så att en fråga löses mot en och samma kunskapsbas i organisationen i stället för en uppsättning isolerade arkiv som var och en måste sökas igenom på sina egna villkor.
Hämtning är medveten om behörighet genomgående. Access-kontroller från varje källsystem ärvs och upprätthålls, så information som exponeras — Zoom-intern eller från tredje part — begränsas utifrån de tillämpliga behörigheterna för den användare eller agent som begär dem. Att utöka mängden sökbara källor utökar inte någons individuella åtkomst till dem.
#### "Agentic Search" beskriver en förmåga, inte ett gränssnitt
Agentic Search förstås bäst som en underliggande funktion snarare än en specifik skärm eller knapp. Samma funktion nås på mer än ett sätt: via ZoomMate-gränssnittet för vardagsanvändare, och via Search and Ask APIs samt Model Context Protocol (MCP) för applikationer och AI-agenter. Oavsett vilken ingångspunkt som används, syftar termen på samma kärnfunktion: att hämta och sammanställa relevant information från olika källor.
#### ZoomMate använder Agentic Search för att hämta indexerade data från ansluten organisatorisk kunskap och sammanställer sedan resultaten till ett svar på naturligt språk
För vanliga användare är ZoomMate platsen där Agentic Search blir rutinmässigt. Att förbereda sig för ett kommande möte, minnas ett beslut som fattades över flera tidigare möten eller hitta ett dokument som är kopplat till en öppen åtgärdspunkt kan var och en lösas i en enda begäran, i stället för att kräva separata sökningar i möten, chattar, dokument, molnlagring och CRM- eller ärendehanteringssystem.
#### MCP och API:erna Search och Ask utökar samma informationshämtning till applikationer och externa AI-agenter
Applikationer och externa AI-agenter, inklusive de som bygger på tredjeparts-LLM:er, gör ett samtal till Agentic Search som ett verktyg via MCP. Access-kontroller följer med samtalet, så att en agent hämtar information som är konsekvent med den autentiserade användares behörigheter.
Den **Search API:n** returnerar en rankad uppsättning relevanta resultat och lämnar genereringen till anroparens egen modell, vilket passar fall där rått, förankrat källmaterial är det önskade resultatet.
Den **Ask API:n** utför både hämtning och generering inom Zoom, och returnerar ett syntetiserat, källhänvisat svar på naturligt språk.
#### Ett beständigt index och hämtning vid förfrågningstillfället håller data som ändras ofta uppdaterade
Agentic Search är inte begränsat till ett statiskt index. Innehåll vektoriseras, indexeras och nyckelordssätts, med godkänt innehåll från tredje part införlivat genom inkrementell synkronisering i admin-scoped för effektivare senare hämtning. Data som ändras ofta, eller som gynnas av färskhet vid förfrågningstillfället, kan i stället frågas direkt via MCP eller motsvarande realtidsanslutningar i stället för att levereras från indexet.
Tillsammans innebär det beständiga indexet och hämtning vid förfrågningstillfället att kontextlagret speglar det aktuella tillståndet i anslutna system snarare än deras tillstånd vid den senaste synkroniseringen.
## **Datakällor och indexering**
#### Zooms indexeringsarkitektur är särskilt utformad för hämtning för konversations-AI
Zooms indexeringsarkitektur är särskilt utformad för konversations-AI, med vektorsökning, uppdelning av innehåll i bitar och ett schema som är utformat efter hur konversationssystem hämtar kontext. Många enterprise-söknings- och graftekniker var ursprungligen utformade kring ett annat mål: att ansluta dokument, personer, metadata och andra entiteter i en produktivitetsmiljö. Denna arkitektoniska skillnad spelar roll eftersom konversations-AI behöver identifiera och hämta de specifika informationsdelar som är semantiskt relevanta för användarens fråga, snarare än att främst navigera relationer mellan dokument eller entiteter. Zooms metod strukturerar och indexerar innehåll utifrån den hämtmodellen, vilket gör användningsfall för konversationella system till en kärnarkitektonisk övervägelse snarare än en kapacitet som lagts ovanpå ett system utformat för ett annat syfte.
Med andra ord: det är skillnaden mellan att indexera ett bibliotek efter enskilda böcker och att indexera det efter de passager som någon faktiskt kan behöva för att svara på en fråga.
#### Tredjepartsanslutningsprogram utökar Zooms kontextlager till auktoriserade tredjepartssystem, förutsatt att admin aktiverar dem
Agentic Search stöder indexering från auktoriserade tredjepartsanslutningsprogram, inklusive Google Drive, OneDrive, Box, Salesforce, ServiceNow, Zendesk, Seismic, Confluence och SharePoint, med ytterligare anslutningsprogram som är tillgänglig beroende på aktuell versionsstatus. Att ett anslutningsprogram är tillgänglig betyder inte att dess innehåll automatiskt är sökbart — varje källa måste aktiveras av en administratör innan Agentic Search kan börja ta in det. Denna admin-styrda modell är avsiktlig: den är utformad för att hålla indexeringsomfånget i linje med vad en organisation faktiskt har auktoriserat, snarare än att exponera varje anslutbart system som standard.
#### Så fungerar indexering: från inhämtning till ett sökbart index
När ett anslutningsprogram är aktiverat bygger Agentic Search ett sökbart index över godkänt innehåll i stället för att fråga källsystemet på nytt för varje begäran. Processen går igenom flera steg:
1. **Inhämtning** — Godkänt innehåll hämtas från den anslutna källan, med förbehåll för den omfattning som en administratör har auktoriserat och behörigheterna för de användare som ansluter. För filbaserade källor som molnlagringsenheter hämtas dokumentinnehållet för bearbetning snarare än att bara länkas.
2. **Segmentering** — Det hämtade innehållet delas upp i mindre passager så att hämtning kan returnera den specifika del av ett dokument som är relevant för en fråga, i stället för hela filer.
3. **Vektorisering** — Varje passage konverteras till en numerisk inbäddning med hjälp av en inbäddningsmodell, vilket gör att hämtning kan matcha på betydelse och inte bara exakt ordalydelse.
4. **Nyckelordsindexering** — Innehållet indexeras också för nyckelordsmatchning. Både Search- och Ask-funktionerna är beroende av nyckelordsmatchningar tillsammans med vektorsimilaritet, så de två angreppssätten fungerar tillsammans snarare än som alternativ.
5. **Indexering av behörighetsmetadata** — Användar-Access-information indexeras tillsammans med innehållet, härledd från källsystemets egna inbyggda behörigheter, så att behörighetsmedveten filtrering kan tillämpas vid frågetillfället.
Resultatet är ett kundspecifikt hämtningsindex — innehåll från en källa lagras i en form som är avgränsad till den kunden och styrs av den kundens behörigheter, i stället för i ett delat eller hyresgästöverskridande lager.
#### Diagram och dataflöden är tillgängliga för referens
Diagram som illustrerar hur Zooms Agentic Search ansluter till tredjepartsapplikationer, tjänster och datakällor — inklusive dataflöden för anslutning och indexering — är tillgängliga i [Zoom AI-vitbok](https://library.zoom.com/ai/ai-whitepaper/diagrams#zoommate-third-party-connections-and-indexing).
#### Det som indexeras styrs av den omfattning som en administratör auktoriserar för anslutningsprogrammet
Det innehåll som indexeras styrs av den omfattning som en administratör auktoriserar för anslutningsprogrammet. När en källa är ansluten underhålls indexet genom löpande uppdateringar i stället för engångsimport:
1. **Initial synkronisera**: Vid den första konfigurationen utför anslutningsprogrammet en fullständig synkronisering av det innehåll som omfattas, inklusive befintligt historiskt innehåll.
2. **Daglig indexuppdatering**: För vissa källor uppdaterar anslutningsprogrammet det innehåll som omfattas en gång per dag.
3. **Inkrementell synkronisera**: För andra kör anslutningsprogrammet periodiska synkronisera under hela dagen som endast bearbetar innehåll som har lagts till, ändrats eller uppdaterats sedan den senaste synkronisera, i stället för att bearbeta hela arkivet varje gång.
#### Indexerad hämtning och hämtning i realtid fungerar tillsammans
Agentic Search använder två hämtningsvägar, och vilken som gäller avgörs av hur en källa är ansluten och vilken typ av data den innehåller — inte av en inställning per fråga eller per mapp som en användare eller admin växlar.
Innehåll som är anslutet som en **datakälla på kontonivå** i adminpanelen matas in i ett kundspecifikt index och söks därifrån. Detta är standardvägen för ostrukturerat innehåll — dokument, kunskapsartiklar och filer — eftersom ett förbyggt index gör hämtning snabb och effektiv vid frågetillfället, och det skapar ett sökbart index som delas över hela organisationen.
Innehåll nås **direkt, i realtid, via MCP eller ett API** i de andra fallen: personliga anslutningsprogram som en enskild användare auktoriserar (till exempel sin egen e-post, kalender eller personliga molnlagring), strukturerade poster som CRM-objektdata och annat innehåll som ändras tillräckligt ofta för att dra nytta av färskhet vid förfrågningstillfället. Ett personligt anslutningsprogram hämtar endast de dokument som den användare som ansluter kan komma åt, och anslutningar för strukturerade data använder sin egen användarautentisering och auktorisering i stället för att levereras från indexet.
Eftersom vägen följer anslutningen kan samma underliggande applikation nås på båda sätten beroende på hur den är konfigurerad. En molnlagringstjänst som är ansluten som en adminstyrd datakälla indexeras för sökning i hela organisationen, medan samma tjänst som är ansluten som en enskild användares personliga anslutningsprogram frågas direkt och avgränsas till den användarens egen åtkomst.
#### Externa anslutningar för Agentic Search är byggda på Model Context Protocol (MCP)
Anslutningar mellan Zoom och externa modeller, verktyg och datakällor är byggda på Model Context Protocol (MCP), en öppen klient–server-standard för att länka modeller till verktyg och data. MCP-servrar körs vid Zooms kant och tillhandahåller ett konsekvent gränssnitt genom vilket hämtningsförfrågningar görs — både för realtidshämtning från anslutna system och för externa agenter som använder Agentic Search som ett verktyg. Denna standardiserade transport ersätter enstaka integrationer, källa för källa, med en gemensam anslutningsmodell.
#### Indexeringstiden varierar beroende på kund, datavolym och datatyp
Det finns ingen fast tidslinje för hur lång tid ett givet anslutningsprogram tar för att indexera fullt ut. Tiden som krävs varierar för varje kund, beroende på mängden data som indexeras och vilken typ av data det gäller. Hastighetsbegränsningar som införs av den tredjepartsplattform som indexeras är en bidragande faktor — varje källsystem stryper hur mycket data som kan hämtas under ett visst tidsfönster, och denna strypning varierar beroende på plattform, plannivå och API-design. Kunder som planerar en första indexeringsinsats för ett stort eller flitigt använt arkiv bör räkna med en tidsram på flera veckor snarare än ett resultat samma dag eller samma vecka.
#### Indexeringskapaciteten skalar med licensnivån för ZoomMate och samlas i en pool på organisationsnivå
Indexeringskapaciteten är en funktion av licensnivån snarare än en fast universell tilldelning. Varje licenserad användare bidrar med ett kapacitetsbelopp per plats baserat på sin nivå, och dessa belopp slås ihop till en enda organisationsomfattande pool som delas över hela organisationen i stället för att tilldelas varje enskild användare.
Det totala indexerade innehållet från alla anslutna källor och alla användare måste hålla sig inom organisationens samlade pool — vilket innebär att en användare som indexerar ett stort arkiv använder samma delade kapacitet som är tillgänglig för alla andra. Eftersom poolen växer med varje licensierad plats är en organisations totala kapacitet summan av vad alla dess licenserade användare bidrar med.
Till exempel, om en licens ger 1 GB lagring har kontot vid 25 licenser totalt 25 GB lagring. Vid 100 användare, 100 GB.
Organisationer som planerar att indexera stora arkiv (ett helt Confluence-utrymme, en stor SharePoint-plats, en mogen CRM-instans) bör dimensionera sin licensnivå och sitt antal platser utifrån den förväntade totala innehållsvolymen, inte utifrån användningsmönster per användare. Ytterligare indexkapacitet finns tillgänglig — kontakta ditt Zoom-kontoteam för mer information.
#### Filstorlek och filtyp påverkar båda vad som indexeras
Två separata storleksgränser gäller, och de beter sig olika:
* **64 MB-gräns för originalfil (nedladdning):** Om en källfils ursprungliga storlek överstiger 64 MB hoppas den över och laddas inte ned för bearbetning.
* **16 MB-gräns för bearbetat innehåll (indexering):** Nedladdade filer konverteras till ett enhetligt bearbetningsformat. Om den resulterande bearbetade filen överstiger 16 MB indexeras endast de första 16 MB av dess innehåll; resten gör det inte.
De två gränserna slår igenom på olika sätt: en för stor originalfil hoppas över helt, medan en för stor bearbetad fil trunkeras i stället för att uteslutas, så dess inledande innehåll visas fortfarande i hämtning medan senare innehåll inte gör det.
Separat beror indexeringen också på filtyp, oberoende av storlek. Multimediainnehåll — ljud, video och bilder — indexeras inte, oavsett storlek. Det tas bort under konverteringen till det enhetliga bearbetningsformatet, innan någon av storleksgränserna utvärderas. Metadata indexeras för alla dokument, men hela innehållet indexeras endast för filtyper som stöds och inte är media. För filtyper som inte stöds går dokumentet ändå att hitta via sin metadata, men dess innehåll är inte sökbart.
#### Administratörer kan för närvarande inte kontrollera i vilken ordning innehåll indexeras
Det finns i dag ingen mekanism för att en administratör ska kunna prioritera vissa mappar, utrymmen eller innehållstyper så att de indexeras före andra inom en ansluten källa. Indexeringen fortskrider över berättigat innehåll i ett aktiverat anslutningsprogram utan någon möjlighet att sekvensera det, vilket innebär att organisationer inte kan lägga indexeringen av sitt mest värdefulla innehåll först och bör förvänta sig att indexeringsomfattningen byggs upp gradvis över hela arkivet i stället för att börja med det mest affärskritiska materialet först.
Indexering kan inte heller schemaläggas att köras vid en vald tidpunkt eller med en viss frekvens. När en källa har aktiverats körs indexeringen enligt sin egen tidsplan snarare än enligt ett schema som en administratör ställer in, så det är bäst att behandla den som en bakgrundsprocess som slutförs när den slutförs snarare än en som kan tidsanpassas till ett specifikt fönster.
## **Administration, behörighet och styrning**
#### Administratörer kan kontrollera vilka källor som är anslutna, och användare autentiserar sin egen åtkomst
Anslutningsprogram aktiveras av en administratör, som avgör vilka tredjepartssystem som är tillgängliga för indexering och sökning inom organisationen. Att aktivera ett anslutningsprogram gör en källa tillgänglig för organisationen, men det ger i sig inte åtkomst till dess innehåll. Varje användare måste autentisera sin åtkomst till källan individuellt — när de väl är autentiserade överensstämmer deras hämtningsbehörigheter med deras befintliga behörigheter i källsystemet, så de kan bara visa det de redan kunde komma åt där.
#### Hämtning tar hänsyn till behörigheter och är skrivskyddad
Agentic Search är utformat för att tillämpa åtkomstkontrollerna i varje källsystem, så svaren speglar endast det innehåll som användaren redan har behörighet att se; två användare som ställer samma fråga kan få olika resultat baserat på sina respektive behörigheter i tredjepartsdatakällan. Hämtning är skrivskyddad och följer bevarandepolicyn för varje källa — till exempel följer Zoom-mötesinnehåll sin tillämpliga bevarandetid i stället för att bevaras separat av söklagret. Eftersom hämtning styrs och tar hänsyn till behörigheter vid frågetillfället, erbjuder den också ett alternativ till att exportera råa transkriptioner eller poster i bulk, och håller åtkomsten i linje med den ursprungliga tredjepartskällan.
---
# 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/sv/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.