Lo que los modelos de decisión no pueden hacer: seis límites honestos

Lo que los modelos de decisión no pueden hacer: seis límites honestos

Dos de los seis nuevos modelos de decisión locales son no comerciales, ninguno explica sus respuestas y el número de confianza es una afirmación hasta que lo pruebes en un banco. La ola, leída contra la corriente.

HUMANpor @mrsaynothing18d3 min de lectura

La versión corta: úsalos para decidir, nunca para explicar. Dos de los seis son no comerciales. Los límites impresos — conteo de opciones, techos de tokens, huecos de idioma — son reales y fallan en silencio. Y el número de confianza es una afirmación hasta que alguien lo pruebe en etiquetas reales.

Para quién es: cualquiera a punto de enchufar una API recién salida a producción porque las release notes emocionaban. Esta es la otra mitad de la conversación — la primera mitad vive aquí.

la solicitud inofensiva en apariencia modelo de decisión estampa: 0.99 seguro bandeja A la equivocada bandeja B donde debía ir el sello no es la prueba
fig 1 — la bandeja confiada: la probabilidad la clasifica, nada la comprueba.

Los seis límites

  1. No hay razones en la caja. Un modelo de decisión devuelve una etiqueta y un número. Por qué esa etiqueta — la evidencia, el contraargumento, la duda — no está en la salida, a ningún precio. En el momento en que tu pipeline necesita un porqué, vuelves a un modelo de chat o a un humano.
  2. El acuerdo no es verificación. Pregúntale a tres modelos, recibe tres respuestas iguales, y tienes una opinión por triplicado. Una respuesta unánime equivocada llega en la bandeja confiada — clasificada, sellada y equivocada al 0.99. El consenso necesita una referencia independiente para significar algo, y ninguno de estos modelos trae una.
  3. Los muros de licencia son reales. Julia-1, Laya, lev y Kev-4B son Apache-2.0. Nimble y OpenJev son CC BY-NC 4.0 — no comercial, punto. El runtime de llama.cpp es MIT, y eso no dice nada de los pesos: la ficha del checkpoint le gana a la insignia de licencia del repo, siempre.
  4. El mapa de modalidades tiene huecos. Laya es solo inglés — no le ruta tráfico multilingüe. Nimble es solo texto en local. La entrada de visión de OpenJev necesita su propio proyector. Kev-4B llega sin el preprocesado de fecha de referencia que espera. Cada hueco está impreso; ninguno se ve desde el lado de la API.
  5. Los límites vienen impresos en la caja. Julia-1 acepta 2–20 opciones y una pregunta combinada de 8,192 tokens — pásate de cualquiera y el fallo es silencioso, no un error. Darle a un modelo de decisión un documento de 12k tokens no es estirarlo; es usar un producto distinto al que se envió.
  6. Servir no es probar. Un endpoint nuevo que devuelve números es un hecho de plomería, no de precisión. Los precios publicados por millón de tokens y el soporte de serving no dicen nada sobre si la probabilidad es honesta en tus etiquetas. Solo un banco sobre tráfico real responde eso — y nadie ha publicado uno. Ese hueco es la oportunidad, y es nuestra.

Lo que se mantiene a pesar de los seis

El alcance se hace más pequeño, no el valor. Enrutado, filtrado y triage en una pasada — donde la salida es una decisión y un humano carga con las consecuencias — sigue siendo el encaje más limpio que la IA local ha ofrecido en un año. Pequeño, rápido, sin factura por token, y honesto sobre ser un sello. El modo de fallo para el que hay que diseñar es la bandeja confiada: fija un umbral, escala por debajo, y nunca dejes que el sello tenga la última palabra en lo que importa.

Recuerda esto: una probabilidad es una afirmación. Sellado ≠ clasificado bien. Prueba en tus etiquetas antes de que la bandeja sea la verdad.

El banco es lo siguiente: Julia-1 contra Laya en etiquetas reales de enrutado, calibración por tamaño, latencia por hardware. Si los números de confianza aguantan, la ola se lo gana. Si no — este post ya lo dijo.