La medición que decide cuánto corre esto
El peso del benchmark viene de su método: se compararon instantáneas mensuales de Wikipedia a lo largo de medio año, y los cambios de hechos se extrajeron de forma automática, con una precisión de extracción del 96,8 %. De ahí salieron 96.124 pares de pregunta y respuesta y 219.463 documentos.
El resultado en presencia de documentos caducados:
| Modelo | Precisión global |
|---|---|
| Modelo grande (70.000 millones de parámetros) | 51,7 % |
| Mediano (8.000 millones) | 40,0 % |
| Pequeño (7.000 millones) | 29,9 % |
El estudio informa de una caída de al menos el 20 % —la tabla muestra los valores absolutos medidos en presencia de documentos caducados— y, en la parte baja del cuadro, un rendimiento por debajo del nivel del azar.
La frase clave, en cambio, es esta: los modelos siguen siendo debidamente inseguros cuando no encuentran nada, pero «tienden a dar respuestas seguras pero incorrectas cuando se topan con información caducada.»
Eso le da la vuelta al razonamiento habitual. Una base de conocimiento incompleta es molesta: el bot dice que no lo sabe. Una base caducada es peligrosa: el bot dice algo falso con aplomo, y el usuario no recibe ninguna señal de que algo va mal.
¿Por qué no se da cuenta el modelo?
Porque no es su cometido. El principio fundacional del RAG es que te fíes del contexto: lo construyes justamente para que el modelo responda desde tus documentos y no desde su propia memoria.
Sobre esto hay una medición de 2026 que cuantifica cuánto cuesta. El estudio miró 4.500 registros para ver qué pasa cuando el texto recuperado contradice lo que el modelo sabe por otro lado:
| Configuración | Precisión con datos contradictorios |
|---|---|
| RAG convencional | 63,0 % |
| Con tratamiento de conflictos | 78,1 % |
Y el detalle más dramático de la misma fuente: cuando se metió en la base de conocimiento un documento con un bulo extendido, la precisión del RAG convencional cayó al 15 %.
Dicho claro: si tienes en la base de conocimiento un documento viejo y retirado, el sistema te lo va a devolver la mayoría de las veces, no porque el modelo sea malo, sino porque es exactamente lo que le pediste.
(Los propios autores del estudio avisan: el mecanismo de la mejora varía según la familia de modelos, así que no hay una solución única consolidada para el conflicto.)
De ahí se sigue directamente dónde hay que resolverlo: no en el modelo, sino en la indexación. Cuando el documento malo ya está entre los resultados, es tarde.
Las cuatro operaciones que no van solas
Mantener la frescura consiste en cuatro operaciones, y dos de ellas no suelen funcionar por sí solas.
| Operación | Qué pasa por defecto |
|---|---|
| Documento nuevo | La única que funciona bien en todas partes. |
| Documento modificado | Suele funcionar, pero la detección de cambios depende del sistema de origen. |
| Documento borrado | Esta es la trampa. En varias plataformas el borrado no se propaga solo. |
| Cambio de permisos | Se aplica con retardo, y los permisos heredados exigen un refresco aparte. |
El borrado es el más peligroso, porque es silencioso. Sacas el documento de la carpeta, el sistema sigue funcionando y el chatbot devuelve durante meses algo que ya no existe.
Según la documentación de los fabricantes, esto varía de una plataforma a otra: en unas funciona automáticamente; en otras solo si lo configuraste en la primera indexación; en otras solo en modo de reconciliación completa; y en otras hay que activar un ajuste de limpieza aparte.
La tarea práctica cabe en una frase: busca la palabra «borrado» en la documentación de tu sistema antes de ponerlo en producción.
Reindexar es más barato de lo que crees
[Cálculo propio] Esto suele sorprender:
| Tamaño de la base | Coste de embedding de un recálculo completo | Cuántas veces cabe en 100 dólares |
|---|---|---|
| 1.000 documentos | ~0,50 USD | 200× |
| 10.000 documentos | ~5 USD | 20× |
| 100.000 documentos | ~50 USD | 2× |
Una reindexación completa mensual de diez mil documentos son sesenta dólares al año. No es una cuestión de coste, es una cuestión de operación.
El coste de verdad está en otro sitio: en reconstruir el índice. La documentación del fabricante enumera con precisión qué se puede cambiar en marcha y qué obliga a tirarlo todo y rehacerlo:
SE PUEDE HACER EN CALIENTE
- añadir un campo nuevo
- cambiar un perfil de puntuación, una lista de
sinónimos o la configuración semántica
- ajustar si un campo existente se devuelve
EXIGE UNA RECONSTRUCCIÓN COMPLETA
- borrar un campo
- CAMBIAR LA DEFINICIÓN DE UN CAMPO (tipo, si es
buscable, filtrable u ordenable)
- asignar o cambiar un analizador
- cambiar de servicio o de plan
La segunda línea de la segunda lista es la que sorprende a todo el mundo: cambiar el modelo de embedding es un cambio de definición de campo. Si pasas a otro modelo, o cambia el número de dimensiones, hace falta una reconstrucción completa del índice. El coste no son los cincuenta dólares, sino la parada y el riesgo.
Para esto hay una solución técnica, y marca la diferencia entre «parada de mantenimiento» y «el usuario no nota nada»: el index alias. Tu aplicación apunta a un alias y no a un índice concreto; construyes el nuevo al lado, lo pruebas y, cuando está listo, rediriges el alias.
El orden, según la documentación:
1. Guarda la definición actual del índice
2. Si tienes capacidad libre, conserva el viejo
mientras construyes y pruebas el nuevo
3. Construye el nuevo con los campos cambiados
4. Cárgalo desde la fuente externa
5. Cambia el alias
(Sobre el tiempo que tarda una reindexación no encontré cifra publicada: depende de los límites de la API, del tamaño de chunk y de la velocidad de escritura del almacén. Mídelo una vez sobre mil documentos tuyos y multiplica.)
Documentos contradictorios
Esta es la parte más difícil, porque no es un problema técnico. Dos documentos dicen cosas distintas sobre lo mismo: la normativa vieja y la nueva, la versión húngara y la inglesa, la plantilla de contrato y el contrato concreto.
El modelo no lo va a resolver por ti. La medición anterior muestra que tratar el conflicto da resultados distintos según la familia de modelos, y que no hay una solución única consolidada.
El único enfoque que funciona es del lado de la indexación, en tres pasos:
- Metadato de vigencia obligatorio en cada documento. Válido desde, válido hasta, versión, estado. Si eso falta, no hay filtrado posible.
- El documento retirado sácalo del índice, no lo filtres. El filtro se olvida, se desactiva y en los índices con chunks no siempre alcanza a los chunks. Lo que no está dentro no se puede devolver.
- Si el sistema encuentra una contradicción, que no elija. El comportamiento correcto es señalar el conflicto y mostrar ambas fuentes, no quedarse con una.
El tercer punto importa porque es la diferencia entre un sistema útil y uno peligroso. Un chatbot que dice «sobre esto tengo dos fuentes que se contradicen, míralas» es más útil que otro que cita una de ellas con aplomo.
¿Quién es el responsable?
Con franqueza: una encuesta sectorial específica sobre quién es el responsable de la base de conocimiento tras un despliegue de IA no la encontré. Nuestra experiencia, en cambio, es que en la mayoría de las organizaciones ese papel no está asignado, y justo por eso caduca la base de conocimiento.
Lo que se puede recomendar con responsabilidad: que el responsable sea quien responde también de los documentos de origen, no quien opera el sistema. De la normativa de recursos humanos responde recursos humanos, no informática. En cuanto eso se separa, actualizar es siempre tarea del otro departamento.
La rutina
1. UN CAMPO DE VIGENCIA EN CADA DOCUMENTO
Válido desde, válido hasta, versión, estado.
Sin este, nada de lo demás funciona.
2. COMPRUEBA PRIMERO EL BORRADO
Mete un documento de prueba, bórralo y pregunta
por él. Si vuelve, tienes trabajo.
3. INCREMENTAL SEMANAL, COMPLETO MENSUAL
El incremental es rápido y barato. El recálculo
completo mensual pesca lo que aquel estropeó.
4. INDEX ALIAS DESDE EL PRIMER DÍA
Que la aplicación apunte a un alias. Sin eso,
todo cambio estructural es una parada.
5. SEÑALA LA CONTRADICCIÓN, NO LA RESUELVAS
Dos fuentes, dos fechas, decide el usuario.
Es más útil que un error dicho con aplomo.
6. REPITE VEINTE PREGUNTAS CADA MES
Las mismas veinte preguntas, mes tras mes.
Si empeora, lo sabrás antes de la queja.
7. NOMBRA RESPONSABLE POR TIPO DE DOCUMENTO
Quien responde de la fuente, no quien opera el
sistema.
8. REVISA CADA AÑO QUÉ SOBRA
Una base más grande no es la meta. La exacta sí.
El segundo punto son cinco minutos y pesca el fallo silencioso más habitual. Conviene hacerlo antes de poner el sistema en producción.
Malentendidos habituales
- «Lo grave es que la base esté incompleta.» Al revés. Según la medición, ante un resultado vacío el modelo se mantiene inseguro; ante uno caducado se equivoca con aplomo.
- «Si borro el fichero, sale del sistema.» En varias plataformas no. Propagar el borrado es un ajuste aparte, y en algunas solo se puede activar en la primera indexación.
- «El modelo ya se dará cuenta de que el dato es viejo.» No. El principio fundacional del RAG es que te fíes del contexto: justo por eso lo construiste.
- «Reindexar es caro.» El recálculo completo de diez mil documentos son cinco dólares. La parte cara es la reconstrucción estructural del índice y la parada.
- «Cambiar el modelo de embedding es solo configuración.» Es un cambio de definición de campo, o sea reconstrucción completa del índice.
- «La contradicción debe resolverla el sistema.» No hay solución consolidada para eso. El comportamiento correcto es señalar, no elegir.
Lo que conviene llevarse
Una base de conocimiento no se estropea por estar incompleta, sino por estar vieja, y en la medición esa diferencia es de al menos el veinte por ciento.
Tres cosas lo evitan, y las tres se configuran la primera semana: metadato de vigencia en cada documento, comprobar con un fichero de prueba que el borrado se propaga, e index alias, para que un cambio estructural no signifique una parada.
Y una rutina mensual que cuesta cinco minutos: vuelve a lanzar esas mismas veinte preguntas. No para sacar una cifra bonita, sino para notar cuándo empieza a empeorar, porque los usuarios no te lo van a decir. Simplemente dejan de usarlo. La planificación del despliegue la desarrolla el artículo sobre el chatbot de conocimiento interno , paso a paso, y la parte de medición le toca al post sobre la evaluación de un sistema RAG , con las cifras.