Cómo medimos GNOSIS: 41 consultas, 10 trampas y lo que falló

Por qué medimos#

La página de GNOSIS dice que el asistente no inventa fallos. Esa frase es una promesa, y una promesa sin medición es solo marketing.

La primera vez que corrí este examen fue un sábado de agosto, con la notebook y el mate ya frío. Armamos un golden set, un lote de consultas jurídicas con la trampa adentro, para ver si el sistema decía "no lo tengo" cuando correspondía o inventaba algo para quedar bien. Esa tarde el chequeo automático marcó una cita como fabricada. Fuimos a leerla: el número venía de nuestra propia pregunta, el asistente la había citado para rechazarla, no para inventarla. Corregimos la regla ese mismo día.

Revisando ahora el informe real de esa corrida de agosto, encuentro que el plan gratuito sí tuvo una cita fabricada de verdad, no cero como decía el texto que publicamos entonces. No sé cómo pasó: el borrador quedó con una cifra que su propio informe no respalda, y en su momento nadie lo cruzó.

Por eso esta vez lo cuento distinto: con la fecha de la corrida, el archivo fuente y la revisión manual antes de publicar nada.

Cómo es el examen#

Un golden set es un examen con respuesta esperada conocida, armado a propósito para tentar al sistema a fallar. El de GNOSIS tiene 41 consultas de derecho paraguayo: preguntas reales de usuarios, parafraseadas para no exponer a nadie, más consultas para cubrir huecos, artículos puntuales del CT y del Código Civil, comparaciones de criterio entre salas, casos con hechos para razonar.

Diez de esas 41 son trampas. Piden un Acuerdo y Sentencia que no existe, jurisprudencia penal que la base nunca cargó, un artículo del Código Procesal Civil que ya no rige, citado como vigente. Frente a una trampa lo correcto es decir "eso no lo tengo". Rellenar el hueco con un invento es justo lo que la landing promete que no pasa.

Cada consulta corre dos veces, una por plan: Explorar, que usa Haiku, y Profesional, que usa Sonnet. Las preguntas pasan por el motor real del producto, con las mismas herramientas de búsqueda, en un arnés de evaluación que no reproduce todos los ajustes de salida de producción.

Un verificador automático lee las 82 respuestas y compara cada número de Acuerdo y Sentencia citado contra la base. Ahí está el límite del método: el script compara solo el número, no la fecha ni la sala. Dos fallos distintos pueden compartir número entre años, así que "el número existe" no alcanza para decir "la cita es correcta". Por eso, además del chequeo automático, reviso a mano una muestra buscando cada cita por número y fecha exacta, y comparo tribunal, sala y fecha contra lo que la respuesta atribuye.

Resultado de la corrida del 05/09#

En esta corrida del 05/09 sobre 82 respuestas (41 consultas en cada plan), 17 respuestas de Explorar y 17 de Profesional citaron jurisprudencia. Revisé a mano 11 citas en Explorar y 23 en Profesional. En Explorar, 10 de 11 coinciden en tribunal, sala, fecha y número con el fallo de la base; la que queda no es verificable con precisión porque la respuesta no dio fecha y hay varios fallos homónimos. En Profesional, 20 de 23 coinciden en identidad completa, 2 tienen respaldo parcial (la propia respuesta ya advirtió que no podía confirmar si eran opinión del tribunal o alegato de parte, y esa advertencia fue correcta), y 1 no es verificable por la misma razón que en Explorar.

Las otras 24 respuestas de cada plan no citaron jurisprudencia y no entran en el conteo de aciertos. En Profesional, esas 24 incluyen 2 respuestas completamente vacías; una tercera sí llegó a citar, con identidad verificada, pero se cortó antes de terminar de responder.

De las 10 consultas trampa, GNOSIS rechazó las 10 en Explorar y las 10 en Profesional, sin afirmar como real ningún fallo, artículo o acordada inventado. Esa es la lectura de la revisión manual línea por línea. El conteo automático, más estricto con el fraseo exacto, reconoció 5 de 10 y 8 de 10 respectivamente.

Lo que falló y qué se corrigió#

La primera corrida completa de este golden set midió el plan Profesional con el modelo equivocado. El archivo de configuración local del producto tiene una variable, ANTHROPIC_MODEL, que si está presente fuerza Haiku en todo el tráfico del chat, sin importar qué modelo le toque a cada plan según el pricing. Estaba presente, así que esa corrida midió bien el plan Explorar (que de todas formas usa Haiku) pero midió Profesional corriendo con Haiku, no con el Sonnet que ese plan promete.

Repetí el plan Profesional neutralizando la variable desde la terminal, sin tocar el archivo ni el código. Confirmé con una consulta de prueba que el modelo había cambiado y corrí después las 41 consultas completas otra vez: los números de Profesional que cito acá salen de esa segunda corrida.

Dos respuestas de Profesional, ya con Sonnet, volvieron con el texto completamente vacío, después de haber ejecutado varios pasos de búsqueda. Una tercera no quedó vacía, pero se cortó a mitad de una oración, sin llegar a responder la pregunta de fondo. El chequeo de citas no marca nada de esto como falla: para ese script, una respuesta vacía y una respuesta correcta son indistinguibles, porque ninguna de las dos tiene una cita que verificar. El arnés de evaluación tampoco fija el mismo techo de tokens de salida ni el mismo nivel de esfuerzo que usa la ruta de producción; sospecho que esa diferencia tiene algo que ver con los cortes, pero con lo que tengo acá no lo puedo confirmar.

El verificador automático busca frases de rechazo de una lista fija de once, del tipo "no encontré" o "no dispongo de". Varias trampas se rechazaron con palabras fuera de esa lista, como "no existe un tope de 200 salarios mínimos en la norma civil aplicable" o "no arrojó resultados" para una sala puntual. El script las marcó "revisar" aunque el contenido estaba bien. Leí completas esas seis respuestas y las diez trampas de los dos planes: ninguna afirmó como real un fallo, artículo o acordada que no existe.

Ese mismo verificador, cuando sí hay una cita, compara solo el número de Acuerdo y Sentencia contra la base. No mira fecha ni sala, y hay números que se repiten entre años y salas distintas. Por eso la identidad completa (número, sala y fecha exactos) la revisé a mano, sobre una muestra, en vez de confiársela al script.

Quedó una pregunta sin cerrar: si la misma variable de configuración también está presente en el entorno donde corre el producto en vivo. No lo pude verificar desde acá. Si lo estuviera, hay que revisarlo aparte; no es algo que este examen mida.

Qué no mide este examen#

41 consultas no prueban el universo de lo que un abogado puede preguntar, y la base de GNOSIS no cubre todas las materias del derecho paraguayo: un tema ausente no es un tema que el sistema vaya a inventar, pero tampoco uno que vaya a responder bien. Este examen mide si la cita existe en la base propia de GNOSIS, no si coincide con el portal del Poder Judicial: son bases distintas, y no cruzamos una contra la otra. El chequeo automático compara solo el número de la resolución; la identidad completa (sala, fecha, tribunal) sale de la revisión manual, sobre una muestra, no sobre las 82 respuestas completas.

Cómo seguimos midiendo#

Para repetir el examen, hacemos las mismas 41 preguntas en Explorar y en Profesional. Primero comprobamos automáticamente si los números de las resoluciones citadas aparecen en la base. Después revisamos a mano una muestra: contrastamos tribunal, sala, fecha y número, y señalamos las citas que no podemos verificar por completo.

Antes de incorporar un cambio importante en GNOSIS, como un modelo nuevo o una actualización de la base de fallos, volvemos a pasar por este examen. La próxima evaluación tendrá su propio informe fechado, para que se pueda comparar qué mejoró y qué sigue fallando.

Este post cierra, como el número 11, la serie C4L-PY sobre cómo construimos GNOSIS en público. El post anterior mostró el mismo principio con otro examen: si el eval falla, no se publica.