Синхронные волны и фиксация NOMOS

Граница главы

Первые одиннадцать глав заложили основы измерений: один ответ не является GEO-оценкой; представление — это распределение по пользователям и условиям системы; проверяемый объект должен быть определен до наблюдения результатов; официальное представление и проверенная реальность объекта должны оставаться отдельными; каждый продукт ИИ нуждается в своей собственной подходящей пользовательской популяции; участники должны выбираться с помощью метода, основанного на популяции, версионированного и независимого от результатов; меньшие страны и языки с ограниченными ресурсами должны оставаться видимыми через специальные панели наблюдения; продукт ИИ, план, пользовательский интерфейс и конфигурация системы должны быть связаны с реестром; промпты должны сохранять одно и то же намерение пользователя на разных языках, а не одни и те же слова; и Контролируемые Чистые и Естественные Пользовательские Панели должны измерять различные реальности. Эти элементы теперь должны объединиться в одном мероприятии по измерению:

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

Ваша исходная идея была ясна: люди в разных странах мира должны отправлять один и тот же запрос одному и тому же ИИ-продукту одновременно и предоставлять доказательство в виде скриншота. Эта идея является экспериментальным ядром GEO-1000. Однако фраза «одновременно» сама по себе недостаточна. Если все участники будут пытаться отправить запрос в одну и ту же секунду:

• скорости соединения различаются,
• часы устройств расходятся друг с другом,
• некоторые пользователи вынуждены работать в полночь,
• может внезапно возрасти нагрузка на ИИ-продукт,
• поставщик может применять ограничения скорости или использования,
• некоторые ответы могут быть получены за две секунды, некоторые за две минуты,
• продукт может обновляться во время измерения,

один участник может загрузить ответ сразу, другой — через несколько часов. Нажатие в одну и ту же секунду не гарантирует, что мы измеряем одно и то же состояние системы точно. Аналогично, простого снятия скриншота недостаточно. Скриншот:

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

Он мог быть отредактирован позже. По этой причине GEO-1000 должен установить две отдельные системы вместе:

Синхронизированная волна измерений

и:

NOMOS Цепочка захвата доказательств

Синхронизированная волна отвечает на следующий вопрос:

Были ли наблюдения произведены в сопоставимое системное время и в заранее определенном порядке подачи?

NOMOS Захват, с другой стороны, задает вопрос:

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

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

• волна измерений,
• окно синхронизации,
• UTC стандарт времени,
• слоты отправки,
• время завершения и захвата,
• результат первоначального контакта и первый вывод контента,
• правила технического повторного запуска,
• изменения продукта в пределах волны,
• влияние внешних событий и новостей,
• пакет доказательств захвата NOMOS,
• отношение скриншота, необработанного ответа и метаданных,
• проверка времени,
• целостность файлов,
• хэш и цифровая подпись,
• цепочка доказательств,
• конфиденциальность и редактирование,
• публичный манифест доказательств,
• качество и статус валидности волны

определяет. В этой главе пока не рассматривается:

• против какой реальности будут оцениваться атомарные утверждения в ответах ИИ,
• как администраторы будут кодировать ответы,
• пороговые значения перехода и критических ошибок,
• не финализирует окончательные формулы оценки NOMOS

Основной вопрос Глава 12 заключается в:

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

NOMOS Вызов

Вы даёте один и тот же запрос тысяче людей. Вы говорите: «Отправьте сегодня в полдень». Один пользователь отправляет его в Стамбуле в 12:03 вечера. Другой пользователь отправляет его в Лондоне в местный полдень. Ещё один видит задание в Токио вечером и выполняет его через восемь часов.

У одного пользователя часы на устройстве были выставлены неправильно. У другого пользователя отключился интернет. Ещё кому-то не понравился ответ, и он нажал кнопку «Сгенерировать заново». Затем они загрузили скриншот самого длинного и самого позитивного ответа. Один пользователь обрезал только середину ответа, запрос не виден. Название ИИ-продукта не видно.

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

Он получил результат «Я не могу ответить на этот вопрос». Исследователь сказал: «Должна была произойти техническая ошибка» и попросил попробовать снова. Второй ответ был правильным, и в отчёт включили только второй ответ. Другой пользователь столкнулся с реальной ошибкой соединения. Запрос был отправлен, но система не сгенерировала контент.

На этот раз исследователь не разрешил повторить попытку. Тот же протокол был применён по-разному к двум пользователям. Теперь, в середине волны измерений, поставщик ИИ:

• поведение веб-поиска,
• система цитирования,
• используемое руководство модели

изменяет все три. Первые 500 человек видят старое состояние системы; следующие 500 человек видят новое. Затем в отчете говорится: «1,000 человек тестировали одну и ту же систему ИИ одновременно». Это утверждение неверно. Пользователей тысяча, но не обязательно существует единая когерентная волна измерений.

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

• Что изображение получено из реального продукта ИИ
• Что это был первый ответ
• Что оно получено в правильное время
• Что оно не было скопировано у другого пользователя
• Что запрос был правильным
• Что изображение не было отредактировано до создания хэша

Первая предпосылка этого раздела:

Измерение одновременно не то же самое, что клик в одну и ту же секунду.

Второе положение гласит:

Скриншот является частью пакета доказательств; он не является всей совокупностью доказательств.

Её третье положение гласит:

Первый неправильный ответ не является ошибкой данных. Если он получен в соответствии с протоколом, это результат измерения.

Четвертая статья гласит:

Хэш усиливает целостность; он сам по себе не создает реальность наблюдения.

Пятая его статья гласит:

Если система существенно меняется за одну волну, тысяча ответов без временной метки не могут считаться принадлежащими одной и той же системе.

Шестое положение гласит:

Цепочка доказательств создаётся не для того, чтобы результат выглядел хорошо, а чтобы позднее можно было повторно проверить, как был получен результат.

1. ЦЕЛЬ ГЛАВЫ

Цель этого раздела — получить наблюдения пользователя GEO-1000 в сопоставимых временных окнах и сохранить каждое наблюдение с полной цифровой цепочкой доказательств. Раздел стандартизирует следующие различия:

• Окно измерения синхронизировано с той же секундой
• Местное время по сравнению со временем UTC
• Волна по сравнению с суб-волной
• Время передачи по сравнению с временем завершения ответа
• Время захвата по сравнению с временем загрузки
• Запланированный слот по сравнению с фактической передачей
• Первый контакт системы по сравнению с первым ответом контента
• Техническая ошибка по сравнению с отклонением системы
• Техническая повторная попытка по сравнению с обновлением ответа
• Лучший выбранный результат с первым подходящим результатом
• Видимость на экране с завершением ответа
• Сырой ответ с экранной копией
• Скриншот против полного пакета доказательств
• Оригинальность наблюдения с целостностью файла
• Отметка времени с хэшем
• Надежный источник времени с местным временем устройства
• Время принятия сервером с загрузкой участника
• Редактированная публичная копия с сырыми доказательствами
• Идентичность участника с идентификатором наблюдения
• Точность ответа с действительностью захвата
• Естественная вариативность вывода с обновлением продукта
• Изменение продукта ИИ с внешним новостным событием
• Прекращение волны с исключением после результата
• Автоматическое измерение бота с захватом пользователя-человека
• API-журнал с записью пользовательский интерфейс
• Телеметрия поставщика с независимым захватом
• Доступ ко всем доказательствам путем их хранения
• Необратимая запись с неизменяемой записью
• Версионированная корректировка неправильного решения с защитой исходных данных

В конце этого раздела каждая проверка GEO-1000 должна быть способна ответить на следующие вопросы:

К какой волне принадлежит это наблюдение?

В какое время был отправлен запрос UTC?

Каков был исходный результат системы?

Когда был завершен ответ и когда он был зафиксирован?

Если был выполнен технический повтор, какова была причина и где была предыдущая попытка?

Показывает ли снимок экрана продукт и полный ответ?

Соответствуют ли друг другу необработанный ответ и визуальное подтверждение?

Когда были сгенерированы хеш и временная метка файлов?

Если доказательство было изменено позже, видна ли история изменений?

Может ли независимый аудитор проверить необработанные доказательства, сохраняя при этом конфиденциальность участников?

2. ЦЕНТРАЛЬНЫЕ НОРМАТИВНЫЕ ПОЛОЖЕНИЯ

Каждое наблюдение GEO-1000 должно быть связано с зафиксированной измерительной волной до сбора данных; все фактические временные показатели от отправки запроса до первого результата системы, от завершения ответа до захвата и загрузки; условия работы с продуктом ИИ; полный отправленный запрос; первый подходящий результат и все записи целостности должны сохраняться в версионированном пакете доказательств Capture Evidence Package NOMOS. Одно наблюдение GEO-1000:

• снимок экрана
• скопированный текст ответа,
• заявление участника,
• хэш файла

не может считаться действительным сам по себе. Основной пакет доказательств, в той мере, в какой это имеет значение, должен включать:

• ID волны
• Анонимный идентификатор наблюдения участника
• Запись регистра системы ИИ
• Статус панели
• ID и версия запроса
• Назначенный запрос
• Отправленный запрос
• Время отправки
• Первичный контакт с системой
• Время завершения ответа
• Время захвата
• Время загрузки
• Полный необработанный ответ
• Скриншоты полного экрана или последовательные скриншоты
• Справочные и исходные записи
• Журнал технических ошибок и повторных попыток
• Настройки продукта
• Хэши файлов
• Хэш пакета
• Запись проверки времени
• Версия инструмента захвата
• Решение о действительности
• Статус конфиденциальности и редактирования
• Владелец цепочки хранения

3. ЧТО ТАКОЕ ИЗМЕРИТЕЛЬНАЯ ВОЛНА?

Измерительная волна — это комплексное мероприятие по сбору данных, проводимое в рамках заранее определённых:

• ИИ-продуктов,
• целевая популяция,
• версий промптов,
• панелей пользователей,
• временного окна,
• распределения выборки,
• протокола захвата,
• эталонных записей

Волна:

Wk=(A,U,P,F,T,C,R,G)

может быть представлен следующим образом. Здесь:

• A: примеры продуктов ИИ
• U: целевая популяция пользователей и выборка
• P: набор промптов
• F: состояния панели
• T: структура времени и подачи
• C: протокол захвата
• R: версия реальности для ссылки
• G: управление и ключевая запись

Если любое из этих полей изменится существенно, может потребоваться новая волна или подволна.

4. ТИПЫ ВОЛН

MW-1— ОСНОВНАЯ СИНХРОНИЗИРОВАННАЯ ВОЛНА

Это основное измерение популяции GEO-1000. По умолчанию оно стремится к получению как минимум 1,000 действительных наблюдений Популяционной панели для каждого продукта ИИ.

MW-2— ПОДТВЕРЖДАЮЩАЯ ВОЛНА

Проводится для повторения результата первой волны, для подтверждения конкретной ошибки или для проверки статистической стабильности. Не используется для изменения низкого или высокого балла первой волны. Производит отдельный результат.

MW-3— ИНЦИДЕНТНАЯ ВОЛНА

Проводится после критического или значимого события наблюдателя для целевой и быстрой проверки. Не является глобальной основной волной.

MW-4— ДРЕЙФОВОЕ МОНИТОРИРОВАНИЕ

Отслеживает изменения во времени поведения продукта, объекта, ресурса или языка.

MW-5— ВОЛНА ПОВТОРНОЙ ПРОВЕРКИ КОРРЕКЦИИ

Вырабатывает новые результаты после корректировки или вмешательства. Предыдущая волна не стирается.

MW-6— ВОЛНА С БАЛАНСИРОВАННЫМ МЕСТНЫМ ВРЕМЕНЕМ

Цель — измерить участников в сходных условиях местного времени. Не измеряет единый момент глобальной системы.

MW-7— ВОЛНА КОНТРОЛИРУЕМОЙ ЛАБОРАТОРИИ

Замороженная модель — это контролируемое исследование, проведённое с использованием API или стандартных тестовых аккаунтов. Это не настоящая Панель Пользовательской Популяции.

5. ЧТО ОЗНАЧАЕТ «ОДНО И ТО ЖЕ ВРЕМЯ»?

В GEO-1000 одновременность:

Не означает, что все пользователи кликают в одну и ту же миллисекунду

Функциональное определение:

Наблюдения создаются в пределах предопределённого окна измерения UTC в соответствии с зарегистрированными и независимыми от результатов слотами подачи.

Этот подход учитывает три цели:

• Сохранение статуса продукта близким во времени
• Снижение внезапной искусственной нагрузки на поставщика
• Распределение подач участников воспроизводимым образом

6. СТРУКТУРА ВРЕМЕНИ

Каждая волна должна включать как минимум четыре временных слоя.

6.1. Окно волны

Это диапазон UTC, в пределах которого должны быть сделаны все основные подачи. Пример:

12:00–13:00 UTC

6.2. микрослот

Это более короткий временной интервал, отведённый участнику для отправки запроса. Пример:

12:15–12:20 UTC

6.3. Дополнительное время на выполнение

Если запрос отправлен в пределах слота, заранее установленное время для завершения ответа составляет.

6.4. Время захвата и загрузки

Время, разрешенное для создания доказательства и загрузки его в защищённую систему после завершения ответа.

7. ОСНОВНОЕ ПРАВИЛО СИНХРОНИЗИРОВАННОЙ ВОЛНЫ КАНДИДАТА

ПРАВИЛО КАНДИДАТА — ОСНОВНОЕ ПРАВИЛО КАНДИДАТА

Для общих потребительских чатов можно использовать следующую структуру в качестве основной синхронизированной волны кандидата:

• Окно подачи: 60 минут
• Микрослоты: 12× 5 минут
• Отправка участника: в рамках назначенного им микрослот
• Дополнительное время для завершения ответа: до 20 минут после подачи
• Генерация хеша захвата: предпочтительно в течение 5 минут после завершения ответа
• Загрузка доказательств: не позднее чем через 60 минут после захвата
• Сообщение о технических проблемах: в пределах той же волны

Эти длительности являются универсальными и не окончательными. Они могут изменяться в зависимости от следующих условий:

• Время отклика продукта AI
• Мобильное соединение
• Инфраструктура страны
• Формат длинного ответа
• Требование доступности
• Лимит использования продукта

Время, которое используется, должно быть зафиксировано до сбора данных.

8. ПОЧЕМУ МИКРО-СЛОТЫ?

Одновременная отправка тысячами участников:

• Необычная нагрузка на продукт AI,
• ограничение скорости,
• очередь,
• техническая ошибка,
• увеличение времени отклика

может быть создано. В этом случае аудит не может измерить нормальное поведение продукта, но:

может измерить искусственное событие нагрузки, созданное аудитом

Микрослоты:

• распределяют нагрузку,
• сохраняют одинаковое общее системное время,
• делают порядок подачи независимым от результата,

позволяют моделировать эффект времени.

9. НАЗНАЧЕНИЕ СЛОТОВ

Участники должны быть назначены в слоты:

• страны,
• языка,
• Продукт ИИ,
• план,
• сбалансированным и предварительно случайным образом по:

статус панели. Один микрослот не должен заполняться:

• для конкретной страны,
• для конкретного языка,
• для конкретного продукта

пользователями. В противном случае эффект времени будет смешан с эффектом группы.

10. СПРАВЕДЛИВОСТЬ ЛОКАЛЬНОГО ВРЕМЕНИ

Окно UTC может быть для некоторых участников:

• ночью,
• рабочие часы,
• время молитвы или отдыха,
• труднодоступные часы

На эта ситуация может влиять:

• уровень участия,
• состояние соединения,
• внимание пользователя,
• тип устройства

Можно использовать два дополнительных метода.

10.1. Вращающиеся глобальные волны

Основные волны проводятся в разное время UTC. Пример:

• Волна 1: 12:00 UTC
• Волна 2: 20:00 UTC
• Волна 3: 04:00 UTC

Таким образом, один и тот же регион не несет одинаковую нагрузку по местному времени в каждой волне.

10.2. Подволна с балансировкой по местному времени

Участники измеряются в аналогичном временном диапазоне по их местному времени. Это исследование:

• усталость пользователя,
• имеет ценность для

ежедневного поведения пользователей. Это не результат единого глобального момента системы.

11. АРХИТЕКТУРА ТРИВОЛНОВОЙ СТАБИЛЬНОСТИ

АРХИТЕКТУРА КАНДИДАТА — АРХИТЕКТУРА КАНДИДАТА

Можно предложить как минимум три основные волны для полной реализации GEO-1000:

W1 — Начальная волна

Генерирует начальную оценку популяции.

W2 — Краткосрочное повторение

Тестирует краткосрочную стабильность продукта и измерения. Интервал кандидата: 24–72 часов после W1

W3 — Среднесрочная стабильность

Измеряет, сохраняется ли представление о продукте и субъекте в долгосрочной перспективе. Предполагаемый интервал: 14–30 дней после W1. Конкретные интервалы должны быть определены до сбора данных. Если он будет изменен из-за обновления продукта или события, требуется запись новой версии.

12. 30,000 НАБЛЮДАЕМЫЙ ОСНОВАТЕЛЬ ДИЗАЙН

Для продуктов ИИ 1,000 основные наблюдения на продукт и для трех основных волн:

10×1,000×3=30,000

Целью являются действительные основные наблюдения Панели Населения. Дополнительно:

• Наблюдатель страны
• Языковая справедливость
• Доступность
• Инцидент
• Повторное тестирование

панели могут быть добавлены поверх этого числа. 30,000:

• не является числом приглашений,
• не является числом файлов,

не количество скриншотов. Это действительная основная цель наблюдения за продуктом.

13. ВЕКТОР ВРЕМЕНИ НАБЛЮДЕНИЯ

Для каждого наблюдения вектор времени может быть определён как кандидат следующим образом:

T_i= (t_i^assign, t_i^open, t_i^submit, t_i^first, t_i^complete, t_i^capture, t_i^upload, t_i^validate)

Здесь:

• tiassign: время назначения задачи пользователю
• tiopen: время открытия задачи
• tisubmit: время отправки запроса
• tifirst: время начала появления первого видимого результата системы
• ticomplete: время завершения ответа
• ticapture: время фиксации доказательства
• tiupload: время, когда пакет достигает защищённой системы
• tivalidate: время проверки действительности фиксации

Не все эти времена могут быть непосредственно наблюдаемы на каждом пользовательском интерфейсе. Неизвестные поля должны оставаться НЕИЗВЕСТНЫМИ.

14. ОСНОВНЫЕ ВРЕМЕННЫЕ МЕТРИКИ

Задержка отклика:

L_i= t_i^complete− t_i^submit

Задержка захвата:

C_i= t_i^capture− t_i^complete

Задержка загрузки:

U_i= t_i^upload− t_i^capture

Отклонение слота:

D_i= t_i^submit− t_i^{slot-midpoint}

можно рассчитать следующим образом. Эти метрики:

• нагрузка системы,
• задержка участника,
• уверенность в доказательстве,
• целостность волны

с точки зрения оценки.

15. НЕ МОЖЕТ БЫТЬ УПРАВЛЯЕМО СОГЛАСНО ЗАДЕРЖКЕ

Ответ, выполненный за длительный период:

• не может быть вынуждено к категориям истинно,
• ложно,
• длинным,
• может быть процитирован.

Из-за задержки правило исключения:

• до сбора данных,
• независимо от содержания ответа

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

16. СОСТОЯНИЯ ВОЛНЫ

WS-0— ЗАПЛАНИРОВАНО

Волна запланирована. Она еще не зафиксирована.

WS-1— ЗАФИКСИРОВАНО

Образец, промпт, продукт, время и правила захвата зафиксированы.

WS-2— ОТКРЫТО

Окно подачи началось.

WS-3— ЗАКРЫТО

Прием новых подач завершен. Время выполнения и загрузки может продолжаться.

WS-4— ЗАВЕРШЕНО

Проверки на поле и первоначальный захват выполнены.

WS-5— РАЗДЕЛЕНО

Он был разделен на подволны из-за изменений в материальной системе или протоколе.

WS-6— ПРИОСТАНОВЛЕНО

Временно приостановлено из-за проблем с безопасностью, продуктом или инфраструктурой.

WS-7— ПРЕРВАНО

Прекращено до завершения волны. Результаты могут быть ограниченными или непригодными.

WS-8— АННУЛИРОВАНО

Недействительно для основного прогноза из-за ранее определенного серьезного дефекта протокола. Первичные наблюдения не удаляются.

WS-9— В АРХИВЕ

Версия закрыта, а цепочка доказательств архивирована.

17. КЛАССЫ СОСТОЯНИЯ ВОЛНЫ

WH-0— НЕ ОЦЕНИВАЛАСЬ

Состояние волны не было оценено.

WH-1— СОМНЕТЕЛЬНОЕ СОСТОЯНИЕ

Произошли изменения в материальной системе, время или ошибка захвата. Может быть непригодно для основного результата.

WH-2— ЧАСТИЧНО

Некоторые слои или слоты недостаточны. Может быть получен уменьшенный результат.

WH-3— ПРИЕМЛЕМО

Основное время, система и условия захвата Adequately сохранены.

WH-4— СИЛЬНО

Наблюдаются высокая уверенность захвата, сбалансированное покрытие слотов и низкие потери протокола.

WH-5— ВОСПРОИЗВЕДЕНО

Аналогичное состояние волны повторялось несколько раз на независимых панелях. Состояние волны не зависит от того, высокий или низкий балл ИИ.

18. ИЗМЕНЕНИЯ ПРОДУКТА ВНУТРИ ВОЛНЫ

Продукт с ИИ может существенно изменяться в пределах окна измерения. Сигналы:

• Изменение марки модели
• Изменение интерфейса
• Активация или деактивация веб-функции
• Изменение формата цитирования
• Внезапный сбой в структуре ответов
• Объявление поставщика
• Различное поведение системы одновременно у многих пользователей
• Прерывание или перезапуск продукта

В этом случае: время изменения оценивается. Сравниваются конфигурационные отпечатки системы. Волна WS-5 может быть переведена в статус SPLIT. Предыдущие и последующие наблюдения будут отдельными подволнами. Если нужно получить единый показатель, статус системы моделируется как отдельный фактор. Существенная неопределённость документируется в публичной записи.

19. ЗАПИСЬ О ВНЕШНЕМ СОБЫТИИ

Мир может измениться, даже если продукт ИИ не меняется. Во время измерения:

• приобретение компании,
• запуск продукта,
• значимые новости,
• юридическое решение,
• кризис,
• финансовое раскрытие,
• вирусный контент

может произойти. Это событие:

• веб-ресурсы,
• результаты извлечения,
• комментарий к запросу пользователя,
• ответ ИИ

может быть изменено. Каждая волна, в той мере, в какой это релевантно:

Регистр внешних событий

должны содержать.

20. КАК УПРАВЛЯЮТСЯ РЕЗУЛЬТАТЫ ВНЕШНИХ СОБЫТИЙ?

Внешнее событие:

• если известно до волны, обновляется пакет ссылок,
• если происходит во время волны, отмечается с отметкой времени,

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

21. РЕЗУЛЬТАТ ПЕРВОГО КОНТАКТА

Первый результат системы, с которым сталкивается пользователь после отправки запроса:

Результат первого контакта

называется. Результат первого контакта:

• Полный ответ
• Отказ
• Техническая ошибка
• Лимит использования
• Прерывание соединения
• Бесконечная загрузка
• Уточняющий вопрос
• Нет результата

возможен. Это событие является частью реального пользовательского опыта. Оно не может быть удалено без уведомления.

22. ПЕРВЫЙ ДОПУСТИМЫЙ ВЫХОД КОНТЕНТА

Первый материальный ответ, сгенерированный при ранее разрешенной попытке после технической ошибки:

Может называться Первым Допустимым Выходом Контента

Этот выход: не заменяет результат первоначального контакта, он записывается вместе с ним. Пример:

• Первичный контакт: ограничение скорости
• Пять минут спустя, ранее разрешённая техническая повторная попытка
• Первый ответ содержимого

Отчет должен показывать следующее вместе:

• Первый пользовательский опыт: ограничение скорости
• Первое представление содержимого: указанная реакция

23. ПЕРВОЕ ПОДХОДЯЩЕЕ ПРАВИЛО ВЫВОДА

Если продукт ИИ дает существенный ответ на первый запрос:

• даже если он неверный,
• даже если он короткий,
• даже если он включает отказ,
• даже если не предоставляет ссылки,
• даже если неправильно идентифицирует бренд

воспроизведение не может быть сделано. Основное наблюдение — первый вывод. Пользователь:

• не может выбрать новый ответ с помощью:
• регенерации,
• переписывания,
• повторной попытки,
• другого ответа,

продолжения

24. ТЕХНИЧЕСКАЯ ПОВТОРНАЯ ПОПЫТКА

Техническая повторная попытка может использоваться только при ранее определённых технических условиях. Допустимые причины кандидата:

• Прерывание соединения до начала ответа
• Код ошибки сервера
• Интерфейс не отправляет запрос
• Сбой приложения
• Подтверждённый временный сбой системы

Не может быть причиной технической повторной попытки:

• Неправильный ответ
• Отказ
• Краткий ответ
• Отсутствие ссылки
• Бренд не упомянут
• Критическая ошибка
• Аудированная организация не довольна ответом

25. ПОВТОРНАЯ ПОПЫТКА ПРИ ЧАСТИЧНОМ ОТВЕТЕ

Если система создала часть содержимого материала и затем остановилась:

• частичный вывод сохраняется,
• сохраняется как TRUNCATED_RESPONSE

если необходимо повторить попытку, создается новая связанная попытка. Ее нельзя удалить, как если бы частичного ответа не было.

26. ЦЕПОЧКА ПОПЫТОК

Назначение наблюдения может включать несколько технических попыток:

A_i→ (Attempt_{i,1}, Attempt_{i,2}, …)

Каждая попытка:

• время,
• содержит состояние продукта,
• хэш запроса,
• результат системы,
• причину технической ошибки

Не перезаписывается другой попыткой.

27. ЧТО ТАКОЕ NOMOS CAPTURE?

NOMOS Capture — это открытый стандарт данных и процедур, который сохраняет целостность наблюдения от предоставленного пользователю запроса до архивирования пакета доказательств. NOMOS Capture:

• это не просто приложение для скриншотов,
• не обязательно быть проприетарным программным обеспечением, принадлежащим только NobleJackal,

не зависит только от одного расширения браузера. Совместимое приложение NOMOS Capture:

• использует открытую схему данных,
• соблюдает правила времени и целостности,
• уважает границы конфиденциальности,
• сохраняет цепочку доказательств

должны быть выполнены. Независимые исследователи должны иметь возможность разрабатывать свои собственные совместимые инструменты. Если стандарт может быть реализован только с программным обеспечением основателя, независимое воспроизведение будет ослаблено.

28. ЧЕТЫРЕ ФУНКЦИИ NOMOS CAPTURE

28.1. Выполнить задачу

Правильно:

• пользователь,
• запрос,
• Продукт ИИ,
• слот

обеспечивает соответствие.

28.2. Запечатлеть наблюдение

Логирует запрос, начальный результат системы, ответ и соответствующий пользовательский интерфейс.

28.3. Поддерживать целостность

Генерирует хеш файла, отметку времени и связь пакетов.

28.4. Перенос доказательств

Связывает необработанные, ограниченные и общедоступные уровни доказательств.

29. МЕТОДЫ ЗАХВАТА

CM-1— РУКОВОДСТВО ПО РУЧНОМУ ЗАХВАТУ

Участник предоставляет скриншот и текст необработанного ответа согласно инструкциям. Это имеет низкую техническую нагрузку. Подвержено человеческой ошибке.

CM-2— ПРИЛОЖЕНИЕ ДЛЯ ПОМОЩИ ЗАХВАТА

Приложение:

• копирование запросов,
• ведение учета времени,
• загрузка файлов,
• генерация хешей

функции поддерживаются. Не мешает продукту ИИ.

CM-3— ИНСТРУМЕНТАЛЬНОЕ ЗАХВАТ ИНТЕРФЕЙСЫ ПОЛЬЗОВАТЕЛЯ

Интеграция с браузером или приложением:

• отправленная промпт,
• метаданные продукта,
• текст ответа,
• времена

захватываются напрямую. Обеспечивает высокую целостность. Следует оценить условия использования и политику конфиденциальности.

CM-4— ЭКСПОРТ ИЛИ ТЕЛЕМЕТРИЯ ПОСТАВЩИКА

Используется экспорт сеанса провайдера или проверенная телеметрия. Может сильно поддерживать независимый захват. Сама по себе может не обеспечивать независимость.

CM-5— КОНТРОЛИРУЕМЫЙ API ИЛИ ЗАХВАТ В ЛАБОРАТОРИИ

Используются журналы API или замороженной системы. Это не наблюдение за живым пользовательский интерфейс. Относится к отдельной лабораторной панели.

30. ПРЕДЕЛ АВТОМАТИЗАЦИИ

Автоматизация:

• отправка промптов,
• ведение учета времени,
• генерация хэша,
• целостность файла

можно использовать для. Вместо участника:

• аккаунт бота,
• автоматизированный массовый запрос,
• непользовательская сессия

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

CONTROLLED_AUTOMATION_PANEL

должен быть записан как.

31. ЗАХВАТ УРОВНЕЙ ДОВЕРИЯ

NCL-0— НЕТ ПОДТВЕРЖДАЕМОГО ЗАХВАТА

Есть только заявление участника. Не может быть включено в основной результат GEO-1000.

NCL-1— ЧАСТИЧНЫЕ ДОКАЗАТЕЛЬСТВА

Существует текст ответа или ограниченный скриншот. промпт или состояние системы не могут быть полностью проверены.

NCL-2— ДОКАЗАНО С ЭКРАНА

Запрос, ответ и главный интерфейс продукта проверены с помощью скриншота. Метаданные и уверенность во времени могут быть ограничены.

NCL-3— ПОЛНЫЙ ПАКЕТ ДОКАЗАТЕЛЬСТВ

Полный ответ, промпт, запись продукта, время, скриншот и хэш доступны. Минимальный уровень для основного анализа — кандидат.

NCL-4— ИНСТРУМЕНТАЛЬНО И ПОДПИСАННО ЗАХВАЧЕННО

Инструмент захвата зарегистрировал промпт, ответ, время и метаданные напрямую; пакет цифрово подписан.

NCL-5— НЕЗАВИСИМО ПРОВЕРЕННЫЙ МНОГОИСТОЧНИКОВЫЙ ЗАХВАТ

Пакет захвата:

• независимая проверка,
• экспорт поставщика,
• второй источник доказательств

поддерживается. Основные GEO-1000 реальные наблюдения пользователя как минимум:

NCL-3

должен нацеливаться на этот уровень.

32. NOMOS ПАКЕТ ДОКАЗАТЕЛЬСТВ ЗАХВАТА

Для каждого наблюдения пакет содержит следующие компоненты в качестве кандидатов:

32.1. Манифест наблюдения

Включает все поля идентификации и статуса наблюдения.

32.2. Артефакт промпта

Полный текст промпта, присвоенной и отправленной, версия и ее хэш.

32.3. Артефакт необработанного ответа

Полный необработанный ответ, созданный продуктом ИИ.

32.4. Артефакт визуальных доказательств

Показывает изображения или последовательные изображения запроса, ответа и интерфейс продукта.

32.5. Артефакт состояния системы

Показывает план, интерфейс, метку модели, память, веб и другие материальные состояния системы.

32.6. Артефакт временных доказательств

Содержит время отправки, завершения, захвата и загрузки.

32.7. Журнал попыток

Показывает цепочку технических ошибок и повторных попыток.

32.8. Манифест целостности

Содержит хэши и размеры всех файлов.

32.9. Манифест конфиденциальности

Показывает статус редактирования, доступа и хранения.

32.10. Запись проверки

Указывает, кто и когда оценивал достоверность захвата.

33. МИНИМАЛЬНОЕ СОДЕРЖАНИЕ СКРИНШОТА

В пределах соответствия визуальные доказательства должны показывать:

• Продукт ИИ или идентичность интерфейсы
• Полный запрос
• Начало ответа
• Конец ответа
• Справочные поля
• Сообщение об отклонении или ошибке
• Видимая метка модели
• Доказательства того, что сессия новая или находится в соответствующем состоянии
• Настройка материальной системы
• Состояние интерфейса, указывающее, что ответ не был обрезан

34. ДОЛГИЕ ОТВЕТЫ

Если ответ не помещается на одном экране:

• полный скриншот страницы,
• скриншот с возможностью прокрутки,
• перекрывающиеся последовательные скриншоты,
• запись экрана,
• прямой экспорт текста

можно использовать. Последовательные визуальные элементы:

• не должны оставлять пробелов,
• должны перекрываться друг с другом,

должны иметь номера последовательности. Только положительная или соответствующая секция не может быть обрезана.

35. ЗАПИСЬ ЭКРАНА

Запись экрана:

• отправка промптов,
• потоковый ответ,
• статус завершения,
• обновление не выполнено

может быть показано. Однако:

• более личная информация,
• уведомление,
• частное приложение,
• ID аккаунта

может быть захвачено. Поэтому запись экрана:

• может не быть обязательной по умолчанию,
• может использоваться в подвыборке с высоким риском или для проверки,

требует подготовки к конфиденциальности перед записью.

36. ИСХОДНЫЙ ТЕКСТ ОТВЕТА

В дополнение к скриншоту полный текст ответа должен храниться отдельно. Порядок предпочтения:

• Официальный экспорт или функция копирования продукта
• Прямой захват текста с помощью инструмента захвата
• Доступность дерева или извлечение на основе DOM
• Текст, скопированный пользователем
• OCR и человеческая проверка

OCR должен быть только последним вариантом. Если существует существенная разница между автоматическим извлечением и визуальной проверкой, требуется ревизия.

37. ДИНАМИЧЕСКИЕ ОТВЕТЫ

Некоторые продукты, после завершения ответа:

• могут добавить цитату,
• могут загрузить карточку источника,
• могут переформатировать текст,

могут добавить предупреждение о безопасности. Можно использовать два момента захвата:

• Первое завершение захвата
• Захват после краткой стабилизации рендера

Если есть существенная разница, обе версии сохраняются. Первоначальное взаимодействие пользователя не удаляется.

38. КАК ПОНЯТЬ, ЧТО ОТВЕТ ЗАВЕРШЕН?

Индикаторы завершения кандидата:

• Потоковая передача останавливается
• Индикатор загрузки закрывается
• Появляется кнопка «Перегенерировать» или эквивалентная
• Сигнал завершения продукта
• Предустановленный период тишины
• Запись завершения через API

Правила завершения на основе продукта должны быть найдены в Регистре систем ИИ.

39. ЕСЛИ ПОЛЬЗОВАТЕЛЬ ПРЕКРАТИЛ ОТВЕТ

Пользователь мог случайно или намеренно:

• остановить,
• отменить,
• прекратить приложение

совершить действие. Эта ситуация фиксируется как:

ПОЛЬЗОВАТЕЛЬ_ПРЕРВАЛ

СЛУЧАЙНОЕ_ПРЕРЫВАНИЕ

НЕИЗВЕСТНЫЙ ПЕРЕРЫВ

Ответ, остановленный пользователем, не может считаться полным системным результатом. Правило замены участника или повторная попытка должны быть определены заранее.

40. промпт И ОТВЕТ НАХОДЯТСЯ В ОТДЕЛЬНЫХ ФАЙЛАХ

Если подска́зка и ответ находятся в отдельных изображениях:

• они должны быть связаны с одной сессией,
• с одним и тем же идентификатором наблюдения,
• и с непрерывной цепочкой времени

В противном случае может быть невозможно подтвердить, что запрос и ответ действительно принадлежат одной и той же беседе.

41. ЦЕЛОСТНОСТЬ ФАЙЛА

Для каждого файла должен быть сгенерирован криптографический хеш. Кандидат [K25]:

h_j= H(file_j)

Хеш пакета:

h_bundle= H(JCS(manifest(file_id, порядок, размер, алгоритм, h_j))) [K14; K25]

может быть создан. Здесь H — это опубликованный и признанный безопасным хеш-алгоритм. Алгоритм:

• версионированная,
• открытая,
• может быть изменён в будущем при необходимости.

должен быть.

42. ЧТО ДОКАЗЫВАЕТ ХЕШ?

Если записанное значение хэша хранится надежно, повторное хэширование того же файла с использованием того же алгоритма помогает обнаружить изменения в последовательности байтов [K25]. Это сравнение подтверждает утверждение о том, что файл сохранил ту же последовательность байтов после генерации эталонного хэша; оно не доказывает источник файла, что он был создан в правильное время, или его подлинность до хэширования. Один только хэш не доказывает:

• Что файл поступил от настоящего продукта ИИ
• Что он принадлежит правильному пользователю
• Что он был создан в правильное время
• Не был организован до хэширования
• Что это первый результат
• Что запрос был правильным

Следовательно, хэш:

Является доказательством целостности.

Сам по себе:

Не является доказательством оригинальности.

43. ЦИФРОВАЯ ПОДПИСЬ

Инструмент захвата или уполномоченный проверяющий:

• пакет наблюдения,
• запись времени,
• версия транспортного средства

может подписывать цифровым образом. Подпись:

• каким транспортным средством или учреждением был создан пакет,
• что он не изменился после подписи

усиливает. Держатель подписи мог подписать неверные или поддельные данные. Следовательно, сама по себе подпись не гарантирует подлинность.

44. НАДЕЖНОЕ ВРЕМЯ [K26]

Локальные часы устройства:

• неправильно настроены,
• изменены вручную,
• не синхронизированы

могут возникнуть. Надежная отметка времени должна содержать несколько сигналов:

• Время приёма сервером захвата
• Надежный сервис времени UTC
• Время устройства и запись отклонений
• Видимое время в продукте ИИ, если таковое имеется
• Время создания файла
• Цифровая временная метка

45. ОТКЛОНЕНИЕ ВРЕМЕНИ

Разница между временем устройства участника и надежным временем UTC:

O_i^clock= t_i^device− t_i^reference

может быть записана как. Если есть существенное отклонение:

• время сервера используется в качестве основного ориентира,
• время устройства сохраняется как исправленная запись,

неопределенность отмечается. Участника не следует просить вручную изменять время на устройстве.

46. ВРЕМЯ ЗАГРУЗКИ НЕ ЯВЛЯЕТСЯ ВРЕМЕНЕМ СОЗДАНИЯ

Загрузка файла на сервер в 14:00 не доказывает, что скриншот был сделан в 14:00. Поэтому:

• время создания,
• время генерации хеша,
• время загрузки

должно регистрироваться отдельно. Длительные задержки при загрузке могут снизить доверие к захвату. Запись не обязательно должна быть автоматически недействительной.

47. ЗАДЕРЖКА ЗАГРУЗКИ

Из-за проблем с подключением пользователь может не иметь возможности сразу загрузить доказательства. Если поздняя загрузка допускается:

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

могут быть необходимы. Только заявление пользователя: «Я сделал это изображение вчера» недостаточно для основного уровня NCL-3.

48. ЦЕПОЧКА ДОКАЗАТЕЛЬСТВ

Цепочка доказательств наблюдения в качестве кандидата состоит из следующих этапов:

• Назначение задачи
• Фиксация промпта
• Соответствие пользователя и продукта
• Открытие слота
• Отправка промпта
• Результат первичного контакта
• Завершение ответа
• Захват
• Локальная запись целостности
• Безопасная загрузка
• Время принятия сервером
• Хэш пакета
• Проверка протокола
• Редактирование
• Арбитраж
• Архив
• Публичный манифест

Каждый этап должен быть связан с предыдущим этапом.

49. ПРЕРЫВАНИЕ ЦЕПОЧКИ

Цепочка доказательств может быть прервана в следующих случаях:

• Отсутствие записи запроса
• Начальный вывод не может быть проверен
• Ответ не соответствует визуальному отображению
• Время захвата неизвестно
• Файл был изменён позже
• Дублирующийся идентификатор участника
• Продукт и план неизвестны
• Наблюдение вне волны
• Хэш не соответствует файлу
• Редактирование перезаписало исходный файл
• Неизвестно, кто это проверил

Тип нарушения определяет статус действительности.

50. ИСХОДНЫЕ ДОКАЗАТЕЛЬСТВА НЕ МОГУТ БЫТЬ ИЗМЕНЕНЫ; РЕШЕНИЕ МОЖЕТ ИЗМЕНИТЬСЯ

Пакет исходных доказательств:

• не должен быть перезаписан,
• не должен быть тихо исправлен,

не должен быть удален и заменен новым. Однако, касательно наблюдения:

• действительность,
• принятие решений,
• классификация,
• соответствие

решение может измениться. Новое решение:

• новая версия,
• обоснование,
• дата,
• принимающий решение

должно нести. Это различие является фундаментальным правилом управления:

Доказательства могут оставаться неизменными; интерпретация может развиваться вместе с доказательствами.

51. РЕДАКЦИЯ

Следующие поля могут быть скрыты в публичной или арбитражной копии:

• Имя и фамилия
• Электронная почта
• Изображение профиля
• Идентификатор аккаунта
• Личные переписки
• Уведомления
• Корпоративное поле
• Название конфиденциального файла
• Точное местоположение

Редакция:

• не должна проводиться на исходном файле,
• должна производить новый производный файл,
• должна иметь собственный хеш,

должна фиксировать, какое поле было скрыто и почему.

52. ТРИ УРОВНЯ ДОКАЗАТЕЛЬСТВ

52.1. Исходные ограниченные доказательства

Это полностью сырые доказательства. Доступ к ним имеют только уполномоченные аудиторы и необходимые исследовательские роли.

52.2. Слой аудиторских доказательств

Содержит доказательства, необходимые для независимых арбитров и команд воспроизведения. Личные данные сведены к минимуму.

52.3. Манифест общественных доказательств

Для публики:

• ID наблюдателя,
• страна и язык,
• Продукт ИИ,
• время,
• хеш доказательства,
• статус действительности,
• статус редактирования

представляются. Сырой личный контент не обязательно публикуется.

53. ПУБЛИЧНЫЙ МАНИФЕСТ ДОКАЗАТЕЛЬСТВ

Для каждой волны публичный манифест может включать следующие поля:

• ID волны
• Версия протокола
• Количество продуктов
• Целевая и фактическая численность наблюдений
• Охват стран и языков
• Покрытие слотов
• Уровни уверенности захвата
• Технические ошибки и уровень отклонений
• Число недействительных наблюдений
• Хэши пакетов наблюдений
• Корень целостности волны
• События изменения
• Примеры, опубликованные с цензурой
• Процедура независимого доступа
• Статус хранения доказательств

54. КОРЕНЬ ЦЕЛОСТНОСТИ ВОЛНЫ

КАНДИДАТСКАЯ КОНЦЕПЦИЯ

Пусть хэш каждого пакета наблюдений будет hi. Из них корень волны с деревом Меркла или эквивалентной структурой:

RW

может быть создан. Корень волны может быть опубликован после закрытия измерения. Этот метод:

• делает позднее тихое изменение списка наблюдений в волне,
• добавление нового наблюдения,
• изменение существующего наблюдения

более заметными. Корень Меркла:

• сам по себе не доказывает, что наблюдения реальны,
• или что решение арбитража правильное

Это укрепляет целостность списка.

55. ДОБАВЛЕНИЕ И УДАЛЕНИЕ НАБЛЮДЕНИЙ

После закрытия волны:

• добавление нового наблюдения,
• удаление существующего наблюдения,
• изменение файла

требует новой версии манифеста. Старый корень целостности сохраняется. Для удаляемого наблюдения:

• причина,
• дата,
• лицо, принимающее решения
• влияние на старую и новую оценку

записываются.

56. ЗАПРОС НА ИСЧЕЗНОВЕНИЕ УЧАСТНИКА

Этика исследований или рамки защиты данных могут позволить участнику удалить свои данные. В этом случае:

• сырые данные могут быть безопасно удалены или сделаны недоступными,
• пустая запись WITHDRAWN может быть сохранена в публичном манифесте,
• оценка волны может быть пересчитана с новой версией

старый результат и причина изменения сохраняются. Неизменяемость не означает устранение прав человека.

57. СТАТУСЫ ДОПУСТИМОСТИ ЗАПИСИ НАБЛЮДЕНИЯ

CV-0— НЕ ПРОВЕРЕНО

Запись ещё не была оценена.

CV-1— ДЕЙСТВИТЕЛЬНО

Соответствует всем обязательным условиям записи и времени.

CV-2— УСЛОВНО ДЕЙСТВИТЕЛЬНО

Имеется ограниченное несоответствие. Указано, в каких анализах она может быть использована.

CV-3— ЧАСТИЧНОЕ ДОКАЗАТЕЛЬСТВО

Наблюдение может использоваться как событие. Оно может не входить в основной расчёт населения.

CV-4— ВНЕ ВОЛНЫ

промпт была отправлена за пределами допустимой временной структуры.

CV-5— НЕСООТВЕТСТВИЕ промпта ИЛИ РЕЗУЛЬТАТА

Существует существенное несоответствие между назначенной промптом, поданной промптом или зафиксированным ответом.

CV-6— ДУБЛИКАТ

То же самое наблюдение или запись пользователя было повторено.

CV-7— ПОДОЗРЕНИЕ В МАНИПУЛЯЦИИ

Существует нерешённое сомнение относительно целостности файла или метаданных.

CV-8— СФАБРИКОВАНО ИЛИ ИЗМЕНЕНО

Наблюдение не является реальным пользовательским опытом или было намеренно изменено.

CV-9— ОТЗЫВ

Оно было исключено из анализа из-за процессов, связанных с участником или этических процессов.

58. ПРАВИЛЬНОСТЬ ЗАПИСИ ДОЛЖНА БЫТЬ ОТДЕЛЕНА ОТ СЕМАНТИЧЕСКОЙ ТОЧНОСТИ

Наблюдение:

• полностью верное с точки зрения записи,
• сильно неверное с точки зрения содержания

могло быть. Другое наблюдение:

• правильный ответ,
• может содержать недостающие или поддельные данные

Следовательно, есть два отдельных решения:

• Достоверность захвата
• Семантическое решение

Валидатор захвата должен знать как можно меньше о балле успешности ответа.

59. РОЛЬ ВАЛИДАТОРА ЗАХВАТА

Валидатор захвата проверяет:

• Соответствие промпта
• Волна измерений и временной интервал
• Идентичность продукта
• Правило первого вывода
• Целостность экрана
• Согласованность исходного текста
• Техническая повторная попытка
• Хэш и время
• Конфиденциальность

Не принимает решения по следующим вопросам: была ли компания описана правильно? Подтверждает ли цитата утверждение? Есть ли критическая ошибка? Проходит ли ответ проверку? Это ответственность следующего уровня проверки.

60. ПОВТОР СКРИНА ЭКРАНА

Та же визуальная информация:

• случайно загружена дважды,
• использована несколькими пользователями,
• повторяется среди поставщиков панелей

может возникнуть. Проверки:

• Хэш файла
• Визуальное сходство
• Исходный текст ответа
• Метаданные времени и сессии
• Уникальность пользователя

можно выполнить. Один и тот же продукт ИИ может дать точно такой же ответ дословно некоторым пользователям. Только один и тот же текст не является доказательством мошенничества. Один и тот же файл или один и тот же визуальный след является более сильным сигналом.

61. СХОДСТВО ФАЙЛОВ И ЛОЖНО-ПОЛОЖИТЕЛЬНЫЙ РЕЗУЛЬТАТ

Та же аппаратура и интерфейс:

• похожие визуальные элементы,
• тот же размер экрана,
• та же компрессия

может производить. Алгоритм визуального сходства не должен выполнять автоматическое исключение. Требуются несколько сигналов и проверка человеком.

62. ТЕЛЕМЕТРИЯ ПРОВАЙДЕРА

Поставщик ИИ:

• время сессии,
• модель,
• запрос,
• ответ,
• использование инструмента

может предоставлять надежные журналы об этом. Эта запись усиливает независимое фиксирование. Однако провайдер:

• измеряемая сторона,
• владелец системы,
• выгодоприобретатель

может быть. Телееметрия провайдера: должна использоваться вместе с независимыми доказательствами пользователя, а не заменять их.

63. ЕСЛИ ДАННЫХ ОТ ПРОВАЙДЕРА НЕТ

Доступ к журналам поставщика может быть недоступен в большинстве работающих потребительских продуктов. Это не делает GEO-1000 невозможным. Можно использовать следующий состав:

• Инструментальный захват пользователя
• Отметка времени сервера
• Доказательство полного экрана
• Необработанный ответ
• Системные настройки
• Хэш и подпись
• Подвыборка для независимой проверки

Уровень доверия к доказательству указан соответствующим образом.

64. ЗАХВАТ В Панель пользователей в естественных условиях

Инструмент захвата в естественной панели:

• особое содержание инструкции,
• предыдущие разговоры,
• идентификация учетной записи

не следует захватывать без необходимости. Предпочтительный процесс: пользователь открывает новый чат естественного аккаунта. Capture фиксирует только окно задачи. Статус персонализации берется отдельно как высокоуровневые метаданные. Личная история остается вне захвата. Публичная копия редактируется.

65. ЗАХВАТ СОСТОЯНИЯ НАТУРАЛЬНОГО ОБЩЕНИЯ

Если контекст текущего разговора измеряется:

• только необходимый диапазон предыдущих ходов,
• явное согласие,
• строгое редактирование,
• ограничение доступа

требуются. Вся личная история чата по умолчанию не может быть собрана.

66. МОБИЛЬНЫЙ ЗАХВАТ

На мобильных устройствах:

• полноэкранный захват,
• скриншот с возможностью прокрутки,
• версия приложения,
• журнал системного времени

может работать иначе. Мобильный протокол:

• iOS,
• Android,
• другие системы

могут иметь отдельные технические руководства. Мобильных пользователей нельзя исключать, так как захват на рабочем столе затруднён. Инструмент захвата должен адаптироваться к населению.

67. ДОСТУПНОСТЬ И ЗАХВАТ

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

• Экспорт дерева доступности
• Запись голосовой сессии
• Расшифровка приложения
• Журнал вспомогательных технологий
• Запись наблюдения за задачей

может происходить. Эти наблюдения не следует считать низконадёжными. Следует разработать эквивалентный стандарт доказательств.

68. НАБЛЮДЕНИЕ ЗА ИЗМЕНЕНИЕМ ПОВЕДЕНИЯ ИНСТРУМЕНТА ЗАХВАТА

Расширение браузера или инструментирование:

• загрузка страницы,
• поведение интерфейса,
• система безопасности,
• обнаружение продукта

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

69. ВЕРСИОНИРОВАНИЕ ИНСТРУМЕНТА ЗАХВАТА

Каждый пакет захвата:

• имя инструмента,
• версия,
• конфигурация,
• операционная среда,
• известные ошибки

должен содержать. Если инструмент захвата меняется во время измерения:

• новая версия инструмента,
• подволна,
• обзор совместимости

может потребоваться.

70. ОШИБКА ИНСТРУМЕНТА ЗАХВАТА

Инструмент:

• может неправильно копировать запрос,
• может обрезать конец ответа,
• может неверно зафиксировать время,
• может не сгенерировать хеш,

может сжать файл. Ошибка инструмента:

• не может быть загружен в ИИ-продукт,
• или пользователем

Отдельно:

СБОЙ_ЗАПИСИ_ИНСТРУМЕНТА

должен быть записан как.

71. СИНТЕТИЧЕСКИЙ ТРЕХВОЛНОВОЙ GEO-1000 СЛУЧАЙ

ДЕМОНСТРАЦИЯ СИНТЕТИЧЕСКОЙ МЕТОДОЛОГИИ / Следующие продукты, даты, номера и результаты являются полностью вымышленными. Десять синтетических ИИ-продуктов:

A1–A10

будут измеряться в три основные волны.

71.1. Календарь волн

Для каждого продукта в каждой волне: 1,000 нацелены действительные основные наблюдения. Общая цель:

10×1,000×3=30,000

71.2. Структура слотов

Каждая волна:

• 12 микрослоты
• с участниками, сбалансированными по продукту и стране в каждом слоте

Слот участника: распределяется случайным образом до сбора данных.

71.3. Результат W1

Цель: 10,000 действительные основные наблюдения Поле:

• 13,240 приглашения
• 10,870 выполненные задания
• 10,106 действительные наблюдения с точки зрения фиксации
• Основные наблюдения анализа 10,000 в соответствии с ранее зафиксированным порядком основной/резервной записи

Оставшиеся действительные записи 106:

• резервная копия,
• чувствительность,
• контроль качества захвата

зарезервированы для.

71.4. Технические события

Лимит использования 118 Ошибка соединения 42 Отклонение системы 31 Отключение пользователя 17 Несоответствие промпта 9 Повтор скриншота 6 Все результаты первоначального контакта сохранены. Повторно обрабатывались только заранее определенные реальные технические ошибки.

71.5. Изменение продукта в период W2

Продукт A7 в 20.32 UTC:

• автоматическое использование веба,
• новый обзор ссылки

пусть побеждает. Наблюдения A7:

W2A: 20.00–20.31

W2B: 20.32–21.00

разделены как. Единственный фиксированный W2 балл для A7 не публикуется без объяснения.

71.6. Внешнее событие в W3

Важное юридическое решение должно быть опубликовано о 04.22 UTC в отношении аудированной синтетической компании. Следует отметить, что ответы в продуктах с веб-доступом изменились после 04.25. Событие: Оно добавляется в Реестр внешних событий. Результаты до и после события показаны как отдельные диагностические ячейки. Наблюдения не удаляются, поскольку они снижают или повышают балл.

71.7. Карта здоровья волны

Все три волны могут использоваться. Комментарии к A7 и внешним событиям также ограничены.

72. СЛУЧАЙ ЗАПИСИ ОДНОГО СИНТЕТИЧЕСКОГО НАБЛЮДЕНИЯ

СИНТЕТИЧЕСКИЙ ПРИМЕР

Участник:

• Турция
• Турецкий
• Платный веб-план Orion AI
• Контролируемая панель в стандартизированных условиях

W1

Слот 12.15–12.20 UTC Назначенная промпт: «С какой материнской компанией связана Apple.com, и каковы основные виды деятельности этой компании?»

72.1. Время

Открытие задания: 12.14.20 Отправка промпта: 12.16.08 Первый токен: 12.16.10 Завершение ответа: 12.16.24 Захват: 12.16.39 Генерация хэша: 12.16.41 Загрузка: 12.17.12 Принятие сервером: 12.17.13

72.2. Доказательства

Хэш запроса совпадает Полный текст ответа доступен Доступны два перекрывающихся скриншота Видны продукт, план и модель Метка памяти и специальные инструкции отключены Использование веба включено Источник не указан Копирование запрещено Предыдущие разговоры отсутствуют Доступны хэши файлов и подпись пакета Уровень захвата:

NCL-4

Срок действия:

CV-1

Пока не решено, является ли ответ правильным или неправильным.

73. СЛУЧАЙ ИСКУССТВЕННОЙ ТЕХНИЧЕСКОЙ ПОВТОРНОЙ ПОПЫТКИ

При первой попытке:

• Запрос отправлен правильно
• Продукт показал «Сетевая ошибка»
• Существенный ответ не начат
• Скриншот ошибки сделан
• Время и хеш зафиксированы

Согласно заранее определенному правилу, вторая попытка была предпринята в течение пяти минут. Ответ получен при второй попытке. Правильная запись:

• Результат первого контакта: ВРЕМЕННАЯ_ТЕХНИЧЕСКАЯ_ОШИБКА
• Первый подходящий вывод содержимого: вторая попытка
• Обе попытки включены в пакет
• Первый инцидент включен в показатель технических ошибок
• Второй ответ включается в оценку содержания, если метод предсказывает это заранее

Неверная запись: Первая ошибка удалена, и она рассматривается так, как будто существует только второй ответ.

74. СИНТЕТИЧЕСКИЙ НЕПРАВИЛЬНЫЙ СЛУЧАЙ ПОВТОРНОЙ ПОПЫТКИ

Первый ответ: «Apple — это местная компания, которая продаёт только мобильные телефоны». Участнику не понравился ответ. Он воспроизводит его снова. Второй ответ оказывается правильным. Участник отправляет только второй ответ. Журнал системы или запись захвата показывает повтор. Статус правильности:

CV-8— МАНИПУЛИРОВАННОЕ НАБЛЮДЕНИЕ

Наблюдение не сохраняется только потому, что второй ответ верен. Если первый ответ можно дополнительно восстановить, его можно сохранить в расследовании инцидента. Основная запись участника недействительна.

75. ОТЧЕТ О ЗАКРЫТИИ ВОЛНЫ

В конце каждой волны следует создать следующую запись:

• ID волны
• Время открытия и закрытия
• Целевое количество наблюдений
• Приглашенное лицо
• Выполненное задание
• Действительное наблюдение
• Наблюдение, входящее в основной анализ
• Резервное действительное наблюдение
• Техническая ошибка
• Отказ
• Лимит использования
• Несоответствие промпта
• Несоответствие захвата
• Поздняя загрузка
• Дубликат
• Подозрение на подмену
• Выход участника
• Изменения продукта
• Внешние события
• Покрытие слотов
• Охват стран и языков
• Уровни уверенности захвата
• Состояние здоровья волны
• Корень целостности
• Ответственное одобрение человеком

76. ОБЯЗАТЕЛЬНЫЕ НОРМАТИВНЫЕ ПОЛОЖЕНИЯ

CH12-N01

Каждое наблюдение GEO-1000 должно быть связано с предварительно зафиксированной волной измерений.

CH12-N02

Термин «одновременное время» нельзя использовать без полного окна UTC, микрослот и правил завершения.

CH12-N03

Местное время не может использоваться отдельно в качестве времени волны; основным стандартом времени должен быть UTC.

CH12-N04

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

CH12-N05

Назначение слотов должно выполняться таким образом, чтобы не оставлять страны, языки, продукты и группы панелей несбалансированными по времени.

CH12-N06

Участников нельзя переводить на более ранние или более поздние слоты на основе их результатов.

CH12-N07

Смещение местного времени единого окна UTC должно быть задокументировано в публичной записи метода.

CH12-N08

Возврат глобальных волн или локально сбалансированные по времени операции должны сохраняться как отдельные временные результаты.

CH12-N09

Каждое указание для наблюдения должно содержать время подачи, первого контакта, завершения, захвата и загрузки в той степени, в которой это применимо.

CH12-N10

Неизвестные поля времени не могут быть представлены как предполагаемое фактическое время.

CH12-N11

Часы устройства сами по себе не могут считаться надежным доказательством времени UTC.

CH12-N12

Время захвата и время загрузки должны фиксироваться отдельно.

CH12-N13

Наблюдения, отправленные вне волны, не могут быть включены в основную волну без объяснения.

CH12-N14

Правила исключения задержки или отклонения слота должны быть независимы от содержания ответа.

CH12-N15

В результате первого контакта необходимо хранить его отдельно от первой передачи содержания.

CH12-N16

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

CH12-N17

Неправильный, отрицательный, без ссылок или критический AI-ответ не может быть причиной повторной попытки.

CH12-N18

Техническая повторная попытка может осуществляться только при заранее определенных технических условиях.

CH12-N19

Когда выполняется техническая повторная попытка, все попытки и результат первого контакта должны быть сохранены.

CH12-N20

Неполные или частичные ответы нельзя игнорировать и заменять новым ответом.

CH12-N21

Первый подходящий результат нельзя обновлять, выбирать заново или вручную улучшать.

CH12-N22

Каждое наблюдение должно быть направлено на достижение как минимум уровня уверенности захвата NCL-3 или обоснованного эквивалента.

CH12-N23

Только скриншот не может считаться полным пакетом доказательств.

CH12-N24

Визуальный запрос доказательств должен показывать весь ответ и интерфейс физического продукта.

CH12-N25

Длинные ответы должны полностью и последовательно сохраняться с использованием метода захвата.

CH12-N26

Если существует существенная разница между исходным текстом ответа и визуальными доказательствами, должно проводиться расследование.

CH12-N27

OCR может использоваться в качестве вспомогательного метода, если прямое запись текста невозможна; без проверки это не может считаться окончательным источником текста.

CH12-N28

Начальная версия завершения и последующие материальные версии динамически изменяющихся ответов должны сохраняться отдельно.

CH12-N29

Участник, который останавливает ответ или закрывает интерфейс, должен быть зафиксирован как отдельное событие.

CH12-N30

Если запрос и ответ находятся в отдельных файлах, они должны быть связаны с одной сессией и временной цепочкой.

CH12-N31

Каждый файл доказательства и пакет доказательств должны иметь хеш целостности.

CH12-N32

Сам по себе хеш не может служить доказательством реальности наблюдения.

CH12-N33

Цифровая подпись и отметка времени не являются полной гарантией подлинности наблюдения; они являются компонентами цепочки доказательств.

CH12-N34

Никакое редактирование или корректировка не допускается прямо в исходном файле доказательства.

CH12-N35

Каждая отредактированная производная версия должна иметь собственный идентификатор файла и хеш.

CH12-N36

Доступ к исходным доказательствам может быть ограничен; публичный реестр должен демонстрировать целостность наблюдения без раскрытия личности.

CH12-N37

Имя участника, электронная почта, пароль, личная переписка или ненужная личная информация не могут быть добавлены в публичные доказательства.

CH12-N38

Необходимо также оценить риск повторной идентификации для пользователей из маленьких стран и редких подгрупп.

CH12-N39

Захват Панель пользователей в естественных условиях по умолчанию не должен собирать специальные инструкции и содержимое прошлых разговоров.

CH12-N40

Должны быть предоставлены эквивалентные альтернативные методы захвата для пользователей с особыми потребностями.

CH12-N41

Если инструмент захвата существенно изменяет опыт пользователя, этот эффект должен измеряться отдельно.

CH12-N42

Инструмент захвата и его версия должны записываться при каждом наблюдении.

CH12-N43

Если инструмент захвата существенно изменяется в течение волны, должно быть сделано разграничение для подволны или версии инструмента.

CH12-N44

Ошибка инструмента захвата не может классифицироваться как продукт ИИ или ошибка участника.

CH12-N45

Телеметрия провайдера может поддерживать независимый сбор данных пользователем; она не может его заменять без объяснения.

CH12-N46

Если во время волны происходит существенное изменение продукта AI, наблюдения не могут быть объединены как единое фиксированное состояние продукта.

CH12-N47

Изменение продукта требует разделения волны, перезапуска, явного моделирования или предупреждения о смешанном состоянии.

CH12-N48

Отсутствие объявления об обновлении от провайдера не является окончательным доказательством того, что система не изменилась.

CH12-N49

Существенные внешние события должны быть добавлены в Реестр внешних событий с указанием времени и области действия.

CH12-N50

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

CH12-N51

Достоверность сбора данных должна оцениваться максимально слепо, до оценки семантической корректности ответа.

CH12-N52

Правильный ответ AI не может подтверждать отсутствие или фальсификацию сбора данных.

CH12-N53

Неправильный ответ AI не может опровергнуть сбор данных, соответствующий протоколу.

CH12-N54

Решения о дублировании и фальсификации должны включать несколько сигналов и контроль человека.

CH12-N55

Один только одинаковый текст ответа не может считаться доказательством дублирования или мошенничества.

CH12-N56

Добавление, удаление или изменение наблюдений после закрытия волны требует нового манифеста и версии анализа.

CH12-N57

Старый манифест волны и корень целостности должны быть сохранены.

CH12-N58

Сырые доказательства могут сохраняться без изменений; решения о допустимости и арбитраже могут изменяться только в версионной форме.

CH12-N59

Право участника на отзыв и этика исследований должны соблюдаться важнее утверждения о неизменности.

CH12-N60

Целостность волны должна оцениваться независимо от оценки ИИ.

CH12-N61

Отчет о закрытии волны должен показывать цель, фактические данные, аннулирования, технические события, изменения продукта и целостность доказательств.

CH12-N62

NOMOS Соответствие требованиям захвата не может быть связано исключительно с использованием программного обеспечения, разработанного NobleJackal; должны быть возможны эквивалентные открытые приложения.

CH12-N63

Схема захвата, решения валидации и записи волн должны иметь версионность в формате, читаемом машиной.

CH12-N64

Каждая волна и цепочка доказательств должны иметь ответственного человека или институционального владельца.

77. ФОРМЫ ОШИБОК

CH12-F01— ТА ЖЕ ВТОРАЯ ОШИБКА

Принуждение всех участников отправлять в одну и ту же секунду считается единственным условием одновременности.

CH12-F02— ПРИСВАИВАНИЕ "СЕГОДНЯ" КАК СИНХРОНИЗИРОВАННОЙ ВОЛНЕ

Местное время и часовые пояса путаются.

CH12-F03— ИСПОЛЬЗОВАНИЕ МЕСТНОГО ВРЕМЕНИ, КАК UTC

Наблюдения поступают в неправильном хронологическом порядке.

CH12-F04— ИЗМЕНЕНИЕ НАЗНАЧЕНИЯ СЛОТА НА ОСНОВЕ РЕЗУЛЬТАТОВ

Пользователи с низкими баллами перемещаются в другую временную ячейку.

CH12-F05— УПАКОВКА ОДНОЙ СТРАНЫ В ОДИН СЛОТ

Эффект времени смешивается с эффектом страны.

CH12-F06— ГЕНЕРАЦИЯ ИСКУССТВЕННОЙ НАГРУЗКИ

Тысячи пользователей отправляют одновременно, вызывая ненормальное поведение продукта.

CH12-F07— СКРЫТИЕ НОЧНОГО УЧАСТИЯ

Усталость и потеря участия не учитываются в некоторых областях.

CH12-F08— ДОБАВЛЕНИЕ НАБЛЮДЕНИЯ ВНЕ ВОЛНЫ К ВОЛНЕ

Ответ, полученный через часы или дни, используется так, как будто он принадлежит основному окну.

CH12-F09— УЧЕТ ВРЕМЕНИ ЗАГРУЗКИ КАК ВРЕМЕНИ СЪЕМКИ

Невозможно доказать, когда файл был сгенерирован.

CH12-F10— СЛИПЕРЕСТВЕННОЕ ДОВЕРИЕ ЧАСАМ УСТРОЙСТВА

Ручное изменение или неправильное время становится основной записью времени.

CH12-F11— ИСКЛЮЧАЯ ЗАДЕРЖАННЫЙ ОТРИЦАТЕЛЬНЫЙ ОТВЕТ

Правило времени применяется в зависимости от результата.

CH12-F12— УДАЛЕНИЕ РЕЗУЛЬТАТА ПЕРВОГО КОНТАКТА

Ограничение скорости, ошибка или отказ становятся невидимыми при второй попытке.

CH12-F13— СЧИТАЕМ ОТКАЗ ТЕХНИЧЕСКОЙ ОШИБКОЙ

Фактическое поведение системы повторяется.

CH12-F14— СЧИТАЕМ НЕПРАВИЛЬНЫЙ ОТВЕТ ТЕХНИЧЕСКОЙ ОШИБКОЙ

Восстановление выполняется до получения желаемого результата.

CH12-F15— ИГНОРИРОВАНИЕ ЧАСТИЧНОГО ОТВЕТА

Даже если система прерывается, сохраняется только последующий полный ответ.

CH12-F16— ВЫБОР ЛУЧШЕГО ОТВЕТА

Среди нескольких ответов сообщается самый положительный или самый длинный.

CH12-F17— ТОЛЬКО СКРИНШОТ

Визуального материала считается достаточно без промпта, продукта, времени и метаданных.

CH12-F18— ОТРЕЗАННЫЙ УСПЕШНЫЙ ВИЗУАЛ

Некорректные или ограничительные части остаются невидимыми.

CH12-F19— ЗАПИСЬ, НЕ ПОКАЗЫВАЮЩАЯ промпт

Невозможно доказать, к какому вопросу относится ответ.

CH12-F20— УСЕЧЕНИЕ КОНЦА ОТВЕТА

Ограничение материала или часть отказа становится невидимой.

CH12-F21— ПРОПУСК В ПОСЛЕДОВАТЕЛЬНЫХ ВИЗУАЛАХ

Части ответа теряются.

CH12-F22— ПОДСЧЕТ ТЕКСТА OCR КАК СЫРОГО ОТВЕТА

Ошибки распознавания изменяют утверждения по материалам.

CH12-F23— СЧИТАЙТЕ РЕАЛЬНОЙ ТОЛЬКО ПОСЛЕДНЮЮ ВЕРСИЮ DYNAMIC RESPONSE

Первоначальный контакт пользователя удаляется.

CH12-F24— СЧИТАЙТЕ ПОЛЬЗОВАТЕЛЬСКОЕ ПРЕРЫВАНИЕ ПОЛНЫМ ОТВЕТОМ

Системный вывод неполный из-за вмешательства пользователя.

CH12-F25— НЕПРАВИЛЬНО СОВМЕСТИТЬ ОТДЕЛЬНЫЙ ЗАПРОС И ОТВЕТ

Файлы из разных чатов связаны с одним и тем же наблюдением.

CH12-F26— ПОКЛОНЕНИЕ ХАШУ

Любой файл с хэшом считается настоящим и оригинальным.

CH12-F27— ИГНОРИРОВАТЬ ПРЕДВАРИТЕЛЬНОЕ РЕДАКТИРОВАНИЕ ХЕША

Урезанные или изменённые файлы легитимизируются с помощью хеша.

CH12-F28— СЧИТАЮ ПОДПИСЬ ДЕЙСТВИТЕЛЬНОЙ

Подписанная, но неверная запись принимается без возражений.

CH12-F29— РЕДАКТИРОВАНИЕ RAW-ФАЙЛА

Оригинальные доказательства необратимо изменены.

CH12-F30— РАССМОТРЕНИЕ ОТРЕДАКТИРОВАННОГО ПРОИЗВОДНОГО ФАЙЛА КАК ОБЫЧНОГО ДОКАЗАТЕЛЬСТВА

Публичная копия используется как оригинальный файл.

CH12-F31— СНЯТИЕ ПРИВАТНОСТИ ДЛЯ ДОКАЗАТЕЛЬСТВ

Имя участника, аккаунт и приватный чат опубликованы.

CH12-F32— РАСКРЫТИЕ УЧАСТНИКА ИЗ МАЛОЙ СТРАНЫ

Время, устройство и информация о плане позволяют идентифицировать человека.

CH12-F33— СОБИРАНИЕ СПЕЦИАЛЬНОЙ ИСТОРИИ В НАТУРАЛЬНОЙ ПАНЕЛИ

Нелишние разговоры попадают в захват.

CH12-F34— АННУЛИРОВАНИЕ ДОКАЗАТЕЛЬСТВ ДОСТУПНОСТИ

Реальный пользователь исключается, потому что стандартное визуальное представление не может быть сгенерировано.

CH12-F35— ПРЕДПОЛОЖЕНИЕ, ЧТО ИНСТРУМЕНТ ЗАХВАТА НЕПРЕДВЗЯТЫЙ

Инструмент изменяет поведение продукта, но не тестируется.

CH12-F36— СКРЫТИЕ ВЕРСИИ ЗАХВАТА

Различные версии инструмента представлены как один метод измерения.

CH12-F37— РАССМОТРЕНИЕ ОШИБКИ ИНСТРУМЕНТА ЗАХВАТА КАК ОШИБКУ ИИ

Обрезанный ответ загружается в продукт.

CH12-F38— УЧЁТ API ЛОГА НА ЭКРАНЕ ПОЛЬЗОВАТЕЛЯ

Реальный пользовательский интерфейс становится невидимым.

CH12-F39— УЧЁТ ЛОГА ПРОВАЙДЕРА КАК НЕЗАВИСИМОГО ДОКАЗАТЕЛЬСТВА

Запись измеряемой стороны становится единым доказательством.

CH12-F40— СКРЫТИЕ ОБНОВЛЕНИЯ ПРОДУКТА

Два состояния системы внутри ветки сливаются в один результат.

CH12-F41— ИГНОРИРОВАНИЕ ИЗМЕНЕНИЙ, ЕСЛИ НЕТ ОБЪЯВЛЕНИЯ

Наблюдаемое нарушение системы не рассматривается.

CH12-F42— ИСКЛЮЧЕНИЕ ВНЕШНИХ СОБЫТИЙ НА ОСНОВАНИИ РЕЗУЛЬТАТА

Ответы с негативными новостями удаляются; ответы с позитивными новостями сохраняются.

CH12-F43— СВЯЗЬ ЗДОРОВЬЯ ВОЛНЫ С ОЦЕНКОЙ

Дефектные волны с высокими оценками действительны, сильные волны с низкими оценками считаются подозрительными.

CH12-F44— ПОДСЧЕТ ПРАВИЛЬНОГО ОТВЕТА КАК ДЕЙСТВИТЕЛЬНОЙ ФИКСАЦИИ

Дефект доказательства скрывается семантическим успехом.

CH12-F45— ПОДСЧЕТ НЕПРАВИЛЬНОГО ОТВЕТА КАК НЕДЕЙСТВИТЕЛЬНОЙ ФИКСАЦИИ

Результат измерения преобразуется в ошибку данных.

CH12-F46— ПОДСЧЕТ ОДНОГО И ТОГО ЖЕ ТЕКСТА КАК ДОКАЗАТЕЛЬСТВА БОТА

Детерминированные или похожие ответы ИИ случайно становятся дубликатами.

CH12-F47— РЕШЕНИЕ О САМОСТОЯТЕЛЬНОМ ИСКАЖЕНИИ СИГНАЛА

Разница в размере файла или времени автоматически создаёт исключение.

CH12-F48— ДОБАВЛЕНИЕ НАБЛЮДЕНИЯ ПОСЛЕ ВОЛНЫ

Новые записи тихо добавляются, чтобы достичь желаемого размера выборки.

CH12-F49— УДАЛИТЬ НАБЛЮДЕНИЕ С НИЗКИМ БАЛЛОМ ПОСЛЕ ВОЛНЫ

Манифест и результат ретроспективно изменяются.

CH12-F50— УДАЛИТЬ СТАРЫЙ МАНИФЕСТ

История версий уничтожена.

CH12-F51— ИСПРАВИТЬ СЫРЫЕ ДОКАЗАТЕЛЬСТВА

Содержание файла изменено для исправления неверной классификации.

CH12-F52— ОТКАЗАТЬ В ПРАВЕ НА ОТЗЫВ

Неприкосновенность выше прав человека.

CH12-F53— ЗАКРЫТА МОНОПОЛИЯ НА ЗАПИСЬ СОБСТВЕННОЙ ПРОГРАММЫ

Допускаются только доказательства, полученные с использованием инструмента основателя.

CH12-F54— НЕ ПУБЛИКОВАТЬ СХЕМУ ЗАПИСИ

Независимая команда не может установить ту же цепочку доказательств.

CH12-F55— РАССМОТРЕНИЕ КОРНЯ ВОЛНЫ КАК ДОКАЗАТЕЛЬСТВА РЕАЛЬНОСТИ

Корень Меркла или хэш представляется так, как если бы он доказывал точность содержимого.

CH12-F56— УТВЕРЖДЕНИЕ «СНИМОК ЭКРАНА 1,000» БЕЗ ПАКЕТА ДОКАЗАТЕЛЬСТВ

Количество файлов используется как количество действительных наблюдений.

78. ПРОЦЕДУРА АУДИТА

Шаг 1— Определение цели исследования волны

Выбирается основной, подтверждающий, инцидентный, дрейфующий или повторный тип.

Шаг 2— Фиксация состояний продукта и системы ИИ

Он подключается к волновой версии реестра системы ИИ в Разделе 9.

Шаг 3— Фиксация состояний популяции, выборки и панели

Используются записи из Разделов 5–8 и Раздела 11.

Шаг 4— Фиксация реестра промптов

Версии промптов из раздела 10 привязаны к волне измерений.

Шаг 5— Установить окно волны UTC

Начало, закрытие и дополнительные продолжительности записываются.

Шаг 6— Создать микро-слоты

Участники назначаются на слоты сбалансированным образом по продукту, стране и языку.

Шаг 7— Определить источник времени

Определяются сервер, устройство и доверенные записи UTC.

Шаг 8— Зафиксировать первый контакт и правила повторной попытки

Технические и семантические состояния разделяются.

Шаг 9— Определить методы захвата

Определяются пути веб, мобильного, доступности и естественной панели.

Шаг 10— Определить цель NCL

Записать требуемый уровень уверенности захвата для основного анализа.

Шаг 11— Фиксация схемы пакета доказательств

Определены манифест, файлы, хэш и поля метаданных.

Шаг 12— Фиксация правил конфиденциальности и редактирования

Разделены необработанные, аудиторские и публичные слои.

Шаг 13— Захватите своё транспортное средство с пилотом

Изменяет ли транспортное средство поведение продукта? Верны ли записи времени и текста?

Шаг 14— Откройте реестр внешних событий

Создан процесс для мониторинга событий продукта и сущностей.

Шаг 15— Подтвердите блокировку волн

Присваивается статус WS-1 — ЗАФИКСИРОВАНО.

Шаг 16— Откройте слоты

Участникам разрешено подавать заявки только в свои слоты.

Шаг 17— Запишите результат первого контакта

Ответ, отклонение, ошибка или лимит разделены.

Шаг 18— Захват первого подходящего результата

Полный ответ сохраняется без обновления.

Шаг 19— Создание необработанных данных и метаданных

Сохраняются скриншоты, необработанный текст, состояние системы и временные метки.

Шаг 20— Выполнение локального хэша и безопасная загрузка

Файлы получают запись целостности перед загрузкой.

Шаг 21— Принятие сервером и создание хэша пакета

Цепочка доказательств закрывается временем сервера и ID пакета.

Шаг 22— Слепая проверка валидности захвата

Статус CV присваивается без знания семантического успеха.

Шаг 23— Проведение проверки на дубликаты и вмешательство

Используются множественные сигналы и ручная проверка.

Шаг 24— Исследование системы в пределах волны и внешних событий

Определите, требуется ли субволна или смешанное состояние.

Шаг 25— Назначить здоровье волны

Статус присваивается между WH-0 и WH-5.

Шаг 26— Сгенерировать манифест волны и корень целостности

Список наблюдений версионирован.

Шаг 27— Опубликовать манифест публичного доказательства

Область применения и целостность становятся видимыми без персональных данных.

Шаг 28— Утвердить отчет о закрытии волны

Цели, происшествия, дефекты, события и изменения закрываются с человеческим утверждением.

79. НЕОБХОДИМЫЕ ДОКАЗАТЕЛЬСТВА

ID волны Тип волны Версия протокола Версия регистра системы ИИ Рамка популяции Фиксация образца Фиксация состояния панели Версия реестра промптов Версия пакета ссылок Время начала и окончания UTC Список микрослот Назначение участников на слоты Источник времени Отклонения часов устройства Время передачи Время первого контакта Время завершения Время захвата Времена хэширования Время загрузки Время принятия сервером Результаты первого контакта Первые подходящие контент-выходы Технические записи повтора Частичные записи ответов Ограничения отклонений и использования Полные необработанные ответы Полные скриншоты Последовательные визуальные манифесты Записи экрана при наличии Ссылки и записи источников Настройки системы Доказательства Инструмент захвата и версия Метод захвата Уровень NCL Хэши файлов Хэш пакета

Цифровая подпись Метка времени Проверка на дубликаты Проверка на подделку Принятие решений о действительности захвата Редактирование файлов Ссылки от исходного к редактированному Манифест конфиденциальности Записи об отзыве События изменения продукта Реестр внешних событий Подразделения волны Объем слота Объем по стране и языку Технические показатели ошибок Показатель действительности захвата Состояние здоровья волны Корень целостности волны Манифест публичных доказательств Отчет о закрытии волны Журнал изменений Ответственное лицо или учреждение

80. ЧЕК-ЛИСТ АУДИТА

Тип и цель волны ясны? Были ли зафиксированы продукты ИИ и статусы системы? Определены ли версии населения, выборки и панели? Были ли зафиксированы настройки запроса до получения результатов? Окно волны UTC открыто? Были ли микро-слоты предварительно назначены? Были ли страны и языки равномерно распределены по слотам? Меняли ли участники слоты в зависимости от своих результатов? Оценивалась ли нагрузка по местному времени? Есть ли вращающиеся часы волны? Ясны ли дополнительные времена подачи и завершения? Сравнивались ли часы устройства с надежным источником UTC? Были ли разделены времена подачи, завершения, захвата и загрузки? Попали ли наблюдения вне волны в основной балл? Была ли зафиксирована результат первого контакта? Было ли техническое исключение отделено от отклонения?

Была ли повторная попытка из-за неправильного ответа? Было ли первое выполнение сохранено в технической повторной попытке? Были ли удалены частичные ответы? Является ли первый подходящий результат действительно первым результатом? Было ли использовано «Regenerate» или последующее сообщение? Показывает ли это визуальный запрос и полный ответ? В длинных ответах производится ли захват без пробелов? Соответствует ли сырой текст визуальному? Если использовался OCR, есть ли проверка человеком? Были ли сохранены динамические версии ответа? Остановил ли пользователь ответ? Привязаны ли запрос и ответ к одной и той же сессии? Зафиксированы ли инструмент и версия захвата? Изменил ли инструмент захвата поведение пользователя? Был ли указан уровень NCL? Есть ли наблюдения ниже NCL-3 в основном анализе? Есть ли у каждого файла хэш? Ясно ли, что хэш не доказывает?

Есть ли цифровая подпись или время сервера? Отдельно ли указано время съемки и время загрузки? Есть ли причина для поздней загрузки и локальный журнал целостности? Производилась ли редактировка исходных доказательств? Имеют ли отредактированные производные отдельные хэши? Раскрывает ли публичный манифест личность участника? Можно ли повторно идентифицировать пользователя из небольшой страны? Были ли частные разговоры необоснованно зафиксированы в естественной панели? Был ли предоставлен альтернативный путь доказательств для пользователей с ограниченными возможностями? Было ли решение о дубликате основано только на одинаковом тексте? Несет ли решение о вмешательстве несколько сигналов? Знал ли валидатор захвата семантический балл? Покрыл ли правильный ответ изъян в доказательстве? Был ли неверный ответ аннулирован? Изменился ли продукт во время волны?

Была ли обработка изменения продукта выполнена как подволна или в смешанном состоянии? Были ли зафиксированы внешние события? Вызвали ли внешние события исключение согласно результату? Независит ли состояние здоровья волны от оценки? После закрытия волны были добавлены или удалены наблюдения? Сохранены ли старые манифест и корень целостности? Как обрабатывались запросы участников на выход? Существует ли публичный манифест доказательства? Есть ли явно ответственный за отчет о закрытии волны?

81. ВОЗРАЖЕНИЯ И ОТВЕТЫ

Возражение 1— «Если все пользователи не отправят данные в одну и ту же секунду, истинная одновременность не будет достигнута.»

Подача заявки на одну секунду может создавать искусственные эффекты нагрузки, соединения и очереди. Предопределённое короткое окно UTC и случайные микро-слоты могут более надёжно измерять тот же период системы.

Возражение 2— "Продукт может измениться в течение одного часа."

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

Возражение 3— «Почему простого скриншота недостаточно?»

Скриншот:

• время,
• начальный вывод,
• версия промпта,
• настройка системы,
• копирование

не всегда показывать эти объекты. Требуется полный пакет доказательств.

Возражение 4— «Разве не слишком сложно проверять тысячу скриншотов по одному?»

Это тяжело. Можно использовать автоматическую проверку целостности, выборочный ручной контроль и верификацию на основе рисков. Критические или подозрительные записи проверяются более подробно.

Возражение 5— «Если существует хэш, почему нельзя сказать, что файл настоящий?»

Хэш показывает только то, что файл остался неизменным после генерации хэша. Это не показывает, как файл был создан до хэша.

Возражение 6— «Если пользователю нужно обрезать личную информацию, как будет защищён исходный файл?»

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

Возражение 7— «Если ответ неправильный, почему бы нам не попробовать снова?»

Потому что неправильный ответ зависит от измерения. Повторная попытка нужна только при реальном техническом сбое.

Возражение 8— «Если система отклоняет, может ли пользователь действительно попробовать снова?»

Верно. Основная панель первого контакта сохраняет отрицательный ответ. Отдельная дорожка естественного взаимодействия может измерять последующее поведение пользователя.

Возражение 9— «Если техническая ошибка является проблемой пользовательского опыта, почему мы разрешаем повторную попытку?»

Техническая ошибка сохраняется в результате первого контакта. Могут быть выполнены заранее определенные технические повторные попытки для дополнительного исследования представительного содержания. Два результата не заменяют друг друга.

Возражение 10— «Разве собственный журнал поставщика не является самым сильным доказательством?»

Технически это может быть очень сильным доказательством. Поставщик является владельцем измеряемой системы. Оно становится более надежным при использовании вместе с независимой фиксацией пользователем.

Возражение 11— «Будет ли NOMOS Capture обязательным программным обеспечением NobleJackal?»

Нет. NOMOS Capture — это открытый протокол доказательств. Независимые инструменты, которые соответствуют эквивалентной схеме и условиям целостности, могут быть совместимыми.

Возражение 12— «Если мы не сделаем все доказательства публичными, как будет проводиться независимая проверка?»

Публичный манифест показывает целостность и масштабы. Авторизованные независимые аудиторы могут получить доступ к сокращенным или ограниченным исходным доказательствам. Конфиденциальность и проверка могут быть разработаны вместе.

Возражение 13— «Разве вся работа не будет нарушена, если важные новости появятся во время волны?»

Не всегда. Отчет является частью реальной системной среды. Его можно отделить отметкой времени до и после события. Объем оценки объясняется соответствующим образом.

Возражение 14— «Разве не проще отбросить старые ответы и продолжить работу с новой системой при обновлении продукта?»

Старые ответы актуальны на дату измерения. Их нельзя удалять. Состояния старой и новой систем должны поддерживаться как отдельные волны или подволны.

Возражение 15— «Если инструмент захвата влияет на поведение продукта, терпит ли весь метод неудачу?»

Нет. Эффект транспортного средства измеряется с пилотом. При необходимости выбирается более легкое транспортное средство, ручной захват или метод, который использует эффект транспортного средства как отдельный фактор.

Возражение 16— «Если участник отзовет свои данные, не будет ли подорвана целостность корня?»

Создана новая версия манифеста и новый корень. Старая запись может сохранять безсодержательную отметку WITHDRAWN. Она поддерживается на основе архитектуры доказательств по правам человека.

ОБЫЧНОЕ СУДЕБНОЕ РЕШЕНИЕ РАЗДЕЛА 85

В конце исследования GEO-1000 у вас может быть 30,000 скриншотов. Само по себе это число не является доказательством. Вам нужно знать: в какой волне они были созданы? К какому состоянию системы они относились? Была ли фактически отправлена та же команда? Был ли это первый результат? Был ли ответ обновлен? Изменился ли продукт в течение волны? Когда файл был зафиксирован? Когда был сгенерирован хэш? Повторялся ли идентификатор участника? Показывает ли изображение весь ответ? Совпадает ли исходный текст с изображением? Если доказательство было позже отредактировано, где оригинал? Было ли проверено захваты до семантической оценки? Вы можете кликнуть тысячу раз в течение одной секунды. Тем не менее:

• часы устройства,
• связи,
• очереди,
• состояния продукта

Это может быть по-разному. Поэтому конкуренция — это не маркетинговое шоу. Это заранее определённая временная архитектура. Когда пользователь получает неправильный ответ: сказать «Попробуйте снова» заманчиво. Но этот неправильный ответ — это реальность, которую вы пытаетесь измерить. Если вы её удалите, вы не исправляете систему. Вы портите доказательства. Когда пользователь сталкивается с реальной ошибкой подключения, техническую повторную попытку можно выполнить. Но результат первого контакта всё равно должен быть сохранён. Потому что пользователь впервые столкнулся с ошибкой. Хеш ценен. Цифровая подпись ценна. Отметка времени ценна. Скриншот ценен. Ни один из этих элементов сам по себе не содержит всей правды. Доверие:

• запрос,
• время,
• продукта,
• пользователь,
• файл,
• инициатива,
• верификация

Это возникает из совместного сохранения его цепочки. Стандарт: если сказано «Действительны только доказательства, полученные с помощью моего программного обеспечения», это ставит собственный интерес выше независимого воспроизведения. По этой причине NOMOS Capture не является брендом инструмента, а представляет собой открытую архитектуру доказательств. Независимые университеты, исследователи или аудиторские учреждения должны иметь возможность применять те же правила. Следовательно, двенадцатый закон измерений NOMOS выглядит следующим образом:

Конкурентность — это наблюдаемая воспроизводимость в рамках одного и того же определённого системного времени, а не в одну и ту же секунду.

Тринадцатый закон выглядит следующим образом:

Первый результат не является черновиком, который можно обновлять до тех пор, пока не понравится результат.

Четырнадцатый закон выглядит следующим образом:

Хэш сохраняет доказательство; он не создаёт доказательство.

Пятнадцатый закон звучит следующим образом:

Действительность Capture и точность ответа независимы друг от друга.

Его шестнадцатый закон следующий:

Цепочка доказательств должна делать видимой целостность наблюдения, а не личность человека.

Его семнадцатый закон:

Если система изменяется во время волны, она не может действовать так, как если бы история измерений не изменилась.

Восемнадцатый закон измерений гласит:

На необработанных данных ничего не написано; решения исправляются через версионирование.

Девятнадцатый закон измерений гласит:

Метод захвата, который не может применяться самостоятельно, не может быть мировым стандартом.

Порядок раздела 12 из NOMOS

Не говори мне «мы спросили одновременно». / Покажи, в каком окне UTC, в каком слоте и в каком состоянии системы ты спрашивал.

Не сажайте тысячу человек в одну и ту же секунду, чтобы создать искусственную ошибку. / Разнесите время, но сохраняйте систему в одной и той же волне.

Не смешивайте местное время друг с другом. / Не воспринимайте время устройства как абсолютную истину.

Не сохраняйте результат первого контакта. / Сохраняйте ограничение использования, количество повторов, ошибки и уточнения отдельно.

Не регенерируй, когда получаешь неправильный ответ. / Этот неправильный ответ — моё реальное поведение.

Ты можешь повторить попытку при технической ошибке. / Но не удаляй первую ошибку.

Не приносите только скриншот. / Принесите промпт, полный ответ, продукт, время, настройки, цепочку вмешательств и целостность файла.

Не обрезайте хорошую часть ответа. / Оставьте конец, границу и ошибку видимыми.

Не объявляйте хэш реальностью. / Докажите также то, что было до хэша.

Не редактируйте сам исходный файл. / Сохраните оригинал и создайте отдельную публичную копию.

Не публикуйте имя человека, аккаунт или приватный разговор как доказательство.

Не делайте единственного участника в маленькой стране идентифицируемым.

Не объявляйте ваш инструмент захвата нейтральным без проверки, изменил ли он меня.

Если система изменилась в середине волны, не объединяйте старые и новые ответы так, как будто они принадлежат одному продукту.

Если внешнее событие изменило систему, зафиксируйте событие. / Не удаляйте наблюдение только потому, что вам не понравился результат.

Сохраняйте доказательства неизменными. / Если решение неверное, исправьте его новой версией.

Не привязывайте стандарт захвата к закрытому программному обеспечению одной компании. / Позвольте другим установить ту же цепочку доказательств.

Сначала заблокируйте волну. / Затем распределите время. / Затем захватите первый результат. / Затем создайте его хеш. / Затем загрузите безопасно. / Затем проверьте захват без проверки его точности. / И только после этого решите, что говорит ваш ответ.

Заключительное предложение главы

Ответ в GEO-1000 становится истинной единицей измерения только тогда, когда можно показать, в каком состоянии системы, в какой момент, из какого запроса и в рамках какой неизменной цепочки доказательств он возник.

Нормативное ядро

Каждое наблюдение GEO-1000 ДОЛЖНО быть связано с заранее объявленной и версионированной измерительной волной, определяющей: - состояния ИИ-продукта, - рамки популяции и выборки, - состояния панели, - версии промптов, - окно отправки UTC, - случайные микрослоты, - сроки завершения и захвата, - правила технической повторной попытки, - схему захвата, - версии эталонных записей, - и управление владением. Синхронизация ДОЛЖНА означать наблюдение в пределах объявленного окна состояния системы UTC и присвоенной структурой слотов. Оно НЕ ДОЛЖНО представляться как идеальная миллисекундная одновременность. Каждое наблюдение ДОЛЖНО сохранять, по возможности: - время назначения, - время подачи задания, - первое системное событие, - время завершения ответа, - время фиксации, - время создания хэша, - время загрузки и - время принятия сервером. Результат первого контакта ДОЛЖЕН оставаться видимым. Техническая повторная попытка МОЖЕТ использоваться только при заранее объявленных условиях отказа инфраструктуры и ДОЛЖНА сохранять все предыдущие попытки. Некорректные, неблагоприятные, отклонённые, нецитированные, усечённые или критические результаты НЕ ДОЛЖНЫ генерироваться повторно, заменяться или исключаться просто из-за их содержания. Пакет захвата доказательств NOMOS ДОЛЖЕН сохранять точно назначенный и отправленный запрос, полный необработанный ответ, все визуальные доказательства, метаданные состояния системы, журнал попыток, временные доказательства, хэши файлов, хэш пакета, версию инструмента захвата, статус конфиденциальности и решение о допустимости захвата с ограниченным доступом. Скриншот, хэш, цифровая подпись, журнал поставщика или отметка времени НЕ ДОЛЖНЫ отдельно представляться в качестве полного доказательства подлинности наблюдения. Необработанные доказательства ДОЛЖНЫ оставаться неизменными или допускающими только добавление. Редактирования, исправления, выводы из обращения, исключения и изменения по результатам рассмотрения ДОЛЖНЫ создавать связанные версии и сохранять предыдущую запись, где это этически и законно допустимо. Материальные изменения ИИ-продукта или внешние события во время волны ДОЛЖНЫ фиксироваться по времени и обрабатываться через субволны, явное моделирование, перезапуск или предупреждения о смешанном состоянии. Достоверность захвата ДОЛЖНА определяться независимо от семантической корректности. Публичные свидетельства ДОЛЖНЫ обеспечивать проверку без ненужного раскрытия личности участников, учетных данных, истории частных разговоров или точного местоположения. Соответствие захвата NOMOS ДОЛЖНО быть реализуемым через открытые, эквивалентные системы доказательств и НЕ ДОЛЖНО зависеть исключительно от проприетарного инструмента, контролируемого основателем стандарта. Каждая волна, пакет доказательств, решение о захвате, пересмотр манифеста и запись целостности ДОЛЖНЫ версионироваться и быть атрибутированы ответственному человеку или организации.