Gold review после публикации: как завод учится на оценке человека

Когда материал уже опубликован, самая полезная работа только начинается. Внутри production-процесса это обычно называют gold review: человек с устойчивыми правилами оценки смотрит на результат постфактум, фиксирует ошибки, подтверждает удачные решения и переводит наблюдения в обновление промптов, правил и gates.
Смысл не в том, чтобы «поймать плохой ответ». Смысл в том, чтобы создать обучающий след: что именно было сделано правильно, где модель срезала угол, какой gate пропустил проблему и как это поправить без ручного героизма в следующий раз.

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

Что такое gold review в производственном смысле

Gold review — это не просто «оценка качества». Это контрольный разбор эталонным человеком после публикации, где ответ сопоставляется не с ожиданиями автора, а с рабочими критериями системы.

Обычно в таком разборе фиксируют четыре вещи:

1. Правильность фактов и допущений — есть ли ошибка, недосказанность, подмена причины следствием.
2. Соответствие задаче — ответ действительно решает запрос или только выглядит убедительно.
3. Исполнимость — может ли пользователь или внутренний оператор повторить предложенный шаг.
4. Риск — не был ли пропущен безопасностный, юридический, операционный или репутационный барьер.

Важно: gold review нужен не только для плохих случаев. Хороший ответ тоже должен быть разобран, чтобы понять, какой именно шаблон сработал. Тогда завод не просто чинит дефекты, а накапливает повторяемые удачные решения.

Если коротко, gold review отвечает на вопрос:
какое поведение системы мы считаем эталоном, и как сделать так, чтобы оно воспроизводилось чаще?

Почему проверка после публикации полезнее, чем только перед ней

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

Постфактум-проверка даёт три преимущества:

• Есть фактический результат, а не прогноз.
• Можно увидеть, где пропустил gate: промпт, фильтр, маршрут, шаблон ответа или сам критерий качества.
• Можно строить выборку по реальным сбоям, а не по искусственным примерам.

Это особенно полезно для обучения промптов. На этапе разработки легко переоценить текстовую красоту и недооценить операционную устойчивость. После публикации видно, что именно сломалось в живом контуре: слишком широкий ответ, не тот уровень уверенности, лишняя интерпретация, слабая структура, отсутствие развилки «если/то».

Для завода это означает простую вещь: оценка человека становится не финальной печатью, а сырьём для улучшения процесса.

Как устроить контур оценки: от опубликованного ответа к обучающему сигналу

Рабочий контур gold review можно собрать без лишней теории. Нужны не «сложные метрики вообще», а последовательность, по которой каждый кейс проходит одинаково.

1. Сбор опубликованного объекта
   Фиксируется сам ответ, исходный запрос, версия промпта, версия gates, контекст маршрутизации и дата публикации.
2. Назначение ревьюера
   Лучше, если это один из нескольких обученных оценщиков с одинаковой шкалой. Иначе сравнение оценок будет шумным.
3. Оценка по рубрике
   Человек не пишет эссе, а отмечает конкретные поля: что верно, что неверно, какой дефект главный, насколько он критичен.
4. Классификация причины
   Ошибка относится к промпту, к отсутствующему правилу, к неверному gate, к плохому контексту или к неудачной постановке запроса.
5. Решение о действии
   Нужно не просто «поставить низкую оценку», а выбрать следующий шаг: переписать инструкцию, добавить проверку, изменить шаблон, разделить маршрут, усилить отказ.
6. Возврат в библиотеку обучения
   Кейс попадает в набор примеров для промптов, регрессионных тестов и gate-матриц.

Ниже — компактная схема, которая помогает не потерять логику в рутине.

Как переводить человеческую оценку в промпты и gates

Главная ошибка здесь — пытаться «улучшить модель» в целом. В production это слишком расплывчато. Нужно переводить оценку в конкретное изменение управления.

Есть четыре типовых направления.

1. Обновление промпта

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

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

2. Усиление gates

Если ошибка повторяется в чувствительных местах, одного текста промпта мало. Нужен gate: проверка, которая не выпускает ответ без нужного признака.

Например: - нет подтверждения источника — не публикуем; - есть уверенная формулировка без основания — уводим в отказ; - не соблюдён формат — возвращаем на перегенерацию.

3. Разделение маршрута

Иногда проблема не в качестве, а в том, что один и тот же маршрут обслуживает слишком разные типы задач. Тогда gold review показывает, что часть кейсов надо увести в отдельный поток: короткий ответ, проверочный ответ, экспертный ответ, безопасный отказ.

4. Уточнение критериев оценки

Иногда модель отвечает нормально, но человек оценивает её по неявному стандарту. Тогда нужно чинить не ответ, а рубрику. Иначе завод начинает обучаться на размытом сигнале.

Практически это означает: каждый негативный кейс должен заканчиваться не только оценкой, но и назначенным действием.

Как не превратить gold review в ручной музей ошибок

Когда система начинает собирать постфактум-проверки, появляется риск всё утопить в ручном разборе. Тогда люди читают кейсы, спорят о формулировках и ничего не меняют в контуре.

Чтобы этого не случилось, стоит держать несколько правил.

Правило 1. Один кейс — одно главное решение

Не надо превращать разбор в список из десяти замечаний. Выберите первопричину, которая реально улучшит систему, и зафиксируйте её.

Правило 2. Ревьюер смотрит по рубрике, а не по вкусу

Если оценка строится на «нравится / не нравится», learning signal быстро деградирует. Нужны критерии, которые можно применять одинаково.

Правило 3. Ошибка идёт в библиотеку, а не в спор

Цель gold review — не доказать, кто был прав, а создать повторно используемый пример. Спор без фиксации решения не даёт производственного эффекта.

Правило 4. Хорошие кейсы тоже сохраняются

Удачный ответ важен не меньше неудачного. Именно из хороших кейсов завод извлекает устойчивые шаблоны.

Правило 5. После изменения нужен регресс

Если промпт или gate изменили, старый кейс должен пройти повторно. Иначе улучшение останется на уровне намерения.

Короткий рабочий запрос для запуска процесса

Ниже — минимальный запрос, с которого удобно начинать системный gold review.

Рабочий запрос:

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

Этот формат полезен тем, что сразу задаёт не «общее мнение», а рабочий результат.

Минимальный контур внедрения: что делать на следующем цикле

Если строить процесс без лишней сложности, достаточно следующего порядка:

1. Собрать 20–50 опубликованных кейсов.
2. Разметить их одной рубрикой.
3. Выделить 5–7 повторяющихся типов дефектов.
4. Для каждого дефекта назначить одно изменение: промпт, gate, маршрут или критерий.
5. Проверить изменения на старых кейсах.
6. Зафиксировать, что стало лучше, а что осталось шумом.

Ниже — короткий чеклист, который удобно использовать как внутреннее рабочее требование.

• [ ] У каждого опубликованного кейса есть версия промпта и gates
• [ ] Оценка проводится по одной рубрике
• [ ] У каждого дефекта назначена причина
• [ ] У каждого кейса есть следующее действие
• [ ] Хорошие ответы тоже сохраняются как эталоны
• [ ] После изменения запускается регресс-проверка
• [ ] Итоговый вывод попадает в библиотеку обучения

Что в итоге получает завод

Gold review после публикации полезен не как отдельная церемония, а как механизм накопления производственной памяти. Он связывает человеческую оценку с конкретными изменениями в промптах, gates и маршрутах. Это особенно важно там, где качество нельзя удерживать одной универсальной инструкцией.

Хорошо поставленный процесс делает три вещи одновременно:
он показывает, что система уже умеет;
он вскрывает, где она ошибается;
и он превращает оба наблюдения в следующий рабочий релиз.

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