Краткий ответ: Определите, что означает «хороший» результат для вашего конкретного случая, затем протестируйте с помощью репрезентативных, версионированных подсказок и граничных случаев. Сочетайте автоматизированные метрики с оценкой, проводимой человеком, а также с проверками на безопасность при столкновении и проверками на внедрение подсказок. Если ограничения по стоимости или задержке становятся обязательными, сравните модели по успешности выполнения задачи на единицу затраченных средств и времени отклика p95/p99.
Основные выводы:
Ответственность : Назначайте четких ответственных лиц, ведите журналы версий и повторно запускайте оценки после любого запроса или изменения модели.
Прозрачность : Прежде чем начать сбор оценок, запишите критерии успеха, ограничения и издержки, связанные с неудачей.
Проверяемость : Поддерживайте воспроизводимые наборы тестов, размеченные наборы данных и отслеживаемые метрики задержки p95/p99.
Возможность оспаривания : Используйте критерии оценки, применяемые людьми, и четко определенный порядок обжалования для спорных результатов.
Устойчивость к злоупотреблениям : внедрение вредоносного ПО командой «красных», деликатные темы и чрезмерный отказ защищать пользователей.
Если вы выбираете модель для продукта, исследовательского проекта или даже внутреннего инструмента, вы не можете просто сказать: «Звучит умно» и выпустить её (см. руководство по оценке OpenAI и NIST AI RMF 1.0 ). Именно так вы получаете чат-бота, который уверенно объясняет, как разогреть вилку в микроволновке. 😬
Статьи, которые могут вас заинтересовать после этой:
🔗 Будущее ИИ: тенденции, определяющие следующее десятилетие.
Ключевые инновации, влияние на рынок труда и этические аспекты, за которыми следует следить в будущем.
🔗 Базовые модели генеративного ИИ: объяснение для начинающих.
Узнайте, что это такое, как они обучаются и почему они важны.
🔗 Как ИИ влияет на окружающую среду и энергопотребление.
Изучите выбросы, спрос на электроэнергию и способы уменьшения экологического следа.
🔗 Как работает масштабирование с помощью ИИ для получения более четких изображений сегодня.
Узнайте, как модели добавляют детали, удаляют шум и обеспечивают чистое увеличение.
1) Определение понятия «хороший» (это зависит от ситуации, и это нормально) 🎯
Прежде чем проводить какую-либо оценку, определите, что для вас означает успех. В противном случае вы будете измерять всё подряд и ничего не узнаете. Это как взять рулетку, чтобы оценить торт на конкурсе. Конечно, вы получите цифры, но они мало что вам скажут 😅
Объяснить:
-
Цели пользователя : составление резюме, поиск, написание текста, рассуждение, извлечение фактов.
-
Цена неудачи : неправильная рекомендация фильма — это смешно; неправильная медицинская инструкция — это… не смешно (формулировка риска: NIST AI RMF 1.0 ).
-
Среда выполнения : на устройстве, в облаке, за брандмауэром, в регулируемой среде.
-
Основные ограничения : задержка, стоимость запроса, конфиденциальность, объяснимость, многоязычная поддержка, регулировка тональности.
Модель, которая «лучше всего» справляется с одной работой, может оказаться катастрофой в другой. Это не противоречие, это реальность. 🙂
2) Как выглядит надежная система оценки моделей ИИ 🧰
Да, именно этот этап люди пропускают. Они берут бенчмарк, запускают его один раз и на этом останавливаются. Надежная система оценки обладает несколькими неизменными характеристиками (практические примеры инструментов: OpenAI Evals / руководство по OpenAI evals ):
-
Повторяемость гарантирована — вы можете повторить эксперимент на следующей неделе и доверять результатам сравнения.
-
Репрезентативность — это отражение реальных пользователей и выполняемых ими задач (а не просто мелочи).
-
Многоуровневая система — сочетает автоматизированные метрики + проверку человеком + состязательные тесты.
-
Практически применимые результаты — они показывают, что нужно исправить, а не просто «рейтинг снизился».
-
Защита от несанкционированного вскрытия — предотвращает «обучение под тест» или случайную протечку.
-
Экономически обоснованный подход — сама процедура оценки не должна вас разорить (если, конечно, вы не любите боль).
Если ваша оценка не выдерживает критики со стороны коллеги, который говорит: «Хорошо, но сопоставьте это с производственной средой», значит, работа еще не завершена. Это проверка на соответствие общему настроению.
3) Как оценивать модели ИИ, начиная с анализа конкретных сценариев использования 🍰
Вот один приём, который сэкономит кучу времени: разбейте задачу на части .
Вместо «оцените модель» сделайте следующее:
-
Понимание намерений (получает ли система то, что хочет пользователь)
-
Использование контекста или поиск информации (правильно ли используется предоставленная информация)
-
Логическое мышление / многоэтапные задачи (сохраняется ли согласованность между этапами)
-
Форматирование и структура (соответствует ли это инструкциям)
-
Соответствие требованиям безопасности и политики (избегает ли это небезопасного контента; см. NIST AI RMF 1.0 )
-
Тон и фирменный стиль (звучит ли он так, как вы хотите)
Благодаря этому курс «Как оценивать модели ИИ» воспринимается не как один большой экзамен, а скорее как набор целенаправленных тестов. Тесты, конечно, раздражают, но их можно пройти. 😄
4) Основы офлайн-оценки — тестовые наборы, метки и не самые привлекательные детали, которые имеют значение 📦
Офлайн-оценка — это проведение контролируемых тестов до того, как пользователи начнут что-либо тестировать (шаблоны рабочих процессов: оценки OpenAI ).
Создайте или соберите набор тестов, который будет действительно принадлежать вам
Хороший набор тестовых данных обычно включает в себя:
-
Золотые примеры : идеальные результаты, которые вы с гордостью бы отправили на рынок.
-
Крайние случаи : неоднозначные подсказки, неаккуратный ввод, неожиданное форматирование.
-
Проверки на наличие отказов : подсказки, которые провоцируют галлюцинации или небезопасные ответы (формулировка теста риска: NIST AI RMF 1.0 ).
-
Охват разнообразия : разные уровни навыков пользователей, диалекты, языки, предметные области.
Если вы будете тестировать только на «чистых» запросах, модель будет выглядеть потрясающе. Но потом ваши пользователи начнут писать с опечатками, обрывками предложений и проявлять агрессию, кликая мышкой. Добро пожаловать в реальность.
Варианты маркировки (или уровни строгости)
Вы можете присвоить выходным данным следующие метки:
-
Двоичная система : проходной/непроходной балл (быстрый, строгий).
-
Порядковая шкала : оценка качества от 1 до 5 (тонкая, субъективная)
-
Многокритериальный подход : точность, полнота, тон, использование цитат и т. д. (лучший, худший вариант)
Многоатрибутивный подход — оптимальный вариант для многих команд. Это как дегустация еды, когда соленость оценивается отдельно от текстуры. В противном случае вы просто говорите «хорошо» и пожимаете плечами.
5) Показатели, которые не лгут, и показатели, которые вроде бы лгут 📊😅
Показатели ценны… но они также могут быть похожи на бомбу из блесток. Блестящие, повсюду, и их трудно убрать.
Общие семейства метрик
-
Точность / точное совпадение : отлично подходит для извлечения, классификации и структурированных задач.
-
F1 / точность / полнота : полезны, когда пропуск чего-либо хуже, чем лишний шум (определения: точность/полнота/F-мера в scikit-learn ).
-
Пересечение стилей BLEU и ROUGE : подходит для задач, связанных с обобщением, но часто вводит в заблуждение (исходные метрики: BLEU и ROUGE ).
-
Встраивание сходства : полезно для семантического сопоставления, может поощрять неправильные, но похожие ответы.
-
Показатель успешности выполнения задачи : «получил ли пользователь то, что ему было нужно» — это золотой стандарт при условии четкого определения задачи.
-
Соответствие ограничениям : соблюдение формата, длины, корректности JSON, соответствия схеме.
Ключевой момент
Если ваша задача имеет открытый характер (письменное задание, логическое мышление, общение в чате поддержки), то однозначные показатели могут быть… ненадежными. Не бессмысленными, просто ненадежными. Измерить креативность линейкой возможно, но вы будете чувствовать себя глупо, делая это. (А еще вы, вероятно, выколете себе глаз.)
Итак: используйте метрики, но привязывайте их к экспертной оценке и реальным результатам выполнения задач (один из примеров обсуждения оценки на основе LLM + оговорки: G-Eval ).
6) Таблица сравнения — лучшие варианты оценки (с некоторыми особенностями, потому что в жизни бывают свои особенности) 🧾✨
Вот практичный набор подходов к оценке. Комбинируйте и подбирайте. Большинство команд так и делают.
| Инструмент/Метод | Аудитория | Цена | Почему это работает |
|---|---|---|---|
| Набор тестов, созданных вручную по запросу | Продукт + инженер | $ | Очень целенаправленный, быстро выявляет регрессии, но его нужно поддерживать постоянно 🙃 (начальный инструмент: OpenAI Evals ) |
| экспертная комиссия по оценке | Команды, которые могут выделить рецензентов | $$ | Лучше всего подходит для передачи тона, нюансов, вопроса «принял бы это человек», возможен небольшой хаос в зависимости от оценок |
| Кандидат на получение степени магистра права в качестве судьи (с критериями оценки) | Быстрые циклы итерации | $-$$ | Быстрый и масштабируемый, но может содержать предвзятые оценки, и иногда оценки отражают субъективное восприятие, а не факты (исследования + известные проблемы предвзятости: G-Eval ). |
| Состязательный спринт по борьбе с противниками | Безопасность + соответствие требованиям | $$ | Обнаруживает опасные режимы сбоев, особенно быстрое внедрение угроз — ощущения как на стресс-тесте в спортзале (обзор угроз: OWASP LLM01 Быстрое внедрение угроз / OWASP Топ-10 для приложений LLM ) |
| Генерация синтетических тестов | Команды, работающие с минимальным объемом данных | $ | Отличное покрытие, но синтетические подсказки могут быть слишком аккуратными, слишком вежливыми… пользователи невежливы |
| A/B-тестирование с участием реальных пользователей | Зрелые продукты | $$$ | Самый ясный сигнал — и одновременно самый эмоционально напряженный, когда показатели колеблются (классическое практическое руководство: Кохави и др., «Контролируемые эксперименты в интернете» ). |
| Оценка на основе полученных данных (проверки RAG) | Приложения для поиска и вопросов и ответов | $$ | Меры, которые «правильно используют контекст», снижают завышение оценок галлюцинаций (Обзор оценки RAG: Оценка RAG: Опрос ). |
| Мониторинг + обнаружение дрейфа | Производственные системы | $$-$$$ | Выявляет признаки деградации с течением времени — незаметен до того дня, пока не спасет вас 😬 (обзор дрейфа концепции: исследование дрейфа концепции (PMC) ) |
Обратите внимание, что цены намеренно занижены. Они зависят от масштаба, используемого оборудования и количества случайно созданных вами встреч.
7) Человеческая оценка — секретное оружие, которое люди недофинансируют 👀🧑⚖️
Если вы будете проводить только автоматизированную оценку, вы упустите следующее:
-
Несоответствие тона («почему это так язвительно?»)
-
Незаметные фактические ошибки, которые выглядят естественно
-
Вредные коннотации, стереотипы или неуклюжие формулировки (формулировка риска + предвзятости: NIST AI RMF 1.0 )
-
Неудачи в выполнении инструкций, которые всё ещё звучат «умно»
Сделайте критерии оценки конкретными (иначе рецензенты будут импровизировать)
Неудачная критерий оценки: «Полезность»
. Лучшая критерий оценки:
-
Корректность : фактически верна с учетом задания и контекста.
-
Полнота : охватывает необходимые пункты без лишних рассуждений.
-
Четкость : читабельность, структурированность, минимальное количество путаницы.
-
Политика/безопасность : избегает контента с ограниченным доступом, эффективно обрабатывает отказы (формулировка, обеспечивающая безопасность: NIST AI RMF 1.0 )
-
Стиль : соответствует голосу, тону, уровню чтения.
-
Верность : не выдумывает источники или утверждения, не подтвержденные фактами.
Кроме того, иногда проводите межэкспертную проверку. Если два рецензента постоянно расходятся во мнениях, это не «проблема людей», а проблема критериев оценки. Обычно (основы межэкспертной надежности: МакХью о коэффициенте Каппа Коэна ).
8) Как оценивать модели ИИ с точки зрения безопасности, надежности и «фу, пользователей» 🧯🧪
Это то, что нужно сделать перед запуском — и продолжать делать, потому что интернет никогда не спит.
Тесты на устойчивость, в том числе
-
Опечатки, сленг, грамматические ошибки
-
Очень длинные и очень короткие задания
-
Противоречивые инструкции («будьте кратки, но укажите все детали»)
-
Многоэтапные диалоги, в которых пользователи меняют свои цели
-
Попытки немедленного внедрения («игнорируйте предыдущие правила…») (подробности угрозы: OWASP LLM01 Немедленное внедрение )
-
Деликатные темы, требующие осторожного отказа (формулировка рисков/безопасности: NIST AI RMF 1.0 )
Оценка безопасности – это не просто вопрос «отказывается ли устройство»
Хорошая модель должна:
-
Отказывайтесь от небезопасных запросов четко и спокойно (руководящие принципы: NIST AI RMF 1.0 ).
-
При необходимости предоставляйте более безопасные альтернативы
-
Избегайте чрезмерного отклонения безобидных запросов (ложных срабатываний)
-
В случае неоднозначных запросов задавайте уточняющие вопросы (если это допустимо)
Чрезмерный отказ — это реальная проблема продукта. Пользователям не нравится, когда к ним относятся как к подозрительным гоблинам. 🧌 (Даже если они и есть подозрительные гоблины.)
9) Стоимость, задержка и операционные реалии — оценка, о которой все забывают 💸⏱️
Модель может быть «потрясающей», но при этом не подходить вам, если она медленная, дорогая или ненадежная в эксплуатации.
Оценивать:
-
Распределение задержки (не только среднее значение — важны p95 и p99) (почему важны процентили: см. Google SRE Workbook по мониторингу )
-
Стоимость за успешно выполненное задание (а не стоимость за токен отдельно).
-
Стабильность под нагрузкой (тайм-ауты, ограничения скорости, аномальные всплески)
-
Надежность вызова инструментов (если они используют функции, как они себя ведут)
-
Тенденции к увеличению длины выходных данных (некоторые модели слишком длинные, а длинные тексты стоят денег).
Немного худшая модель, но вдвое быстрее, может победить на практике. Это звучит очевидно, но люди игнорируют это. Как, например, купить спортивный автомобиль для поездки в магазин, а потом жаловаться на недостаток места в багажнике.
10) Простой сквозной рабочий процесс, который вы можете скопировать (и доработать) 🔁✅
Вот практический алгоритм оценки моделей ИИ, позволяющий избежать бесконечных экспериментов:
-
Определение успеха : задача, ограничения, издержки неудачи.
-
Создайте небольшой «базовый» набор тестов : 50-200 примеров, отражающих реальное использование.
-
Добавьте наборы угроз и состязательных ситуаций : попытки внедрения кода, неоднозначные подсказки, проверки безопасности (класс внедрения подсказок: OWASP LLM01 ).
-
Выполните автоматическую проверку : форматирование, корректность JSON, по возможности — базовую правильность.
-
Провести проверку человеком : проанализировать результаты по различным категориям и оценить их с помощью критериев оценки.
-
Сравните компромиссы : качество против стоимости против задержки против безопасности
-
Пилотный проект в ограниченном объеме : A/B-тестирование или поэтапное внедрение (руководство по A/B-тестированию: Kohavi et al. )
-
Мониторинг в процессе производства : дрейф, регрессии, циклы обратной связи с пользователями (обзор дрейфа: опрос о дрейфе концепции (PMC) )
-
Итерация : обновление запросов, получение данных, тонкая настройка, контрольные точки, затем повторный запуск оценки (шаблоны итерации оценки: руководство по оценке OpenAI ).
Ведите версионные записи. Не потому что это весело, а потому что в будущем вы поблагодарите себя, держа в руках чашку кофе и бормоча: «Что же изменилось…» ☕🙂
11) Распространенные ошибки (иначе говоря, способы, которыми люди случайно обманывают самих себя) 🪤
-
Обучение к тесту : вы оптимизируете подсказки до тех пор, пока результаты теста не станут отличными, но пользователи страдают.
-
Утечка данных для оценки : тестовые подсказки появляются в обучающих данных или данных для тонкой настройки (ой!).
-
Поклонение одному показателю : погоня за одним результатом, который не отражает ценность для пользователя.
-
Игнорирование сдвига распределения : изменение поведения пользователей приводит к незаметному ухудшению вашей модели (формулировка производственного риска: опрос о дрейфе концепции (PMC) ).
-
Чрезмерное внимание к «уму» : хитроумные рассуждения не имеют значения, нарушают ли они форматирование или выдумывают факты.
-
Не тестируется качество отказа : «Нет» может быть правильным ответом, но всё равно это ужасный пользовательский опыт.
Также остерегайтесь демо-версий. Демо-версии похожи на трейлеры к фильмам. В них показывают лучшие моменты, скрывают затянутые сцены и иногда обманывают зрителей драматической музыкой. 🎬
12) Заключительное резюме о том, как оценивать модели ИИ 🧠✨
Оценка моделей ИИ — это не просто один балл, это сбалансированное питание. Вам нужны белки (точность), овощи (безопасность), углеводы (скорость и стоимость), и да, иногда десерт (вкус и удовольствие) 🍲🍰 (формулировка рисков: NIST AI RMF 1.0 )
Если вы ничего больше не запомните:
-
Определите, что означает «хорошо» для вашего конкретного случая использования
-
Используйте репрезентативные тестовые наборы, а не только известные бенчмарки
-
Сочетайте автоматизированные метрики с ручной проверкой критериев
-
Проверяйте надежность и безопасность так, как будто пользователи настроены враждебно (потому что иногда… так оно и есть) (класс внедрения подсказок: OWASP LLM01 )
-
Учитывайте стоимость и задержку при оценке, а не рассматривайте их как второстепенный фактор (почему важны процентили: см. Google SRE Workbook ).
-
Мониторинг после запуска — модели меняются, приложения развиваются, люди проявляют креативность (обзор изменений: Опрос по изменению концепций (PMC) )
Вот как оценивать модели ИИ таким образом, чтобы они оставались работоспособными, когда ваш продукт запущен и люди начинают делать непредсказуемые вещи. А это происходит постоянно. 🙂
Часто задаваемые вопросы
Какой первый шаг в оценке моделей искусственного интеллекта для реального продукта?
Начните с определения того, что означает «хорошо» для вашего конкретного случая. Четко сформулируйте цель пользователя, во сколько вам обойдутся неудачи (с низкими и высокими рисками) и где будет работать модель (облако, устройство, регулируемая среда). Затем перечислите жесткие ограничения, такие как задержка, стоимость, конфиденциальность и регулировка тональности. Без этой основы вы будете проводить множество измерений и все равно примете неверное решение.
Как мне создать набор тестов, который действительно отражает потребности моих пользователей?
Создайте набор тестов, который будет действительно вашим, а не просто общедоступным эталоном. Включите в него эталонные примеры, которые вы с гордостью бы выпустили, а также тестовые запросы, имитирующие реальные условия эксплуатации, с опечатками, неполными предложениями и неоднозначными формулировками. Добавьте граничные случаи и проверки на наличие ошибок, которые могут привести к галлюцинациям или небезопасным ответам. Учитывайте разнообразие уровней квалификации, диалектов, языков и областей применения, чтобы результаты не давали сбоев в продакшене.
Какие показатели следует использовать, а какие могут ввести в заблуждение?
Сопоставляйте метрики с типом задачи. Точное совпадение и достоверность хорошо подходят для извлечения информации и структурированных результатов, в то время как точность/полнота и F1 помогают, когда пропуск чего-либо хуже, чем лишний шум. Метрики перекрытия, такие как BLEU/ROUGE, могут вводить в заблуждение при решении задач с открытым ответом, а учет сходства может поощрять «неправильные, но похожие» ответы. Для написания текстов, поддержки или рассуждений сочетайте метрики с результатами проверки человеком и показателями успешности выполнения задачи.
Как мне структурировать оценочные процедуры, чтобы они были воспроизводимыми и подходили для практического применения?
Надежная система оценки должна быть воспроизводимой, репрезентативной, многоуровневой и пригодной для практического применения. Сочетайте автоматизированные проверки (формат, валидность JSON, базовая корректность) с оценкой, проводимой людьми, и состязательными тестами. Обеспечьте защиту от несанкционированного доступа, избегая утечек информации и «обучения на основе результатов теста». Учитывайте стоимость оценки, чтобы можно было проводить ее часто, а не только один раз перед запуском.
Как лучше всего проводить оценку человеком, не допуская при этом хаоса?
Используйте четкую систему критериев оценки, чтобы рецензенты не импровизировали. Оценивайте такие характеристики, как правильность, полнота, ясность, соблюдение правил безопасности, соответствие стиля/голоса и достоверность (отсутствие выдуманных утверждений или источников). Периодически проверяйте согласованность оценок между рецензентами; если мнения рецензентов постоянно расходятся, система критериев, вероятно, нуждается в доработке. Человеческая проверка особенно полезна при несоответствии тона, незначительных фактических ошибках и несоблюдении инструкций.
Как оценить безопасность, надежность и риски, связанные с немедленным введением препарата?
Протестируйте с использованием «ужасных» запросов пользователей: опечатки, сленг, противоречивые инструкции, очень длинные или очень короткие подсказки, а также многоэтапные изменения целей. Включите попытки внедрения подсказок, например, «игнорировать предыдущие правила», и деликатные темы, требующие осторожного отказа. Хорошая безопасность заключается не только в отказе, но и в четком отказе, предложении более безопасных альтернатив, когда это уместно, и избегании чрезмерного отказа на безобидные вопросы, которые вредят пользовательскому опыту.
Как оценить стоимость и задержку таким образом, чтобы это соответствовало реальности?
Не ограничивайтесь измерением средних значений — отслеживайте распределение задержек, особенно p95 и p99. Оценивайте стоимость выполнения одной успешной задачи, а не стоимость токена в отрыве от остальных, поскольку повторные попытки и нестабильные выходные данные могут свести на нет экономию. Проверяйте стабильность под нагрузкой (тайм-ауты, ограничения скорости, скачки) и надежность вызовов инструментов/функций. Немного худшая модель, но вдвое быстрее или стабильнее, может оказаться лучшим выбором.
Каков простой комплексный алгоритм оценки моделей искусственного интеллекта?
Определите критерии успеха и ограничения, затем создайте небольшой базовый набор тестов (примерно 50–200 примеров), имитирующий реальное использование. Добавьте наборы тестов с использованием уязвимостей и состязательных примеров для проверки безопасности и попыток внедрения кода. Запустите автоматизированные проверки, затем выберите примеры выходных данных для оценки специалистами. Сравните качество, стоимость, задержку и безопасность, проведите пилотное тестирование с ограниченным внедрением или A/B-тестированием и отслеживайте изменения и регрессии в производственной среде.
Какими наиболее распространенными способами команды случайно обманывают сами себя при оценке моделей?
К распространённым ловушкам относятся оптимизация подсказок для достижения наилучшего результата в бенчмарке, в то время как пользователи страдают, включение подсказок для оценки в обучающие или корректирующие данные, а также поклонение единственному показателю, не отражающему ценность для пользователя. Команды также игнорируют изменение распределения, чрезмерно акцентируют внимание на «интеллектуальности» вместо соответствия формату и верности ему, а также пропускают тестирование качества отказов. Демонстрационные версии могут скрывать эти проблемы, поэтому полагайтесь на структурированные оценки, а не на краткие обзоры.
Ссылки
-
OpenAI - Руководство по оценке OpenAI - platform.openai.com
-
Национальный институт стандартов и технологий (NIST) — Рамочная программа управления рисками в области ИИ (AI RMF 1.0) — nist.gov
-
OpenAI - openai/evals (репозиторий GitHub) - github.com
-
scikit-learn - precision_recall_fscore_support - scikit-learn.org
-
Ассоциация вычислительной лингвистики (ACL Anthology) - BLEU - aclanthology.org
-
Ассоциация вычислительной лингвистики (антология ACL) - ROUGE - aclanthology.org
-
arXiv - G-Eval - arxiv.org
-
OWASP - LLM01: Быстрое внедрение - owasp.org
-
OWASP - OWASP Top 10 для приложений с большими языковыми моделями - owasp.org
-
Стэнфордский университет - Кохави и др., «Контролируемые эксперименты в интернете» - stanford.edu
-
arXiv - Оценка RAG: обзор - arxiv.org
-
PubMed Central (PMC) - Исследование дрейфа концепций (PMC) - nih.gov
-
PubMed Central (PMC) - МакХью о каппа Коэна - nih.gov
-
Google - Рабочая тетрадь SRE по мониторингу - google.workbook