Спасет ли нас Human-in-the-loop?
Этот текст вырос из разговора с приятелем. Он пишет статью с неожиданным заходом: что если к AI-агентам попробовать применить логику авиационной сертификации? Не в смысле красивой метафоры, а как инженерную дисциплину надёжности: уровни риска, отказоустойчивость, каскадные сбои, контроль точек отказа.
Все это — попытка собрать более строгий ответ на проблему галлюцинаций и агентных отказов. Потому что тот самый human-in-the-loop проблему не всегда лечит. Если агенты ошибаются каскадно, человек, посаженный на проверку результатов за агентами, не обязательно разрывает эту каскадность. Очень часто он просто оказывается встроен в ту же самую цепь.
Я слушал и узнавал свои интервью, которые провожу для научной работы. Когда я расспрашивал стартапы, как они борются с галлюцинациями, практически все отвечали одно и то же: ручной контроль результата. Кто-то мягче, кто-то жёстче, но в сухом остатке — потом глазами проверяем.
Звучит логично. Но здесь есть неприятный инженерный нюанс. Человек, встроенный в процесс как обязательный согласователь на каждом шаге, не всегда повышает надёжность системы. Часто он её снижает. Последовательная цепочка надёжна не по самому сильному звену, а по всей цепи. Агент сделал шаг, второй что-то уточнил, человек подтвердил, дальше следующий этап. Каждый обязательный элемент добавляет не только контроль, но и новую точку отказа: задержку, невнимательность, усталость, потерю контекста, формальное «ок».
Человек в такой архитектуре — не гарант качества. Это просто ещё один компонент системы. Причем компонент с ограниченным вниманием, контекстной усталостью и вполне человеческой способностью через две недели превратить проверку в ритуальное нажатие approve. В длинных агентных цепочках это видно особенно ясно. Если человек подтверждает каждый шаг, быстро происходит одно из трех. Либо он одобряет все подряд, либо тормозит процесс, либо вмешивается в решение, контекст которого давно живёт внутри цепочки, а не у него в голове.
Во всех трёх случаях human-in-the-loop превращается в human-as-bottleneck. А это уже вопрос не процесса, а вопрос архитектуры принятия решений. Ключевой вопрос теперь не в том, оставляем ли мы человека в контуре, а в том, какую функцию выполняет человек: обязательного верификатора или обработчика исключений.
Между этими функциями огромная пропасть. Первая стоит на каждом шаге и всё одобряет. Вторая подключается только там, где появляется риск, неопределенность, конфликт, высокая цена ошибки или стратегический выбор. Стандартные случаи система проходит сама. Человек нужен не там, где надо ещё раз глазами посмотреть на результат. Человек нужен там, где ситуация неоднозначна. Где цена ошибки выходит за рамки локального процесса. Где есть этический, юридический, репутационный или стратегический риск. Где система столкнулась с ситуацией, для которой у неё ещё нет правила.
Поэтому проблема с human-in-the-loop не в том, что человек больше не нужен. Это слишком примитивный вывод. Проблема в том, что многие проектируют human-in-the-loop как управление тревожностью — своей и руководства, — а не как архитектуру надежности. Раз мы не доверяем AI до конца, пусть человек посмотрит итоговый результат.
Но «пусть человек посмотрит» — это не архитектура. Это жест самоуспокоения. Архитектура начинается там, где мы честно отвечаем на другой вопрос: в какой момент человек действительно повышает надежность системы, а в какой просто становится еще одной точкой отказа?
Здесь как раз пригодны старые инструменты safety engineering — FMEA и FTA. Не потому что AI-организация буквально похожа на самолет, а потому что они заставляют задать правильный вопрос: какой именно отказ мы пытаемся предотвратить? Не «пусть человек посмотрит», а где агент может выдумать факт, где потерять контекст, где передать ошибку дальше, где несколько агентов могут ошибиться одинаково, где guard может пропустить сбой.
Так что будущее AI-организаций, скорее всего, будет не в том, чтобы везде оставить человека в контуре. А в том, чтобы наконец понять, в каком именно контуре человек нужен.
Этот текст вырос из разговора с приятелем. Он пишет статью с неожиданным заходом: что если к AI-агентам попробовать применить логику авиационной сертификации? Не в смысле красивой метафоры, а как инженерную дисциплину надёжности: уровни риска, отказоустойчивость, каскадные сбои, контроль точек отказа.
Все это — попытка собрать более строгий ответ на проблему галлюцинаций и агентных отказов. Потому что тот самый human-in-the-loop проблему не всегда лечит. Если агенты ошибаются каскадно, человек, посаженный на проверку результатов за агентами, не обязательно разрывает эту каскадность. Очень часто он просто оказывается встроен в ту же самую цепь.
Я слушал и узнавал свои интервью, которые провожу для научной работы. Когда я расспрашивал стартапы, как они борются с галлюцинациями, практически все отвечали одно и то же: ручной контроль результата. Кто-то мягче, кто-то жёстче, но в сухом остатке — потом глазами проверяем.
Звучит логично. Но здесь есть неприятный инженерный нюанс. Человек, встроенный в процесс как обязательный согласователь на каждом шаге, не всегда повышает надёжность системы. Часто он её снижает. Последовательная цепочка надёжна не по самому сильному звену, а по всей цепи. Агент сделал шаг, второй что-то уточнил, человек подтвердил, дальше следующий этап. Каждый обязательный элемент добавляет не только контроль, но и новую точку отказа: задержку, невнимательность, усталость, потерю контекста, формальное «ок».
Человек в такой архитектуре — не гарант качества. Это просто ещё один компонент системы. Причем компонент с ограниченным вниманием, контекстной усталостью и вполне человеческой способностью через две недели превратить проверку в ритуальное нажатие approve. В длинных агентных цепочках это видно особенно ясно. Если человек подтверждает каждый шаг, быстро происходит одно из трех. Либо он одобряет все подряд, либо тормозит процесс, либо вмешивается в решение, контекст которого давно живёт внутри цепочки, а не у него в голове.
Во всех трёх случаях human-in-the-loop превращается в human-as-bottleneck. А это уже вопрос не процесса, а вопрос архитектуры принятия решений. Ключевой вопрос теперь не в том, оставляем ли мы человека в контуре, а в том, какую функцию выполняет человек: обязательного верификатора или обработчика исключений.
Между этими функциями огромная пропасть. Первая стоит на каждом шаге и всё одобряет. Вторая подключается только там, где появляется риск, неопределенность, конфликт, высокая цена ошибки или стратегический выбор. Стандартные случаи система проходит сама. Человек нужен не там, где надо ещё раз глазами посмотреть на результат. Человек нужен там, где ситуация неоднозначна. Где цена ошибки выходит за рамки локального процесса. Где есть этический, юридический, репутационный или стратегический риск. Где система столкнулась с ситуацией, для которой у неё ещё нет правила.
Поэтому проблема с human-in-the-loop не в том, что человек больше не нужен. Это слишком примитивный вывод. Проблема в том, что многие проектируют human-in-the-loop как управление тревожностью — своей и руководства, — а не как архитектуру надежности. Раз мы не доверяем AI до конца, пусть человек посмотрит итоговый результат.
Но «пусть человек посмотрит» — это не архитектура. Это жест самоуспокоения. Архитектура начинается там, где мы честно отвечаем на другой вопрос: в какой момент человек действительно повышает надежность системы, а в какой просто становится еще одной точкой отказа?
Здесь как раз пригодны старые инструменты safety engineering — FMEA и FTA. Не потому что AI-организация буквально похожа на самолет, а потому что они заставляют задать правильный вопрос: какой именно отказ мы пытаемся предотвратить? Не «пусть человек посмотрит», а где агент может выдумать факт, где потерять контекст, где передать ошибку дальше, где несколько агентов могут ошибиться одинаково, где guard может пропустить сбой.
Так что будущее AI-организаций, скорее всего, будет не в том, чтобы везде оставить человека в контуре. А в том, чтобы наконец понять, в каком именно контуре человек нужен.