RAG en tu propia nube: las cuatro decisiones que importan más que el modelo

Un asistente sobre la documentación propia es el primer proyecto de IA que hace la mayoría de las empresas, y el que más probabilidades tiene de quedarse atascado entre el piloto y producción. El piloto impresiona porque alguien le hace tres preguntas cuya respuesta ya conoce. Producción decepciona porque doscientas personas le hacen preguntas que nadie anticipó.

La diferencia rara vez está en el modelo. Elijas el que elijas, la tubería de recuperación decide qué llega a leer. Estas son las cuatro decisiones que cerramos en la primera semana de cada proyecto de IA aplicada, en el orden en que deben tomarse.

1. Qué es un fragmento y qué viaja con él

Partir los documentos en ventanas fijas de quinientos tokens es lo que hace cada tutorial y lo que lamenta cada sistema en producción. Un fragmento tiene que ser una unidad con sentido propio: una sección con su título, una tabla con su pie, un procedimiento con todos sus pasos.

Dos cosas deben viajar con cada fragmento al índice:

• Procedencia: sistema de origen, documento, sección, versión y fecha de última modificación. Sin ella, la respuesta no puede citar nada y nadie se fiará.
• Contexto: el título del documento y la ruta de encabezados. Un párrafo que dice "ponlo a 30 segundos" no sirve de nada sin saber que pertenece a "Timeouts > Conexiones a base de datos" del runbook de la plataforma.

Vuelve a fragmentar cuando cambien los documentos, no por calendario. Reindexar entera cada noche una wiki que cambia diez páginas al día es dinero tirado y un día de respuestas desactualizadas.

2. Quién puede leer qué

Esta es la decisión que impide que la mayoría de los pilotos lleguen a producción, así que tómala primero. Tus documentos ya tienen permisos en Confluence, SharePoint, Google Drive o el sistema de tickets. El asistente debe heredarlos, por usuario, en el momento de la consulta.

El patrón que funciona: guardar la lista de control de acceso del origen junto a cada fragmento, resolver los grupos del usuario cuando pregunta y filtrar la búsqueda vectorial por esos grupos antes de ordenar. Filtrar después de ordenar filtra la existencia de documentos a través del propio orden y se rompe cuando los primeros resultados quedan todos descartados.

Si tu almacén vectorial no puede filtrar por metadatos antes de buscar, eso es motivo para cambiar de almacén, no para saltarse el requisito.

3. Cómo sabrás que es bueno

"Parece que responde bien" no es una prueba. Antes de escribir la tubería, escribe el conjunto de evaluación: de cincuenta a cien preguntas reales de usuarios reales, cada una con el documento que debería citar y una respuesta de referencia corta. Los tickets de soporte y los registros de búsqueda son la mejor fuente; contienen las preguntas que la gente hace de verdad, incluidas las mal formuladas.

Después mide tres cosas por separado en cada cambio:

• Recuperación: ¿está el fragmento correcto entre los cinco primeros? Aquí están la mayoría de los fallos, y no cuesta nada evaluarlo porque no interviene ningún modelo.
• Respuesta: ¿coincide con la referencia? Un juez LLM con una rúbrica funciona lo bastante bien para cazar regresiones, siempre que una persona revise una muestra cada semana.
• Rechazo: cuando la respuesta no está en los documentos, ¿lo dice? Cuéntalos. Un asistente que nunca rechaza está inventando.

Ejecuta este conjunto en CI. Un cambio en la estrategia de fragmentación o en el prompt que baje la recuperación del 88 al 71 por ciento debería romper la build, no aparecer en una queja tres semanas después.

4. Cuánto cuesta cada consulta y dónde se ejecuta

El coste por consulta se puede conocer antes de lanzar, y es la cifra que decide si el proyecto sobrevive a su primera revisión de presupuesto. Tres palancas, por orden de impacto:

• Tamaño del contexto. Enviar diez fragmentos de mil tokens cuesta diez veces más que enviar los tres que importan. Recuperar mejor es la optimización de coste más barata que existe.
• Modelos por niveles. Un modelo pequeño clasifica la pregunta y responde las rutinarias; uno mayor se ocupa de aquellas en las que el pequeño no está seguro. En nuestros proyectos, el pequeño atiende entre el 70 y el 80 por ciento del tráfico.
• Dónde se ejecuta. Los modelos disponibles dentro de tu nube, por ejemplo a través de Amazon Bedrock, mantienen los datos en tu cuenta y permiten poner presupuestos y alarmas con las mismas herramientas que ya usas. Alojar un modelo de pesos abiertos propio tiene sentido a partir de cierto volumen, y no antes.

Trátalo como cualquier otro problema de coste cloud: pon una alarma de presupuesto mensual el día que arranque el piloto, con la misma seriedad que una alarma de base de datos. Nadie se fija en un asistente que cuesta 400 euros al mes; todo el mundo se fija en el que costó 9.000 en un mes porque un proceso por lotes empezó a llamarlo.

La decisión del modelo, al final

Cuando estas cuatro están cerradas, la elección del modelo es pequeña: ejecuta el conjunto de evaluación contra dos o tres candidatos y quédate con el más barato que supere el listón. Cambiará en menos de un año de todos modos, y una tubería construida sobre estas decisiones te permitirá sustituirlo en una tarde.