Þess vegna þarftu trausta innviði til að vera agent-ready árið 2025

Formáli

Með þessari alls staðar nálægð vakna margar hugmyndir og löngunin til að framkvæma eða að minnsta kosti prófa sig áfram. Hjá glueckkanja AG styðjum við viðskiptavini okkar í gegnum allt þetta ferli. Að sjálfsögðu erum við þegar farin að þróa og byggja agents, en í 80% verkefna okkar er megináherslan á að undirbúa gögnin og tenantinn fyrir smíði agents. Áður en þú innleiðir Copilot í rekstur hjá þér er þess virði að skoða innviðina þína gagnrýnum augum. Þegar ákvarðanir eru teknar á þessu sviði eru nokkur mikilvæg atriði sem þarf að skilja áður en AI agents eru teknir í notkun í stórum stíl. Þess vegna leiði ég þig í þessari bloggfærslu í gegnum lykilskrefin og muninn þar á milli. Á tímum þegar AI aðstoðarmenn eins og Microsoft 365 Copilot Agents lofa að umbreyta vinnuheiminum gildir ein regla umfram allt aðrar: AI er aðeins jafn góð og kerfið undir henni.

Þessi ítarlegi leiðarvísir lýsir hvernig þú undirbýrð gögnin þín og innviði fyrir Copilot Agents og fer yfir lykilaðferðir í SharePoint, Teams og Power Platform.

Hvers vegna innviðir (gögn) þín skipta máli

Þegar við notum AI agents er brýnt að skilja að þessir agents búa ekki sjálfkrafa yfir þekkingu um fyrirtækið okkar, gögnin okkar eða sérstakt rekstrarumhverfi. Sjálfgefið hefur AI agent aðeins þá innbyggðu þekkingu sem verður til við þjálfun Large Language Model (LLM). Til að auka og víkka út virkni þessara AI agents á áhrifaríkan hátt er nauðsynlegt að tengja saman ýmsa þætti á skipulagðan hátt. Það má gera með System Prompts, Knowledge Bases, Connectors, Web-Search, aðgangi að Microsoft Graph, Semantic Search og fleiri verkfærum. Saman gera þessir þættir AI agents kleift að skila nákvæmari og samhengislega réttum svörum og aðgerðum, í takt við sértækar þarfir og gögn fyrirtækisins. Þar sem við erum aðeins í upphafi agentic-tímabilsins munu mörg okkar byrja á einföldum agents sem sækja upplýsingar úr fyrirliggjandi SharePoint Online libraries.

Fyrir okkur í IT þýðir það að við þurfum að hugsa betur um gögnin okkar í SharePoint Online en nokkru sinni fyrr.

SharePoint Online = Þekking = Gögn og Gögn = Lykillinn

Skýr skilaboð frá mér: Áður en þú bætir AI copilots inn í fyrirtækið, komdu skikk á gagnahúsið þitt fyrst. Sömu gögn og fæða Copilot Agents þína fæða líka Microsoft 365 Copilot sjálfan.

Og ekki bara það. Microsoft 365 Copilot metur sömu gögnin. Ef þau eru óskipulögð, of víða deilt eða illa varin getur AI birt rangar eða viðkvæmar upplýsingar á óvæntum stundum. Ímyndaðu þér til dæmis að þú spyrjir Copilot um skipurit fyrirtækisins og fáir smáatriði úr trúnaðarmáli um endurskipulagningu sem þú áttir aldrei að sjá. Slík atvik gerast þegar innihaldi er oversharað (of víða aðgengilegt) á pöllum eins og SharePoint eða Teams. Athugaðu að Copilot virðir allar núverandi heimildir, sem þýðir að slíkt getur aðeins gerst þegar heimildir eru rangt stilltar. Á móti kemur að ef gögn eru læst inni í sílóum eða óaðgengileg verða AI aðstoðarmenn minna gagnlegir.

Copilot birtir aðeins gögn frá fyrirtækinu sem viðkomandi notandi hefur að minnsta kosti view permissions á.

Heimild: https://learn.microsoft.com/en-gb/copilot/microsoft-365/microsoft-365-copilot-privacy?azure-portal=true

Aðalatriðið: Enterprise AI heppnast aðeins með traustum gagnagrunni. Nýleg skýrsla frá Microsoft bendir á data oversharing, data leakage og noncompliant usage sem stærstu áskoranirnar sem þarf að leysa áður en AI er tekið í notkun. Fyrirtæki sem fjárfesta í undirbúningi SharePoint Online og annarra gagnaheimilda opna kosti Copilot með sjálfstrausti, á meðan þau sem sleppa því taka á sig áhættu á öryggisrofum eða óviðeigandi AI úttaki. Rannsóknir sýna að um þriðjungur ákvarðanatakenda hefur ekki fulla yfirsýn yfir gögn sem eru mikilvæg fyrir reksturinn.

10 skref til að bæta M365 gagnainnviðina þína núna

Nú vitum við að agents þínir munu þurfa gögn. Þegar við hjá glueckkanja komum að slíkum verkefnum er þetta dæmigerður 10 punkta listi sem við förum yfir með viðskiptavinum, ofan frá og niður.

Skref 1: Farðu yfir grunn sharing settings

Yfirfarðu tenant-víðar stillingar sem gætu leitt til oversharing. Skoðaðu til dæmis sjálfgefnar link sharing policies (t.d. hvort „Anyone with the link" eða „People in your organization" er leyft sjálfgefið fyrir SharePoint/OneDrive), hvort notendur geta stofnað opinber Teams sjálfgefið, og hvort Power Platform umhverfið þitt er opið án governance. Rangar sjálfgefnar stillingar hér eru algeng orsök óviljandi víðtæks aðgangs.

Skref 2: Skoðaðu opinber Teams

Farðu yfir öll Microsoft Teams sem merkt eru „Public". Opinbert Team þýðir að hver sem er í fyrirtækinu þínu getur fundið og skoðað innihaldið. Gakktu úr skugga um að öll Team sem stillt eru á opinber innihaldi eingöngu efni sem ekki er viðkvæmt og hentar breiðum hópi. Ef ekki, breyttu því í einkanotkun eða lagaðu meðlimalistann. Það er auðvelt fyrir Team að vera stofnað sem opinbert og gleymast síðan, þannig að skjöl séu opin öllum starfsmönnum.

Skref 3: Yfirfarðu Graph Connectors

Athugaðu hvort tenantinn þinn er með Microsoft Graph Connectors uppsetta sem draga inn gögn frá þriðja aðila (t.d. úr utanaðkomandi skráakerfum, wikis o.s.frv.). Fjarlægðu eða tryggðu hvern þann connector sem indexar gögn sem ekki allir eiga að sjá. Hvers vegna? Innihald sem er indexað í gegnum Graph Connectors verður hluti af Microsoft Graph search index, sem þýðir að Copilot getur mögulega notað það til að svara prompts. Þú vilt aðeins tengja við gagnaheimildir sem eru viðeigandi og ætlaðar.

Skref 4: Búðu til SharePoint Online Baseline Report

SPO hefur ýmsar mögulegar áhættur varðandi óæskileg gögn í Agents og Copilot. Þú þarft að skoða nokkur lykilmælikvarða:

• Broken Permission Inheritance á möppustigi
• Opinber SharePoint Sites
• Notkun á „Everyone Except External Users" eða öðrum dynamic group sem inniheldur alla notendur
• Anyone Sharing Links
• Everyone-in-my-org Sharing Links
• Óæskilegir aðilar í Site Admins / Owners / Members / Visitors Group

Skref 5: Flokkaðu og forgangsraðaðu áhættum

Taktu niðurstöðurnar úr Skrefum 1 til 4 og raðaðu þeim eftir alvarleika. Hvaða sites eða skrár innihalda mest af viðskiptalega mikilvægum eða viðkvæmum gögnum og eru jafnframt með exposure áhættu? Forgangsraðaðu því að laga þau fyrst. Með því að leggja viðskiptalegt samhengi ofan á (t.d. site með fjárhagsgögnum á móti site með almennum sniðmátum) getur þú einbeitt þér að þeim málum sem hafa mest áhrif fyrst.

Skref 6: Fáðu site owners með í access reviews

Fyrir hvert SharePoint site (eða Team) sem er merkt sem áhættusamt skaltu láta site owner tvítékka hverjir hafa aðgang og hvort það sé viðeigandi. Owners eru yfirleitt næstir efninu og geta fljótt greint „Bíddu, af hverju hefur Everyone read access hérna? Það á ekki að vera svona." Innleiddu ferli þar sem site admins staðfesta heimildir reglulega.

Skref 7: Komdu á áframhaldandi eftirliti

Settu upp stöðugt vöktunarferli fyrir ný oversharing tilvik. Oversharing er ekki eitt skipti sem lagast; eftir því sem ný sites, Teams og skrár verða til þarftu að grípa misconfigurations í fyrirbyggjandi tilgangi. Íhugaðu að nýta reports eða alerts úr Microsoft Purview til að ná hlutum eins og skrám sem eru deilt út fyrir, eða til stórra hópa, nýstofnuðum opinberum teams o.s.frv. Verkfæri Microsoft geta sjálfvirknivætt alerts fyrir þessar aðstæður, svo nýttu þau til að halda sterkri stöðu.

Skref 8: Beittu Sensitivity Labels og DLP Policies

Notaðu Microsoft Purview Sensitivity Labels til að flokka gögn (Confidential, Highly Confidential o.s.frv.) og tengdu þessar labels við verndarstillingar. Til dæmis getur „Confidential" label dulkóðað skrár eða komið í veg fyrir ytra sharing. Stilltu líka Data Loss Prevention (DLP) policies til að koma í veg fyrir eða vakta oversharing á viðkvæmum upplýsingum (eins og að hindra einhvern í að senda lista yfir SSN númer viðskiptavina í tölvupósti). Þessi verkfæri koma ekki aðeins í veg fyrir óviljandi leka í daglegri notkun, þau vinna líka með Copilot: ef Copilot reynir að nálgast eða skila labeled innihaldi á hátt sem hann á ekki að gera getur DLP gripið inn í. Að auki mun Copilot sjálfur bera label skjalsins áfram í svör sín, eins og fjallað er um síðar.

Skref 9: Innleiddu Power Platform governance

Færðu eftirlitið líka yfir á Power Platform (Power Apps, Power Automate o.s.frv.). Skilgreindu DLP policies fyrir Power Platform til að stýra connectors (svo einhver geti ekki t.d. búið til flow sem sækir gögn úr viðkvæmum SharePoint lista og birtir þau á ytri þjónustu). Íhugaðu líka að hafa mörg environments (Dev/Test/Prod) með viðeigandi öryggi, þannig að „Citizen Developers" sem byggja agents eða öpp opinberi ekki gögn óviljandi. Í grunninn, komdu í veg fyrir að Power Platform verði ólöggaður bakdyraaðgangur að gögnunum þínum.

Skref 10: Fræddu og styrktu agent-smiðina þína

Loks skaltu setja upp leiðbeiningar og best practices fyrir þá sem munu byggja eða innleiða AI agents (hvort sem það eru pro developers eða business notendur). Bjóddu upp á þjálfun í öruggri meðhöndlun gagna: t.d. hvernig á að velja viðeigandi knowledge sources fyrir agent, hvers vegna ætti ekki að hafa viðkvæmar skrár í agent sem er deilt víða, hvernig á að prófa úttak agents fyrir óvæntum upplýsingum. Með því að rækta gagnavitaða menningu meðal „agent makers" dregur þú úr líkum á að einhver opinberi upplýsingar óviljandi þegar hann hannar AI lausn.

Heimildir:

• https://techcommunity.microsoft.com/blog/microsoft365copilotblog/from-oversharing-to-optimization-deploying-microsoft-365-copilot-with-confidence/4357963
• https://techcommunity.microsoft.com/blog/microsoft365copilotblog/microsoft-graph-connectors-update-expand-copilot%E2%80%99s-knowledge-with-50-million-ite/4243648

Þegar þú hefur klárað þessi skref getur þú farið áhyggjulaus af stað og byrjað að byggja agents fyrir raunverulegan rekstur. Til að smíða agents höfum við mismunandi palla og eiginleika frá Microsoft sem við getum reitt okkur á. Þú finnur þekktustu dæmin í næsta kafla. Ef þú þarft aðstoð með þennan lista, hafðu samband við okkur og við hjálpum þér með þessa mikilvægu undirbúningsvinnu.

Ekkert kemur í veg fyrir að þú búir á meðan til PoC eða Test-Agents með sample data, handvirkt upphlaðnum skrám eða sérstökum gögnum tengdum í gegnum RAG. En við mælum með þessum skrefum fyrir stærri innleiðingu eða rollout á agents.

Að skilja muninn á agent-pöllum

Skref 1: Skildu agent-creators þína

Eftir undirbúningsvinnuna á gögnunum þurfum við að skilja hvaða pallar eru í boði til að búa til þessa agents. Við reynum að aðgreina þessi verkfæri út frá eiginleikum og möguleikum, en það er mikilvægt að hafa í huga að að búa til agents og velja rétt tooling er svið, ekki bara einn punktur. Það eru margar leiðir til að byggja AI agents í Microsoft ecosystem. Það skiptir máli að velja rétta leið fyrir þínar þarfir og fyrir kunnáttustig teymisins þíns. Það útskýrir líka hvenær á að nýta Azure AI Foundry á móti innbyggðum Copilot Studio verkfærum.

Microsoft býður í dag upp á sett af mismunandi verkfærum sem geta byggt agents. Þótt þau virðist svipuð eru þau smíðuð fyrir mismunandi markhópa og kunnáttustig. Skoðaðu yfirlitið hér að neðan nánar. Þegar við skiljum hverjir þurfa að búa til og viðhalda þessum agents sjáum við líka hvaða knowledge sources (= gögn) við þurfum að undirbúa fyrir agents okkar. Auk verkfæranna í listanum hér að neðan eru til fleiri pro-code lausnir til að byggja agents, eins og M365 Agents Toolkit, Visual Studio Code, Agent SDK og fleiri. Öll skrefin okkar til undirbúnings á gögnum eiga jafnt við þau, þar sem þau sækja í sömu gögn og aðrir agents.

Heimild: https://www.egroup-us.com/news/microsoft-copilot-ai-integration/

Skref 2: Greindu use cases og kröfur fyrir pallinn þinn

Eins og þú getur ímyndað þér styður ekki hver einasti pallur öll use cases. Agents má nota fyrir einföld verkefni, eins og að svara spurningum út frá fyrirliggjandi þekkingu, eða fyrir flókin verkefni, eins og að búa sjálfkrafa til svör eða framkvæma ferla. Að auki skiptir lokaupplifunin (UX), það er hvar og hvernig við viljum nálgast þessa agents, máli þegar við veljum pall.

Með þessi atriði í huga reynum við yfirleitt að nota einföldustu mögulegu lausnina til að byggja Agent-inn okkar. En við þurfum líka að finna lausn sem er skalanleg fyrir áframhaldandi þróun. Þó þarf ekki hver Agent að vera byggður á Agent AI Foundry frá fyrsta degi.

Ábending:

Ef þú ert ekki viss hvar þú átt að byrja að byggja Agent-inn þinn getur þú alltaf notað Copilot Studio, tengt inn frekari gögn frá Azure AI þar og birt hann í Microsoft 365 Copilot. Þannig færðu bæði „up- og downwards compatibility".

RAG (Retrieval-Augumented Generation) vs. SharePoint vs. Upload

Við fyrstu sýn lítur allt út eins og RAG, en það er munur á. Þegar þú kynnir þér Copilot Agents og getu þeirra fyrst er freistandi að álykta að öll knowledge integration fylgi sama RAG (Retrieval-Augmented Generation) mynstri. Þótt þau líti öll út eins og RAG utan frá, að sækja skjöl og búa til svör, þá er hvernig þau vinna undir yfirborðinu verulega mismunandi. Að skilja þennan mun er nauðsynlegt til að velja rétta nálgun út frá markmiðum þínum, umfangi og tæknilegri stöðu. Hér kemur stutt útskýring og yfirlit.

Handvirkar skráaupphleðslur

Handvirk upphleðsla er einfaldasta leiðin til að bæta þekkingu við Copilot agent. Þú dregur og sleppir skjölum beint inn í Copilot Studio viðmótið. Microsoft indexar þessar skrár sjálfkrafa og sækir viðeigandi innihald þegar notandi spyr. Þetta hentar vel fyrir litla pílóta og fyrstu prófanir. Athugaðu líka að innihald skránna ætti að vera aðgengilegt öllum sem hafa aðgang að agent-inum. Það er ekkert Permission-Management hér sem þú þarft að sjá um. Á móti kemur að þú þarft að uppfæra þessar skrár handvirkt til lengri tíma ef eitthvað breytist. Sem stendur getur þú bætt við allt að 20 skrám handvirkt fyrir Copilot Agents.

Heimild: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/copilot-studio-agent-builder-knowledge#file-size-limits

SharePoint Online

Þessi aðferð notar Retrieval API frá Microsoft til að nálgast innihald beint úr SharePoint Online, tengt í gegnum Graph Connector. Agent-inn sækir viðeigandi innihald í rauntíma þegar spurt er og virðir gildandi Microsoft 365 permissions. Innihald getur verið SharePoint sites, document libraries, möppur eða skrár. Þetta er dynamic, öruggt og hentar vel til að skala þvert á deildir eða business units án þess að þú þurfir að reka eigin innviði. Með því að byggja á fyrirliggjandi innviðum notum við innbyggða öryggislíkanið úr SharePoint sem er stór kostur miðað við aðra knowledge möguleika. Deildir geta auðveldlega uppfært skrárnar og það endurspeglast strax í agent-inum. Það þýðir að ef tveir notendur með mismunandi aðgang spyrja agent-inn getur einn fengið svar úr tiltekinni skrá á meðan annar (án aðgangs) myndi ekki fá það, sem er nákvæmlega sú hegðun sem við viljum.

Athugið: SharePoint Lists eru sem stendur ekki studd knowledge-tegund, svo þú getur ekki indexað þær out of the box (Q3 2025).

Custom RAG (Self-Managed)

Í klassískri RAG uppsetningu byggir þú og rekur alla retrieval pípuna sjálfur. Það felur í sér document preprocessing, chunking, embedding, geymslu í vector database og að sækja bestu samsvaranir þegar spurt er. Þetta gefur þér fulla stjórn á því hvernig innihald er unnið og sótt, en færir líka með sér flækjustig og viðhaldskostnað. Það hentar best í flóknari use cases sem krefjast sérsniða umfram það sem stýrðu þjónusturnar frá Microsoft bjóða upp á. Þetta er ekki innbyggður eiginleiki í Copilot eða Copilot Studio; þessa vinnu myndum við vinna í Microsoft Azure.

Dæmi um hvenær RAG á við gæti verið til dæmis ef þú þyrftir að tengja AI agent við sérsniðinn gagnagrunn eða þúsundir PDF-skjala geymdar utan Microsoft 365, og beita sérstökum síum, þá gæti self-managed RAG verið nauðsynlegt, en það krefst verulegrar vinnu.

heimild: https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview?tabs=docs

Hvað á að velja og hvenær

Þótt allar þrjár aðferðirnar snúist um að sækja innihald til að styðja við language generation þá er aðeins custom self-managed lausnin sem uppfyllir „true RAG" í tæknilegum skilningi. Fyrir flest fyrirtæki sem eru að byrja er handvirk upphleðsla eða SharePoint tenging umtalsvert einfaldari og fljótari í innleiðingu. Þær skila sterkum niðurstöðum með lágmarks uppsetningu, og leyfa teymum að einbeita sér að hönnun use cases og innleiðingu í stað innviða.

Almennt ráð frá mér á þessum tímapunkti:

Reyndu að byggja agents eins nálægt gögnunum þínum og hægt er.

Dæmi: Ef gögnin þín eru geymd í stórum SQL gagnagrunnum eða utanaðkomandi CRM kerfum mun SharePoint Agent ekki duga. Ef við höfum alla okkar þekkingu í SharePoint gætu SharePoint Agents eða Copilot Agents verið góð byrjun.

Custom RAG ætti aðeins að íhuga þegar þarfir þínar fara umfram það sem stýrðu valmöguleikarnir bjóða upp á, ekki sem sjálfgefinn upphafspunkt. Handvirk upphleðsla er frábær fyrir fyrsta pílótann eða fyrir litla pílóta með takmarkaða og sértæka þekkingu sem er ekki oft uppfærð. Í mörgum tilvikum myndum við einfaldlega nota SharePoint library eða site með agent-inum. Þess vegna einbeitum við okkur að atburðarás sem lítur svona út:

Microsoft 365 Copilot & Copilot Agents: Öryggi & samræmi út úr kassanum

Öruggir cloud innviðir eru grunnurinn undir enterprise AI. Microsoft býður upp á öruggasta mögulega rammann fyrir Agents okkar með því að setja þá í samhengi Microsoft 365 Copilot. Öll fyrirtæki geta reitt sig á núverandi Security Framework sem byggir á Conditional Access og Multi-Factor authentication fyrir aðgang og núverandi Governance Framework sem byggir á Microsoft Purview.

Agents sem eru notaðir í M365 Copilot eða birtir úr Copilot Studio sem Teams Chatbot eru aðeins aðgengilegir innan tenant boundaries okkar. Það þýðir að við fáum sama öryggisstig fyrir þessi forrit og við höfum nú þegar.

Að auki býður Microsoft upp á nokkrar tæknilegar og skipulagslegar skuldbindingar sem eru teknar saman undir því sem við köllum „Enterprise Grade Data Protection".

Heimild: https://learn.microsoft.com/en-gb/copilot/microsoft-365/microsoft-365-copilot-privacy?azure-portal=true

Microsoft 365 Copilot: Enterprise Data Protection (EDP) fyrir Prompts og Responses

• Samningsbundin vernd: Prompts (input frá notanda) og responses (úttak Copilot) eru varin samkvæmt Data Protection Addendum (DPA) og Product Terms. Þessi vernd er sú sama og gildir um tölvupósta í Exchange og skrár í SharePoint.
• Gagnaöryggi: Dulkóðun í hvíld og í flutningi, líkamleg öryggisstýring, gagnaeinangrun á tenant-stigi
• Persónuverndarskuldbindingar Microsoft starfar sem data processor og notar gögn eingöngu samkvæmt fyrirmælum viðskiptavinar. Styður GDPR, EU Data Boundary, ISO/IEC 27018 og fleira.
• Aðgangsstýring og erfðir stefnu: Copilot virðir: identity models og heimildir, sensitivity labels, retention policies, audit settings, admin configurations, AI & Copyright Risk Mitigation og vernd gegn: prompt injection, skaðlegu innihaldi, höfundarréttarmálum (með protected material detection og Customer Copyright Commitment)
• Engin þjálfun líkana: Prompts, responses og Microsoft Graph gögn eru EKKI notuð til að þjálfa foundation models.

Copilot Agents með SharePoint Online-þekkingu:

• Permission og Sharing Model: Agents með SharePoint Online aðgang virða alltaf heimildir tengdrar SharePoint site. Það þýðir að annars vegar þarftu að tryggja að allir sem eiga að hafa aðgang hafi að minnsta kosti read permissions á síðunni; hins vegar þarftu að vera vakandi fyrir því að veita ekki óþarfa heimildir sem gætu opnað viðkvæmar upplýsingar fyrir óheimiluðum notendum. Rétt uppsetning heimilda er nauðsynleg, því Copilot Agents munu aðeins geta nálgast og birt innihald sem sá notandi sem spyr hefur leyfi til að sjá. Að auki tryggir notkun Microsoft Purview information protection að sensitivity labels og data loss prevention (DLP) policies fylgi innihaldinu áfram.
• Þrálátir Labels og DLP: Virkjaðu Microsoft Purview information protection þannig að sensitivity labels haldist með innihaldinu. Copilot agents erfa labels af upprunaskjölum. Það þýðir að ef skrá er flokkuð sem „Confidential" mun hvert AI-búið innihald eða skjal héðan í frá bera þá label áfram. Þessi þráláta erfðir label vinnur saman við Data Loss Prevention policies til að koma í veg fyrir að AI opinberi óviljandi varin gögn. Í reynd þýðir það að jafnvel þótt Copilot taki saman viðkvæma skrá verður sú samantekt líka meðhöndluð sem viðkvæm. Þetta er atriði sem er einstakt og við sjáum ekki utan Microsoft 365, og við munum ekki sjá AI Agent sem getur samþætt jafn djúpt í Microsoft 365 ecosystem á þennan hátt.

Best Practices til að undirbúa SharePoint Online fyrir agent-notkun

Til að undirbúa SharePoint Online fyrir árangursríka notkun með Copilot Agents skaltu fylgja þessum best practices:

Sérstök SharePoint Site

Byrjaðu á að búa til sérstaka SharePoint site eða tiltekna möppu sem er eingöngu ætluð fyrir knowledge base Copilot Agent-sins þíns. Þessi nálgun hjálpar við að lágmarka vandamál tengd oversharing og dregur úr áhættu á að notendur hlaði óvart upp viðkvæmum eða óviðkomandi skrám í repository-ið sem agent-inn hefur aðgang að. Ef þú ákveður að nota fyrirliggjandi SharePoint site skaltu fara vandlega yfir innihald hennar til að tryggja að þar séu engar trúnaðar- eða viðkvæmar upplýsingar sem agent-inn ætti ekki að geta fundið.

Að veita aðgang

Það er líka mikilvægt að tryggja að allir ætlaðir notendur hafi nauðsynlegar read permissions til að nálgast site-una eða möppuna. Ef þú þarft að veita aðgang handvirkt skaltu tryggja að allir ætlaðir notendur hafi read access á site-una (til dæmis með því að bæta þeim í Visitors group SharePoint site-arinnar eða viðeigandi Azure AD security group) til að einfalda ferlið og koma í veg fyrir óviljandi misconfigurations á heimildum.

Undirbúðu skrár

Þegar þú undirbýrð skjöl til notkunar með Copilot Agents skaltu muna að AI getur eins og er ekki túlkað innfelldar myndir í skrám. Því ættir þú að bæta við lýsandi myndatextum eða alternative text til að tryggja að mikilvægar sjónrænar upplýsingar tapist ekki. Fyrir texta-þung skjöl skaltu tryggja að þegar innihald er tekið saman eða vísað í það sé heildarumfangið að hámarki 1,5 milljón orð eða 300 síður svo Copilot virki á áhrifaríkan hátt.

Fyrir Excel skrár skaltu skipuleggja gögnin þannig að hver skrá einbeiti sér annaðhvort að tölum eða texta, því töflur með blönduðu innihaldi skila yfirleitt ónákvæmari niðurstöðum. Agents svara líka fyrirspurnum áreiðanlegast þegar viðeigandi gögn eru öll á einu sheet í workbook-inu.

Agents svara best Excel gögnum þegar þau eru öll á einu sheet.

Dæmi: Ef þú ert með stóra könnun um viðskiptavinaviðbrögð geymda í einni Excel skrá skaltu aðskilja megindleg gögn (eins og einkunnir og tölulega svör) frá eigindlegum gögnum (eins og frjálsum textaviðbrögðum) yfir á tvö mismunandi sheet. Þessi aðferð leyfir þér að nota verkfæri eins og Python og Excel formúlur til að greina tölulegu gögnin á skilvirkan hátt (t.d. reikna meðaltöl, raða niðurstöðum, meta öryggisbil), á meðan þú nýtir sentiment analysis eiginleika M365 Copilot til að fá innsýn úr texta-svörunum.

Takmörk á skrám

Loks skaltu vera meðvituð um þær skráargerðir og stærðartakmarkanir sem Copilot Agents og Copilot Studio styðja. Eftirfarandi tafla dregur saman núverandi stuðning:https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/copilot-studio-agent-builder-knowledge#file-size-limits

Kynntu þér einnig best practices sem Microsoft hefur birt um lengd skjala: https://support.microsoft.com/en-gb/topic/keep-it-short-and-sweet-a-guide-on-the-length-of-documents-that-you-provide-to-copilot-66de2ffd-deb2-4f0c-8984-098316104389

Skráargerðir sem eru sem stendur ekki studdar í SharePoint Online: Formlega er allt annað sem er ekki á listanum ekki opinberlega stutt.

Ákveðnar skráargerðir, eins og CSV skrár, geta virkað nægilega vel þótt þær séu ekki formlega studdar, því þær líkjast mjög plain text sniði. Hins vegar eru flestar aðrar skráargerðir, sérstaklega container skrár eins og CAB, EXE, ZIP, sem og myndir, myndbönd og hljóðsnið eins og PNG, IMG, MP3 og MP4, ekki studdar sem stendur.

Samantekt

Með því að fylgja þessum ráðleggingum getur þú tryggt að Copilot Agents þínir hafi aðgang að vel skipulögðum, öruggum og hágæða gögnum, hámarkað nytsemi þeirra og lágmarkað áhættu á óviljandi opinberun gagna. Að fjárfesta tíma í undirbúningi SharePoint umhverfisins þíns leggur sterkan foundation fyrir árangursríka innleiðingu og upptöku AI agents innan fyrirtækisins.

Í raun byrja mörg „Build-an-Agent" verkefni okkar einmitt þar. Ekki á að byggja agent-inn, heldur á að undirbúa innviðina og þekkinguna svo við höfum gögn í góðum gæðum til að nota fyrir AI, því Agent er aðeins jafn góður og kerfið undir honum.