AnyJev: calibración de LLM y sesgo por orden

Revisado el 28 de septiembre de 2026. Versión de referencia: AnyJev 0.2.0. Código revisado: 10d5db91dda38dbde74c6abc1c075ce6463723d1. Este artículo analiza documentación y código fuente; no presenta un benchmark propio en GPU ni un despliegue de Wavect en producción. Publicación de AnyJev 0.2.0

¿Qué es AnyJev y qué significa «sin entrenamiento»?

AnyJev es una biblioteca de código abierto que extrae decisiones tipadas de un modelo de lenguaje existente, en lugar de pedirle que redacte una respuesta. Su aportación no se limita a la velocidad: aborda el sesgo por el orden de las opciones y distingue las puntuaciones corregidas de la confianza calibrada con etiquetas. El proyecto identifica como autores a Jiamu Zhang, Tianze Yang, Yucheng Shi y Liang Wu, con afiliaciones a Nokia y Tencent Hunyuan. Se inspira en la interfaz Jev de TypeSafe AI, pero no está afiliado a TypeSafe. Descripción y atribución del proyecto

El paquete se publica bajo Apache 2.0. Eso no constituye una licencia global para todos los modelos o conjuntos de datos que utilices. Licencia del paquete.

La cuestión práctica es sencilla. Un agente ya dispone de un ticket, un documento o el resultado de una herramienta. Debe elegir una de varias respuestas permitidas. ¿La elección sigue siendo fiable cuando alguien cambia su orden? ¿Una confianza de 0,9 significa que decisiones comparables son correctas aproximadamente el 90% de las veces?

Son problemas distintos. Una respuesta estable puede ser incorrecta. Una distribución normalizada puede transmitir demasiada confianza. AnyJev ofrece diferentes niveles de procesamiento, no una solución universal.

«Sin entrenamiento» describe correctamente su ruta L0 sin etiquetas. L1 ajusta una temperatura mediante ejemplos etiquetados. L2 ajusta una cabeza lineal supervisada, aunque no modifica el modelo base ni utiliza descenso de gradiente para ese ajuste. Presentar los tres niveles como «sin entrenamiento» oculta el trabajo de datos y validación. La distinción útil es no hacer fine-tuning del modelo base frente a no ajustar nada con etiquetas. Contrato de cada nivel

Para entender el panorama general, consulta nuestro análisis de Jev y la comparación de benchmarks de Laya y Jev. Esta guía se centra en la calibración, el orden y la evaluación de AnyJev, no en otra clasificación de modelos de decisión.

Raw, L0, L1 y L2: ¿qué ruta necesita etiquetas?

Los intervalos son orientaciones del proyecto, no garantías sobre el tamaño de muestra. Los errores poco frecuentes pero costosos pueden exigir muchos más datos. Del mismo modo, auto significa «usar el mejor nivel disponible», no «automáticamente seguro». Comprueba el nivel devuelto. La tabla resume el contrato documentado.

Por qué cambiar el orden de las opciones cambia la respuesta

Imagina tres respuestas semánticas: facturación, soporte técnico y ventas. Una implementación sencilla las asigna a A, B y C, lee las puntuaciones del siguiente token y selecciona la mayor. Sin embargo, una preferencia por «A», por una posición inicial o por una opción vecina puede convertirse en preferencia por la respuesta de negocio que ocupe ese lugar.

Es un problema conocido en investigación, no un descubrimiento original de AnyJev. Zheng y sus colaboradores estudiaron la sensibilidad de la selección múltiple de los LLM al orden de las opciones. Su trabajo forma parte de la base del enfoque de permutaciones del proyecto. Investigación sobre sensibilidad al orden en selección múltiple

AnyJev normalmente evalúa las rotaciones cíclicas de una pregunta con K opciones. Cada opción ocupa una vez cada posición. El método predeterminado logmean vuelve a asociar las probabilidades con las opciones semánticas, promedia sus logaritmos, aplica la exponencial y renormaliza. Bajo un supuesto idealizado de sesgo posicional aditivo en los logits, el término de posición se cancela. Implementación de rotaciones y marginalización

Esa cancelación idealizada no demuestra invariancia ante cualquier permutación real del prompt. Un ciclo completo conserva las relaciones de vecindad entre opciones; el modelo puede responder a esas interacciones. Los resultados anteriores de BANKING77 siguen mostrando cambios residuales de respuesta.

La versión 0.2.0 ofrece otra medida, opcional: canonical_order=True ordena las opciones por su texto antes de rotarlas. El mismo conjunto genera así los mismos prompts con independencia del orden recibido. Es una propiedad de normalización determinista de la entrada, suponiendo iguales condiciones de inferencia y estado del prior. No garantiza acierto, no elimina variaciones numéricas ni independiza un prior acumulado del historial de solicitudes. La documentación del presupuesto de rotaciones explica por qué también importa cuando solo se leen algunas rotaciones.

Al probar reordenamientos, compara etiquetas semánticas, no índices. El índice cero identifica otra cosa después de invertir la lista. Distingue también el desacuerdo entre rotaciones individuales del desacuerdo entre dos llamadas completas con entradas reordenadas.

Cuándo ayuda la corrección del prior y cuándo perjudica

L0 puede corregir un prior de etiquetas estimado a partir de predicciones sobre entradas sin etiquetar. Conceptualmente, divide cada puntuación por una estimación de la preferencia general por esa respuesta y renormaliza. La intensidad predeterminada del prior por lotes es 0,75; la corrección empieza cuando el acumulador de la pregunta ha visto al menos ocho entradas. Antes, el diagnóstico indica que no se aplica corrección. Valores predeterminados, calibración y estado del Decider

El problema: una predicción frecuente puede reflejar sesgo del modelo o una clase realmente frecuente. Las frecuencias de predicción sin etiquetas no distinguen ambos casos de forma fiable. Si la mayoría de los tickets pertenece de verdad a facturación, corregir esa mayoría hacia una distribución equilibrada puede empeorar el enrutamiento.

El estudio diagnóstico del proyecto abarca 230 combinaciones de modelo y pregunta. Describe mejoras útiles en tareas equilibradas de 20 clases, pero también pérdidas importantes en algunas preguntas desequilibradas. Mantiene prior="none" para aislar el efecto de las rotaciones cuando se sabe que las clases tienen frecuencias muy distintas. Es una ablación que conviene medir, no una promesa de que desactivar el prior siempre sea mejor. Resultados positivos y negativos de L0

El enfoque de calibración por lotes procede de Zhou y sus colaboradores. AnyJev lo combina con rotaciones e interfaces operativas; no inventa todos estos métodos desde cero. Investigación sobre Batch Calibration

También existe calibración sin contenido mediante entradas de prueba vacías o como N/A, siguiendo el trabajo de Zhao y sus colaboradores. Pero la respuesta del modelo a una entrada vacía puede tener significado propio. Trata prior="content_free" como otra variante experimental, no como una referencia universalmente superior. Calibrate Before Use

En un piloto de enrutamiento, compara raw, L0 solo con rotaciones y L0 predeterminado tanto en un conjunto diagnóstico equilibrado como en una muestra temporal de tráfico natural. El primero permite detectar clases débiles; la segunda refleja lo que encontrará el sistema.

Qué calibra L1 y por qué la temperatura no aumenta la exactitud

El escalado de temperatura modifica la concentración de un vector fijo de probabilidades. Conceptualmente aplica softmax(log(p) / T) con T positiva. Una temperatura mayor suele suavizar la confianza; una menor la concentra. AnyJev ajusta T minimizando la log-verosimilitud negativa en ejemplos etiquetados y guarda en el artefacto el prior utilizado durante esa calibración. Implementación del escalado de temperatura

Para un vector fijo, una temperatura positiva conserva la clase ganadora. No convierte una clase incorrecta en la correcta. La literatura distingue la calidad de las probabilidades de la exactitud de clasificación. Guo y sus colaboradores ofrecen el tratamiento fundacional utilizado aquí. On Calibration of Modern Neural Networks

¿Por qué pueden diferir ligeramente las columnas de exactitud L0 y L1? Porque el procesamiento completo no es solo una temperatura: L1 congela el prior estimado en sus datos de calibración, mientras que L0 puede acumular otro prior. No atribuyas la diferencia a que la temperatura cambie la clase ganadora. Se deduce de la implementación del Decider y de la transformación monótona anterior.

Por ello, un artefacto de despliegue útil necesita más que un valor de temperatura. Recomendamos registrar la revisión del modelo base, el tokenizador, el texto de la pregunta, el orden exacto de las opciones, la configuración del prior, la versión del paquete y la ventana temporal de calibración. Cambiar la pregunta o el servidor exige revalidar, no reutilizar silenciosamente un umbral favorable.

Qué demuestran realmente los benchmarks publicados

Los siguientes datos son resultados comunicados por el proyecto para Qwen3-8B en un subconjunto de 20 clases de BANKING77 con 300 casos de prueba. No representan las 77 clases completas, un SLA de Nokia en producción ni una medición de la configuración opcional canónica y adaptativa más reciente. Tablas de benchmarks versionadas

Las mejoras merecen estudiarse. Sin embargo, la última fila requiere especial cuidado: la cobertura es una propiedad retrospectiva de esa muestra ordenada por confianza. No prueba que un umbral fijo vaya a automatizar el 52% del tráfico futuro con un 5% de error. En esa muestra, el 52% equivale a unas 156 decisiones. Un error adicional entre 156 decisiones aceptadas cambia su tasa de error observada en aproximadamente 0,64 puntos porcentuales. El cálculo ilustra incertidumbre; no reconstruye un recuento de errores no publicado.

La misma fuente incluye un contraejemplo importante. En newsgroups con Qwen3-8B, L1 reduce el ECE de 0.309 a 0.138, pero la cobertura empírica al 5% de error baja de 42.3% a 23.7%. Una mejor calibración promedio no implica una mejor selección de bajo riesgo. Evalúa la calidad de las probabilidades y la curva de riesgo-cobertura. Fuente del benchmark.

Los resultados L2 requieren otra distinción. El repositorio comunica un 77,1% para Qwen3-8B en 2.000 decisiones tipadas después de ajustar cada pregunta con etiquetas. En ese conjunto, «exactitud» significa acuerdo con etiquetas derivadas de un modelo profesor, no una revisión humana independiente de cada resultado de negocio. El README identifica los datos comparativos de Jev como cifras publicadas por terceros, no como una repetición directa del experimento. No conviertas esas filas en un ganador general. Límites del proyecto.

Rotaciones adaptativas: un objetivo del 1% no significa 99% de acierto

Las rotaciones adaptativas intentan terminar antes de evaluar las K disposiciones. Se calibran con estados sin etiquetar porque la referencia es la propia respuesta del ciclo completo. El umbral de parada se selecciona utilizando una cota superior de confianza del desacuerdo frente a esa referencia. Se estima concordancia con otra lectura, no corrección respecto a la tarea real. Experimentos y límites del presupuesto de rotaciones

En un experimento publicado con Qwen2.5-7B, 18 opciones, una H100 NVL y vLLM 0.7.0, las rotaciones completas produjeron 16,73 decisiones/s. Las oleadas adaptativas de dos produjeron 37,20 decisiones/s con 7,28 solicitudes por decisión, una relación de rendimiento medida de 2,22×. Sin embargo, la concordancia fue del 98,7%, es decir, 1,3% de desacuerdo, por encima del objetivo nominal del 1%. Los autores lo indican expresamente. No es una garantía contractual sobre futuras solicitudes.

La secuencia práctica consiste en establecer una referencia con todas las rotaciones, activar el orden canónico, calibrar el presupuesto adaptativo en estados representativos separados y medir después tanto el desacuerdo con la referencia como los errores reales en datos reservados. El tamaño de calibración, el contexto y el servidor pueden cambiar el resultado. Menos rotaciones no equivalen al mismo factor de aceleración de todo el agente.

Un punto de partida reproducible para evaluar un router

El siguiente flujo es un ejemplo offline, no un despliegue medido. AnyJev 0.2.0 requiere Python 3.10 o posterior. Instálalo en un entorno aislado y bloquea las dependencias resueltas para reproducirlo. Fijar el paquete no fija PyTorch, Transformers ni los pesos del modelo. Versión de referencia.

python -m venv .venv
. .venv/bin/activate
python -m pip install "anyjev[hf]==0.2.0"

Question.choice admite actualmente entre dos y 26 opciones de texto únicas. Las etiquetas de calibración son índices enteros de esas opciones. Mantén una correspondencia semántica estable y evita categorías solapadas que obligarían a adivinar incluso a un anotador humano. Validación y hash de preguntas tipadas

El ejemplo presupone un entorno CUDA compatible y memoria suficiente para el modelo base elegido. El backend HF carga el modelo y su tokenizador, acepta una revisión y no habilita por defecto código remoto del modelo. Un paquete AnyJev pequeño no sustituye al modelo base por otro pequeño. Backend HF y carga del modelo

Antes de ejecutar los bloques Python en orden, establece ANYJEV_MODEL_REVISION con el commit real de 40 caracteres del modelo Qwen3-8B elegido. Es la revisión del modelo, no el commit del código de AnyJev.

import os
import re
from anyjev import Decider, Question
from anyjev.backends.hf import HFBackend

# Set this to the actual Qwen model commit, not the AnyJev commit.
revision = os.environ.get("ANYJEV_MODEL_REVISION", "")
if not re.fullmatch(r"[0-9a-f]{40}", revision):
    raise ValueError("Set ANYJEV_MODEL_REVISION to a Qwen3-8B commit SHA")

backend = HFBackend(
    "Qwen/Qwen3-8B", revision=revision,
    device="cuda", dtype="bfloat16",
)
route = Question.choice(
    "Which internal queue should review this ticket? Classify only.",
    ["Billing", "Technical support", "Sales", "Manual review"],
    name="route",
)
d = Decider(
    backend, level="L0", prior="none",
    canonical_order=True, adaptive_shifts=False,
)
result = d.decide("I need a copy of my invoice.", [route])["route"]
print(result.level, result.distribution)  # Inspection only; no dispatch.

El ejemplo usa deliberadamente todas las rotaciones, orden canónico y prior="none" para establecer una referencia del efecto de las permutaciones. No depende de un prior acumulado previamente sin indicarlo. Compáralo con la corrección por lotes predeterminada antes de seleccionar una configuración. La pregunta y las etiquetas en inglés se mantienen idénticas en todas las traducciones para conservar el mismo experimento.

Recoge a continuación archivos separados de calibración y evaluación reservada. Cada línea JSONL no vacía debe contener id, state y un label que coincida con una opción. La línea ilustrativa muestra el formato; no constituye un conjunto suficiente de calibración.

{"id":"ticket-example-001","state":"Please resend my invoice.","label":"Billing"}

# Continue after the setup above. Supply your own labeled JSONL files.
import json
from pathlib import Path


def load_rows(filename: str, minimum: int = 1) -> list[dict]:
    rows, ids, states = [], set(), set()
    for line_no, line in enumerate(Path(filename).read_text(encoding="utf-8").splitlines(), 1):
        if not line.strip():
            continue
        row = json.loads(line)
        if not isinstance(row, dict) or not all(
            isinstance(row.get(k), str) and row[k].strip()
            for k in ("id", "state", "label")
        ):
            raise ValueError(f"{filename}:{line_no}: id, state and label must be strings")
        if row["label"] not in route.options:
            raise ValueError(f"{filename}:{line_no}: unknown label")
        if row["id"].strip() in ids or row["state"].strip() in states:
            raise ValueError(f"{filename}:{line_no}: duplicate id or state")
        ids.add(row["id"].strip())
        states.add(row["state"].strip())
        rows.append(row)
    if len(rows) < minimum:
        raise ValueError(f"{filename}: need at least {minimum} rows for this example")
    return rows


calibration = load_rows("calibration.jsonl", minimum=100)
heldout = load_rows("heldout.jsonl")
for field in ("id", "state"):
    if {r[field].strip() for r in calibration} & {r[field].strip() for r in heldout}:
        raise ValueError(f"Calibration and held-out {field} values overlap")
if {r["label"] for r in calibration} != set(route.options):
    raise ValueError("Calibration must cover every route in this example")

artifact = d.calibrate(
    route, [r["state"] for r in calibration],
    [route.options.index(r["label"]) for r in calibration], level="L1",
)
# Exclusive creation prevents accidental overwrite of an existing artifact.
with Path("route-calibration.json").open("x", encoding="utf-8") as f:
    json.dump(artifact, f, ensure_ascii=False, indent=2)

predictions = d.decide_batch(
    [r["state"] for r in heldout], route, level="L1", require="L1",
)
for row, prediction in zip(heldout, predictions):
    print(json.dumps({
        "id": row["id"], "expected": row["label"],
        "predicted": prediction.argmax, "confidence": prediction.confidence,
        "level": prediction.level,
    }, ensure_ascii=False))

El código ajusta con una partición y solo puntúa la otra. No selecciona un umbral de automatización ni envía tickets a ninguna cola. La comprobación de 100 filas es una política de ejemplo, no una afirmación de suficiencia estadística. Rechaza duplicados y entradas compartidas; revisa también fugas temporales o entre clientes, no solo identificadores.

require="L1" impide utilizar silenciosamente un resultado de nivel inferior; confidence es la mayor probabilidad devuelta. Ninguno sustituye a un control de permisos ni garantiza una tasa aceptable de errores de negocio. El objeto incluye además el nivel real y sus diagnósticos. Campos de resultados y nivel mínimo

Para seleccionar un umbral de producción, añade una partición de validación independiente. Fija allí la regla de aceptación y evalúala una vez en el conjunto de prueba intacto. Informa de recuentos aceptados y errores por clase, no únicamente de confianza agregada.

Límites del servidor y los artefactos que pueden invalidar la prueba

El adaptador vLLM tiene dos rutas distintas. Raw, L0 y L1 utilizan un servidor de generación y solicitan max_tokens=1, IDs de tokens permitidos y log-probabilidades. No hay texto libre que interpretar, pero el adaptador sí pide un token: «sin generación» no debe entenderse como ausencia total de trabajo de tokens en cada frontera de API. L2 necesita, en cambio, estados ocultos no normalizados de la última posición desde un servidor de pooling. Adaptador de servicio y contratos de los endpoints

Un endpoint genérico de embeddings no es automáticamente intercambiable con esa interfaz. Un servidor de pooling vLLM ordinario expone la última capa de su checkpoint. Una cabeza ajustada a una capa anterior necesita un checkpoint truncado compatible o un backend que exponga esa capa. Valida conjuntamente identidad del modelo, tokenizador, forma del vector y preprocesamiento.

Para L2, el proyecto ajusta una cabeza lineal por pregunta mediante una solución cerrada; las particiones internas de validación guían la selección de cabeza y capa. Es aprendizaje supervisado aunque no actualice el modelo base por gradientes. Ajustar una pregunta con éxito no valida otra con etiquetas parecidas. Ajuste de cabezas mediante solución cerrada

Dos errores operativos habituales son solicitar L1 antes de cargar o ajustar su artefacto, y ajustar un artefacto pero continuar utilizando la ruta L0 predeterminada. Especifica level y require. Mantén fija la configuración durante la evaluación y registra cada fallback, calentamiento del prior o incompatibilidad de artefacto como evento, no como un cambio invisible de exactitud.

Una prueba de aceptación para un sistema de decisiones real

Recomendamos empezar con una decisión acotada y reversible. Diseña la prueba alrededor del coste de aceptar una decisión equivocada, no de la novedad de la interfaz.

Separa corrección y estabilidad. Mide exactitud por clase, macro F1, desacuerdo al invertir opciones y varias permutaciones no cíclicas. Mantén idéntico el estado del prior en cada comparación. Una respuesta estable puede ser incorrecta; un prior que cambia no demuestra necesariamente un defecto por orden.

Separa confianza y cobertura. Registra NLL, Brier, ECE, error entre decisiones aceptadas y cobertura con un umbral preseleccionado. Examina clases raras y cada idioma utilizado. El contraejemplo de newsgroups explica por qué no basta con optimizar ECE.

Mide costes en la frontera real del sistema. Cuenta prompts, latencia p50/p95, colas, comportamiento de la caché de prefijos y fallbacks. Incluye el servidor del modelo y la revisión humana, no solo la aritmética posterior a los logits. Compara con el router actual y una referencia sencilla basada en reglas.

Mantén los controles de ejecución fuera del clasificador. Limita los candidatos a acciones autorizadas, incluye revisión o abstención y aplica permisos mediante reglas deterministas. Un umbral de confianza no debe autorizar un reembolso, un cambio de cuenta o una orden en producción. Observa la deriva y recalibra antes de ampliar el alcance.

El repositorio sigue situando la evaluación dentro de un agente entre los trabajos futuros. Sus decisiones aisladas no demuestran que un agente completo de producción ya funcione mejor. Alcance del proyecto. Para el despliegue general, consulta nuestra guía de evaluación de LLM y la scorecard para cerrar o escalar un piloto. La economía de los procesos permanece en la guía de ROI de Laya y Jev.

Para el problema distinto de servir un encoder y sus cabezas, consulta la guía de autoalojamiento y caché de acciones de CLM-8B. Allí se explica la reutilización de vectores y la configuración de verificadores; aquí se evalúan calibración y orden de opciones.

Un piloto útil de AnyJev termina con una pregunta versionada, un procesamiento de probabilidades reproducible y un resultado de prueba intacto. Es una base más sólida para automatizar que una respuesta segura de sí misma o una lectura más rápida del siguiente token.

Para implementar el sistema, consulta el servicio de ingeniería de IA de Wavect. El caso Twinsoft AI aporta contexto de entrega separado, no acredita un despliegue de AnyJev. Con decisiones representativas y la lista de QA previa al lanzamiento, podemos definir una integración basada en evaluación.