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.
Kontrolní seznam před nasazením
- Kdo vlastní upstream obsah?
- Která servisní nebo uživatelská identita se bude přihlašovat?
- Které přesné složky, projekty, spaces nebo cesty jsou v rozsahu?
- Kdo smí kolekci používat?
- Kdo smí zdroje upravovat, přesouvat, synchronizovat nebo mazat?
- Jak rychle se musí projevit změna upstreamu?
- Jak otestujete retrieval a bezpečné chování při chybějící odpovědi?
- 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_idafile_pathrelativní 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
- Zdroj dosáhne Processed/Successful.
- Počet dokumentů a reprezentativní názvy odpovídají očekávání.
- U vybraných dokumentů jsou chunky čitelné a smysluplné.
- Files mají Indexed a Readable.
- Projde present-answer i absent-answer test.
- Odpověď správně uvádí/cituje dokument.
- Neoprávněný uživatel kolekci ani agenta nevidí.
- Ruční sync přenese kontrolovanou upstream změnu.
- Logs neobsahují nevysvětlené Failed/Skipped položky.
- 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ý:
- Při materiálním riziku kolekci odpojte od produkčních agentů.
- Zachovejte název zdroje, dokument, stav, časy a necitlivý kontext chyby.
- Rozlište upstream permission, selector, sync, parsing, indexing nebo retrieval problém.
- Opravu synchronizujte na bezpečném testovacím agentovi.
- 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.