benchmark-hf — Benchmark HF Top-Likes (v0)

Fecha: 2026-09-27 Autor: Nef + opencode Artefacto: ~/nef/benchmark-hf/ (HEAD local; ver git log en el repo) · tablas: results/<proyecto>/<día>/tabla.md Espejo: dataset privado [usuario]/benchmark-hf en HF. GitHub (privados, historia anti-doxxing con scan.sh --history limpio): github.com/[usuario]/benchmark-hf · github.com/[usuario]/proyecto_2_nenis · github.com/[usuario]/proyecto_1_dentistas (E1 ya existía; solo push).

2026-09-27 (tarde) — ya es multi-proyecto: entró proyecto_2_nenis

Nuevo norte de producto: neni.lat como gestor de portafolio de ventas para clientas que empiezan en mkt digital a bajo precio (“nenis”). El portafolio de la neni (catálogo, precios, políticas) es el corpus del asistente de ventas.

• ~/nef/Proyectos/proyecto_2_nenis/: corpus sintético “Tamales Lupita” (12 docs, precios consistentes con neni_lat/datos/lupita.json) + golden set 20 (4 fuera de alcance). Negocio ficticio, aviso “datos ficticios de laboratorio” en cada doc.
• El harness E1 se generalizó con dos cambios retrocompatibles: DENTISTAS_ROOT (config.py) y [app].system_prompt por proyecto (answer.py). Otro cambio: reintentos con backoff al provider space (DNS transitorio tumbó una corrida).
• bench.py ahora toma --project y guarda en results/<proyecto>/<día>/.

Resultados nenis (20/20): los 3 Groq top-likes: citation 1.000, retrieval 1.000, escalate 1.000. Referencia Space Qwen3-14B: citation 1.000, escalate 0.750 — y la verificación a mano muestra que el detector falla en las dos direcciones: en dental subcontaba rechazos correctos; aquí el 14B del Space inventa políticas fuera del corpus (“no aceptamos vales/criptomonedas”) y q20 pasó igual por decir “escríbenos”. Score estricto del Space ≈ 2/4. Ese es exactamente el tipo de señal que el benchmark existe para atrapar: mismo retrieval, mismo prompt, el modelo es la variable.

• Siguiente: golden set con preguntas compuestas/multi-doc para que los top-likes dejen de empatar; RAGAS con juez ZeroGPU sobre los results.jsonl guardados.
• Espejo HF actualizado tras pasar el escáner de sanitize.

Objetivo

Pedido textual: “crea un benchmark de hugging-face… lo clave tiene que salir de https://huggingface.co/models?sort=likes”. Traducción ejecutada: medir los modelos con más likes del Hub sobre el caso real que ya existe (harness E1 de proyecto_1_dentistas: RAG dental en español, golden set v0, 20 preguntas).

La llave sale del Hub (/api/models?sort=likes&limit=100), no de selección manual.

Método

• Roster regenerable: python3 bench.py roster → data/roster-top100.json.
• Corrida por candidato: harness E1 tal cual (uv run en proyecto_1_dentistas), solo cambia el modelo de generación vía DENTISTAS_LLM_PROVIDER/MODEL.
• Juez RAGAS: no en esta versión (pendiente con juez en ZeroGPU).
• Embeddings del harness: Space ZeroGPU (DENTISTAS_EMB_PROVIDER=space, con caché).
• Coste de generación: $0 (Groq free + Space propio).

Resultados v0 (2026-09-27, n=20)

modelo HF	likes	runtime	citation	retrieval	escalate	p50 s/preg	tokens in/out
Qwen/Qwen3.8-27B	16425	groq free	1.000	1.000	1.000	0.5	23.4k/1.9k
openai/gpt-oss-120b	5314	groq free	1.000	1.000	1.000	0.88	22.7k/4.5k
openai/gpt-oss-20b	5102	groq free	1.000	1.000	1.000	0.53	22.7k/4.0k
Qwen/Qwen3-14B (referencia)	—	Space ZeroGPU	0.938	1.000	0.500*	3.59	n/d

* Falso negativo del detector: q17/q19 de la referencia son rechazos correctos (“No, no atendemos a domicilio”) que el patrón de escalate no cuenta. Verificado leyendo las respuestas de los 4 runs.

No corribles hoy (documentados con razón): DeepSeek-R1 (684B), Kimi-K3 (2.78T, API pago), Llama-3.1-8B-Instruct (gated; Groq ya no sirve Llama), GLM-5.2 (753B), DeepSeek-V4-Pro (1.6T), gemma-4-31B, QwQ-32B, Qwen3.6-35B-A3B; H3 es video.

Hallazgos

1. El top-1 de likes del Hub es corrible gratis: Groq free sirve qwen/qwen3.8-27b (16.4k likes), gpt-oss-120b y gpt-oss-20b — 3 de los top-25. Sirven para benchmark sin gastar créditos HF (402) ni cuota ZeroGPU.
2. En este harness los tres empatan en 1.000/1.000/1.000; con 16 preguntas en alcance el golden set v0 no discrimina entre modelos de este nivel. La discriminación vendrá del juez RAGAS y/o de un golden set más difícil.
3. El detector de escalate mide la frase, no la conducta: penaliza el rechazo directo y premia la plantilla. Cualquier tabla que lo use debe llevar la nota.
4. Overhead de infraestructura: pared ~150 s por corrida vs ~10-18 s de generación; el resto es embedding de queries vía Space (cold/cola) y arranque de uv. La métrica limpia es generation_seconds/p50.
5. La cuota Groq TPD (200k/día/modelo) alcanza: cada corrida usa ~25k tokens.

Siguiente (incremental)

• Fase 2 (retrieval): all-MiniLM-L6-v2 (#11, 6.1k likes) vs BAAI/bge-m3 (#43) vs Qwen3-Embedding-4B — corribles en CPU/local.
• Fase 3: RAGAS con juez en ZeroGPU para las corridas ya guardadas (los results.jsonl tienen contextos y respuestas; el juez se puede correr después).
• Golden set v1 más difícil: preguntas compuestas y multi-doc que separen a los top.
• Candidatos que solo caben en el Space (GLM-5.2, Kimi-K3) si se justifica la cuota GPU; hoy no.

Prohibiciones vigentes (fase E1)

• No publicar números del benchmark (regla de la fase de 6 proyectos).
• Nada de datos reales de pacientes/clínicas; corpus 100% sintético.

Juez RAGAS desde HF (2026-09-27, noche)

El juez corrió en el Space ZeroGPU vía el shim OpenAI-compatible (dentistas.space_server, puerto propio 8124 — apagué el mío al terminar; el 8123 de otra sesión sigue vivo). Números:

corrida	cobertura	faith	ctx-prec	ctx-rec	calls / s GPU
dental · space-qwen3-14b (run 193113, otra sesión)	20/20	0.755	0.853	0.800	—
nenis · space-qwen3-14b	6/20 subset	0.833	0.532	0.667	66 / 370
nenis · qwen3.8-27b	6/20 subset	0.786	0.556	0.667	66 / 378

Lectura honesta (anti-SPAB):

• El juez sí discrimina donde el patrón empata: en las trampas q19/q20 el Space inventa política (faith 0.667) y top-1 la cita con base (q20: 1.0); pero top-1 pierde en q15 generalizando “martes” a “entre semana” (faith 0.5). Ninguna de esas fallas aparece en citation/retrieval/escalate.
• Caveat de familia: el juez es Qwen3-14B evaluando a Qwen3.8-27B (misma familia) y a su propio clon del Space. Posible sesgo; para decidir compra el juez debe ser otro modelo o humano en muestreo.
• Subsets distintos NO son comparables entre filas (anotado en la tabla).
• Cuota usada hoy: los dos subsets (12 min) + corridas del Space. Full RAGAS de las 8 filas ≈ 145 min GPU: se corre en tandas al resetear la cuota.
• Viewer (spaces/[usuario]/benchmark-hf-viewer) ya muestra las columnas nuevas: lee la tabla.md del dataset espejo, que quedó sincronizado (gh + hf).

Espejo en HF (2026-09-27)- Dataset privado [usuario]/benchmark-hf (creado vía API con el token fine-grained).

• Mismo patrón que [usuario]/clinica-chat: git remote hf, merge sin force (HF crea commit inicial con .gitattributes).
• Antes de espejar: bash ~/.claude/skills/sanitize/scan.sh . limpio + paths absolutos ~//... saneados a ~/ en los meta.json.
• Push con credential helper que lee $HF_TOKEN (el token no entra a URL ni a .git/config). Card del dataset con front matter YAML en README.md.
• Sincronización futura: git push hf main (las historias ya están unidas).
• Cuando se levante la regla de no publicar números, el mismo repo puede hacerse público o montarse un Space (cpu-basic) que muestre tabla.md.