Ajuste fino frente a prompting: cuándo especializar un SLM

Por qué el debate entre ajuste fino y prompting confunde a los equipos de producto

Cuatro aspectos que la gente confunde en una sola pregunta

Los equipos suelen preguntar "¿SLM o LLM?" como si eso resolviera el producto. No es así. Se mezclan cuatro decisiones distintas:

Puedes usar prompting en un LLM privado. Puedes realizar un ajuste fino y seguir llamando a una API pública para las partes abiertas. El alojamiento y la especialización son independientes. Confundirlos es la razón por la que los equipos en sectores regulados pierden un trimestre esperando GPUs cuando el verdadero obstáculo era la falta de un índice documental.

Para saber cómo los equipos mantienen bajo control la elección del modelo y el gasto una vez que el tráfico está activo, consulta qué es una puerta de enlace LLM (https://www.truefoundry.com/blog/llm-gateway). La cuestión de la puerta de enlace surge una vez que sabes en qué fase te encuentras.

Las tres fases que realmente ayudan

Una vez que separas esas cuatro decisiones, la hoja de ruta se reduce a tres fases:

1. Aprendizaje: modelo alojado, conjunto de evaluación, registro. Valida el flujo de trabajo antes de hacerte cargo de un modelo.
2. Fundamentación: recuperación, herramientas, esquemas. Proporciona pruebas al modelo en lugar de modificar sus pesos.
3. Especialización: ajusta un modelo pequeño en un ámbito limitado una vez superadas las fases previas. No todo el asistente.

La mayoría de las propuestas de "necesitamos un SLM" son en realidad problemas de Aprendizaje o Fundamentación disfrazados con lenguaje de Especialización.

Hemos creado un asistente para resolver el dilema entre ajuste fino y prompting (https://benchmark-accelerators.ml.tfy-eo.truefoundry.cloud/fine-tuning-vs-slm) basado en este enfoque. Responde a unas cuantas preguntas sobre el producto y obtendrás un diagnóstico, las fases bloqueadas frente a las actuales y un memorando listo para copiar y pegar. Usamos siempre el mismo criterio para que los responsables de producto, ingeniería y seguridad hablen sobre la misma base.

----------------------------------------

Qué evaluar antes de realizar un ajuste fino

Requisitos previos antes de especializar

El entusiasmo de los desarrolladores es importante. Las demostraciones de los proveedores, menos. Ninguna de las dos cosas sustituye a los requisitos previos.

1. Define la tarea, no el modelo

¿Se trata de triaje de tickets, extracción de campos, preguntas y respuestas sobre documentos, chat abierto o un agente de varios pasos?

El trabajo cerrado o sujeto a un esquema puede especializarse más adelante. Los asistentes de final abierto y los agentes de programación casi nunca deberían ajustarse primero. Si puedes separar una subtarea específica (clasificar y luego redactar), especializa solo esa parte.

2. Decide la ruta de los datos antes que el tamaño del modelo

Los datos internos o de bajo riesgo pueden empezar en una API pública con la revisión habitual del proveedor. La información de identificación personal (PII) de los clientes requiere una revisión de privacidad. Los datos regulados (PHI, residencia financiera, entornos aislados) obligan a usar una VPC o una infraestructura local.

Esa decisión depende del alojamiento. Por sí sola, no permite el ajuste fino. Para gestionar el gasto y la latencia a medida que aumenta el volumen, la optimización de costes de LLM (https://www.truefoundry.com/blog/llm-cost-optimization) es una conversación paralela, no un sustituto de las etiquetas.

3. Cuenta las etiquetas de calidad, no los volcados de tickets

Los tickets históricos y los registros de chat no son un conjunto de entrenamiento hasta que alguien marca la salida correcta. Volcar un CSV en LoRA solo sirve, en la mayoría de los casos, para memorizar ruido.

‍