nimbus-lora-format-tuning-adapter

Adaptador LoRA que ensena a Qwen/Qwen2.5-0.5B-Instruct a responder siempre con la estructura de tickets de soporte de NimbusCloud. El objetivo no es incorporar conocimiento nuevo, sino obediencia de formato.

[DIAGNOSTICO] <una linea>
[PASOS]
1. ...
2. ...
[ESCALAMIENTO] SI - <equipo> | NO

Equipos validos de escalamiento: Redes, Plataforma, Datos, Seguridad, o NO cuando lo resuelve el propio usuario.

Uso

from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer

base = "Qwen/Qwen2.5-0.5B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(base)
model = AutoModelForCausalLM.from_pretrained(base)
model = PeftModel.from_pretrained(model, "MatiasMarro/nimbus-lora-format-tuning-adapter")

mensajes = [
    {"role": "system", "content": SYSTEM_PROMPT},  # ver el repo del proyecto
    {"role": "user", "content": "No puedo conectarme a NimbusDB, me da timeout."},
]
prompt = tokenizer.apply_chat_template(
    mensajes, tokenize=False, add_generation_prompt=True
)
entrada = tokenizer(prompt, return_tensors="pt", add_special_tokens=False)
salida = model.generate(**entrada, max_new_tokens=300, do_sample=False)
print(tokenizer.decode(salida[0][entrada["input_ids"].shape[-1]:], skip_special_tokens=True))

El system_prompt debe ser el mismo con el que se entreno: vive en app/config.py del repositorio del proyecto.

Configuracion de entrenamiento

Parametro	Valor
Modelo base	Qwen/Qwen2.5-0.5B-Instruct
Rank (r)	16
Alpha	32
Dropout	0.05
Target modules	q_proj,k_proj,v_proj,o_proj
Epochs	3
Learning rate	0.0002
Batch efectivo	8
Max seq length	1024
Precision	fp16

El loss se calcula unicamente sobre la respuesta del assistant: los tokens de system y user se enmascaran con -100 mediante un collator propio.

Dataset y split

Dataset sintetico de soporte tecnico de NimbusCloud (empresa ficticia), generado de forma determinista.

• Registros de usuario: formal, informal con errores de tipeo, incompleto y con dos incidencias mezcladas.
• Casos dificiles: consultas fuera de dominio y escalamientos ambiguos entre dos equipos.
• Split por grupo: la unidad indivisible es el par (producto, incidencia). Ninguna combinacion de eval aparece en train con ninguna redaccion.
• Held-out de producto: un producto entero queda fuera de train para medir generalizacion a un servicio nunca visto.

Un split aleatorio a nivel de ejemplo habria sido incorrecto: como cada combinacion existe en varias redacciones, el eval habria medido memorizacion.

Metricas

Run	Configuracion	Formato valido	Acierto escalamiento	Exact match
b0	Base zero-shot	0.0%	-	0.0%
b1	Base few-shot (3)	54.8%	34.8%	0.0%

Limitaciones conocidas

• El dominio es sintetico: los productos y las incidencias son ficticios, asi que el adaptador no aporta conocimiento operativo real.
• Aprende estructura, no diagnostico. El contenido de los pasos proviene de plantillas y no debe tomarse como recomendacion tecnica.
• Fuera del dominio de soporte, el adaptador tiende a forzar el formato de ticket incluso cuando no corresponde.
• Entrenado y evaluado solo en espanol.
• El adaptador es inutil sin su modelo base: hay que cargar Qwen/Qwen2.5-0.5B-Instruct y aplicar los pesos encima.