Por qué el retrieval-augmented generation que más me impresiona es el que se rinde — y las tres decisiones técnicas que lo hacen posible.
TL;DR — Los sistemas RAG tienden a alucinar cuando la documentación no cubre la pregunta. Se puede evitar con tres decisiones técnicas: retrieval con umbral (no llamar al LLM si el score es bajo), prompt con permiso de rendirse (instrucción explícita para admitir “no lo sé”) y citación obligatoria (cada afirmación debe apuntar a un chunk de la fuente). En Polaris — mi demo pública — estas tres reglas conviven en un stack Python + Cloudflare Workers + MongoDB Vector Search.
El demo que casi no publico
La semana pasada le pregunté a mi propio RAG cómo conectar Polaris con Salesforce. Su respuesta empezó así: “Entiendo que quieres integrar Polaris con Salesforce. Lamentablemente, la documentación provista solo cubre HubSpot; no contiene información sobre Salesforce.”
Esa respuesta me hizo sonreír más que cualquier respuesta correcta.
La mayoría de demos de RAG que veo en LinkedIn — usando LangChain, LlamaIndex, o cualquier otro framework — muestran solo el camino feliz: pregunta que la doc cubre, respuesta pulida, aplausos. Nadie muestra la pregunta trampa, esa donde la doc no dice nada y el modelo debe decidir entre inventar o admitir.
El default de un LLM es inventar
Un LLM sin restricciones alucina por diseño. Suena bien, cita fuentes que parecen reales, satisface al usuario. En contextos de bajo costo (chatbot de recomendación de pizza), no pasa nada. Pero yo construí Polaris para triage de tickets de soporte. Ahí un cliente pregunta “¿cómo canjeo mi cupón antes del vencimiento?” — si el RAG inventa un procedimiento inexistente, no solo pierdes al cliente: le mientes con confianza. El peor mundo posible.
Por eso mi criterio no es “¿qué tan bien responde cuando sabe?”, sino “¿qué hace cuando no sabe?”.
Las tres decisiones que definen ese “no lo sé”
1. Retrieval con umbral de similitud
Si el score entre la pregunta y los chunks no supera un mínimo (~0.7 en cosine similarity), no llamo al LLM. Devuelvo “no encontré evidencia relevante” y punto. No hay respuesta a inventar.
2. Prompt con permiso explícito de rendirse
El system prompt le dice al modelo: “si el contexto no responde la pregunta, no adivines. Di ‘no lo sé’ y ofrece lo que sí puedas”. Esa línea vale más que 200 embeddings extra.
3. Citación obligatoria
Cada afirmación debe apuntar a un chunk. Sin cita, no hay afirmación. El usuario ve las fuentes debajo y puede auditar la respuesta.
El costo real de ser honesto
Hay un trade-off. El sistema se ve “menos capaz” en demos pulidas. Y en LinkedIn los demos que hacen ruido son los otros: los que muestran una respuesta magistral a una pregunta hecha a la medida de la doc que el creador cargó.
Pero cuando estás construyendo algo que la gente va a usar en trabajo real — no en el demo del portafolio — la honestidad es el único atributo que sostiene la confianza en el tiempo. Un sistema que se equivoca con seguridad se descarta en la segunda semana. Uno que admite lo que no sabe se queda.
Mi Polaris respondió honestamente sobre Salesforce y luego me redireccionó a la doc de HubSpot que sí tenía. Prefiero eso mil veces sobre un párrafo pulido inventando un procedimiento inexistente.
¿Cuántos RAGs en producción están inventando respuestas ahora mismo, con confianza total y cero fricción, mientras alguien toma una decisión basada en eso?
