20 častých otázek k pohovoru pro Data Scientist. Data science je žádaný obor, který převádí produktová, zákaznická a byznysová data na rozhodnutí, experimenty, modely a měřitelné poznatky. Otázky pokrývají různé úrovně a odpovědi si můžeš nahlas procvičit v našem pohovorovém trenéru.
1How do you explain foundational metrics like conversion rates or statistical significance to non-technical business stakeholders without using technical jargon?
When communicating foundational metrics to non-technical stakeholders, the key is to translate abstract formulas and statistical mechanics into intuitive user stories, decision confidence, and business risk. For conversion rate, rather than presenting a bare ratio or abstract percentage, frame it around concrete user counts: 'Out of every 100 people who landed on the checkout page, 5 completed a purchase.' This grounds the metric directly in observable customer behavior. For statistical significance, avoid formal null hypothesis terminology like alpha levels or rejection regions. Instead, explain it as confidence that an observed uplift is real rather than random noise or lucky timing. For instance: 'A statistically significant result means we are 95% confident this improvement reflects a genuine change in user behavior rather than random fluke. Rolling this out gives us high confidence of a positive outcome instead of reacting to random noise.'
## Experiment Results: New Checkout Flow
- Baseline Conversion: 5.0% (5 out of 100 visitors buy)
- Variant Conversion: 5.8% (5.8 out of 100 visitors buy, a +16% relative lift)
- Decision Confidence: 96% confidence (p = 0.04)
- Business Takeaway: The risk that this lift was just random chance is under 4%. Rolling this out is estimated to bring +$45k in monthly revenue.
2Jaký je koncepční rozdíl mezi operacemi inner, left, right a full outer join a jak každá z těchto voleb mění analytickou populaci a zpracování hodnot null při následném výpočtu metrik?
Spojení typu inner, left, right a full outer join určují, které záznamy zůstanou zachovány při slučování tabulek na základě shodných klíčů:
- Inner Join (vnitřní spojení): Ponechá pouze záznamy, u kterých existuje shoda spojovacího klíče v obou tabulkách.
- Left (Outer) Join (levé vnější spojení): Ponechá všechny záznamy z levé tabulky a sloupce z pravé tabulky vyplní hodnotou NULL, pokud shoda neexistuje.
- Right (Outer) Join (pravé vnější spojení): Ponechá všechny záznamy z pravé tabulky a neshodující se sloupce z levé tabulky vyplní hodnotou NULL.
- Full Outer Join (plné vnější spojení): Ponechá všechny záznamy z obou tabulek a na kterékoliv straně bez shody doplní hodnoty NULL.
Dopad na analytickou populaci a následné výpočty metrik: Volba typu spojení přímo určuje analytickou kohortu a jmenovatele použité při výpočtu metrik. Neúmyslný inner join mezi tabulkou uživatelů a tabulkou aktivit/transakcí vyřadí neaktivní uživatele, čímž zmenší jmenovatel pouze na aktivní uživatele a uměle navýší míru konverze nebo retence. Naopak vnější spojení (outer joins) zachovávají celou výchozí populaci, ale pro neshodující se řádky zavádějí hodnoty NULL. Následné výpočty s těmito hodnotami NULL musí počítat: standardní agregační funkce v jazyce SQL jako `SUM()` nebo `AVG()` hodnoty NULL ignorují, `COUNT(sloupec)` počítá pouze hodnoty různé od NULL, zatímco `COUNT(*)` počítá všechny řádky, a aritmetické operace s neošetřenými hodnotami NULL mají za výsledek opět NULL.
-- Inner join silently shrinks denominator to purchasers only
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS inner_conv_rate
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id;
-- Left join preserves full user base for accurate metric computation
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS true_conv_rate
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id;
3In product experimentation, what does randomization achieve that simple before-after comparison usually cannot, and how would you explain the core causal claim an A/B test is designed to support?
In product experimentation, a simple before-after comparison compares metrics across different time periods, which confounds the effect of a feature change with external temporal factors such as seasonality, day-of-week patterns, concurrent marketing campaigns, macro trends, and natural user maturation. Randomization assigns eligible units simultaneously to treatment and control groups, balancing both observed and unobserved confounding variables across groups in expectation. This establishes internal validity. The core causal claim supported by an A/B test relies on counterfactual reasoning: because the control group is subjected to the exact same external conditions over the exact same time window, it serves as an empirical estimate of the counterfactual—what would have happened to the treatment group had they not received the feature. Therefore, any statistically significant difference in outcomes can be causally attributed to the treatment intervention.
# Naive Before-After Comparison:
# Effect_estimate = Metric_t1 (Holiday Launch) - Metric_t0 (Pre-Holiday Baseline)
# Problem: Lift is confounded by holiday shopping surge and marketing spend.
# Randomized A/B Test:
# Effect_estimate = E[Metric_Holiday | Treatment] - E[Metric_Holiday | Control]
# Solution: Both arms experience the exact same external shocks simultaneously.
4Čeho má explorativní analýza dat (EDA – Exploratory Data Analysis) typicky dosáhnout před formálním modelováním nebo experimentováním a jak odlišíte EDA od konfirmatorní analýzy?
Explorativní analýza dat (EDA – Exploratory Data Analysis) je otevřený proces zaměřený na porozumění vnitřní struktuře datové sady, odhalování vzorců, identifikaci anomálií nebo problémů s kvalitou dat, posuzování předpokladů o rozdělení pravděpodobnosti a generování hypotéz před sestavením formálních statistických modelů či spuštěním experimentů.
Základní rozdíl mezi EDA a konfirmatorní analýzou spočívá v jejich účelu a metodologii:
- EDA slouží ke generování hypotéz, je flexibilní a průzkumná – využívá popisné statistiky, korelace a vizualizace k prozkoumání toho, co data naznačují, aniž by vyžadovala striktní předem stanovené závazky.
- Konfirmatorní analýza (například testování statistických hypotéz nebo vyhodnocování A/B testů) naopak slouží k testování hypotéz, je strukturovaná a inferenční – jejím cílem je rigorózně otestovat předem specifikované, falzifikovatelné hypotézy při kontrole statistické chybovosti (např. chyba I. typu).
Považování zjištění odhalených během EDA za potvrzené závěry na téže datové sadě může vést k dolování dat (data dredging / p-hacking) a přeučení (overfitting).
import numpy as np
import pandas as pd
# 1. EDA Phase: Open-ended discovery and hypothesis generation
df = pd.DataFrame({'engagement_score': np.random.normal(50, 10, 1000)})
summary = df['engagement_score'].describe()
# 2. Confirmatory Phase: Testing pre-registered hypothesis on fresh test/experiment data
# (e.g., two-sample t-test with fixed significance level alpha = 0.05)
5Co je únik cílové proměnné (target leakage) při učení s učitelem a jak se liší od legitimní silné korelace mezi příznakem a cílovou proměnnou?
K úniku cílové proměnné (target leakage) dochází tehdy, když příznak zahrnutý do trénování modelu obsahuje informace o cílové hodnotě, které by při reálném nasazení v čase inference nebyly legitimně dostupné. K tomu často dochází, pokud je příznak zaznamenán chronologicky až po sledované události nebo je přímým důsledkem výsledku (například použití časového razítka zrušení účtu nebo ID refundace při predikci odchodu zákazníka). Naproti tomu legitimní silná korelace odráží skutečný, existující prediktivní či kauzální vztah, který je plně znám a dostupný ještě před okamžikem predikce (například frekvence přihlášení zákazníka za posledních 30 dní). Přestože v obou případech vykáže model vysokou důležitost příznaku (feature importance) nebo skvělé metriky, model s únikem cílové proměnné dosáhne nerealisticky vysokých výsledků při offline validaci, ale v produkci selže, protože uniklý příznak v čase inference nelze znát.
# Scenario: Predicting whether a user will cancel their subscription (is_churned)
# LEAKY FEATURE:
# 'cancellation_survey_submitted' -> Occurs after the decision to churn has executed.
# LEGITIMATE FEATURE:
# 'login_count_last_30_days' -> Observed strictly before the prediction cut-off date.
6Jaký je účel rozdělení dat na trénovací, validační a testovací množinu a jak by měly jednotlivé části řídit iterativní vývoj modelu?
Rozdělení dat na trénovací, validační a testovací množinu odděluje trénování modelu, ladění hyperparametrů a finální evaluaci, aby byla zajištěna schopnost generalizace na neviděná data. - Trénovací množina (Training Set): Používá se k natrénování interních parametrů modelu (např. vah a biasů v neuronových sítích, prahových hodnot pro větvení ve stromech). - Validační množina (Validation Set): Používá se během iterativního vývoje pro výběr modelu, ladění hyperparametrů, výběr příznaků (feature selection) a detekci přetrénování (overfitting). Řídí rozhodování o tom, jaká architektura nebo konfigurace modelu funguje nejlépe, aniž by se zasahovalo do dat určených pro finální evaluaci. - Testovací množina (Test Set): Slouží jako striktně oddělený zástupce neviděných produkčních dat. Vyhodnocuje se pouze jednou na samém konci projektu, aby poskytla nezkreslený odhad generalizační chyby. Opakované upravování modelů na základě výsledků z testovací množiny zneplatňuje její objektivitu a vnáší optimistické zkreslení.
from sklearn.model_selection import train_test_split
from sklearn.datasets import make_classification
X, y = make_classification(n_samples=1000, n_features=10, random_state=42)
# Step 1: Split off final test set (20%)
X_dev, X_test, y_dev, y_test = train_test_split(
X, y, test_size=0.20, random_state=42, stratify=y
)
# Step 2: Split remaining development data into train (75% of dev = 60% total) and validation (25% of dev = 20% total)
X_train, X_val, y_train, y_val = train_test_split(
X_dev, y_dev, test_size=0.25, random_state=42, stratify=y_dev
)
print(f"Train size: {len(X_train)}, Val size: {len(X_val)}, Test size: {len(X_test)}")
7Jaký je rozdíl mezi učením s učitelem a učením bez učitele a jak dostupnost anotací a obchodní cíle určují volbu paradigmatu?
Algoritmy učení s učitelem (supervised learning) se učí matematické mapování ze vstupních příznaků (X) na známé cílové anotace (y) s využitím historických označených dat k předpovídání výsledků pro dosud neviděná pozorování. Učení bez učitele (unsupervised learning) analyzuje datové sady obsahující pouze příznaky (X) s cílem odhalit vnitřní struktury, přirozená seskupení (shlukování neboli clustering) nebo redukované reprezentace bez předem definovaných cílových anotací. Volba mezi těmito paradigmaty se řídí dostupností anotací a obchodními cíli: pokud existují spolehlivě ověřené anotace (ground-truth labels) nebo je jejich sběr proveditelný a obchodním cílem je cílená predikce (např. detekce podvodů, predikce odchodu zákazníků, předpovídání cen), je vhodné učení s učitelem. Pokud anotace neexistují, jejich pořízení je příliš nákladné, nebo je cílem volný průzkum dat (např. segmentace zákazníků, detekce anomálií bez známých popisků), volí se učení bez učitele.
import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.cluster import KMeans
X = np.array([[10, 2], [12, 3], [1, 8], [2, 9]])
y = np.array([0, 0, 1, 1])
# Supervised: Learns mapping X -> y
clf = LogisticRegression().fit(X, y)
# Unsupervised: Discovers clusters directly from X
kmeans = KMeans(n_clusters=2, random_state=42, n_init=10).fit(X)
8Co je to NSM (North Star Metric) a jak při vyhodnocování stavu produktu odlišíte efektivní hlavní metriku od marnivé metriky (vanity metric)?
North Star Metric (NSM) je primární metrika, která nejlépe vystihuje klíčovou hodnotu, již produkt přináší zákazníkům, a zároveň podporuje udržitelné obchodní výsledky (např. „Počet rezervovaných nocí“ pro Airbnb nebo „Týdenní počet hodin aktivního streamování“ pro hudební platformu). Sjednocuje produktové týmy kolem dlouhodobé hodnoty pro zákazníka namísto povrchního růstu. Pro odlišení efektivní North Star metriky od marnivé metriky (vanity metric) platí:
1. Soulad s hodnotou (Value Alignment): Efektivní North Star odráží skutečný užitek pro uživatele a aktivní zapojení, zatímco marnivá metrika měří povrchní objem (například celkový počet registrovaných uživatelů, kumulativní počet stažení aplikace nebo hrubý počet zobrazení stránek), který může růst i v momentě, kdy uživatelé službu okamžitě opouštějí (churn).
2. Akceschopnost a korelace: Efektivní North Star koreluje s retencí uživatelů, zdravím produktu a monetizací a přímo reaguje na zlepšení kvality produktu. Marnivé metriky často nelze provázat se skutečnou retencí ani obchodním zdravím a snadno podléhají umělému nafukování.
Platform: Vacation Rental App
Vanity Metric: Cumulative app downloads (increases continuously even if 95% of users uninstall immediately).
North Star Metric: Nights booked per active user (reflects actual value exchange between guests and hosts).
9Jaký je praktický rozdíl mezi posunem dat (data drift) a posunem konceptu (concept drift) a proč je jejich správná kategorizace zásadní pro údržbu modelu po nasazení do produkce?
Posun dat (data drift, často označovaný jako covariate shift) nastává, když se statistické rozdělení vstupních příznaků P(X) v čase mění, zatímco podmíněný vztah mezi vstupy a cílovou proměnnou P(Y|X) zůstává beze změny. Naproti tomu posun konceptu (concept drift) nastává, když se mění samotný vztah mezi vstupy a cílovou proměnnou P(Y|X), což znamená, že stejné hodnoty příznaků nově odpovídají jinému chování nebo výsledkům cílové proměnné.
Jejich správná kategorizace je pro údržbu po nasazení do produkce klíčová, protože způsoby jejich nápravy se zásadně liší. Při posunu dat zůstávají historické vzorce platné; údržba se zaměřuje na rozšíření trénovacího pokrytí do nových oblastí příznaků, aktualizaci předzpracování dat nebo převážení vzorků (sample re-weighting). Při posunu konceptu již historická označení neodpovídají aktuální skutečnosti; údržba vyžaduje sběr nových označených dat, vyřazení zastaralých historických příkladů a přetrénování nebo redesign modelu.
# Data Drift (Covariate Shift):
# User demographics or devices change (P(X) shifts),
# but genuine vs fraudulent transaction patterns remain identical (P(Y|X) unchanged).
# Concept Drift:
# Fraudsters adapt tactics to mimic normal shopping patterns;
# identical feature inputs now have a higher probability of fraud (P(Y|X) shifts).
10Jaký je rozdíl mezi parametrem populace a výběrovou statistikou a jak variabilita výběru ovlivňuje interpretaci metrik?
Parametr populace je fixní, obvykle neznámá číselná charakteristika celé populace (například skutečný průměr populace μ nebo podíl p). Výběrová statistika je číselný souhrn vypočítaný z pozorovaných výběrových dat (například výběrový průměr x̄ nebo výběrový podíl p̂), který se používá k odhadu neznámého parametru. Výběrová variabilita (sampling variability) označuje přirozené kolísání výběrových statistik napříč různými náhodnými výběry pořízenými ze stejné populace. V důsledku výběrové variability podléhá jakákoli jednotlivá výběrová metrika náhodné chybě a jen zřídka přesně odpovídá skutečnému parametru populace. Pokud se při interpretaci metrik tato variabilita nezohlední, hrozí záměna náhodného šumu za skutečnou změnu. Analytici musí kvantifikovat nejistotu odhadu pomocí směrodatných chyb (standard errors), intervalů spolehlivosti (confidence intervals) nebo testování hypotéz dříve, než učiní závěr, že pozorovaný rozdíl je reálný.
import numpy as np
# True population parameter (mean = 50, standard deviation = 10)
pop_mean = 50.0
pop_std = 10.0
# Draw multiple independent samples of size n=30
np.random.seed(42)
sample_means = [np.mean(np.random.normal(pop_mean, pop_std, size=30)) for _ in range(5)]
for i, sm in enumerate(sample_means, 1):
print(f"Sample {i} Mean (Statistic): {sm:.2f} | Error: {sm - pop_mean:+.2f}")
11Zúčastněná strana (stakeholder) položí nejednoznačnou otázku typu „Funguje funkce Y?“. Jak tento dotaz přeformulujete do měřitelného analytického rámce připraveného pro rozhodování?
Když se stakeholder zeptá: „Funguje funkce Y?“, začínám rozkladem otázky na její základní záměr: Jaký problém měla funkce Y vyřešit, pro koho je určena a jaké rozhodnutí bude na základě odpovědi učiněno (např. iterovat, škálovat nebo ukončit podporu)? Následně vytvořím víceúrovňový rámec měření sestávající z těchto oblastí: 1. Adopce a zapojení (engagement): Objevují a používají cíloví uživatelé danou funkci podle očekávání? 2. Přímá hodnota / úspěšnost úlohy: Dokončují uživatelé úspěšně klíčový proces (workflow), který funkce umožňuje? 3. Následný dopad na byznys: Koreluje adopce funkce s klíčovými hlavními metrikami (např. retence, konverze, tržby) nebo je přímo pohání? 4. Ochranné mantinely (guardrails): Nezpůsobila funkce nezamýšlené negativní vedlejší účinky (např. zvýšenou latenci, nárůst tiketů podpory, kanibalizaci jiných funkcí)? Nakonec se stakeholderem ještě před spuštěním analýzy předem stanovím rozhodovací prahy a hodnoticí kritéria, což zajistí shodu na tom, co představuje úspěch, a zabrání posouvání cílů ex post.
Feature: Quick Checkout Button
1. Primary Decision: Keep & expand vs. Redesign vs. Deprecate
2. Evaluation Metrics:
- Adoption: % of checkout sessions clicking the quick button (Target: >= 15%)
- Funnel Completion: Checkout completion rate given button click (Target: >= 75%)
- Business Metric: Overall cart conversion lift (Target: +1.5% in A/B test)
- Guardrail: Support tickets for accidental purchases (Threshold: < 0.2% increase)
3. Pre-agreed Action Plan:
- If Target Met: Roll out to 100% and promote to mobile app.
- If Adoption Low but Completion High: Retain, optimize UI discovery.
- If Guardrail Exceeded: Halt rollout, add confirmation step.
12Jak se při přípravě a čištění datové sady (data wrangling) s výrazným podílem chybějících hodnot rozhodujete mezi analýzou kompletních případů (complete-case analysis), jednoduchou imputací, příznaky indikujícími chybějící hodnoty a imputací založenou na modelech?
Volba strategie pro chybějící data závisí především na mechanismu jejich vzniku (MCAR, MAR, MNAR), podílu chybějících dat, cílovém způsobu použití (statistická inference vs. prediktivní modelování) a riziku zkreslení:
1. **Analýza kompletních případů (Complete-Case Analysis / odstraňování řádků):** Vhodná pouze tehdy, když data chybí zcela náhodně (MCAR – Missing Completely at Random) a podíl chybějících hodnot je malý (např. < 5 %). Pokud data chybí náhodně (MAR – Missing at Random) nebo nenáhodně (MNAR – Missing Not at Random), odstraňování řádků vnáší závažné výběrové zkreslení (selection bias) a připravuje model o cennou statistickou sílu vzorku.
2. **Jednoduchá imputace (průměr/medián/modus):** Rychlá a praktická pro základní prediktivní modely, ale nebezpečná pro statistickou analýzu, protože uměle snižuje rozptyl příznaků, nafukuje testové statistiky a zkresluje kovarianční struktury.
3. **Příznaky indikující chybějící hodnoty (imputace + binární příznak):** Ideální pro prediktivní modelování (zejména pro stromové algoritmy) a případy, kdy je absence hodnoty informativní (MNAR, například vynechaná nepovinná pole). Zachovává signál o chybějící hodnotě, aniž by došlo k narušení platných číselných rozdělení.
4. **Imputace založená na modelech (KNN, MICE, IterativeImputer):** Preferovaná v situacích, kdy jsou data typu MAR, existují silné korelace mezi proměnnými a je kritické zachovat vícerozměrné vztahy nebo směrodatné chyby parametrů (např. při regresní inferenci). Nevýhodami jsou výpočetní náročnost, implementační režie v produkčních pipeline a riziko úniku dat (data leakage), pokud není model fitován striktně na trénovacích záhybech (folds).
from sklearn.impute import SimpleImputer
import pandas as pd
df = pd.DataFrame({'income': [50000, None, 75000, None, 120000]})
# Impute median while tracking missingness pattern
imputer = SimpleImputer(strategy='median', add_indicator=True)
imputed_data = imputer.fit_transform(df)
# Returns: [income_imputed, income_is_missing]
13Produktový tým porovnává uživatele, kteří se aktivně přihlásili k nové funkci, s těmi, kteří tak neučinili, a zjišťuje o 20 % vyšší míru retence. Jak byste diagnostikovali výběrové zkreslení (selection bias) a zavádějící faktory (confounding) a jak byste navrhli nové vyhodnocení?
Porovnávání uživatelů, kteří se sami přihlásili k funkci (opt-in), s těmi, kteří se nepřihlásili, trpí výběrovým zkreslením (self-selection bias) a přítomností zavádějících faktorů (confounding). Uživatelé, kteří se aktivně rozhodnou novou funkci využívat, mají obvykle vyšší výchozí zájem, míru zapojení (engagement) nebo technickou zdatnost. Pozorovaný 20% rozdíl v retenci proto směšuje skutečný kauzální efekt funkce s již existující motivací uživatelů.
Diagnostika zkreslení:
1. Porovnání kovariát před zásahem: Porovnejte výchozí atributy mezi kohortou s opt-in a bez opt-in ještě před zavedením funkce (např. historickou aktivitu, minulou retenci, délku užívání služby, frekvenci transakcí, skladbu zařízení). Statisticky významné rozdíly potvrzují zavádějící faktory.
2. Kontrola předchozích trendů / placebo testy: Vyhodnoťte, zda opt-in uživatelé vykazovali vyšší retenci nebo zapojení již v obdobích před spuštěním funkce.
Nový návrh vyhodnocení:
- Randomizovaný experiment (zlatý standard): Implementujte randomizovaný pobídkový design (Randomized Encouragement Design) nebo randomizované postupné nasazení funkce. Všichni způsobilí uživatelé jsou náhodně rozděleni do testovací skupiny (Treatment – je jim funkce nabídnuta/zobrazena výzva) a kontrolní skupiny (Control – funkce není nabídnuta). Analyzujte pomocí metody Intention-to-Treat (ITT) pro celkový efekt nabídky a metody instrumentálních proměnných / dvoustupňových nejmenších čtverců (2SLS – Two-Stage Least Squares) s využitím přiřazení jako instrumentu k odhadu lokálního průměrného účinku léčby (LATE – Local Average Treatment Effect) na aktivní uživatele.
- Kvaziexperimentální přístupy (pokud randomizace není možná): Použijte párování podle indexu sklonu (PSM – Propensity Score Matching), metodu rozdílu v rozdílech (DiD – Difference-in-Differences) nebo syntetickou kontrolu k očištění o pozorovatelné výchozí zavádějící proměnné a paralelní preexistující trendy.
import statsmodels.formula.api as smf
import pandas as pd
# df columns: ['user_id', 'post_period', 'opted_in', 'retained']
# Interaction term captures causal lift above baseline group differences
model = smf.ols('retained ~ opted_in + post_period + opted_in:post_period', data=df).fit()
print(model.summary().tables[1])
14Jak byste navrhli kohortové řezy (cohort cuts) pro analýzu aktivace nebo retence, aby porovnání nebyla zkreslena posuny ve složení uživatelů (mix shifts) nebo neúplností dat kvůli nedostatečné vyzrálosti (maturity truncation)?
Návrh kohortových řezů, který předchází zkreslení vlivem posunů ve složení a neúplné vyzrálosti: 1. **Standardizace časových oken životního cyklu**: Sjednoťte kohorty podle relativního trvání (např. Den 0, Den 7, Den 30 od registrace/aktivace) namísto kalendářních dat, aby byla zajištěna férová porovnání životního cyklu. 2. **Ošetření neúplné vyzrálosti (cenzorování zprava / right-censoring)**: Vyhodnocujte pouze kohorty, které plně prošly celým pozorovacím oknem. Vylučte nebo explicitně označte nedávné kohorty, které ještě neměly dostatek času na dosažení daného milníku. 3. **Zmírnění vlivu posunů ve složení (mix shifts)**: Segmentujte kohorty podle vlivných proměnných (např. akviziční kanál, platforma, země nebo záměr uživatele). Pokud uvádíte agregované číslo, použijte standardizaci / vážení post-stratifikací, aby změny v mixu akvizičních zdrojů nezkreslovaly vnímaný trend retence.
WITH user_cohorts AS (
SELECT
user_id,
DATE_TRUNC('week', signup_time) AS cohort_week,
signup_time,
acquisition_channel
FROM users
-- Exclude cohorts that have not reached 7 full days of maturity
WHERE signup_time <= CURRENT_DATE - INTERVAL '7 days'
),
user_activity AS (
SELECT DISTINCT
c.user_id,
c.cohort_week,
c.acquisition_channel,
1 AS retained_d7
FROM user_cohorts c
JOIN events e ON c.user_id = e.user_id
WHERE e.event_time >= c.signup_time + INTERVAL '7 days'
AND e.event_time < c.signup_time + INTERVAL '8 days'
)
SELECT
c.cohort_week,
c.acquisition_channel,
COUNT(c.user_id) AS cohort_size,
COUNT(a.user_id) AS d7_active_users,
ROUND(100.0 * COUNT(a.user_id) / COUNT(c.user_id), 2) AS d7_retention_pct
FROM user_cohorts c
LEFT JOIN user_activity a ON c.user_id = a.user_id
GROUP BY 1, 2
ORDER BY 1 DESC, 2;
15Během evaluace dosáhne váš model neobvykle vysoké metriky, například AUC (Area Under the Curve) 0,99, ale v shadow testování výkonnost prudce klesne. Jak systematicky izolujete a ověříte únik cílové proměnné (target leakage)?
Když model dosáhne nerealisticky vysoké offline metriky (např. AUC 0,99), která v živém shadow testování prudce klesne, primárním podezřelým je únik cílové proměnné (target leakage). Systematický postup pro izolaci a ověření zahrnuje: 1. Důležitost a atribuce příznaků (Feature Importance & Attribution): Spočítejte hodnoty SHAP, gain importances nebo permutační důležitost k identifikaci kandidátních příznaků s dominantní predikční silou. 2. Modely s jedním příznakem a ablační studie: Natrénujte jednoduché jednopříznakové modely (např. mělké rozhodovací stromy nebo logistickou regresi) na jednotlivých podezřelých příznacích. Pokud samotný příznak dosahuje téměř dokonalé klasifikace, pravděpodobně dochází k úniku cílové proměnné. Následně podezřelé příznaky postupně odstraňujte (ablace) a měřte pokles offline výkonnosti. 3. Audit časového vývoje a časových razítek: Zkontrolujte přesná časová razítka vytvoření a aktualizace kandidátních příznaků vůči hraničnímu časovému razítku predikce. Ověřte, zda hodnota příznaku nemohla být známa až po výskytu cílové události (např. `cancellation_reason` nebo `refund_status` vyplněné až při odchodu zákazníka / zpětném zúčtování). 4. Datový původ (data lineage) a inženýrské ověření: Zkontrolujte předcházející datovou pipeline a logiku mutace tabulek (např. měnitelné tabulky aktualizované in-place vs. neměnné protokoly pouze pro připojování), abyste ověřili, kdy jsou pole skutečně naplňována.
from sklearn.metrics import roc_auc_score
from sklearn.tree import DecisionTreeClassifier
leakage_candidates = {}
for col in X_train.columns:
clf = DecisionTreeClassifier(max_depth=2)
clf.fit(X_train[[col]], y_train)
preds = clf.predict_proba(X_test[[col]])[:, 1]
auc = roc_auc_score(y_test, preds)
if auc > 0.85:
leakage_candidates[col] = auc
print("Candidate Leaky Features:", leakage_candidates)
16Jak se rozhodujete mezi standardní K-Fold, Stratified K-Fold a Group K-Fold křížovou validací při vyhodnocování reálných strukturovaných dat?
Volba mezi standardní K-Fold, Stratified K-Fold a Group K-Fold křížovou validací závisí na rozdělení cílové proměnné a nezávislosti jednotlivých řádků:
1. Standardní K-Fold: Náhodně rozdělí data do K stejně velkých bloků (folds). Předpokládá, že pozorování jsou nezávislá a identicky rozdělená (IID – Independent and Identically Distributed), a obvykle se používá pro spojité regresní cíle nebo dobře vyvážené datové sady.
2. Stratified K-Fold: Zajišťuje, aby každý blok zachovával stejné procentuální zastoupení tříd cílové proměnné jako celá datová sada. Je klíčová pro klasifikační úlohy, zejména při nevyvážených třídách, aby se předešlo blokům s příliš malým počtem vzorků minoritní třídy nebo bez nich.
3. Group K-Fold: Zajišťuje, aby se konkrétní skupiny či entity (např. `user_id`, `patient_id`, `device_id`) neobjevily současně v trénovacích i validačních blocích. Pokud pochází více pozorování ze stejné entity, standardní rozdělení způsobí závažný únik dat (data leakage), protože si model zapamatuje specifické rysy dané entity namísto učení obecných vzorců. Group K-Fold vyhodnocuje, jak dobře model generalizuje na zcela neznámé entity.
17Jak volíte mezi logistickou regresí, gradientně zesílenými rozhodovacími stromy (Gradient Boosted Decision Trees) a nelineárními neuronovými architekturami pro klasifikaci tabulkových dat při omezeních na latenci a posun dat (drift)?
Volba mezi logistickou regresí (LR), gradientně zesílenými rozhodovacími stromy (GBDT) a neuronovými sítěmi (NN) pro klasifikaci tabulkových dat vyžaduje vyvážení prediktivní přesnosti, limitů latence při inferenci, vysvětlitelnosti a odolnosti vůči posunu dat (data drift).
1. **Logistická regrese** vyniká v prostředích s ultra nízkou latencí (< 1–5 ms p99) a přísně omezenými výpočetními zdroji. Protože její vyhodnocení je jednoduchý skalární součin, je extrémně rychlá a robustní. Při posunu kovariát (covariate drift) nebo hodnotách příznaků mimo trénovací distribuci lineární modely extrapolují monotónně, což může být předvídatelné nebo naopak rizikové v závislosti na regularizovaných sklonech, ale zřídka produkují nevyzpytatelné skokové chování. Vyžaduje však rozsáhlé manuální vytváření příznaků (interakce, nelineární binning), aby se vyrovnala nelineárním architekturám.
2. **GBDT** (např. XGBoost, LightGBM, CatBoost) představují výchozí průmyslový standard pro tabulková data. Přirozeně zachycují složité nelineární interakce a bezproblémově zpracovávají smíšené datové typy i chybějící hodnoty. Z hlediska latence optimalizované GBDT (nebo modely zkompilované přes Treelite/ONNX) snadno splňují SLA pod 10 ms. Při posunu dat GBDT nedokážou extrapolovat mimo rozsah pozorovaný při trénování (omezují predikce na mezní listy), což poskytuje vestavěnou pojistku proti divoké extrapolaci, ale hrozí ustrnutí na neaktuálních skokových predikcích, pokud se distribuce příznaků výrazně posune.
3. **Neuronové architektury** (např. FT-Transformer, TabNet, MLP) jsou preferovány, pokud jsou tabulková data multimodální (kombinovaná s textem, embeddingy nebo obrázky) nebo v prostředí kontinuálního online učení. Čistě tabulkové neuronové sítě však obvykle vykazují vyšší latenci při inferenci (vyžadují násobení matic napříč vrstvami nebo akceleraci pomocí GPU), jsou náročnější na trénování a jsou vysoce citlivé na neškálované vstupy a posun kovariát.
**V praxi:** Začněte s GBDT jako silným výkonnostním základem (baseline); pokud je vyžadována striktní mikrosekundová latence nebo jednoduchá interpretovatelnost, nasaďte logistickou regresi; neuronové sítě využívejte primárně pro multimodální architektury nebo přenos embeddingů.
decision_matrix = {
"Logistic Regression": {"Latency": "<1ms (Ultra-low)", "Drift Behavior": "Linear extrapolation", "Tabular Baseline": "Moderate (needs feature engineering)"},
"GBDT (XGB/LightGBM)": {"Latency": "1-15ms (Fast)", "Drift Behavior": "Leaf clamping (no extrapolation)", "Tabular Baseline": "State of the Art"},
"Tabular Neural Net": {"Latency": "10-50ms+ (Higher)", "Drift Behavior": "Nonlinear extrapolation", "Tabular Baseline": "Competitive / High tuning cost"}
}
for model, traits in decision_matrix.items():
print(f"{model}: Latency={traits['Latency']}, Tabular Perf={traits['Tabular Baseline']}")
18Vedení se musí rozhodnout, zda provede celostátní spuštění klíčové funkce za nejednoznačných podmínek, včetně smíšených výsledků regionálních experimentů a pevně stanovených termínů vydání. Jak navrhnete rámec pro strategické doporučení?
Při návrhu strategického doporučení v situaci s nejednoznačnými výsledky regionálních experimentů a pevnými termíny vydání byste měli rozhodnutí oddělit od čistě binární volby „spustit / nespustit“.
Zaprvé rozložte agregované výsledky na heterogenní efekty působení (heterogeneous treatment effects) napříč tržními segmenty, kohortami zákazníků a provozními prostředími, abyste přesně izolovali, kde funkce uspěla, kde stagnuje a kde působí negativně.
Zadruhé navrhněte fázovanou strategii nasazení zajištěnou proti rizikům (např. regionální fázování nebo kanárkové nasazení – canary deployment), která upřednostní segmenty s vysokou mírou jistoty a zároveň izoluje rizika v chvostu rozdělení (negative-tail risk).
Zatřetí stanovte explicitní, předem odsouhlasené bezpečnostní metriky (guardrails) a automatizované jističe (circuit breakers) či prahové hodnoty pro vrácení změn (rollback), které ohraničí nejhorší možný scénář rizika.
Nakonec komunikaci směrem k vedení zarámujte kolem očekávané hodnoty, asymetrického rizika ztráty oproti komerčním nákladům na zmeškání pevného termínu a kolem provozních scénářů pro případné korekce za běhu.
| Rollout Tier | Target Markets | Launch Exposure | Guardrail Circuit-Breaker | Expected Value / Risk Profile |
|---|---|---|---|---|
| Tier 1: Immediate Launch | Cohorts with stat-sig positive lift (e.g., Regions A, C) | 100% | Rollback if 48h conversion drops > 1.5% | High upside; verified market fit |
| Tier 2: Phased Staging | High-variance / neutral cohorts (e.g., Region B) | 10% -> 25% -> 50% over 14 days | Hold expansion if CSAT drops > 2.0% | Moderate upside; bounded downside |
| Tier 3: Hold & Re-test | Stat-sig negative cohorts (e.g., Region D) | 0% (Holdout / internal testing) | Launch blocked until root-cause resolution | Eliminates primary churn risk |
19Jak byste navrhli centralizovanou sémantickou vrstvu napříč podnikovým datovým skladem, aby byla zajištěna konzistentní definice obchodních metrik mezi různými analytickými týmy?
Návrh centralizované sémantické vrstvy nad podnikovým datovým skladem vyžaduje zavedení deklarativní vrstvy pro definici metrik na bázi kódu (jako je MetricFlow/dbt Semantic Layer, Cube nebo LookML), která odděluje obchodní logiku od fyzického úložiště a navazujících konzumačních nástrojů (BI platformy, notebooky v Pythonu/R, API). Základní architektura definuje entity, dimenze, míry a odvozené metriky v repozitářích se správou verzí (Git), což poskytuje jediný zdroj pravdy a vynucuje konzistenci metrik napříč týmy. Pro podporu multi-tenancy a správy dat (governance) napříč oddělenými obchodními jednotkami by měl být použit model federovaného řízení: klíčové podnikové ukazatele (např. ARR, aktivní uživatelé) vlastní centrální tým pro správu dat, zatímco metriky specifické pro danou doménu spravují decentralizované doménové týmy prostřednictvím izolovaných sémantických modelů s validací v CI/CD. Sémantická vrstva následně vystavuje standardizovaná rozhraní pro dotazování (SQL, GraphQL, REST) se sjednoceným řízením přístupu na základě rolí (RBAC) a cachováním či předagregacemi pro udržení vysokého výkonu a konzistence.
semantic_model:
name: orders
node_relation:
alias: fct_orders
dimensions:
- name: order_date
type: time
type_params:
time_granularity: day
- name: country
type: categorical
measures:
- name: total_revenue
expr: revenue_usd
agg: sum
- name: distinct_buyers
expr: user_id
agg: count_distinct
metrics:
- name: average_order_value
description: "Governed metric for AOV across all BI tools"
type: ratio
type_params:
numerator: total_revenue
denominator: distinct_buyers
20Jak byste na oboustranném trhu (jako je spolujízda nebo e-commerce) navrhli experiment k vyhodnocení změny párovacího algoritmu s ohledem na kanibalizaci nabídky a poptávky a prostorově-časovou interferenci?
Na oboustranných trzích vyhodnocování párovacích algoritmů pomocí standardního A/B testování na úrovni uživatelů porušuje předpoklad SUTVA (Stable Unit Treatment Value Assumption). Pokud jednotky v testované skupině (treatment) spotřebovávají vzácné sdílené zdroje (např. řidiče nebo zásoby), kanibalizují zdroje kontrolní skupiny, což vede k umělé degradaci kontrolní skupiny a nadhodnocení efektu testované varianty v důsledku posunů tržní rovnováhy. Pro řešení prostorové a časové interference se využívají dvě hlavní experimentální architektury: randomizace na bázi shluků (klastrů) a switchback experimenty. Při prostorové klastrové randomizaci jsou geografické trhy nebo izolované podoblasti (např. oddělené metropolitní oblasti nebo hexagonální prostorové buňky rozdělené na grafu) náhodně přiřazeny do testované nebo kontrolní skupiny. Tím se izolují přímé interakce nabídky a poptávky, ačkoli k vyřešení heterogenity mezi trhy jsou nutné metody jako syntetické kontroly nebo rozdíl v rozdílech (difference-in-differences). U switchback experimentů (s dělením v čase) celé izolované trhy střídají testovaný a kontrolní algoritmus v diskrétních časových oknech (např. střídání každé 1–2 hodiny). Switchbacky udržují společnou rovnováhu nabídky a poptávky na trhu v rámci každého okna, vnášejí však zkreslení přesahem v čase (carryover bias). Pro zmírnění tohoto zkreslení se mezi okna vkládají přechodná vyrovnávací období (washout periods), během nichž se objednávky v době přechodu zahazují, a volí se délka oken, která je dostatečně dlouhá na absorpci přemístění nabídky, ale zároveň dostatečně krátká pro zachování statistické síly. Analýza musí zohlednit sériově korelované chyby časových řad shlukováním směrodatných chyb na úrovni časových bloků či trhu, nebo pomocí zobecněných odhadovacích rovnic (GEE) a Newey-Westových odhadů rozptylu.
import pandas as pd
import numpy as np
def generate_switchback_schedule(n_days=14, window_minutes=60, washout_minutes=15):
total_windows = int((n_days * 24 * 60) / window_minutes)
np.random.seed(42)
treatments = np.random.binomial(1, 0.5, size=total_windows)
schedule = []
for i, trt in enumerate(treatments):
start_min = i * window_minutes
eval_start_min = start_min + washout_minutes
end_min = (i + 1) * window_minutes
schedule.append({
'window_id': i,
'treatment': trt,
'start_min': start_min,
'eval_start_min': eval_start_min,
'end_min': end_min
})
return pd.DataFrame(schedule)