Indice
Cuando un asistente de IA contesta sobre tu documentación, el problema no es que diga "no lo sé". El problema es que diga una cosa con total seguridad, ponga una cita debajo, y esa cita no respalde nada. Un estudio internacional de la EBU y la BBC sobre más de 3.000 respuestas de ChatGPT, Copilot, Gemini y Perplexity lo dejó claro: el 45% de las respuestas tenía algún problema serio y el 31% fallaba en la atribución de fuentes —citas ausentes, equivocadas o que no sostenían lo que se afirmaba.
Si estás pensando en montar un asistente sobre tus manuales técnicos, tus contratos o tu base de conocimiento —para uso interno o de cara a tus clientes—, ese 31% es justo lo que te tiene que quitar el sueño. Una respuesta sin fuente la descartas. Una respuesta con una fuente que parece buena pero no lo es, te explota en la cara delante de un cliente. En este artículo te explico, sin marketing, qué hace que un sistema RAG cite de verdad, dónde fallan casi todos, y qué deberías exigirle a quien te lo monte.
1. Una respuesta con la fuente inventada es peor que un "no lo sé"
Imagina la escena. Un técnico de campo consulta el asistente de tu empresa: "¿Cuál es el par de apriete de los tornillos de la carcasa del modelo X?". El asistente responde "42 Nm" y debajo añade: "Fuente: Manual X, página 14". Suena perfecto. El técnico aprieta a 42 Nm.
El problema: en la página 14 no pone 42 Nm. Pone 24 Nm, o pone el par de otro modelo, o esa cifra el modelo se la ha sacado de su entrenamiento genérico y la cita es decorativa.
Esto no es un fallo raro. Es el fallo. En el estudio de la EBU, el modo de error dominante no era inventarse datos en el vacío, sino dar respuestas con fuentes que no respaldaban la afirmación, enlaces fabricados y citas a contenido irrelevante. En un contexto de noticias da rabia. En tu documentación técnica, jurídica o de producto, genera responsabilidad: decisiones mal tomadas, garantías mal explicadas, clientes mal informados.
La conclusión incómoda es esta: una cita que parece fiable pero no lo es destruye más confianza que no tener cita. Porque la gente baja la guardia precisamente cuando ve una fuente.
2. ¿Por qué la IA se inventa cosas sobre tu propia documentación?
Aquí hay un malentendido que cuesta caro. Mucha gente cree que si "le metes tus documentos" a un modelo, ya responde con ellos. No funciona así.
Un modelo de lenguaje, por sí solo, responde con lo que aprendió durante su entrenamiento: una mezcla difusa de medio internet, sin tus manuales dentro y sin saber qué es verdad y qué no. Cuando le preguntas algo específico de tu empresa, no tiene el dato, pero está diseñado para sonar convincente, así que rellena el hueco con lo más plausible. A eso lo llamamos alucinación.
La técnica que cierra ese hueco es RAG (Retrieval-Augmented Generation, o generación aumentada por recuperación). Antes de responder, el sistema busca en tus documentos los fragmentos relevantes y se los pasa al modelo como contexto, para que conteste con eso y no con su memoria. Es la base de cualquier agente de IA que tenga que trabajar con conocimiento propio de una empresa, y no por casualidad: Anthropic, OpenAI y Google recomiendan RAG como la técnica principal para conectar un modelo con datos privados.
Pero ojo, y aquí empieza lo importante: montar un RAG no garantiza que el sistema use bien tus documentos. Solo le pone los documentos delante. Que los use de verdad, y que la cita corresponda al dato, es otra historia.
3. Citar la fuente no es lo mismo que decir la verdad (esto casi nadie te lo cuenta)
Aquí va nuestra opinión, y es fuerte. La mayoría de productos de "IA sobre tus documentos" venden una promesa incompleta: "mira, cita la fuente". Y se quedan ahí, como si poner una cita debajo fuera prueba de que la respuesta es correcta.
No lo es. Hay un trabajo académico con un título que resume el problema mejor que cualquier folleto: "Correctness is not Faithfulness in RAG Attributions". Traducido a tu día a día: que la respuesta sea correcta y que la cita respalde esa respuesta son dos cosas distintas. Puedes tener una respuesta correcta con una cita que no la sostiene. Y, peor, una cita a un documento real que no dice lo que el sistema afirma que dice.
Un análisis de grounding en sistemas LLM lo describe con precisión quirúrgica: un documento citado puede ser real mientras el párrafo citado no respalda la afirmación generada. Es decir, el enlace existe, el PDF existe, la página existe… y aun así la frase es falsa.
Por eso, cuando alguien te enseñe una demo de "IA que cita fuentes", la pregunta correcta no es "¿pone la fuente?". Es: "¿el sistema verifica que esa fuente respalda lo que dice, antes de enseñármelo?". Si la respuesta es no, tienes una demo bonita, no un sistema en el que apoyar decisiones.
4. Cómo se consigue que cite el párrafo exacto: las tres vías reales
Que un sistema cite a nivel de párrafo —y no "según el manual" en abstracto— se puede hacer de tres formas, y conviene que sepas cuál te están vendiendo. La investigación reciente sobre citación estructurada en RAG las separa así:
Por prompt. Le pides al modelo, en las instrucciones, que añada la cita de dónde sacó cada afirmación. Es lo más fácil de montar y lo más frágil: el modelo "dice" de dónde lo sacó, pero nadie lo comprueba. Es donde nacen las citas decorativas.
Post-hoc (verificación posterior). El modelo responde y, después, un segundo proceso comprueba qué fragmento del documento respalda cada frase y ancla la cita ahí. Más robusto, porque la cita se ata a evidencia real, no a lo que el modelo cree recordar.
Decodificación restringida. El sistema obliga a que la respuesta se construya pegada a los fragmentos recuperados, de modo que no pueda afirmar nada que no esté en el contexto. Es lo más exigente de implementar y lo más fiable cuando el dato tiene que ser exacto.
Por debajo de cualquiera de las tres, un RAG serio sigue una cadena que importa más que el modelo elegido. Recupera los fragmentos candidatos, los reordena por relevancia real (re-ranking) para quedarse con los mejores tres o cuatro de entre veinte, y devuelve una respuesta estructurada con la cita anclada al fragmento y, cuando aplica, un nivel de confianza. No es magia: es ingeniería de recuperación. Y es exactamente la parte que un producto enlatado no te deja tocar y un desarrollo a medida sí.
5. La capa que separa un RAG de verdad de una demo: verificar antes de enseñar
Esta es la pieza que casi nadie monta porque da trabajo. Y es la que convierte un asistente "que cita" en un asistente fiable.
La idea: antes de mostrarte la respuesta, el sistema la descompone en afirmaciones sueltas y comprueba, una a una, si el contexto recuperado las respalda. Técnicamente esto se hace con modelos de inferencia de lenguaje (NLI) que clasifican cada frase como respaldada, neutra o contradicha por la fuente —el enfoque que usan marcos de evaluación como RAGAS o QAFactEval para medir la fidelidad de una respuesta. Si una afirmación no está respaldada, no se enseña, o se marca.
En Potenzzia esta capa es innegociable cuando el caso es sensible. Y aquí está la diferencia entre nuestro enfoque y un SaaS cerrado: nosotros desarrollamos el motor de recuperación y verificación en código, adaptado a la estructura real de tus documentos y a tu nivel de exigencia. No dependes de las limitaciones de una plataforma genérica que decide por ti cuándo una cita es "suficientemente buena".
Mientras estás en esto, conviene saber detectar los síntomas de un grounding roto, porque aparecen siempre los mismos: citas que apuntan a un texto contiguo en vez de al correcto, respuestas que mencionan entidades que no están en ningún fragmento recuperado, y un goteo de pulgares hacia abajo justo en las respuestas que llevan fuente. Si ves eso en una demo, no es mala suerte: es que falta la capa de verificación.
6. Cuándo el sistema debe decir "no lo sé" (y por qué cambia entre uso interno y de cara al cliente)
Un buen RAG sabe callarse. Cuando la búsqueda no encuentra fragmentos suficientemente sólidos, lo correcto no es improvisar: es reconocer la duda, pedir que se concrete la pregunta o no responder. Que un asistente diga "esto no está en la documentación que tengo" no es un defecto. Es la señal más clara de que el sistema está bien hecho.
Y el umbral para callarse no es el mismo en todos los casos. No existe un único nivel de confianza válido para todo: un asistente interno, un bot comercial y un portal de cara al cliente necesitan listones distintos.
Asistente interno (técnicos, soporte, onboarding): el listón puede ser algo más permisivo, porque hay una persona experta que filtra y la respuesta lleva siempre la cita para verificar de un vistazo. El coste de un "no lo sé" de más es bajo.
De cara al cliente o a un stakeholder (documentación de producto consultable, soporte externo, portales): el listón sube. Aquí preferimos que el sistema derive a un humano o reconozca el límite antes que arriesgar una respuesta mal fundamentada con tu marca delante. El coste de un error es reputacional.
Definir esos umbrales —y las rutas de escalado cuando el sistema no llega— es una decisión de negocio, no solo técnica. Por eso la tomamos contigo, caso por caso, no la dejamos en manos de la configuración por defecto de una herramienta.
7. Caso real: cómo se ve esto en una empresa con documentación técnica densa
8. Errores frecuentes al montar un asistente RAG que "cita fuentes"
Estos son los fallos que más vemos, y casi todos vienen de quedarse en la superficie:
Confundir "muestra la fuente" con "está verificado". Es el error de base. Poner una cita por prompt y dar por hecho que respalda la respuesta. Sin la capa de verificación, la cita es un adorno.
Obsesionarse con el modelo y descuidar el preprocesado. El modelo importa menos de lo que crees. La mayor parte de la calidad está en cómo extraes y troceas los documentos: si las tablas se leen mal, si los diagramas se ignoran, si los chunks parten una idea por la mitad, ningún modelo lo arregla después.
No prever el "no lo sé". Un sistema que siempre responde es un sistema que tarde o temprano inventa. Si en la demo nunca dice "esto no lo tengo", desconfía.
Tratar igual lo interno y lo externo. Sacar a producción de cara al cliente con el mismo umbral de confianza que usas internamente. Es la receta para un incidente con tu marca delante.
Olvidar quién puede ver qué. En cuanto el asistente toca documentación con permisos, la recuperación tiene que respetar esos accesos. Si un usuario no debería ver un contrato, el RAG tampoco puede citárselo.
