Где остаётся человек, решают для каждого процесса до сборки. Граница, проведённая потом, превращается в согласование, которое никто не читает.
Содержание6 разделов
Галочка вместо решения
В большинстве коммерческих предложений по ИИ участие человека выглядит как галочка: её поставили, клиент успокоился, разговор перешёл к срокам.
Потом система запускается, в очереди на проверку набирается по четыреста элементов в день, и к третьей неделе кто-то разгребает её пачками в шесть вечера не читая. Согласовано девяносто девять процентов, и в журнале записано, что человек согласовал каждый элемент.
Это хуже, чем вовсе без проверки, потому что остаётся документальное подтверждение надзора, которого не было.
Граница своя для каждого процесса
Чтобы провести полезную границу, нужно ответить на один вопрос: во что здесь обходится неверный результат.
- Обратимо, внутренне, дёшево исправить: работает без проверки человеком, но под мониторингом.
- Уходит клиенту, необратимо или дорого откатывать: решение принимает человек до вступления в силу.
Эти две категории редко совпадают с отделами, системами или должностями, поэтому общая политика компании всегда проводит границу не там. Ошибка в черновике внутренней заметки и ошибка в сообщении клиенту относятся к разным видам, и одного правила на обе не хватит.
Четыре правила, к которым это сводится на практике, описаны в тексте безопасный ИИ и участие человека.
Что попадает в техническое задание
Его пишут до сборки, а не после, и в нём три пункта. Проверяющему показывают не голый результат, а всё, что нужно для решения: источник, оценку уверенности, то, как решались похожие случаи на прошлой неделе. Спрашивают его о конкретном, и у вопроса немного вариантов ответа, потому что приглашение «взгляните» ничего не проверяет. И заранее записано, что происходит при отклонении: элемент возвращается в очередь, уходит конкретному человеку или переходит на ручной путь.
Последний пункт чаще всего оставляют неопределённым, а именно от него зависит, настоящая ли проверка: отклонение, которому некуда идти, рано или поздно становится согласованием.
Как измерить, работает ли проверка
Для этого есть два числа, и оба неудобные.
Первое - доля отклонений. Если она около нуля, проверки на деле нет, и панель не отличит точную систему от непрочитанной очереди.
Второе - медианное время решения. За четыре секунды ничего не решают.
Когда оба числа плохие, дело обычно не в дисциплине: границу провели слишком широко, и проверяющий не справляется с потоком. Если сузить её до результатов, ошибка в которых действительно стоит денег, внимание вернётся туда, где оно нужно.
Что ломается без этого этапа
Сбоев два, они противоположны по форме и одинаковы по исходу.
Если граница слишком строгая, получается очередь, которую никто не разбирает честно. Если слишком свободная, первая необратимая ошибка покажет, где граница должна была проходить, причём на глазах у клиента.
Причина у обоих одна: границу провели, когда система уже работала, и провёл её тот, кто оказался рядом, когда всё пошло не так. Граница, проведённая на Cast по измеренной цене ошибки, - проектное решение. Проведённая потом, она служит оправданием задним числом.
Место этапа в протоколе
Cast - пятый из шести этапов, и вторая его половина - сборка строго по замороженному техзаданию, а не по устным договорённостям. Обе половины защищают от того, на чём проваливается большинство внедрений чат-ботов; разбор - в тексте почему ваш прошлый чат-бот не сработал. Вся последовательность на примере одного внедрения - в тексте протокол от начала до конца.
Часто задаваемые вопросы
Почему общая политика участия человека - плохая идея?
Потому что она выходит либо слишком строгой для работы, либо слишком мягкой для защиты, а на практике и той и другой сразу в разных местах одной системы. Если проверять всё, появится очередь, которую человек в конце дня разгребает пачками не читая. Это хуже, чем вовсе без проверки, потому что в журнале остаётся запись, будто человек всё согласовал. Если не проверять ничего, первая же необратимая ошибка покажет, где должна была проходить граница. Граница должна меняться от процесса к процессу, потому что от процесса к процессу меняется цена ошибки: неверно подшитая внутренняя заметка и неверное сообщение клиенту - ошибки разного рода, и одно правило к ним не подходит.
Что конкретно попадает в техническое задание?
Три вещи. Что видит проверяющий: не голый результат, а результат вместе с тем, что нужно для решения, - исходный документ, оценку уверенности системы, похожие случаи, решённые на прошлой неделе. О чём именно его спрашивают: вопрос с небольшим числом вариантов ответа, а не просьба на что-нибудь посмотреть. И что происходит при отклонении: возвращается ли элемент в очередь, уходит ли конкретному человеку или переходит на ручной путь. Третий пункт пропускают чаще всего, а именно от него зависит, настоящая ли проверка, потому что отклонение, которому некуда идти, рано или поздно превращается в согласование.
Как понять, что проверка работает, а не превратилась в формальность?
Смотрите на долю отклонений и время на решение. Если шаг проверки согласует почти сто процентов, это говорит не о точности системы, а о том, что никто не читает, и на панели эти два состояния выглядят одинаково. Со временем то же самое: если медианное решение занимает четыре секунды, никто ничего не решает. Помогает обычно не дисциплина, а меньшая очередь: проверяющий не справляется, потому что границу провели слишком широко. Если сузить её до результатов, ошибка в которых действительно стоит денег, внимание вернётся туда, где оно нужно.
Меняется ли граница после запуска?
Должна, но только по фактам. Обычно это выглядит так: категория результатов, которую первый месяц проверяли, набирает достаточно верных решений, чтобы работать без надзора, и это послабление вводят намеренно и с датой, а не потихоньку. Обратное движение, ужесточение, случается реже и всегда после инцидента. Тихих изменений быть не должно. Если порог незаметно ослабили, чтобы разгрести завал, система остаётся без действующей проверки, хотя документация по-прежнему её описывает, и в таком состоянии находится большинство ИИ-внедрений, прошедших аудит.
