Arquitectura RAG en una empresa: de dónde sale cada respuesta
Cuando un asistente montado sobre los documentos de la empresa responde mal, la reacción por defecto es cambiar de modelo. Casi nunca es el problema.
En los sistemas que he revisado, la causa está en las tres piezas anteriores: de qué documento salió la respuesta, cómo estaba troceado ese documento y qué se buscó exactamente antes de redactar.
Definición
Una arquitectura RAG tiene cuatro piezas: la fuente, el troceado, el índice y el modelo que redacta. Cuando la respuesta sale mal, casi siempre falló una de las tres primeras.
Las cuatro piezas
Y por qué importa el orden: cada una recibe lo que produjo la anterior, así que un fallo arriba no se puede corregir abajo.
Una arquitectura RAG tiene cuatro piezas: la fuente, el troceado, el índice y el modelo que redacta. Cuando la respuesta sale mal, casi siempre falló una de las tres primeras.
- 01
La fuente. Qué documentos entran, quién los actualiza y cuál manda cuando dos se contradicen.
- 02
El troceado. Cómo se parte cada documento en fragmentos recuperables.
- 03
El índice. Cómo se busca y qué fragmentos se traen para responder.
- 04
El modelo. Redacta la respuesta con lo que le llegó, y sólo con eso.
El modelo no puede inventar una respuesta correcta si el índice le trajo el fragmento equivocado. Y no puede saber que le trajeron el equivocado.
1 · La fuente, que es donde se decide casi todo
La pregunta que hay que responder antes de indexar nada es cuál es la versión oficial de cada cosa.
Toda empresa mediana tiene la misma política escrita en tres sitios con tres redacciones distintas: el manual, la web y lo que el equipo de atención responde de verdad.
Si los tres entran al índice, el sistema va a responder una de las tres al azar y a convertirla en oficial sin que nadie lo haya decidido.
Esta conversación de una hora, decidir cuál manda, es el trabajo con más retorno de todo un proyecto de RAG. Se salta siempre porque parece administrativa y porque obliga a que alguien admita que su versión no es la buena. Y es exactamente lo que separa un asistente fiable de uno que hay que revisar siempre.
Hay una decisión práctica que suele destrabar esa conversación cuando se atasca: no hace falta unificar las tres versiones, basta con ordenarlas.
Se declara una como oficial para el índice y las otras dos se quedan fuera. No hay que reescribir nada ni convencer a nadie de que su versión era peor: sólo hay que decidir cuál entra.
La unificación real puede venir después, y normalmente viene sola cuando el sistema empieza a responder siempre lo mismo y las diferencias se vuelven evidentes.
2 · El troceado, la pieza más subestimada
Los documentos se parten en fragmentos porque no cabe todo en cada consulta. Cómo se parten decide qué se puede responder.
El error clásico es partir por número de caracteres. Un fragmento que corta una tabla por la mitad, o que separa la condición de su excepción, produce respuestas incompletas que suenan completas.
- Partir por estructura, no por longitud: por sección, por artículo, por apartado.
- Arrastrar el encabezado en cada fragmento, para que se sepa de dónde salió.
- Mantener juntas condición y excepción. Es donde más se equivoca un sistema mal troceado.
- Guardar la referencia al documento y la sección de origen.
La cuarta es la que permite citar la fuente en la respuesta, y citar la fuente es lo que convierte al sistema en verificable.
3 · El índice y la búsqueda
Aquí es donde se decide qué fragmentos ve el modelo, y por tanto qué puede responder.
La búsqueda por significado, que es la que usa una base de datos vectorial, encuentra fragmentos que hablan del tema aunque no compartan palabras. Es potente y falla en un caso concreto: cuando la consulta contiene un código, una referencia o un nombre propio exacto.
Por eso lo que funciona en empresas casi siempre es combinar las dos búsquedas: por significado y por coincidencia literal. La combinación cubre lo que cada una se pierde.
La otra decisión es cuántos fragmentos se traen. Pocos y falta contexto; muchos y el modelo se pierde entre información irrelevante.
4 · El modelo, que es la pieza intercambiable
Redacta con lo que le llegó. Su trabajo es no salirse de ahí, y eso se consigue con la instrucción y no con el tamaño del modelo.
- Responder sólo con los fragmentos recibidos.
- Decir que no sabe cuando no está en ellos, que es la instrucción más importante y la más ignorada.
- Citar de qué fragmento salió cada afirmación.
La segunda es la que separa un asistente útil de uno peligroso. Un sistema que prefiere inventar antes que admitir que no encontró nada es peor que no tener sistema, porque genera confianza injustificada.
Cómo diagnosticar una respuesta mala
En orden, y sin tocar el modelo hasta el final. Casi siempre se resuelve antes.
- 01
¿La información existe en alguna fuente indexada? Si no, no es un problema de RAG: falta el documento.
- 02
¿El índice trajo el fragmento correcto? Se mira qué fragmentos se recuperaron para esa consulta.
- 03
¿El fragmento contenía la respuesta completa? Si estaba cortada, es troceado.
- 04
¿El modelo tenía la información y aun así respondió mal? Recién aquí es del modelo, y es el caso menos frecuente.
Sin este orden, la conversación se va directa al paso cuatro, se cambia de modelo, no mejora nada y se concluye que RAG no funciona.
Una herramienta que ahorra mucho tiempo en este diagnóstico: guardar, junto a cada respuesta, qué fragmentos se recuperaron.
Con eso, el paso dos deja de ser una investigación y se convierte en mirar una lista. Sin eso, cada diagnóstico exige reproducir la consulta y esperar que el resultado sea el mismo.
Es un campo más en el registro y cambia por completo la velocidad de corregir.
Lo que casi nadie diseña: qué pasa cuando el documento cambia
Un sistema RAG se monta con la foto de los documentos del día que se montó. Y los documentos cambian.
Si no hay un proceso de reindexado, el asistente responde con la política del año pasado con total seguridad. No hay señal de error: hay una respuesta obsoleta bien redactada.
- Quién avisa cuando un documento cambia.
- Cada cuánto se reindexa, y si es automático o manual.
- Qué pasa con la versión anterior, que debería salir del índice.
Las tres son de proceso, no de tecnología, y son las que deciden si el sistema sigue siendo fiable a los seis meses.
Permisos: quién puede ver qué
El riesgo específico de RAG en una empresa: el índice no distingue quién pregunta si nadie lo diseñó para distinguirlo.
Si en el índice entran documentos de recursos humanos junto con manuales de producto, cualquiera que pregunte de la forma correcta puede recibir un fragmento que no le correspondía ver.
Se resuelve de dos formas y conviene elegir explícitamente: índices separados por nivel de acceso, o filtrado por permiso del usuario en el momento de la búsqueda. La primera es más simple y más segura; la segunda es más flexible y más fácil de equivocar.
Cuándo RAG no es la respuesta
Se ha convertido en la solución por defecto y hay casos donde es la herramienta equivocada.
- Cuando el dato está en una base y no en documentos. Ahí lo que hace falta es una consulta, no una búsqueda por significado.
- Cuando la respuesta exige calcular. Un modelo redactando sobre fragmentos no es una hoja de cálculo.
- Cuando los documentos son pocos y estables. A veces caben enteros en la consulta y no hace falta índice.
- Cuando lo que falta es que alguien escriba la política. RAG no puede recuperar lo que no existe.
La cuarta es la más frecuente en empresas medianas, y la más incómoda de decir en la reunión donde ya se aprobó el proyecto.
Hay un quinto caso que aparece en empresas medianas y conviene reconocerlo a tiempo: cuando lo que se busca es una sola tabla.
Si toda la pregunta se responde consultando un listado de precios o un catálogo estructurado, montar un índice de texto encima es dar un rodeo caro.
La señal es que las respuestas correctas siempre salen del mismo documento y siempre son un dato puntual. Ahí hace falta una consulta, no una búsqueda.
Preguntas frecuentes
¿RAG o afinar el modelo con nuestros datos?
Para información que cambia y que hay que citar, RAG casi siempre. Afinar sirve para cambiar cómo responde el modelo, no para darle conocimiento actualizado. El contraste completo está en RAG contra fine-tuning, y en la mayoría de casos empresariales la respuesta es empezar por RAG.
¿Cuántos documentos hacen falta para que valga la pena?
No es cuestión de cantidad sino de si la información cambia y de si hay que citarla. Con veinte documentos estables que caben en una consulta, montar un índice es sobreingeniería. Con doscientos que se actualizan, hace falta desde el primer día.
¿Por qué el asistente responde cosas que no están en ningún documento?
Porque le falta la instrucción de responder sólo con lo recuperado y de admitir que no sabe. Sin esa instrucción, el modelo rellena con conocimiento general, y como lo redacta igual de bien nadie nota la diferencia. Es el fallo más común y el más fácil de corregir.
¿Se puede montar sobre documentos en PDF escaneados?
Se puede si antes se extrae el texto, y la calidad de esa extracción determina el techo de todo lo demás. Un PDF escaneado con texto mal reconocido produce fragmentos con errores que el sistema va a citar como si fueran correctos. Conviene revisar una muestra antes de indexar todo.
¿Cada cuánto hay que reindexar?
Depende de cada cuánto cambien los documentos, y lo importante es que sea un proceso definido y no una tarea que alguien recuerde. Para políticas que cambian dos veces al año, un reindexado manual con aviso basta. Para catálogos o precios, tiene que ser automático.
Fuentes
Este artículo sintetiza y pone en contexto de negocio material público de estas fuentes. Léelas directo; aquí solo se agrega criterio de implementación.
- Anthropic documenta las prácticas de recuperación de contexto y por qué la calidad del fragmento recuperado determina la calidad de la respuesta. anthropic.com/engineering
- Google Cloud documenta los patrones de arquitectura de recuperación aumentada en entornos empresariales, incluida la combinación de búsqueda literal y por significado. cloud.google.com
- IBM documenta el gobierno de datos aplicado a bases de conocimiento, incluida la separación por nivel de acceso que sostiene la sección de permisos. ibm.com/topics/ai-governance
Sigue explorando
Qué es RAG y cómo se usa en una empresa
Qué es RAG y cómo se usa en una empresa: qué problema resuelve, qué datos necesitas antes de intentarlo y por qué la mayoría de proyectos falla.
TecnologíasQué es una base de datos vectorial y para qué sirve en una empresa
Para dirección: qué es una base de datos vectorial, qué problema resuelve, en qué se diferencia de la base que ya tiene tu empresa y cuándo es sobreingeniería.
ComparativasRAG vs. fine-tuning: cómo elegir cuando quieres que tu IA sepa tu información
RAG vs fine-tuning: cuándo conectar la IA a una base que se actualiza sola y cuándo vale la pena reentrenar el modelo. Criterio, no hype técnico.
GlosarioCómo crear una base de conocimiento con IA para tu empresa
Cómo crear una base de conocimiento con IA para tu empresa: qué documentos entran, cómo se ordenan y por qué el problema nunca es el modelo.
TecnologíasArquitectura empresarial de IA: cómo encaja con lo que ya tienes
Cómo encaja una arquitectura empresarial de IA con el ERP, el CRM y los datos que ya existen, y qué decisiones hay que tomar antes de construir nada.
El siguiente paso
No son artículos relacionados al azar: es el orden en el que esto se entiende y se aplica.
Tecnologías · Arquitectura RAG en una empresa: de dónde sale cada respuesta
Lo siguiente que conviene entender
Cómo se ve aplicado a un proceso real
Cuando quieras aplicarlo
Siguiente paso recomendadoArquitectura IA
El framework propio para construir la empresa con IA, no decorarla con un chatbot.
Las piezas técnicas, en criterio de negocio · Playbook AI Native
