Správa datových kolekcí a zdrojů

Administrátor odpovídá za hranici mezi externími systémy, uloženými credentials, indexovaným obsahem, přístupem ke kolekci a agenty, kteří data používají. Nestačí, že zdroj technicky funguje. Musí mít vlastníka, schválený rozsah, obnovovací politiku a postup vyřazení.

Reference pro nastavení zdrojů

Podrobné Data návody popisují všechna pole aktuálních formulářů:

• Výběr zdroje a vlastnictví
• Manual Upload a pravidla nahrávání
• Google Drive složky a Shared Drives
• OneDrive a SharePoint
• Azure bloby a file shares
• Automatizovaný příjem souborů přes Azure File Share
• Jira projekty a Confluence spaces
• Firecrawl domény a omezení cest
• Processing, sync, akceptační testy a incidenty

Tyto stránky použijte jako implementační checklist. Tento Admin Guide určuje vlastnictví identity, least privilege, přístup ke kolekci, revize, monitoring a vyřazení.

U každého zdroje oddělujte:

• Connection: autentizace a identita vůči providerovi.
• Datový zdroj: konkrétní složka, cesta, blob selektor, share, projekt, space nebo URL.
• Kolekce: business seskupení a access policy.
• Přiřazení agentovi: produkční chování, které smí z kolekce vyhledávat.

Volba direct context, RAG nebo hybridní pipeline

Následující rozsahy jsou provozní heuristiky, nikoli produktové limity. Počítejte použitelný parsovaný obsah, ne pouze zdrojové soubory: méně než 20 dlouhých dokumentů může přesáhnout 100k tokenů a vyžadovat retrieval, zatímco mnoho krátkých záznamů se může pohodlně vejít. Před produkčním nasazením ověřte volbu na evaluační sadě.

Orientační velikost korpusu	Výchozí přístup	Proč, kompromis a postup administrátora
Přibližně 1–20 souborů a nejvýše 100k tokenů	Direct context	Nejvhodnější pro detailní čtení, porovnávání celých dokumentů a reasoning, který závisí na zobrazení celého malého korpusu. Nevzniká riziko retrieval miss, ale s každým dokumentem rostou náklady a latence kontextu. Ověřte kontextové okno modelu a načítejte pouze schválený obsah.
Přibližně 21–49 souborů	Rozhodnout podle úlohy	Direct context použijte, pokud úloha potřebuje většinu dokumentů najednou a celkový počet tokenů se vejde. RAG nebo hybridní přístup použijte pro konkrétní otázky, řídké důkazy, časté aktualizace nebo různé přístupové rozsahy. Obě varianty otestujte na reprezentativních otázkách.
Přibližně 50–199 souborů	Začít používat RAG	Retrieval snižuje velikost a cenu kontextu, ale může vynechat důkazy potřebné pro široké porovnání. Definujte metadata, připravte testy známých i chybějících odpovědí a před nasazením kontrolujte vrácené chunky.
Přibližně 200–999 souborů	Preferovat RAG	Přímé načítání korpusu bývá neefektivní a zvyšuje šum. Použijte metadata filtering a hybridní lexikální/vector retrieval s rerankingem; sledujte relevanci, latenci a zastaralý nebo duplicitní obsah.
1 000 a více souborů	RAG je prakticky nutný	Korpus je příliš velký pro běžné přímé načítání. Rozdělte jej podle vlastnictví a přístupu, vyžadujte kvalitní metadata, průběžně vyhodnocujte retrieval a nastavte alerty na chyby ingestion a retrievalu.

Tvar úlohy může výchozí rozsah změnit. Pro porovnávání nebo reasoning napříč mnoha dokumenty nejprve vyhledejte kandidáty a potom načtěte celé relevantní dokumenty, pokud se vejdou do kontextového okna. Pro přesné identifikátory i sémanticky formulované otázky v jedné kolekci použijte doporučenou hybridní retrieval pipeline.

Plánování synchronizace a práce se selháním

Frekvenci synchronizace vyberte podle nejvyšší přijatelné zastaralosti obsahu, nikoli pouze podle velikosti korpusu. Daily nebo Weekly určuje frekvenci spuštění běhu; nejde o požadavek znovu parsovat a indexovat každý soubor. Běh projde celý rozsah zdroje kvůli discovery a potom zpracuje pouze nové, změněné a dříve Failed soubory. Úspěšně zpracované nezměněné soubory a soubory označené IsUserDeleted se přeskočí. Úplnou stavovou matici uvádí reference inkrementálního reingestu.

Před produkčním nasazením evidujte vlastníka zdroje, plán, očekávaný rozsah počtu dokumentů, přijatelnou zastaralost a vlastníka eskalace. Po každém plánovaném běhu zkontrolujte v Overview poslední a další synchronizaci, v Logs počty zjištěných a zpracovaných souborů a v Files dokumenty ve stavu Failed, skipped, unreadable nebo unindexed.

Dříve Failed soubor se při dalším běhu zkusí zpracovat znovu. Opakované selhání není důvodem ke zkrácení intervalu: zkontrolujte přístup providera, selector, podporovaný formát, extrakci, velikost a logy, opravte příčinu a po dalším běhu soubor ověřte. Častější plán zvyšuje zatížení providera při enumeraci a processingu a může dříve zpřístupnit nerevidované upstream změny. Podrobnou kontrolu a řešení incidentů popisuje Processing, Sync a řešení potíží.

Kontrolní seznam před nasazením

1. Kdo vlastní upstream obsah?
2. Která servisní nebo uživatelská identita se bude přihlašovat?
3. Které přesné složky, projekty, spaces nebo cesty jsou v rozsahu?
4. Kdo smí kolekci používat?
5. Kdo smí zdroje upravovat, přesouvat, synchronizovat nebo mazat?
6. Jak rychle se musí projevit změna upstreamu?
7. Jak otestujete retrieval a bezpečné chování při chybějící odpovědi?
8. Co se stane při odchodu vlastníka credentials nebo vyřazení zdroje?

Volba architektury zdroje

Požadavek	Doporučený zdroj	Důvod
Malá/testovací sada nebo řízený neměnný snapshot	Manual Upload	Obsah se změní jen vědomým novým uploadem
Týmová složka v Google	Google Drive s týmovým účtem	Zachová živé změny a hranice Google sdílení
Soubory vlastněné Microsoft uživatelem	OneDrive	Respektuje oprávnění vybraného uživatele
Často měněná knihovna týmu/oddělení	SharePoint	Synchronizace sleduje řízený týmový zdroj
Velký externí systém nebo exportní pipeline	Azure Storage Account	Blob delivery je vhodný pro strojově generované repozitáře a vysoký objem
Velký lokální/on-premises repozitář přes Azure Files	Azure File Share	Zachovává SMB styl zdroje a hranici pojmenovaného file share
Aktuální issues projektu	Jira	Nevznikají zastaralé CSV exporty
Udržovaná znalostní báze	Confluence	Jeden řízený space je zdrojem pravdy
Veřejný/schválený web	Firecrawl	Webový ingest bez nativního providera

Zdroj nevybírejte jen proto, že už existuje Connection. Vybírejte systém, který vlastní autoritativní verzi.

Governance credentials

OAuth providery

Google Drive, OneDrive a SharePoint používají oprávnění připojeného účtu. Pro sdílená produkční data:

• preferujte dedikovanou nebo týmovou identitu,
• povolte jí pouze požadované složky, weby a knihovny,
• evidujte vlastníka identity a postup obnovení,
• kontrolujte Private versus Shared přístup Connection,
• otestujte reautorizaci dříve, než token vyprší nebo vlastník odejde.

Azure Storage

Connection obsahuje storage credential/connection string. Zdroj obsahuje pouze blob selektory nebo názvy file shares.

• Connection string, Account Key ani SAS secret nedávejte do popisu kolekce nebo selectoru.
• Preferujte read-only přístup omezený na potřebný container/share, pokud to konstrukce Connection umožňuje.
• Klíče rotujte v Connection a následně spusťte a ověřte sync.
• Blob Storage a Azure File Share udržujte jako různé zdroje i v jednom Storage Accountu.

Současný formulář Azure Storage přijímá raw textové selectory a ověřuje jen přítomnost alespoň jedné hodnoty. Kontrola selectoru a výsledku po vytvoření je proto povinná.

Atlassian

Pro sdílený Jira/Confluence ingest použijte servisní účet. URL, username/e-mail a API token patří do Connections. Do zdroje se předává pouze Jira Project Key nebo Confluence Space Key.

Firecrawl

API endpoint a klíč uložte v Connections. Pro každý zdroj zvlášť schvalte doménu, startovní URL, limit a include/exclude regexy. Firecrawl nesmí obcházet autentizaci ani pravidla nakládání s obsahem.

Access policy kolekce

Kolekce je hlavní access-controlled entita. Aktuální volby jsou:

• Private: autor a oprávnění administrátoři.
• Entire organization: organizace podle efektivní policy.
• Selected teams: explicitně vybrané týmy.

Backend při zápisu kontroluje write právo na nadřazenou kolekci. Vytvoření, úprava, přesun nebo smazání zdroje tedy závisí na write oprávnění kolekce. Oddělte Can Use od edit/write práv: většina uživatelů potřebuje retrieval, ne konfiguraci.

Doporučený model:

• jeden business owner,
• jeden technický owner,
• team use access pro konzumenty,
• edit pouze pro vyškolené správce,
• celoorganizační přístup jen pro skutečně celoorganizační obsah.

Nespoléhejte jen na provider permissions. Po ingestu jsou další distribuční hranicí kolekce a agenti, kteří ji používají.

Struktura kolekcí

Kolekce rozdělte, pokud se liší:

• cílové publikum nebo důvěrnost,
• business owner,
• source-of-truth systém,
• frekvence synchronizace,
• retention/deletion policy,
• cíloví agenti,
• očekávané retrieval chování.

Nevytvářejte jednu kolekci s tisíci nesouvisejících dokumentů. Úzké kolekce se lépe testují, snižují nerelevantní retrieval a usnadňují access review.

Název kolekce by měl přežít změnu providera:

Customer Support — Approved Policies
Finance — Month-end Procedures
Engineering — Production Runbooks

Název zdroje může popsat implementaci:

Support Shared Drive — Policies folder
Production exports — Azure blob feed
HELP — Confluence space

Kontroly podle zdroje

Google Drive

• Každé Folder ID ověřte pod připojeným účtem.
• Rekurzivní subfolders mohou nečekaně rozšířit rozsah.
• Shared Drives povolte jen při potřebě.
• Z upstream složky odstraňte nerelevantní shortcuts a duplicitní verze.

OneDrive a SharePoint

• OneDrive pro obsah uživatele, SharePoint pro obsah týmu/knihovny.
• Evidujte přesné cesty a pravidla velikosti písmen/zápisu.
• Servisní identita má mít přímý přístup, ne pouze dočasný share link.

Azure Storage Account

• Evidujte cílový účet/container a convention selectoru mimo secrets.
• Do Blobs dávejte pouze blob název/cestu/selector.
• Výsledek kontrolujte ve Files a Logs, protože formulář neumí selector předem ověřit.
• Pro různé přístupy nebo retenci vytvořte samostatné zdroje.

Azure File Share

• Zadávejte přesné názvy shares.
• Connection musí obsahovat platný secret key.
• Kontrolujte očekávané soubory, ne jen úspěšný stav zdroje.

Automatizovaný Azure File Share ingestion

Lokální repozitář, synchronizační službu, Azure landing zone, zdroj Siesta AI, kolekci a agenta spravujte jako jednu pipeline s oddělenými vlastníky.

• Určete vlastníka dokumentů, Azure administrátora, provozovatele synchronizace, Siesta AI administrátora a vlastníka agenta.
• Uploaderu dejte zápis pouze do schválené hranice. Connection v Siesta AI dejte jen čtecí přístup vyžadovaný nasazenou integrací.
• Upřednostněte identity-based SMB autentizaci s RBAC na úrovni share a odpovídajícími ACL. Pokud je nutný account key, evidujte vlastníka, datum rotace, ovlivněné zdroje a test po rotaci.
• Whitelistem schvalte kořenové složky a typy souborů. Před uploadem vynechte drafty, archivy, dočasné soubory, obsolete obsah a nepovolené klasifikace.
• Vyžadujte stabilní document_id a file_path relativní ke share. Před publikováním validujte status, čas, klasifikaci a duplicitní ID.
• Definujte, zda odstranění znamená delete, deprecate, archive nebo retain. Chování otestujte před produkcí.
• Soubory publikujte atomicky a manifest jako poslední, aby ingestion neviděl neúplnou dávku.
• Sledujte zvlášť synchronizační službu i Siesta AI. Alertujte zmeškané publikování, chyby přenosu, neplatná metadata, chyby ingestion, neočekávané změny počtu dokumentů a zastaralé verze.

Pro implementaci a pilot použijte celý návod Automatizovaný příjem souborů přes Azure File Share.

Jira a Confluence

• Jeden Jira zdroj přijímá jeden Project Key.
• Jeden Confluence zdroj přijímá jeden Space Key.
• Projekty/spaces rozdělte při rozdílném týmu, důvěrnosti nebo retenci.
• Po změně práv servisního účtu zdroj znovu otestujte.

Firecrawl

• Schvalte doménu a práva k obsahu.
• Scrape pro jednu stránku, Crawl jen pro omezený strom.
• Začněte nízkým limitem a úzkým include regexem.
• Vylučte login, search, archivy, query varianty a uživatelské cesty.

Upload limity

V Data → Upload limits lze spravovat výchozí limit organizace pro jednoho uživatele a individuální overrides.

Limity brání náhodným masivním uploadům a zpřehledňují kapacitu. Vyšší limit musí mít popsaný business důvod. Hodnota označená jako default dědí nastavení organizace; explicitní override pravidelně revidujte.

Upload limit neurčuje, zda je kolekce bezpečná ke sdílení. Access policy a scope zdroje posuzujte zvlášť.

Výchozí processing profil

• Fixed-size chunking pro běžné delší dokumenty.
• Advanced extraction vypnutý, dokud nejsou tabulky/layout/obrázky otestované.
• Pouze relevantní file classes.
• Vector size 3072 a quantization None, pokud infrastruktura a retrieval test neodůvodní změnu.
• Retriever skip volby neměnit bez evaluace.

Několik současných provider implementací posílá RAG službě ChunkSize: 700 a ChunkOverlap: 200; jejich jednotku a výsledné dělení určuje nasazená RAG pipeline. Změna vector/chunk nastavení může vyžadovat reprocessing a zásadně změnit odpovědi.

Netunujte podle jedné povedené otázky. Udržujte malou testovací sadu se známou odpovědí, chybějící odpovědí, duplicitami, tabulkami a čerstvě změněným obsahem.

Produkční akceptační test

1. Zdroj dosáhne Processed/Successful.
2. Počet dokumentů a reprezentativní názvy odpovídají očekávání.
3. U vybraných dokumentů jsou chunky čitelné a smysluplné.
4. Files mají Indexed a Readable.
5. Projde present-answer i absent-answer test.
6. Odpověď správně uvádí/cituje dokument.
7. Neoprávněný uživatel kolekci ani agenta nevidí.
8. Ruční sync přenese kontrolovanou upstream změnu.
9. Logs neobsahují nevysvětlené Failed/Skipped položky.
10. Je evidovaný owner, schedule, review date a retirement procedure.

U automatizovaného Azure File Share feedu navíc otestujte nový soubor, aktualizaci se stejným document_id, vynechaný draft, odstraněný soubor, chybná metadata a prázdný share. Ověřte citaci známé odpovědi, bezpečné odmítnutí otázky bez odpovědi a použití nové verze po synchronizaci.

Monitoring a incident

Sledujte:

• Overview: zdraví, velikost, počet souborů, poslední a další sync,
• Files: failed, skipped, unreadable nebo unindexed dokumenty,
• Logs: ruční/plánované běhy a počty dokumentů,
• konverzace agentů: nesprávné použití zdroje,
• audit a access záznamy po změně konfigurace.

Když je obsah chybný:

1. Při materiálním riziku kolekci odpojte od produkčních agentů.
2. Zachovejte název zdroje, dokument, stav, časy a necitlivý kontext chyby.
3. Rozlište upstream permission, selector, sync, parsing, indexing nebo retrieval problém.
4. Opravu synchronizujte na bezpečném testovacím agentovi.
5. Před návratem do produkce zopakujte testovací sadu.

Jediný failed dokument nemažte před získáním diagnostiky.

Smazání a vyřazení

Smazání dokumentu odstraní jeho indexovaný/RAG obsah. Smazání zdroje naplánuje odstranění retrieval dat. Smazání kolekce odstraňuje její zdroje a vazby na agenty.

Před smazáním:

• najděte závislé agenty,
• uchovejte potřebné auditní důkazy,
• ověřte náhradní obsah,
• informujte business ownera,
• otestujte bezpečné chování agenta bez zdroje.

Související návody

• Technická reference Data
• Uživatelská práce se zdroji
• Správa sdílených a privátních Connections
• Příprava agentů a workflows
• Monitoring, audit a rizika

Ukládání původních souborů

U podporovaných vzdálených zdrojů při vytváření rozhodněte, zda se mají uchovat i původní binární soubory. Store source files je oddělené od parsování a indexace a pro Google Drive, OneDrive, SharePoint, Azure File Share a Azure Storage Account je ve výchozím stavu vypnuté; Manual Upload ukládá originály. U zapnutého zdroje evidujte důvod, storage/residency dopad a vlastníka. Přesné chování a hranici cleanupu při neúspěšném vytvoření popisuje Ukládání zdrojových souborů.