#метрики — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #метрики, aggregated by home.social.
-
Правда ли, что медицинский ИИ точнее врачей? Наш фреймворк помогает это выяснить
Привет, Хабр! Меня зовут Илья Копаничук, я старший научный сотрудник лаборатории «Сильный ИИ в медицине» AIRI. Мы с коллегами создаём ИИ‑инструменты, задача которых сделать качественную медицину доступнее. Например, основанное на нашей технологии приложение «Помощник по здоровью» стало лучшим ИИ‑решением в клиентском сервисе по версии Generation AI Awards 2025 . Но речь сегодня не об этом. За время нашей работы мы поняли, что контроль качества ИИ‑диагностики в медицине — это одна из ключевых задач, которая, как оказалось, не была ещё достаточно хорошо решена. Во‑первых, тесты для медицинских моделей зачастую далеки от реальной практики. А во‑вторых, всегда ли точны люди? Пытаясь ответить на эти вопросы, мы с помощью коллег из ФГБУ «НМИЦ им. В. А. Алмазова» Минздрава России собрали собственный фреймворк и опубликовали про него статью в Scientific Reports . Здесь я расскажу, как он устроен и на какие метрики мы обратили внимание, а также постараюсь дать ответ на вопрос, заданный в заголовке.
-
Ежедневный ряд подписчиков в MAX: публичный эндпоинт, четыре грабли и почему not_found — не измерение
У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru. Ниже — как устроен сбор и четыре места, где мы ошиблись. Самая дорогая ошибка стоила трёх ночей молчащего ряда при зелёном логе и exit 0: парсер на любую неудачу писал один статус not_found, а под него попадали три разных события — канала нет, max.ru сменил формат, нас затроттлило. Пока они не разделены, скрипт ничего не измеряет — он производит число, похожее на измерение.
https://habr.com/ru/articles/1080198/
#MAX #мессенджер_MAX #парсинг #SvelteKit #SQLite #каталог_каналов #firstparty_данные #обработка_ошибок #антинакрутка #метрики
-
Ежедневный ряд подписчиков в MAX: публичный эндпоинт, четыре грабли и почему not_found — не измерение
У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru. Ниже — как устроен сбор и четыре места, где мы ошиблись. Самая дорогая ошибка стоила трёх ночей молчащего ряда при зелёном логе и exit 0: парсер на любую неудачу писал один статус not_found, а под него попадали три разных события — канала нет, max.ru сменил формат, нас затроттлило. Пока они не разделены, скрипт ничего не измеряет — он производит число, похожее на измерение.
https://habr.com/ru/articles/1080198/
#MAX #мессенджер_MAX #парсинг #SvelteKit #SQLite #каталог_каналов #firstparty_данные #обработка_ошибок #антинакрутка #метрики
-
Ежедневный ряд подписчиков в MAX: публичный эндпоинт, четыре грабли и почему not_found — не измерение
У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru. Ниже — как устроен сбор и четыре места, где мы ошиблись. Самая дорогая ошибка стоила трёх ночей молчащего ряда при зелёном логе и exit 0: парсер на любую неудачу писал один статус not_found, а под него попадали три разных события — канала нет, max.ru сменил формат, нас затроттлило. Пока они не разделены, скрипт ничего не измеряет — он производит число, похожее на измерение.
https://habr.com/ru/articles/1080198/
#MAX #мессенджер_MAX #парсинг #SvelteKit #SQLite #каталог_каналов #firstparty_данные #обработка_ошибок #антинакрутка #метрики
-
Prometheus и VictoriaMetrics: почему одни и те же метрики могут занимать в 139 раз больше места
Меня зовут Стас Погоржельский, я технологический евангелист VK Cloud и последние месяцы гоняю Prometheus и VictoriaMetrics на одном стенде, чтобы понять, сколько на самом деле стоит одна точка метрики на диске. Обе системы делают одно и то же: принимают миллионы точек в минуту, хранят их месяцами и быстро отдают в алерты и дашборды. Обе сжимают точку до байтов и долей байта. Именно эти байты, умноженные на миллиарды точек в сутки, превращаются в счёт за диск. Ошибка в расчёте цены сэмпла заканчивается переполненным диском под мониторингом, урезанным retention или незапланированным расходом. Когда место под метрики кончается, первым на планёрке звучит «сменим движок». Публичные бенчмарки подталкивают к тому же: Флант показывает, что Prom++, форк Prometheus, тратит памяти в 7,8 раза меньше Prometheus v2 ( разбор на Habr ), VictoriaMetrics показывает трёхкратную экономию диска против Grafana Mimir ( бенчмарк VictoriaMetrics , замер вендора, 2022 год). На моём стенде картина оказалась сложнее. В Prometheus 3.13 и VictoriaMetrics 1.149 ушёл один и тот же набор: 2,88 млн сэмплов, шесть профилей данных, один генератор с фиксированным seed. Внутри одного движка цена сэмпла различалась в 139 раз у VictoriaMetrics и в 12,8 раза у Prometheus. Между движками на одних данных разрыв доходил до 30,7 раза на шести профилях и до 34,3 раза в опыте с точностью. На равномерно случайных float64 движки менялись местами. Один лишний знак после запятой поднимал цену сэмпла у Prometheus в восемь раз, у VictoriaMetrics на 12%.
https://habr.com/ru/companies/vk/articles/1068798/
#vk_cloud #prometheus #victoriametrics #time_series #tsdb #мониторинг #метрики #observability #сжатие_данных #cardinality
-
Prometheus и VictoriaMetrics: почему одни и те же метрики могут занимать в 139 раз больше места
Меня зовут Стас Погоржельский, я технологический евангелист VK Cloud и последние месяцы гоняю Prometheus и VictoriaMetrics на одном стенде, чтобы понять, сколько на самом деле стоит одна точка метрики на диске. Обе системы делают одно и то же: принимают миллионы точек в минуту, хранят их месяцами и быстро отдают в алерты и дашборды. Обе сжимают точку до байтов и долей байта. Именно эти байты, умноженные на миллиарды точек в сутки, превращаются в счёт за диск. Ошибка в расчёте цены сэмпла заканчивается переполненным диском под мониторингом, урезанным retention или незапланированным расходом. Когда место под метрики кончается, первым на планёрке звучит «сменим движок». Публичные бенчмарки подталкивают к тому же: Флант показывает, что Prom++, форк Prometheus, тратит памяти в 7,8 раза меньше Prometheus v2 ( разбор на Habr ), VictoriaMetrics показывает трёхкратную экономию диска против Grafana Mimir ( бенчмарк VictoriaMetrics , замер вендора, 2022 год). На моём стенде картина оказалась сложнее. В Prometheus 3.13 и VictoriaMetrics 1.149 ушёл один и тот же набор: 2,88 млн сэмплов, шесть профилей данных, один генератор с фиксированным seed. Внутри одного движка цена сэмпла различалась в 139 раз у VictoriaMetrics и в 12,8 раза у Prometheus. Между движками на одних данных разрыв доходил до 30,7 раза на шести профилях и до 34,3 раза в опыте с точностью. На равномерно случайных float64 движки менялись местами. Один лишний знак после запятой поднимал цену сэмпла у Prometheus в восемь раз, у VictoriaMetrics на 12%.
https://habr.com/ru/companies/vk/articles/1068798/
#vk_cloud #prometheus #victoriametrics #time_series #tsdb #мониторинг #метрики #observability #сжатие_данных #cardinality
-
Prometheus и VictoriaMetrics: почему одни и те же метрики могут занимать в 139 раз больше места
Меня зовут Стас Погоржельский, я технологический евангелист VK Cloud и последние месяцы гоняю Prometheus и VictoriaMetrics на одном стенде, чтобы понять, сколько на самом деле стоит одна точка метрики на диске. Обе системы делают одно и то же: принимают миллионы точек в минуту, хранят их месяцами и быстро отдают в алерты и дашборды. Обе сжимают точку до байтов и долей байта. Именно эти байты, умноженные на миллиарды точек в сутки, превращаются в счёт за диск. Ошибка в расчёте цены сэмпла заканчивается переполненным диском под мониторингом, урезанным retention или незапланированным расходом. Когда место под метрики кончается, первым на планёрке звучит «сменим движок». Публичные бенчмарки подталкивают к тому же: Флант показывает, что Prom++, форк Prometheus, тратит памяти в 7,8 раза меньше Prometheus v2 ( разбор на Habr ), VictoriaMetrics показывает трёхкратную экономию диска против Grafana Mimir ( бенчмарк VictoriaMetrics , замер вендора, 2022 год). На моём стенде картина оказалась сложнее. В Prometheus 3.13 и VictoriaMetrics 1.149 ушёл один и тот же набор: 2,88 млн сэмплов, шесть профилей данных, один генератор с фиксированным seed. Внутри одного движка цена сэмпла различалась в 139 раз у VictoriaMetrics и в 12,8 раза у Prometheus. Между движками на одних данных разрыв доходил до 30,7 раза на шести профилях и до 34,3 раза в опыте с точностью. На равномерно случайных float64 движки менялись местами. Один лишний знак после запятой поднимал цену сэмпла у Prometheus в восемь раз, у VictoriaMetrics на 12%.
https://habr.com/ru/companies/vk/articles/1068798/
#vk_cloud #prometheus #victoriametrics #time_series #tsdb #мониторинг #метрики #observability #сжатие_данных #cardinality
-
Как оценивать эффективность разработки
Меня зовут Антон Омельяненко, я Head of Software Development в EXANTE. Менеджер управляет командой так, чтобы она приносила бизнесу результат. Чтобы понимать, насколько хорошо люди справляются с задачами, ему нужны данные о работе и система оценки. С разработкой это сложнее, чем кажется. В статье я разберу три вопроса: почему классические метрики не подходят для оценки эффективности разработчиков, как измерять её правильно и что делать, если вам кажется, что сотрудник работает не только на вас.
https://habr.com/ru/articles/1067558/
#продуктивность #удаленка #ии #эффективность #аналитика #метрики #разработка_по #gitlab #jira
-
6 ошибок в метриках дефектов, из-за которых QA теряет контроль над качеством
Дашборд зеленеет, число багов падает, команда получает похвалу — а через пару недель прод ловит инцидент на ровном месте. Так бывает, когда метрики дефектов становятся целью для отчёта и начинают подменять реальное управление качеством. В статье — шесть типовых ошибок: от количества багов как личного KPI до доли переоткрытых задач, которую легко обойти красивой статистикой.
https://habr.com/ru/companies/otus/articles/1047054/
#QA #метрики #тестирование #QALead #управлениекачеством #баги #escaperate #DRE #reopenrate