Presentamos Lapis SAL: modelos bilingües para seleccionar herramientas

Qué presentamos y por qué

Antes de que un asistente pueda consultar el tiempo, crear un recordatorio o buscar información, necesita tomar una decisión: ¿qué herramienta encaja con lo que pide la persona? Y a veces, la respuesta correcta es no utilizar ninguna.

Hoy presentamos Lapis SAL, una familia de modelos de routing bilingüe desarrollada por Lapis Labs. Publicamos un teacher (modelo guía), un student más pequeño que aprende del teacher mediante destilación y una versión del student para MLX. Su tarea es acotada: seleccionar una herramienta a partir de una petición en inglés o español y de las opciones que ofrece el desarrollador.

Separar esa decisión del resto del asistente permite explorar sistemas donde cada modelo tiene una responsabilidad concreta. Es una línea de investigación para futuros desarrollos de Lapis, orientada a asistentes más eficientes y al procesamiento local. Estos modelos no están integrados en la app de Lapis.

Cómo funciona la selección de herramientas

El desarrollador proporciona un menú de herramientas con identificadores y descripciones; también puede añadir ejemplos de cómo se pedirían. SAL compara la petición con esas opciones y devuelve el identificador que mejor encaja, o None si ninguna resulta apropiada. El runtime expone una puntuación calibrada y las puntuaciones de las opciones, incluida la abstención interna.

Un menú podría ofrecer previsiones meteorológicas y gestión del calendario. Ante una pregunta sobre lluvia, el router seleccionaría una opción meteorológica; ante una petición ajena al menú, podría abstenerse. Es un ejemplo del flujo esperado, no una garantía para cualquier formulación.

Seleccionar no es ejecutar. SAL no llama a la herramienta, no extrae sus argumentos ni genera una respuesta conversacional completa. La aplicación que lo utiliza debe encargarse de esos pasos y de los permisos correspondientes.

La adaptación y la evaluación abarcan trece familias de herramientas y la opción de no usar ninguna:

CALCULATOR, CALENDAR, CLOCK, CODE, CONTACTS, HEALTH, LOCATION, MAIL, MAPS, MESSAGES, REMINDERS, WEATHER, WEB_SEARCH, NONE.

Estas son las categorías evaluadas, no un vocabulario de salida cerrado. Los identificadores y las descripciones se suministran en cada aplicación. Añadir herramientas nuevas o cambiar sus descripciones requiere evaluación propia.

Cómo se construyeron y entrenaron

El teacher está basado en Laya / ModernBERT-large y tiene aproximadamente 421 millones de parámetros aprendidos. El student utiliza un encoder Ettin de la familia 150M: su encoder tiene unos 149 millones de parámetros y el modelo completo, con la cabeza de decisión, alcanza aproximadamente 164 millones. El nombre 150M identifica la familia del encoder.

1. Adaptación supervisada. El teacher se ajusta a episodios bilingües de selección de herramientas.
2. Destilación. Sus distribuciones de puntuación sirven como objetivos para entrenar al student, combinadas con las etiquetas correctas.
3. Calibración. Se ajustan las puntuaciones con datos de desarrollo reservados para ese propósito.
4. Exportación y comprobación. Se preparan los backends y se comprueba su comportamiento antes de evaluar el test final.

La fuente de datos es sintética y bilingüe: 10.000 ejemplos, separados en 8.000 de entrenamiento, 1.000 de validación y 1.000 de test final. La preparación genera episodios con menús variables a partir de entrenamiento y validación; el test final permanece separado. Los datos y las etiquetas blandas del teacher no se redistribuyen.

El entorno estaba configurado con 2 × NVIDIA T4 y precisión mixta FP16. El entrenador conservado funciona en un único dispositivo (world_size: 1); esta configuración no demuestra ni implica entrenamiento distribuido entre ambas GPU.

Modelos y formatos disponibles

Los tres repositorios publicados se distribuyen bajo Apache 2.0, conservando los avisos de sus componentes de base. Cada uno contiene su propio checkpoint o backend, tokenizer, runtime e instrucciones. No necesitas descargar toda la familia para ejecutar uno de los modelos.

• Student PyTorch — lapis-sal-150M. Checkpoint FP32 para investigación, nuevos ajustes y conversiones.
• Teacher PyTorch — lapis-sal-421M. Checkpoint FP32 para inferencia del teacher y generación de objetivos para destilación.
• Student MLX — lapis-sal-150M-MLX. Pesos FP16 para inferencia local en macOS con Apple Silicon y GPU Metal.

MLX permite cuantizar capas compatibles a INT8 al cargar. Utiliza el mismo checkpoint FP16: INT8 no es una descarga independiente ni un archivo de pesos de menor tamaño. Las capas no elegibles, como los embeddings, conservan su representación original.

La exportación ONNX se ha validado internamente, pero no está publicada. No forma parte de las descargas de esta presentación.

Los modelos utilizan una arquitectura de decisión personalizada. Debes seguir el runtime incluido y las instrucciones de cada repositorio; cargar solo el encoder o utilizar una función genérica de generación no reproduce el router.

Resultados y límites de la evaluación

Evaluamos un benchmark privado y sintético de 1.000 ejemplos reservados: 500 en inglés y 500 en español. Se ofrecen las trece herramientas y la opción NONE, con preselección desactivada y umbral 0,625. La métrica es la proporción de peticiones dirigidas a la opción correcta.

El checkpoint PyTorch del student no se evaluó por separado en este test final. Los resultados del student mostrados corresponden a las exportaciones MLX FP16 e INT8 al cargar. Que ambas obtengan el mismo porcentaje no prueba equivalencia para todas las entradas posibles.

Estos números describen este benchmark concreto; no garantizan el rendimiento en tráfico real. Las descripciones que se solapan, las peticiones ambiguas o el contexto largo pueden producir errores incluso con puntuaciones altas. El presupuesto total de entrada es de 512 tokens, compartido entre la petición, el menú y el historial que se aporte.

Solo se han evaluado inglés y español. La selección de HEALTH o CODE no valida la calidad de un consejo de salud o del código posterior. Las mediciones de MLX corresponden a macOS con Apple Silicon; no validan el funcionamiento en iPhone o iPad. La licencia de los modelos no concede acceso a los datos privados de entrenamiento y evaluación.

Dónde puede ser útil

SAL puede servir como una capa de selección en asistentes personales con calendario, recordatorios o correo; en automatizaciones que deban elegir entre varios pasos; y en aplicaciones locales que quieran resolver esta decisión en el propio ordenador.

Los checkpoints PyTorch también permiten explorar ajustes para un dominio concreto y nuevas estrategias de destilación. En todos estos casos conviene comprobar la abstención, calibrar el menú con datos representativos y mantener la autorización y ejecución de acciones en la aplicación.

Los próximos pasos para Lapis

Queremos investigar cómo una selección de herramientas acotada puede contribuir a asistentes más eficientes y a más procesamiento local. Los siguientes pasos pasan por ampliar la evaluación con peticiones representativas, estudiar menús de herramientas distintos y explorar posibles usos en futuros desarrollos de Lapis.

Publicar los modelos permite que otros prueben esta propuesta y revisen sus límites. No anunciamos una integración en la app ni una fecha de lanzamiento para ella. Las novedades del producto se documentan por separado en Novedades de Lapis.