Inicio / Artículos

Destilación con etiquetas suaves para un agente SQL de 0.8B: por qué ganó un modelo maestro Qwen más débil

El ajuste fino de LoRA con etiquetas suaves top-k extraídas de registros congelados permitió que un agente SQL de 0.8B lograra resolver 55 de las 220 tareas, y un modelo Qwen menos potente superó al modelo GPT más fuerte.

Editor: REACTAPP.TOP20 min de lectura4637 palabras

Fuentes: Small-Model Distillation — Part 2: Off-Policy Soft-Label KD for a 0.8B SQL Agent

La versión breve

En una ejecución anterior, un agente SQL de 0.8B pasó de resolver 1 tarea de un total de 220 a 46, al hacer que copiara, uno por uno, los tokens de un modelo “maestro” más grande. Esta vez solo hay un cambio: ¿qué ocurre si el estudiante también ve parte de la incertidumbre del maestro, y no solo el token que terminó eligiendo? Todo lo demás permanece igual: el marco de trabajo, la evaluación de las 220 tareas, el esquema de acciones, el estudiante de 0.8B y la configuración de ajuste fino con LoRA. Solo el señal de aprendizaje cambia.

Se volvieron a calcular las puntuaciones de las huellas congeladas del maestro. En cada posición se guardaron las 20 probabilidades de token más altas, junto con una pequeña cantidad restante que representaba todo lo demás. Luego se comparó el entrenamiento tradicional con tokens ponderados con la destilación de etiquetas suaves tipo top-k. La mejor ejecución resolvió 55 de las 220 tareas, frente a 46 para el estudiante con tokens duros y 49 para una ejecución combinada con tokens duros.

La cifra principal no es la parte más interesante. Las etiquetas suaves empeoraron las cosas en dos de las ocho pruebas con una sola fuente. Tampoco el mejor profesor fue el más fuerte. Qwen, un modelo más débil de la misma familia con una puntuación de 96/220, se ajustó mucho más fielmente a sus propias huellas que el modelo GPT más potente (115/220), por lo que sus probabilidades ofrecieron al estudiante una lección más clara. La verdadera ventaja surgió al combinar las dos fuentes.

Hay una advertencia desde el principio: las probabilidades de tokens del propio GPT nunca estuvieron disponibles. Las huellas de GPT aquí fueron evaluadas por Qwen, lo que las convierte en un indicador aproximado y no en una verdadera destilación de logit de GPT.

Qué se estaba probando

El objetivo general es mejorar la capacidad de los modelos pequeños para tareas específicas. El agente es el mismo agente de reparación de SQL de antes. Recibe un problema del usuario junto con un código SQL defectuoso, puede inspeccionar una base de datos SQLite, ejecutar consultas de prueba, leer los resultados y enviar el SQL corregido. La puntuación proviene de pruebas deterministas ocultas, sin la participación de un modelo de lenguaje grande como juez.

La ejecución anterior con tokens fijos ya había demostrado que un modelo pequeño puede operar este ciclo. El modelo base sin ajustar repetía principalmente las acciones y nunca enviaba nada. Después del entrenamiento con tokens fijos, inspeccionaba, realizaba consultas y enviaba resultados con mucha más frecuencia.

El entrenamiento con tokens difíciles es un método rudimentario. Se le pide al estudiante que reproduzca cualquier token que haya escrito el profesor, sin ninguna indicación sobre cuán seguro estaba el profesor, qué más consideró, o si la segunda mejor opción era casi tan buena. En SQL, esa información faltante puede ser importante en los nombres de tablas y columnas, predicados, uniones, valores literales y la sintaxis de las acciones estructuradas.

La pregunta, entonces, era si la destilación de etiquetas suaves top-k mejora al mismo agente de 0.8B cuando los registros de seguimiento y las pruebas de referencia se mantienen fijos.

Se compararon dos puntos de partida. Uno era el modelo base unsloth/Qwen3.5-0.8B. El otro era el adaptador de tokens difíciles de Qwen3.5-0.8B, entrenado anteriormente con trayectorias exitosas de Qwen3.5-35B-A3B 8-bit. En otras palabras: ¿debería el entrenamiento con etiquetas suaves comenzar desde cero, o continuar a partir del estudiante de tokens difíciles?

La tarea del agente SQL

La configuración coincide con la ejecución anterior con tokens fijos. Cada tarea incluye un problema del usuario, una consulta con errores y una base de datos SQLite. El modelo elige entre acciones estructuradas: inspeccionar el esquema, ejecutar SQL o enviar el SQL final. Una tarea solo se considera resuelta si el SQL enviado pasa las pruebas ocultas.

Una tarea típica, pequeña pero real: en la base de datos chinook, el usuario desea obtener el track_id más reciente y luego usarlo para filtrar filas de la tabla track. La consulta con errores es:

WITH vars AS (SELECT COUNT(*) AS vars_id FROM track)
SELECT * FROM track WHERE track_id = vars_id

El defecto no tiene nada que ver con el formato. COUNT(*) no representa el ID más reciente, y se necesita una solución similar a MAX(track_id). El modelo debe resolver esto dentro de un bucle de herramientas: quizás inspeccionar el esquema, ejecutar una prueba, leer la observación y, finalmente, enviar SQL en el formato estructurado exacto que acepta el sistema.

BAML, abreviatura de Boundary Markup Language, sigue envolviendo la instrucción como capa de salida estructurada. Determina la forma de una decisión y reúne la solicitud enviada al modelo. El texto libre escrito por el instructor nunca forma parte de los datos de entrenamiento del estudiante; lo que aprende son decisiones en formato JSON canónico, compuestas por un breve draft y una acción output ejecutable.

{"draft":"Need schema first.","output":{"action":"inspect_schema"}}
{"draft":"Test a candidate query.","output":{"action":"run_sql_query","sql":"SELECT ..."}}
{"draft":"Submit corrected SQL.","output":{"action":"submit_sql","sql":["SELECT ..."]}}

Cada evaluación reutilizó la configuración de la ejecución anterior, por lo que la señal de entrenamiento fue lo único que cambió. Hay dos configuraciones que merecen mención especial. El límite de secuencia de 8192 representa el presupuesto total para el prompt y la generación en conjunto: el prompt del sistema, la tarea, las acciones anteriores, el esquema, los resultados de la consulta, las instrucciones de salida estructurada y la reserva para la generación comparten este límite. El número máximo de tokens generados se indica por separado, ya que limita una sola llamada al modelo. El estudiante puede leer un estado extenso, pero aún debe emitir una acción compacta por turno. Los resultados se informan a través de los resultados en la terminal y métricas de comportamiento como las entregas, las entregas incorrectas, los errores SQL, las interrupciones por acciones repetidas y las interrupciones por número máximo de turnos.

Los mejores estudiantes no fracasan principalmente en JSON. Llegan a submit_sql sin problemas. La parte difícil es el juicio en SQL y recuperarse cuando una prueba no tiene buen resultado.

La idea de entrenamiento

La destilación de tokens duros proporciona al estudiante un único token objetivo por posición. En cambio, la destilación de etiquetas suaves ofrece una pequeña distribución de probabilidades. Supongamos que el objetivo del profesor contiene un token de tabla como en ... FROM users .... El entrenamiento duro indica que el siguiente token es users. El entrenamiento con etiquetas suaves también puede indicar qué probabilidad asignó el profesor a un par de alternativas cercanas. El token elegido sigue contando, pero el estudiante también ve que algunas alternativas estaban más cerca que otras.

Almacenar las probabilidades de todo el vocabulario es costoso para un modelo de lenguaje grande. Un vocabulario puede contener cientos de miles de tokens, y cada decisión del profesor abarca muchas posiciones objetivo del asistente. El compromiso práctico fue una versión esparsa: las 20 probabilidades más altas del profesor por posición objetivo del asistente, más la masa residual para todos los demás tokens.

¿Por qué mantener la cola? Digamos que las 20 probabilidades más altas guardadas suman 0,996. Los 0,004 restantes siguen perteneciendo a la distribución del profesor, y elevar esas 20 probabilidades a 1,0 daría al estudiante un objetivo que lo haga demasiado confiado. Por eso el objetivo se diseña intencionadamente para recordar que existe alguna masa fuera de lo que se ha guardado.

El enfoque sigue siendo fuera de política. El estudiante aprende a partir de las huellas recopiladas anteriormente y nunca actúa mientras se realizan las evaluaciones.

Un breve recorrido por el código

La forma más sencilla de seguir este método es seguir una fila a través del proceso. No se creó un nuevo entorno de agente para las etiquetas suaves. Se reutilizaron las mismas decisiones exitosas del profesor tomadas durante la ejecución de la trayectoria con tokens duros, se presentaron con la misma estructura de prompt en BAML y luego se enriquecieron con información de probabilidad sobre los tokens objetivo del asistente.

Aquí se muestra una fila de ajuste fino supervisado con tokens fijos (SFT). El SFT consiste en entrenar con pares de entrada-salida en los que solo los tokens de respuesta contribuyen a la pérdida:

row = {
    "messages": conversation_before_teacher_decision + [
        {"role": "assistant", "content": canonical_decision_json(teacher_decision)}
    ],
    "teacher_draft": teacher_decision.draft,
    "teacher_action": teacher_decision.output,
}

Una fila de etiqueta suave mantiene los mismos mensajes canónicos y metadatos del profesor, y obtiene puntuaciones de tokens impuestas por el profesor en las posiciones objetivo del asistente. “Forzamiento por parte del profesor” aquí significa entregar el texto objetivo conocido al modelo de probabilidad y preguntar, token por token, cuán probable es ese texto teniendo en cuenta su contexto. Se almacenan probabilidades logarítmicas en lugar de probabilidades brutas, ya que son numéricamente más seguras para ser escritas y utilizadas en el entrenamiento:

row = {
    "messages": [..., {"role": "assistant", "content": target_decision_json}],
    "distillation": {
        "probability_model": "Qwen3.5-35B-A3B 8-bit",
        "top_k": 20,
        "row_weight": 1.18,
        "token_scores": [
            {
                "position": 1661,              # full-sequence token position
                "target_token_id": 412,
                "target_logprob": -0.21,
                "top_token_ids": [412, 879, 91],
                "top_logprobs": [-0.21, -2.81, -3.51],
                "top_mass": 0.90,
                "tail_mass": 0.10,
            }
        ],
    },
}

La función de puntuación tiene una única tarea: tomar una fila congelada y aplicarle probabilidades de token. Al puntuador Qwen3.5-35B-A3B de 8 bits nunca se le pide que genere una nueva decisión. El prompt se procesa sin la respuesta del asistente, la secuencia completa se procesa con ella, y la parte objetivo se puntuación token por token:

prompt = chat_template(messages[:-1], add_generation_prompt=True)
full = chat_template(messages, add_generation_prompt=False)
prompt_ids = tokenize(prompt)
full_ids = tokenize(full)
target_ids = full_ids[len(prompt_ids):]
prefill_teacher_cache(prompt_ids[:-1])
driver_ids = [prompt_ids[-1]] + target_ids[:-1]
for i, target_id in enumerate(target_ids):
    logits = qwen_35b(driver_ids[i]).logits
    logprobs = log_softmax(logits)
    top_ids, top_logprobs = top_k(logprobs, k=20)
    save_token_score(
        position=len(prompt_ids) + i,
        target_token_id=target_id,
        target_logprob=logprobs[target_id],
        top_token_ids=top_ids,
        top_logprobs=top_logprobs,
        tail_mass=1.0 - sum(exp(top_logprobs)),
    )

El enmascaramiento exclusivo para el asistente no cambia respecto a la ejecución con tokens fijos. Los tokens de la instrucción constituyen el contexto, mientras que los tokens de destino del asistente sirven como supervisión. Esto es más importante para un agente que para la simple respuesta a preguntas, ya que la instrucción contiene observaciones del esquema, resultados anteriores de herramientas y resultados SQL. Dichos tokens existen para ser utilizados como condición, nunca para ser predichos:

labels = full_ids.copy()
labels[: len(prompt_ids)] = -100
hard_ce = cross_entropy(student_logits, labels)

El entrenamiento también requiere más tensores que el SFT ordinario. Un lote contiene input_ids, attention_mask y labels enmascarados como de costumbre, y además incluye un peso para cada posición, los identificadores de los tokens de top-k con sus probabilidades logarítmicas, una máscara sobre esos k espacios y las probabilidades restantes del extremo. El relleno inserta valores neutros en los espacios inactivos, de modo que la función de pérdida los ignora sin problemas:

batch = {
    "input_ids": pad(input_ids, pad_id),
    "attention_mask": pad(attention_mask, 0),
    "labels": pad(labels, -100),
    "position_weights": pad(position_weights, 0.0),
    "topk_token_ids": pad(topk_token_ids, [0] * top_k),
    "topk_logprobs": pad(topk_logprobs, [0.0] * top_k),
    "topk_mask": pad(topk_mask, [False] * top_k),
    "tail_probs": pad(tail_probs, 0.0),
}

La condición de control es el ajuste fino con tokens duros ponderados. Un token seleccionado sigue siendo el objetivo, pero la entropía cruzada de los tokens asistentes se multiplica por un peso de confianza tomado de la probabilidad de registro del evaluador para dicho objetivo. Una opción fácil para el evaluador puede tener un peso mayor, mientras que una poco probable puede tener un peso menor:

z = (mean_target_logprob - dataset_mean_logprob) / dataset_logprob_std
row_weight = clip(2 / (1 + exp(-z)), 0.25, 1.75)
loss = row_weight * hard_ce

El recorte a [0.25, 1.75] impide que una sola fila impar domine un lote, mientras que las filas fiables pueden seguir superando con creces a las poco confiables.

En el caso de las etiquetas suaves, se añade un término de coincidencia de probabilidades a la función de pérdida. Lo que sigue es un esbozo de su forma y no el código de implementación exacto:

teacher_top_probs = exp(top_logprobs) * topk_mask
teacher_top_probs *= (1.0 - tail_mass) / sum(teacher_top_probs)
student_logprobs = log_softmax(student_logits_at_target_positions)
student_top_logprobs = gather(student_logprobs, topk_token_ids)
student_tail_prob = 1.0 - sum(exp(student_top_logprobs))
topk_kl = sum(teacher_top_probs * (log(teacher_top_probs) - student_top_logprobs))
tail_kl = tail_mass * (log(tail_mass) - log(student_tail_prob))
loss = hard_ce + topk_kl + tail_kl

La información fluye del profesor al estudiante: la distribución del profesor es el objetivo del estudiante, y se aplica una penalización cuando se asigna una probabilidad demasiado baja a esa masa. En el entrenador real, tanto la entropía cruzada como la destilación se calculan únicamente sobre posiciones de objetivo del asistente desplazadas.

El entrenamiento actual del estudiante sigue siendo un ajuste fino con LoRA. LoRA, o adaptación de rango bajo, mantiene el modelo base en su mayor parte congelado y añade pequeñas matrices adaptadoras entrenables a módulos de atención y MLP seleccionados. Esto hace que sea económico comparar muchas ejecuciones sin tener que ajustar finamente el modelo de 0.8B cada vez.

student = load_student("unsloth/Qwen3.5-0.8B", max_seq_length=4096)
student = add_lora_adapters(
    student,
    rank=32,
    alpha=32,
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj",
    ],
)
trainer_class = make_trainer_class(Trainer, soft_label_args)
trainer = trainer_class(
    model=student,
    train_dataset=scored_train_examples,
    eval_dataset=scored_validation_examples,
    data_collator=distillation_collator,
    batch_size=1,
    gradient_accumulation_steps=8,
    learning_rate=5e-5,
    epochs=3,
)
trainer.train()
adapter = save_lora_adapter(student)

La implementación real sigue este patrón: make_trainer_class devuelve una subclase de Trainer de Hugging Face que aplica la pérdida dispersa top-k guardada más la pérdida residual de cola. Observe cómo esto difiere del DistillationTrainer en línea de TRL, en el cual la evaluación del modelo maestro se realiza dentro del propio entrenador. Las tres ponderaciones de etiquetas suaves se mantuvieron en 1.0: entropía cruzada dura, destilación y temperatura. La temperatura se dejó en su valor original a propósito, ya que los artefactos dispersos se definieron con un valor de 1.0 y no era el objetivo realizar un estudio de escalamiento de temperatura.

La evaluación al final es un despliegue real y no un método de imposición por parte del modelo maestro. El adaptador entrenado vuelve al entorno del SQL-agent y debe resolver las 220 tareas reservadas, actuando una vez por turno:

for task in held_out_eval_tasks:
    state = start_sql_agent_task(task)
    for turn in range(8):
        messages = render_baml_messages(state)
        decision = model_with_adapter.generate_action(
            messages,
            max_new_tokens=512,
            temperature=0.0,
        )
        state = execute_action_and_append_observation(state, decision)
        if state.solved or state.stopped:
            break
    results.append(score_final_submission(state))

Muchas ideas de destilación sin conexión fallan en este último paso. La prueba impuesta por el profesor verifica si el estudiante puede predecir qué hará el profesor a continuación en un contexto creado por él. Una prueba de implementación comprueba si el estudiante puede aceptar sus propias decisiones anteriores, elegir preguntas útiles, evitar repeticiones y enviar SQL correcto. Solo el segundo número es importante aquí.

Cómo se lleva a cabo el experimento

Podría parecer fácil interpretarlo como destilación on-policy, pero no lo es. Nada de lo que genera el estudiante es evaluado. Solo aprende, posteriormente, a partir de las pistas que el profesor ya había creado.

Los datos provienen de una evaluación basada en rastros congelados y exitosos. Las acciones del profesor ya existen, y el modelo de probabilidad solo determina qué tan probable es que aparezca cada token elegido dada la contextualización. Nunca genera una decisión nueva. Los dos conjuntos de datos evaluados se mantuvieron separados (rastros de GPT evaluados por Qwen, rastros de Qwen evaluados por Qwen), y cada uno se filtró según la longitud de toda la secuencia generada, ya que las observaciones del esquema y las salidas anteriores de las herramientas forman parte de lo que el estudiante debe asimilar, y no solo la respuesta final. Límite: los rastros de GPT se consideran evaluados como si fueran por Qwen-proxy y no se evaluaron con las propias probabilidades de GPT, además de que el estudiante nunca interviene durante el proceso de evaluación.

Se aplicaron tres variantes de entrenamiento a los datos evaluados:

  • Ajuste fino de tokens duros ponderados (el control). Se elige un token por posición, siendo cada fila ponderada según la confianza del evaluador. Se trata de un SFT con un control de confianza. Límite: esto no es destilación de etiquetas suaves, ya que el estudiante ve el peso y nunca la distribución top-k.
  • Destilación de etiquetas suaves top-k (el método bajo prueba). El mismo objetivo duro más una segunda señal que pide al estudiante que distribuya la probabilidad entre las top-k alternativas que vio el evaluador, reservando la masa restante para todo lo demás. Límite: es fuera de política y es forzado por un instructor sobre rastros congelados, y el instructor nunca evalúa las propias muestras del estudiante.
  • Una combinación de fuentes de los profesores y del modelo. Las filas de GPT-proxy y Qwen-self se unen, se mezclan y se utilizan para entrenar al modelo estudiante base de ambas maneras. Límite: mezcla los datos entre los profesores en lugar de fusionar sus distribuciones en una sola, y cada fila mantiene el evaluador que la generó.
  • Mezclar las fuentes da el resultado más claro y menos confuso: huellas exitosas más variadas además de un objetivo por token más rico, lo que proporciona al pequeño modelo base más material para aprender que cualquiera de las fuentes por separado.

    Conjunto de datos y filtrado

    Las huellas de los profesores no se regeneraron intencionadamente. Se congelaron a partir de la ejecución con tokens difíciles para que la comparación se centrara en la señal de supervisión y no en una nueva ronda de generación de datos.

    En esa ronda de la generación anterior, ambos modelos procesaron las mismas 879 tareas de entrenamiento. GPT 5.5 medium acertó 446 de las 879, lo que generó 1046 filas de SFT. Qwen3.5-35B-A3B 8-bit acertó 394 y produjo 1232 filas, ya que sus rastros exitosos fueron más largos. En la evaluación con 220 tareas, GPT 5.5 medium fue más fuerte, con 115 aciertos frente a 96 del otro modelo; por lo tanto, el enfoque con Qwen aquí es un test dentro de la misma familia de modelos y no representa al modelo con el mejor rendimiento.

    La advertencia sobre el uso de proxies es relevante. Para obtener etiquetas precisas de GPT 5.5 medium se necesitarían las probabilidades de tokens propias de ese modelo, las cuales no estaban disponibles. Así que el experimento con rastros de GPT plantea una pregunta más específica: ¿agrega algo útil un modelo Qwen de la misma familia a las acciones elegidas por GPT?

    Para cada fila, se generó la prompt de BAML que realmente utilizó el harness. Luego, el objetivo del asistente conocido se aplicó por medio de Qwen3.5-35B-A3B; solo se almacenaron las puntuaciones de tokens en 8 bits para las posiciones del objetivo del asistente.

    Antes de cualquier entrenamiento, es necesario verificar dos aspectos de los datos puntuados: qué proporción de ellos cabe dentro de un límite de 4096 tokens y hasta qué punto el puntuador de Qwen coincide con cada fuente de datos. Una menor probabilidad logarítmica negativa es mejor, ya que indica que el modelo de probabilidades considera que las acciones objetivo son más fáciles de explicar. Por eso los datos auto-puntuados por Qwen difieren tanto de los datos puntuados de forma indirecta por GPT: Qwen tenía mucha más confianza en sus propios registros que en los del GPT 5.5 medium. La probabilidad logarítmica negativa promedio para las filas auto-puntuadas por Qwen fue de 0.297, mientras que para las filas puntuadas de forma indirecta por GPT fue de 0.876. El token objetivo se encontraba entre los 20 mejores almacenados en el 100.00% de las posiciones auto-puntuadas por Qwen y en el 98.56% de las posiciones puntuadas de forma indirecta por GPT.

    El conjunto fusionado comenzó con 2278 filas. Después del filtro de 4096 tokens, quedaron 2253, divididos en 2141 para entrenamiento y 112 para validación. Una semilla fija barajó las filas antes de la división, de modo que el conjunto de validación no reflejara el orden de las fuentes originales.

    Configuración de entrenamiento

    Ocho ejecuciones formaron la matriz principal, que representaba una combinación completa de tres opciones binarias: qué fuente de seguimiento utilizar (proxy GPT o Qwen propio), qué método aplicar (etiquetas ponderadas duras o suaves) y qué tipo de inicio para el estudiante (inicio en caliente básico o con tokens duros). Otras dos ejecuciones, ambas con el modelo base y ambas utilizando los datos combinados, una con etiquetas ponderadas duras y otra con etiquetas suaves, dieron como resultado diez estudiantes entrenados en total. Se excluyeron las ejecuciones de inicio en caliente combinado. Las primeras ocho demostraron que los inicios en caliente dependían en gran medida de la fuente de seguimiento, mientras que las ejecuciones combinadas tenían como objetivo responder a una pregunta más simple: ¿ayuda mezclar instructores a partir del modelo base?

    Los hiperparámetros de entrenamiento siguieron la línea de base de trayectoria de tokens duros. Los adaptadores utilizaron LoRA con un rango de 32 y un valor de alpha de 32 en las proyecciones de atención (q_proj, k_proj, v_proj, o_proj) y en las proyecciones de MLP (gate_proj, up_proj, down_proj). Otras configuraciones: una tasa de aprendizaje de 5e-5, un lote por dispositivo de 1 con 8 pasos de acumulación, tres épocas, formato bf16 en una GPU NVIDIA, algoritmo Unsloth y FlashAttention 2 siempre que estuviera disponible. Las demás configuraciones fueron una división de validación del 5%, uso de packing off, semilla 42 y un límite de 4096 tokens en las secuencias de entrenamiento completas.

    Para las etiquetas suaves, la temperatura fue de 1.0, con pesos de 1.0 tanto en la entropía cruzada dura como en el proceso de destilación. El código mantiene la masa top-k almacenada junto con la masa residual del extremo, una solución numérica sencilla para probabilidades que se serializaron de forma dispersa.

    Los tamaños de las ejecuciones no fueron idénticos. Las ejecuciones con puntuación proxy de GPT se entrenaron con 990 filas, las de Qwen con puntuación propia con 1151, y las combinadas con 2141. Con un tamaño de lote de 1 y 8 pasos de acumulación, tres épocas resultaron en 372, 432 y 804 actualizaciones del optimizador respectivamente. En las etiquetas de las ejecuciones, Base se refiere al modelo unsloth/Qwen3.5-0.8B sin ajustar, GPT proxy indica las huellas provenientes de GPT 5.5 medium evaluadas por Qwen3.5-35B-A3B 8-bit, Qwen self significa que las huellas del modelo Qwen fueron evaluadas por sí mismo, y Combined corresponde a los conjuntos de puntuaciones combinados antes del entrenamiento.

    Tenga cuidado con las pérdidas de validación. Estas tienen sentido dentro de un único objetivo, pero las ejecuciones con etiquetas duras ponderadas y etiquetas suaves no pueden compararse entre sí porque sus pérdidas incluyen términos diferentes. La menor pérdida de validación correspondió a la ejecución ponderada-dura autoevaluada de Qwen base, que resolvió solo 40 de 220 problemas, mientras que el mejor resultado provino de la ejecución combinada con etiquetas suaves, a pesar de su mayor pérdida.

    La preparación y el entrenamiento se realizaron en hardware diferente. Una máquina con mucha memoria resultó útil para cargar y evaluar localmente a Qwen3.5-35B-A3B en formato de 8 bits; sin embargo, la evaluación forzada por un instructor tomó aproximadamente 60 minutos para los resultados de GPT y 41 minutos para los de Qwen. Los estudiantes entrenaron utilizando la GPU de NVIDIA. Esas ejecuciones de fuente única, con tiempos de ejecución registrados, duraron entre 23 y 30 minutos cada una, mientras que las ejecuciones combinadas más extensas tardaron alrededor de 52 minutos (con etiquetas duras ponderadas) y 55 minutos (con etiquetas suaves).

    Resultados, organizados por pregunta

    Un primer gráfico intentó mostrarlo todo a la vez y confundió dos preguntas distintas: qué ocurre cuando el entrenamiento comienza desde el modelo base y qué ocurre cuando continúa a partir del modelo de trayectoria de tokens difíciles. Por lo tanto, los resultados se dividieron según la pregunta de investigación.

    Para dar una idea de la escala, los profesores y puntos de referencia en la evaluación fija de 220 tareas fueron: sin ajuste fino 1/220, el estudiante con tokens difíciles 46/220, Qwen como profesor 96/220 y GPT como profesor 115/220. El objetivo del experimento con etiquetas suaves top-k nunca fue superar a los profesores, sino determinar si una señal de supervisión más rica podía impulsar al estudiante de 0,8 mil millones de parámetros aún más bajo las mismas condiciones.

    Partiendo del modelo base. Todas las ejecuciones entrenadas superaron al modelo sin ajustar, que obtuvo 1/220. El entrenamiento exclusivo con GPT y el exclusivo con Qwen arrojaron resultados similares, resolviendo entre 41 y 43 tareas según el método utilizado. La combinación de ambos enfoques generó una mayor diferencia: la ejecución con tokens duros ponderados combinados obtuvo 49/220, mientras que la ejecución con etiquetas suaves top-k combinadas logró 55/220, lo que representa aproximadamente una cuarta parte de las tareas. Aunque son cifras modestas en términos absolutos y están lejos de los 115/220 del mejor modelo de referencia, lo interesante es ver hasta dónde puede llegar un modelo de 0.8B partiendo de casi cero, y no tanto igualar al modelo de referencia. Para comenzar con un modelo base, la conclusión es aprovechar ambos enfoques, siendo las etiquetas suaves superiores a los tokens duros ponderados en esos datos combinados.

    Continuando con el estudiante de tokens duros. Aquí la situación no es tan clara. El punto de control ya había resuelto 46/220. Más entrenamiento con rastros de GPT y tokens duros ponderados lo llevó a 48/220, mientras que las etiquetas suaves en esos mismos rastros lo hicieron descender a 44/220. En los rastros autoevaluados por Qwen, el patrón se invirtió: los tokens duros ponderados bajaron a 38/220, y las etiquetas suaves subieron a 49/220.

    El hallazgo inesperado: las etiquetas suaves solo ayudaron cuando el evaluador y el rastro estaban de acuerdo. Qwen3.5-35B-A3B 8-bit fue el profesor más débil, con un resultado de 96/220 frente a los 115/220 de GPT; sin embargo, sus probabilidades se ajustaban a sus propios rastros, y las etiquetas suaves funcionaron allí (49/220), mientras que perjudicaron en los rastros de GPT evaluados de forma indirecta (44/220). La coincidencia entre evaluador y rastro tuvo más peso que la fuerza bruta del profesor.

    Qué cambió en el bucle del agente. El modelo base casi nunca envió solicitudes. El entrenamiento con trayectorias de tokens fijos le enseñó a entrar en el bucle y enviar solicitudes, pero muchas de ellas eran incorrectas. La ejecución combinada con etiquetas blandas volvió a aumentar la tasa de éxito y es la mejor en general. Aun así, envió 171 tareas y resolvió 55, lo que significa que 116 solicitudes enviadas fallaron en las pruebas ocultas, y además tuvo 39 interrupciones por acciones repetidas.

    Esa es la realidad honesta de los resultados. El modelo no falla principalmente porque no pueda generar acciones BAML válidas; falla porque sigue tomando decisiones deficientes en SQL y a veces se queda atascado en el bucle.

    La señal de comportamiento más fiable fue el número de giros. El promedio de giros en el método de etiquetas suaves combinadas fue de 3,39, frente a 3,48 en el inicio en caliente con tokens duros; la diferencia es lo suficientemente pequeña como para que pasos adicionales no puedan explicar la mejora. Una combinación de acciones ligeramente mejor sí lo explica: más envíos correctos que en el inicio en caliente, menos errores que en el método de pesos combinados para tokens duros, además de menos errores SQL y menos interrupciones al alcanzar el límite de giros. No se registraron los conteos de tokens generados por cada llamada de evaluación, por lo que no se ofrecen cifras sobre tokens de salida. Las cifras que se pueden reportar con seguridad provienen del entrenamiento: cuántos tokens de prompt y de destino había, la longitud total de la secuencia y el porcentaje de cobertura top-k.

    Una nota sobre cómo leer las tablas detrás de los gráficos: “submitted” incluye tanto las entregas correctas como las incorrectas, y “wrong submits” equivale a submitted menos éxito. La columna “SQL-error tasks” no es exclusiva; una tarea termina en ella si alguna de sus pruebas SQL genera un error durante el bucle, por lo que puede coincidir con cualquier resultado final.

    Análisis de fallos

    Si juzgáramos únicamente en función de la ejecución combinada del modelo base, el resultado parecería demasiado claro: profesores mixtos más etiquetas suaves, y listo. Las vistas separadas no son tan ordenadas. Lo sorprendente es que un profesor menos competente enseñó mejor que uno más competente, ya que sus probabilidades coincidían con sus propios registros. Las etiquetas suaves obtuvieron los mejores resultados en los caminos de Qwen de la misma familia, y también claramente al combinar las fuentes. Obtuvieron resultados menores en los registros de GPT que Qwen solo había evaluado de forma indirecta, y afectaron negativamente a la celda de inicio en caliente de GPT.

    Esto es plausible: las probabilidades de 8 bits de Qwen3.5-35B-A3B describen bien las acciones de este modelo en formato de 8 bits, por lo que el estudiante Qwen de 0.8B recibe una señal más clara para imitar.

    El proceso de implementación mantiene la última palabra. La pregunta al forzar al estudiante a actuar es si puede adivinar la próxima acción del profesor cuando el contexto es similar al del profesor. El sistema propuesto plantea algo más difícil: ¿puede recuperarse de sus propios movimientos anteriores, elegir pruebas adecuadas, evitar bucles y finalizar con un SQL correcto? Ambos aspectos están relacionados, pero distan mucho de ser lo mismo.

    La pérdida de validación cuenta la misma historia desde un ángulo diferente. Con un ratio de 55/220, el método combinado de etiquetas suaves tuvo una pérdida de validación de 0.5684, superior a los 0.3478 del método combinado de tokens duros, que resolvió 49 problemas. La menor pérdida registrada, 0.2544, correspondió al método base de Qwen con puntuación automática de tokens duros, y solo resolvió 40/220 problemas. Una baja pérdida debido a la intervención del instructor no implica necesariamente un agente mejor.

    El resultado obtenido con el método combinado que incluye al instructor es el que más enseña. Las pistas de GPT incentivaron al estudiante a presentar respuestas con mayor frecuencia. Las pistas de Qwen eran más fáciles de puntuar y pertenecían a la misma familia, pero generaron más bucles en el proceso. El método combinado de etiquetas suaves no simplemente tomó lo mejor de cada uno, y las interrupciones continuaron ocurriendo. Aun así, su número de éxitos fue el más alto, y en comparación con el método combinado de tokens duros presentó menos errores en la ejecución de SQL y finalizó menos episodios al alcanzar el límite de turnos.

    El control ponderado-estricto también ofreció una lección importante. Ponderar las filas según la confianza del evaluador es más económico que ajustar distribuciones de probabilidad dispersas, y con los datos de inicio temprano evaluados mediante GPT, produjo el mejor resultado. Lo que no puede hacer es informar al estudiante sobre las alternativas cercanas en cada posición; solo indica “copia este token con más o menos intensidad”. Las etiquetas suaves top-k son adecuadas para casos en los que el evaluador coincide con la fuente de referencia y la mezcla de datos es lo suficientemente amplia como para que el estudiante no sobreajuste al estilo de un único instructor.

    Lecciones de hardware

    Se necesitaban dos tipos de máquinas. Para la evaluación era necesario mantener Qwen3.5-35B-A3B en formato de 8 bits en memoria y ejecutarlo sobre objetivos congelados, por lo que tenía sentido utilizar una Mac con alta capacidad de RAM, 128 GB de memoria unificada, capaz de albergar al instructor cuantizado. No era rápida, pero permitía realizar toda la preparación localmente antes de utilizar tiempo en una GPU de pago.

    El entrenamiento requería lo opuesto. El ajuste fino de LoRA implica un gran uso de matrices, con pasos hacia adelante y hacia atrás, núcleos de atención y pasos del optimizador, y la GPU de NVIDIA era mucho más rápida a pesar de tener menos memoria total, ya que esos tensores permanecían en la VRAM y se ejecutaban con núcleos CUDA. La lección recurrente es que la capacidad y el rendimiento son problemas separados. La gran cantidad de RAM del sistema permite almacenar y preparar los datos, mientras que la VRAM de la GPU junto con CUDA permite entrenarlos rápidamente. El flujo de trabajo se estableció en hacer todo lo posible en la Mac y activar la GPU remota solo una vez que los datos y los scripts estuvieran listos.

    Lecciones aprendidas

    La destilación con etiquetas suaves merece ser probada para el ajuste fino de agentes, siempre y cuando se evalúe mediante pruebas en entornos reales. La incertidumbre a nivel de token contiene más información que los tokens estándar, pero sigue siendo una supervisión local y por sí sola no enseñará al modelo a recuperarse de una llamada a herramienta defectuosa, a evitar bucles o a actuar mejor al recibir nuevas observaciones.

    Las etiquetas suaves proxy deben asignarse de manera honesta. Las filas de GPT aquí no corresponden a las probabilidades propias de GPT, sino a aquellas puntuadas con Qwen. Aún así, se trata de un experimento útil, aunque no sea una verdadera destilación de logit de GPT.

    Un modelo maestro de la misma familia puede superar a uno más potente. La calidad con la que el evaluador coincidió con el comportamiento del modelo fue más importante que su puntuación de evaluación.

    El top-k escaso con cola es un compromiso viable. Guardar los logits del vocabulario completo sería más completo, pero es costoso de almacenar, transferir y utilizar en el entrenamiento. Veinte tokens más una cola residual lo suficientemente grande permiten que el token objetivo siga siendo visible casi en todas partes.

    Mejor es mezclar varios modelos que elegir solo uno. El mejor resultado combinó filas con puntuación proxy de GPT 5.5 medium con filas con puntuación propia de Qwen, y entrenó el modelo base con etiquetas suaves.

    Resultado final

    Entonces, ¿ayuda? Sí, bajo ciertas condiciones. En la mejor configuración, la destilación de etiquetas suaves top-k mejoró al agente SQL de 0.8B: las filas con puntuación proxy de GPT combinadas con las filas con puntuación propia de Qwen, alimentadas al modelo base unsloth/Qwen3.5-0.8B, resolvieron 55 de 220 problemas, superando claramente al modelo basado en trayectorias de tokens rígidos fuera de política (46/220) y al modelo que utilizaba tokens rígidos combinados (49/220).

    No interprete esto como que “las etiquetas suaves siempre ganan”. La fuente del profesor, la inicialización del estudiante, la alineación de probabilidades y el comportamiento durante la ejecución fueron factores importantes, y el profesor que salió adelante no fue el que obtuvo la mejor puntuación de evaluación. Lo que sigue fallando es por problemas relacionados con la agencia: SQL incorrecto, acciones repetidas y recuperación imperfecta dentro del bucle.

    Este es precisamente el motivo por el cual vale la pena mantener este punto de referencia. Un estudiante puede parecer funcional bajo la dirección del profesor, pero seguir tropezando cuando debe actuar por sí mismo. Cualquier estudio posterior debe mantener constante el entorno de pruebas y verificar si una nueva idea de entrenamiento mejora realmente el bucle de ejecución y no solo la pérdida fuera de línea.

    Leer más