Saltar al contenido principal

Evaluación de modelos en tu infraestructura

Tienes tu propio nodo de IA, pero ¿es lo que necesitas?

Esa pregunta lleva meses sin respuesta mientras el nodo lleva meses trabajando. Y si aún no lo has montado, es la que se responde antes de la orden de compra, no después. Construimos las pruebas sobre tu trabajo real, fijamos contigo el criterio, medimos de extremo a extremo sobre tu infraestructura y entregamos un dictamen con la evidencia y con las acciones repartidas: las de tu nodo y las nuestras. Y si prefieres no montarlo tú, lo elegimos, lo montamos y te lo entregamos con la medición ya hecha sobre tus casos.

El problema

«Va bastante bien» no es un estado.

Cuando una respuesta sale mal, hay cuatro causas posibles y ninguna se ve desde fuera. Sin separarlas, cada reunión sobre el nodo es una discusión de impresiones, y la impresión que acaba ganando es la del que habla más alto.

El modelo

No da para esa tarea, y ninguna configuración lo va a arreglar.

La cuantización

El modelo daría, pero no con los bits por peso con los que está cargado.

El nodo

Una bandera de arranque, un tamaño de contexto o un tokenizador mal declarado.

La capa de acceso

Un temporizador, un límite declarado o un presupuesto de salida que el nodo no puede cumplir.

Si todavía no lo has montado, el problema es el mismo un paso antes: vas a elegir esas cuatro cosas a la vez, comprometiendo dinero y plazo, sin un número que diga cuál de ellas es la que decide el resultado.

Y hay una quinta posibilidad, que es la peor de todas: que acierte casi siempre y falle en un sitio concreto, siempre el mismo, con una cifra lo bastante creíble como para que nadie la mire dos veces.

La prueba, antes que el argumento

Un aprobado y una liquidación mal calculada, en la misma medición.

Esto es nuestro propio nodo: un modelo MoE de pesos abiertos, sobre nuestro hardware. Medido el 12 de septiembre de 2026: tres expedientes, cinco intentos por expediente, todo por la misma capa de acceso por la que pasa el trabajo real, y 50 minutos de nodo dedicado de principio a fin. El modelo, el nodo y la fecha quedan registrados juntos a propósito: sin los tres, la nota no se puede volver a sacar.

Modelo MoE de pesos abiertos · nodo propio · 12 de septiembre de 2026 · 5 intentos por expediente · 50 minutos de medición
ExpedienteNotaCifra devueltaCifra correctaDesviaciónIntentos idénticos
Sucesión · reparto de una herencia100,0078.731,75 €78.731,75 €0,00 €5 de 5
Declaración de la renta25,003.872,79 €3.724,79 €148,00 €5 de 5
Finiquito por despido improcedente100,0064.506,70 €64.506,70 €0,00 €5 de 5
Agregado75,00 · aptoumbral 70error medio 49,33 €ejecución completa y estable

148,00 euros sobre 3.724,79. Un 4 %. No es una cifra absurda: es una cifra creíble, y por eso nadie la habría detectado leyendo la respuesta. El modelo la devolvió idéntica en los cinco intentos, así que tampoco la habría detectado repitiendo la consulta. Y la nota agregada (75,00 sobre un umbral de 70) la habría dado por buena.

El fallo está localizado, no intuido. De las seis comprobaciones de trazabilidad del expediente, cinco pasan: acierta el tope del plan de pensiones, la ganancia neta de la venta de acciones y las retenciones, y declara explícitamente fuera del cálculo el gasto que no es deducible. Falla una sola, la del rendimiento del alquiler reducido, que es exactamente donde el caso esconde sus tres trampas de gasto. Se equivoca en un sitio, y siempre en el mismo.

Una demostración habría enseñado la sucesión y el finiquito. Habría durado diez minutos, habría salido bien y no habría sido falsa: habría sido incompleta, que en una decisión es peor. Un piloto sin criterio de aceptación fijado de antemano produce exactamente ese resultado, y por eso siempre sale bien.

Podemos enseñar esta medición entera porque la carga es nuestra. No es el expediente de ningún cliente, así que no hay nada que anonimizar ni ninguna cifra que recortar.

Cómo funciona

Cinco pasos. Los dos primeros no necesitan hardware.

Esa es la parte que suele sorprender: el criterio con el que se va a juzgar el nodo se puede construir antes de que exista el nodo. De ahí salen las tres formas de entrar de la sección siguiente.

  1. Las pruebas, sobre tu trabajo

    Se escriben los casos a partir de expedientes reales tuyos (el trabajo general y el específico de tus equipos) y se calcula la respuesta correcta a mano, antes de que ningún modelo los vea.

    Sin hardware
  2. El criterio, fijado por ti

    Qué nota es suficiente, y por qué esa. Con el suelo medido (qué saca quien no hace nada) y con el techo medido contra un modelo de proveedor, para que el número signifique algo. Y antes de la orden de compra.

    Sin hardware
  3. La medición, sobre tu infraestructura

    De extremo a extremo, por la misma capa de acceso por la que pasará el trabajo real: sobre la infraestructura que ya tienes, o sobre la que montamos nosotros. Cinco intentos por caso, y el registro completo de cada ejecución.

  4. El dictamen

    Una frase que cierra la pregunta, la evidencia debajo, y las acciones repartidas por ámbito: las que ejecuta tu equipo en el nodo y las que ejecutamos nosotros en la capa de acceso.

  5. La iteración

    Se repite la medición tras cada cambio, hasta alcanzar el criterio o hasta poder decirte, con el registro delante, que con ese modelo y ese hardware no se alcanza.

Por dónde entras

Tres formas de recorrerlo. En la tercera no lo recorres tú.

Lo que cambia entre la segunda y la tercera no es la comodidad: es quién elige las variables. Si eliges tú el modelo, la cuantización y la máquina, nosotros medimos lo que haya y te decimos qué sale. Si elegimos nosotros, respondemos del resultado, y eso solo se puede prometer cuando se controla lo que se promete.

Montar un entorno así llave en mano no nos distingue: hay quien lo hace y lo publica con sus fases y sus precios. Lo distinto es qué viaja con la entrega: una nota sobre tus propios expedientes, obtenida con un instrumento cuyo suelo está medido y cuyos fallos están publicados.

Y una honestidad sobre el dimensionamiento: elegir la máquina es una estimación hasta que se mide. Por eso el orden es ese, las pruebas antes que la compra, y por eso la entrega va condicionada a la medición y no a que el pedido haya llegado.

A partir de la entrega, la operas tú o la operamos nosotros. Es una decisión aparte, y se toma cuando toca.

El método

Un número con fecha, versión y procedimiento.

La pregunta «¿lo hace bien?» no tiene respuesta, porque le falta el término de comparación. La que sí la tiene es: ¿este modelo, aquí dentro, resuelve este trabajo tan bien como el que usarías si no lo tuvieras? Estas son las seis reglas que convierten esa pregunta en una cifra.

La parte incómoda

Un instrumento que nadie ha intentado romper no es un instrumento: es una opinión con decimales.

Es la objeción razonable, y conviene decirla en voz alta: una prueba diseñada por quien va a venderte el arreglo puede dar el resultado que le convenga. No se responde con argumentos. Se responde enseñando lo que le hemos hecho al instrumento.

Esa es la disciplina entera: separar en todo momento lo que mide al modelo de lo que mide al instrumento, y no dar por bueno ningún arreglo que no se haya comprobado en los dos sentidos.

El compromiso

Tres cosas se comprometen. Una de ellas, no.

Si estás eligiendo con quién montar esto, vas a oír que te garantizan resultado, plazo y coste. Conviene separarlos, porque solo dos de los tres se pueden sostener y el tercero es la señal más fiable que tienes para descartar proveedores.

Y una consecuencia que conviene decir entera: si la medición contradice la decisión, el informe lo va a decir. Con el registro al lado, y en el primer entregable, no en el tercero.

Esta es la iteración, con cifras. Entre las dos mediciones cambió la configuración del nodo y los temporizadores de la capa de acceso. Ni el modelo, ni el hardware, ni las pruebas.

Qué pasa entre dos mediciones · mismo nodo, mismo modelo, mismas pruebas
Medida11 de septiembre de 202612 de septiembre de 2026
Expedientes medidos1 de 33 de 3
Duración de la mediciónmás de tres horas50 minutos
Latencia mediana573 s172 s
Razonamiento interno (mediana)4.657 tokens de 6.212638 tokens de 2.701
Estado de la ejecuciónincompletacompleta y estable

El expediente que no se podía medir pasó a medirse, y ahí es donde apareció el error de 148,00 €. Ese es el orden real de las cosas: primero el nodo tiene que poder responder, y solo entonces se puede hablar de si acierta. Confundir las dos preguntas es lo que hace que un equipo pase meses ajustando una configuración para arreglar un problema que estaba en el modelo, o al revés.

Con una advertencia que va en el informe y no en la letra pequeña: recortar el razonamiento interno de un modelo baja su latencia y puede bajar también su nota. Si baja, la decisión deja de ser técnica y pasa a ser tuya: un modelo que necesita nueve minutos para un expediente de 3.500 tokens puede no tener sitio en tu proceso, y eso es un resultado legítimo de la medición, no un fallo que arreglar.

El entregable

Un dictamen, la evidencia debajo, y el trabajo repartido por quién lo ejecuta.

El informe abre con una frase que cierra la pregunta. El de nuestro propio nodo, fechado el 11 de septiembre de 2026, abría con esta: «falla por tiempo, no por tamaño». Debajo, la aritmética que la sostiene: la entrada de los tres expedientes cabía treinta y cinco veces en el límite declarado, así que el tamaño no intervenía; el nodo escribe a 10,88 tokens por segundo y la capa de acceso esperaba 600 segundos como mucho, así que ninguna respuesta de más de 6.528 tokens podía completarse nunca. Un expediente pasó con 29 segundos de margen; los otros dos no. La velocidad del nodo no es un defecto (es un dato físico) y el tope de 600 segundos tampoco lo es (es una decisión razonable para una capa de acceso). El defecto era que nadie había comparado los dos números.

Y a continuación lo que hace que el informe se pueda usar en lugar de discutirse: el reparto. Trece hallazgos, seis en el nodo y siete en la capa de acceso, cada uno con su evidencia, su esfuerzo estimado y su criterio de éxito. Del nodo salieron tres acciones; el resto era contexto que explicaba los números, no trabajo pendiente. Un dictamen que reparte culpa no se ejecuta; uno que reparte trabajo, sí.

El informe incluye además los arreglos que no hay que hacer, que suelen ser los tres primeros que se le ocurren a cualquiera. Subir el límite de entrada declarado rompe una protección que funciona: el nodo no da error cuando se pasa, recorta en silencio y responde igual, y el resultado es una nota alta construida sobre documentos mutilados (creíble, presentable y falsa). Recortar el presupuesto de salida hasta que la prueba pase la pone en verde sin arreglar nada y rompe la comparabilidad con todo lo demás. Y ampliar el contexto del servidor reduce la velocidad de escritura, que era justo el problema.

  • Dictamen · una frase, y la magnitud que la sostiene
  • Evidencia · el registro de cada ejecución, con el modelo que había detrás, la ventana declarada, la versión de los casos y la máquina
  • Acciones del nodo · las que ejecuta tu equipo, con su esfuerzo y su criterio de éxito
  • Acciones de la capa de acceso · las que ejecutamos nosotros, con el mismo detalle
  • Descartes · lo que parece la solución y no lo es, con el motivo

Para quién no es

Cuatro casos en los que te lo diremos en la primera llamada.

Los límites

Decir esto es parte del método.

  • No mide el conocimiento del modelo sobre normativa real. Mide su lectura de un expediente. Todos los tipos, tramos y límites viajan con el enunciado y son ficticios a propósito, para que la prueba siga siendo comparable entre entornos y entre fechas.
  • No ejecuta el código que genera. Un requisito puede estar cumplido en el fichero y la página comportarse mal en un navegador. Se lee el fichero, entre otras cosas porque ejecutar código generado por un modelo dentro de tu perímetro es precisamente lo que no se quiere hacer.
  • No dice todavía a partir de qué tamaño de contexto un modelo deja de acertar. Los casos tienen un tamaño fijo. La curva de calidad frente a contexto es un trabajo distinto y está pendiente.
  • No ordena entre sí a dos modelos que ya resuelven los casos enteros. Certifica que se llega al nivel de referencia, no por cuánto se pasa. Para una decisión de perímetro eso basta; para un ranking, no sirve.
  • No sustituye la validación sobre tu carga real. Los casos publicados son expedientes simulados: se parecen al trabajo, no son el trabajo. Un número obtenido con ellos orienta una decisión; los casos escritos sobre tus expedientes son los que la cierran.
  • No estamos certificados en ISO 27001. Si tu pliego o tu auditoría lo exigen del proveedor, dilo en la primera llamada y te ahorramos el ciclo.

Con quién trabajas

Quien firma el dictamen es quien ha roto el instrumento cuatro veces.

Kairos Tek son dos socios. Uno lleva más de veinticinco años dirigiendo tecnología y producto, y ha asesorado a Europol, la Comisión Europea y el Banco de España. El otro lleva veinticinco programando y ha sido CTO en más de ocho empresas, construyendo y operando sistemas en producción. Entre ellos y tú no hay ninguna capa de gestión, porque no hay nadie más.

Eso importa aquí por una razón concreta y no por la de siempre: el dictamen que recibes reparte trabajo entre tu equipo y el nuestro, y quien lo escribe tiene que haber operado las dos mitades. Un informe que solo entiende una de ellas acaba adjudicando a la otra todo lo que no sabe explicar.

Conoce al equipo →

Empieza por saber qué nota saca hoy.

Y si todavía no lo has montado: ¿qué nota le vas a exigir? Una hora basta para saber si hay caso. Llevamos una agenda concreta: qué expedientes procesas, qué cifra tiene que salir de ellos, y qué nota considerarías suficiente. Si al final de esa hora la respuesta es que no hay caso, te lo decimos ahí.

El documento del método lleva las seis pruebas una a una, las trampas que persigue cada caso con la cifra que produce cada una, el suelo medido, el control negativo y los cuatro defectos del instrumento con su fecha. Se descarga sin dejar datos.