Хороший практический перечень! Результаты проверки должны оставаться воспроизводимыми спустя месяцы, когда поставщик уже изменил модель. Как лучше связать в единый набор доказательств версию, системный запрос, тестовый набор, источники, результаты и человеческую оценку? Если хранить только журнал, конкретный результат после обновления модели уже не повторить. Используете ли вы неизменяемые идентификаторы или контрольные суммы для всей конфигурации отдельного запуска?
Интересный эксперимент. Особенно 350 задач и 14 млрд токенов. Но с точки зрения управления рисками ешё важно то, какие решения ИИ-продакту было запрещено принимать без подтверждения человека. Например, изменение назначения продукта, работа с новыми категориями данных, предоставление доступа к рабочей системе или принятие решений с юридическими последствиями. Перекрёстная проверка двумя моделями снижает число тех. ошибок, но не заменяет человеческий контроль. Интересно юыло бы увидеть матрицу разрешённых действий и оснований для остановки работы.
Большое Вам спасибо за разделение определения принадлежности к обучающей выборке и оценку вклада конкретного произведения. Из статьи следует сложная доказательственная ситуация, технический тест ненадёжен, а обязательная сводка по ст. 53 предоставляется в обобщённом виде. Какие доказательства сегодня действительно могут быть полезны автору? Договоры приобретения данных, журналы формирования набора, сведения от посредников или аудиторский доступ к документации? Может быть, происхождение данных необходимо фиксировать до обучения, поскольку восстановить его после обучения уже практически невозможно
В отношении ИИ-систем я бы разделил реестр технический компонент (модель, версия, поставщик, интерфейс и данные) и сценарий использования (цель, подразделение, затронутые лица, принимаемое решение и география). Одна модель может обслуживать несколько сценариев с разным уровнем риска, а один сценарий может состоять из нескольких моделей и сервисов. Если учитывать только активы, теряется юридический контекст, а если только сценарии то дублируются технические зависимости и уязвимости. Рассматриваете ли вы подобную двухуровневую структуру в продолжении серии?
Хороший практический перечень! Результаты проверки должны оставаться воспроизводимыми спустя месяцы, когда поставщик уже изменил модель. Как лучше связать в единый набор доказательств версию, системный запрос, тестовый набор, источники, результаты и человеческую оценку? Если хранить только журнал, конкретный результат после обновления модели уже не повторить. Используете ли вы неизменяемые идентификаторы или контрольные суммы для всей конфигурации отдельного запуска?
Интересный эксперимент. Особенно 350 задач и 14 млрд токенов. Но с точки зрения управления рисками ешё важно то, какие решения ИИ-продакту было запрещено принимать без подтверждения человека. Например, изменение назначения продукта, работа с новыми категориями данных, предоставление доступа к рабочей системе или принятие решений с юридическими последствиями. Перекрёстная проверка двумя моделями снижает число тех. ошибок, но не заменяет человеческий контроль. Интересно юыло бы увидеть матрицу разрешённых действий и оснований для остановки работы.
Большое Вам спасибо за разделение определения принадлежности к обучающей выборке и оценку вклада конкретного произведения. Из статьи следует сложная доказательственная ситуация, технический тест ненадёжен, а обязательная сводка по ст. 53 предоставляется в обобщённом виде. Какие доказательства сегодня действительно могут быть полезны автору? Договоры приобретения данных, журналы формирования набора, сведения от посредников или аудиторский доступ к документации? Может быть, происхождение данных необходимо фиксировать до обучения, поскольку восстановить его после обучения уже практически невозможно
В отношении ИИ-систем я бы разделил реестр технический компонент (модель, версия, поставщик, интерфейс и данные) и сценарий использования (цель, подразделение, затронутые лица, принимаемое решение и география). Одна модель может обслуживать несколько сценариев с разным уровнем риска, а один сценарий может состоять из нескольких моделей и сервисов. Если учитывать только активы, теряется юридический контекст, а если только сценарии то дублируются технические зависимости и уязвимости. Рассматриваете ли вы подобную двухуровневую структуру в продолжении серии?