Saltar al contenido principal

Modelos propios

Un modelo que ha aprendido tu forma de trabajar.

Un buen prompt le explica a un modelo ajeno, cada vez de nuevo, cómo se trabaja en tu casa. Un modelo propio ya lo ha aprendido. Entrenamos un modelo base abierto con tu conocimiento — el conjunto de datos es tuyo y sobrevive a cualquier cambio de modelo.

La diferencia

Explicar, consultar o saber.

Hay tres sitios donde puede vivir una regla. Solo el tercero sobrevive a un cambio de modelo.

En el prompt

vale hasta la próxima ventana

En los pesos

vale sin que nadie lo escriba

En la memoria

vale si alguien lo busca

El conjunto de datos es el activo, no el modelo

Un modelo entrenado envejece, como todos. El conjunto de datos del que salió, no. Cuando llegue un modelo base mejor, entrenamos de nuevo desde el mismo conjunto. Por eso es tuyo, por escrito.

Tus datos nunca entran en un modelo compartido

Cada cliente tiene su propio entrenamiento y sus propios pesos. No existe un modelo de StudioMeyer montado con los datos de todos. No es un ajuste, es la arquitectura.

Sin dependencia de proveedor

El modelo base tiene licencia abierta, el resultado corre en tu hardware o en tu cloud. No nos necesitas para operarlo. Nos necesitas si quieres seguir desarrollándolo.

Dónde encaja

La mayoría de las veces no necesitas entrenar.

El finetuning es para la forma, no para los hechos. Hay cuatro peldaños, y cada uno entra en juego solo cuando el anterior ha fallado de forma medible, no por intuición.

  1. 1

    Prompt

    La regla está en la instrucción. No cuesta nada, se cambia al instante, vale hasta la siguiente ventana de contexto.

  2. 2

    Memoria

    El conocimiento que cambia va aquí: precios, existencias, historial de clientes. Consultar en lugar de memorizar.

  3. 3

    Entrenamiento

    Solo cuando la forma, el vocabulario técnico o las tool calls fallan de forma reproducible. Entonces el comportamiento pasa a los pesos.

  4. 4

    Destilación

    Un modelo grande le enseña a uno pequeño cómo responder. Para cuando tiene que funcionar pequeño, rápido y barato.

Primero comprobamos si un buen prompt y una memoria bastan. En la mayoría de los casos bastan, y entonces lo decimos, en lugar de vender una ejecución de entrenamiento.

Cuatro caminos

Dónde aterriza una regla decide si aguanta.

No toda regla pertenece a los pesos. Algunas están bien en el prompt, otras en la memoria, otras necesitan una barrera dura fuera del modelo. Eso lo ordenamos antes del primer entrenamiento.

Conocimiento

Lo que sabe tu negocio: productos, lógica de precios, casos especiales, los nombres que solo significan algo en tu casa. Hoy eso vive en un manual al lado del modelo y se envía con cada consulta.

Tras el entrenamiento el modelo lo sabe. Las respuestas son más cortas, más rápidas y menos dependientes de si se encontró el pasaje correcto.

Procesos

Cómo se trabaja en tu casa: en qué orden, con qué pasos intermedios, cuándo alguien tiene que dar el visto bueno. Escrito como reglamento se hace más largo de lo que ayuda.

Como secuencia aprendida ya no necesita lista. El modelo lo hace como se hizo en tus ejemplos.

Comportamiento

Cómo responde: tono, longitud, límites. Qué no se puede prometer nunca. Cuándo preguntar en vez de adivinar. Justo la parte del manual que primero se ignora.

Entrenar comportamiento significa preferir y rechazar ejemplos, no escribir reglas. Lo que tiene que aguantar siempre lo aseguramos además fuera del modelo.

Conexión con robots

Para el sistema, un robot es otro cliente que llama herramientas — como una ventana de chat, solo que con brazos. La interfaz es la misma que ya construimos para conectores y sistemas.

El robot se va algún día, el conocimiento aprendido sobre tu negocio se queda. Por eso lo construimos al lado del robot, no dentro.

Con franqueza

Qué resuelve un entrenamiento y qué no.

Esto sí lo resuelve

  • Un esquema de salida exacto

    El mismo formulario, la misma estructura JSON, diez mil veces, sin desviaciones.

  • Vocabulario técnico estrecho

    Lenguaje del sector, abreviaturas internas, normas, sin que nadie las reexplique en cada llamada.

  • Voz de marca

    Consistente, sin un prompt de tres páginas antes de cada respuesta.

  • Tool calls fiables en modelos pequeños

    En la práctica el punto más importante: los modelos pequeños solo aciertan las tool calls de forma fiable después de un entrenamiento.

Esto no lo resuelve

  • Conocimiento nuevo o cambiante

    Precios, existencias y citas van en la memoria, no en los pesos. Lo que cambia se consulta.

  • Pequeño no se vuelve listo

    Un modelo pequeño se vuelve más estrecho y más fiable, no más inteligente. Quien afirme que un entrenamiento convierte un modelo de 8B en uno de primera línea está vendiendo algo falso.

  • Aprender tiene efectos secundarios

    Un modelo olvida en otro sitio cuando aprende algo nuevo. Se contrarresta con mezcla de datos, pero hay que saberlo.

  • Sin un test set aparte nadie sabe nada

    Sin ejemplos reservados no se puede decir si una ejecución mejoró algo o lo rompió. Aquí es donde fracasan la mayoría de los proyectos.

Con qué

Con qué lo construimos.

Modelos abiertos, métodos trazables, nada secreto. Quien conoce el stack puede comprobar cada cifra.

Modelo base
Un modelo con licencia abierta que permite trabajo derivado comercial (Apache 2.0). La elección sigue la tarea y el hardware, no la moda.
QLoRA + SFT
Nuestro caso estándar, cubre alrededor del 95 por ciento de los proyectos: formato de salida, vocabulario técnico, voz y tool calls. Entrenamos un adaptador, no el modelo completo. Eso hace las ejecuciones asequibles y permite varias especializaciones sobre una base.
DPO / SimPO
Etapa dos, cuando el entrenamiento supervisado ya está firme. Se afina con pares según el patrón «A es mejor que B». El comportamiento sale de esta etapa, no de la primera.
GRPO / DAPO
Aprendizaje por refuerzo con recompensa verificable, en nuestro caso para el orquestador. Solo merece la pena cuando la corrección es medible por máquina. Con las tool calls lo es exactamente.
Hardware propio o GPU alquilada
La ejecución pasa donde los datos pueden estar. En local para datos sensibles, si no en GPUs alquiladas que se borran después.
Evaluación
Comprobado contra un conjunto de prueba de tu trabajo real antes de entregar, no contra un benchmark de papel. Ningún resultado sin comparación con el modelo sin entrenar.

Cómo se hace

Ocho pasos.

  1. 01

    Definir el comportamiento objetivo y construir primero el test set

    Antes de la primera línea de datos de entrenamiento va la pregunta: ¿cómo sabremos que ha funcionado? Un conjunto de ejemplos se aparta y no se toca nunca durante el entrenamiento.

  2. 02

    Comprobar si funciona sin entrenamiento

    El prompt y la memoria se miden contra ese mismo test set. Si basta, el proyecto termina aquí, a tu favor.

  3. 03

    Construir el conjunto de datos

    El punto más honesto de esta página: en proyectos de empresa, entre el 30 y el 50 por ciento del coste total es pura preparación de datos. Los ejemplos salen de la operativa real, llevan origen y fecha, y se versionan como código fuente.

  4. 04

    Elegir el método y el modelo base

    Para alrededor del 95 por ciento de los casos, QLoRA con fine-tuning supervisado. El modelo en sí queda intacto; se aprende en pequeñas matrices adicionales. El resultado es un archivo de unos cientos de megabytes, no un modelo nuevo.

  5. 05

    Entrenar con cómputo alquilado

    No hace falta hardware propio. La tarjeta se alquila por horas y se apaga después.

  6. 06

    Medir contra el test set apartado

    Antes y después, con cifras. Sin intuiciones, sin «parece mejor».

  7. 07

    Desplegar

    Un modelo base sostiene varios especialistas a la vez, cada uno como su propio archivo pequeño. En lugar de cinco modelos de 20 GB, funciona un modelo con cinco complementos.

  8. 08

    Mantener

    Cuando llega una nueva generación de modelos, se entrena un complemento nuevo a partir del mismo conjunto de datos. Justo por eso el conjunto de datos es el activo y no el modelo.

FAQ

Preguntas frecuentes

¿Por qué no simplemente escribir un mejor prompt?

Porque un prompt se aplica de nuevo en cada consulta y termina con la ventana de contexto. Para muchas tareas eso basta, y entonces es justo lo que recomendamos. Un modelo propio compensa cuando la misma explicación se envía mil veces, o cuando una regla tiene que aguantar aunque nadie la escriba.

¿Es un modelo propio si entrenáis uno existente?

Es propio en el sentido de que los pesos son tuyos y salieron de tus datos. No es un modelo construido desde cero — eso no lo hace nadie con un presupuesto razonable, y quien lo afirme te está vendiendo otra cosa. La licencia del modelo base permite el trabajo derivado comercial de forma explícita.

¿Nuestros datos acaban en un modelo que usan otros?

No. Cada cliente tiene su propia ejecución y sus propios pesos. No hay un modelo compartido hecho con datos de clientes — no como promesa, sino porque no lo construimos así.

¿Cuánto cuesta?

El precio sigue el tamaño del conjunto de datos, no el tiempo de cómputo. El cómputo es la partida menor. Lo que cuesta tiempo es ordenar y preparar tu material, y eso solo lo vemos cuando lo hemos mirado.

¿Cómo sabemos que esto funciona?

Ejecutamos el método en nuestro propio orquestador, el sistema detrás de la estación IA. Lo que construimos para ti funciona antes en nuestra propia operación. Y se mide contra tu propio test set, no contra un benchmark de papel: sin comparación con el modelo sin entrenar no entregamos.

¿Y qué pasa con n8n y la automatización de workflows?

Lo seguimos construyendo cuando un proceso lo necesita. Ya no lo vendemos como oferta propia: hoy cualquiera se monta un vigilante de correo en ChatGPT en treinta segundos. Lo que allí no se puede hacer es un sistema que conozca tu negocio — de eso va esta página.

Siguiente paso

¿Qué explicación envías cada día?

Cuéntanos qué tiene que aprender tu modelo cada vez. Te diremos con honestidad si eso pertenece al entrenamiento o a un mejor prompt.