chimera-when-two-results-contradict-suspect-the-apparatus
Cuando dos de tus propias mediciones discrepan por un margen que ningún mecanismo podría producir, el defecto está en el instrumento. Audita el harness antes de construir teoría encima.
Conferida por quien revisó y leyó la tarjeta, no reclamada por el propio archivo. Una tarjeta que el agente destila durante una ejecución que consumió contenido no confiable nace contaminada y queda retenida para revisión antes de ser recuperada.
Cuándo viene a la mente
- dos ejecuciones discrepan muchísimo
- la ejecución más pequeña puntuó mejor
- una métrica se movió en una dirección imposible
- explicando un resultado de benchmark sorprendente
Evita y Comprueba es donde suele estar el valor. Haz es la sección que todo el mundo escribe.
El cuerpo de la tarjeta de arriba es una traducción. El original en inglés es lo que importa la CLI, lo que lee el agente en ejecución y lo que atestigua el hash de abajo.
Disparador
Dos mediciones que produjiste tú mismo discrepan en una cantidad que no puedes explicar: la ejecución con una fracción de los datos puntúa mejor que la grande; un componente marca 0% en una tarea que una medición adyacente muestra que hace de forma rutinaria; un cambio mueve un número en la dirección que él mismo hace imposible.
El disparador es el tamaño de la brecha, no su existencia. Dos ejecuciones que difieren dentro de su banda de ruido son una cuestión de muestreo, y esta tarjeta no tiene nada que decir al respecto. Tampoco aplica a tu número contra el número publicado por otro — datos, prompts, semillas y versiones distintos explican eso todo el día, y tratarlo como alarma de aparato te tendrá auditando un harness que está bien. El caso aquí es: ambos lados de la contradicción son tuyos, y ambos no pueden ser ciertos.
Haz
- Escribe primero la contradicción, como dos líneas: los dos números, y los comandos y commits exactos que los produjeron. Deja de teorizar hasta que eso esté sobre el papel — una contradicción no escrita se ablanda hasta volverse un acertijo en cosa de un párrafo.
- Haz el diff de las dos ejecuciones antes de razonar sobre ellas: configuración, commit, camino de código, hash del archivo de entrada, versión del evaluador. Prefiere un diff que puedas leer a una explicación que puedas construir.
- Pasa respuestas conocidas por la propia medición. Ejecuta las soluciones de referencia por tu evaluador antes de confiar en ninguna puntuación de un modelo. Si una respuesta correcta conocida se puntúa como fallo, el defecto está en el evaluador y todos los números que ha producido son nulos, incluido el que te gustaba.
- Solo una vez que el aparato sobrevive al paso 3 gastas esfuerzo en explicar el fenómeno.
- Si el aparato tenía la culpa, retracta los números en lugar de reinterpretarlos. Una puntuación de un evaluador roto no es una estimación ruidosa de la verdad; no guarda relación con ella.
Evita
Construir varias hipótesis cuidadosas para explicar ambos números y luego probarlas con rigor. Esa es la versión cara de este error: el rigor es real, el esfuerzo es real, y todo ello se mide sobre un artefacto. La calidad del método aguas abajo de un instrumento roto solo te lleva a la respuesta equivocada con mejores barras de error.
Evita reconciliar por aritmética — promediar los dos, o quedarte calladamente con el que coincidía con lo que esperabas. Evita un evaluador de mundo cerrado, que es el bug concreto que produce esta forma con más frecuencia:
# and the score then reads as "the model cannot do this at all"
CITIES = {"lisbon", "porto"}
ok = answer.lower() in CITIES
# yes — grade against a rule that the real world can satisfy
ok = geocode(answer) == geocode(expected)
Y evita la frase «debe de ser una casualidad» como punto final. Es una hipótesis sobre el aparato, así que es comprobable — compruébala o descártala.
Comprueba
Una frase, en voz alta, con una magnitud dentro: «X produce una diferencia así de grande porque…». Si no puedes terminarla — «diez veces menos datos produciendo mejor puntuación porque…» — el instrumento es el sospechoso y el paso 3 es adonde vas después.
Luego la binaria: ¿pasaron las respuestas de referencia por el evaluador? Cualquier elemento de referencia que el evaluador marque como incorrecto es un techo sobre lo que la medición podría haber significado jamás, y la fracción de ellos que falla es el primer número que hay que reportar.
Riesgo
A veces la contradicción es real y el resultado sorprendente es el hallazgo. Un reflejo de culpar al harness los descarta y — peor — es exactamente el movimiento disponible para quien quiera que una medición inconveniente desaparezca. Así que acótalo: la comprobación del aparato es una lista fija y corta (diff de las ejecuciones, referencias por el evaluador, confirmar los hashes de entrada). Si esa lista vuelve limpia, cree la contradicción y ve a investigar el fenómeno. Esta tarjeta ordena el trabajo; no elige la respuesta.
El segundo costo es recursivo. Código nuevo escrito para revisar el código viejo es una cosa más que puede estar mal, y un script de auditoría con bugs acaba de producir un tercer número. Prefiere comprobaciones que usen artefactos que ya tienes y entradas cuyas respuestas se conocen, antes que un harness nuevo escrito bajo la presión de una anomalía.
Cómo usarla
La tarjeta es un dato. Clona el repositorio e impórtala por ruta: lo que llega por la red se trata como contaminado y queda retenido a la espera de aprobación, que es el comportamiento deseable y la razón por la que aquí no hay un instalador de una línea.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-when-two-results-contradict-suspect-the-apparatus/SKILL.mdIntegridad
SHA-256 del archivo tal como se publicó. Quien lo importe puede comprobar que lo que recibió es lo que mostró esta página.
c33d19c446e5da887d8aee039d0e58690472bd2db3c6d8322497b6cebfbb62bf