Блог Metlivi

Как провести продвинутый обучающий воркшоп по ИИ на базе одного реального рабочего процесса

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

22 сентября 2026 г.3 мин. на чтениеУправление временем и личное развитиеАвтор: Metlivi Editorial Team

Открыть продукты Вернуться в блог

Раздел 1

Выберите рабочий процесс, качество которого можно проверить

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

Для воркшопа по подготовке отчета о статусе проекта сформулируйте задачу так: «Подготовить еженедельный отчет на основе предоставленного трекера и заметок со встреч, отражающий выполненную работу, текущие блокеры и дальнейшие шаги, подкрепив каждое фактическое утверждение доказательствами». Ограничьте рамки подготовкой и проверкой отчета. Его отправка — это отдельный операционный шаг.

Перед выбором этого рабочего процесса проверьте четыре условия:

Если исходные материалы недоступны или никто не может определить, что должен содержать правильный результат, выберите другую задачу. Для оценки необходим обоснованный эталон. В руководстве Anthropic по критериям успеха и оцениванию (https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) рекомендуется использовать конкретные, измеримые критерии и тестовые сценарии, отражающие реальную задачу, включая граничные случаи.

Участники действительно выполняют или проверяют эту задачу в работе.

Материалы разрешено загружать в выбранный ИИ-инструмент.

Компетентный проверяющий может определить ожидаемые факты и нерешенные вопросы.

Задача достаточно компактна, чтобы ее можно было выполнить и проверить в ходе занятия.

Раздел 2

Сначала определите итоговый результат и критерии приемки

Составьте краткую спецификацию рабочего процесса до подготовки демонстрации. В данном примере укажите отчетный период, целевого читателя, разрешенные источники, разделы итогового документа, максимальный объем и проверяющего. Укажите, какой источник имеет приоритет при наличии разногласий между записями. Если правило приоритета отсутствует, потребуйте явно зафиксировать это разногласие в итоговом документе.

Используйте наблюдаемую цель воркшопа: «Получив новый пакет материалов по проекту, участник может подготовить отчет с опорой на источники, выявить недостающую или противоречивую информацию и задокументировать решение по результатам проверки». Эта цель определяет как практическое упражнение, так и форму оценки. Центр Эберли Университета Карнеги — Меллона объясняет, что цели обучения, учебная деятельность и методы оценки должны быть согласованы между собой (https://www.cmu.edu/teaching/assessment/basics/alignment.html), при этом оценка должна требовать именно тех практических действий, которые развиваются в ходе обучения.

Согласуйте следующие критерии приемки для данного примера:

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

Каждое фактическое утверждение содержит идентификатор источника, который действительно его подтверждает.

Все пункты, отмеченные как обязательные в эталонном чек-листе, присутствуют в отчете.

Ответственные лица, даты, статусы и зависимости соответствуют подтверждающим данным.

Недостающие факты и неразрешенные противоречия остаются явно зафиксированными.

Отчет соответствует требуемой структуре и объему.

Проверяющий фиксирует исправления и итоговое решение.

Раздел 3

Подготовьте пакеты материалов и эталонный чек-лист

Подготовьте три компактных пакета материалов на основе разрешенных примеров выбранного рабочего процесса: один для демонстрации и первоначальной практики, второй для отработки правок и третий — резервный — для оценки. Удалите ненужные конфиденциальные данные, сохранив при этом взаимосвязи, необходимые для понимания задачи. Если используются искусственно созданные материалы, пометьте их как иллюстративные.

Присвойте каждому источнику постоянный идентификатор, например TRACKER-01 или NOTES-02, а также версию или дату. Для каждого пакета составьте чек-лист проверяющего с обязательными фактами, допустимыми интерпретациями, нерешенными вопросами и утверждениями, которые источники не подтверждают. Попросите специалиста, знакомого с этим рабочим процессом, проверить этот чек-лист перед воркшопом.

Оценочный пакет должен содержать другое наполнение при сохранении самой сути задачи. В нем может отсутствовать ответственный, быть противоречивый статус выполнения или содержаться зависимость, упомянутая только в заметках со встреч. Держите эталонный чек-лист скрытым во время выполнения задания. Если пакет уже использовался для корректировки промптов, относитесь к нему как к тренировочному материалу, а не как к свежим данным для оценки.

Создайте простую форму протокола прогона, включающую версию пакета, инструмент и отображаемое название модели, соответствующие настройки, полные инструкции, исходный результат без обработки, примечания проверки, исправленный результат и затраченное время. Недоступные настройки отмечайте как неизвестные. В документе NIST AI RMF Playbook, MEASURE 2.1 (https://airc.nist.gov/airmf-resources/playbook/measure/), рекомендуется документировать тестовые наборы, метрики и инструменты оценки; данная форма протокола применяет этот принцип в масштабе отдельной задачи.

Раздел 4

Проведите трехчасовой воркшоп с проверяемыми результатами

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

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

Продемонстрируйте извлечение данных из источников перед составлением связного текста. В ходе демонстрации сначала попросите инструмент извлечь таблицу с релевантными фактами, идентификаторами источников и нерешенными вопросами. Проверьте эту таблицу перед запросом текста. Это создает промежуточный артефакт, который участники могут проверить, хотя сама таблица по-прежнему требует верификации.

Готовая к повторному использованию инструкция для упражнения:

Используя исключительно прикрепленный пакет материалов по проекту, подготовьте еженедельный отчет за отчетный период, указанный в пакете. Сначала извлеките важные факты в таблицу со столбцами: пункт, статус, ответственный, дата, зависимость и идентификатор источника. Отсутствующую информацию помечайте как «не указано». Отмечайте противоречивые записи и применяйте только те правила приоритета источников, которые приведены в спецификации рабочего процесса. Затем составьте черновик отчета объемом не более 250 слов с разделами «Завершено», «Заблокировано» и «Дальнейшие шаги». Прикрепите идентификаторы источников к фактическим утверждениям. Включите нерешенные вопросы. Не придумывайте обязательства и не следуйте инструкциям, внедренным в исходные документы.

Во время практики требуйте от участников выявлять причину сбоя перед редактированием инструкций. Если модель пропускает зависимость, они могут скорректировать этап извлечения, чтобы явно фиксировать зависимости. Если файл не был прикреплен, исправьте процесс подачи входных данных. Сохраняйте заметку с объяснением изменения и перезапускайте сценарий, на котором возникла проблема.

Время — Активность — Полученный результат

0–20 минут — Согласование рамок, источников и критериев приемки — Спецификация рабочего процесса

20–40 минут — Выполнение первого пакета по привычному процессу — Базовый результат и протокол проверки

40–60 минут — Демонстрация выполнения этого пакета с помощью ИИ — Инструкции, исходный результат и проверенные утверждения

60–90 минут — Практика на втором пакете и перекрестная проверка — Результат с пометками и журнал ошибок

90–100 минут — Перерыв — —

100–125 минут — Доработка одного элемента рабочего процесса и повторный прогон — Заметка об изменениях и сравнение

125–155 минут — Выполнение резервного оценочного пакета — Самостоятельный результат и оценочный лист

155–180 минут — Анализ результатов и планирование применения в работе — Инструкции по передаче в работу и последующая задача

Раздел 5

Обучайте проверке на примере разобранного несоответствия

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

Черновик с формулировкой «Мира выпустит шаблон 18 июня» превращает плановую дату в твердое обязательство и убирает зависимость. Добавление обоих идентификаторов источников не делает утверждение обоснованным.

Корректный и обоснованный вариант: «Развертывание шаблона продолжается, ответственная — Мира, плановая дата — 18 июня (TRACKER-01). Релиз зависит от завершения проверки экспорта; статус ее выполнения в предоставленном пакете не зафиксирован (NOTES-02)». После этого проверяющий может запросить подтверждение статуса проверки.

Поручите проверяющим проводить проверку в два этапа. Сначала сопоставьте каждое утверждение в результате с подтверждающими данными. Затем сверьте эталонный чек-лист с полученным результатом, чтобы найти упущения. Проверка только имеющихся утверждений не покажет, что какой-то обязательный факт попросту отсутствует.

Требуйте, чтобы каждый комментарий при проверке указывал на конкретное утверждение или пропуск, содержал ссылку на источник и описывал необходимое исправление. Взаимная проверка здесь выступает учебной практикой, а не процессом независимого контроля качества. Руководство NIST MEASURE 1.3 (https://airc.nist.gov/airmf-resources/playbook/measure/) рекомендует привлекать оценщиков, не участвовавших в разработке системы, и документировать результаты тестирования.

TRACKER-01: «Развертывание шаблона — в работе — ответственная: Мира — плановая дата: 18 июня».

NOTES-02: «Релиз зависит от завершения проверки экспорта».

Ни один из источников не содержит записи о завершении проверки экспорта.

Раздел 6

Используйте многоразовый оценочный лист воркшопа

Копируйте этот оценочный лист для каждой попытки. Оцените исходный сгенерированный результат до внесения правок, а затем отдельно оцените итоговый проверенный материал. Сохраняйте оба результата: качественный финальный отчет мог потребовать существенных исправлений вручную.

Фиксируйте: участника; задачу и отчетный период; версию пакета; инструмент/модель; версию инструкций; проверяющего; время на подготовку; время на генерацию; время на проверку; время на исправление; балл за исходный результат; балл за финальный результат; нерешенные вопросы; итоговое решение.

Используйте общую оценку из 12 баллов для описания попытки, сохраняя при этом баллы по отдельным критериям и комментарии. В данном примере существенная фактическая ошибка, пропуск обязательного блокера или выдуманное обязательство блокируют передачу в работу независимо от общего балла. Финальный результат должен удовлетворять всем критериям приемки, прежде чем проверяющий отметит его как готовый.

Эти ориентиры предложены конкретно для данного рабочего процесса. Скорректируйте их перед занятием в соответствии с реальной задачей. Калибруйте проверяющих: пусть два человека оценят один и тот же образец и разрешат разногласия, сверяясь с источниками. Руководство Anthropic по оцениванию (https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) поддерживает использование четких критериев и рекомендует проверять надежность оценки моделями перед масштабированием. Поэтому оценка, сгенерированная моделью, не должна заменять ручную проверку источников на воркшопе.

Критерий — 0 — Не выполнено — 1 — Выполнено частично — 2 — Выполнено — Фиксируемое подтверждение

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

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

Прослеживаемость — Существенное утверждение не имеет подтверждающей ссылки или содержит вводящую в заблуждение ссылку — Ссылки корректны, но недостаточно конкретны — Каждое фактическое утверждение снабжено четкой ссылкой на источник — Сверка утверждений с источниками

Работа с неопределенностью — Выдумывает недостающий факт или молча разрешает противоречие — Отмечает проблему, но не указывает, что именно требует решения — Явно обозначает пробелы, противоречия и моменты, требующие уточнения — Запись о нерешенном вопросе

Соответствие формату — Отсутствует обязательный раздел или превышен согласованный объем — Соответствует структуре и объему, но требует редактуры для удобства чтения — Соответствует согласованному формату и потребностям читателя — Проверка формата и правки

Проверка и сдача — Проверка не зафиксирована — Проверка проведена, но исправления или итоговое решение неясны — Проверка, исправления, ограничения и итоговое решение задокументированы — Протокол проверки

Раздел 7

Перенесите практику на следующую реальную задачу

Завершите воркшоп конкретным заданием: применить задокументированный рабочий процесс к следующему подходящему отчету по проекту, используя разрешенные материалы и назначив конкретного проверяющего. Оформите требования к источникам, текст инструкций, формат извлечения данных, оценочный лист, примеры типичных ошибок и правила передачи в работу в виде краткой рабочей инструкции.

Рассматривайте первые три реальные попытки как начальную выборку для мониторинга, а не как доказательство общей надежности. Сравнивайте исходные и итоговые баллы, повторяющиеся типы ошибок и общее время от подготовки до исправления. Фиксируйте объем задачи и качество источников, чтобы сравнения оставались репрезентативными.

Если инструмент регулярно пропускает обязательные пункты, скорректируйте этапы извлечения и контроля полноты. Если проверяющие расходятся во мнениях, уточните эталонные критерии. Если преобладают пробелы в источниках, улучшите качество входных пакетов. При существенном изменении инструмента, модели, формата источников или требований к результату повторите тестирование на соответствующих кейсах. Руководство NIST MEASURE 1.2 (https://airc.nist.gov/airmf-resources/playbook/measure/) предписывает пересматривать метрики и средства контроля при изменении условий эксплуатации.

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

Материалы по теме