Англійська для науковців даних: презентація результатів для нетехнічних зацікавлених сторін

Одним з найскладніших комунікаційних викликів в науці даних є переклад технічних знань на мову, на якій можуть діяти бізнес-зацікавлені сторони. Модель з точністю 94,2% нічого не означає для менеджера продукту, який повинен вирішити, чи доставити функцію. Значення p = 0,03 не означає нічого для генерального директора.

Цей посібник містить конкретний англійський словник, структури речень і шаблони спілкування, які необхідні науковцям даних для ефективного спілкування з колегами, які не мають технічних знань — у презентаціях, повідомленнях Slack, письмових звітах і зустрічах.

---

Основні проблеми комунікації

Вчених по даним навчають бути точними. Зацікавлені сторони бізнесу повинні бути вирішальними. Ці цілі часто є в напрузі:

Data scientist mindset	Stakeholder mindset
”The model has 87% recall and 91% precision."	"Will this catch most of the fraud?"
"There is a statistically significant correlation."	"Should we change the product?"
"The confidence interval is 0.12–0.34."	"Is the result reliable enough to act on?”

Навички не в тому, щоб робити речі дурними — це переклад технічних знань на мову бізнесу без втрати точності.

---

Частина 1: Словник для презентацій даних

Заміна жаргону простою англійською

Technical term	Business-friendly equivalent
model accuracy	how often the system gets the prediction right
precision / recall	the false alarm rate / the miss rate
confidence interval	the range we expect the true value to fall in
statistical significance	whether the pattern is real or likely due to chance
p-value	the probability that the result is a fluke
overfitting	the model memorised the training data but doesn’t generalise
feature importance	which factors most influence the prediction
baseline model	the simplest comparison point — what the current system does
training vs inference	building the model vs using it in production
A/B test	a controlled experiment comparing two versions

Ключові фрази для введення результатів

• “На практике это означает…”
• • “Просто кажучи, модель правильно визначає X% з…” *
• “Поставить это в контекст…”
• “Влияние бизнеса…”
• • “Ключевая мысль здесь…” *

---

Частина 2: Представлення результатів моделі

Ясно вказати результати

❌ “Модель досягає 0,91 AUC-ROC на витриманому тестовому наборі з порогом 0,45.”

✅ “Модель виявлення шахрайства правильно фіксує 89% шахрайських транзакцій, генеруючи хибну тривогу приблизно на 1 з 200 законних транзакцій. У нашому поточному обсязі транзакцій, це близько 40 хибних попереджень на день - керованих командою перегляду. ”

Друга версія:

1. Показує результат у вигляді того, що він означає для користувачів
2. З’ єднує з бізнес- метрикою (перегляд завантаження команди)
3. Пропускає технічний поріг і AUC — вони належать до додатку

Структура для представлення результату моделювання

1. ** Що робить система ** (в одному реченні): * “Ця модель передбачає, які користувачі піддаються ризику відходу в найближчі 30 днів.” *
2. ** Як добре це працює ** (у бізнес-термінах): * “Під час тестування, він правильно визначив 3 з 4 користувачів, які насправді скинули.” *
3. ** Що у нього немає / його обмеження **: * “У нього більший відсоток хибно позитивних результатів для нових користувачів з обмеженою історією.” *
4. ** Що це означає для бізнесу **: * “Націлення на 500 найнебезпечніших користувачів на тиждень може зберегти приблизно [X] користувачів на місяць.” *

---

Частина 3: Комунікація невизначеності

Вчені з даних часто хеджують занадто мало (перебільшуючи впевненість) або занадто багато (здійснюючи результати, що здаються ненадійними). Ці фрази досягають правильного балансу.

Виразити довіру відповідним чином

Висока впевненість:

• “Данные сильно указывают…”
• • “Ми можемо сказати з високою впевненістю, що…” *
• “Шаблон є послідовним у всіх трьох наборах даних, що сильно вказує…”

** Помірна впевненість: **

• “Доказівки вказують на…”
• “Розрахунки збігаються з…, хоча ми хотіли б більше даних, щоб бути впевненими.”
• “Це відкриття багатообіцяюче, але воно має бути підтверджене на виробничих даних, перш ніж ми дійдемо до дій.”

** Низький рівень впевненості / попередній: **

• “Це ранній сигнал — ми б розглядали його як гіпотезу, а не як висновок.”
• • « Розмір вибірки невеликий, отже ці результати можуть не відповідати масштабу ». *
• “Ми бачимо цікавий шаблон, але це може бути артефактом періоду збору даних.”

Пояснення статистичного значення без використання терміну

❌ “Різниця статистично значуща при p < 0.05.”

✅ “Ми запустили це в 50 000 сеансів користувачів. Різниця між двома групами достатньо велика, щоб ми були впевнені, що це реальний ефект, а не просто випадкова варіація. ”

✅ “Якщо ми запустимо цей експеримент 100 разів з випадковими даними, ми очікуємо побачити такий великий результат менше ніж 5% часу. Отже, ми віримо, що це реальний ефект.»

---

Частина 4: Письменні звіти і оновлення Slack

Резюме експерименту (Slack)

**Churn Prediction Model — Experiment Summary**

What we tested: A new ML model that predicts 30-day churn risk
Test period: Feb 1–28 (47,000 users split 50/50)

Results:
• Users shown personalized retention offers: 9.2% churned
• Control group (no change): 12.1% churned
• Relative reduction: ~24%

Confidence: High — the result is consistent across all user segments we checked

Next step: I'd recommend expanding to 100% of at-risk users from April 1.
Happy to share the full analysis if useful.

Структура звіту даних (письмовий)

Структура звіту з даними для зацікавлених сторін виглядає так:

1. TL;DR/ Резюме (2-3 речення, ключові висновки і рекомендації)
2. ** Тло ** (чому ми провели цей аналіз, у 2-3 реченнях)
3. ** Що ми знайшли ** (ключові результати простим мовою)
4. ** Обмеження ** (що дані не можуть нам сказати)
5. ** Рекомендація ** (що робити далі, з чіткою логікою)
6. ** Додаток ** (технічні деталі, діаграми, статистичні тести — для тих, хто їх хоче)

Резюме йде ** першим ** - зацікавлені сторони часто читають тільки це.

---

Частина 5: Обробка складних питань

Коли дані не є остаточними

• “Розрахунки неоднозначні — ми бачимо ефект у користувачів мобільних пристроїв, але не у користувачів настільних комп’ ютерів. Це свідчить про те, що… Я б рекомендував [наступний крок] перед тим, як зробити твердий висновок»

• “У нас немає достатньо даних, щоб сказати остаточно. За поточною величиною вибірки, нам потрібно приблизно [X] тижнів даних, щоб виявити ефект такого розміру. До того часу, я б ставився до цього як до гіпотези.»*

Коли модель гірша, ніж очікувалося

• “Початкові результати були нижче нашої мети. Ми визначили дві ймовірні причини: [причина 1] і [причина 2]. Ми розробляємо [причина 1] цей спринт і очікуємо побачити поліпшення до [дата]. Чи було б корисно запланувати перегляд після того, як ми зробимо ці зміни?»*

Коли вас просять зробити рекомендацію, але дані не підтримують її

“Заснований лише на цих даних, я не можу рекомендувати один напрямок над іншим — різниця знаходиться в межах похибки. Якщо нам потрібно зробити дзвінок зараз, я б запропонував [варіант] через [інтуїцію / бізнес-причину], але я б розглядав це як рішення з низькою впевненістю і планував переглянути його в [часові рамки]. ”

Це краще, ніж будь-яке з них:

• Перебільшення впевненості, щоб дати відповідь
• Отказывает в сотрудничестве и постоянно говорит “нужно больше данных”

---

Частина 6: Словник Quick Reference

Situation	Useful phrases
Introducing the bottom line	”The short version is…”, “What this boils down to is…”, “The key finding is…”
Explaining what a number means	”To put that in context…”, “In practice, this means…”, “Translated to business terms…”
Hedging a finding	”The early signal suggests…”, “This is preliminary but…”, “We’d want to validate this before acting on it…”
Recommending action	”Based on this, I’d recommend…”, “The data supports…”, “The most defensible next step is…”
Deferring to domain expertise	”That’s ultimately a business judgment — the data shows X, but whether that’s acceptable is your call.”
Acknowledging a limitation	”One caveat here is…”, “This analysis doesn’t account for…”, “We should note that…”

---

Зв’язані ресурси

• Англійська для інженерів DevOps
• Писання документації API англійською
• Словник: Data Science & ML
• Інформаційна система англійською