Есть фраза, которую произносят с таким лицом, будто цитируют закон сохранения энергии:
— ИИ может быть отличным исполнителем, но суждение о результате должно оставаться за человеком!
Красиво. Уверенно. И всё время хочется спросить одно: а почему, собственно, ДОЛЖНО?
Не «удобно ли», не «привычно ли», не «страшно ли отпустить» — а именно это железобетонное «обязано». Кто выдал обязанность? Где она записана? Звучит не как вывод из практики, а как установка, которую очень не хочется проверять.
Что на самом деле защищают этим «обязано»
Давайте честно про то, что стоит за словом. Когда человек говорит «суждение обязано остаться за мной», он редко имеет в виду техническое ограничение. Чаще стоит вопрос: почему вы не можете, не умеете или не хотите возложить и эту часть на LLM?
Возможны как минимум три причины: нет подходящего процесса, нет навыка формализации критериев или нет желания менять роль человека в пайплайне. «Не можете» — значит не разобрались, как это делается. «Не умеете» — то же самое, только честнее. «Не хотите» — в этом случае речь уже не о техническом ограничении, а о мотивации, потому что именно за «не хочу» обычно и прячется настоящий мотив.
Делегировать оценку результата сложно там, где критерии качества не формализованы. Для этого нужны критерии, тестовые примеры и процедура проверки. Но почему вы с таким упорством ей сопротивляетесь? Упорство — это не про сложность. Сложность сама по себе не доказывает неделегируемость задачи. Упорство — это когда решать не хотят, потому что решение отбирает что-то приятное.
Model-as-a-judge — не ракетостроение, а курс от вендора
Теперь к фактуре, потому что «суждение неделегируемо» рушится о простую вещь: в индустрии для этого давно есть официальный термин.
Model as a judge — когда вторая модель оценивает результат генерации от первой. Одна модель делает, другая судит. Ровно та самая «оценка результата», которую секунду назад объявили сакральной человеческой прерогативой, — вынесена в отдельный, описанный, повторяемый шаг пайплайна.
Это уже распространённый инженерный приём в LLM-пайплайнах. Этому учат на курсах от вендоров AI. Это применяют в продакшне в задачах автопроверки, ранжирования и контроля качества генерации. Пока одни объясняют, почему судить может только человек, другие уже вынесли часть оценки в автоматизированные проверки и model-as-a-judge.
Где действительно есть нюанс — а где ограничение связано скорее с привычкой, чем с технической невозможностью
Честно про границы, потому что иначе получится второй миф, только с обратным знаком.
Да, чисто технически нюансы есть. И зависят они от того, что именно вы отдаёте на суд.
| Что оцениваем | Инструментарий | Зрелость автоматизации |
|---|---|---|
| Качество кода | линтеры, тесты, метрики покрытия, статический анализ, бенчмарки, вторая модель на ревью | хорошо автоматизируется для формальных свойств: прохождения тестов, стиля, типовых ошибок и соответствия требованиям |
| Генерация живописи (вкус, композиция, «цепляет / не цепляет») | формализуется тяжело | придётся повозиться |
| Тексты, отчёты, структурированные данные, ответы поддержки, черновики решений | эталонные примеры, рубрикаторы, вторая модель, метрики | реализуемо во многих бизнес-задачах при наличии критериев, примеров и допустимого уровня ошибки |
Между двумя крайностями — не пропасть, а спектр. Многие промежуточные варианты можно автоматизировать, если есть повторяемый формат результата и понятные критерии оценки. Тексты, отчёты, структурированные данные, ответы поддержки, черновики решений — это классы задач, где часть оценки можно передать рубрикатору, тестам или второй модели.
Практическая граница проходит иначе: она есть, но она подвижная. Она проходит не между «человеком» и «машиной». Она проходит между «уже формализовали критерий» и «ещё не формализовали». По мере появления данных, критериев и инструментов эта граница может сдвигаться.
Так вот про кресло
Утверждать, что человек вот прям «обязан» сохранять за собой суждение, слишком универсально и плохо описывает реальные различия между задачами. Не потому что человек не должен ничего решать — конечно решает, и будет. А потому что «обязан» в универсальной, безусловной форме — это уже не про работу. Это попытка ложными установками сохранить за человеком роль финального контролёра без проверки, действительно ли она нужна в этой задаче.
Вот в чём фокус. «Суждение неделегируемо» — не наблюдение о природе ИИ. Это непроверенное обобщение для того, кто заметил, что исполнение у него забрали, и торопится застолбить хоть какую-то функцию, которую считают принципиально неделегируемой. Оценку результата часто объявляют последней зоной, которую нельзя автоматизировать не потому, что она неотдаваема, а потому что за неё ещё можно подержаться.
Такая позиция мешает проверять, какие части оценки действительно можно автоматизировать.
Что с этим делать, если не греть кресло
Перестаньте спрашивать «должен ли человек судить». Спросите другое: какой именно критерий оценки я сейчас держу в голове — и можно ли его вынести наружу? Если можете сформулировать, что такое «хороший результат» в вашей задаче, — вы уже наполовину его делегировали. Дальше нужно выбрать механизм проверки: вторую модель, тесты, эталонные примеры, метрику и пороги приемлемости.
Останется то, что действительно требует человека: задать сам критерий, поймать случай, который в критерий не влез, и решить, когда критерий пора менять. Это не мало. Ценность человека смещается к постановке критериев, разбору исключений и пересмотру правил оценки. Но это — конкретная работа с подвижной границей, а не священная обязанность, выданная навечно.
Разница между двумя позициями: первый двигает границу делегируемого, второй сидит по её сторону и объясняет, почему двигать нельзя. Первый пересматривает процесс по мере развития инструмента. Второй защищает неизменную роль человека без проверки, можно ли часть оценки формализовать.
Так что в следующий раз, когда услышите «суждение обязано оставаться за человеком» — задайте тот самый вопрос. Это принципиальное ограничение задачи или пока неформализованный критерий оценки?