Registro de sistemas de IA y comparabilidad

Límite de Capítulo

Los primeros ocho capítulos establecieron lo siguiente: una sola respuesta no es una puntuación GEO; la representación es una distribución; la entidad auditada debe ser identificada antes de observar los resultados; la representación oficial y la realidad de la entidad verificada deben permanecer separadas; para cada producto de IA debe definirse una población de usuarios elegible; las observaciones válidas 1,000 deben asignarse mediante un diseño de muestreo basado en la población; los países y idiomas más pequeños deben mantenerse visibles mediante paneles complementarios; y la selección de participantes, la exclusión y el ponderado deben permanecer independientes del contenido de la respuesta. Ahora debemos definir el otro lado del experimento:

¿Qué sistema de IA están midiendo realmente los participantes?

¿El nombre de un proveedor? ¿Un modelo base? ¿Un producto de chat? ¿Una interfaz web gratuita? ¿Una aplicación móvil de pago? ¿Una sesión con búsqueda web habilitada? ¿Un modo de respuesta que no cita fuentes? ¿Un espacio de trabajo empresarial respaldado por datos internos? ¿Una cuenta con memoria habilitada? ¿Chat temporal o limpio? ¿Son las diferentes interfaces de usuario de un mismo proveedor el mismo sistema? ¿Deben medirse de la misma manera dos productos que usan la misma familia de modelos? Incluso si un producto muestra el mismo nombre de modelo en la pantalla:

• recuperación,
• selección de fuente,
• reglas de seguridad,
• personalización,
• acceso a herramientas,
• funciones experimentales

Si cambia, ¿pueden compararse los resultados? Cuando un producto de IA se actualiza en medio de una ola de medición, ¿pueden considerarse que la primera y la última respuesta de la ola provienen del mismo sistema? Un usuario:

• búsqueda web activada,
• memoria activada,
• tiene conversaciones previas,
• plan de pago

respuestas; la de otro usuario:

• la búsqueda está desactivada,
• la memoria está desactivada,
• nueva sesión,
• plan gratuito

¿Se puede fusionar en la misma celda que su respuesta? No. El principio de medición establecido por las secciones anteriores es claro: No existe un único “AI”; el índice de búsqueda, el sistema de recuperación, el reordenador, el modelo de lenguaje, la capa de citación y el sistema de seguridad pueden comportarse de manera diferente. El mismo marco requiere que cada resultado auditable contenga:

• modelo o producto,
• fecha,
• país,
• idioma,
• conjunto de consultas,
• número de repeticiones,
• registro de medición

Esta sección opera estos principios dentro de un Registro del Sistema de IA. Esta sección:

• la distinción entre proveedor, producto, modelo y interfaz de usuario
• instancia de producto de IA,
• niveles de confianza de identidad del modelo,
• recuperación y configuraciones de herramientas,
• estados de memoria y personalización,
• diferencias en el plan, la interfaz y las funciones experimentales,
• cambios de producto,
• configuración del sistema en el momento de la medición,
• niveles de comparabilidad entre productos,
• comparaciones Alcance natural y Base común de comparación,
• desviación de la versión a lo largo del tiempo,

define. Este capítulo aún no:

• sistema de traducción completa y equivalencia semántica de los prompts,
• todos los detalles de los paneles de usuarios controlados y naturales,
• arquitectura del software de captura NOMOS,
• la puntuación de afirmación atómica de las respuestas,
• los coeficientes finales del modelo y la fórmula de puntuación NOMOS

no se finaliza. La pregunta clave de la Sección 9 es:

Antes de comparar dos respuestas de la misma pregunta, ¿cómo demostramos que estas respuestas realmente provienen de condiciones de producto de IA comparables?

NOMOS Desafío

Dos usuarios del mismo proveedor hacen la misma pregunta: “¿Qué tipo de empresa es Apple.com?” Primer usuario:

• está usando el producto web gratuito,
• abre un nuevo chat,
• tiene la memoria desactivada,
• no tiene acceso a la web,

recibe una respuesta solo con la capacidad de conocimiento incorporada del producto. Segundo usuario:

• Usando un producto móvil de pago,
• memoria activada,
• ha hablado previamente sobre Apple,
• búsqueda web activada,

recibe respuestas con fuentes actuales y citas. Primera respuesta: “Apple es una empresa de tecnología que produce productos electrónicos de consumo.” Segunda respuesta: “Apple es una empresa tecnológica global que ofrece hardware, software y servicios digitales. Puedes ver información corporativa actual en estas fuentes.” Ambas respuestas provienen del mismo proveedor.

¿Es este el resultado del mismo sistema? No. Ahora considere a otros dos usuarios. Ambos ven el mismo nombre de modelo en la pantalla. En el país de un usuario, la función web está activada. En el país del otro usuario, está desactivada. En la respuesta de un usuario, los enlaces de origen son visibles. La interfaz del otro usuario no muestra citas incluso si utiliza las mismas fuentes. Existe la misma etiqueta de modelo.

¿Existe la misma celda de medición? No. Ahora considere dos productos de diferentes proveedores. Ambos:

• nuevo chat,
• la memoria está desactivada,
• misma lengua,
• mismo país,
• mismo intervalo de tiempo,
• acceso web habilitado,
• misma versión de prompt

se miden bajo estas condiciones. Están basados en diferentes modelos subyacentes. ¿Son comparables? Sí, pueden ser comparables en términos de un resultado específico del usuario. Porque el objeto de comparación es:

no si utilizan el mismo modelo subyacente, sino qué representación producen bajo la misma condición definida para el usuario.

Ahora, deje que la versión del producto permanezca sin cambios para las primeras 500 observaciones de la oleada de medición. Durante las siguientes 500 observaciones, el proveedor:

• cambiar el sistema de recuperación,
• reglas de seguridad,
• interfaz de usuario

El informe por sí solo dice: “1,000 usuarios probaron el mismo producto de IA.” En realidad, se pueden haber medido dos situaciones de producto diferentes. La primera disposición de esta sección es la siguiente:

El nombre del proveedor no es suficiente para identificar el sistema de IA medido.

Su segunda disposición establece:

El nombre del modelo no constituye la totalidad del comportamiento del producto que llega al usuario.

Su tercera disposición establece:

El mismo proveedor, la misma etiqueta de modelo o el mismo logotipo no garantizan comparabilidad.

Su cuarta disposición establece:

Diferentes proveedores pueden ser comparables en términos de resultados para el usuario si las condiciones de medición están suficientemente igualadas.

Su quinta disposición establece:

Si un producto cambia materialmente durante la medición, no se puede informar como un solo sistema fijo.

1. OBJETIVO DEL CAPÍTULO

El propósito de esta sección es definir el producto de IA auditado dentro de GEO-1000 con todas sus configuraciones materiales y determinar bajo qué condiciones se pueden comparar diferentes resultados del producto. La sección estandariza las siguientes distinciones:

• Proveedor y producto de IA
• Producto de IA y modelo base
• Familia de modelos y despliegue específico
• Etiqueta del modelo e identidad de modelo verificada
• interfaz de usuario y API
• Producto web y móvil
• Plan gratuito y plan de pago
• Producto de consumo y producto empresarial
• Respuesta básica del modelo y respuesta aumentada por recuperación
• Búsqueda web en vivo con recuperación
• Visualización de citas con uso de fuentes
• Uso de herramientas con acceso a herramientas
• Contexto de sesión con memoria
• Política del sistema con instrucción personalizada
• Realidad material con personalización
• Chat temporal con nueva conversación
• Estado del producto a lo largo del tiempo con nombre de producto estático
• Cambio de comportamiento observado con actualización anunciada por el proveedor
• Comparación de Alcance natural y Base común de comparación
• Ejemplo de producto comparable dentro de la misma familia de productos
• Resultado del usuario frente a habilidad abstracta en el modelo
• Ausencia de producto frente a fallo del producto
• Error técnico frente a rechazo real
• Mismo prompt frente al mismo experimento
• Mismo promedio frente al mismo comportamiento del sistema
• Instantánea del producto frente al rendimiento a largo plazo del producto

Al final de esta sección, cada auditor GEO-1000 debería poder responder a las siguientes preguntas:

¿Qué proveedor, qué producto, qué interfaz, qué plan y qué configuración fueron medidos?

¿Cuánto se validó realmente el nombre del modelo que se veía en la pantalla?

¿Cuál era el estado de web, recuperación, citación, memoria, personalización y herramientas?

¿Se mantuvo el producto igual a lo largo de la medición?

¿A qué nivel de comparabilidad se colocaron lado a lado los resultados de los dos productos?

¿Se está comparando el modelo base, el producto de consumo, el interfaz de usuario o toda la cadena del sistema?

2. DISPOSICIÓN NORMATIVA CENTRAL

Cada observación GEO-1000 debe estar vinculada no solo con el proveedor o nombre del modelo; debe estar conectada a un registro versionado del Registro del Sistema de IA que identifique la instancia del producto de IA en el momento de la medición.

Una instancia de producto de IA debe llevar al menos los siguientes campos en la medida en que sean relevantes:

• Proveedor
• Nombre del producto
• interfaz de usuario
• Tipo de producto
• Clase de plan o cuenta
• Etiqueta de modelo aparente
• Nivel de confianza del ID del modelo
• Versión del producto o despliegue
• País y localidad
• Idioma
• Acceso web o de recuperación
• Función de citación
• Acceso a herramientas
• Estado de la memoria
• Estado de instrucciones personalizadas
• Contexto de chats anteriores
• Tipo de sesión
• Estado de personalización
• Modo de seguridad o política, si se conoce
• Funciones experimentales
• Fecha de medición y hora UTC
• Ola de medición
• Registro de cambios del producto
• Confianza en evidencia y registros

Cuando cualquiera de estos campos cambie materialmente:

• nueva instancia de producto AI,
• nueva celda experimental,
• nueva versión de análisis

puede ser requerida.

3. “SISTEMA AI” NO ES UN ÚNICO OBJETO [K02; K03]

En este protocolo, “sistema de IA” es un término general y de alto nivel. Una respuesta real del usuario puede surgir de la combinación de múltiples capas. Cadena candidata:

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

Aquí:

• M: modelo base o guía
• O: capa de orquestación del producto
• K: capa de recuperación o fuente de conocimiento
• Q: reordenamiento y selección de fuentes
• T: herramientas
• P: capa de políticas y seguridad
• S: sesión, memoria y personalización
• U: cuenta de usuario y plan
• C: país y ubicación
• L: idioma
• t: tiempo

Respuesta vista por el usuario:

R

La respuesta visible para un usuario no es necesariamente la salida del modelo base por sí sola. Por lo tanto, el objeto principal orientado al consumidor medido por GEO-1000 es:

el comportamiento del producto presentado al usuario, no una abstracción del modelo.

También se puede realizar investigación controlada con API o modelos. No es el mismo resultado que el panel principal de consumidores.

4. SIETE CAPAS DE IDENTIDAD DEL SISTEMA DE IA

Cada sistema de IA auditado debe definirse a través de siete capas, en la medida en que cada capa sea relevante.

4.1. Capa de Proveedor

La organización que publica u opera el producto. Nombre del proveedor:

• no es lo mismo que ID del producto,
• ID del modelo,
• interfaz de usuario

Un proveedor puede ofrecer más de un producto. Dentro del mismo producto, se puede usar más de un modelo o sistema de orquestación.

4.2. Capa de Producto

El producto comercial, de consumo, empresarial o técnico al que accede el usuario. Tipos de ejemplo:

• Producto de chat general
• Producto de respuesta asistida por búsqueda
• Espacio de trabajo empresarial
• Producto educativo
• Asistente integrado
• API para desarrolladores
• Producto personalizado basado en conocimiento

El nombre del producto por sí solo no describe toda la configuración.

4.3. Capa interfaz de usuario

Es la interfaz a través de la cual el usuario interactúa con el producto. Web Móvil Escritorio Extensión de navegador Integración con sistema operativo Interfaz integrada en la plataforma

API

Portal empresarial Diferentes interfaces del mismo producto:

• diferentes funciones,
• diferente modelo,
• diferente representación de fuente,
• memoria diferente

puede ser usada.

4.4. Capa de Modelo o Motor de Inferencia

Es el modelo, familia de modelos o sistema de enrutamiento usado en la generación de respuestas. ID del modelo:

• abierto,
• parcialmente visible,
• desconocido,
• dinámico

Es posible. Un producto puede dirigir una consulta de usuario a diferentes modelos. En este caso, no se puede decir: 'Se midió un único modelo fijo.'

4.5. Capa de Orquestación e Información

Puede incluir lo siguiente:

• Recuperación
• Búsqueda web en vivo
• Búsqueda interna
• Clasificación de fuentes
• Reclasificación
• Selección de citas
• Llamar a un vehículo
• Reescritura de consultas
• Triturado de documentos
• Fusión de respuestas

Esta capa es de importancia fundamental para la representación de GEO. Porque puede afectar qué registro:

• es accedido,
• es seleccionado,
• es incluido en la respuesta,
• se muestra como referencia

puede ser influenciado.

4.6. Capa de Política y Personalización

Puede incluir lo siguiente:

• Reglas de seguridad
• Instrucciones del sistema
• Política de producto
• Memoria
• Instrucciones especiales
• Historial del usuario
• Reglas regionales
• Edad o clase de cuenta
• Configuraciones del administrador corporativo

Esta capa afecta el:

• alcance de la respuesta,
• su tono,
• su rechazo,
• su recomendación

puede cambiar.

4.7. Capa de Distribución y Tiempo

Indica cuál de los siguientes estados tiene el producto en un momento específico:

• es significativo con
• característica experimental,
• distribución regional,
• distribución por segmento de usuarios,
• prueba A/B

El mismo nombre de producto puede tener diferentes condiciones de distribución para distintos usuarios en un mismo día.

5. EJEMPLO DE PRODUCTO DE IA

La unidad del sistema central dentro de GEO-1000:

Instancia de Producto de IA

Término operativo canónico:

Instancia de Producto de IA

Una Instancia de Producto de IA se define como:

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

puede representarse como. Aquí:

• v: proveedor
• p: producto
• s: interfaz de usuario
• r: plan o clase de cuenta
• m: ID o etiqueta del modelo
• k: recuperación y estructuración de información
• t: configuración de herramientas
• x: memoria, personalización y estado de sesión
• u: clase de configuración del usuario u organización
• c: país y región
• l: idioma
• ω: tiempo, implementación y estado de características experimentales

Una observación: Oj debe estar vinculado a un específico: muestra de producto Ai.

6. DIFERENCIA ENTRE MUESTRA DE PRODUCTO Y NOMBRE DE PRODUCTO

El nombre del producto puede ser fijo. La muestra de producto puede variar. Ejemplo: Deja que el nombre del producto Orion AI permanezca sin cambios. Sin embargo, estas dos mediciones son muestras de producto diferentes:

Muestra de Producto 1

Plan Web Gratis Memoria desactivada Acceso web desactivado Nuevo chat Turco Turquía Onda 1

Muestra de Producto 2

Plan de pago móvil Memoria en acceso web en contexto de chat anterior disponible Turco Turquía Wave 1 Estos pueden existir bajo la misma marca. No son la misma celda experimental.

7. NIVELES DE CONFIANZA DE IDENTIDAD DEL MODELO

El nombre del modelo no siempre se puede conocer con la misma certeza. Por lo tanto, la identidad del modelo puede registrarse en los siguientes niveles.

MI-0— MODELO DESCONOCIDO

Se desconoce qué modelo o familia de modelos utiliza el producto. El resultado se atribuye únicamente al interfaz del producto.

MI-1— ETIQUETA MOSTRADA AL USUARIO

Una etiqueta del modelo es visible en la interfaz de usuario. La etiqueta se registra. No se asume que verifique completamente la implementación del back-end.

MI-2— FAMILIA DE MODELO DOCUMENTADA POR EL PROVEEDOR

Los documentos del producto del proveedor describen una familia de modelos específica o la relación producto–modelo. Aún puede desconocerse si la observación individual se dirige exactamente a ese modelo.

MI-3— DESPLIEGUE CONFIRMADO POR SESIÓN

La sesión verifica una distribución específica de API o metadatos de producto confiables.

MI-4— PUNTO FINAL O DESPLIEGUE VERSIONADO

Se puede registrar un ID de versión específica, punto final o despliegue. Es más sólido para comparaciones controladas.

MI-5— ARTEFACTO DE MODELO CONGELADO REPRODUCIBLE

Existe una estructura de modelo o despliegue estática y reproducible. Puede ser rara en productos de consumo activos. Si la confianza en el ID del modelo es baja, el resultado:

debería atribuirse al comportamiento del producto

No se puede atribuir definitivamente a un modelo específico.

8. LÍMITE DEL NOMBRE DE MODELO APARENTE

Ver el nombre del modelo en una interfaz de usuario es valioso. Sin embargo, las siguientes preguntas pueden seguir sin resolverse: ¿Todas las consultas se dirigen al mismo modelo? ¿Cambia el modelo según la dificultad de la consulta? ¿Utilizan seguridad o recuperación un modelo separado? ¿El proveedor aplica la misma etiqueta a diferentes distribuciones? ¿La etiqueta del modelo solo indica la familia del producto? ¿Forma parte el usuario de un despliegue experimental? Por lo tanto, el informe correcto podría ser: “Se mostró la etiqueta del Modelo X en la interfaz de usuario.” Sin evidencia más sólida, no debe usarse la siguiente oración: “Todas las respuestas son generadas definitivamente únicamente por el Modelo X.”

9. TIPO DE PRODUCTO

Cada producto de IA debe clasificarse con un tipo primario y tipos secundarios.

PT-1— Producto de Conversación General

Es un producto general de chat y preguntas y respuestas.

PT-2— Producto Basado en Búsqueda o Recuperación

La búsqueda o recuperación es un componente fundamental en la generación de respuestas.

PT-3— Producto de Conocimiento Empresarial

Puede utilizar documentos internos, espacios de trabajo o fuentes de datos especiales.

PT-4— Asistente Integrado

Está integrado en otro producto o plataforma.

PT-5— Producto para Desarrolladores o API

Es utilizado por un desarrollador o aplicación en lugar del usuario final.

PT-6— Producto Específico de Dominio

Está diseñado para una profesión o industria específica.

PT-7— Producto Multimodal

Las entradas distintas al texto, como entradas visuales, de audio o de documentos, forman parte de la experiencia principal. Un producto puede tener más de un tipo. La comparación debe realizarse dentro del mismo tipo o con un alcance explícito.

10. REGISTRO interfaz de usuario

Las diferentes interfaces del mismo producto deben registrarse por separado. Áreas de interfaz:

• ID de interfaz
• Web/móvil/escritorio/API
• Versión de la aplicación
• Sistema operativo, si corresponde
• Navegador, si corresponde
• Idioma del producto
• Selección de modelo visible
• Disponibilidad de herramientas
• Vista de citas
• Función de carga de archivos
• Configuraciones de memoria
• Configuraciones de gestión corporativa
• Funciones experimentales
• Tiempo de medición

Si se encuentra que una interfaz web y móvil son materialmente iguales, los resultados pueden combinarse. Esta igualdad no debe asumirse; debe probarse.

11. PLAN Y CLASE DE CUENTA

El tipo de plan puede tener características que pueden afectar la respuesta del usuario. Estados del plan:

• Gratis
• Individual de pago
• Profesional
• Corporativo
• Educación
• Desarrollador
• Prueba
• Invitación o acceso limitado
• Desconocido

Los planes pueden diferir en las siguientes áreas:

• Modelo
• Límite de uso
• Acceso web
• Memoria
• Herramientas
• Citación de fuentes
• Longitud de respuesta
• Velocidad o prioridad
• Datos empresariales
• Configuraciones de seguridad y retención

Si no hay información del plan:

El PLAN_DESCONOCIDO

los resultados gratuitos y de pago no pueden combinarse silenciosamente como el mismo comportamiento del producto.

12. RECUPERACIÓN Y ACCESO WEB

Se puede generar una respuesta de IA en uno de tres estados básicos de conocimiento.

KG-0— MODO DE CONOCIMIENTO INDETERMINADO

No se puede determinar el caso de recuperación o uso de la web.

KG-1— RESPUESTA INTERNA DEL MODELO

Una respuesta que se conoce o se asume fuertemente que no utiliza información en vivo o externa.

KG-2— RESPUESTA ASISTIDA POR RECUPERACIÓN

Puede haberse utilizado recuperación de fuentes preindexadas o de productos.

KG-3— RESPUESTA ASISTIDA POR LA WEB O BÚSQUEDA EN VIVO

Se ha utilizado acceso a la web/búsqueda en tiempo real o casi en tiempo real.

KG-4— RESPUESTA FUNDAMENTADA EN CONOCIMIENTO PRIVADO

Se ha utilizado una fuente de datos privada proporcionada por la institución o el usuario.

KG-5— RESPUESTA HÍBRIDA O DE MÚLTIPLES FUENTES

Se han utilizado varias capas de información juntas. Estos modos pueden producir resultados diferentes en el mismo prompt. Deben distinguirse claramente en la comparación.

13. EL ACCESO A RECUPERACIÓN NO ES LO MISMO QUE EL USO DE RECUPERACIÓN

El producto puede tener una función de búsqueda web. Sin embargo, puede que no se haya utilizado en la respuesta específica. Tres campos deben registrarse por separado: ¿Estaba disponible la función? ¿Estaba activada o seleccionable la función? ¿Había evidencia de que se utilizó en la respuesta específica? Ejemplo de estados:

DISPONIBLE_NO_USADO

USO_DISPONIBLE_DESCONOCIDO

USADO_CONFIRMADO

NO_DISPONIBLE

DESHABILITADO

DESCONOCIDO

La mera presencia de un enlace de fuente puede ser un fuerte indicador de uso. La ausencia de un enlace de fuente no prueba necesariamente que no se haya utilizado la recuperación.

14. CAPA DE CITAS

Usar una fuente no es lo mismo que mostrar una cita. Un producto:

• puede usar una fuente pero puede que no la muestre,
• puede mostrar una cita, pero la cita puede no respaldar la afirmación,
• puede vincular la misma fuente a diferentes oraciones,

El usuario puede ocultar la cita de acuerdo con el interfaz de usuario. El registro de la cita debe contener los siguientes campos: ¿Está disponible la función de cita? ¿Se mostró la cita en la respuesta específica? Número de citas Nombres de campos de origen Coincidencia cita–afirmación Visibilidad en el interfaz de usuario Expansibilidad de la cita Accesibilidad de la fuente Tiempo de generación de la cita Los productos que muestran y no muestran citas no se pueden comparar directamente en términos de "número de fuentes". Primero, se deben explicar las diferencias en el comportamiento del producto y en la interfaz.

15. ACCESO A HERRAMIENTA

El producto de IA puede acceder a las siguientes herramientas:

• Búsqueda en la web
• Navegador
• calculadora
• Ejecución de código
• Lectura de archivos
• Mapa
• Calendario
• Base de conocimientos corporativa
• Catálogo de productos
• Otras APIs

El acceso a herramientas puede afectar tu respuesta:

• su oportunidad,
• evidencia,
• alcance de la respuesta,
• precisión

Registro de herramientas:

• si la herramienta está disponible,
• si está activa,
• si fue utilizada en la respuesta,
• si se conserva el resultado de la herramienta

debe mostrarse.

16. MEMORIA, INSTRUCCIONES ESPECIALES Y PERSONALIZACIÓN

La respuesta visible para el usuario puede verse afectada por los siguientes campos:

• Memoria persistente
• Historial de chat
• Instrucciones especiales
• Nombre de usuario o perfil
• Conversaciones previas de la marca
• Preferencias
• País y localidad
• Configuraciones del espacio de trabajo corporativo
• Segmentación realizada por el proveedor

Estos campos deben registrarse en tres capas separadas.

16.1. Personalización persistente

Información protegida a través de cuentas o sesiones.

16.2. Contexto en la conversación

Mensajes previos dentro del chat actual.

16.3. Configuración del sistema u organización

Administrador o instrucciones del producto que el usuario puede no ver. La información completa puede no estar siempre disponible. Las situaciones desconocidas deben registrarse explícitamente.

17. TIPOS DE SESIÓN

Estados de la sesión del candidato:

ST-1— NUEVA CONVERSACIÓN ESTÁNDAR

Nueva conversación estándar. La memoria o las instrucciones especiales se registran por separado.

ST-2— CONVERSACIÓN TEMPORAL O EFÍMERA

Sesión temporal destinada a separarse del historial permanente. Las características reales deben verificarse en el registro del producto.

ST-3— CONVERSACIÓN EXISTENTE

Existe un contexto de conversación previo. Puede ser valioso para el panel natural. Se mantiene separado en el panel controlado.

ST-4— SESIÓN DE EMPRESA O DE ESPACIO DE TRABAJO COMPARTIDO

Puede haber un área de información empresarial o compartida.

ST-5— ESTADO DE SESIÓN DESCONOCIDO

No se pudo determinar de manera confiable el estado de la sesión. Si se van a combinar diferentes tipos de sesión en la misma celda, se debe explicar la justificación y el peso.

18. POLÍTICA DEL PRODUCTO Y RECHAZO

Un producto de IA puede no responder a una pregunta específica debido a:

• de seguridad,
• ley,
• política del producto,
• reglamento regional,
• no implica ninguna idoneidad en términos de edad,
• configuración empresarial

razón. Rechazo:

• deficiencia del modelo básico,
• política del producto,
• interfaz,
• puede deberse a la cuenta del usuario

GEO-1000 registra en los controles principales del usuario el resultado del rechazo que llega al usuario. Sin embargo, si se conoce la razón del rechazo, se clasifica adicionalmente. La capa de política de un producto también forma parte de la experiencia del usuario.

19. FUNCIONALIDADES EXPERIMENTALES Y DISTRIBUCIONES A/B

Los productos de IA en vivo pueden no ofrecer las mismas funciones a todos los usuarios al mismo tiempo. Los participantes:

• diferente interfaz de usuario,
• distintas formulaciones del prompt según el modelo,
• diferente función web,
• diferente formato de respuesta

puede ver. Indicadores de estado experimental:

• Etiqueta Beta en la interfaz
• Documentación del proveedor
• Diferencia de función
• Diferencia sistemática en la interfaz de usuario entre usuarios
• Comportamiento que rompe durante la medición

puede ocurrir. Si la función experimental es desconocida:

ESTADO_EXPERIMENTAL_DESCONOCIDO

La variación real dentro del producto no es un defecto de datos. Es una característica de distribución del sistema. Sin embargo, debería considerarse en la comparabilidad.

20. Registro del Sistema de IA

Se debe crear un Registro del Sistema de IA para cada producto auditado. El registro debe tener tres niveles.

20.1. Registro Maestro del Proveedor y Producto

Incluye áreas relativamente permanentes:

• Proveedor
• Nombre del producto
• Tipo de producto
• Interfaces principales de usuario
• Países con acceso oficial
• Clases de plan
• Registros de idiomas soportados
• Características generales

20.2. Registro de Producto de oleada de medición

Para una onda específica:

• versión del producto,
• características del plan,
• etiquetas del modelo,
• funciones web y de herramientas,
• comportamiento de la memoria,
• estado de acceso,
• actualizaciones conocidas

que se registra.

20.3. Registro del Sistema a Nivel de Observación

Realmente observado para cada participante:

• interfaz,
• etiqueta del modelo,
• plan,
• uso del vehículo,
• cita,
• sesión,
• personalización,
• tiempo

lleva campos. Solo el registro principal no puede eliminar diferencias a nivel de observación.

21. HUELLA DE CONFIGURACIÓN DEL SISTEMA

Se puede crear una huella digital de configuración del sistema para facilitar la comparabilidad de una instancia de producto de IA. Campos candidatos:

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

Aquí, H es la función que produce un valor de integridad a partir de los campos versionados. La huella digital:

• si dos observaciones pertenecen a la misma configuración,
• si ha habido cambios materiales en la ola

Puede ayudar a identificar. Huella digital: no demuestra el modelo de backend real, no hace visibles capas que el proveedor no haya divulgado. Solo refuerza si la configuración registrada ha sido modificada posteriormente.

22. ¿QUÉ ES LA COMPARABILIDAD?

Se consideran comparables dos resultados cuando:

La diferencia entre ellos puede explicarse suficientemente por el comportamiento monitoreado del producto en lugar de diferencias irrelevantes en el diseño de la medición.

La comparabilidad no es igualdad absoluta. Diferentes productos de IA:

• modelo,
• proveedor,
• interfaz de usuario.

Estos no tienen por qué ser todos idénticos. Sin embargo, las condiciones materiales relevantes para la comparación deben ser:

• igualación,
• estratificación,
• registro,
• modelado en el análisis

son requeridos.

23. EL OBJETO DE LA COMPARACIÓN DEBE DEFINIRSE DE ANTEMANO

Los mismos datos pueden responder a diferentes preguntas de comparación.

23.1. Comparación de Productos de Usuario

"¿Qué producto de consumo produce una representación más precisa bajo las mismas condiciones de usuario?" El objeto que se compara es toda la cadena de producto.

23.2. Comparación de Modelos

"¿Qué modelo produce una respuesta más precisa bajo la misma solicitud controlada y condición sin herramientas?" Puede ser necesario el acceso a API o a modelo fijo.

23.3. Comparación de Recuperación

“¿Hay alguna diferencia entre los modos accesible por web y no accesible del mismo producto?” Se mantiene el modelo y otras condiciones lo más constantes posible.

23.4. Comparación de Planes

“¿Ven los usuarios gratuitos y los de pago la misma representación de la marca?” La diferencia de plan es el objeto de la auditoría.

23.5. Comparación de Interfaz

“¿El producto web y móvil produce representaciones diferentes bajo las mismas condiciones?”

23.6. Comparación de Tiempo

“¿Cambió la representación del mismo producto en diferentes olas?” Se deben separar los cambios de producto y de población. Sin especificar la pregunta de comparación: “El Producto A es mejor que el Producto B.” es excesivamente amplio.

24. DIMENSIONES DE COMPARABILIDAD

Al comparar dos productos u olas, se deben evaluar las siguientes áreas:

• Entidad auditada
• Versión del paquete de realidad
• ID del prompt y versión
• Idioma y localización
• País
• Población objetivo
• Fuente de muestra
• Composición de participantes
• Tipo de sesión
• Memoria
• Instrucciones especiales
• Conversación previa
• Plan del producto
• interfaz de usuario
• Etiqueta del modelo
• Estado de recuperación/web
• Herramientas
• Función de citación
• Tiempo de medición
• Actualizaciones del producto
• Regla de adjudicación
• Estados del resultado
• Ponderación

No todas las dimensiones necesitan ser iguales. Diferentes dimensiones limitan el alcance de la comparación.

25. NIVELES DE COMPARABILIDAD

CP-0— INCOMPARABLE

Las condiciones de medición del material son desconocidas o gravemente inconsistentes. No se puede hacer una comparación directa del rendimiento.

CP-1— COOCURRENCIA DESCRIPTIVA

Hay resultados de dos productos o olas. Sin embargo:

• población,
• prompts,
• tiempo,
• sesión

no son iguales. Solo se puede hacer una visualización descriptiva lado a lado.

CP-2— PARCIALMENTE ALINEADO

Algunos campos principales coinciden. Las diferencias materiales continúan. Se puede hacer una comparación limitada.

CP-3— COMPARACIÓN COINCIDENTE ENTRE USUARIO Y INTERFAZ

Misma entidad, misma versión del prompt, mismo idioma/país, población de usuarios similar, misma ventana de tiempo. Las características del producto registrado están disponibles. Los resultados del producto de consumo son comparables.

CP-4— COMPARACIÓN COINCIDENTE CONTROLADA

Además:

• sesión,
• memoria,
• personalización,
• recuperación,
• tools,
• plan

están coincidentes de manera controlada o abierta. Proporciona una comparación más sólida de producto o característica.

CP-5— COMPARACIÓN REPLICADA Y CALIBRADA

Comparación:

• en múltiples olas,
• con usuarios o paneles independientes,
• con la misma evaluación normativa

repetido; la variabilidad y los cambios de producto han sido calibrados. Estos niveles no son un “puntuación de precisión científica”. Indican el límite que puede tener una afirmación de comparación.

26. ¿QUÉ HACER EN LA CONDICIÓN CP-0?

Si no se pueden comparar dos productos, los resultados no se ignoran. Pueden informarse por separado:

• “Este es el resultado Alcance natural del Producto A.”
• “Este es el resultado del Producto B bajo diferentes usuarios y condiciones del producto.”

Sin embargo: no se puede decir, “A es 12 puntos mejor que B.” La incomparabilidad no es un fallo, es una limitación del método.

27. COMPARABILIDAD PARA EL MISMO PROVEEDOR

Los resultados del mismo proveedor no se pueden comparar automáticamente. Pueden estar presentes las siguientes diferencias:

• Producto
• Plan
• Modelo
• Acceso web
• Interfaz
• Memoria
• Datos empresariales
• Distribución por país
• Característica experimental
• Hora

La comparación del mismo proveedor también debe evaluarse según el nivel de CP.

28. COMPARABILIDAD PARA DIFERENTES PROVEEDORES

Productos de usuario pertenecientes a diferentes proveedores:

• misma población objetivo,
• mismo prompt,
• mismo tiempo,
• similar interfaz de usuario,
• configuración de producto clara

Es comparable por debajo. Ser un proveedor diferente no impide la comparación. Sin embargo, las diferencias en las funcionalidades determinan qué mide la comparación. Ejemplo: El Producto A utiliza la web en vivo. El Producto B no. El resultado puede responder a esta pregunta: '¿Cuál de las dos cadenas de productos ofrecidas al usuario produce una representación más precisa?' No responde directamente a esta pregunta: '¿Qué modelo base tiene más conocimiento?'

29. COMPARACIÓN DE PRODUCTOS CON SOPORTE WEB Y SIN SOPORTE WEB

Son posibles dos comparaciones separadas.

29.1. Comparación de Productos Naturales

Cada producto se mide bajo la condición de usuario real por defecto. Un producto que utiliza la web utiliza la web. Uno que no la utiliza, no lo hace. Resultado: es una comparación de la experiencia real del consumidor con el producto.

29.2. Comparación de Funciones Equivalentes

Si es posible, ambos productos:

• medidos con la web abierta,
• web cerrada

modos por separado también. Esto puede separar mejor el efecto de recuperación. Cada producto puede no ofrecer las mismas opciones. Modo ausente:

REGISTRADO COMO NO DISPONIBLE

Ese estado debe permanecer explícito.

30. PRODUCTOS QUE MUESTRAN Y NO MUESTRAN CITAS

Para un producto sin función de citación: es posible dar una “Cita cero”. Sin embargo, su significado debe explicarse: el producto puede no estar haciendo referencia a fuentes. No es seguro que no use ninguna fuente. La cobertura de citas y la cobertura de precisión son resultados separados. La comparación de citas solo debe hacerse entre productos que soporten citas o con estado de función separado.

31. Alcance natural COMPARACIÓN

Cada producto se mide dentro de su población efectivamente alcanzada. Ventaja: muestra el impacto global natural del producto. Limitación: las poblaciones son diferentes, las distribuciones por país e idioma pueden variar. Puntuaciones de Alcance natural: muestran lo que hace el producto dentro de su población alcanzada. No deben usarse solas para un ranking directo de superioridad de productos.

32. COMPARACIÓN SOBRE UNA BASE COMÚN

Se utiliza la población de acceso común de los productos comparados. Ventaja:

• mismo país,
• misma lengua,
• misma condición de usuario

proporciona una comparación más justa. Limitación: preserva la diferencia real de acceso global de los productos, el universo común puede ser muy reducido. La puntuación Base común de comparación debe publicarse junto con la puntuación Alcance natural.

33. COMPARACIÓN DE USUARIOS PAREADOS

Si el mismo usuario prueba dos o más productos de IA, se pueden controlar las características del usuario. Sin embargo:

• orden de las tareas,
• memoria de respuestas,
• familiaridad con el producto,
• perfil especial de usuarios que pueden acceder a todos los productos

Puede crear sesgo. En un diseño pareado:

• el orden de los productos debe aleatorizarse,
• las respuestas previas no deben compartirse,

la dependencia del mismo usuario debe mantenerse en el análisis.

34. COMPARACIÓN DE USUARIOS INDEPENDIENTES

Cada producto es probado por diferentes usuarios, pero seleccionados del mismo marco poblacional. Ventaja: se reduce la contaminación de tareas, se pueden elegir usuarios de producto más naturales. Limitación: los grupos de usuarios pueden no ser completamente iguales. Se requiere ponderación y estratificación. Los resultados de usuarios emparejados e independientes pueden ser separados pero complementarios.

35. COMPARABILIDAD EN EL TIEMPO

Al comparar el resultado de hoy de un producto de IA con resultados pasados, se deben examinar los siguientes cambios:

• Modelo
• Versión del producto
• Web/recuperación
• Plan
• Acceso por país
• Soporte de idiomas
• Prompt
• Realidad de la entidad
• Adjudicación
• Marco poblacional
• Ponderación

La diferencia de tiempo puede no surgir únicamente del producto de IA.

36. TIPOS DE CAMBIOS EN EL PRODUCTO

UC-1— CAMBIO MENOR DOCUMENTADO

Un cambio menor divulgado por el proveedor y evaluado como que no altera materialmente el objeto de medición.

UC-2— CAMBIO MATERIAL DOCUMENTADO

Cambio material descrito en el modelo, recuperación, interfaz o característica.

UC-3— CAMBIO DE COMPORTAMIENTO OBSERVADO

Incluso si no hay un anuncio oficial, se observa un comportamiento sistemático o un cambio de interfaz.

UC-4— CAMBIO DE ACCESO O PLAN

Cambios en el país, plan o acceso del usuario.

UC-5— EVENTO DE CAMBIO DESCONOCIDO

Hay una interrupción en el comportamiento de la medición. No se pudo verificar la razón.

UC-6— REEMPLAZO O RETIRO DEL PRODUCTO

Un producto o modelo antiguo ha terminado y ha sido reemplazado por otra estructura. El tipo de cambio limita la comparación de series temporales.

37. CAMBIO DE PRODUCTO DENTRO DE LA OLA DE MEDICIÓN

Si ocurre un cambio de material durante una ola, existen las siguientes opciones: Se puede detener la ola y reiniciarla. Se pueden crear sub-olas separadas antes y después del cambio. El cambio se puede modelar como un factor experimental. La ola se etiqueta como MIXED_SYSTEM_STATE. Se prohíbe la siguiente estructura: Combinar todas las respuestas como si resultaran en un único resultado de producto fijo a pesar de conocer el cambio.

38. EL COMPORTAMIENTO PUEDE CAMBIAR SIN QUE HAYA CAMBIO DE PRODUCTO

Incluso si el proveedor no anuncia una actualización explícita, el resultado puede cambiar. Posibles razones:

• Cambio en el índice de recuperación
• Actualización de recursos
• Aparición de contenido nuevo en la web
• Cambio en la reordenación
• prueba A/B
• Implementación regional
• Política de seguridad
• Enrutamiento de tráfico

Por lo tanto, no se puede decir: “El proveedor no actualizó, el sistema era definitivamente el mismo.” También deben examinarse la evidencia de medición y el desglose del comportamiento.

39. PRODUCTO EN VIVO Y MODELO CONGELADO

Existen dos objetos de investigación diferentes.

39.1. Auditoría de Producto en Vivo

Mide lo que los usuarios reales ven en la interfaz real del consumidor. Ventaja:

• muestra la experiencia real,
• fuente real,
• política real,
• interfaz real

limitaciones: es variable, la reproducción completa puede ser difícil.

39.2. Auditoría de Modelo Congelado

Se realiza repetición controlada bajo una versión fija o punto final. La ventaja:

• proporciona reproducibilidad,
• control experimental

La limitación: puede que no represente completamente el producto de consumo real. La capa principal de población de NOMOS GEO-1000 se basa en el producto de usuario en vivo. La auditoría del modelo congelado es un trabajo complementario de laboratorio.

40. NO DISPONIBILIDAD DEL PRODUCTO Y RESULTADOS TÉCNICOS

Se deben mantener separados los siguientes casos:

AR-1— PRODUCTO NO DISPONIBLE

El producto no está disponible para el país o grupo de usuarios. Es el resultado del alcance de acceso.

AR-2— CUENTA O PLAN NO ELEGIBLE

La condición de plan o cuenta asignada al participante no es elegible. Puede haber un problema de muestreo o asignación de tareas.

AR-3— FALLA TÉCNICA TEMPORAL

Ha ocurrido un error técnico temporal. El protocolo de reintento debe estar predefinido.

AR-4— LÍMITE DE TARIFA O USO

Se ha alcanzado una cuota de uso o un límite de velocidad. Puede ser parte de la experiencia del usuario real.

AR-5— RECHAZO DEL SISTEMA

La tarea del producto ha sido rechazada debido a la política o contenido. Es un resultado válido del sistema.

AR-6— SIN RESULTADO ÚTIL

No se ha generado ninguna respuesta útil.

AR-7— FALLO DE ACCESO DESCONOCIDO

Por qué no se pudo determinar. Estas situaciones no se pueden combinar en el mismo cuadro de "sin respuesta".

41. REGLA DE REINTENTO TÉCNICO

Se puede hacer un reintento en caso de un error técnico temporal o interrupción de la conexión. Sin embargo:

• si la respuesta de la IA no gusta,
• ocurrió un rechazo,
• se produjo información incorrecta

no se puede realizar un reintento por estas razones. Reintento técnico:

• mismo usuario,
• mismo producto,
• misma configuración,
• debe realizarse dentro del período predeterminado.

También debe registrarse el primer incidente técnico.

42. MATRIZ DE COMPARACIÓN

Un registro de comparación básico para dos productos podría ser el siguiente:

Estos resultados se pueden mostrar lado a lado. Sin embargo: "El modelo básico del Producto B es mejor." no se puede decir. La diferencia puede provenir de toda la cadena del producto.

43. CASO DE COMPARACIÓN SINTÉTICO APPLE.COM

DEMOSTRACIÓN DE METODOLOGÍA SINTÉTICA / Los productos, respuestas y resultados a continuación son completamente ficticios. No representan el desempeño de la verdadera Apple Inc. ni de ningún proveedor real de IA. Consideremos tres ejemplos de productos sintéticos.

Ejemplo de Producto A

Proveedor: Orion Producto: Orion Chat Interfaz: Web Plan: Gratis Etiqueta del modelo: Orion Standard Confianza del modelo: MI-1 Acceso web: Desactivado Memoria: Desactivada Sesión: Nueva Idioma: Turco Localización: Turquía Onda: W1 Respuesta: "Apple es una empresa tecnológica estadounidense que produce teléfonos y computadoras."

Muestra de Producto B

Proveedor: Orion Producto: Orion Chat Interfaz: Móvil Plan: De pago Etiqueta del modelo: Orion Pro Confianza del modelo: MI-1 Acceso web: Abierto Citación: Abierta Memoria: Activada Conversación previa: Sobre Apple Idioma: Turco Configuración regional: Turquía Ola: W1 Respuesta: "Apple es una empresa tecnológica global que proporciona hardware, software y servicios digitales. La información corporativa actual se puede encontrar en estas fuentes."

Muestra de producto C

Proveedor: Helios Producto: Helios Búsqueda Interfaz: Web Plan: Gratis Etiqueta del Modelo: Desconocido Confianza del Modelo: MI-0 Acceso Web: Abierto Cita: Abierta Memoria: Ninguna Sesión: Nueva Idioma: Turco Configuración Regional: Turquía Ola: W1 Respuesta: "Apple es una empresa tecnológica con sede en EE. UU. que desarrolla dispositivos de consumo, sistemas operativos y servicios digitales."

43.1. Comparación de A y B

Son el mismo proveedor. Sin embargo:

• plan,
• interfaz,
• etiqueta del modelo,
• web,
• memoria,
• conversación previa

es diferente. El nivel de comparación puede ser CP-1 o CP-2. La diferencia de respuesta no puede atribuirse únicamente a la diferencia del modelo básico.

43.2. Comparación de A y C

Son proveedores diferentes. Sin embargo:

• nueva sesión,
• plan gratuito,
• interfaz web,
• mismo idioma/país,
• misma ola

en términos de algunas condiciones coinciden. El acceso web es diferente. Comparación: se puede hacer como un resultado natural de producto de consumo. No se puede hacer como capacidad del modelo básico.

43.3. Comparación de B y C

Ambos productos tienen acceso web y citas habilitadas. Sin embargo, B tiene memoria y conversación previa, mientras que C no. La experiencia del usuario de los productos es comparable. No es una comparación de producto controlada y limpia.

43.4. Repetición Controlada

En el producto B:

• la memoria está desactivada,
• se inicia un nuevo chat,
• las instrucciones especiales están desactivadas,

la web permanece activada. C se mide bajo la misma condición. Nivel de comparación: CP-3, o CP-4 con control adicional suficiente. Este ejemplo muestra:

El mismo proveedor no proporciona una comparación cercana; proveedores diferentes bien registrados pueden ser más comparables.

44. CASO DE CAMBIO DE PRODUCTO SINTÉTICO

EJEMPLO SINTÉTICO

Orion Chat W1 apunta con ondas a las observaciones 1,000. En las primeras observaciones 480:

• versión del producto: 6.1
• función de la web: manual
• atribución: limitada

En las siguientes observaciones 520:

• versión del producto: 6.2
• función de la web: automática
• atribución: extendida

dejarlo así. Resultado único: si se calcula como “puntuación Orion Chat W1,” se mezclan dos estados diferentes del sistema. Opciones correctas:

Opción 1

W1A: primer 480 W1B: siguiente 520 se informan por separado.

Opción 2

La ola no continúa. Se toman nuevas observaciones 1,000 en la versión 6.2.

Opción 3

La versión se mantiene como un factor experimental explícito en el análisis estadístico. Opción incorrecta: La actualización se elimina del informe y todas las observaciones se presentan como un solo producto fijo.

45. REGISTRO MÍNIMO DEL SISTEMA DE IA

Cada observación debe contener al menos los siguientes campos:

• ID del sistema de IA NOMOS
• Proveedor
• Producto
• Interfaz
• Plan
• Tipo de producto
• Etiqueta de modelo aparente
• Nivel de confianza del modelo
• País
• Localización
• Idioma
• Tipo de sesión
• Estado de la memoria
• Estado de instrucciones personalizadas
• Estado de la conversación previa
• Función de recuperación/web
• Estado de uso de la recuperación
• Estado de la citación
• Estado de la herramienta
• Estado de la función experimental
• UTC tiempo
• Onda
• Huella del sistema
• Cambios de eventos
• Fuente de evidencia
• Propietario del registro

Si el campo de material es desconocido, no se puede dejar en blanco. Se debe usar el estado DESCONOCIDO.

46. TARJETA DE COMPARACIÓN MÍNIMA

Al comparar dos productos o oleadas, el registro público debe mostrar:

• Pregunta de comparación
• Nivel de comparación
• Población objetivo común
• Diferencias Alcance natural
• Igualdad del usuario
• Idioma y país
• Tiempo de medición
• Producto, plan y interfaz
• Confianza en la identidad del modelo
• Diferencia web/recuperación
• Diferencia en memoria y personalización
• Diferencia en herramienta
• Diferencia en muestra
• Método de evaluación
• Limitaciones del material
• Métricas directamente comparables
• Áreas no comparables

No se debe publicar un solo número o clasificación sin esta tarjeta.

47. REGLA DE COMPARABILIDAD

Un auditor debe responder estas cuatro preguntas: ¿Se pidió lo mismo? ¿Se midió el mismo universo humano? ¿Se aplicaron las mismas condiciones del usuario? ¿Se usaron el mismo tiempo y sistema de evaluación? Cada una de estas preguntas:

• completamente,
• parcialmente,
• no,
• desconocido

se clasifica como. El nivel de comparación se da en consecuencia.

48. DISPOSICIONES NORMATIVAS OBLIGATORIAS

CH09-N01

Cada observación GEO-1000 debe estar vinculada a un registro con versión en el Registro del Sistema de IA.

CH09-N02

El nombre del proveedor no puede usarse como la identidad completa del producto de IA medido.

CH09-N03

El producto, interfaz de usuario, plan, modelo, recuperación, herramienta, sesión y capas de personalización deben estar separadas entre sí.

CH09-N04

La etiqueta del modelo en el interfaz de usuario no puede ser presentada como una identidad de modelo de back-end verificada.

CH09-N05

El nivel de confianza de la identidad del modelo debe registrarse desde MI-0 hasta MI-5 o mediante un estado equivalente definido de manera abierta.

CH09-N06

Si la identidad del modelo no puede ser verificada, el resultado solo debe atribuirse al producto y al interfaz de usuario.

CH09-N07

Los productos que pertenecen al mismo proveedor no se consideran automáticamente la misma célula experimental.

CH09-N08

Los productos pertenecientes a diferentes proveedores pueden ser comparables cuando se igualan el usuario del material y las condiciones experimentales.

CH09-N09

Las interfaces de productos y API web, móviles, de escritorio e integradas no se pueden combinar sin descripción.

CH09-N10

Los planes gratuitos, de pago, corporativos, educativos y para desarrolladores deben registrarse como términos de producto separados.

CH09-N11

Si el plan es desconocido, el resultado debe llevar el estado PLAN_DESCONOCIDO.

CH09-N12

La disponibilidad de la función de recuperación o web no puede contarse como prueba de que se usó en una respuesta específica.

CH09-N13

El acceso a la recuperación, el uso de la recuperación y la atribución deben registrarse con estados separados.

CH09-N14

Un producto que no muestre atribución no puede considerarse automáticamente como que no utiliza ningún recurso.

CH09-N15

Las citas del producto citado deben examinarse por separado en términos de soporte de la afirmación.

CH09-N16

El acceso a herramientas y el uso de herramientas en respuestas específicas deben registrarse por separado.

CH09-N17

La memoria, las instrucciones especiales, los chats anteriores y la configuración corporativa deben registrarse por separado tanto como sea posible.

CH09-N18

No se puede asumir que un estado de personalización desconocido sea como una sesión limpia.

CH09-N19

Las sesiones de nuevo chat, chat temporal, chat actual y espacio de trabajo corporativo no se pueden fusionar sin explicación.

CH09-N20

Los resultados de Panel de usuarios en condiciones reales y Panel controlado en condiciones depuradas deben tener un estado de producto separado.

CH09-N21

Si una característica experimental o una distribución A/B en el producto es material, debe conservarse en el registro de observación.

CH09-N22

Si ocurre un cambio material en el producto durante una ola, la ola debería dividirse en subversiones separadas, reiniciarse o el cambio debería modelarse explícitamente en el análisis.

CH09-N23

Un cambio de producto conocido no puede almacenarse como si todas las observaciones provinieran de un único sistema fijo.

CH09-N24

El hecho de que el proveedor no explique una actualización no puede tomarse como prueba definitiva de que el producto no ha cambiado.

CH09-N25

El resultado de un producto de consumo en vivo no puede presentarse como si fuera el resultado de un modelo base congelado.

CH09-N26

El resultado de un modelo congelado en el laboratorio no puede presentarse como el rendimiento de un producto real para el usuario.

CH09-N27

La ausencia del producto, error técnico, límite de uso, rechazo del sistema y falta de resultado deben registrarse con estados separados.

CH09-N28

Una respuesta incorrecta o negativa de la IA no puede ser una razón para reintento técnico.

CH09-N29

El sujeto de la comparación debe definirse antes de recopilar los datos.

CH09-N30

El nivel de comparabilidad de dos productos debe ser visible en el resultado público.

CH09-N31

No se puede generar un ranking definitivo de productos a partir de resultados de nivel CP-0 o CP-1.

CH09-N32

Usar solo el mismo prompt no crea un experimento comparable.

CH09-N33

En las comparaciones, la entidad objetivo, el Truth Pack, el prompt, el idioma, el país, el tiempo, la población, la sesión, el producto y el método de evaluación deben examinarse juntos.

CH09-N34

Los resultados Alcance natural no pueden clasificarse directamente sin explicación porque pertenecen a diferentes poblaciones objetivo.

CH09-N35

El resultado Base común de comparación no puede presentarse como el resultado real de alcance global del producto.

CH09-N36

La comparación de productos soportados por la web y sin web se puede hacer como una comparación de productos por usuario; no puede presentarse como una superioridad de modelo básico.

CH09-N37

En las comparaciones pareadas realizadas con el mismo usuario, se debe mantener el orden del producto y la dependencia del usuario.

CH09-N38

En comparaciones realizadas con diferentes usuarios, la composición de usuarios y las diferencias de peso deben ser visibles.

CH09-N39

La versión del producto o la huella de configuración debe almacenarse en cada ola de medición.

CH09-N40

Debe haber un propietario humano o institucional responsable del registro del sistema y de la decisión de comparabilidad.

49. FORMAS DE FALLA

CH09-F01— CONSIDERANDO AL PROVEEDOR COMO UNA SÓLO IA

Todos los productos, modelos y interfaces del proveedor se presentan como un único sistema.

CH09-F02— CONTAR EL COMPORTAMIENTO DEL PRODUCTO POR NOMBRE DE MODELO

Recuperación, seguridad, interfaz y personalización son ignoradas.

CH09-F03— DEFINITIVAMENTE CONSIDERAR LA ETIQUETA VISIBLE DEL MODELO COMO BACKEND

El uso de enrutamiento o modelos dinámicos se pasa por alto.

CH09-F04— CONSIDERANDO AL MISMO PROVEEDOR COMO COMPARABLE

Las diferencias de plan, interfaz y características están ocultas.

CH09-F05— CONSIDERANDO A DIFERENTES PROVEEDORES COMO NO COMPARABLES

Se rechazan las comparaciones de productos posibles bajo condiciones de usuario emparejadas.

CH09-F06— INTEGRANDO WEB Y MÓVIL

Las diferencias de interfaz y características desaparecen.

CH09-F07— COMBINANDO PLANES GRATUITOS Y DE PAGO

Las diferencias de calidad o características debido al plan se vuelven invisibles.

CH09-F08— CONSIDERANDO QUE LOS PRODUCTOS CORPORATIVOS Y DE CONSUMIDORES SON LOS MISMOS

La información privada y los ajustes del administrador están ocultos.

CH09-F09— TRATANDO EL RESULTADO DE LA API COMO PRODUCTO DE CONSUMO

Se eliminan las diferencias de orquestación y interfaz de usuario.

CH09-F10— SI EXISTE RECUPERACIÓN, CONSIDÉRELA USADA

No se puede verificar la ruta de conocimiento verdadero de la respuesta específica.

CH09-F11— SI NO HAY CITA, CONSIDÉRESE SIN FUENTE

Se ignora la posibilidad de recuperación oculta o invisible.

CH09-F12— SI EXISTE CITA, CONTAR COMO FUENTE CORRECTA

No se examina la coincidencia entre cita y afirmación.

CH09-F13— CONSIDERAR EL ACCESO A HERRAMIENTAS COMO USO DE HERRAMIENTA

Se desconoce qué herramienta se utilizó en la respuesta específica.

CH09-F14— CONSIDERAR LA MEMORIA COMO SESIÓN LIMPIA

El efecto de la personalización permanece invisible.

CH09-F15— CONSIDERAR NUEVA CONVERSACIÓN NO PERSONALIZADA

Se ignoran la configuración persistente de la cuenta e instrucciones especiales.

CH09-F16— PRESENTANDO EL CHAT ACTUAL COMO UNA NUEVA SESIÓN

El contexto previo está oculto.

CH09-F17— CONSIDERANDO UNA FUNCIÓN EXPERIMENTAL COMO UN ERROR DE DATOS

La variación real del producto se declara como una observación inválida.

CH09-F18— OCULTANDO UNA FUNCIÓN EXPERIMENTAL

Usuarios en diferentes implementaciones se combinan como un único producto fijo.

CH09-F19— UN SOLO CICLO DESPUÉS DE LA ACTUALIZACIÓN

El cambio material del producto se publica como el resultado de un único sistema fijo.

CH09-F20— IGNORANDO CAMBIOS SI NO HAY ANUNCIO

No se examina la interrupción del comportamiento observada.

CH09-F21— CONTANDO UN PRODUCTO EN VIVO COMO UN MODELO CONGELADO

Se afirma plena reproducibilidad.

CH09-F22— CONSIDERANDO UN MODELO CONGELADO COMO UN PRODUCTO REAL DE USUARIO

Se ocultan las diferencias de cadena de producto e interfaz.

CH09-F23— CONTANDO LA AUSENCIA DEL PRODUCTO COMO UN ERROR

El alcance del acceso se confunde con la precisión de la representación.

CH09-F24— RECHAZANDO UN ERROR TÉCNICO

Un problema de conexión o servicio se clasifica como resultado de la política.

CH09-F25— CONTANDO UN ERROR TÉCNICO COMO RECHAZO Y REINTENTO

El resultado real del usuario se elimina del denominador.

CH09-F26— OCULTANDO EL LÍMITE DE USO

La experiencia real del plan gratuito se vuelve invisible.

CH09-F27— CONSIDERANDO EL MISMO PROMPT COMO EL MISMO EXPERIMENTO

Se ignoran las diferencias de producto, plan, sesión, web y tiempo.

CH09-F28— CONSIDERANDO EL RESULTADO DEL PRODUCTO COMO SUPREMACÍA DEL MODELO

La diferencia a lo largo de toda la cadena del sistema se atribuye al modelo base.

CH09-F29— CLASIFICANDO DIRECTAMENTE LOS puntuaciones DE Alcance natural

Se consideran iguales diferentes universos poblacionales.

CH09-F30— CONSIDERANDO Base común de comparación COMO ALCANCE GLOBAL

El estrecho universo común se presenta como el alcance completo del producto.

CH09-F31— AFIRMANDO EL LIDERAZGO A PARTIR DEL RESULTADO CP-1

La superioridad del producto se deriva únicamente de resultados incompatibles que se colocan lado a lado.

CH09-F32— MANTENIENDO EL NIVEL DE COMPARACIÓN

El público solo ve la clasificación.

CH09-F33— IGNORANDO LA DEPENDENCIA DE USUARIO PAREADA

Las respuestas de la misma persona a los productos se consideran independientes.

CH09-F34— IGNORANDO EL EFECTO DEL ORDEN DE LOS PRODUCTOS

La primera respuesta afecta las tareas posteriores.

CH09-F35— TRATANDO A DIFERENTES USUARIOS DEL PANEL COMO IGUALES

Los productos se prueban con diferentes composiciones de usuarios.

CH09-F36— CAMBIANDO LA VERSIÓN DEL PAQUETE DE REALIDAD

Se comparan las mismas respuestas con diferentes registros de referencia.

CH09-F37— CAMBIANDO SILENCIOSAMENTE LA HUELLA DEL PRODUCTO

Se actualiza el registro de configuración; la medición antigua se preserva en lugar de sobrescribirse.

CH09-F38— CONTANDO UN ÁREA DESCONOCIDA COMO LIMPIA

Se acepta el estado del modelo, la memoria o la herramienta como controlado, incluso si es desconocido.

CH09-F39— USANDO LA MARCA DEL PRODUCTO EN LUGAR DE LA EVIDENCIA

La reputación del proveedor sustituye las condiciones de medición.

CH09-F40— CUBRIENDO TODAS LAS DIFERENCIAS DE PRODUCTO CON UN SOLO COEFICIENTE

Las diferencias de plan, interfaz y configuración se ocultan utilizando el coeficiente de modelo o de mercado.

50. PROCEDIMIENTO DE AUDITORÍA

Paso 1— Identificar al Proveedor y Producto

El nombre del producto, el tipo y las interfaces de usuario oficiales están registrados.

Paso 2— Fijar la Interfaz de Medición

Web Móvil Escritorio

API

El producto integrado se desacopla.

Paso 3— Verificar el Plan y la Clase de Cuenta

Se registra el estado del plan gratuito, de pago, empresarial u otro.

Paso 4— Asignar Confianza al ID del Modelo

Se determina el nivel apropiado entre MI-0 y MI-5.

Paso 5— Guardar la Recuperación y la Configuración Web

¿Está disponible la función? ¿Está activada? ¿Se utilizó en una respuesta en particular? ¿Cuál es la evidencia?

Paso 6— Guardar estado de referencia y herramienta

El uso real se separa del acceso a la función.

Paso 7— Guardar estado de sesión y personalización

Se revisa la instrucción especial de memoria, el chat anterior y la configuración corporativa.

Paso 8— Verificar registro de país, región e idioma

Se determina la condición regional del comportamiento del producto.

Paso 9— Revisar funciones experimentales

Se verifican diferencias de interfaz o función entre usuarios.

Paso 10— Fijar tiempo e identidad de onda

Se crean registro de tiempo y onda UTC.

Paso 11— Generar huella de configuración del sistema

Los campos guardados están vinculados al registro de integridad.

Paso 12— Monitorear eventos de cambio

Se registran los cambios de producto anunciados y observados.

Paso 13— Escribir el objeto de comparación

¿Cuál de las comparaciones de tiempo de la interfaz del Plan de Recuperación del Modelo de Producto se está realizando?

Paso 14— Hacer coincidir las dimensiones de comparación

Se tabulan las áreas de material.

Paso 15— Asignar nivel CP

Se asigna un nivel apropiado entre CP-0 y CP-5.

Paso 16— Separar afirmaciones comparables y no comparables

Se escribe claramente qué resultados pueden colocarse lado a lado.

Paso 17— Separar los resultados de Alcance natural y Base común de comparación

Se registran por separado las comparaciones intra-producto y de población común.

Paso 18— Verificar Cambio del Sistema en la Onda

Se determina si se necesita MIXED_SYSTEM_STATE o una nueva subonda.

Paso 19— Crear Tarjeta de Comparación Pública

Se hacen visibles las condiciones detrás del ranking.

Paso 20— Obtener la Aprobación del Propietario del Registro

El registro del sistema y la decisión de comparación son versionados por la persona responsable.

51. EVIDENCIA REQUERIDA

Identidad del proveedor; nombre y tipo de producto; interfaz de usuario; versión de la aplicación o interfaz; plan y clase de cuenta; etiqueta de modelo mostrada; evidencia de identidad del modelo; nivel de confianza de la identidad del modelo; documentación del producto; registros de acceso por país; idioma y configuración regional; capacidad web y de recuperación; evidencia de uso de recuperación; capacidad de citación; vista de citación; enlace de citación–afirmación; acceso a herramientas; registro de uso de herramientas; configuración de memoria; instrucciones personalizadas; estado de chat previo; tipo de sesión; configuraciones del administrador organizacional; registro de función experimental; señales de asignación A/B; marca de tiempo UTC; ola de medición; huella de configuración del sistema; registros de actualización del proveedor; cambios observados en el comportamiento; errores de acceso al producto; registros de reintento técnico; registro de población Alcance natural; registro de población Base común de comparación; y tabla de dimensión de comparación.

Nivel CP Versión del prompt Versión del paquete de realidad Registro de muestra y peso Versión de adjudicación Tarjeta de comparación pública Registro de cambios Persona o institución responsable

52. LISTA DE VERIFICACIÓN DE AUDITORÍA

¿Se registraron el proveedor y el producto por separado? ¿Es identificable el interfaz de usuario? ¿Se verificaron el plan y la clase de cuenta? ¿La etiqueta del modelo es simplemente la etiqueta mostrada, o identifica un despliegue verificado? ¿Se asignó un nivel de confianza de identidad del modelo? ¿Se atribuye el resultado al producto o al modelo? ¿Estaban disponibles la web o la recuperación? ¿Se verificó su uso en la respuesta específica? ¿Se separaron la capacidad de citación y la visualización de citas? ¿Apoyan realmente las citas las afirmaciones? ¿Se separaron el acceso a herramientas y el uso de herramientas? ¿Se habilitó la memoria? ¿Había instrucciones personalizadas? ¿Hubo contexto conversacional previo? ¿Se registró el tipo de sesión? ¿Estaba presente una fuente de información empresarial o privada? ¿Se verificaron características experimentales del producto? ¿Podrían el país y la localidad afectar el comportamiento del producto?

¿Se ha creado la huella del sistema? ¿El producto cambió durante la ola de medición? ¿Hubo alguna ruptura de comportamiento fuera del anuncio del proveedor? ¿Se separaron las observaciones previas y posteriores al cambio? ¿Se distinguieron los errores técnicos de los rechazos? ¿Se realizó un reintento debido a una respuesta incorrecta? ¿Está claro el objeto de la comparación? ¿Qué condiciones coinciden además del mismo prompt? ¿Es la población objetivo la misma? ¿Son las versiones del prompt y del Paquete de Verdad las mismas? ¿Son visibles las diferencias en el plan, la interfaz y la recuperación? ¿Se proporcionó el nivel CP? ¿Se realizó una clasificación a partir de los resultados de CP-0 o CP-1? ¿Se separaron los resultados de Alcance natural y Base común de comparación? ¿Estaba equilibrada la misma secuencia de productos de usuario? ¿Se calibraron diferentes paneles de usuarios?

¿Se presentó el resultado del producto en vivo como una superioridad fundamental del modelo? ¿Se consideraron controladas las áreas desconocidas? ¿Está disponible una tarjeta de comparación pública? ¿Se conoce al propietario responsable del registro del sistema?

53. OBJECIONES Y RESPUESTAS

Objeción 1— “Si el usuario no sabe qué modelo se está ejecutando, ¿se puede hacer este trabajo de todos modos?”

Se puede hacer. El objeto principal GEO-1000 es el producto del usuario. Si el modelo es desconocido, el resultado se informa como: “Este comportamiento se observó en este producto y interfaz de usuario.” No se hace referencia a un modelo específico.

Objeción 2— “¿Por qué diferenciamos tanto los productos del mismo proveedor?”

Porque el usuario:

• plan diferente,
• modelo,
• recuperación,
• memoria,
• herramienta

Puede ver respuestas diferentes bajo diferentes condiciones. El nombre del proveedor no define completamente la experiencia del usuario.

Objeción 3— “¿No es comparar diferentes proveedores como comparar manzanas con naranjas de todos modos?”

Si la pregunta de comparación está configurada correctamente, no lo es. Un usuario real podría preguntar: “¿Qué producto me informa de manera más correcta?” Toda la cadena de productos es parte de esta pregunta. Si se pretende afirmar la superioridad del modelo base, se necesita un experimento más controlado.

Objeción 4— “¿No es natural que un producto que usa la web tenga una ventaja?”

Es natural. En una comparación de productos naturales, la ventaja es la característica real del producto. En la comparación de modelos, el efecto de recuperación también debe separarse.

Objeción 5— “¿No es injusto no dar una puntuación de citas a un producto que no muestra citas?”

La función de atribución es la función que el producto ofrece al usuario. Si la función falta, el resultado de la atribución puede mostrarse como:

REGISTRADO COMO NO DISPONIBLE

La precisión del material también se mide por separado.

Objeción 6— “Si la memoria es parte de la experiencia natural del usuario, ¿por qué la apagamos?”

Puede permanecer activado en el panel natural. Puede apagarse en el panel controlado para borrar comparaciones entre productos. Los dos paneles responden a diferentes preguntas.

Objeción 7— "¿No es suficiente con abrir un nuevo chat para una sesión limpia?"

No siempre. La memoria persistente, las instrucciones especiales o la configuración de la cuenta pueden continuar. Estas áreas también deben ser guardadas.

Objeción 8— "¿Qué podemos hacer si el proveedor no explicó el cambio de producto?"

Observado:

• interfaz,
• característica,
• comportamiento,
• Atribución

Podemos guardar sus cambios. Si la causa es desconocida, se utiliza un estado de cambio indefinido como UC-5.

Objeción 9— "Si los productos están cambiando constantemente, ¿no serán válidos todos los resultados?"

El resultado indicado:

• fecha,
• onda,
• Muestra de producto

Es válido para. La variabilidad no hace que la medición carezca de sentido. Previene juicios prematuros.

Objeción 10— "¿No es suficiente comparar el mismo prompt y el mismo día?"

El plan, la interfaz, la memoria, la web, el país y la población de usuarios pueden diferir. El mismo prompt puede ser requerido. No es suficiente por sí solo.

Objeción 11— '¿No sería demasiado técnico el nivel de CP para el público?'

Se puede usar una etiqueta corta:

• Descriptivo
• Parcialmente coincidente
• Coincide
• Controlado
• Replicado

Se debe saber qué tan fuerte es la clasificación pública.

Objeción 12— “¿Por qué no podemos clasificar directamente según los puntuaciones Alcance natural?”

Debido a que cada producto puede haber sido medido en diferentes países y poblaciones de usuarios. La diferencia de puntuación puede surgir en parte de cuál población alcanzó el producto. Base común de comparación proporciona una comparación más justa.

Objeción 13— "¿No es Base común de comparación un resultado del mundo real?"

Es el resultado de la población compartida real. Sin embargo, no muestra el acceso de los productos fuera del universo compartido. Debe leerse junto con Alcance natural.

Objeción 14— “¿Es más importante la inspección de productos en vivo o la inspección de modelo congelado?”

Las preguntas son diferentes. El producto en vivo mide la verdad del usuario. El modelo congelado proporciona control científico y reproducibilidad. NOMOS no los utiliza de manera intercambiable.

REGLA COMÚN DEL CAPÍTULO 57

Un usuario:

• “ChatGPT lo dijo.”
• “Gemini lo pensó.”
• “Claude nos recomendó.”
• “Algunos nos citaron.”

se puede decir. Estas expresiones son comprensibles en la conversación diaria. No son suficientes en un registro de auditoría. Porque bajo estos nombres:

• diferentes productos,
• diferentes planes,
• diferentes modelos,
• diferentes interfaces de usuario,
• diferentes sistemas web y de recuperación,
• diferentes condiciones de memoria,
• diferentes países,
• diferentes momentos

pueden encontrarse. Diferentes personas pueden ver diferentes experiencias de IA bajo el mismo nombre. Se pueden establecer experiencias de usuario comparables bajo nombres diferentes. Una etiqueta de modelo parece haber producido toda la respuesta. Pero la realidad que llega al usuario:

• selección de fuente,
• de seguridad,
• personalización,
• interfaz,
• herramientas

El resultado puede verse influenciado por los controles de seguridad, la personalización, la interfaz y las herramientas disponibles. NOMOS, por lo tanto, pregunta más que '¿Qué modelo?' Pregunta: ¿Qué producto? / ¿Qué interfaz? / ¿Qué plan? / ¿Qué modo de información? / ¿Qué sesión? / ¿Qué usuario? / ¿Qué país? / ¿Qué momento? / ¿Qué versión? Dos resultados pueden provenir del mismo prompt sin provenir del mismo experimento. Dos resultados pueden provenir de diferentes proveedores y, sin embargo, seguir siendo bastante comparables bajo las mismas condiciones de usuario. Un producto es un sistema en vivo: sus fuentes, interfaz y modelo pueden cambiar. El cambio no hace que un resultado sea inútil; lo liga a un momento y estado del producto específicos. La novena ley de medición de NOMOS es por lo tanto:

Un proveedor de IA no es un producto de IA.

La décima ley es:

El modelo es solo una parte de la cadena de representación que llega al usuario.

La undécima ley es la siguiente:

El mismo nombre garantiza comparabilidad; un nombre diferente no garantiza no comparabilidad.

La duodécima ley es la siguiente:

El mismo estímulo no es el mismo experimento.

La ley decimotercera es la siguiente:

El resultado del producto vivo es válido solo para la muestra del producto y el momento en que se mide.

La ley decimocuarta es la siguiente:

El poder de la comparación no proviene de la magnitud del rango, sino de la claridad de las condiciones coincidentes.

Orden de la Sección 9 de NOMOS

No me des solo el nombre del proveedor. / Muestra cuál producto se usó, en qué interfaz y con qué plan.

No hagas que la etiqueta del modelo que ves en la pantalla sea la identidad exacta de todo el sistema de back-end.

Se utilizó porque había una función web; no asumas que respaldaba la afirmación solo porque había una cita.

No cuente el acceso a herramientas como uso de herramientas, un nuevo chat como una cuenta limpia o un estado de memoria desconocido como memoria apagada.

No pongas en la misma celda a un usuario gratuito y a un usuario de pago, un producto móvil y un producto web, o un espacio de trabajo empresarial y un chat general.

No considere automáticamente los resultados del mismo proveedor como una comparación justa.

No evites comparar diferentes proveedores solo porque son diferentes. / Primero, iguala las condiciones. / Luego, explica qué pregunta respondiste.

No presente un producto en vivo como un modelo congelado, una API como una experiencia de consumidor, o un resultado de producto como superioridad del modelo base.

Si el sistema cambió en medio de la ola, no combine las respuestas antiguas y nuevas como un solo producto.

No ignores el cambio de comportamiento frente a ti solo porque el proveedor no explicó la modificación.

No suponga que lo desconocido está limpio, es igual o está arreglado.

Primero, registre el sistema en el registro. / Luego bloquee la configuración. / Luego supervise los cambios. / Luego escriba el objeto de comparación. / Luego muestre las condiciones que coinciden y las que no coinciden. / Y solo entonces diga qué producto dio un resultado más fuerte bajo qué condición.

La oración de cierre del capítulo

El “AI” medido en GEO-1000 no es un nombre o modelo único; es un sistema de representación versionado que alcanza a un usuario específico en un momento específico dentro de una cadena de producto específica.

Core normativo

Cada observación GEO-1000 DEBE estar vinculada a un registro versionado del Registro del Sistema de IA que describa la instancia del producto medida, incluyendo, según corresponda: - proveedor, - producto, - interfaz de usuario, - plan, - identidad del modelo mostrada o verificada, - confianza en la identidad del modelo, - configuración de recuperación y web, - capacidad y uso de citación, - acceso y uso de herramientas, - estado de la sesión, - memoria, - instrucciones personalizadas, - contexto previo, - personalización, - país, - configuración regional, - idioma, - estado de implementación, - tiempo de medición, - y cambios del sistema conocidos u observados. El nombre del proveedor, el nombre del producto, la etiqueta del modelo mostrado, el modelo base, el sistema de recuperación y el producto orientado al usuario NO DEBEN ser tratados como identidades intercambiables. La disponibilidad de funciones DEBE mantenerse distinta del uso de funciones. Los resultados de productos en vivo NO DEBEN representarse como resultados de modelos congelados, y los resultados de modelos congelados NO DEBEN representarse como la experiencia completa del producto para el consumidor. Las comparaciones DEBEN definir su objeto y recibir un nivel de comparabilidad divulgado basado en entidad coincidente, prompt, población, idioma, país, tiempo, sesión, plan, interfaz, recuperación, herramientas, registros de referencia y reglas de adjudicación. El mismo proveedor o modelo mostrado NO DEBE crear una suposición automática de comparabilidad. Se PUEDEN comparar diferentes proveedores cuando las condiciones orientadas al usuario estén suficientemente alineadas y la afirmación resultante se limite al comportamiento del producto medido. Los cambios materiales del producto durante una fase de medición DEBEN crear un estado del sistema separado, sub-fase, factor de cambio modelado, o prompt de estado mixto. Los campos de configuración desconocidos DEBEN permanecer DESCONOCIDOS y NO DEBEN ser imputados como controlados o equivalentes. Cada decisión del registro del sistema y de comparabilidad DEBE estar versionada y ser atribuible a un humano u organización responsable.