Добрый вечер, Станислав 👋🏻

Благодарю, что согласились поддержать дискуссию. Да, я тоже скорее вижу здесь второй слой вашего чек-листа, а не альтернативу ему. Я бы попробовал сформулировать проверяемый пункт так:

"Можно ли получить приемлемый результат, используя только зафиксированные данные и правила, без обращения к носителю предметного опыта?"

Мне кажется, здесь важен именно такой отрицательный тест. Спросить, "весь ли контекст доступен модели?", мы толком не можем: часть неявного знания потому и неявная, что мы заранее не знаем, чего именно не хватает.

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

Тогда, думается мне, зависимость от tacit knowledge можно даже оценивать не бинарно: от задач, где зафиксированного контекста обычно достаточно, до задач, где без носителя предметного опыта результат систематически становится неполным или ошибочным.

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

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

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

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

кстати поучаствуйте в опросе: https://set.ki/post/J4ncjw5

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

А вот насчет "зрелости процессов" я бы немного с вами поспорил. Я вообще довольно осторожно отношусь к понятию "зрелости" применительно к процессам, потому что оно часто объединяет под одним словом очень разные характеристики. Если честно, из-за того, что Интернет пестрит этой "зрелостью" наравне с "хаосом", у меня уже дергается глаз иногда, когда я ее вижу.

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

А на ваш вопрос я бы ответил несколько по-иезуитски: наверное, никто из перечисленных по отдельности. Объясню ниже, но сначала задам тут еще один вопрос: а всякое ли найденное исключение вообще нужно превращать в правило?

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

Поэтому тут я бы разделил предлагаемые вами роли примерно так:

1. Эксперт обнаруживает такое знание и объясняет контекст. 2. Аналитик исследует его, сопоставляет с процессом и другими ограничениями и, если это необходимо, формализует. 3. Решение о том, должно ли найденное знание становиться правилом, принимает тот, кому принадлежит соответствующее решение: владелец процесса, бизнес, архитектор, безопасность и так далее. 4. Команда уже обеспечивает его применение там, где это требуется.

То есть для меня здесь важна последовательность: обнаружить != формализовать != утвердить.

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