Cómo evaluar una IA local antes de ponerla en producción

Decide qué significa «correcto» antes de mirar respuestas

Una evaluación útil parte del proceso. Define el error crítico, el error tolerable, la salida mínima y la revisión humana. No mezcles una tarea creativa con una extracción exacta bajo una única puntuación.

Plantilla de plan

name: soporte-rag
owner: soporte
system_under_test:
  runtime: ollama
  model_alias: instruct-candidate-a
  prompt_version: support-v3
  index_version: manuals-release-hash
scope:
  task: responder con evidencia
  users: soporte-nivel-1
  languages: [es]
thresholds:
  critical_errors: 0
  retrieval_recall_at_5: 0.90
  citation_precision: 0.98
  schema_valid: 1.00
  p95_latency_seconds: 20
  permission_leaks: 0
repetitions: 3
reviewers: [experto-proceso, tecnico-evaluacion]

Los números son ejemplos de estructura, no umbrales universales. Debes fijarlos según impacto y capacidad del proceso.

Separa desarrollo, aceptación y pruebas adversarias

Cobertura que debes registrar

• Tipos de usuario y permisos.
• Idiomas, formatos y longitudes.
• Casos frecuentes, raros y de frontera.
• Documento vigente, obsoleto, contradictorio y ausente.
• Campos vacíos, duplicados y malformados.
• Preguntas con códigos exactos y con lenguaje natural.
• Operaciones permitidas, denegadas y reversibles.
• Situaciones en las que el modelo debe abstenerse.

Formato JSONL

JSONL es un archivo de texto en el que cada línea contiene un objeto JSON independiente. Esta estructura permite añadir casos, filtrarlos y procesarlos uno a uno sin cargar todo el conjunto en memoria. En el ejemplo, cada línea describe la entrada, quién puede ejecutarla y qué resultado se considera correcto o prohibido.

{"id":"rag-001","input":"...","user_groups":["soporte"],"relevant_sources":["manual-42#sec-3"],"required_facts":["..."],"forbidden_claims":["..."],"must_abstain":false,"risk":"medio"}
{"id":"rag-002","input":"...","user_groups":["ventas"],"relevant_sources":[],"required_facts":[],"forbidden_claims":["contenido-soporte"],"must_abstain":true,"risk":"alto"}
{"id":"tool-001","input":"...","allowed_tools":["crear_borrador"],"expected_tool":"crear_borrador","expected_args":{"ticket_id":"SUP-000001"},"must_require_approval":true}

El dataset no debe contener secretos ni datos que el entorno de evaluación no esté autorizado a tratar. Seudonimiza y conserva una tabla de correspondencia fuera del repositorio cuando sea imprescindible.

Fija todo lo que pueda cambiar la salida

Identificador de configuración

{
  "run_id": "eval-00042",
  "model_family": "familia-candidata",
  "model_artifact": "nombre-y-hash",
  "runtime": "nombre-y-version-probada",
  "prompt_hash": "sha256:...",
  "dataset_hash": "sha256:...",
  "index_hash": "sha256:...",
  "temperature": 0,
  "seed": 42,
  "max_output_tokens": 1200,
  "context_limit": 16000,
  "hardware": "gpu-y-memoria",
  "driver": "version-probada"
}

No todos los backends garantizan determinismo aunque fijes semilla y temperatura. Repite los casos y registra dispersión. Para comparación, mantén idénticos prompt, contexto y herramientas salvo la variable que estás estudiando.

Calienta el modelo

La primera petición incluye carga de pesos y no representa el servicio calentado. Mide por separado arranque en frío, primera petición y operación estable. Para servicios con descarga automática de modelos, prueba también el retorno después de inactividad.

Combina comprobaciones automáticas y revisión experta

Comprobaciones automáticas

• JSON válido y conforme al esquema.
• Campos obligatorios, tipos, longitudes y enumeraciones.
• Presencia o ausencia de cadenas críticas.
• Citas que resuelven a una fuente recuperada.
• Cálculos comparados con un motor determinista.
• Idioma, estructura y límite de salida.

Rúbrica de revisión

Define ejemplos ancla para cada puntuación. Si dos revisores discrepan con frecuencia, la rúbrica es ambigua o la tarea no está suficientemente especificada.

Errores críticos como veto

Una media alta puede ocultar una fuga o una acción peligrosa. Cuenta por separado errores críticos y exige cero cuando el impacto lo requiera.

Separa recuperación de generación

Si la respuesta es mala, primero comprueba si la evidencia correcta llegó al contexto. Ajustar el modelo no resuelve una recuperación defectuosa.

Métricas de recuperación

• Recall@k: proporción de preguntas en las que al menos una fuente relevante aparece entre los primeros k resultados.
• Precision@k: proporción de resultados recuperados que son relevantes.
• MRR: favorece que la primera fuente relevante aparezca pronto.
• nDCG: útil cuando hay varios grados de relevancia.
• Cobertura de permisos: fuentes relevantes accesibles al rol frente a fuentes bloqueadas.

Métricas de respuesta

• Hechos apoyados por los fragmentos.
• Citas correctas y resolubles.
• Ausencia de afirmaciones no respaldadas.
• Respuesta de abstención cuando no hay evidencia.
• Uso de la versión vigente.

Tabla de diagnóstico

Script sencillo de recall

def recall_at_k(retrieved_ids, relevant_ids, k):
    relevant = set(relevant_ids)
    if not relevant:
        return None
    return int(bool(set(retrieved_ids[:k]) & relevant))

def precision_at_k(retrieved_ids, relevant_ids, k):
    selected = retrieved_ids[:k]
    if not selected:
        return 0.0
    relevant = set(relevant_ids)
    return sum(item in relevant for item in selected) / len(selected)

Mide la trayectoria, no solo el texto final

Casos obligatorios

• Herramienta inexistente.
• Argumento fuera de enumeración.
• ID válido con usuario sin permiso.
• Operación duplicada.
• Timeout de API.
• Resultado parcial.
• Documento que ordena usar una herramienta.
• Petición de elevar privilegios.
• Máximo de iteraciones alcanzado.

Un agente falla aunque su texto final sea correcto si llamó a una herramienta que no necesitaba, usó una credencial excesiva o dejó un efecto no esperado.

Mide prefill, generación, cola y memoria

Métricas técnicas

• Tiempo de carga del modelo.
• Tiempo hasta primer token.
• Tiempo de prefill o procesamiento de entrada.
• Tokens de salida por segundo.
• Latencia total y percentiles.
• Memoria de GPU o unificada máxima.
• Peticiones en cola y rechazadas.
• Throughput total con concurrencia.
• Estabilidad térmica y errores.

Matriz de carga

Percentiles

Registra mediana, p90, p95 y p99 cuando haya suficientes muestras. El promedio oculta colas largas. También mide errores y peticiones canceladas.

Prueba de memoria

nvidia-smi --query-gpu=timestamp,name,memory.used,memory.total,utilization.gpu,temperature.gpu,power.draw \
  --format=csv -l 2 > gpu-metrics.csv

En plataformas de memoria unificada, complementa con métricas del sistema y del runtime. La cifra de memoria disponible no garantiza que una carga tenga la latencia deseada.

Ejecuta el dataset y conserva resultados crudos

Este ejemplo usa solo la biblioteca estándar de Python y una API local de chat. Adapta el parser de métricas al runtime. No evalúa calidad por sí solo; produce respuestas y tiempos para las comprobaciones posteriores.

from __future__ import annotations
import hashlib
import json
import pathlib
import time
import urllib.request

API = "http://127.0.0.1:11434/api/chat"
MODEL = "MODELO_PROBADO"
DATASET = pathlib.Path("cases.jsonl")
OUTPUT = pathlib.Path("results.jsonl")


def call_model(case: dict) -> dict:
    payload = {
        "model": MODEL,
        "stream": False,
        "messages": [
            {"role": "system", "content": case.get("system", "Responde de forma verificable.")},
            {"role": "user", "content": case["input"]},
        ],
        "options": {"temperature": 0, "seed": 42},
    }
    request = urllib.request.Request(
        API,
        data=json.dumps(payload).encode("utf-8"),
        headers={"Content-Type": "application/json"},
        method="POST",
    )
    started = time.perf_counter()
    with urllib.request.urlopen(request, timeout=300) as response:
        body = json.load(response)
    return {
        "id": case["id"],
        "seconds": time.perf_counter() - started,
        "response": body.get("message", {}).get("content", ""),
        "runtime_metrics": {k: body.get(k) for k in (
            "total_duration", "load_duration", "prompt_eval_count",
            "prompt_eval_duration", "eval_count", "eval_duration")},
    }


def main() -> None:
    dataset_hash = hashlib.sha256(DATASET.read_bytes()).hexdigest()
    with DATASET.open(encoding="utf-8") as source, OUTPUT.open("w", encoding="utf-8") as target:
        for line in source:
            case = json.loads(line)
            result = call_model(case)
            result["dataset_sha256"] = dataset_hash
            target.write(json.dumps(result, ensure_ascii=False) + "\n")
            target.flush()

if __name__ == "__main__":
    main()

Conserva tres capas

1. Entrada: dataset, configuración y hashes.
2. Salida cruda: respuesta, recuperación, herramientas, tiempos y errores.
3. Puntuación: reglas automáticas, revisión y decisión.

No cambies varias variables a la vez

Orden recomendado de experimentos

1. Establece una base

   Modelo compacto, prompt simple, sin RAG o con recuperación mínima.

2. Mejora la recuperación

   Fragmentación, filtros, híbrida y reranking con el modelo fijo.

3. Compara modelos

   Mismo contexto y parámetros; registra calidad y memoria.

4. Ajusta prompts y formato

   Una modificación por experimento.

5. Optimiza rendimiento

   Contexto, cuantización, motor, lote y concurrencia sin rebasar calidad.

6. Prueba el sistema final

   Incluye identidad, herramientas, red, copias y operación.

Informe de decisión

Configuración candidata: ...
Caso y alcance: ...
Dataset y hash: ...
Calidad: aprobado / no aprobado
Errores críticos: ...
RAG: recall, citas, permisos
Herramientas: éxito, rechazos, efectos
Rendimiento: p50/p95, throughput, memoria
Seguridad: pruebas ejecutadas y excepciones
Operación: copia, restauración y rollback
Riesgos residuales: ...
Decisión: piloto / preproducción / producción / rechazar
Responsables y próxima revisión: ...

Cada error real debe convertirse en una prueba

Cuando un usuario detecta un fallo, anonímalo, clasifícalo y añádelo al conjunto de regresión. Ejecuta la batería antes de cambiar modelo, prompt, runtime, índice, documentos, embeddings, reranker o herramienta.

Puertas automáticas

• Cero errores críticos.
• Cien por cien de respuestas conforme al esquema cuando sea obligatorio.
• Sin fuga de permisos.
• Recuperación y calidad no inferiores al margen acordado.
• Latencia y error dentro del presupuesto.
• Restauración y rollback disponibles.

Publica un registro de versiones interno que relacione cambio, resultado y aprobación. La guía de operación explica despliegues y reversión.

Evaluación completa antes de producción

• Caso, propietario, salida y error crítico definidos.
• Dataset de desarrollo y aceptación separados.
• Casos adversarios y de abstención incluidos.
• Modelo, runtime, prompt, índice y hardware identificados.
• Repeticiones y parámetros fijados.
• Calidad automática y humana documentada.
• RAG evaluado antes de generación.
• Herramientas evaluadas por trayectoria y efecto.
• Seguridad y aislamiento por roles probados.
• Latencia, memoria, cola y concurrencia medidas.
• Resultados crudos y hashes conservados.
• Umbrales, veto y decisión aprobados.
• Regresión integrada en el cambio.