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

Volič období ovlivňuje všechny karty a grafy. Input zahrnuje zprávy, instrukce a kontext odeslaný modelu; Output výstup modelu; Reasoning nahlášené uvažovací tokeny. Total shrnuje jejich spotřebu. Graf Token Consumption ukazuje denní vývoj podle typu tokenů.

Grafy Tokens by Model a Tokens by Agent rozdělují spotřebu podle modelů a agentů. Token Consumption by Model ukazuje vývoj podle modelů v čase.

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

Karty ukazují Workflow Executions (počet běhů), Operations (provedené kroky), Operation Categories (zastoupené kategorie) a Active Periods (časové intervaly s aktivitou). Jeden běh může obsahovat více operací.

Graf Executions Over Time ukazuje vývoj běhů v čase. Operations by Workflow porovnává podíl, počet a procenta podle workflow nebo typu operace, například časovaných a webhookových běhů, zpracování nahrávek nebo volání nástrojů. Po změně workflow porovnejte očekávanou aktivitu s výsledky a jednotlivé běhy ověřte v jejich detailu.

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

Interpretace grafů a návazná kontrola

Při náhlém poklesu zkontrolujte dostupnost agentů, kanálů a poslední změny instrukcí nebo workflow. Při růstu ověřte kapacitu a limity. Signál z analytiky dále prověřte v Conversations, Agents, Data, Workflows, Recordings nebo Logs podle toho, kde vznikl.

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

Analytics → Limits zůstává přehledem využití. Pravidla upravujte přes Admin → Limits → Model limits po výběru LLM connection. Úpravy vyžadují Connections.ManageLimits; prohlížení Analytics má vlastní reportingové oprávnění.

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.