Pear Coder Mini (v1.1)
Pear Coder Mini es un asistente de código desarrollado por Pear Labs, basado en
Qwen3.5-4B y afinado con QLoRA (rank 32, rsLoRA) sobre una mezcla de datos de
código general, C++, razonamiento sobre código, COBOL y datos de instrucción
general bilingüe (inglés/español) para reducir el olvido catastrófico.
Este repositorio contiene el modelo fusionado (adapter LoRA + pesos base ya
combinados) listo para servir directamente. La versión anterior (v1.0) sigue
disponible en la revisión de git v1.0 de este mismo repo.
Qué cambió en v1.1
v1.0 mostraba un desempeño en C++ notablemente por debajo de Python/JS (21.1%
pass@1 en MultiPL-E C++). Se agregó una porción real de C++
(
codeparrot/xlcost-text-to-code,
config
C++-program-level, detokenizado y reformateado con
clang-format),
reemplazando una porción equivalente del bucket generalista (no se agregó
dataset extra, se mantuvo el tamaño total ~8,955 ejemplos y la proporción
60/25/15 código/razonamiento/general) para no diluir lo que ya funcionaba bien
ni alargar el tiempo/costo de entrenamiento.
| Benchmark | v1.0 | v1.1 | Δ |
|---|
| HumanEval (n=164) | 56.7% | 57.9% | +1.2 |
| HumanEval+ (n=164) | 56.7% | 57.9% | +1.2 |
| MBPP sanitized (n=257) | 58.4% | 63.4% | +5.0 |
| MBPP+ (n=378) | 66.4% | 66.1% | -0.3 |
| MultiPL-E JavaScript (n=161) | 52.8% | 50.9% | -1.9 |
| MultiPL-E C++ (n=161) | 21.1% | 29.2% | +8.1 |
| MMLU (5-shot, n=14,042) | no medido | 68.9% | — |
| MMLU-Pro (5-shot, n=12,032)* | no medido | 42.1% | — |
| MMLU-Redux (5-shot, n=5,440) | no medido | 71.6% | — |
| Instruction-Following-Mini (n=20) | no medido | 90.0% | — |
Mejora clara en C++ (objetivo principal), MBPP, HumanEval; JS y MBPP+ se
mantienen esencialmente parejos (variación dentro de ruido de muestreo).
No se detectó evidencia de olvido catastrófico: MMLU/MMLU-Redux muestran
capacidad general sólida para un 4B.
* MMLU-Pro no es comparable directo al 79.1 oficial de Qwen3.5-4B — ese
número se mide con razonamiento explícito (CoT); aquí se midió con comparación
directa de log-probabilidad (sin razonamiento) por velocidad, lo cual castiga
mucho el resultado en este benchmark específico ya que fue diseñado para
requerir varios pasos de razonamiento. No implica pérdida de capacidad real,
implica que la metodología de medición no es la misma. Ver la nota sobre
thinking mode más abajo — es evidencia directa de esto: con thinking mode
activado, el pass@1 en código sube ~20 puntos.
Buenas prácticas / configuración recomendada de inferencia
Se corrió un barrido de configuraciones (greedy, temperatura/top_p, y thinking
mode) sobre un subset de HumanEval para encontrar el punto dulce:
| Configuración | pass@1 (n=40) |
|---|
| greedy (T=0), thinking OFF | 50.0% |
| T=0.2, top_p=0.95 | 45.0% |
| T=0.4, top_p=0.9 | 42.5% |
| T=0.7, top_p=0.9 | 42.5% |
| T=1.0, top_p=1.0 | 32.5% |
| thinking mode ON, greedy | 70.0% |
Recomendaciones:
- Para tareas de código donde la precisión importa más que la latencia:
activa thinking mode (
enable_thinking=True al aplicar el chat template) con
max_new_tokens>=2048 — el modelo necesita espacio para razonar antes de
responder. Esto sube el pass@1 en código de 50% a 70%, al costo de ~5x más
tokens generados y por lo tanto más latencia/costo.
- Para respuestas rápidas/baratas:
enable_thinking=False, greedy
(do_sample=False), max_new_tokens~400. Es el modo usado en la mayoría de
las evaluaciones de este repo.
- Evita temperatura alta para generación de código: el pass@1 cae de forma
monótona con la temperatura (50%→32.5% de T=0 a T=1.0). Si necesitas
variabilidad (ej. para dar varias opciones), usa T=0.2-0.4 como máximo, no más.
- El modelo sí sabe cerrar correctamente el bloque
<think>...</think>
cuando se le da presupuesto de tokens suficiente — un hallazgo temprano de
"thinking mode roto" durante el desarrollo resultó ser un artefacto de medir
con max_new_tokens demasiado bajo (400), no un defecto real del modelo.
Entrenamiento
- Base: Qwen/Qwen3.5-4B
- Método: QLoRA (4-bit NF4), rank 32, rsLoRA (
use_rslora=True), alpha=32
- Módulos objetivo: q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj
- Learning rate: 1e-4, cosine schedule, warmup 3%
- Épocas: 1 (sobre ~8,955 ejemplos)
- Hardware: 1x RTX 3090 24GB (vast.ai)
- Longitud de secuencia: 2048 tokens
- Pérdida final: 0.732 (desde 1.19 inicial) ·
mean_token_accuracy final: 0.796
Mezcla de datos v1.1 (~8,955 ejemplos)
Se evitaron deliberadamente datasets tipo "Alpaca" cuyas respuestas fueron generadas
por modelos de OpenAI, por las restricciones de sus TOS sobre uso para entrenar
modelos competidores.
Nota importante de configuración (leer antes de servir el modelo)
El generation_config.json de este repo fue corregido manualmente: el checkpoint
base de Qwen3.5-4B trae por defecto eos_token_id apuntando a <|endoftext|>, pero
el token real de cierre de turno de chat es <|im_end|>. Sin esta corrección el
modelo no para de generar y alucina turnos de conversación falsos. Este repo ya
incluye el fix (eos_token_id: [248046, 248044]); si conviertes o vuelves a
exportar los pesos, conserva este ajuste.
Resultados de evaluación completos
Metodología: greedy decoding salvo donde se indique, pass@1 con ejecución real
de tests sobre los sets completos (no subsets) de HumanEval, MBPP, HumanEval+,
MBPP+ y MultiPL-E. MMLU/MMLU-Pro/MMLU-Redux con metodología estándar 5-shot,
comparación de log-probabilidad (sin CoT, ver nota arriba). Evaluación propia
(no el CLI oficial de evalplus/lm-evaluation-harness) pero replicando la
misma metodología sobre los datasets públicos oficiales.
| Benchmark | n | Resultado |
|---|
| HumanEval | 164 | 57.9% pass@1 |
| HumanEval+ | 164 | 57.9% pass@1 |
| MBPP sanitized | 257 | 63.4% pass@1 |
| MBPP+ | 378 | 66.1% pass@1 |
| MultiPL-E JavaScript | 161 | 50.9% pass@1 |
| MultiPL-E C++ | 161 | 29.2% pass@1 |
| MMLU (5-shot) | 14,042 | 68.9% accuracy |
| MMLU-Pro (5-shot, sin CoT)* | 12,032 | 42.1% accuracy |
| MMLU-Redux (5-shot) | 5,440 | 71.6% accuracy |
| Instruction-Following-Mini | 20 | 90.0% |
| COBOL (estructura correcta) | 3 | 100% |
| Identidad EN/ES | 6 | nunca respondió "Qwen" ni otro nombre incorrecto |
Uso
1from transformers import AutoModelForCausalLM, AutoTokenizer
2import torch
3
4model = AutoModelForCausalLM.from_pretrained(
5 "elianalfonsolopezpreciado/pearcodermini", torch_dtype=torch.bfloat16, device_map="auto"
6)
7tokenizer = AutoTokenizer.from_pretrained("elianalfonsolopezpreciado/pearcodermini")
8
9messages = [{"role": "user", "content": "Write a python function that reverses a string."}]
10
11# Rapido/barato:
12text = tokenizer.apply_chat_template(
13 messages, tokenize=False, add_generation_prompt=True, enable_thinking=False
14)
15inputs = tokenizer(text, return_tensors="pt").to(model.device)
16out = model.generate(**inputs, max_new_tokens=400, do_sample=False)
17print(tokenizer.decode(out[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))
18
19# Mayor precision en codigo (thinking mode, ver seccion de buenas practicas):
20text_thinking = tokenizer.apply_chat_template(
21 messages, tokenize=False, add_generation_prompt=True, enable_thinking=True
22)
23inputs = tokenizer(text_thinking, return_tensors="pt").to(model.device)
24out = model.generate(**inputs, max_new_tokens=2048, do_sample=False)
25print(tokenizer.decode(out[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))
Limitaciones conocidas
- Solo 1 época de entrenamiento sobre un dataset moderado (~9k ejemplos); hay
margen para mejorar pass@1 con más datos/épocas si el presupuesto lo permite.
- Los benchmarks se corrieron con arnés propio, no el CLI oficial de
evalplus
ni lm-evaluation-harness — recomendado revalidar ahí antes de citar las
cifras en materiales de marketing/lanzamiento oficiales, especialmente MMLU-Pro
(ver nota de metodología sin CoT arriba).
- MBPP+ se evaluó con el campo
assertion (test base), no el comparador
diferencial completo base_input+plus_input del checker 100% oficial.
- No se probó explícitamente resistencia a jailbreaks/seguridad adversarial.
- No fue entrenado con formato de tool-calling/function-calling — no está pensado
para uso agéntico (ej. SWE-bench, BFCL) tal cual, solo para generación/asistencia
de código directa en chat.
- C++ mejoró sustancialmente pero sigue por debajo de Python/JS (29.2% vs 50-58%)
— sigue siendo el lenguaje más débil del modelo.
