Analytika
Usage
Screenshot Usage ukazuje hlavní KPI pro konverzace, zprávy, datové zdroje a agenty. Sloupcový graf zobrazuje měsíční vývoj konverzací a pravý panel ukazuje poslední negativní zpětnou vazbu, ze které může admin přejít ke konkrétním konverzacím nebo agentům.

Cost
Screenshot Cost se zaměřuje na spotřebu tokenů. KPI karty oddělují input, output, reasoning a celkový počet tokenů za vybraný časový rozsah. Sloupcový graf pod nimi ukazuje, ve kterých dnech spotřeba rostla a jaký typ tokenů ji tvořil.
Pokud se používá Azure AI Foundry model router deployment, čtěte analytiku Siesta AI společně s Azure Monitor. Siesta AI ukazuje, který agent, tým, uživatel nebo modelové připojení spotřebovává tokeny; Azure Monitor je source of truth pro distribuci routeru mezi underlying modely.
Data
Část Data používejte pro kontrolu aktuálního RAG inventáře a hledání kolekcí nebo zdrojů, které vyžadují podrobnější provozní kontrolu. Nejde o účetní přehled ani náhradu logů zpracování konkrétního zdroje.
| Karta | Co počítá |
|---|---|
| Total Storage | Aktuální objem uložených dat zahrnutý v analytickém inventáři. |
| Data Collections | Kolekce zastoupené v aktuálním inventáři. |
| Source Types | Různé typy konektorů nebo zdrojů zastoupené v inventáři. |
| Files | Dokumenty v inventáři; nejde o počet chunků. |
Pomocí Storage Breakdown změňte seskupení mezi User, Data Collection, Data Source a Source Type. Nemění se ani neduplikují data, pouze pohled na stejný uložený objem.
- Files by Type seskupuje počet dokumentů podle přípony nebo hlášeného typu.
- Total Analyzed Pages by Data Source porovnává počet analyzovaných stránek u zdrojů, které tuto metriku poskytují.
- Total Tokens by Data Source porovnává hlášený počet tokenů indexovaného obsahu. Nejde o spotřebu LLM požadavků; ta patří do části Cost.
- RAG Data Ingested Over Time by User seskupuje aktuálně indexované bajty podle data prvního objevení zdroje a uživatele, který datový zdroj vytvořil. Volby Daily a Weekly mění časové intervaly.
Graf ingestu je snapshot aktuálního indexovaného objemu, nikoli historie synchronizačních běhů. Pravidelný sync může projít celý rozsah zdroje, ale graf se nezmění, pokud se nezmění indexovaný obsah. Ani reprocessing existujícího dokumentu neznamená opětovné přičtení celé jeho velikosti. Jednotlivý sync, retry nebo chybu ověřte ve stavech dokumentů a Logs.
Původní vzdálené binární soubory uchované přes Store source files jsou samostatné provozní rozhodnutí vedle extrahovaného textu a indexovaných chunků. Stav ověřte v konfiguraci zdroje a pomocí badge Source files stored; samotný inventory graf neprokazuje retention každého originálu. Viz Ukládání zdrojových souborů.
Při větším počtu autorů zdrojů zůstanou hlavní série samostatné a ostatní se spojí do Other. Individuální vlastnictví proto neodvozujte ze série Other.

Analytics může odhalit chybějící typ zdroje, nečekaně malou kolekci, dominantní zdroj nebo neobvyklou skladbu souborů. Detail kolekce následně ověří přítomnost dokumentů a Processing, Sync, and Troubleshooting vysvětlí stavy, discovery, retries, chunky a source logs.
Workflows
Screenshot Workflows ukazuje počet spuštění workflow, objem operací, kategorie operací a aktivní období. Sloupcový graf sleduje běhy v čase a donut graf ukazuje podíl operací podle workflow nebo typu operace.

Recordings
Screenshot Recordings ukazuje počet nahrávek, nejvyšší objem nahrávek v období a počet aktivních období. Graf seskupuje vytvořené nahrávky podle týdnů, takže jde rychle poznat špičky i tichá období.

Tipy pro práci s daty
- Sledujte denní změny u KPI, abyste rychle poznali výkyvy.
- Pokud se počet zpráv zvyšuje bez růstu konverzací, podívejte se na kvalitu odpovědí (zpětná vazba) a případně upravte instrukce.
- Při nulových datových zdrojích ověřte, že agenti mají přiřazené správné datasety a přístupy.
Limits
V části Limits sledujte preventivní tokenové hranice LLM/modelových připojení. Volič LLM connection určuje kontrolované připojení. Karty Daily org usage, Weekly org usage, Closest daily limit a Closest weekly limit porovnávají aktuální spotřebu s nejbližší Organization, Team nebo User hranicí.
Tabulka Configured default limits obsahuje řádek All models a řádek pro každý modelový default. U každého zobrazuje Organization, Team a User hodnoty Daily / Weekly. Not configured znamená, že pro dané období není nastavena explicitní hranice; neznamená nulovou spotřebu.

Utilization by model porovnává modelovou spotřebu s modelovými defaults a výjimkami subjektů. Rozbalte model a najděte Organization, User nebo Team nejblíže efektivní hranici. All-model a model-specific spotřeba používají oddělené čítače a mohou mít rozdílné limity.
User a Team přehledy ukazují spotřebované tokeny, efektivní denní a týdenní hranici, procento a progress bar. Stavy rozlišují běžné, varovné a kritické využití, unlimited hranice a modely bez spotřeby.

V nastavení připojení jsou hodnoty v milionech tokenů (M). Aktivní subject override nahradí celý pár daily/weekly v daném scope. Chybějící nebo Disabled override dědí příslušné defaults; Disabled nezakazuje přístup. All-model a model-specific policies se kontrolují samostatně a dosažení kterékoli User, Team nebo Organization hranice vrátí řízenou denní nebo týdenní chybu limitu.

Nejprve nastavte široké defaults připojení, potom modelové defaults pro modely s jiným nákladovým profilem a User nebo Team výjimky jen tam, kde je odůvodňuje skutečná spotřeba. Přesné pořadí popisuje Connections Management.