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í.

První pilotní datová sada

Začněte jednou schválenou sadou pro konkrétní použití. V Data vytvořte soukromou kolekci a zaznamenejte vlastníka, účel, cílového agenta a pravidla vyřazení. Pro řízený snapshot použijte Manual Upload, pro průběžně měněný obsah podporovaný synchronizovaný zdroj. Odstraňte zastaralé nebo nesouvisející dokumenty a přihlašovací údaje.

Zvolte profil zpracování a určete vlastníka ingestu. První discovery ponechte ke schválení: v Overview → Updates porovnejte počty a přeskočené soubory s plánem a po zpracování ověřte dokumenty a jejich stavy. Následně kolekci připojte k soukromému pilotnímu agentovi a otestujte známou, chybějící i zastaralou odpověď včetně dohledání zdroje. Ingest není dotaz na živý systém; pro aktuální data použijte vhodné nástroje a API.

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
• Datové zdroje OneDrive
• Datové zdroje SharePoint
• Azure bloby a file shares
• 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 nastavený rozsah, odhadne nové, změněné a dříve neúspěšné soubory a čeká na schválení, pokud není zapnuté automatické zpracování. Při dalším discovery se mohou vrátit také zamítnuté soubory nebo soubory uvolněné odebráním pravidla vyloučení cesty. Ú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 Přehled → Aktualizace discovery, rozhodnutí o schválení a výsledek zpracování. V Souborech prohlédněte neúspěšné, přeskočené, nečitelné nebo neindexované dokumenty. Určete odpovědnou osobu, aby plánovaná discovery nezůstávala bez schválení.

Dříve neúspěšný soubor může znovu projít discovery a schválením v dalším běhu. 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 zdroje a kdo schvaluje nalezené aktualizace?
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 v Souborech a Přehled → Aktualizace, 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.

Soubory ze serveru Windows

Kopírování souborů z Windows do Azure a jejich připojení k Siesta AI popisuje návod Azure File Share Data Sources. Pole datového zdroje a synchronizaci popisuje reference 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 Admin → Limits → Data 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ášť.

Profil zpracování a schvalování

Aplikace začíná profilem Kvalitní (Quality): 3072 dimenzí, bez kvantizace a u šesti podporovaných souborových zdrojů se zapnutou pokročilou extrakcí PDF. Nezaměňujte tento výchozí stav s doporučením pro každý projekt.

Pro malý pilot můžete vědomě zvolit Úsporný (Economy), který používá 1536 dimenzí, Int8 a vypnutou pokročilou extrakci. Vlastní (Custom) umožňuje vlastní kombinaci, například větší vektory bez pokročilé extrakce. Vždy zkontrolujte profil a náklady na stránky PDF.

Pro první běh ponechte Automaticky zpracovat nalezené soubory vypnuté. Určete vlastníka, který v Přehled → Aktualizace porovná souhrn s plánovaným rozsahem, prověří přeskočené soubory a vybraný běh schválí nebo zamítne. Postup ukazuje Discovery mode. Automatické zpracování povolte až pro zdroj, jehož rozsah, profil a kvóty jsou schválené.

Používejte pouze relevantní typy souborů a vyloučení cest. Některé integrace předávají nastavení ChunkSize: 700 a ChunkOverlap: 200; jejich výsledné dělení určuje nasazená RAG pipeline. Změna vektorů nebo dělení může vyžadovat nové zpracování.

Rozhodujte podle malé testovací sady se známou odpovědí, chybějící odpovědí, duplicitami, tabulkami a čerstvě změněným obsahem, ne podle jedné povedené otázky.

Produkční akceptační test

1. Discovery odpovídá schválenému rozsahu, aktualizace je schválena a zpracování dosáhne úspěšného výsledku.
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. Přehled → Aktualizace ani Soubory neobsahují nevysvětlené neúspěšné nebo přeskočené položky.
10. Je evidovaný owner, schedule, review date a retirement procedure.

U Azure File Share otestujte nový soubor, změnu souboru na stejné cestě a odstranění souboru. Po přenosu do Azure a synchronizaci v Siesta AI zkontrolujte dokumenty v kolekci a odpovědi agenta. Samotné smazání souboru v Azure nepotvrzuje jeho odstranění z kolekce.

Monitoring a incident

Sledujte:

• Overview: zdraví, velikost, počet souborů, poslední a další sync,
• Files: failed, skipped, unreadable nebo unindexed dokumenty,
• Přehled → Aktualizace: ruční a plánované běhy, schválení 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ů.