---
theme: default
paginate: true
---


# Od datového skladu k datovým agentům
## Jak AI mění přístup k datům

<!-- _footer: "KIV/DBM1, Yuki Kryl, 2026-04-07" -->

<!--
Set expectation: we will rethink how we access data.

Optional: mention this is a "different perspective" lecture AKA Paradigm shift, hihi 😼
-->

---

# Jak vlastně získáváme odpovědi z dat?

Co vše se skrývá na pozadí otázky:
- „Kdo jsou naši nejaktivnější uživatelé za poslední týden?“

<!--
❓ How would you solve this?
❓ What steps would you take?
-->

---

# Co se musí stát v systému?

- výběr dat
- spojení tabulek (JOIN)
- filtrování (čas, podmínky)
- agregace
- řazení

Jednoduchá otázka → složitý proces

<!--
❓ Which step is hardest?
❓ Where do errors happen?
❓ Where can we get a completely wrong result without any error message 🙀

Tricky parts:
- joins (understanding relationships, correct keys, duplication/missing data)
- aggregation (what to group by, logical errors (different granularity levels, subtotals, ...), hard to debug/validate)

❗ dangerous part — these errors often don’t crash. They just give wrong results.
-->

---

# Klasický BI / DW pipeline

![](BI-pipeline.png)

<!--
Mention:
- This is what BI systems do internally

❓ Where is most effort in this pipeline?


In practice, most effort is in ETL… but even after that, accessing the data correctly is still difficult
-->


## Role v pipeline

- **Data engineer** → připravuje data
- **Analytik** → píše dotazy, sestavuje reporty
- **Manažer** → interpretuje výstup

<!--
❓ Which role would you prefer?
❓ Do managers really understand the data?

Point: knowledge is distributed.
-->

---
<!-- _header: Klasický BI / DW pipeline -->

## Vlastnosti klasického přístupu

➕ strukturovaný
➕ spolehlivý
➕ opakovatelný
➖ ale náročný na znalosti

<!--
Stress tradeoff:
- reliability vs accessibility

Hook:
- AI usage to make it more accessible
-->


## Kde je problém?

**Přístup k datům**

- nutnost znát schéma
- nutnost umět dotazovací jazyk (SQL)
- znalost business logiky

<!--
Key transition.

Say:
- The problem is not storing data
- The problem is accessing and interpreting it
-->

---

# Sémantická mezera

**Člověk:** uvažuje v konceptech jako `aktivní uživatel`

**Systém:** potřebuje přesně definované podmínky, formální dotaz

<!--
Core concept slide.

❓ Have you felt this mismatch when writing queries?
-->


Co tedy znamená `Aktivní uživatel za posledních 7 dní` ?

- počet akcí?
- přihlášení?
- odehrané hry?

<!--
❓ What would YOU define as active user?

Then say:
- All valid → problem.

Somebody has to convert: fuzzy business meaning → explicit formal definition

-->

---

# Data ≠ informace

Data jsou uložená, ale význam není explicitně zmíněn poblíž dat. 

Je potřeba aby někdo převedl **fuzzy business význam** na **explicitní formální definici**

<!--
That conversion is the semantic gap.
Key idea: meaning is not stored.

Ex: data o rozvrhu studentů: překrývající se akce mohou být napočítány do zátěže, ale ve skutečnosti mohou chodit jen na jedno z toho. To z dat ale není poznat bez znalosti situace.
-->

---

# Nový přístup: AI jako rozhraní

Co kdybychom se ptali přirozeným jazykem? 

<!--
Introduce AI calmly.

Frame as attempt to bridge gap.
-->

---

# Nový přístup

![](AI-pipeline.png)

## Role AI:

- interpretuje záměr
- generuje SQL/Pandas/filtry/agregace


<!--
Draw attention to new layer.

❓ What could go wrong here?

Clarify:
- AI does not know data
- it translates intent

-->

---

# Úrovně použití AI

- **Jednoduchý dotaz** (LLM, chatbot) k sestavení dotazu
- **Dotaz + dodání kontextu** uživatelem (schema)
- **Agentní přístup** (může si dohledat kontext, doptat se)

Každá úroveň přidává více schopností, ale i více komplexity a rizik 

<!--

-->
---
<!-- _header: Úrovně použití AI -->

## Naivní LLM

`Kdo jsou naši top zákazníci?`

Nemá kontext, odhaduje strukturu, generuje **nějaký** generický SQL.


Vypadá správně… ale nemusí být!


![bg right:55%](naiveLLM.png)

<!--
⚠️ Problémy
špatné názvy tabulek/sloupců
špatná metrika („top“ podle čeho?)
halucinace

💬 You can even say:

“This works surprisingly often… and fails silently.”

📝 Actually highlighting diff possible interpretations of top in text  
-->

---
<!-- _header: Úrovně použití AI -->
## Schema-aware prompting

Prompt obsahuje schema - tabulky, sloupce, vztahy

➕ Výhody
méně halucinací, lepší joiny, realističtější dotazy

➖ Limity
stále nezná business logiku, jednorázový odhad

AI už „vidí strukturu“, ale stále nechápe význam


![bg right:55%](LLM-context.png)

<!-- 
AI už „vidí strukturu“
ale stále nechápe význam
-->

---
<!-- _header: Úrovně použití AI -->
## Agentní přístup

Agentní přístup není jen o jednom dotazu a promptu, ale AI systém může **na základě svého vnitřního usouzení** volat další pomocné funkce, například:
- zjíštění schematu tabulky
- ověření funkčnosti dotazu + oprava
- iterace na řešení
- upřesňující dotaz na uživatele

---
<!-- _header: Úrovně použití AI - Agentní přístup -->

### Možný proces agentního systému

🧑 se zeptá `kdo jsou naši top zákazníci`
🤖 zavolá funkci na **načtení schematu** databáze
🤖 **usoudí**, které entity a attributy jsou relevantní
🤖 **zeptá se uživatele** na upřesnění definice `top`
🧑 popíše metriku
🤖 **vytvoří query**
🤖 **spustí query** a v případě chyby iteruje řešení problému
🤖 **vrátí výsledek**
🧑 ověří, že výsledek odpovídá požadavku


**Klíčová změna:** dotaz není jednorázový, ale je to plnohodnotný iterativní proces hledání odpovědi
<!--

-->

---
<!-- _footer: https://www.linkedin.com/pulse/ai-agent-sql-queries-visualization-using-multi-agent-3an9c -->
![bg 90%](multi-agent-workflow.png)

---
 
# Posun paradigmatu díky Agentům

Klasický přístup:
- pevně definované dotazy pro dashboardy
- validované
- vysoká důvěra

AI přístup:
- dynamické dotazy
- flexibilita
- nutnost ověření a chápání kontextu uživatelem

Ideální hybrid využívající silné stránky obou - AI přístup pro exploraci, pak ukotvit a validovat klasicky

<!-- 
dříve uživatel pouze sestavoval dashboard z katalogu známých prvků
dnes je může i vytvářet dle potřeby bez čekání na implementaci a ověření
-->


---
## Limitace Agentní přístupu


AI neřeší nejednoznačnost - odhaluje ji.

Co agent stále neví:
- co je „správná metrika“
- jaká data jsou validní
- jaké jsou business pravidla

---



# Co se děje uvnitř agenta?

Agent může dělat různé věci, 
komplikací je, že uživatel většinou vidí jen výsledek. 


## Skrytá logika

- rozhodovací proces není viditelný
- mezikroky nejsou běžně dostupné
- debug logy bývají skryté

Běžný uživatel nástroje neví, *proč* agent došel k výsledku.

---
<!-- _header: Co se děje uvnitř agenta? -->

## SQL vs AI přístup

| SQL | AI |
|-----|----|
| vidím dotaz | vidím výsledek |
| kontroluji logiku | odhaduji správnost |
| přesný postup | skrytý proces |

Změna kontroly nad systémem a posun k **black box rozhodování**.


<!--
* rozhodování není viditelné
* nelze snadno ověřit postup
* debug logy nejsou běžně dostupné

❓ Vadí vám, že nevidíte, jak systém přemýšlí?
❓ Kdy by vám to vadilo? report pro management? osobní explorace?
-->


---

# Mapování úrovní použití AI na reálné nástroje

**Jednoduchý LLM**
- ChatGPT, Copilot, ...
- generování SQL z textu

**Kontext + schema**
- BI nástroje (Power BI, Tableau + AI)
- nástroje s přístupem ke schématu

**Agentní přístup**
- systémy s přístupem k DB + iterací
- experimentální agenti (LangChain a podobné frameworky)
- interní firemní adhoc řešení

<!--
❓ použili jste něco z toho?
❓ věřili jste výsledku?
-->

---

# Jak vyspělá je tato oblast?

- rychlý vývoj (2023–2026)
- nástroje jsou zatím nedokonalé
- velká variabilita kvality

Neexistuje „standardní řešení“ kvůli rychlému zastarávání a velké konkurenci.

---
<!-- _footer: https://www.linkedin.com/posts/jsu05_i-love-ethan-mollicks-newsletter-one-useful-activity-7426992300695896064-VdAV -->
![bg 90%](decide-delegate-ai.png)

---


# Jakou odpověď od AI dostaneme?

## Běžné nástroje pro využití AI k dotazování

- jeden SQL dotaz  
- jeden výsledek  
- bez vysvětlení  

Rychlé, ale zjednodušené. Efektivní pro integraci do dalšího workflow, protože odpověď je jednoznačná.

---
<!-- _header: Jakou odpověď od AI dostaneme? -->

## Co by mohl dělat LLM

- nabídnout více interpretací  
- vysvětlit rozdíly  
- ukázat alternativy  

`Top zákazník` může znamenat více věcí. Ale uživatel musí odpověď zpracovat a vybrat si.

## Zploštění odpovědi

- Nástroj vybere jednu interpretaci,
- ignoruje ostatní možnosti  

Nuance se ztrácí. Uživatel si nemusí uvědomit "nejistotu" odpovědi a alternativy.

<!--
What-if: output is set of queries with estimated probability or confidence of model

-->

---

# AI a citlivá data

Použití SaaS řešení AI znamená:

- data (nebo jejich část) opouští systém  
- dotazy mohou obsahovat citlivé informace 
- poskytovatel může garantovat respektování soukromí a nepoužívání interních dat pro své účely, ale těžko prokazatelné

---
<!-- _header: AI a citlivá data? -->

## Rizika

- únik dat  
- porušení regulací (např. GDPR)  
- nemožnost auditu  

Problém bude zejména v oblastech jako: zdravotnictví, finanční sektor, interní firemní data.

<!-- 
❓ Poslali byste firemní data do ChatGPT?
❓ A víte, jestli to už někdo ve firmě udělal?
-->

---
<!-- _header: AI a citlivá data? -->

## Lokální modely

Alternativa:

- model běží interně  
- data neopouští infrastrukturu  
- větší kontrola  

### Trade-off

| Cloud AI | Lokální model |
|----------|--------------|
| vyšší kvalita | nižší kvalita |
| snadné použití | složitější provoz |
| riziko dat | větší bezpečnost |

---

# Jak poznáme správný výsledek?

AI nástroj vrátí:

✔ validní SQL  
✔ validní výstup  

Ale je to správně?

---
<!-- _header: Jak poznáme správný výsledek? -->
## Proč je to těžké?

- neexistuje jednoznačný „ground truth“  
- business definice nejsou explicitní  
- data mohou být nekvalitní  

## Důsledek

Validace je na uživateli

---
<!-- _header: Jak poznáme správný výsledek? -->
## Jak ověřit výsledek?

- dává číslo smysl?  
- odpovídá rozsahu dat?  
- není extrémně velké / malé?  
- lze výsledek spočítat jinak?  

Jednoduché kontroly často odhalí chybu. 
Je výhodné mít **širokou general knowledge**, protože pak snadněji padne chyba do oka.

---

# Typy chyb AI dotazů

1. **syntaktická**  
   SQL se nespustí  

2. **strukturální**
   špatný join, duplicity  

3. **logická**
   špatná metrika / agregace  

4. **interpretační**
   špatné pochopení zadání  
   
Nejhorší typ chyby logická / interpretační - dotaz funguje a výsledek může vypadat ok (= těžké odhalit)

---



## Co se mění se zaváděním AI nástrojů?

- méně potřeby znát SQL syntax
- méně potřeby znát schéma

<!--
❓ Who benefits from this?

Highlight accessibility.
-->

## Důležité omezení

- AI nezná vaše data
- kdo garantuje správnost?

AI může dát špatnou odpověď, která vypadá správně

<!--

❓ Would you trust this for business decisions?
❓ Which is worse: wrong or uncertain result?

-->

---

## Datové modelování je stále klíčové

- kvalitní schéma → lepší výsledky
- jasné názvy → lepší interpretace
- čistá data → méně chyb
- dokumentace ke znalostní bázi je důležitá pro kontext (agent si ji rád přečte)

<!--
Tie back to course value.
-->
---


# Nová role uživatele

**Dříve:**

- psaní dotazů  

**Dnes:**

- interpretace výsledků
- odhalování chyb
- chápání kontextu
- ověřování metodologie výpočtu  

--- 

# Závěrečná myšlenka

AI usnadňuje přístup k datům (nejen skrze SQL), ale ztěžuje důvěru ve výsledek.

### Proč se vlastně o datech učíme?
AI vám pomůže napsat dotaz, ale **nepozná, že je špatně**. To musíte umět vy


<!--
Let it sit.

❓ Would you deploy this in production?
❓ Jaké jsou core skills pro uživatele?
-->