Un SLM para tu operación: qué implica de verdad
«Modelo dedicado» se usa hoy para casi cualquier cosa. Esta página explica qué significa técnicamente, qué se hace y qué no, y por qué la especialización importa más que el tamaño en una operación industrial.
Un SLM (small language model) es un modelo de lenguaje que renuncia a ser generalista para especializarse en un dominio acotado. Construir uno dedicado no significa entrenar un transformer desde cero —eso exige datos y cómputo que ninguna operación individual justifica— sino partir de un modelo base adecuado y adaptarlo al dominio. El objetivo no es tener más parámetros: es tener menos conocimiento irrelevante y más contexto de la operación, con un despliegue que la empresa pueda ejecutar por su cuenta.
No es tamaño, es a qué le prestó atención
Sabe un poco de todo: literatura, derecho, cocina. Nada de eso ayuda a leer un parte de guardia, pero sí exige hardware de centro de datos y, por tanto, procesar fuera de la red de la empresa.
Entiende los equipos, las labores, los códigos, los procedimientos, la forma de escribir del personal y las reglas particulares de una operación. Ese conocimiento no está en internet: está en sus documentos.
Ocho decisiones, no un botón de entrenar
Qué combinación se usa depende del caso. Lo que no cambia es que ninguna de estas decisiones se toma sin haber visto los documentos reales de la operación.
Elegir bien el modelo base
La primera decisión no es entrenar, es escoger. Un modelo base adecuado al idioma y al tipo de tarea ahorra la mayor parte del trabajo posterior.
Ajuste fino sobre el dominio
Se adapta el modelo a los documentos, el vocabulario y los formatos de la operación. Técnicas como LoRA permiten hacerlo sin reentrenar el modelo completo ni necesitar un centro de datos.
Recuperación sobre conocimiento propio
Para procedimientos, estándares y manuales no conviene meter el texto en los pesos del modelo: se recupera en el momento de responder. Así el conocimiento se actualiza sin reentrenar.
Herramientas determinísticas
Lo que se puede calcular o validar con una regla, se resuelve con una regla. Un modelo no debería decidir si un horómetro puede retroceder.
Enrutamiento y umbrales
Decidir qué campo resuelve qué modelo, y con cuánta confianza se acepta. Es la diferencia entre un sistema utilizable y una demo.
Cuantización para desplegar
Reducir el tamaño del modelo para que corra con la infraestructura que la operación ya tiene, en vez de exigir hardware nuevo.
Evaluación contra el negocio
No basta una métrica académica. La evaluación útil mide si el campo que importa sale correcto en los documentos de esa operación.
Realimentación humana
Cada corrección de una persona en revisión es material de entrenamiento. Sin este bucle el modelo se estanca el día que se despliega.
Un modelo que sabe cuándo no confiar en sí mismo
Esta es la parte que separa un sistema utilizable de una demo. En MUKI la decisión no depende de un umbral único: cada campo se agrupa en una familia y cada familia tiene sus propias reglas, con excepciones por contexto de trabajo.
Se acepta solo
El campo sale sin revisión adicional. Reservado a familias donde el modelo tiene evidencia suficiente, como valores numéricos y códigos cerrados.
Se acepta con contexto
El modelo por sí solo no basta, pero el dato se confirma cruzándolo con el dispatch, el roster o la memoria del documento.
Va a revisión humana
El campo se marca y espera a una persona. No se ingresa a ciegas: es preferible una fila pendiente a un dato falso en producción.
Se abstiene
El sistema frena y pide validación explícita. Existe porque en minería equivocarse en silencio cuesta más que no responder.
Las familias de campo
Numérico
Horómetros, tonelajes, número de viajes. Admite aceptación autónoma porque el rango válido es verificable.
Código cerrado
Códigos de actividad, labores, materiales. El catálogo es finito, así que el modelo puede resolverlos y las reglas los validan.
Nombre abierto
Nombres de operadores e ingenieros. No admite aceptación autónoma: siempre requiere contexto o una persona. Un apellido mal leído contamina el histórico de forma silenciosa.
Contextual
Campos cuyo valor correcto depende de qué está haciendo el equipo. Se resuelven con el contexto de trabajo, no aislados.
Un detalle que vale más que cualquier porcentaje: la familia de nombres propios no admite aceptación autónoma. Ninguna. Un apellido mal leído no rompe nada visiblemente — contamina el histórico en silencio, y meses después nadie sabe por qué las horas de un operador no cuadran. Por eso siempre pasa por contexto o por una persona.
Lo que no vas a encontrar en esta página
Cifras de precisión ni comparativas de rendimiento. No porque no midamos —medimos por campo y por contexto— sino porque un número medido en una operación no predice el resultado en otra: depende de la calidad de los documentos, de cuán consistente sea el llenado y de qué proporción de campos son de escritura abierta.
Lo que sí se puede medir antes de comprometer un proyecto es cuántos campos llegan legibles, cuántos tienen una fuente contra la cual validarse y cuántos dependen de escritura abierta. Eso se evalúa sobre tus documentos, durante el diagnóstico.
Preguntas frecuentes
¿Un SLM dedicado significa entrenar un modelo desde cero?
No, y casi nunca conviene. Entrenar un transformer desde cero exige volúmenes de datos y de cómputo que ninguna operación minera individual justifica. En la práctica se parte de un modelo base adecuado y se lo adapta al dominio mediante ajuste fino, recuperación de conocimiento propio y herramientas determinísticas para las validaciones críticas. El objetivo no es tener más parámetros: es tener menos conocimiento irrelevante y más contexto de la operación.
¿Qué se necesita para adaptar un modelo a una operación?
Documentos reales en cantidad, incluidos los mal llenados y los que se salen del formato, porque son los que el modelo encontrará en producción. Un criterio de validación contra el cual contrastar lo que extrae. Personal que revise las excepciones al inicio, ya que cada corrección es material de entrenamiento. Y una infraestructura donde alojarlo, que no requiere ser un centro de datos pero sí un servidor que TI acepte administrar.
¿Un modelo pequeño puede correr dentro de la infraestructura de una mina?
Esa es precisamente la razón de usarlo. Un modelo especializado y cuantizado está diseñado para ejecutarse con recursos de cómputo modestos, dentro de la red de la propia empresa. Eso elimina la necesidad de enviar cada documento a la API de un tercero y hace viable operar con conectividad intermitente, que es la norma en una unidad minera.
¿Cómo se decide qué acepta el modelo solo y qué revisa una persona?
Con una política de autonomía declarativa, no con un umbral único. Los campos se agrupan en familias —numérico, código cerrado, nombre abierto y contextual— y cada familia tiene reglas propias. Un campo puede aceptarse solo, aceptarse cruzándolo con contexto como el dispatch, mandarse a revisión humana, o hacer que el sistema se abstenga y pida validación explícita. Los nombres propios, por ejemplo, nunca se aceptan de forma autónoma.
¿Cuánta precisión alcanza un SLM dedicado en reportes mineros?
Depende de la calidad de los documentos, de cuán consistente sea el llenado y de qué campo se mida, así que cualquier cifra general sería engañosa. Lo que sí es medible antes de comprometer un proyecto es cuántos campos llegan legibles, cuántos tienen una fuente contra la cual validarse y cuántos dependen de escritura abierta. Esa evaluación se hace sobre los documentos reales de la operación durante el diagnóstico.
Cuéntanos tu reto operativo
Visitamos tu operación, entendemos el proceso y proponemos una solución ajustada a tu realidad. Sin diagnóstico no hay propuesta.
Solicitar un diagnóstico en campo