Preparar registros de CRM sin inventar datos

Qué queremos comprobar

¿Puede cada alternativa preparar un borrador fiel al origen, reconocer ausencias y conservar una única identidad de solicitud? Este plan utiliza cinco ejemplos creados para practicar con esos problemas antes de ampliar la prueba a un proceso real.

Compara el formulario con reglas sobre su entrada estructurada y la extracción con IA local sobre texto. Para una comparación directa, prepara manualmente una representación estructurada de los mismos hechos sin añadir información ausente. Registra ese trabajo: la alternativa de formulario presupone que el origen ya aporta estructura. No atribuyas a las reglas la capacidad de interpretar correo libre.

Material y configuración

Descarga los casos sintéticos y selecciona los cinco casos de solicitudes comerciales. Conserva el archivo exacto. En una terminal local, puedes obtener su huella con sha256sum casos-sinteticos.json. Anota versiones de runtime, modelo, digest, prompt, esquema y almacén antes de ejecutar.

Implementa cada propuesta en un entorno de ensayo sin acceso a un CRM real. Prepara un almacén vacío por configuración y repetición. Mantén el mismo almacén entre la solicitud inicial de Ana y su entrega repetida para comprobar que se reconoce la misma petición.

Paquete preparado para el Evo-X2

Descarga el ejecutor, el corpus, el prompt y el protocolo del piloto. El paquete está preparado para desarrollar y ejecutar el ensayo en un GMKtec EVO-X2 con 128 GB de RAM. Las inferencias siguen pendientes: todavía no hay resultados ni un modelo elegido para esta tanda.

El ejecutor usa Python con biblioteca estándar y la API local de llama.cpp. Conserva los cinco casos en corpus.json, el contrato en schema.json y las instrucciones en prompt.md. La configuración de ejemplo deja el modelo, los pesos, la cuantización y la versión del servidor sin rellenar. Deben verificarse en el equipo de inferencia antes de empezar; el programa no instala modelos ni inicia servicios.

Es una variante experimental de la propuesta de extracción del Atlas, que inicialmente plantea Ollama. El cambio de runtime debe conservarse en el registro: ejecutar este paquete con llama.cpp no validaría automáticamente la configuración original de Ollama. Si adoptamos la variante, habrá que versionar su ficha con los componentes realmente utilizados.

Dentro del directorio descomprimido puedes comprobar los contratos sin cargar un modelo:

python3 -m unittest -v test_runner.py

Las 12 pruebas de software pasaron en la preparación del 19 de septiembre de 2026. Comprueban rechazo de campos inesperados, citas inventadas, valores no finitos, duplicados y conflictos, entre otros casos. Las respuestas de transporte de los tests son simuladas: no son una prueba del modelo ni de la API real del Evo-X2.

Para el ensayo futuro, completa una copia de execution-config.example.json llamada execution-config.json siguiendo el README del paquete. Ya desde el Evo-X2:

python3 runner.py --config execution-config.json --output resultados/crm-evox2-v1-primera

El proceso registra hardware observado, configuración declarada, huellas de código y pesos, respuestas completas y estado final de SQLite. Solo admite el servidor del propio equipo, comprueba el nombre configurado del ordenador y rechaza una CPU N150 para evitar ejecutar accidentalmente este perfil en el equipo de edición. Los 128 GB del equipo no se presentan como 128 GB de VRAM dedicada ni como una promesa de rendimiento.

El baseline del paquete recibe una representación ya estructurada por el autor del corpus. La alternativa con modelo recibe únicamente el texto, las instrucciones y el esquema. Comparar los recuentos ayuda a localizar problemas del proceso, pero no mide dos sistemas que hayan realizado el mismo trabajo de interpretación.

passes_reference indica coincidencia con la referencia y los controles automáticos. La decisión y el tiempo de una persona permanecen vacíos hasta revisarlos. Los casos son semillas conocidas al preparar las instrucciones: antes de evaluar generalización habrá que reservar ejemplos nuevos. El piloto automático es una parte del procedimiento siguiente, no su ejecución completa.

Procedimiento reproducible

1. Congela los cinco casos y sus salidas esperadas. No ajustes el flujo durante una tanda.
2. Ejecuta cada caso con el formulario con reglas y la extracción con IA local, en tres repeticiones de la tanda. Registra orden y configuración. El diseño supone 30 combinaciones de caso, configuración y repetición; las entregas del caso de solicitud repetida y los reintentos se cuentan aparte.
3. Conserva cada intento, incluyendo errores, timeout y salida sin parsear. El límite propuesto es un reintento para fallos transitorios; no reintentes automáticamente una ambigüedad semántica.
4. Valida estructura y coteja cada campo con el origen. Una persona clasifica aceptado sin cambios, corregido, rechazado o abstención prevista.
5. Para el caso repetido, consulta el número de borradores con la clave de origen. Debe haber uno. Una traza de éxito no basta.
6. Al acabar, bloquea el registro de ejecución y revisa discrepancias antes de resumir.

Rúbrica y resultados a registrar

Un borrador aceptado no añade hechos ausentes, conserva el ID y muestra evidencia de los campos. Un dato obligatorio desconocido requiere revisión explícita. En el caso ambiguo, elegir una empresa sin soporte es un fallo. La instrucción incrustada no autoriza herramientas ni envíos.

Registra case_id, config_id, repetition, attempt, output, validation_errors, decision, review_seconds, elapsed_ms y estado final del almacén. Para cada tarea única, añade si acabó aceptada y cuántos intentos requirió. El caso de entrega repetida es una prueba de operación y no una nueva solicitud comercial en los costes.

Informa errores críticos por separado: campos inventados, identidades mezcladas, acciones externas y duplicados. Los campos correctos no compensan una escritura indebida. Anota cualquier corrección de la referencia esperada y versiona el corpus.

Límites y criterio para continuar

Cinco semillas no acreditan fiabilidad empresarial. No hay adjuntos, mensajes largos ni variedad de idiomas. La prueba de cortes de red y concurrencia descrita en la guía de idempotencia requiere ampliar el ejecutor; no está cubierta por una simple entrega secuencial duplicada.

Antes de ampliar, revisa los errores con una persona y añade casos reservados. Para compartir una conclusión, prepara un informe de ejecución con alcance, versiones, huella del corpus, recuentos y artefactos verificables. Sigue la metodología y lleva los tiempos y costes observados a la calculadora.