El guard de SKU: precisión contra la contaminación cruzada
6 min de lectura · Calidad
Imagina que un cliente pregunta por el portátil "Asus ROG Strix G16 G614JVR-N3031W". La recuperación semántica trae fragmentos de "Asus TUF Gaming F15" porque son "parecidos". Si el generador mezcla esas specs, la respuesta afirma datos de otro producto. Ese es el fallo más dañino en un asistente de ventas o soporte, y es exactamente lo que ataca el guard de SKU.
Determinista, no probabilístico
En lugar de confiar en que el LLM "se dé cuenta", el guard es una capa de código que se ejecuta antes y después de la generación:
- Extrae códigos de modelo/SKU de la consulta con reglas (evitando confundir "16GB" o "i7" con un SKU real).
- Verifica si ese SKU exacto aparece en las fuentes recuperadas (archivo, chunk o texto).
- Inyecta una instrucción estricta según el resultado.
El guard de factualidad cierra el hueco
El guard de SKU previene la contaminación cruzada, pero no detecta un código inventado. Por eso hay una segunda capa post-generación que extrae los códigos afirmados en la respuesta y comprueba si están respaldados por la consulta o por la evidencia. Si un código no está respaldado, queda marcado en debug_info para el agente.
Se mide, no se promete
El comportamiento se verifica con un golden dataset versionado: cada caso define la consulta, el modelo esperado y los productos prohibidos. El evaluador comprueba de forma determinista model_found (el modelo correcto apareció), contamination (apareció un producto prohibido) y deferred (el sistema derivó cuando debía).
Los tests puros corren en CI en cada push, y antes de migrar de modelo se re-ejecuta el dataset completo contra el candidato. Puedes ver la metodología en la página de benchmarks.
La regla de oro: si el SKU exacto no está confirmado, preferimos derivar a un humano antes que arriesgar una especificación equivocada.