Su bandeja de soporte recibe tres mensajes: «No encuentro mi factura», «La descarga falla» y «¿Puede presentarme su oferta?». Antes de redactar una respuesta, hay que decidir a qué equipo enviarlos. Este primer paso es una clasificación: elegir una categoría de una lista definida. Clef, anunciado por Cloudflare el 1 de octubre, invita a tratar esta elección como una tarea por derecho propio. Aquí se muestra cómo preparar su evaluación en un equipo de soporte ficticio, con errores visibles y una intervención humana.
Comenzar por la decisión esperada
En nuestro ejemplo de demostración, las categorías son facturación, técnica y comercial. Una cuarta categoría, fuera del alcance, recibe las solicitudes a las que esta organización no sabe responder. Junto a estas categorías, la aplicación tiene un estado de tratamiento: aceptado o a revisar. La categoría describe la solicitud; el estado describe lo que usted autoriza hacer con ella.
Esta separación ayuda a comprender una solicitud ambigua: «Mi suscripción está pagada, pero ya no puedo acceder a mis archivos.» El modelo puede proponer la categoría técnica, mientras que su política impone una verificación porque el mensaje también se refiere a un pago. No es necesario forzar a una sola etiqueta a abarcar toda la complejidad de la intervención.
Defina lo que queda fuera del primer piloto: reembolso, cierre de cuenta, modificación de derechos o respuesta enviada al cliente. El clasificador propuesto aquí sugiere una orientación. No activa ninguna de estas acciones. Para una primera prueba, las personas continúan trabajando normalmente mientras usted compara las sugerencias con las decisiones tomadas.
Lo que Cloudflare pone a disposición
En el anuncio del 1 de octubre de 2026, Cloudflare presenta Clef y Clef-flash como modelos de decisión con salidas estructuradas, disponibles en Workers AI. La adaptación a las tareas de los clientes comienza con un acompañamiento humano; se anuncia una plataforma de ajuste fino de autoservicio para más adelante. El ajuste fino consiste en adaptar un modelo a partir de ejemplos de una tarea particular.
La ficha oficial Clef en Hugging Face, consultada el 6 de octubre, muestra una licencia Apache-2.0 y describe los artefactos del modelo. Esto no demuestra su funcionamiento en su hardware. La ficha también contiene un tipo inusual en un ejemplo: no tomamos ese ejemplo como un contrato de integración validado.
Esta información abre dos vías de prueba a calificar: un servicio alojado o una ejecución de los pesos disponibles. La elección depende de sus restricciones de datos, de su hardware y del tiempo de operación. Antes de prometer una prueba local reproducible, sería necesario fijar la revisión de los artefactos, las dependencias y la configuración del hardware, y luego ejecutar una prueba. Este artículo no presenta ni instalación ejecutada ni llamada facturada.
Las comparaciones publicadas en el anuncio son las del proveedor. Nuestra decisión de prueba no se basa en su clasificación: el resultado interesante sería una mejor orientación de sus solicitudes, con un costo de error aceptable. Varias páginas del mismo editor no constituyen una confirmación independiente de la calidad en un soporte en francés.
Escribir un contrato simple para la aplicación
El contrato a continuación es una propuesta interna de Partitech, independiente del esquema oficial de Clef. Describe lo que su aplicación debe recibir y verificar. Ningún nombre de campo se presenta como un parámetro de la API del proveedor.
| Elemento conceptual | Rol en el piloto | Verificación a prever |
|---|---|---|
| Identificador de demostración | Vincular entrada y decisión | Presencia, unicidad en el lote |
| Texto autorizado | Contenido para clasificar | No vacío, tamaño limitado, ausencia de secreto |
| Versión de las categorías | Definir las opciones posibles | Versión reconocida por la aplicación |
| Categoría propuesta | Orientación sugerida | Valor presente en la lista permitida |
| Puntuación opcional | Ayudar a evaluar la aceptación | Formato esperado e interpretación documentada |
| Estado de procesamiento | Aceptar o solicitar una revisión | Regla de negocio distinta del modelo |
Puede verificar el contrato con algunos mensajes sintéticos. Para «La factura de demostración no se encuentra», la etiqueta de referencia elegida para el ejercicio sería facturación. Para «La descarga de mi documento de demostración se interrumpe», sería técnica. Un mensaje publicitario sin solicitud recibiría fuera del alcance. Estos ejemplos sirven para verificar el cableado y las categorías; no miden la calidad con clientes reales.
Prevea casos de rechazo: texto ausente, categoría desconocida, puntuación ilegible, respuesta incompleta y plazo excedido. El comportamiento esperado es una intervención humana o un fallo explícito, nunca una orientación silenciosa hacia una categoría por defecto. Una respuesta bien formada aún puede contener una decisión incorrecta; los controles de formato y de calidad permanecen separados.
Constituir un conjunto de prueba que revele los errores
El siguiente protocolo es propuesto por Partitech y no se ha ejecutado. Comience con una instrucción de anotación: qué significa cada clase, cómo tratar los mensajes con varios temas y cuándo retener fuera del alcance. Haga que una segunda persona revise los casos ambiguos. Si los anotadores no se ponen de acuerdo, el modelo no puede resolver por sí solo la imprecisión de su organización.
Luego separe tres usos de los datos. Un conjunto sirve eventualmente para adaptar el modelo. Otro sirve para elegir los ajustes y umbrales. El conjunto de prueba final permanece congelado hasta la comparación. Si ajusta una instrucción después de haber visto sus errores en este último conjunto, se convierte en un conjunto de desarrollo; entonces prepare una nueva evaluación independiente.
También evite las copias entre lotes: dos mensajes de un mismo hilo, un modelo de correo electrónico reproducido o variantes casi idénticas pueden dar una impresión de generalización. Para nuestro soporte ficticio, una separación por conversación y una revisión de los duplicados serían controles pertinentes. Mantenga los mensajes autorizados, minimice la información identificativa y no envíe ningún dato de clientes sin un marco ya establecido.
Incluya las dificultades reales: frases muy cortas, francés aproximado, solicitudes mezclando dos temas y vocabulario nuevo. Mantenga su frecuencia y su naturaleza. Así podrá explicar si un método tiene éxito sobre todo en las solicitudes evidentes y deriva todas las demás a una persona.
Contar los errores según sus consecuencias
Una matriz de confusión es una tabla que cruza la categoría esperada con la propuesta. Permite ver dónde se equivoca el sistema. En nuestro ejemplo, clasificar una solicitud comercial como técnica hace perder tiempo; clasificar un problema de acceso como comercial puede retrasar aún más su resolución. Por lo tanto, el mismo número de errores no produce el mismo costo para el negocio.
Defina este costo con las personas que manejan las solicitudes. Para el piloto, podría contar el número de reasignaciones, el tiempo de revisión y los casos urgentes mal orientados. Si utiliza una escala numérica, indique que es una elección de su equipo y conserve sus razones. Una ponderación decidida después de ver los resultados favorables haría que la comparación fuera difícil de defender.
Un puntaje alto no significa automáticamente «decisión confiable». La calibración describe la concordancia entre un nivel de confianza anunciado y la frecuencia de decisiones correctas en casos comparables. Para verificarlo, agrupe las decisiones por intervalos de puntaje, cuente los casos y compare la confianza y la corrección observadas. Un intervalo con muy pocos ejemplos aporta poca información: muestre su tamaño en lugar de darle un veredicto definitivo.
La abstención también merece una medida. Si exige una revisión para todos los mensajes difíciles, las orientaciones aceptadas pueden parecer excelentes mientras que el equipo humano conserva la mayor parte del trabajo. Cuente la proporción de solicitudes aceptadas, la proporción a revisar y el tiempo de corrección. Examine los resultados por categoría y por tipo de dificultad.
Comparar antes de adaptar
Su punto de partida, llamado línea base, puede ser una regla simple: algunos términos de facturación, una lista de errores técnicos y una recuperación en caso de conflicto. Agregue si es útil un modelo generalista con una salida limitada. Compare estas soluciones con Clef en las mismas entradas, con las mismas categorías y las mismas reglas de validación. Una adaptación especializada solo se justifica después de esta comparación.
| Medida propuesta | Reglas simples | Modelo generalista | Clef | Clef-flash |
|---|---|---|---|---|
| Errores por categoría | A medir | A medir | A medir | A medir |
| Costo de los errores para el negocio | A medir | A medir | A medir | A medir |
| Parte a revisar | A medir | A medir | A medir | A medir |
| Tiempo de respuesta | A medir | A medir | A medir | A medir |
| Costo y tiempo de recuperación | A medir | A medir | A medir | A medir |
Mida el tiempo del recorrido completo, incluyendo la validación y la posible intervención humana. Anote la configuración, la versión del modelo y la fecha. No reemplace un campo vacío con un resultado del anuncio: esta tabla debe describir su ensayo. Una solución más rápida de predecir puede ser menos útil si requiere más correcciones.
Autorizar un piloto que se puede detener
Comience observando, sin modificar automáticamente las colas de soporte. Compare la sugerencia y la orientación humana, luego examine los desacuerdos. Pueden revelar un error del modelo, una referencia incorrecta o una categoría que precisar. Solucione estas causas antes de volver a realizar una prueba con un protocolo explícito.
Decida de antemano los criterios de aceptación: errores críticos tolerados, carga máxima de revisión y categorías cubiertas. Prevea un retorno inmediato al tratamiento humano si las salidas se vuelven inválidas, si aumentan los errores críticos o si el vocabulario cambia drásticamente. Para este ejemplo, el siguiente paso útil es por lo tanto estabilizar las categorías y el conjunto de prueba. La elección del modelo viene después de este contrato de negocio.
Fuentes y fecha de verificación
Páginas primarias reabiertas y leídas el 6 de octubre de 2026: Cloudflare, lanzamiento de Clef, 1 de octubre ; Cloudflare, ficha oficial Clef en Hugging Face. El corpus sintético, los contratos y los cuadros son propuestas de Partitech. No se realizó ningún benchmark propio, entrenamiento ni llamada alojada para este artículo.