Röviden:

  • A hatékony SharePoint-alapú RAG pipeline kiindulópontja az indexelt Azure AI Search megoldás, amely gyors és jogosultságtudatos eredményeket ad.
  • A sikerhez fontos a megfelelő chunking, a permission-modell folyamatos finomhangolása, és a rendszeres mérés, különösen a groundedness és a felhasználói elégedettség növelése érdekében.

A legjobb kiindulópont egy webhelyszintű, előre indexelt Azure AI Search alapú pipeline, permission-aware lekérdezéssel. Ez adja a leggyorsabb, mérhető eredményt anélkül, hogy a jogosultságkezelés vagy a frissesség azonnal bonyolult kompromisszumokat kényszerítene.

Mielőtt belevágnál a részletekbe, három dolog, amit érdemes fejben tartani:

  • Ajánlott pilotméret: egy közepes nagyságú dokumentumállomány webhelyenként; ennél kisebb mintán a chunking-tuning nem ad megbízható visszajelzést, ennél nagyobbon a jogosultsági rések hamar elrejtőznek.
  • Miért indexelt megközelítés? Jobb válaszidő, teljes kontroll a chunk metaadatok és a keresési relevancia felett, és a pilot alatt mérhetően javuló groundedness-mutató.
  • Iterálj, ne tökéletesíts: az első két hétben a chunking és a permission-modell finomhangolása fontosabb, mint a modellcsere.

A RAG (Retrieval-Augmented Generation) kifejezés a visszakereséssel kiegészített szöveggenerálást jelöli: a rendszer először releváns dokumentumrészleteket keres, majd ezek alapján generál választ. SharePoint-környezetben ez azt jelenti, hogy a vállalati tudásbázis dokumentumai valóban elérhetővé válnak egy AI-asszisztens számára, a jogosultságok és a tartalom frissessége megőrzésével.

Tartalomjegyzék

Hogyan épül fel egy SharePoint RAG pipeline rétegről rétegre?

A pipeline hat egymásra épülő rétegből áll. Mindegyik réteg meghibásodása a felette lévőket is érinti, ezért az architektúra megértése nem opcionális.

Réteg Komponens Fő feladat
Forrás Microsoft SharePoint Dokumentumok, könyvtárak, metaadatok tárolása
Beolvasás (ingestion) Microsoft Graph API / SharePoint REST / Logic Apps Fájlok és metaadatok kinyerése, változáskövetés
Feldolgozás Azure Document Intelligence, OCR Szöveg kinyerése, chunking, metaadat-gazdagítás
Embedding és vektortár Azure OpenAI embeddings, Azure AI Search, pgvector Vektoros reprezentáció és indexelés
Retrieval Azure AI Search, Copilot Retrieval API Releváns chunkök visszakeresése, permission-szűrés
Generálás Azure OpenAI GPT-modell Kontextus alapú válasz előállítása, forráscitáció
Felhasználói alkalmazás Teams bot, webalkalmazás, API Végfelhasználói interfész, feedback-gyűjtés

Infografika, amely szemléletesen, függőleges elrendezésben mutatja be a SharePoint RAG folyamat főbb rétegeit.

Az architekturális gyakorlatok szerint a pipeline sikere az ingestion és a retrieval rétegeken múlik. A modellcsere viszonylag egyszerű, de egy rosszul tervezett chunking-stratégia vagy hiányos permission-modell az egész rendszert megbízhatatlanná teszi.

Skálázhatóság és monitoring. Már a pilot fázisban érdemes bevezetni egy alapszintű megfigyelési réteget: lekérdezési latencia, indexelési hibák és chunk-szintű relevancia-visszajelzés. Ezek nélkül a tuning vak kísérletezéssé válik. A hibakezelés szempontjából a leggyakoribb problémák a throttling a Graph API-nál, az OCR-hibák scannelt dokumentumoknál és a jogosultsági rések, amelyek csak éles tesztelésnél derülnek ki.

Közelről látható a SharePoint RAG rendszer felügyeletének hardveres kialakítása.

Hogyan csatlakoztasd a SharePoint-ot a pipeline-hoz?

Négy fő csatlakozási minta létezik, és a választás a frissességi igénytől, a csapat képességeitől és a licenckörnyezettől függ.

Microsoft Graph delta API a legmegbízhatóbb megközelítés inkrementális szinkronizáláshoz. A /sites/{siteId}/drive/root/delta endpoint visszaadja az utolsó szinkronizálás óta megváltozott fájlokat, beleértve az áthelyezéseket és törléseket is. Az Azure GPT-RAG projekt SharePoint connectorja erre épít: intelligens freshness-ellenőrzéssel, chunk ID-kkal és beállítható párhuzamossággal dolgozik.

Egy alap Graph hívás fájlok listázásához:

const { Client } = require('@microsoft/microsoft-graph-client');

const client = Client.initWithMiddleware({ authProvider });
const result = await client
  .api(`/sites/${siteId}/drive/root/children`)
  .select('id,name,lastModifiedDateTime,webUrl,file')
  .get();

SharePoint REST API régebbi környezetekben vagy specifikus lista-adatoknál hasznos, de a Graph API-t érdemes preferálni az egységes hitelesítési modell miatt.

Azure Logic Apps / Power Automate alacsony kódigényű megközelítés: a SharePoint-connector triggereli az ingestion-folyamatot fájlmódosításkor. Kisebb pilotoknál gyors beindítást tesz lehetővé, de a finomhangolhatóság korlátozott.

A csatlakozási opciók összehasonlítása:

  • Dedikált indexer (Azure GPT-RAG): — előre épített SharePoint-integráció, chunk ID-kezelés és párhuzamos feldolgozás; ajánlott, ha az Azure-ökoszisztémán belül maradsz.

Hitelesítés és jogosultságok. Az app registration során válaszd az alkalmazás-szintű (client credentials) hitelesítést szerver-oldali pipeline-hoz, delegált hitelesítést (on-behalf-of) pedig akkor, ha a felhasználói kontextust a lekérdezésig meg kell őrizni. A Microsoft Entra (korábban Azure AD) csoporttagságokat már az ingestion fázisban érdemes a chunk metaadatokhoz rendelni, nem utólag. A rate-limit hibákat exponenciális visszalépéssel (exponential backoff) kezeld: a 429-es válaszoknál a Retry-After fejléc értékét használd várakozási időként.

Indexelt tudásbázis vagy távoli lekérdezés: melyiket válaszd?

A SharePoint dokumentumok RAG-rendszerekbe történő integrációja két fő megközelítést használ: előre indexelt Azure AI Search és távoli lekérdezés a Copilot Retrieval API-n keresztül.

Szempont Indexelt (Azure AI Search) Távoli (Copilot Retrieval API)
Lekérdezési latencia Alacsony (előre indexelt) Magasabb (valós idejű SharePoint-hívás)
Tartalom frissessége Szinkronizálástól függ Valós idejű
Jogosultságkezelés Manuális permission-szűrés szükséges Automatikus, SharePoint-natív
Chunk-kontroll Teljes Nincs
Implementációs komplexitás Közepes–magas Alacsony
Licenckövetelmény Azure AI Search Copilot licenc szükséges lehet
Költség Index tárolás + lekérdezés Copilot API-hívás díja

A távoli SharePoint tudásbázis a Copilot Retrieval API-t használja, és lekérdezés időben érvényesíti a SharePoint jogosultságokat és Purview-címkéket; nincs szükség előzetes indexelésre. Ez vonzó egyszerűsége miatt, de a magasabb latencia és a Copilot-licencfüggőség valós korlátok.

Az indexelt megközelítésnél egy kritikus beállítás: az includeReferenceSourceData: true paraméter szükséges ahhoz, hogy a generált válaszokban a forrásdokumentum URL-je megjelenjen. Enélkül a felhasználó nem tudja ellenőrizni, honnan származik az információ, ami vállalati környezetben elfogadhatatlan.

Mikor melyiket? Ha a csapatnak nincs Copilot-licence, vagy ha a chunking és keresési relevancia finomhangolása prioritás, az indexelt megközelítés a jobb választás. Ha a jogosultságkezelés komplexitása a fő kockázat és a latencia elfogadható, a távoli megközelítés gyorsabb beindítást ad.

Hogyan dolgozd fel a SharePoint dokumentumokat hatékonyan?

A dokumentumfeldolgozás az a pont, ahol a legtöbb pilot megbotlik. Nem a modell, hanem a rossz chunking okozza az irreleváns válaszokat.

Formátumok és OCR:

  • .docx, .pptx: natív szövegkinyerés az Azure Document Intelligence-szel, a stílusok és fejlécek megőrzésével.
  • .pdf: ha digitálisan létrehozott, szövegkinyerés elegendő; scannelt PDF-eknél OCR szükséges, és az Azure Document Intelligence Layout modellje adja a legjobb eredményt táblázatoknál és többhasábos elrendezéseknél.
  • .aspx (SharePoint oldalak): a HTML-ből érdemes kiszűrni a navigációs elemeket és a boilerplate-tartalmat, csak a fő tartalmi zónát megtartva.

Chunking szabályok:

  • Fejezet- és címsoralapú chunking az elsődleges stratégia: egy chunk egy logikai egységet fedjen le, ne egy fix karakterszámot.
  • Az 1 000–1 500 token alapérték jó kiindulópont, de az optimum az embedding modell és a vektortár konfigurációjától függ; a pilotban mindkét végét teszteld.
  • Táblázatokat és listákat ne vágj szét: egy táblázat egy chunk, még ha ez meghaladja az alapértéket.
  • Átfedő (overlapping) chunking 10–15%-os átfedéssel csökkenti a kontextusvesztést a határon.

Metaadatok, amelyeket minden chunkhoz érdemes tárolni:

  • Forrásút és webhely URL
  • Könyvtár és fájlnév
  • Szerző és lastModifiedDateTime
  • Section heading lineage (az összes szülőcím a gyökértől a chunkig)
  • Azure AD csoportazonosítók (permission-aware retrieval-hoz)
  • Tartalom-hash (deduplikációhoz)

Profi tipp: A tartalom-hash (pl. SHA-256 a chunk szövegéből) tárolása lehetővé teszi, hogy dokumentummozgatásnál ne indexeld újra a tartalmat, csak a metaadatokat frissítsd. Ez különösen hasznos, ha a felhasználók rendszeresen átszervezik a SharePoint-könyvtárakat.

A deduplikáció a hash alapján működik: ha egy fájl tartalma nem változott, csak az útvonala, a chunk szövegét nem kell újra embeddingolni, csak a metaadatokat kell frissíteni a vektortárban.

Melyik embedding modellt és vektortárat válaszd?

Az embedding modell és a vektortár választása hosszú távú döntés: a pipeline többi részénél nehezebb cserélni, mert az összes vektort újra kell generálni.

Embedding modellek. Az Azure OpenAI text-embedding-3-large modell jelenleg a legjobb pontosságot adja angol és vegyes nyelvű vállalati tartalmakhoz. A text-embedding-3-small olcsóbb és gyorsabb, de a relevancia-különbség érezhető hosszabb dokumentumoknál. Nyílt modellek (pl. multilingual-e5-large) helyi üzemeltetésnél jönnek szóba, ha az adatvédelmi követelmények nem engedik a tartalom külső API-ra küldését.

Vektortárak:

  • Azure AI Search — az ajánlott választás Azure-natív pipeline-hoz: beépített hibrid keresés (vektoros + full-text BM25), permission-szűrés metaadat-alapon és közvetlen integráció az Azure OpenAI-jal.

Magyarországi üzemeltetési szempontok. Ha a tartalom személyes adatokat vagy üzleti titkot tartalmaz, az adatrezidencia kérdése kritikus: az Azure West Europe (Amszterdam) és North Europe (Dublin) régiók EU-s adatkezelést biztosítanak, de a GDPR-megfelelőség a szerződéses kontrollokat is megköveteli. Helyi üzemeltetésnél a pgvector vagy Qdrant on-premises telepítése csökkenti a külső adatátvitelt, de növeli az üzemeltetési komplexitást.

Az operációs checklist: rendszeres backup a vektortárból, reindex-stratégia modellváltáskor (az összes vektor újragenerálása szükséges), és hibrid keresés bekapcsolása az Azure AI Search-ben a ritka kulcsszavak jobb lefedéséhez.

Hogyan tartsd szinkronban a SharePoint-ot és az indexet?

A szinkronizálás az a terület, ahol a legtöbb implementáció alulbecsüli a komplexitást. Egy dokumentum átnevezése, áthelyezése vagy törlése mind külön kezelést igényel.

Szinkronizálási minták:

  • Delta endpoint (Graph API): a /delta hívás visszaadja az összes változást az utolsó deltaLink token óta. Ez a legmegbízhatóbb módszer, mert a SharePoint maga követi a változásokat, nem a pipeline.
  • Webhook alapú push: a SharePoint értesíti a pipeline-t változáskor; azonnali frissítést ad, de a webhook-előfizetések lejárnak (max. 6 hónap), és megújításuk automatizálást igényel.
  • Ütemezett batch indexelés: egyszerűbb, de a frissesség a batch-intervallumtól függ. Napi batch elfogadható, ha a tartalom nem változik percenként.

Intelligens inkrementális frissítés. A delta endpoint és a lastModifiedDateTime alapú intelligens inkrementális frissítés megakadályozza a felesleges újraindexelést. A gyakorlatban 1 másodperces tolerancia használata csökkenti a race condition jelenségeket: ha a tárolt és a SharePoint-bélyegző közötti különbség kisebb, mint 1 másodperc, a chunk nem kerül újraindexelésre.

Fájlmozgatás és törlés kezelése:

  • Áthelyezésnél a Graph delta API deleted és file mezőit vizsgáld: az új id azonos marad, de a parentReference változik.
  • Törléskor a chunk-okat a vektortárból is törölni kell; a chunk ID-k tárolása (forrásút + fájl ID + chunk sorszám hash) teszi ezt megbízhatóvá.
  • Átnevezésnél csak a metaadatokat kell frissíteni, ha a tartalom-hash nem változott.

Webhook vs batch: valós idejű frissítési igénynél (pl. jogi dokumentumok, szerződések) a webhook a jobb választás. Nagyobb dokumentumkönyvtáraknál, ahol a throughput fontosabb, a napi batch olcsóbb és egyszerűbben monitorozható.

Hogyan illeszd a retrieval-t a prompt pipeline-ba?

A retrieval és a prompt-összeállítás közötti illesztés határozza meg, hogy a felhasználó hasznos, idézhető választ kap-e, vagy egy magabiztosan téves állítást.

Retrieval scoring. Az Azure AI Search hibrid keresése vektoros hasonlóságot és full-text BM25 pontszámot kombinál. A reciprocal rank fusion (RRF) a két lista rangsorait összevonja: az RRF-pontszám 1/(k + rank) alakú, ahol k általában 60. Ez a módszer robusztusabb, mint a nyers vektoros hasonlóság, különösen rövidebb lekérdezéseknél.

Prompt-összeállítás. A bevált minta: a top-N chunk (általában 5–10) szövegét és metaadatait a rendszer-promptba illeszted, majd a felhasználói kérdést utána. A cite-inline technika azt jelenti, hogy minden chunkhoz egy [Forrás: {webUrl}] jelölőt adsz, és az LLM-et utasítod, hogy a válaszban hivatkozzon rájuk. Az includeReferenceSourceData: true beállítás az Azure AI Search oldalán gondoskodik arról, hogy a forrás URL-je visszakerüljön a retrieval válaszba.

Egy egyszerű prompt sablon:

Rendszer: Az alábbi dokumentumrészletek alapján válaszolj a kérdésre.
Minden állítást jelölj meg a forrás URL-jével [Forrás: URL].
Ha a válasz nem található a dokumentumokban, jelezd ezt.

Dokumentumok:
{chunks_with_sources}

Kérdés: {user_query}

Latencia és tokenköltség. A top-N limit kritikus: 10 chunknál több ritkán javít a válásminőségen, de jelentősen növeli a tokenköltséget. Reranking után (pl. cross-encoder modellel) csak a top-3–5 chunk kerüljön a modellhez. A chunk mérete és a modell kontextusablaka közötti egyensúly: GPT-4o esetén 128k token kontextus elegendő teret ad, de a tokenköltség lineárisan nő.

Hogyan tervezd meg és mérd a pilotot?

Egy jól tervezett pilot 4–8 hét alatt megbízható döntési alapot ad a skálázáshoz. A kulcs a mérhető metrikák előzetes definiálása.

  1. Scope meghatározása: egy SharePoint webhely, 500–2 000 dokumentum, egy jól körülhatárolt felhasználói csoport (pl. egy részleg).
  2. Baseline mérés: rögzítsd a jelenlegi SharePoint-keresés teljesítményét ugyanazon kérdéskészleten; ez lesz az összehasonlítási alap.
  3. Ingestion és chunking beállítása: az első héten az ingestion pipeline és a chunking-stratégia finomhangolása a prioritás.
  4. Retrieval tuning: a második héten a keresési relevancia mérése és a hibrid keresési súlyok beállítása.
  5. Felhasználói tesztelés: a harmadik–negyedik héten a célcsoport teszteli a rendszert előre definiált kérdésekkel és szabad kérdésekkel egyaránt.
  6. Iteráció: a visszajelzések alapján chunking- és retrieval-módosítások, majd újabb mérési kör.
  7. Skálázási döntés: a pilot végén a metrikák alapján döntés a kiterjesztésről.

Metrikák, amelyeket követni érdemes:

  • Retrieval latencia: a lekérdezéstől a válasz megjelenéséig eltelt idő, amely optimálisan alacsony, a gyors felhasználói élmény biztosításához.
  • Groundedness: az idézett forrásokra visszavezethető állítások aránya a válaszban.
  • Relevancia (CTR on citations): a felhasználók hány százaléka kattint a forrásokra, jelezve, hogy a citáció hasznos volt.
  • Hibaarány: sikertelen lekérdezések, üres válaszok, jogosultsági hibák aránya.
  • Felhasználói elégedettség: egyszerű 1–5 skálás visszajelzés vagy NPS a tesztelő csoporttól.

A baseline összehasonlítás a legfontosabb: ha a RAG-rendszer nem teljesít szignifikánsan jobban a jelenlegi SharePoint-keresésnél a felhasználói elégedettségben és a groundedness-ben, a chunking vagy a retrieval tuning szorul javításra, nem a modell.

Hogyan kezeld a biztonságot és a megfelelőséget a pipeline-ban?

A permission-aware retrieval nem opcionális vállalati környezetben. Egy jogosultsági rés azt jelenti, hogy egy felhasználó olyan dokumentumból kap választ, amelyhez nincs hozzáférése, és ezt a rendszer nem jelzi.

Permission-aware retrieval megvalósítása. A permission-aware retrieval minta implementálása dokumentum-szintű hozzáférés-filterezéssel történik, ahol a lekérdezéskor a felhasználó Entra/Azure AD csoporttagságait használjuk filterként. A gyakorlatban ez azt jelenti, hogy minden chunkhoz tároljuk az engedélyezett Azure AD csoportazonosítókat, majd lekérdezéskor a felhasználó aktuális csoporttagságát lekérdezzük a Microsoft Graph-ból, és ezt WHERE feltételként alkalmazzuk a vektoros keresésnél.

Purview és bizalmassági címkék. Ha a szervezet Microsoft Purview-t használ, a dokumentumok bizalmassági címkéit (pl. Confidential, Highly Confidential) az ingestion során kell kinyerni és a chunk metaadatokhoz rendelni. A pipeline-nak tudnia kell, hogy bizonyos bizalmassági szintű tartalmakat kizárjon a retrieval-ből, vagy csak meghatározott felhasználói csoportoknak adjon vissza.

GDPR-szempontok magyarországi környezetben. Az adatminimalizálás elvét a pipeline-ra is alkalmazni kell: csak azokat a mezőket tárold a vektortárban, amelyek a retrieval-hez szükségesek. Az audit logok kötelezők: minden lekérdezést, a visszaadott chunkök forrásait és a felhasználói azonosítót naplózni kell. A harmadik féltől származó AI-szolgáltatásokkal (Azure OpenAI) szemben adatfeldolgozási szerződés (DPA) szükséges, és ellenőrizni kell, hogy a tartalom nem kerül modelltraining adatként felhasználásra. Az AI compliance kérdése különösen érzékeny, ha a SharePoint-könyvtárak személyes adatokat (HR-dokumentumok, szerződések) tartalmaznak.

Üzemeltetési javaslatok:

  • Hozzáférési tokeneket ne tárold hosszabb ideig, mint szükséges; az on-behalf-of flow esetén a token élettartama legyen a minimálisan szükséges.
  • Rendszeres jogosultsági felülvizsgálat: ha egy felhasználó csoporttagsága megváltozik a SharePoint-ban, a pipeline-nak ezt a következő lekérdezésnél már tükröznie kell.
  • A vektortárban tárolt chunk metaadatokat ugyanolyan hozzáférési kontrollal védd, mint magát a SharePoint-könyvtárat.

Node.js walkthrough: fetch, chunk, embed, retrieve, generate

Ez a walkthrough egy minimális, de futtatható folyamatot mutat be. A cél nem a production-ready kód, hanem az, hogy az alapfolyam gyorsan kipróbálható legyen.

  1. Környezeti változók és konfiguráció
// .env
AZURE_TENANT_ID=...
AZURE_CLIENT_ID=...
AZURE_CLIENT_SECRET=...
SHAREPOINT_SITE_ID=...
AZURE_OPENAI_ENDPOINT=...
AZURE_OPENAI_EMBEDDING_DEPLOYMENT=text-embedding-3-small
AZURE_SEARCH_ENDPOINT=...
AZURE_SEARCH_INDEX=sharepoint-rag-pilot
AZURE_SEARCH_KEY=...
OPENAI_CHAT_DEPLOYMENT=gpt-4o
  1. Fájl letöltése és szövegkinyerés
const { Client } = require('@microsoft/microsoft-graph-client');
const { DocumentAnalysisClient, AzureKeyCredential } = require('@azure/ai-form-recognizer');

async function fetchAndExtract(fileId) {
  // Graph-on keresztül letöltés
  const stream = await graphClient
    .api(`/sites/${process.env.SHAREPOINT_SITE_ID}/drive/items/${fileId}/content`)
    .getStream();

  // Azure Document Intelligence feldolgozás
  const docClient = new DocumentAnalysisClient(
    process.env.AZURE_DOC_INTEL_ENDPOINT,
    new AzureKeyCredential(process.env.AZURE_DOC_INTEL_KEY)
  );
  const poller = await docClient.beginAnalyzeDocument('prebuilt-layout', stream);
  const result = await poller.pollUntilDone();
  return result.content; // teljes szöveg
}
  1. Chunking és metaadat-mentés
function chunkText(text, metadata, maxTokens = 1200) {
  const paragraphs = text.split(/
{2,}/);
  const chunks = [];
  let current = '';

  for (const para of paragraphs) {
    if ((current + para).length > maxTokens * 4) { // ~4 karakter/token
      if (current) chunks.push({ text: current.trim(), ...metadata });
      current = para;
    } else {
      current += '

' + para;
    }
  }
  if (current) chunks.push({ text: current.trim(), ...metadata });
  return chunks;
}
  1. Embedding és feltöltés Azure AI Search-be
const { OpenAIClient } = require('@azure/openai');
const { SearchClient, SearchIndexClient } = require('@azure/search-documents');

async function embedAndIndex(chunks) {
  const openai = new OpenAIClient(process.env.AZURE_OPENAI_ENDPOINT, ...);
  const searchClient = new SearchClient(process.env.AZURE_SEARCH_ENDPOINT,
    process.env.AZURE_SEARCH_INDEX, ...);

  for (const chunk of chunks) {
    const embeddingResult = await openai.getEmbeddings(
      process.env.AZURE_OPENAI_EMBEDDING_DEPLOYMENT,
      [chunk.text]
    );
    await searchClient.uploadDocuments([{
      id: chunk.chunkId,
      content: chunk.text,
      contentVector: embeddingResult.data[0].embedding,
      sourceUrl: chunk.webUrl,
      allowedGroups: chunk.allowedGroups,
      lastModified: chunk.lastModifiedDateTime
    }]);
  }
}
  1. Retrieve és generate
async function retrieveAndGenerate(userQuery, userGroups) {
  // Vektoros keresés permission-szűréssel
  const queryEmbedding = await getEmbedding(userQuery);
  const results = await searchClient.search(userQuery, {
    vectorSearchOptions: {
      queries: [{ vector: queryEmbedding, fields: ['contentVector'], kNearestNeighborsCount: 10 }]
    },
    filter: `allowedGroups/any(g: search.in(g, '${userGroups.join(',')}'))`,
    top: 5,
    select: ['content', 'sourceUrl']
  });

  // Prompt összeállítás
  let context = '';
  for await (const result of results.results) {
    context += `[Forrás: ${result.document.sourceUrl}]
${result.document.content}

`;
  }

  const response = await openaiClient.getChatCompletions(
    process.env.OPENAI_CHAT_DEPLOYMENT,
    [
      { role: 'system', content: `Válaszolj az alábbi dokumentumok alapján. Minden állítást jelölj meg forrással.

${context}` },
      { role: 'user', content: userQuery }
    ]
  );
  return response.choices[0].message.content;
}
  1. Smoke test és debug tippek

Lokális futtatáshoz: node index.js után tesztelj néhány ismert kérdéssel, amelyekre tudod a helyes választ. A leggyakoribb hibák:

  • 401 Unauthorized: ellenőrizd az app registration jogosultságait (Sites.Read.All és Files.Read.All szükséges).
  • 429 Too Many Requests: adj hozzá exponenciális backoff-ot a Graph-hívásokhoz.
  • Üres retrieval eredmény: ellenőrizd a permission-szűrőt; ha a allowedGroups mező üres a chunkban, a szűrő kizárja.
  • Irreleváns válasz: a chunking méretét csökkentsd, és ellenőrizd, hogy a section heading lineage benne van-e a chunk szövegében.

Mik a következő lépések a pilot után?

Három azonnali teendő, amellyel a legtöbb csapat el tudja indítani a pilotot:

  1. Scope definiálása: válassz egy SharePoint webhelyet, ahol a tartalom jól körülhatárolt és a felhasználói igény egyértelmű. Egy HR-tudásbázis vagy egy projekt-dokumentumtár jó kiindulópont.
  2. Pilot beállítása: az ingestion pipeline és a permission-modell felállítása az első két hét feladata; a chunking-stratégia finomhangolása a harmadik–negyedik héten kezdődik.
  3. Mérés és iteráció: a groundedness és a felhasználói elégedettség mérése után döntsd el, hogy a chunking, a retrieval tuning vagy a permission-modell szorul-e javításra, mielőtt skálázol.

Ha a governance, az üzemeltetés vagy a skálázás kérdései merülnek fel, érdemes konzultációt kérni: a jogosultsági modell és a GDPR-megfelelőség azok a területek, ahol egy külső szem a legtöbb értéket adja. Kezdj kicsiben, és ne próbálj egyszerre több SharePoint-webhelyet integrálni: a chunking és a jogosultságok finomhangolása webhelyenként eltérő lehet.

Fő tanulságok

A SharePoint RAG pipeline sikerének alapja az ingestion és a retrieval réteg gondos tervezése, mert a modell könnyen cserélhető, de egy rosszul épített pipeline nem.

Pont Részletek
Indulj webhelyszinten Egy webhely, 500–2 000 dokumentum, egy felhasználói csoport: ez adja a leggyorsabb, kockázatmentes pilotot.
Permission-modell az első naptól Az Azure AD csoportazonosítókat az ingestion során rendeld a chunkokhoz, ne utólag.
Chunking fontosabb, mint a modell Az 1 000–1 500 tokenes, fejezet-alapú chunking és a tartalom-hash deduplikáció a retrieval relevancia alapja.
Mérj, mielőtt skálázol Groundedness, retrieval latencia és felhasználói elégedettség: ezek döntik el, hogy érdemes-e kiterjeszteni a rendszert.
Stratify a pilot tervezésétől a termelésig Stratify a pilot tervezésétől az ingestion-implementáción és a compliance-tanácsadáson át a skálázási tervekig végigkíséri a bevezetést.

Amit a legtöbb implementáció elsőre elront

A SharePoint RAG bevezetéseknél visszatérően ugyanazok a hibák okozzák a legtöbb problémát, és ezek szinte soha nem a modellel kapcsolatosak.

A leggyakoribb csapda a jogosultsági rések figyelmen kívül hagyása. Fejlesztői környezetben, ahol mindenki adminisztrátor, a permission-szűrő hibátlanul működik. Éles környezetben, ahol a felhasználók különböző csoportokhoz tartoznak és a SharePoint-könyvtárak jogosultságai öröklődnek, a rések csak akkor derülnek ki, amikor egy felhasználó olyan információhoz fér hozzá, amelyhez nem kellene. Ez nem technikai hiba, hanem tervezési hiányosság: a permission-modellt az ingestion fázisban kell felépíteni, nem utólag hozzáadni.

A második visszatérő hiba a túl korai modelloptimalizáció. Sok csapat az első gyenge eredmények után azonnal modellt vált vagy finomhangolja a promptot, miközben a valódi probléma a chunking vagy a metaadatok hiánya. Egy egyszerű teszt: ha a releváns chunk benne van az indexben, de a retrieval nem adja vissza, a keresési súlyok vagy a szűrők a hibásak. Ha a chunk nincs benne, a chunking-stratégia szorul javításra.

A harmadik hiba a hiányzó monitoring. Egy SharePoint RAG rendszer nem statikus: a dokumentumok változnak, a jogosultságok módosulnak, és a felhasználói kérdések idővel eltolódnak. Monitoring nélkül a minőségromlás észrevétlen marad, amíg valaki panaszt nem tesz. Érdemes már a pilot fázisban bevezetni egy egyszerű visszajelzési mechanizmust (pl. „hasznos volt ez a válasz?“ gomb), és a lekérdezési logokat rendszeresen átnézni.

Magyarországi környezetben egy operatív szempont különösen fontos: a security és a legal csapat bevonása nem a projekt végén, hanem az architektúra tervezésekor szükséges. A GDPR-megfelelőség és a belső adatvédelmi szabályzatok utólagos beillesztése drágább és kockázatosabb, mint az előzetes tervezés.

Hogyan segít Stratify a SharePoint RAG bevezetésében?

A SharePoint RAG pipeline felépítése technikailag megoldható belső erőforrásokkal is, de a jogosultságkezelés, a GDPR-megfelelőség és a skálázási terv azok a területek, ahol a tapasztalat valódi időt és kockázatot takarít meg.

Stratify

Stratify a pilot tervezésétől a termelésbe vitelig végigkíséri a bevezetést: ingestion és chunking implementáció, permission-aware retrieval megvalósítás, compliance-tanácsadás és mérésekkel alátámasztott skálázási terv. A megközelítés nem eszközcentrikus: először a vállalat konkrét dokumentumkezelési kihívásait és jogosultsági modelljét térképezzük fel, majd erre építjük a pipeline-t. Az AI compliance és governance integrált részét képezi minden megbízásnak, nem utólagos pótlás.

Az első lépés egy konzultáció vagy AI workshop, ahol a scope, a pilot dokumentumkör és a jogosultsági modell körvonalazódik. Ha már van konkrét elképzelés, közvetlenül árajánlatot is kérhetsz.

Ajánlott források és hivatalos dokumentáció

Ajánlott

Tags: