Experiencia · Modelos IA personalizados
El trabajo tiene cuatro partes: medimos los modelos candidatos con tus datos, elegimos entre configuración, búsqueda en documentos y ajuste fino, verificamos los derechos de uso de los datos, y luego ponemos el consumo bajo presupuesto por clave. No hemos entrenado hasta ahora ningún modelo en producción y lo decimos antes de que preguntes.
Ya construidoLa parte de medición y operación está construida y en ejecución, con resultados guardados: un banco de pruebas propio que comparó ocho sistemas de reconocimiento de voz sobre las mismas 200 frases en rumano, con intervalo de confianza y diferencias por pares, además de una descomposición de la latencia vocal en seis segmentos que suman el total con una desviación inferior a un milisegundo. La parte de operación es un gateway propio con 44 modelos configurados, claves por proyecto con lista blanca de modelos y presupuesto, y una consolidación diaria del consumo por usuario × clave × modelo. La parte que NO hemos hecho — el ajuste fino propiamente dicho — está escrita tal cual: la tubería está preparada y calculada, pero nunca ha corrido en GPU. El servicio sigue siendo «entregado» porque el trabajo que vendemos es la elección informada y la operación, no el entrenamiento.
La mayoría de los proyectos de “modelo personalizado” no necesitan un modelo entrenado. Necesitan el modelo adecuado, con la instrucción adecuada, sobre los datos adecuados, con un coste por llamada que alguien siga. El trabajo empieza con la pregunta que pocos hacen: cómo se ve el éxito, medido cómo, sobre qué conjunto de casos. Sin esa respuesta, cualquier comparación de modelos es una discusión de gustos.
Medimos nosotros, no tomamos las cifras de los proveedores. Cuando necesitábamos saber qué reconoce mejor el rumano hablado, ejecutamos ocho sistemas sobre las mismas 200 frases, con el mismo normalizador, con intervalo de confianza por bootstrap y con diferencias calculadas por pares. Los resultados fueron incómodos: el sistema que usábamos en producción tenía una tasa de error por palabra del 26,26%, y un modelo pequeño, de 110 millones de parámetros, ejecutado en procesador, tenía un 6,83%. Publicamos también la parte desagradable — en la exactitud en rumano perdemos por mucha diferencia frente a los proveedores comerciales.
La segunda parte del trabajo es la elección entre tres caminos que a menudo se confunden: la configuración del modelo (instrucción, herramientas, parámetros), la búsqueda en tus documentos, y el ajuste fino. El orden en que los probamos no es una preferencia, es economía: los dos primeros son reversibles en una tarde, el tercero requiere datos, derechos, GPU y una medición antes y después. Recomendamos el ajuste fino solo cuando tenemos la prueba de que los dos primeros no bastan.
La tercera parte, la que queda después de lanzar: el coste por llamada. Los modelos pasan por un gateway propio, donde cada clave tiene lista blanca de modelos, presupuesto y periodo. El consumo se consolida diariamente por usuario, clave y modelo, lo que significa que la pregunta “por qué ha subido la factura este mes” tiene respuesta por filas, no por suposiciones.
Qué incluye
Un conjunto de casos de tu realidad, un criterio numérico y un método de normalización fijados por escrito. Para voz usamos la tasa de error por palabra con normalizador propio; para respuestas de texto, la conformidad con el esquema más una verificación de sentido común más la semejanza con una respuesta de referencia. Sin este paso, el resto del trabajo no lo puede verificar nadie.
Las mismas frases, la misma máquina, un solo modelo cargado cada vez, cada uno en su propio proceso. Informamos intervalo de confianza por bootstrap y diferencias por pares, no solo la media — porque dos modelos pueden tener medias distintas y aun así estar empatados estadísticamente. Tuvimos exactamente ese caso: dos sistemas en 66 de 66 comparaciones por pares, es decir, empate, aunque la tabla de medias sugería un ganador.
En un recorrido vocal medimos seis segmentos por separado — la decisión de turno, el reconocimiento de voz, la puerta, el tiempo hasta el primer texto del modelo, el primer bloque de síntesis, la cola y el transporte. La comprobación que importa: la suma de los seis da el tiempo total hasta el primer sonido con una desviación inferior a un milisegundo en cada turno válido. De ahí se ve dónde está el problema: en el caso medido, el 68,7% del tiempo era la espera del primer texto del modelo, no el reconocimiento de voz, que tomaba el 2,9%.
La búsqueda en documentos está implementada y en funcionamiento: búsqueda híbrida, 70% semántica y 30% coincidencia de palabras, umbral de similitud 0,70, cinco fragmentos por pregunta, con un registro por consulta que conserva las puntuaciones y los tiempos. El ajuste fino lo proponemos solo con prueba de que los dos primeros no bastan — y con el presupuesto y los derechos sobre la mesa antes, no después.
No es una formalidad, es lo que detiene proyectos. Un corpus de 1.746 horas de rumano que habíamos tomado en cuenta resultó tener licencia no comercial, así que era inutilizable para un modelo comercial. Un conjunto de 270.946 ejemplos tenía el código bajo una licencia permisiva, pero los datos sin ninguna licencia declarada. Y la política de uso de un proveedor de voz prohíbe explícitamente entrenar un modelo con su salida. Cada fuente se verifica en su propia página, no en lo que dice un artículo.
Gateway propio con 44 modelos configurados, cada uno con coste por token y límite de contexto en la configuración. La clave del proyecto tiene lista blanca de modelos, presupuesto y periodo, y se puede rotar conservando el historial. El consumo se consolida diariamente por usuario × clave × modelo. El enrutamiento usa la estrategia «el menos ocupado», dos reintentos y un tiempo máximo de 120 segundos.
Los modelos de tipo razonamiento producen pasos internos que la plataforma de seguimiento del coste no ve, pero el proveedor los factura. La consecuencia práctica: el presupuesto bruto fijado por clave debe ser menor que el techo deseado, dividido por un factor de razonamiento. Si no haces esa corrección, la clave parece estar dentro del presupuesto y la factura no lo está.
Tenemos funcional una cadena local: reconocimiento del habla con un modelo de 0,6 mil millones de parámetros en procesador y síntesis de voz con un modelo de 99 millones de parámetros, también local. En un producto de monitorización radiofónica, la transcripción se hace localmente, y la variante por gateway existe en paralelo; así que la comparación entre local y alojado está hecha, no supuesta. Lo que sale de la máquina es texto, no audio.
Un banco de regresión semanal sobre casos fijos, que compara la conformidad con el esquema, pasa una prueba de sentido común y mide la similitud con las respuestas de referencia. Un modelo que cambia bajo ti —y cambia— se ve en la tabla, no en las reclamaciones de los clientes.
Qué aspecto tiene
Los casos vienen de tu realidad, no de un conjunto de prueba general. Se fija el criterio numérico, el método de normalización y el umbral a partir del cual el resultado es aceptable. Entregamos: el conjunto de casos, el criterio escrito y el script que lo calcula.
Los modelos candidatos se ejecutan sobre datos idénticos, con intervalo de confianza. Entregamos: la tabla con todos los sistemas probados, incluidos los rechazados y el motivo, más el comando exacto de reproducción. Un modelo que rechazamos para rumano tuvo una tasa de error del 99,69% porque derivaba al italiano; el rumano no estaba entre sus lenguas declaradas. Ese resultado está en la tabla.
Configuración, búsqueda en documentos o ajuste fino, con el motivo, el coste y lo que se pierde al elegir. Entregamos: la decisión argumentada, más la medición que la respalda. Si la recomendación es «no entrenamos nada», lo escribimos igual de explícitamente.
La clave del proyecto se emite con presupuesto, periodo y lista de modelos permitidos, con la corrección para los tokens de razonamiento aplicada. Entregamos: la clave, el panel de consumo y el umbral a partir del cual alguien recibe una alerta.
Los mismos casos, el mismo criterio, sobre el modelo en producción. Entregamos: la comparación antes/después y la lista de cambios con el motivo de cada uno. Un banco de regresión recurrente detecta los cambios de comportamiento del modelo del proveedor.
Los datos
Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.
Un caso
La situación
Teníamos un sistema de reconocimiento de voz en funcionamiento para rumano y una pregunta abierta: ¿es el mejor disponible o solo el primero que integramos? No existía ninguna medición propia, solo cifras publicadas por proveedores, medidas en otras lenguas y otros conjuntos.
Qué construimos
Construimos un banco: 200 enunciados en rumano de un conjunto público, la misma semilla para la selección, 35,1 minutos de audio, el mismo normalizador para todos los sistemas, intervalo de confianza mediante bootstrap, diferencias calculadas por pares. Ocho sistemas, cada uno cargado por separado, en su propio proceso, en la misma máquina. Escribimos en el informe tanto la configuración de la máquina como el comando exacto de reproducción.
Qué salió
El sistema en producción tenía una tasa de error por palabra del 26,26%. Un modelo de 110 millones de parámetros, ejecutado en procesador con un modelo de lenguaje al lado, tenía 6,83%. Un modelo muy elogiado salió con 99,69%, porque se deslizaba al italiano —el rumano no estaba entre sus lenguas declaradas. Y dos sistemas que parecían distintos por la media quedaron estadísticamente empatados en la comparación por pares. Publicamos toda la tabla, incluida la fila que contradijo nuestra elección.
Qué no dice el caso
La medición se hizo en un conjunto público de lectura, no en conversaciones telefónicas reales, con ruido y solapamientos. Un buen resultado en este conjunto no garantiza el mismo resultado por teléfono. Por eso, para un cliente, el banco de pruebas se reconstruye con sus grabaciones; de lo contrario medimos algo distinto de lo que le interesa.
Preguntas
No. Ningún modelo ajustado fino o entrenado por nosotros está en producción y no existe ningún punto de control guardado en nuestros repositorios. Lo que sí tenemos: la canalización de entrenamiento escrita hasta el comando exacto de arranque de la máquina con GPU, el presupuesto calculado en tres escenarios, los datos preparados y las licencias verificadas — y una lista escrita con lo que debe decidirse antes de la primera ejecución. Preferimos decir eso antes que vender una competencia que no hemos ejercido.
Porque el trabajo que da el resultado en la mayoría de los casos no es el entrenamiento. Es saber qué modelo hace el trabajo en tus datos, con qué latencia y a qué coste por llamada — y eso requiere una medición que casi nadie hace. Un ejemplo de nuestro trabajo: un solo valor por defecto incorrecto en una configuración de modelo (una penalización de repetición ajustada a 1,2 en lugar de 1,0) costó 4,3 puntos porcentuales de error. No hizo falta entrenamiento, sino medición.
Empieza con la búsqueda en documentos, casi siempre. Es reversible, se actualiza cambiando un archivo y puede mostrar la fuente de la respuesta. El ajuste fino cambia el comportamiento del modelo de formas que no puedes inspeccionar, requiere datos etiquetados, derechos de uso y una medición antes y después. Recomendamos el ajuste fino cuando tenemos la prueba de que la primera variante no basta — por ejemplo, cuando demostramos que un modelo offline no se convierte en un modelo en flujo solo por configuración: al estrechar la ventana de atención sin reentrenamiento, el error subió de 8,81% a 22,26% y luego a 48,95%.
No, y ningún proveedor honesto puede, porque la precisión depende de tus datos. Lo que garantizamos es el método: medimos en tus casos, mostramos el intervalo de confianza y decimos cuándo la diferencia entre dos opciones no es estadísticamente significativa. Tuvimos un caso en el que un resultado publicado por los autores de un modelo no se reprodujo con nosotros — ellos reportaban 20,70%, nosotros medimos 26,68% en el mismo modelo. Escribimos que no sabíamos por qué, en lugar de elegir la cifra conveniente.
Depende del camino elegido y es una decisión, no un accidente. A través del gateway, la solicitud llega al proveedor del modelo. Si eso no es aceptable, tenemos el canal local funcionando: reconocimiento de voz y síntesis vocal ejecutados en tu máquina, donde de la máquina sale solo texto, nunca audio. En un producto de monitorización radio, la transcripción local y la transcripción a través del gateway están implementadas ambas, así que el compromiso entre ellas lo podemos mostrar con cifras.
Pasa. Por eso el trabajo incluye un banco de regresión con casos fijos, ejecutado periódicamente, que compara la conformidad con el esquema, pasa una prueba de sentido común y mide la similitud con las respuestas de referencia. Y por eso la integración pasa por el gateway: el modelo se cambia en un campo, no reescribiendo el código.
La clave del proyecto tiene lista blanca de modelos, presupuesto y periodo, y se puede rotar manteniendo el historial. El consumo se consolida diariamente por usuario, clave y modelo. Una trampa que corregimos desde el inicio: los modelos de razonamiento producen pasos internos que el sistema de seguimiento no ve, pero el proveedor los factura — así que el presupuesto bruto de la clave se configura más bajo que el techo deseado, dividido por un factor de razonamiento. Quien no hace la corrección ve la clave en el presupuesto y la factura por encima.
Porque «público» y «utilizable comercialmente» son cosas diferentes, y la diferencia se descubre tarde y caro. Tres ejemplos de nuestras verificaciones: un gran corpus de rumano, licenciado no comercialmente, así que excluido para un producto comercial; un conjunto de cientos de miles de ejemplos con código bajo licencia permisiva pero datos sin ninguna licencia declarada; y la política de uso de un proveedor de voz, que prohíbe explícitamente entrenar un modelo con su salida. La verificación se hace en la página de la fuente, no en lo que repite un artículo.
No entrena hoy modelos fundacionales y no promete un modelo propio en producción. No garantiza porcentajes de mejora. No compara un modelo con la competencia basándose en cifras publicadas por la competencia — si no hemos ejecutado nosotros la comparación, decimos que es una cifra declarada por ellos, no una medida por nosotros.
26 de ellas son código y archivos de nuestros repositorios. No publicamos su nombre ni la línea: juntos, en una sola página, describirían con demasiada precisión cómo están construidos sistemas que no son solo nuestros. Los repasamos contigo, en el repositorio, a petición — la verificación sigue siendo posible, solo que se hace en una conversación.
Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.