Sistema RAG o asistente de IA: checklist antes de empezar

La mayoría de los proyectos de asistentes de IA que decepcionan no fracasan por el modelo. Fracasan porque nadie acordó para qué sirve el asistente, porque el contenido de base estaba incompleto o desactualizado, porque los permisos se dejaron para el final o porque no había forma de saber si un cambio mejoraba o empeoraba las cosas. La elección del modelo importa, pero suele ser una de las decisiones más fáciles.

Esta checklist reúne las preguntas que repasamos antes de construir un sistema de generación aumentada por recuperación (RAG) o un asistente de IA sobre datos de empresa. Úsala para preparar un proyecto interno, para dar el briefing a un proveedor o para comprobar si una propuesta que has recibido cubre lo esencial. No necesitas todas las respuestas el primer día, pero sí deberías saber cuáles siguen abiertas.

1. Caso de uso y criterios de éxito#

Déjalos por escrito antes de que nadie abra un notebook o compare modelos.

• Una tarea principal. Nombra la única tarea que el asistente debe hacer bien en primer lugar, por ejemplo responder a las preguntas de producto de los agentes de soporte o encontrar cláusulas en contratos con proveedores. Los demás casos de uso pueden llegar cuando el primero esté medido; mezclar varios al principio desdibuja tanto los requisitos como la evaluación.
• Los usuarios y su situación. Describe quién pregunta, con qué frecuencia, en qué idioma y desde qué dispositivo, y qué hace con la respuesta. Un experto interno que comprueba las fuentes necesita algo distinto de un cliente que actúa directamente a partir de la respuesta.
• Preguntas reales con respuestas ideales. Reúne entre 20 y 50 preguntas reales de tickets, correos o registros de chat, y pide a un experto en la materia que escriba la respuesta ideal e indique la fuente de la que debería salir. Este conjunto define qué significa «bueno» y se convierte en la semilla de tu conjunto de evaluación.
• Fuera de alcance y negativas. Enumera lo que el asistente no debe hacer: dar asesoramiento legal, médico o financiero, responder más allá de sus fuentes o asumir compromisos en nombre de la empresa. Decide qué debe decir en su lugar y adónde debe dirigir al usuario.
• Línea base del proceso actual. Registra cómo se hace hoy la tarea, cuánto se tarda, quién la hace y cuánto cuesta. Sin una línea base, «el asistente ayuda» es una opinión y no un resultado.

2. Fuentes de datos#

La calidad de las respuestas tiene como techo la calidad y la accesibilidad del contenido que hay detrás.

• Inventario de fuentes. Enumera todas las fuentes que el asistente debería usar: wikis, carpetas de SharePoint o Google Drive, sistemas de tickets, bases de datos, PDF, sitios web. Anota para cada una cómo se puede acceder a ella (API, exportación, crawling) y si ese acceso está permitido.
• Formatos y calidad de los documentos. Busca PDF escaneados que necesiten OCR, tablas complejas, formularios, diapositivas e imágenes con contenido esencial. Las tablas y los escaneos son donde los pipelines ingenuos pierden más información, así que analiza una muestra cuanto antes.
• Responsables y actualidad. Nombra a un responsable de cada fuente y registra con qué frecuencia cambia. Si nadie es responsable del contenido, nadie corregirá las respuestas erróneas que salgan de él.
• Duplicados, versiones e idiomas. Identifica copias obsoletas, borradores y versiones paralelas de una misma política, y decide cuál es la válida. Anota los idiomas tanto de los documentos como de las preguntas, porque la recuperación entre idiomas hay que probarla de forma explícita.

3. Control de acceso y privacidad#

Resuélvelo antes de que ningún dato real salga de tus sistemas.

• Permisos trasladados a la recuperación. Si los usuarios solo pueden ver determinados documentos, la recuperación debe filtrar según los permisos del usuario que pregunta, sincronizados desde los sistemas de origen. Poner instrucciones en el prompt o confiar en que el modelo se calle contenido no es control de acceso.
• Datos personales y base jurídica. Identifica los datos personales en documentos, preguntas y logs, y documenta la base jurídica y la finalidad del tratamiento conforme al RGPD. Implica a tu delegado de protección de datos al principio, no en el lanzamiento.
• Contrato con el proveedor y residencia de los datos. Firma un contrato de encargo del tratamiento con cada proveedor de modelos y de infraestructura, revisa sus subencargados y confirma que el tratamiento puede permanecer en una región de la UE si lo necesitas. Consigue confirmación por escrito de que tus datos no se usan para entrenar los modelos del proveedor.
• Conservación, logs y anonimización. Decide cuánto tiempo se guardan los prompts, los fragmentos recuperados y las respuestas, quién puede leerlos y si los datos personales se eliminan antes de registrarlos. Los logs hacen falta para depurar y evaluar, así que el objetivo es una conservación controlada, no prescindir de los logs.

4. Diseño de la recuperación#

La mayoría de las respuestas erróneas de los sistemas RAG tienen su origen en la recuperación y no en el modelo; con un corpus pequeño y estable, un contexto largo con prompt caching puede sustituir por completo a la recuperación (consulta RAG vs fine-tuning).

• Chunking según la estructura del documento. Divide el contenido por títulos, secciones, elementos de lista y límites de tabla, no por un número fijo de caracteres. Conserva con cada fragmento la ruta de títulos para que el pasaje siga teniendo sentido por sí solo.
• Metadatos y filtros. Guarda con cada fragmento el título, la fuente, la sección, la fecha, el idioma, la versión y los grupos de acceso. Los metadatos son lo que hace posibles el filtrado por permisos, las reglas de «solo la última versión» y unas citas útiles.
• Búsqueda híbrida y reranking. Combina la búsqueda por palabras clave para términos exactos, como códigos de producto, números de artículo y nombres, con la búsqueda vectorial sobre embeddings para el significado, y después reordena los candidatos combinados. Prueba cada paso con tus preguntas de ejemplo en lugar de dar por hecho que los valores por defecto bastan.
• Citas obligatorias. Exige al asistente que cite los pasajes que ha utilizado, con un enlace al documento y a la sección de origen. Las citas permiten a los usuarios verificar las respuestas y a los revisores ver si una respuesta errónea se debe a una mala recuperación o a una mala generación.

5. Elección del modelo y del proveedor#

Elige el modelo cuando ya tengas un conjunto de evaluación, para que la decisión se apoye en tus datos y no en benchmarks genéricos.

• Opción de alojamiento. Compara una API alojada, los mismos modelos u otros similares en una región cloud de la UE y un modelo de pesos abiertos alojado en tu propia infraestructura. Cada opción desplaza el equilibrio entre calidad de las respuestas, control de los datos, esfuerzo de operación y coste.
• Latencia y coste por consulta. Mide el tiempo de respuesta de extremo a extremo y el coste por pregunta respondida con tus propias preguntas de ejemplo, incluidos la recuperación, el reranking y los tokens de entrada y de salida. El prompt caching y los modelos más pequeños para los pasos sencillos pueden cambiar bastante estas cifras.
• Plan alternativo y dependencia del proveedor. Planifica qué ocurre cuando el proveedor se cae o retira un modelo: un segundo proveedor, un modo degradado o un mensaje de error claro. Mantén los prompts, el conjunto de evaluación y la capa de recuperación neutrales respecto al proveedor, para que cambiar sea un ajuste de configuración más una ejecución de la evaluación y no una reescritura.

6. Evaluación#

Si no puedes medir la calidad, no puedes mejorarla ni defender la decisión de salir a producción.

• El conjunto de evaluación, antes de construir. Convierte las preguntas reales de la sección 1 en un conjunto de evaluación versionado, con las respuestas y las fuentes esperadas, y amplíalo con casos difíciles y casos límite. Constrúyelo antes del primer prototipo, no después de la primera demo.
• Calidad de la recuperación y de la respuesta. Mide por separado si se recuperaron los pasajes correctos y si la respuesta es correcta, completa y fiel a esos pasajes. Comprueba la exactitud de las citas: el pasaje citado debe respaldar de verdad la afirmación.
• Tests de negativa y de prompt injection. Incluye preguntas que el asistente debe rechazar y preguntas que sus fuentes no pueden responder, y verifica que lo dice en lugar de inventar. Añade documentos y entradas que intenten anular sus instrucciones o extraer datos de otros usuarios, y confirma que no lo consiguen.
• Ejecuciones de regresión y revisión humana. Ejecuta el conjunto de evaluación completo con cada cambio en los prompts, los modelos, el chunking o los datos, y compara los resultados con la ejecución anterior. La corrección automática con un modelo lo acelera, pero un experto en la materia debería revisar muestras de los resultados con regularidad.

7. Integración y operación#

El asistente tiene que vivir en algún sitio, y alguien tiene que operarlo después del lanzamiento.

• Canal e inicio de sesión. Decide dónde vive el asistente: un widget en el sitio web, Slack o Microsoft Teams, una herramienta interna o un sistema de tickets existente. Usa tu SSO actual para que la identidad y los permisos salgan del mismo sitio que en todo lo demás.
• Traspaso a una persona y feedback. Define cómo llega un usuario a una persona cuando el asistente no puede ayudar, con la conversación incluida en el traspaso. Añade botones de feedback sencillos y lleva el feedback negativo al conjunto de evaluación.
• Modelo de costes y monitorización. Estima el coste por consulta y por mes con el uso previsto y con el uso pico, y configura alertas de presupuesto. Monitoriza la latencia, las tasas de error, las tasas de negativa y el feedback de los usuarios, con los logs anonimizados según lo acordado en la sección 3.
• Reindexación, responsables del contenido e incidentes. Automatiza la reindexación cuando cambien los documentos de origen, incluidas las eliminaciones, para que el asistente nunca cite contenido retirado. Nombra a quien corrige los problemas de contenido y define un proceso de incidentes para respuestas erróneas, dañinas o con fugas de información, que incluya cómo apagar el asistente rápidamente.

8. Criterios go/no-go#

Acuerda las reglas de decisión antes de que lleguen los resultados, para que la decisión no se tome por el efecto de una buena demo.

• Umbrales acordados de antemano. Deja por escrito los niveles mínimos de corrección de las respuestas y de exactitud de las citas en el conjunto de evaluación, la latencia y el coste por consulta aceptables, y tolerancia cero con las respuestas que se salten los límites de permisos. Compara los resultados con la línea base de la sección 1.
• Piloto acotado en el tiempo y con una salida clara. Haz un piloto con un grupo pequeño de usuarios reales durante un periodo fijo, con una persona designada que tome la decisión. Reducir el alcance o parar es un resultado legítimo, y mucho más barato que descubrirlo tras un despliegue completo.

Cómo podemos ayudarte#

Si quieres repasar esta checklist con nosotros, el camino más directo es nuestro AI Proof-of-Value Sprint, de alcance cerrado. En dos semanas definimos contigo el caso de uso, construimos un prototipo de RAG o de agente sobre tus propios datos, creamos un conjunto de evaluación, preparamos un modelo de costes y entregamos un informe go/no-go que puedes llevar a quienes toman las decisiones. Tienes los detalles en nuestra página de Precios y en nuestros servicios de IA y automatización.

Antes de que ninguno de tus documentos llegue a un modelo, acordamos contigo cómo se tratan los datos; puedes leer de antemano cómo tratamos los datos de los clientes en proyectos de IA. Si prefieres empezar con una conversación, solicita una estimación gratuita y describe el caso de uso que tienes en mente.