Среднее геометрическое и среднее гармоническое: формулы и примеры

Что такое среднее геометрическое и среднее гармоническое простыми словами

Любое среднее отвечает на вопрос: каким одним числом заменить все значения, чтобы итог не изменился. Различие в том, какой итог сохраняется. Среднее арифметическое сохраняет сумму, среднее геометрическое — произведение, среднее гармоническое — сумму обратных величин.

Отсюда области применения. Если значения перемножаются — рост на 10%, затем ещё на 20%, — нужен общий множитель, и его даёт геометрическое. Если значения — отношения с одинаковым числителем (километры в час на равных участках пути, рубли за литр при равных суммах), итог складывается из обратных величин, и подходит гармоническое.

• Оба определены только для положительных чисел, и всегда H ≤ G ≤ A, где A — среднее арифметическое.
• Геометрическое — для темпов роста и других множителей; гармоническое — для скоростей, цен и других отношений при равных числителях.
• В Excel это функции СРГЕОМ и СРГАРМ, в Python — scipy.stats.gmean и hmean, в SQL — EXP(AVG(LN(x))) и COUNT(*) / SUM(1.0 / x).

Как найти среднее геометрическое: формула и пример

Перемножьте все числа и извлеките корень той степени, сколько чисел. Для двух чисел это квадратный корень: среднее геометрическое 2 и 8 равно √(2 · 8) = √16 = 4. Для трёх — кубический: у 2, 4 и 8 произведение равно 64, ∛64 = 4.

Проверка смысла: замените каждое число на 4, и произведение останется прежним — 4 · 4 · 4 = 64. Среднее арифметическое тех же чисел равно 4,67, и этого свойства у него нет: 4,67³ ≈ 102. Геометрически 4 — ребро куба того же объёма, что брусок 2 × 4 × 8.

Корень высокой степени считать неудобно, поэтому на практике идут через логарифмы: среднее геометрическое — экспонента от среднего арифметического логарифмов.

Как найти среднее гармоническое: формула и пример

Возьмите обратные величины, сложите и разделите на эту сумму количество чисел. Для 2 и 8: 1/2 + 1/8 = 0,625, и 2 / 0,625 = 3,2.

Классическая задача. Машина едет 120 км туда со скоростью 60 км/ч и 120 км обратно со скоростью 40 км/ч. На дорогу ушло 2 + 3 = 5 часов, значит, средняя скорость — 240 / 5 = 48 км/ч, а вовсе не 50. Это среднее гармоническое 60 и 40: медленный участок занимает больше времени и поэтому весит больше.

Если бы машина ехала два часа со скоростью 60 и два часа со скоростью 40, ответом было бы обычное среднее, 50 км/ч. Изменилось то, что у участков одинаково: в первом случае путь (числитель отношения «километры в час»), во втором время (знаменатель).

Почему гармоническое не больше геометрического, а геометрическое — арифметического

Для любых положительных чисел H ≤ G ≤ A, и равенство наступает, только когда все числа одинаковы. У 2 и 8 это 3,2 < 4 < 5. Справка Microsoft к функции СРГАРМ пишет жёстче — «всегда меньше», — но у набора 7, 7, 7 все три средних равны 7.

Для двух чисел неравенство видно на чертеже. Отложите отрезки 2 и 8 подряд и постройте полукруг на их сумме как на диаметре. Любой радиус равен среднему арифметическому, 5. Перпендикуляр из точки стыка до дуги — геометрическому, 4. Проведите радиус в верхний конец перпендикуляра: проекция перпендикуляра на этот радиус — гармоническое, 3,2. В обоих прямоугольных треугольниках катет короче гипотенузы: 3,2 < 4 и 4 < 5. Для двух чисел есть и точная связь: G² = A · H, здесь 16 = 5 · 3,2. Для трёх и более она в общем случае не выполняется.

Зазор между средними растёт вместе с разбросом. В учебной базе у DAU (числа активных пользователей за день) за 1–29 августа коэффициент вариации 9%, и три средних почти сливаются: 486,9, 485,0 и 483,1. За все 90 полных дней, где DAU менялся от 32 до 586, они расходятся: 328,5, 284,0 и 225,0.

Зачем аналитику среднее геометрическое: средний темп роста

Темпы роста перемножаются. Выручка выросла на 50%, потом упала на 50%: 100 → 150 → 75. Среднее арифметическое темпов — ноль, «в среднем ничего не изменилось», хотя четверть выручки исчезла. Среднее геометрическое множителей 1,5 и 0,5 равно 0,866, то есть −13,4% за период, и два таких шага дают ровно 75.

Теперь на данных. В учебной базе продукта «Маяк» 12 полных недель, с 1 июня по 23 августа; последняя неделя выгрузки неполная, и запрос её отсекает. Регистраций в первую неделю 196, в двенадцатую — 481. Между ними 11 недельных множителей: от ×1,32 в неделю кампании 15–16 июля до ×0,88 сразу после неё.

Среднее арифметическое множителей — 1,0893, «рост на 8,9% в неделю». Проверка обратным пересчётом: 196 · 1,0893¹¹ ≈ 502 регистрации вместо 481. Среднее геометрическое — 1,0850, и 196 · 1,0850¹¹ ≈ 481. Совпадение не заслуга метода: произведение одиннадцати множителей и есть 481 / 196, так что этот темп попадает в последнюю точку по построению и ничего не знает о неделях между краями. Арифметическое всегда не меньше геометрического, поэтому пересчёт по нему завышает итог: здесь на 21 регистрацию (4,4%).

С выручкой оно уже не мелочь. В первую неделю прошло три оплаты на 67 долларов, во вторую выручка выросла в 8,2 раза, дальше рост замедлялся. Среднее арифметическое множителей — 1,8756, «плюс 88% в неделю»; пересчёт по нему даёт к двенадцатой неделе 67 695 долларов при фактических 3 893, в 17 раз больше. Среднее геометрическое, 1,4467, возвращает 3 893. Почти весь разрыв создаёт один шаг — ×8,2 от базы в три оплаты: первые оплаты пришли 6 июня, и первая неделя по выручке состоит из двух дней. Если начать со второй недели, средние равны 1,245 и 1,217, а пересчёт по арифметическому даёт 4 912 долларов — на 26% больше факта. Ошибка осталась, но стала правдоподобной, и этим опаснее.

На графике видно и второе свойство. Геометрическая кривая сходится с фактом в первой и последней точке, а между ними идёт далеко от него: на шестой неделе она показывает 425 долларов при фактических 2 098. Темп 44,7% в неделю не описывает ход ряда: во вторую и третью недели выручка росла в 8,2 и в 2 раза, в четвёртую — на 45%, с пятой — на 7–25% в неделю с одним падением на 14%.

WITH weekly AS (
  SELECT 'signups' AS metric, DATE_TRUNC('week', signup_date) AS week_start,
    1.0 * COUNT(*) AS value
  FROM users
  WHERE signup_date < DATE '2026-08-24'
  GROUP BY DATE_TRUNC('week', signup_date)
  UNION ALL
  SELECT 'revenue', DATE_TRUNC('week', paid_at), SUM(amount)
  FROM payments
  WHERE paid_at < DATE '2026-08-24'
  GROUP BY DATE_TRUNC('week', paid_at)
),
rates AS (
  SELECT metric,
    value / LAG(value) OVER (PARTITION BY metric ORDER BY week_start) AS k,
    FIRST_VALUE(value) OVER (PARTITION BY metric ORDER BY week_start) AS first_value
  FROM weekly
)
SELECT metric,
  COUNT(k) AS steps,
  ROUND(AVG(k), 4) AS arithmetic,
  ROUND(EXP(AVG(LN(k))), 4) AS geometric,
  ROUND(MAX(first_value) * POWER(AVG(k), COUNT(k)), 0) AS replay_arithmetic,
  ROUND(MAX(first_value) * POWER(EXP(AVG(LN(k))), COUNT(k)), 0) AS replay_geometric
FROM rates
GROUP BY metric
ORDER BY metric DESC;

Как посчитать среднее геометрическое в SQL, Python и Excel

В стандартном SQL и в PostgreSQL агрегата «произведение» нет, и он не нужен: логарифм превращает произведение в сумму. В DuckDB есть product() и готовый geomean(), но переносимая запись — EXP(AVG(LN(k))): она работает в обоих движках одинаково.

В Python это scipy.stats.gmean, в Excel — функция СРГЕОМ: =СРГЕОМ(B2:B12) по столбцу множителей. Справка Microsoft приводит именно этот сценарий — средние темпы роста при переменных ставках.

Связь с CAGR. Среднее геометрическое темпов можно получить по двум точкам: (481 / 196)^(1/11) = 1,0850. Формула CAGR, совокупного среднегодового темпа роста, та же самая, только шаг равен году: (конец / начало)^(1 / число лет) − 1.

import numpy as np
from scipy import stats

signups = np.array([196, 223, 249, 273, 300, 326, 429, 377, 404, 430, 454, 481])
k = signups[1:] / signups[:-1]                 # 11 недельных множителей

arithmetic = k.mean()
geometric = stats.gmean(k)                     # то же: np.exp(np.log(k).mean())
by_endpoints = (signups[-1] / signups[0]) ** (1 / len(k))

print(f"{arithmetic:.4f} {geometric:.4f} {by_endpoints:.4f}")
print(round(signups[0] * arithmetic ** len(k)), round(signups[0] * geometric ** len(k)))

Когда нужно среднее гармоническое: цена, средний чек и F1-мера

Гармоническое среднее появляется там, где усредняют отношение, а одинаков у наблюдений числитель. Классический пример — закупка на равные суммы: дважды заправились на 3 000 ₽, по 50 и по 60 ₽ за литр. Литров вышло 60 и 50, средняя цена — 6 000 / 110 = 54,55 ₽ вместо 55.

Рабочий пример на учебной базе. В таблице оплат три тарифа с фиксированной ценой: basic — 19 долларов, pro — 29, team — 39. Менеджер спрашивает, сколько в среднем приносит одна оплата. Среднее трёх цен — 29 долларов. Фактический средний чек — 30 639 долларов выручки на 1 251 оплату, то есть 24,49. Простое среднее завысило его на 18%: на дешёвый basic приходится 56% оплат, на team — 11%.

Гармоническое среднее трёх цен, 26,61, тоже не совпадает с чеком. Оно было бы верным, если бы тарифы приносили одинаковую выручку: при 21 489 долларах на каждый (19 · 29 · 39) вышла бы 1 131, 741 и 551 оплата, и чек 64 467 / 2 423 = 26,61. Простое арифметическое было бы верным при одинаковом числе оплат. В данных не равно ни то, ни другое — нужны веса.

Правило весов. Известны знаменатели (число оплат) — берите арифметическое среднее, взвешенное по ним. Известны только числители (выручка по тарифам и прайс-лист) — гармоническое, взвешенное по выручке: Σвыручка / Σ(выручка / цена). Оба пути дают 24,49, потому что сводятся к «вся выручка / все оплаты». В Excel =СРГАРМ(A2:A4) считает простое гармоническое, весов у функции нет.

Так же устроена F1-мера классификатора — среднее гармоническое precision (доли подтвердившихся сигналов) и recall (доли найденных случаев). В матрице из статьи о чувствительности и специфичности 170 верных сигналов, 294 ложных и 30 пропусков: precision 36,64%, recall 85%, их среднее арифметическое — 60,8%, F1 — 51,2%. Числитель у обеих долей общий, верные сигналы, поэтому F1 = 2·TP / (2·TP + FP + FN) = 340 / 664. Модель, помечающая всех подряд, в той же выборке (200 нарушителей на 10 000) получит recall 100% и precision 2%: среднее арифметическое 51%, F1 — 3,9%.

WITH by_plan AS (
  SELECT plan, COUNT(*) AS payments, SUM(amount) AS revenue, AVG(amount) AS price
  FROM payments
  GROUP BY plan
)
SELECT
  ROUND(AVG(price), 2) AS simple_mean,
  ROUND(COUNT(*) / SUM(1.0 / price), 2) AS simple_harmonic,
  ROUND(SUM(price * payments) / SUM(payments), 2) AS weighted_by_payments,
  ROUND(SUM(revenue) / SUM(revenue / price), 2) AS harmonic_by_revenue,
  ROUND(SUM(revenue) / SUM(payments), 2) AS real_check
FROM by_plan;

import numpy as np
from scipy import stats

price = np.array([19, 29, 39])                  # basic, pro, team
revenue = np.array([13414, 11687, 5538])        # выручка по тарифам
payments = revenue / price                      # 706, 403, 142 оплаты

print(price.mean())                                      # простое среднее цен
print(round(stats.hmean(price), 2))                      # простое гармоническое
print(round(stats.hmean(price, weights=revenue), 2))     # гармоническое, веса — выручка
print(round(np.average(price, weights=payments), 2))     # арифметическое, веса — оплаты
print(round(revenue.sum() / payments.sum(), 2))          # вся выручка / все оплаты

Что делать с нулями и отрицательными значениями

Оба средних определены только для положительных чисел. Ноль обнуляет произведение, а с ним и среднее геометрическое; в гармоническом на ноль пришлось бы делить. Инструменты реагируют по-разному: LN(0) в PostgreSQL и DuckDB останавливает запрос ошибкой, СРГЕОМ и СРГАРМ при любом значении ≤ 0 возвращают #ЧИСЛО!, а scipy.stats.gmean и hmean молча возвращают 0.

В учебной базе это не теория. За 90 полных дней, с 1 июня по 29 августа (30 августа выгрузка обрывается днём и исключена), оплат не было семь дней: 1–5, 9 и 11 июня. Запрос с GROUP BY paid_at этих дней не увидит: строк нет — нет и нулей. Среднее геометрическое по 83 дням с оплатами, 302,32 доллара, — это уже «типичный день с оплатами»: семь пустых дней выпали из расчёта молча. Сумму оно не восстанавливает ни при каком числе дней — её даёт только среднее арифметическое по всем 90 дням: 332,42 · 90 = 29 918. Геометрическое для уровня берут как устойчивую к хвосту оценку типичного дня, и нули ломают именно её.

Популярная заплатка — прибавить единицу, усреднить и вычесть: EXP(AVG(LN(x + 1))) - 1. Она даёт 193,71 доллара, но зависит от единиц: для выручки в центах та же формула вернёт 135,51 доллара. Надёжнее показать долю нулевых дней (7 из 90) и среднее геометрическое по остальным либо укрупнить шаг: недель без оплат в базе нет.

В темпах роста ноль означает падение на 100%: среднее геометрическое множителей становится нулём, а следующий шаг, рост с нуля, не определён. В дневной выручке так выглядят 8–10 июня: 77, 0 и 58 долларов. PostgreSQL на делении 58 / 0 остановится с ошибкой, DuckDB вернёт бесконечность, а запрос без календаря поделит 58 на 77 и получит множитель 0,75 за шаг, в котором на самом деле два дня.

Отрицательные значения — прибыль, изменение в процентах — тоже вне области определения. Частая ошибка — подать в функцию проценты прироста вместо множителей: для ряда +13,8%, +11,7%, −12,1% scipy.stats.gmean вернёт nan и предупреждение. Сначала переведите проценты в множители (1,138, 1,117, 0,879), усредните и вычтите единицу.

WITH calendar AS (
  SELECT CAST(g.d AS date) AS day
  FROM generate_series(TIMESTAMP '2026-06-01', TIMESTAMP '2026-08-29', INTERVAL '1 day') AS g(d)
),
daily AS (
  SELECT c.day, COALESCE(SUM(p.amount), 0) AS revenue
  FROM calendar AS c
  LEFT JOIN payments AS p ON p.paid_at = c.day
  GROUP BY c.day
)
SELECT
  COUNT(*) AS days,
  COUNT(*) FILTER (WHERE revenue = 0) AS zero_days,
  ROUND(AVG(revenue), 2) AS mean_all_days,
  ROUND(AVG(NULLIF(revenue, 0)), 2) AS mean_paid_days,
  ROUND(EXP(AVG(LN(NULLIF(revenue, 0)))), 2) AS geometric_paid_days,
  ROUND(EXP(AVG(LN(revenue + 1))) - 1, 2) AS geometric_plus_one
FROM daily;

Где ещё эти средние обманывают: края ряда, малые окна, точность

Сдвиг края меняет темп. Для регистраций за первые семь недель окно заканчивается неделей кампании, и выходит 13,9% в неделю; с восьмой неделей — 9,8%. Когда нужен темп по всему ряду, строят прямую по логарифмам значений (REGR_SLOPE(LN(value), номер_недели)); exp(наклон) − 1 даёт для регистраций 8,4% в неделю, для выручки — 29,4% против 44,7% по краям.

Малые окна. Четыре недели подряд — это три множителя. По всем таким окнам «средний недельный темп» регистраций гуляет от 0,1% до 16,3%: первое из этих окон начинается неделей кампании, второе ею заканчивается. И темп 8,5% по 12 неделям нельзя продлевать на следующий квартал: в последней неделе есть платный поиск, которого в первой не было (канал запущен 1 июля). Кампания 15–16 июля на эти 8,5% не повлияла никак — она внутри ряда.

Точность. Перемножать и извлекать корень «в лоб» нельзя уже на сотнях значений. Перемножьте суммы всех 1 251 оплат — выйдет число порядка 10¹⁷¹⁸: float64 вмещает около 10³⁰⁸, и np.prod возвращает inf. Через логарифмы тот же расчёт даёт 23,62 доллара.

Чувствительность гармонического к малым значениям. Одно малое значение решает всё: промо-тариф за 1 доллар опускает гармоническое цен с 26,61 до 3,59, арифметическое — только с 29 до 22. В задаче о скорости такой перекос оправдан: медленный участок съедает почти всё время. В отчёте о ценах он обычно означает, что забыты веса.

import numpy as np
from scipy import stats

amounts = np.repeat([19.0, 29.0, 39.0], [706, 403, 142])    # суммы всех 1 251 оплаты
print(np.prod(amounts))                                     # inf: произведение не помещается в float64
print(round(np.exp(np.log(amounts).mean()), 2), round(stats.gmean(amounts), 2))

print(stats.gmean([4, 0, 9]), stats.hmean([4, 0, 9]))       # ноль обнуляет оба средних
print(stats.gmean([13.8, 11.7, -12.1]))                     # проценты прироста вместо множителей

Какое среднее когда применять

Выбор определяется тем, что происходит со значениями в итоге: складываются они, перемножаются или делят общий числитель. Проверка одна: подставьте среднее вместо каждого значения и посмотрите, сохранился ли итог — сумма, конечный уровень, общее время.

Частые вопросы

Где среднее геометрическое встречается в геометрии? В прямоугольном треугольнике высота, проведённая к гипотенузе, равна среднему геометрическому отрезков, на которые она делит гипотенузу. На чертеже с полукругом это перпендикуляр длиной 4 над отрезками 2 и 8.

Может ли среднее геометрическое быть нулём или отрицательным? По формуле с корнем ноль среди чисел даёт G = 0, но СРГЕОМ и расчёт через логарифмы такой набор не принимают. Отрицательные числа не усредняют вовсе: у −2 и −8 корень из произведения равен +4, и такое «среднее» лежит вне диапазона значений.

Как посчитать средний темп роста в Excel? Запишите множители (значение, делённое на предыдущее) в столбец, примените СРГЕОМ и вычтите 1. Если известны только крайние значения, возведите их отношение в степень 1 / число шагов.

Когда брать среднее гармоническое, а когда взвешенное арифметическое? Гармоническое — когда у отношений одинаковые числители: равный путь, равная сумма закупки. Взвешенное арифметическое — когда известны знаменатели: число оплат, пользователей, часов. Оба расчёта обязаны совпасть с «сумма числителей / сумма знаменателей».

Что попробовать на учебной базе

Запросы из статьи выполняются в песочнице симулятора SQL-аналитика: база там та же. Первое упражнение: посчитайте средний недельный темп роста WAU — числа пользователей хотя бы с одним событием за неделю — за те же 12 недель. В запросе о темпах замените первую ветку на таблицу events, DATE_TRUNC('week', event_time) и COUNT(DISTINCT user_id) с условием event_time < TIMESTAMP '2026-08-24'. Должно получиться: 11 шагов, среднее арифметическое множителей 1,2590, геометрическое 1,2376; пересчёт по арифметическому даёт 2 469 пользователей вместо фактических 2 045.

Второе: уберите из выручки четыре недели разгона условием paid_at >= DATE '2026-06-29'. Останется семь шагов, арифметическое 1,1231, геометрическое 1,1160, пересчёт 4 071 доллар против 3 893: разрыв сжался с 17 раз до 4,6%. Какое из двух чисел, 44,7% или 11,6% в неделю, вы поставили бы в отчёт о текущем росте?