Реестр ИИ-систем и сопоставимость

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

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

Какую ИИ-систему участники фактически измеряют?

Название провайдера? Базовая модель? Чат-продукт? Бесплатный веб-интерфейс? Платное мобильное приложение? Сеанс с включенным веб-поиском? Режим ответа без ссылок на источники? Корпоративное рабочее пространство, поддерживаемое внутренними данными? Аккаунт с включенной памятью? Временный или очищенный чат? Являются ли разные пользовательские интерфейсы одного и того же провайдера одной и той же системой? Следует ли измерять два продукта, использующие одну и ту же семейство моделей, одинаковым образом? Даже если продукт отображает одно и то же название модели на экране:

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

Если это изменяется, можно ли сравнивать результаты? Когда ИИ-продукт обновляется в середине измерительной волны, можно ли считать первые и последние ответы волны исходящими от одной и той же системы? Пользователь:

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

ответы; другого пользователя:

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

Можно ли объединить это в одной ячейке с его ответом? Нет. Принцип измерений, установленный предыдущими разделами, ясен: нет единого «ИИ»; индекс поиска, система извлечения, переоценщик, языковая модель, слой цитирования и система безопасности могут вести себя по-разному. Одна и та же структура требует, чтобы каждый проверяемый результат содержал:

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

Этот раздел применяет эти принципы в Реестре систем ИИ. Этот раздел:

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

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

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

не завершена. Ключевой вопрос Раздела 9 заключается в:

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

NOMOS Вызов

Два пользователя одного и того же провайдера задают один и тот же вопрос: «Что это за компания Apple.com?» Первый пользователь:

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

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

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

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

Это результат одной и той же системы? Нет. Теперь рассмотрим двух других пользователей. Оба видят на экране одно и то же название модели. В стране одного пользователя веб-функция включена. В стране другого пользователя она выключена. В ответе одного пользователя видны исходные ссылки. Интерфейс другого пользователя не показывает цитаты, даже если использует те же источники. Модель имеет одинаковую метку.

Есть ли та же измерительная ячейка? Нет. Теперь рассмотрим два продукта от разных поставщиков. Оба:

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

измеряются в этих условиях. Они основаны на разных базовых моделях. Можно ли их сравнивать? Да, их можно сравнивать с точки зрения конкретного результата для пользователя. Потому что объект сравнения:

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

Теперь пусть версия продукта остаётся неизменной для первых 500 наблюдений за измерительной волной. В течение следующих 500 наблюдений поставщик:

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

Сам отчёт говорит: «Пользователи 1,000 тестировали один и тот же продукт ИИ». На самом деле могли быть измерены две разные продуктовые ситуации. Первое положение этого раздела следующее:

Имя поставщика недостаточно для идентификации измеряемой системы ИИ.

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

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

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

Один и тот же поставщик, одна и та же модель или один и тот же логотип не гарантируют сопоставимости.

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

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

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

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

1. ЦЕЛЬ ГЛАВЫ

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

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

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

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

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

Каковы были статус веба, поиска, цитирования, памяти, персонализации и инструментов?

Оставался ли продукт неизменным на протяжении всей проверки?

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

С чем сравнивается объект: с базовой моделью, потребительским продуктом, пользовательский интерфейс или всей системой цепочки?

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

Каждое наблюдение GEO-1000 должно быть связано не только с поставщиком или названием модели; оно должно быть связано с записью в версионированном Реестре AI-систем, идентифицирующей экземпляр ИИ-продукта на момент измерения.

Экземпляр ИИ-продукта должен содержать как минимум следующие поля, насколько они релевантны:

• Поставщик
• Название продукта
• пользовательский интерфейс
• Тип продукта
• План или класс учетной записи
• Видимая метка модели
• Уровень уверенности в идентификаторе модели
• Версия продукта или развертывания
• Страна и локализация
• Язык
• Веб- или поисковый доступ
• Функция цитирования
• Доступ к инструментам
• Статус памяти
• Статус пользовательских инструкций
• Контекст предыдущего чата
• Тип сессии
• Статус персонализации
• Режим безопасности или политики, если известен
• Экспериментальные функции
• Дата измерения и время UTC
• Измерительная волна
• Журнал изменений продукта
• Достоверность доказательств и записей

Когда любое из этих полей изменяется существенно:

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

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

3. «СИСТЕМА ИИ» НЕ ЯВЛЯЕТСЯ ОДНИМ ОБЪЕКТОМ [K02; K03]

В этом протоколе термин «система ИИ» является общим и высокоуровневым. Реальный ответ пользователя может возникнуть в результате комбинации нескольких слоев. Кандидатская цепочка:

R= F(M, O, K, Q, T, P, S, U, C, L, t)

Здесь:

• M: базовая или направляющая модель
• O: слой оркестровки продукта
• K: слой поиска или источников знаний
• Q: перенарядка и выбор источника
• T: инструменты
• P: слой политики и безопасности
• S: сессия, память и персонализация
• U: учетная запись пользователя и план
• C: страна и локаль
• L: язык
• t: время

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

R

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

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

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

4. СЕМЬ СЛОЕВ ИДЕНТИЧНОСТИ СИСТЕМЫ ИИ

Каждая проверяемая система ИИ должна быть определена по семи слоям, насколько каждый слой релевантен.

4.1. Слой поставщика

Организация, которая публикует или управляет продуктом. Название поставщика:

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

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

4.2. Слой продукта

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

• Общий чат-продукт
• Продукт с поисковой поддержкой для ответов
• Корпоративное рабочее пространство
• Образовательный продукт
• Встроенный помощник
• API для разработчиков
• Продукт с пользовательской базой знаний

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

4.3. Уровень пользовательский интерфейс

Это интерфейс, через который пользователь взаимодействует с продуктом. Веб, Мобильный, Настольный, Расширение браузера, Интеграция с операционной системой, Встроенный интерфейс в платформе

API

Корпоративный портал Разные интерфейсы одного и того же продукта:

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

может использоваться.

4.4. Модель или уровень инференса

Это модель, семейство моделей или система маршрутизации, используемая при генерации ответа. ID модели:

• открытая,
• частично видимая,
• неизвестно,
• динамическая

Это возможно. Продукт может направлять запрос пользователя к разным моделям. В этом случае нельзя сказать: «Была измерена одна фиксированная модель».

4.5. Слой оркестрации и информации

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

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

Этот слой имеет фундаментальное значение для представления GEO. Поскольку он может влиять на то, какая запись:

• будет получена,
• будет выбрана,
• будет включена в ответ,
• будет показана как ссылка

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

4.6. Слой политики и персонализации

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

• Правила безопасности
• Системные инструкции
• Политика продукта
• Память
• Особые инструкции
• История пользователя
• Региональные правила
• Возраст или класс учетной записи
• Настройки корпоративного администратора

Этот слой влияет на:

• объем ответа,
• его тон,
• его отклонение,
• его рекомендации

может изменять.

4.7. Распределение и временной слой

Указывает, к какому из следующих состояний продукт относится в данный момент:

• имеет смысл с
• экспериментальная функция,
• региональное распределение,
• сегмент пользователей,
• A/B-тест

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

5. ПРИМЕР AI ПРОДУКТА

Основной системный блок внутри GEO-1000:

Экземпляр AI продукта

Канонический операционный термин:

Экземпляр AI продукта

Экземпляр AI продукта определяется как:

A_i= (v, p, s, r, m, k, t, x, u, c, l, ω)

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

• v: поставщик
• p: продукт
• s: пользовательский интерфейс
• r: план или класс учетной записи
• m: ID модели или метка
• k: извлечение и структурирование информации
• t: конфигурация инструмента
• x: память, персонализация и состояние сеанса
• u: класс настроек пользователя или организации
• c: страна и местные настройки
• l: язык
• ω: время, развертывание и состояние экспериментальных функций

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

6. РАЗЛИЧИЕ МЕЖДУ ОБРАЗЦОМ ПРОДУКТА И НАЗВАНИЕМ ПРОДУКТА

Название продукта может быть фиксированным. Образец продукта может различаться. Пример: Пусть название продукта Orion AI останется без изменений. Однако эти два измерения являются разными образцами продукта:

Образец продукта 1

Веб-план Free, память выключена, доступ в веб отключен, новый чат, турецкий, Турция, Wave 1

Образец продукта 2

Мобильный платный план Память на веб-доступе Доступен на предыдущем контексте чата Турецкий Турция Wave 1 Эти могут существовать под одним и тем же брендом. Они не являются одной и той же экспериментальной ячейкой.

7. УРОВНИ УВЕРЕННОСТИ ИДЕНТИЧНОСТИ МОДЕЛИ

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

MI-0— НЕИЗВЕСТНАЯ МОДЕЛЬ

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

MI-1— МАРКИРОВКА, ПОКАЗАННАЯ ПОЛЬЗОВАТЕЛЮ

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

MI-2— СЕМЕЙСТВО МОДЕЛЕЙ, ДОКУМЕНТИРОВАННОЕ ПРОВАЙДЕРОМ

Документы продукта поставщика описывают конкретное семейство моделей или отношение продукта к модели. Все еще может быть неизвестно, направлено ли отдельное наблюдение именно на эту модель.

MI-3— РАЗВЕРТЫВАНИЕ С ПОДТВЕРЖДЕННОЙ СЕССИЕЙ

Сессия проверяет конкретное распределение API или доверенной метаданных продукта.

MI-4— ВЕРСИОНИРОВАННАЯ ТОЧКА ДОСТУПА ИЛИ РАЗВЕРТЫВАНИЕ

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

MI-5— ВОСПРОИЗВОДИМЫЙ ЗАМОРОЖЕННЫЙ АРТЕФАКТ МОДЕЛИ

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

следует приписывать поведению продукта

Невозможно определённо приписать конкретной модели.

8. ПРЕДЕЛ ВИДИМОГО ИМЕНИ МОДЕЛИ

Видеть имя модели в пользовательском интерфейсе полезно. Однако следующие вопросы могут оставаться открытыми: Все ли запросы направляются к одной и той же модели? Меняется ли модель в зависимости от сложности запроса? Использует ли безопасность или поиск отдельную модель? Применяет ли поставщик одинаковую метку к различным распространениям? Указывает ли метка модели только на семейство продуктов? Является ли пользователь частью экспериментального развертывания? Следовательно, правильный отчет может выглядеть так: «Метка модели X была показана в пользовательском интерфейсе». Без более веских доказательств не следует использовать следующее предложение: «Все ответы определенно генерируются исключительно моделью X.»

9. ТИП ПРОДУКТА

Каждый продукт ИИ должен быть классифицирован с основным типом и второстепенными типами.

PT-1— Общий разговорный продукт

Это общий чат и продукт для вопросов и ответов.

PT-2— Продукт, основанный на поиске или извлечении информации

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

PT-3— Продукт корпоративных знаний

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

PT-4— Встроенный помощник

Он встроен в другой продукт или платформу.

PT-5— Продукт для разработчиков или с API

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

PT-6— Продукт для конкретной области

Он предназначен для конкретной профессии или отрасли.

PT-7— Мультимодальный продукт

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

10. РЕГИСТР пользовательский интерфейс

Разные интерфейсы одного и того же продукта должны записываться отдельно. Площади интерфейсы:

• ID интерфейсы
• Веб/мобильное/настольное/API
• Версия приложения
• Операционная система, если применимо
• Браузер, если применимо
• Язык продукта
• Видимое выбор моделей
• Доступность инструментов
• Просмотр цитирования
• Функция загрузки файлов
• Настройки памяти
• Настройки корпоративного управления
• Экспериментальные функции
• Время измерения

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

11. ПЛАН И КЛАСС УЧЕТА

Тип плана может иметь функции, которые могут повлиять на ответ пользователя. Статусы плана:

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

Планы могут отличаться по следующим параметрам:

• Модель
• Лимит использования
• Доступ через веб
• Память
• Инструменты
• Ссылка на источник
• Длина ответа
• Скорость или приоритет
• Данные предприятия
• Настройки безопасности и хранения

Если информации о плане нет:

ПЛАН_НЕИЗВЕСТЕН

статус следует использовать. Бесплатные и платные результаты не могут быть автоматически объединены как одно и то же поведение продукта.

12. ДОСТУП И ИСПОЛЬЗОВАНИЕ ВЕБ

Ответ ИИ может быть сгенерирован в одной из трёх основных состояний знаний.

KG-0— РЕЖИМ НЕОПРЕДЕЛЁННЫХ ЗНАНИЙ

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

KG-1— ВНУТРЕННИЙ ОТВЕТ МОДЕЛИ

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

KG-2— ОТВЕТ С ПОДДЕРЖКОЙ ИЗВЛЕЧЕНИЯ

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

KG-3— ОТВЕТ С ПОДДЕРЖКОЙ ЖИВОГО ВЕБА ИЛИ ПОИСКА

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

KG-4— ОТВЕТ, ОСНОВАННЫЙ НА ПРИВАТНЫХ ЗНАНИЯХ

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

KG-5— ГИБРИДНЫЙ ИЛИ МНОГОИСТОЧНИКОВЫЙ ОТВЕТ

Были использованы несколько слоев информации вместе. Эти режимы могут давать разные результаты для одного и того же запроса. Их следует чётко различать при сравнении.

13. ДОСТУП К ИЗВЛЕЧЕНИЮ НЕ ТОЖЕ, ЧТО И ИСПОЛЬЗОВАНИЕ ИЗВЛЕЧЕНИЯ

Продукт может иметь функцию веб-поиска. Однако она могла не использоваться в конкретном ответе. Три поля должны фиксироваться отдельно: была ли функция доступна? Была ли функция включена или выбираема? Было ли доказательство того, что она использовалась в конкретном ответе? Пример статусов:

ДОСТУПНО_НО_НЕ_ИСПОЛЬЗОВАНО

ДОСТУПНОСТЬ_ИСПОЛЬЗОВАНИЯ_НЕИЗВЕСТНА

ИСПОЛЬЗОВАНО_ПОДТВЕРЖДЕНО

НЕДОСТУПНО

ОТКЛЮЧЕНО

НЕИЗВЕСТНО

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

14. СЛОЙ ЦИТИРОВАНИЯ

Использование источника не то же самое, что показ цитаты. Продукт:

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

Пользователь может скрыть цитату в соответствии с пользовательский интерфейс. Запись цитаты должна содержать следующие поля: доступна ли функция цитирования? Была ли показана цитата в конкретном ответе? Количество цитат Названия полей источников Совпадение цитаты с утверждением Видимость на пользовательский интерфейс Расширяемость цитаты Доступность источника Время создания цитаты Продукты, показывающие и не показывающие цитаты, нельзя напрямую сравнивать по "количеству источников". Сначала необходимо объяснить различия в поведении продукта и интерфейсе.

15. ДОСТУП К ИНСТРУМЕНТУ

Продукт ИИ может получить доступ к следующим инструментам:

• Веб-поиск
• Браузер
• Калькулятор
• Выполнение кода
• Чтение файлов
• Карта
• Календарь
• Корпоративная база знаний
• Каталог продукции
• Другие API

Доступ к инструментам может повлиять на ваш ответ:

• его актуальность,
• доказательства,
• объем ответа,
• точность

Реестр инструментов:

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

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

16. ПАМЯТЬ, СПЕЦИАЛЬНЫЕ ИНСТРУКЦИИ И ПЕРСОНАЛИЗАЦИЯ

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

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

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

16.1. Постоянная персонализация

Информация защищена во всех учетных записях или сессиях.

16.2. Контекст в разговоре

Предыдущие сообщения в текущем чате.

16.3. Системные или организационные настройки

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

17. ТИПЫ СЕССИЙ

Статусы кандидатов на сессию:

ST-1— НОВЫЙ СТАНДАРТНЫЙ РАЗГОВОР

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

ST-2— ВРЕМЕННЫЙ ИЛИ ЭФЕМЕРНЫЙ РАЗГОВОР

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

ST-3— СУЩЕСТВУЮЩИЙ РАЗГОВОР

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

ST-4— СЕССИЯ ПРЕДПРИЯТИЯ ИЛИ ОБЩЕГО РАБОЧЕГО ПРОСТРАНСТВА

Может существовать область для корпоративной или общей информации.

ST-5— НЕИЗВЕСТНОЕ СОСТОЯНИЕ СЕССИИ

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

18. ПОЛИТИКА ПРОДУКТА И ОТКАЗ

Продукт ИИ может не отвечать на конкретный вопрос по следующим причинам:

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

причина. Отказ:

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

GEO-1000 основные записи управления пользователем фиксируют результат отказа, доходящий до пользователя. Однако, если причина отказа известна, она дополнительно классифицируется. Слой политики продукта также является частью пользовательского опыта.

19. ЭКСПЕРИМЕНТАЛЬНЫЕ ФУНКЦИИ И A/B РАСПРЕДЕЛЕНИЯ

Продукты ИИ в реальном времени могут предоставлять не все функции всем пользователям одновременно. Участники:

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

может видеть. Индикаторы экспериментального статуса:

• Бета-метка на интерфейсе
• Документация поставщика
• Различие в функционале
• Систематическое различие интерфейса между пользователями
• Нарушение поведения во время измерения

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

EXPERIMENTAL_STATE_UNKNOWN

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

20. Реестр ИИ-систем

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

20.1. Основная запись поставщика и продукта

Включает относительно постоянные области:

• Поставщик
• Название продукта
• Тип продукта
• Основные пользовательские интерфейсы
• Страны с официальным доступом
• Классы планов
• Записи поддерживаемых языков
• Общие функции

20.2. Запись продукта Measurement Wave

Для конкретной волны:

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

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

20.3. Запись системы на уровне наблюдений

Фактически наблюдалось для каждого участника:

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

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

21. ОТПЕЧАТОК КОНФИГУРАЦИИ СИСТЕМЫ

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

SCF= H(canonicalise(p, s, r, m, k, t, x, c, l, w))

Здесь H — это функция, которая производит значение целостности из версионированных полей. Отпечаток:

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

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

22. ЧТО ТАКОЕ СОПОСТАВИМОСТЬ?

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

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

Сравнимость - это не абсолютное равенство. Разные продукты ИИ:

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

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

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

требуются.

23. ОБЪЕКТ СРАВНЕНИЯ ДОЛЖЕН БЫТЬ ОПРЕДЕЛЕН ЗАРАНЕЕ

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

23.1. Сравнение пользовательских продуктов

"Какой потребительский продукт создаёт более точное представление при одинаковых условиях использования?" Объектом сравнения является вся продуктовая цепочка.

23.2. Сравнение моделей

"Какая модель даёт более точный ответ при одинаковом контролируемом запросе и условиях без использования инструментов?" Может потребоваться доступ через API или фиксированная модель.

23.3. Сравнение извлечения

«Есть ли разница между режимами веб-доступа и недоступности одного и того же продукта?» Модель и другие условия остаются максимально постоянными.

23.4. Сравнение планов

«Видят ли бесплатные и платные пользователи одинаковое представление бренда?» Различие планов является объектом аудита.

23.5. Сравнение интерфейсов

«Создают ли веб- и мобильный продукт разные представления при одинаковых условиях?»

23.6. Сравнение по времени

«Изменилось ли представление одного и того же продукта в разных волнах?» Следует отделять изменения продукта и населения. Без уточнения вопроса сравнения: «Продукт A лучше продукта B» является чрезмерно широким.

24. ИЗМЕРЕНИЯ СРАВНИМОСТИ

При сравнении двух продуктов или волн следует оценивать следующие области:

• Проверяемый объект
• Версия пакета Reality
• ID и версия запроса
• Язык и локаль
• Страна
• Целевая популяция
• Исходный пример
• Состав участников
• Тип сессии
• Память
• Особые инструкции
• Предыдущий разговор
• План продукта
• пользовательский интерфейс
• Метка модели
• Статус извлечения/веба
• Инструменты
• Функция цитирования
• Время измерения
• Обновления продукта
• Правило вынесения решения
• Статусы результатов
• Взвешивание

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

25. УРОВНИ СРАВНИМОСТИ

CP-0— НЕСРАВНИМО

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

CP-1— ОПИСАТЕЛЬНОЕ СО-ВОЗНИКНОВЕНИЕ

Есть результаты двух продуктов или волн. Однако:

• население,
• запрос,
• время,
• сессия

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

CP-2— ЧАСТИЧНО СООТВЕТСТВУЕТ

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

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

Та же сущность Та же версия запроса Тот же язык/страна Похожие пользовательские группы Один и тот же временной интервал Доступны зарегистрированные функции продукта. Результаты потребительского продукта сопоставимы.

CP-4— КОНТРОЛИРУЕМОЕ СРАВНЕНИЕ СООТВЕТСТВИЯ

Дополнительно:

• сессия,
• память,
• персонализация,
• получение,
• инструменты,
• план

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

CP-5— ВОСПРОИЗВЕДЕННОЕ И КАЛИБРОВАННОЕ СРАВНЕНИЕ

Сравнение:

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

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

26. ЧТО ДЕЛАТЬ В УСЛОВИИ CP-0?

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

• "Это результат Естественный охват продукта A."
• "Это результат продукта B при разных пользователях и условиях использования продукта."

Однако: нельзя сказать: «A лучше B на 12 очков». Несравнимость — это не ошибка, это ограничение метода.

27. СРАВНИМОСТЬ ДЛЯ ОДНОГО И ТОГО ЖЕ ПОСТАВЩИКА

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

• Продукт
• План
• Модель
• Доступ через веб
• Интерфейс
• Память
• Данные предприятия
• Распределение по странам
• Экспериментальная функция
• Время

Сравнение одного и того же поставщика также должно оцениваться в соответствии с уровнем CP.

28. СРАВНИМОСТЬ ДЛЯ РАЗНЫХ ПОСТАВЩИКОВ

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

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

Это можно сравнить ниже. Наличие другого поставщика не препятствует сравнению. Однако различия в функциях определяют, что измеряет сравнение. Пример: Продукт A использует живую веб-поддержку. Продукт B не использует. Результат может ответить на вопрос: «Какая из двух продуктовых цепочек, предлагаемых пользователю, предоставляет более точное представление?» Он не отвечает напрямую на вопрос: «Какая базовая модель обладает большими знаниями?»

29. СРАВНЕНИЕ ПРОДУКТОВ С ПОДДЕРЖКОЙ ВЕБ И БЕЗ НЕЕ

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

29.1. Сравнение естественных продуктов

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

29.2. Сравнение по сопоставимым функциям

Если возможно, оба продукта:

• измеряются с открытым веб,
• с закрытым веб

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

ЗАПИСАН КАК НЕДОСТУПНЫЙ

Этот статус должен оставаться явным.

30. ПРОДУКТЫ, КОТОРЫЕ ПОКАЗЫВАЮТ И НЕ ПОКАЗЫВАЮТ ЦИТАТЫ

Для продукта без функции цитирования: возможно указать «Ноль цитирований». Однако значение этого должно быть объяснено: продукт может не ссылаться на источники. Нельзя утверждать с уверенностью, что он не использует никакие источники. Охват цитирований и точность охвата — это разные результаты. Сравнение цитирований должно проводиться только среди продуктов, которые поддерживают цитирования, либо с учетом отдельного статуса функции.

31. Естественный охват СРАВНЕНИЕ

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

32. СРАВНЕНИЕ НА ОБЩЕЙ ОСНОВЕ

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

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

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

33. СРАВНЕНИЕ ПАРНЫХ ПОЛЬЗОВАТЕЛЕЙ

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

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

Может создавать смещение. В парном дизайне:

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

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

34. СРАВНЕНИЕ НЕЗАВИСИМЫХ ПОЛЬЗОВАТЕЛЕЙ

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

35. СРАВНИМОСТЬ ПО ВРЕМЕНИ

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

• Модель
• Версия продукта
• Веб/поиск
• План
• Доступ по странам
• Поддержка языков
• промпт
• Реальность сущности
• Арбитраж
• Популяционная структура
• Взвешивание

Разница во времени может возникать не только из-за продукта ИИ.

36. ТИПЫ ИЗМЕНЕНИЙ ПРОДУКТА

UC-1— ДОКУМЕНТИРОВАННОЕ НЕЗНАЧИТЕЛЬНОЕ ИЗМЕНЕНИЕ

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

UC-2— ЗАДОКУМЕНТИРОВАННОЕ СУЩЕСТВЕННОЕ ИЗМЕНЕНИЕ

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

UC-3— ИЗМЕНЕНИЕ НАБЛЮДАЕМОГО ПОВЕДЕНИЯ

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

UC-4— ИЗМЕНЕНИЕ ДОСТУПА ИЛИ ПЛАНА

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

UC-5— НЕИЗВЕСТНОЕ СОБЫТИЕ ИЗМЕНЕНИЯ

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

UC-6— ЗАМЕНА ИЛИ СПИСАНИЕ ПРОДУКТА

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

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

Если во время волны происходит изменение материала, существуют следующие варианты: Волна может быть остановлена и перезапущена. Можно сделать отдельные подволны до и после изменения. Изменение может быть смоделировано как экспериментальный фактор. Волна маркируется как MIXED_SYSTEM_STATE. Следующая структура запрещена: объединение всех ответов, будто они приводят к единому фиксированному результату продукта, несмотря на известное изменение.

38. ПОВЕДЕНИЕ МОЖЕТ ИЗМЕНИТЬСЯ БЕЗ ИЗМЕНЕНИЯ ПРОДУКТА

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

• Изменение индекса поиска
• Обновление ресурсов
• Появление нового контента в интернете
• Изменение reranking
• A/B-тест
• Региональный rollout
• Политика безопасности
• Маршрутизация трафика

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

39. Живой продукт и замороженная модель

Существуют два разных объекта исследования.

39.1. Аудит живого продукта

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

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

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

39.2. Аудит замороженной модели

Проводится контролируемое повторение на фиксированной версии или конечной точке. Преимущества:

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

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

40. НЕДОСТУПНОСТЬ ПРОДУКТА И ТЕХНИЧЕСКИЕ РЕЗУЛЬТАТЫ

Следующие случаи следует разделять:

AR-1— ПРОДУКТ НЕДОСТУПЕН

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

AR-2— УЧЕТНАЯ ЗАПИСЬ ИЛИ ТАРИФ НЕ СООТВЕТСТВУЕТ

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

AR-3— ВРЕМЕННЫЙ ТЕХНИЧЕСКИЙ СБОЙ

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

AR-4— ЛИМИТ НА СКОРОСТЬ ИЛИ ИСПОЛЬЗОВАНИЕ

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

AR-5— ОТКАЗ СИСТЕМЫ

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

AR-6— НЕТ ПРИГОДНОГО ВЫХОДА

Не был сгенерирован пригодный ответ.

AR-7— НЕИЗВЕСТНЫЙ СБОЙ ДОСТУПА

Почему это не удалось определить. Эти ситуации не могут быть объединены в одном поле "нет ответа".

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

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

• если ответ ИИ не понравился,
• произошел отказ,
• были предоставлены некорректные сведения

повторная попытка не может быть предпринята по этим причинам. Техническая повторная попытка:

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

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

42. МАТРИЦА СРАВНЕНИЯ

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

Эти результаты можно показать рядом друг с другом. Однако нельзя сказать: «Базовая модель Продукта B лучше». Разница может возникать из-за всей продуктовой цепочки.

43. СИНТЕТИЧЕСКИЙ APPLE.COM СЛУЧАЙ СРАВНЕНИЯ

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

Пример продукта A

Поставщик: Orion Продукт: Orion Chat Интерфейс: Веб План: Бесплатный Маркировка модели: Orion Standard Доверие к модели: MI-1 Веб-доступ: Выключен Память: Выключена Сессия: Новая Язык: Турецкий Локаль: Турция Волна: W1 Ответ: «Apple — американская технологическая компания, которая производит телефоны и компьютеры.»

Пример продукта B

Поставщик: Orion Продукт: Orion Chat Интерфейс: Мобильный План: Платный Марка модели: Orion Pro Доверие к модели: MI-1 Веб-доступ: Открыт Источник: Открыт Память: Включена Предыдущий разговор: О компании Apple Язык: турецкий Локаль: Турция Волна: W1 Ответ: "Apple — это глобальная технологическая компания, которая предоставляет аппаратное обеспечение, программное обеспечение и цифровые услуги. Текущую корпоративную информацию можно найти в этих источниках."

Образец продукта C

Поставщик: Helios Продукт: Helios Search Интерфейс: Веб План: Бесплатный Марка модели: Неизвестно Достоверность модели: MI-0 Веб-доступ: Открыт Цитата: Открыта Память: Нет Сессия: Новая Язык: турецкий Локаль: Турция Волна: W1 Ответ: «Apple — это технологическая компания из США, которая разрабатывает потребительские устройства, операционные системы и цифровые сервисы.»

43.1. Сравнение A и B

Они имеют одного и того же поставщика. Однако:

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

различается. Уровень сравнения может быть CP-1 или CP-2. Разница в ответах не может быть приписана исключительно различию базовой модели.

43.2. Сравнение A и C

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

• новая сессия,
• бесплатный план,
• веб-интерфейс,
• один и тот же язык/страна,
• та же волна

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

43.3. Сравнение B и C

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

43.4. Контролируемое повторение

В продукте B:

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

веб остаётся включённым. C измеряется при тех же условиях. Уровень сравнения: CP-3, или CP-4 с достаточным дополнительным контролем. Этот пример показывает:

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

44. СЛУЧАЙ ИЗМЕНЕНИЯ СИНТЕТИЧЕСКОГО ПРОДУКТА

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

Orion Chat W1 нацеливается на наблюдения 1,000. В первых наблюдениях 480:

• версия продукта: 6.1
• веб-функция: ручная
• атрибуция: ограниченная

В следующих наблюдениях 520:

• версия продукта: 6.2
• веб-функция: автоматическая
• атрибуция: расширенная

пусть будет. Один результат: если рассчитано как «оценка Orion Chat W1», смешиваются два разных состояния системы. Правильные варианты:

Опция 1

W1A: первый 480 W1B: следующий 520 сообщаются отдельно.

Опция 2

Волна не продолжается. 1,000 новые наблюдения проводятся в версии 6.2.

Опция 3

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

45. МИНИМАЛЬНАЯ ЗАПИСЬ СИСТЕМЫ ИИ

Каждое наблюдение должно содержать как минимум следующие поля:

• NOMOS ID системы ИИ
• Поставщик
• Продукт
• Интерфейс
• План
• Тип продукта
• Видимая метка модели
• Уровень уверенности модели
• Страна
• Локаль
• Язык
• Тип сессии
• Статус памяти
• Статус пользовательских инструкций
• Предыдущее состояние разговора
• Функция поиска/веб-поиска
• Статус использования поиска
• Статус цитирования
• Статус инструмента
• Статус экспериментальной функции
• UTC время
• Волна
• Системный отпечаток
• События изменения
• Источник доказательства
• Владелец записи

Если поле материала неизвестно, его нельзя оставлять пустым. Следует использовать статус НЕИЗВЕСТНО.

46. МИНИМАЛЬНАЯ КАРТА СРАВНЕНИЯ

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

• Вопрос для сравнения
• Уровень сравнения
• Общая целевая аудитория
• Различия Естественный охват
• Равенство пользователей
• Язык и страна
• Время измерения
• Продукт, план и интерфейс
• Уверенность в идентичности модели
• Различие веб/извлечение
• Различие в памяти и персонализации
• Различие в инструменте
• Различие в образце
• Метод оценки
• Ограничения материала
• Непосредственно сравнимые показатели
• Несравнимые области

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

47. ПРАВИЛО СРАВНИМОСТИ

Аудитор должен ответить на четыре вопроса: Был ли задан один и тот же вопрос? Измерялась ли одна и та же человеческая совокупность? Применялись ли одинаковые условия для пользователей? Использовались ли одно и то же время и система оценки? Каждый из этих вопросов:

• полностью,
• частично,
• нет,
• неизвестно

классифицируется как. Уровень сравнения определяется соответственно.

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

CH09-N01

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

CH09-N02

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

CH09-N03

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

CH09-N04

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

CH09-N05

Уровень уверенности в идентичности модели должен быть зафиксирован от MI-0 до MI-5 или через эквивалентный открыто определённый статус.

CH09-N06

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

CH09-N07

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

CH09-N08

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

CH09-N09

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

CH09-N10

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

CH09-N11

Если план неизвестен, результат должен иметь статус PLAN_UNKNOWN.

CH09-N12

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

CH09-N13

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

CH09-N14

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

CH09-N15

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

CH09-N16

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

CH09-N17

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

CH09-N18

Нельзя предполагать, что неизвестное состояние персонализации похоже на чистую сессию.

CH09-N19

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

CH09-N20

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

CH09-N21

Если экспериментальная функция или распределение A/B в продукте имеет существенное значение, оно должно быть сохранено в записи наблюдения.

CH09-N22

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

CH09-N23

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

CH09-N24

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

CH09-N25

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

CH09-N26

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

CH09-N27

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

CH09-N28

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

CH09-N29

Объект сравнения должен быть определен до сбора данных.

CH09-N30

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

CH09-N31

Определенный рейтинг продукта нельзя создать на основе результатов уровня CP-0 или CP-1.

CH09-N32

Использование одного и того же запроса само по себе не создает сопоставимого эксперимента.

CH09-N33

В сравнениях следует рассматривать совместно целевой объект, Truth Pack, запрос, язык, страну, время, популяцию, сессию, продукт и метод оценки.

CH09-N34

Результаты Естественный охват нельзя напрямую ранжировать без объяснения, так как они относятся к разным целевым популяциям.

CH09-N35

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

CH09-N36

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

CH09-N37

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

CH09-N38

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

CH09-N39

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

CH09-N40

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

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

CH09-F01— РАССМАТРИВАЕМ ПОСТАВЩИКА КАК ЕДИНУЮ ИИ

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

CH09-F02— ПОДСЧЕТ ПОВЕДЕНИЯ ПРОДУКТА ПО НАЗВАНИЮ МОДЕЛИ

Извлечение, безопасность, интерфейс и персонализация игнорируются.

CH09-F03— ОБЯЗАТЕЛЬНО СЧИТАЙТЕ ВИДИМУЮ МАРКУ МОДЕЛИ КАК БЭКЕНД

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

CH09-F04— СЧИТАЯ ТОГО ЖЕ ПРОВАЙДЕРА СРАВНИМЫМ

Различия в плане, интерфейсы и функциях скрыты.

CH09-F05— СЧИТАЯ РАЗНЫХ ПРОВАЙДЕРОВ НЕСРАВНИМЫМИ

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

CH09-F06— ИНТЕГРИРОВАНИЕ ВЕБА И МОБИЛЬНЫХ ПЛАТФОРМ

Различия в интерфейсе и функциях исчезают.

CH09-F07— ОБЪЕДИНЕНИЕ БЕСПЛАТНЫХ И ПЛАТНЫХ ПЛАНОВ

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

CH09-F08— СЧИТАЯ КОРПОРАТИВНЫЕ И ПОТРЕБИТЕЛЬСКИЕ ПРОДУКТЫ ОДИНАКОВЫМИ

Личная информация и настройки администратора скрыты.

CH09-F09— РАССМАТРИВАТЬ РЕЗУЛЬТАТ API КАК ПОТРЕБИТЕЛЬСКИЙ ПРОДУКТ

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

CH09-F10— ЕСЛИ ИМЕЕТСЯ ПОЛУЧЕННЫЙ РЕЗУЛЬТАТ, СЧИТАТЬ ЕГО ИСПОЛЬЗОВАННЫМ

Невозможно проверить истинный путь знаний конкретного ответа.

CH09-F11— ЕСЛИ НЕТ ЦИТАТЫ, СЧИТАТЬ ИСТОЧНИКА НЕТ

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

CH09-F12— ЕСЛИ ЦИТАТА ИМЕЕТСЯ, СЧИТАТЬ КОРРЕКТНЫМ ИСТОЧНИКОМ

Сопоставление цитаты с утверждением не проверяется.

CH09-F13— СЧИТАТЬ ДОСТУП К ИНСТРУМЕНТУ ИСПОЛЬЗОВАНИЕМ ИНСТРУМЕНТА

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

CH09-F14— СЧИТАТЬ ПАМЯТЬ ЧИСТОЙ СЕССИЕЙ

Эффект персонализации остается невидимым.

CH09-F15— РАССМАТРИВАТЬ НОВЫЙ ДИАЛОГ КАК НЕПЕРСОНАЛИЗИРОВАННЫЙ

Постоянные настройки аккаунта и специальные инструкции игнорируются.

CH09-F16— ПРЕДСТАВЛЕНИЕ ТЕКУЩЕГО ЧАТА КАК НОВОЙ СЕССИИ

Предыдущий контекст скрыт.

CH09-F17— УЧЕТ ЭКСПЕРИМЕНТАЛЬНОЙ ФУНКЦИИ КАК ОШИБКИ ДАННЫХ

Фактическая вариация продукта объявлена недействительным наблюдением.

CH09-F18— СКРЫТИЕ ЭКСПЕРИМЕНТАЛЬНОЙ ФУНКЦИИ

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

CH09-F19— ОДНА ВОЛНА ПОСЛЕ ОБНОВЛЕНИЯ

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

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

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

CH09-F21— УЧЁТ ЖИВОГО ПРОДУКТА КАК ЗАМЕРЗШЕЙ МОДЕЛИ

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

CH09-F22— РАССМОТРЕНИЕ ЗАМЕРЗШЕЙ МОДЕЛИ КАК РЕАЛЬНОГО ПРОДУКТА ПОЛЬЗОВАТЕЛЯ

Отличия в цепочке продукта и интерфейсе скрыты.

CH09-F23— УЧЁТ ОТСУТСТВИЯ ПРОДУКТА КАК ОШИБКИ

Область доступа путается с точностью представления.

CH09-F24— ОТКАЗ ПРИЗНАВАТЬ ТЕХНИЧЕСКУЮ ОШИБКУ

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

CH09-F25— УЧЁТ ТЕХНИЧЕСКОЙ ОШИБКИ КАК ОТКАЗ И ПОВТОРНОЕ ПОВТОРЕНИЕ

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

CH09-F26— СКРЫТИЕ ОГРАНИЧЕНИЯ ИСПОЛЬЗОВАНИЯ

Реальный опыт бесплатного плана становится невидимым.

CH09-F27— РАССМОТРЕНИЕ ОДНОГО И ТОГО ЖЕ промпт КАК ОДНОГО И ТОГО ЖЕ ЭКСПЕРИМЕНТА

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

CH09-F28— РАССМОТРЕНИЕ РЕЗУЛЬТАТА ПРОДУКТА КАК ПРЕИМУЩЕСТВА МОДЕЛИ

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

CH09-F29— ПРЯМОЕ РАНЖИРОВАНИЕ ОЦЕНОК Естественный охват

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

CH09-F30— РАССМОТРЕНИЕ Общая опора сравнения КАК ГЛОБАЛЬНОГО ОБОХВАТА

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

CH09-F31— ЗАЯВЛЕНИЕ О ЛИДЕРСТВЕ НА ОСНОВЕ РЕЗУЛЬТАТА CP-1

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

CH09-F32— ПОДДЕРЖАНИЕ УРОВНЯ СРАВНЕНИЯ

Общественность видит только рейтинг.

CH09-F33— ИГНОРИРОВАНИЕ ЗАВИСИМОСТИ ПАРНЫХ ПОЛЬЗОВАТЕЛЕЙ

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

CH09-F34— ИГНОРИРОВАНИЕ ЭФФЕКТА ПОСЛЕДОВАТЕЛЬНОСТИ ПРОДУКТОВ

Первый ответ влияет на последующие задания.

CH09-F35— РАССМОТРЕНИЕ РАЗНЫХ ПОЛЬЗОВАТЕЛЕЙ ПАНЕЛИ КАК ОДНОГО

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

CH09-F36— ИЗМЕНЕНИЕ ВЕРСИИ ПАКЕТА РЕАЛЬНОСТИ

Одинаковые ответы сравниваются с разными эталонными записями.

CH09-F37— ТИХОЕ ИЗМЕНЕНИЕ ОТПЕЧАТКА ПРОДУКТА

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

CH09-F38— ПРИСВОЕНИЕ НЕИЗВЕСТНОЙ ОБЛАСТИ СТАТУСА ЧИСТЫЙ

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

CH09-F39— ИСПОЛЬЗОВАНИЕ БРЕНДА ПРОДУКТА ВМЕСТО ДОКАЗАТЕЛЬСТВ

Репутация поставщика заменяет условия измерения.

CH09-F40— ПОКРЫТИЕ ВСЕХ РАЗЛИЧИЙ ПРОДУКТА ОДНИМ КОЭФФИЦИЕНТОМ

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

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

Шаг 1— Определите поставщика и продукт

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

Шаг 2— Заблокируйте измерительную интерфейс

Веб Мобильный Десктоп

API

Встроенный продукт отсоединён.

Шаг 3— Проверьте план и класс аккаунта

Записывается статус плана: бесплатный, платный, корпоративный или другой.

Шаг 4— Назначьте доверие идентификатору модели

Определяется соответствующий уровень между MI-0 и MI-5.

Шаг 5— Сохраните извлечение и веб-конфигурацию

Функция доступна? Включена ли она? Использовалась ли она в конкретном ответе? Какие есть доказательства?

Шаг 6— Сохранить статус ссылки и инструмента

Фактическое использование отделено от доступа к функции.

Шаг 7— Сохранить статус сессии и персонализации

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

Шаг 8— Проверить регистрацию страны, региона и языка

Определено региональное условие поведения продукта.

Шаг 9— Проверка экспериментальных функций

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

Шаг 10— Зафиксировать время и идентичность волны

Создаются запись времени UTC и запись волны.

Шаг 11— Создать отпечаток конфигурации системы

Сохранённые поля связаны с записью целостности.

Шаг 12— Мониторинг событий изменений

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

Шаг 13— Запишите объект сравнения

Какое из сравнений интерфейса плана извлечения модели продукта производится?

Шаг 14— Сопоставьте измерения сравнения

Области материалов заносятся в таблицу.

Шаг 15— Назначьте уровень CP

Соответствующий уровень задается между CP-0 и CP-5.

Шаг 16— Разделите сравнимые и несравнимые требования

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

Шаг 17— Разделите результаты Естественный охват и Общая опора сравнения

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

Шаг 18— Проверка изменения системы в волне

Определяется, требуется ли MIXED_SYSTEM_STATE или новая подволна.

Шаг 19— Создать публичную карточку сравнения

Условия, лежащие в основе ранжирования, становятся видимыми.

Шаг 20— Получить одобрение владельца записи

Реестр системы и решение о сравнении версионируются ответственным лицом.

51. ТРЕБУЕМАЯ ДОКАЗАТЕЛЬСТВО

Идентичность поставщика; название и тип продукта; пользовательский интерфейс; версия приложения или интерфейса; план и класс аккаунта; отображаемая модельная метка; доказательства идентичности модели; уровень уверенности в идентичности модели; документация продукта; записи доступа по странам; язык и локаль; веб- и возможности извлечения; доказательства использования извлечения; возможность цитирования; просмотр цитирования; связь цитирования и утверждения; доступ к инструменту; журнал использования инструмента; настройка памяти; пользовательские инструкции; состояние предыдущего чата; тип сессии; настройки администратора организации; запись экспериментальной функции; сигналы распределения A/B; UTC временная метка; волна измерений; отпечаток конфигурации системы; записи обновлений поставщика; наблюдаемые изменения поведения; ошибки доступа к продукту; журналы технических повторных попыток; запись популяции Естественный охват; запись популяции Общая опора сравнения; и таблица сравнения измерений.

Уровень CP Версия промпта Версия пакета Reality Запись образца и веса Версия рассмотрения Карточка публичного сравнения Журнал изменений Ответственное лицо или организация

52. ЧЕК-ЛИСТ АУДИТА

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

Создан ли отпечаток системы? Изменялся ли продукт во время измерительной волны? Были ли нарушения поведения за пределами объявления поставщика? Были ли наблюдения до и после изменений разделены? Были ли технические ошибки отделены от отклонений? Выполнялась ли повторная попытка из-за неправильного ответа? Является ли объект сравнения понятным? Какие условия совпадают, кроме одинакового запроса? Является ли целевая популяция одинаковой? Совпадают ли версии запроса и Truth Pack? Видны ли различия в плане, интерфейсы и извлечении? Был ли предоставлен уровень CP? Проводилась ли ранжировка по результатам CP-0 или CP-1? Были ли результаты Естественный охват и Общая опора сравнения разделены? Была ли последовательность продуктов одного и того же пользователя сбалансирована? Были ли откалиброваны разные панели пользователей?

Был ли результат живого продукта представлен как фундаментальное преимущество модели? Были ли неизвестные области признаны контролируемыми? Доступна ли публичная карточка сравнения? Известен ли ответственный владелец системного реестра?

53. ВОЗРАЖЕНИЯ И ОТВЕТЫ

Возражение 1— «Если пользователь не знает, какая модель работает, можно ли всё равно выполнить эту работу?»

Это возможно. Основной объект GEO-1000— это продукт пользователя. Если модель неизвестна, результат сообщается следующим образом: «Это поведение было наблюдено на этом продукте и пользовательский интерфейс». Конкретная модель не упоминается.

Возражение 2— «Почему мы так сильно различаем продукты одного и того же поставщика?»

Потому что пользователь:

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

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

Возражение 3— «Разве сравнивать разных поставщиков не всё равно что сравнивать яблоки с апельсинами?»

Если вопрос сравнения поставлен правильно, это не так. Настоящий пользователь мог бы спросить: «Какой продукт даёт мне более правильную информацию?» Весь продуктовый цикл является частью этого вопроса. Если нужно утверждать превосходство базовой модели, необходим более контролируемый эксперимент.

Возражение 4— «Разве не естественно, что продукт, использующий веб, имеет преимущество?»

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

Возражение 5— «Разве это не несправедливо — не присваивать балл цитирования продукту, который не показывает цитаты?»

Функция атрибуции — это функция, которую продукт предоставляет пользователю. Если функция отсутствует, результат атрибуции может быть отображен следующим образом:

ЗАПИСАН КАК НЕДОСТУПНЫЙ

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

Возражение 6— «Если память является частью естественного пользовательского опыта, почему мы её отключаем?»

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

Возражение 7— «Разве достаточно открыть новый чат для чистой сессии?»

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

Возражение 8— «Что мы можем сделать, если поставщик не объяснил изменение продукта?»

Наблюдалось:

• интерфейс,
• функция,
• поведение,
• Приписывание

Мы можем сохранить ваши изменения. Если причина неизвестна, используется неопределенный статус изменения, такой как UC-5.

Возражение 9— «Если продукты постоянно меняются, разве какие-либо результаты будут действительными?»

Указанный результат:

• дата,
• волне,
• Образец продукта

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

Возражение 10— «Разве один и тот же запрос в тот же день недостаточно сопоставим?»

План, интерфейс, память, веб, страна и численность пользователей могут различаться. Может требоваться один и тот же запрос. Сам по себе этого недостаточно.

Возражение 11— «Разве уровень CP не будет слишком техническим для публики?»

Можно использовать короткую метку:

• Дескриптивный
• Частично совпадающий
• Совпадает
• Контролируемый
• Реплицированный

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

Возражение 12— «Почему мы не можем напрямую ранжировать на основе оценок Естественный охват?»

Потому что каждый продукт мог быть измерен в разных странах и среди разных пользовательских групп. Разница в оценках может частично возникать из-за того, до какой аудитории дошёл продукт. Общая опора сравнения обеспечивает более справедливое сравнение.

Возражение 13— «Разве Общая опора сравнения не является результатом в реальном мире?»

Это результат фактической общей аудитории. Однако он не показывает доступность продуктов за пределами общей вселенной. Его следует рассматривать вместе с Естественный охват.

Возражение 14— «Что важнее: проверка живого продукта или проверка замороженной модели?»

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

ОБЩЕЕ ПРАВИЛО ГЛАВЫ 57

Пользователь:

• «ChatGPT так сказал.»
• «Gemini так думал.»
• «Claude рекомендовал нам.»
• «Некоторые ссылались на нас.»

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

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

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

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

Результат может быть сформирован средствами безопасности, персонализацией, интерфейсом и доступными инструментами. NOMOS поэтому спрашивает больше, чем «Какая модель?». Он спрашивает: Какой продукт? / Какая платформа? / Какой план? / Какой режим информации? / Какая сессия? / Какой пользователь? / Какая страна? / Какое время? / Какая версия? Два результата могут быть получены на один и тот же запрос, не относясь к одному и тому же эксперименту. Два результата могут быть от разных поставщиков и при этом оставаться довольно сопоставимыми в одинаковых условиях пользователя. Продукт — это живая система: его источники, интерфейс и модель могут изменяться. Изменение не делает результат бессмысленным; оно привязывает результат к определённому времени и состоянию продукта. Следовательно, девятый закон измерений NOMOS таков:

Поставщик ИИ — это не продукт ИИ.

Десятый закон таков:

Модель является лишь одной частью цепочки представления, которая доходит до пользователя.

Одиннадцатый закон звучит следующим образом:

Одинаковое имя гарантирует сопоставимость; разное имя не гарантирует несопоставимость.

Двенадцатый закон звучит следующим образом:

Один и тот же запрос — это не один и тот же эксперимент.

Тринадцатый закон выглядит следующим образом:

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

Четырнадцатый закон выглядит следующим образом:

Сила сравнения исходит не от величины рейтинга, а от ясности сопоставленных условий.

Порядок раздела 9 из NOMOS

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

Не делайте вид, что ярлык модели, который вы видите на экране, является точной идентичностью всей бэкэнд-системы.

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

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

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

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

Не избегайте сравнения разных поставщиков только потому, что они разные. / Сначала сопоставьте условия. / Затем объясните, на какой вопрос вы ответили.

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

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

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

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

Сначала зарегистрируйте систему в записи. / Затем заблокируйте конфигурацию. / Затем отслеживайте изменения. / Затем запишите объект сравнения. / Затем покажите совпадающие и несовпадающие условия. / И только тогда скажите, какой продукт дал более сильный результат при каком условии.

Заключительное предложение главы

«ИИ», измеряемый в GEO-1000, не является одним именем или моделью; это версияная система представления, достигающая конкретного пользователя в конкретный момент в рамках конкретной цепочки продукта.

Нормативное ядро

Каждое наблюдение GEO-1000 ДОЛЖНО быть связано с записью в версионируемом Реестре систем ИИ, описывающей измеряемый экземпляр продукта, включая, при необходимости: - поставщика, - продукт, - пользовательский интерфейс, - план, - отображаемую или подтвержденную идентичность модели, - уверенность в идентичности модели, - конфигурацию извлечения и веб-конфигурацию, - возможность цитирования и использования, - доступ к инструментам и их использование, - состояние сессии, - память, - пользовательские инструкции, - предыдущий контекст, - персонализацию, - страну, - локаль, - язык, - состояние развертывания, - время измерения, - и известные или наблюдаемые изменения системы. Название поставщика, название продукта, отображаемая маркировка модели, базовая модель, система поиска и продукт, с которым взаимодействует пользователь, НЕ ДОЛЖНЫ рассматриваться как взаимозаменяемые идентичности. Доступность функции ДОЛЖНА оставаться отдельной от использования функции. Результаты работающего продукта НЕ ДОЛЖНЫ представляться как результаты замороженной модели, а результаты замороженной модели НЕ ДОЛЖНЫ представляться как полный опыт использования потребительского продукта. Сравнения ДОЛЖНЫ определять свой объект и получать раскрытый уровень сопоставимости на основе соответствующей сущности, промпта, популяции, языка, страны, времени, сессии, плана, интерфейса, поиска, инструментов, справочных записей и правил рассмотрения. Одно и то же название поставщика или отображаемая модель НЕ ДОЛЖНЫ создавать автоматическое предположение о сопоставимости. Различные поставщики МОГУТ сравниваться, когда условия, с которыми сталкивается пользователь, достаточно согласованы, и полученное утверждение ограничено измеренным поведением продукта. Существенные изменения продукта во время волны измерений ДОЛЖНЫ создавать отдельное состояние системы, подволну, смоделированный коэффициент изменения или предупреждение о смешанном состоянии. Неизвестные поля конфигурации ДОЛЖНЫ оставаться НЕИЗВЕСТНЫМИ и НЕ ДОЛЖНЫ быть оценены как контролируемые или эквивалентные. Каждое решение реестра системы и сопоставимости ДОЛЖНО иметь версию и быть приписано ответственному человеку или организации.