IA anti-alucinacion: como garantizar que tu producto de IA no invente datos
Las alucinaciones son el talon de Aquiles de la IA generativa. Cuando tu producto maneja informacion legal, financiera o medica, un dato inventado puede ser catastrofico. Asi construimos un sistema de 5 capas que logra 0% de alucinacion comprobada.
El problema: por que las IAs inventan datos
Los modelos de lenguaje grandes (LLMs) no "saben" cosas. Generan texto estadisticamente probable basandose en patrones. Cuando no tienen informacion suficiente, hacen lo que mejor saben hacer: generar texto que parece correcto pero no lo es.
En aplicaciones triviales — un chatbot de atencion al cliente, un asistente de redaccion — las alucinaciones son molestas pero no criticas. Pero cuando construyes productos para sectores regulados como derecho, finanzas o salud, una alucinacion puede significar:
- En LegalTech: Citar un articulo de ley que no existe. Un abogado presenta eso en un tribunal y pierde el caso (y su reputacion).
- En FinTech: Calcular mal un impuesto o una retencion. La empresa recibe una multa del SAT o el SII.
- En HealthTech: Sugerir una dosis incorrecta o una interaccion medicamentosa inexistente.
En Innova y Cree, la anti-alucinacion no es un feature — es un requisito de existencia. Si LEXIMEX inventara un articulo de ley, toda la plataforma perderia credibilidad instantaneamente.
Capa 1: RAG (Retrieval-Augmented Generation)
La primera linea de defensa es RAG. En vez de dejar que el modelo responda desde su "conocimiento general", forzamos que solo use documentos especificos que nosotros controlamos.
El proceso: la pregunta del usuario se convierte en un vector semantico, se buscan los chunks mas relevantes en nuestra base de datos vectorial (41,000+ chunks en LEXIMEX), y esos chunks se inyectan como contexto en el prompt del modelo. El modelo solo puede responder basandose en ese contexto.
La instruccion clave en el system prompt: "Si la informacion no esta en el contexto proporcionado, di explicitamente que no tienes informacion suficiente para responder. NUNCA inventes datos."
Capa 2: Verificacion de fuente obligatoria
Cada afirmacion del modelo debe incluir la referencia exacta: nombre de la ley, numero de articulo, parrafo especifico. No aceptamos respuestas genericas como "segun la legislacion mexicana...".
El formato forzado es: [Ley X, Articulo Y, Fraccion Z]. Si el modelo no puede proporcionar esta referencia, la respuesta se marca como "sin fuente verificable" y se advierte al usuario.
Esto funciona porque el modelo, al ser forzado a citar, tiene que "buscar" en el contexto RAG la referencia exacta. Si no la encuentra, activa la clausula de "no tengo informacion suficiente" en vez de inventar una cita.
Capa 3: Validacion cruzada automatica
Despues de que el modelo genera su respuesta, un proceso automatico extrae las citas y las valida contra la base de datos de legislacion. Si el modelo dice "Articulo 123 de la Ley Federal del Trabajo", verificamos que ese articulo existe y que el contenido citado corresponde al texto real.
Si la validacion falla — por ejemplo, el modelo cito un articulo que no existe o mezclo contenido de dos articulos diferentes — la respuesta se descarta y se regenera con un prompt mas estricto, o se devuelve con una advertencia visible al usuario.
Capa 4: Score de confianza
No todas las respuestas tienen el mismo nivel de certeza. Calculamos un score de confianza basado en:
- Relevancia del contexto RAG: Que tan cercanos semanticamente son los chunks recuperados a la pregunta original.
- Cantidad de fuentes: Una respuesta basada en 5 chunks es mas confiable que una basada en 1.
- Consistencia interna: Si la respuesta se contradice a si misma, el score baja.
- Validacion cruzada: Si las citas pasaron la Capa 3, el score sube.
El usuario ve un indicador visual del nivel de confianza. Respuestas con score bajo llevan una advertencia: "Esta respuesta tiene confianza limitada. Recomendamos verificar con un profesional."
Capa 5: Auditoria y aprendizaje continuo
Cada interaccion se registra: la pregunta, el contexto RAG usado, la respuesta generada, las citas, el score de confianza y si el usuario reporto un error. Esto crea un dataset que nos permite:
- Detectar patrones: Si el modelo consistentemente tiene problemas con un tipo especifico de consulta, ajustamos el prompt o el indexado.
- Mejorar el RAG: Chunks que nunca son recuperados pueden indicar problemas de indexacion. Chunks que siempre se recuperan pero no son utiles indican ruido.
- Validar la metrica: El 0% de alucinacion no es un claim marketing — es una metrica medida sobre interacciones reales auditadas.
Resultados en produccion
En LEXIMEX, con 291 leyes mexicanas y 41,000+ chunks:
- 0% de alucinacion en casos verificados (el modelo nunca genero un articulo de ley inexistente)
- 97% de precision en anti-alucinacion general (incluyendo matices de interpretacion)
- 99% de tasa de exito en stress tests de carga
En AbogadoIA, con 43 leyes chilenas: resultados equivalentes. El sistema anti-alucinacion es agnóstico a la jurisdiccion — funciona igual para derecho mexicano que para derecho chileno.
Estos numeros los logramos sin sacrificar velocidad ni UX. La respuesta promedio tarda menos de 3 segundos, incluyendo todas las capas de verificacion.
Aplicando anti-alucinacion en otros verticales
El mismo patron funciona fuera de LegalTech. En factoIA, el asistente de contabilidad usa RAG sobre las tablas de impuestos, tasas de AFP y tramos de impuesto unico para no inventar calculos. En Licitometro, las licitaciones provienen directamente de APIs gubernamentales — el modelo no puede inventar una licitacion que no existe.
La regla general: si tu producto maneja datos que deben ser factuales, necesitas anti-alucinacion. Y las 5 capas son un framework adaptable a cualquier vertical.
"La IA que inventa datos es peor que no tener IA. Porque la gente confia en ella y actua basandose en informacion falsa. Anti-alucinacion no es un feature — es una responsabilidad."