Desarrollo RAG: respuestas de IA precisas a partir del conocimiento de su empresa

¿Qué es el desarrollo RAG y cuándo lo necesita su empresa?

El desarrollo RAG es el trabajo de ingeniería que conecta un modelo de lenguaje de gran tamaño con su propio conocimiento, de modo que las respuestas salgan de sus documentos y no de lo que el modelo memorizó durante el entrenamiento. Una empresa necesita RAG cuando las personas hacen una y otra vez preguntas cuyas respuestas ya existen en algún lugar interno: macros de soporte, manuales de producto, contratos, políticas, tickets anteriores, una wiki en la que nadie encuentra nada. En lugar de reentrenar un modelo, un sistema RAG recupera los pocos fragmentos relevantes para cada pregunta y se los entrega al modelo con la instrucción de responder a partir de ellos y citarlos.

Implementaciones de RAG que nos piden con frecuencia:

• Un asistente interno que responde a las preguntas del personal a partir de políticas, procedimientos (SOP) y la wiki.
• Un asistente de atención al cliente basado en los artículos del centro de ayuda y los tickets resueltos (vea desarrollo de chatbots con IA).
• Búsqueda y respuesta a preguntas sobre contratos, especificaciones o documentación técnica.
• Una capa de "memoria" para un producto de IA, para que el asistente recuerde datos sobre un usuario o una cuenta concretos.

¿Cómo funciona un pipeline RAG en producción?

Un pipeline RAG en producción tiene dos mitades: una parte de ingesta offline que prepara su conocimiento y una parte de consulta online que responde a las preguntas. La mayoría de los problemas de precisión vienen de la parte de ingesta, por eso dedicamos ahí tiempo real de ingeniería en lugar de tratarla como un script puntual.

¿Cómo deben fragmentarse los documentos para RAG?

La fragmentación debe seguir la estructura de sus documentos, no un número fijo de caracteres. Una buena opción por defecto es dividir por encabezados y párrafos en fragmentos de unos pocos cientos de tokens, mantener un pequeño solapamiento y adjuntar metadatos a cada fragmento: título del documento, ruta de secciones, fecha, idioma y quién puede verlo. La ruta de encabezados importa, porque un fragmento que dice "el límite es de 30 días" no sirve de nada si no se sabe que viene de "Reembolsos > Clientes de la UE".

Cada tipo de contenido necesita un tratamiento específico. Las tablas se mantienen enteras o se convierten en afirmaciones por fila. Las preguntas frecuentes se dividen en una pregunta por fragmento. Los contratos largos se fragmentan por cláusula, conservando el número de cláusula. Los registros de chat y los tickets se agrupan por conversación, no por línea. Probamos dos o tres estrategias de fragmentación con el mismo conjunto de evaluación y nos quedamos con la que recupera el fragmento correcto con más frecuencia, en lugar de adivinar.

¿Qué embeddings y qué base de datos vectorial conviene usar?

El modelo de embeddings y la base de datos vectorial deben elegirse según su volumen de datos, sus idiomas y sus reglas de alojamiento, y ambos deben poder sustituirse más adelante. Los mantenemos detrás de una pequeña interfaz en el código, de modo que cambiar de proveedor sea una reindexación y no una reescritura.

Para los embeddings, los modelos alojados de OpenAI y proveedores similares son el inicio más rápido. Los modelos de embeddings abiertos se ejecutan en sus propios servidores cuando los datos no pueden salir de su entorno. El contenido multilingüe (por ejemplo, inglés más francés o ucraniano) necesita un modelo probado en esos idiomas, algo que comprobamos durante la evaluación en lugar de darlo por hecho.

¿Cómo se mide la precisión de un RAG?

La precisión de un RAG se mide con un conjunto de evaluación fijo: de 50 a 200 preguntas reales de sus usuarios, cada una con la respuesta esperada y la fuente de la que debería salir. Sin ese conjunto, cualquier discusión sobre calidad es una opinión. Con él, cada cambio en la fragmentación, los prompts, los modelos o los datos obtiene una puntuación comparable.

Seguimos cuatro cifras:

1. Tasa de acierto de la recuperación: ¿apareció el fragmento correcto entre los primeros resultados?
2. Fidelidad: ¿la respuesta afirma solo lo que dicen los fragmentos recuperados?
3. Corrección de la respuesta: ¿coincide la respuesta con la esperada, según un revisor o un evaluador LLM contrastado con muestras humanas?
4. Calidad del rechazo: cuando la respuesta no está en la base de conocimiento, ¿el sistema lo dice en lugar de inventarla?

En producción añadimos el feedback de los usuarios (pulgar arriba o abajo con un motivo), el registro de las fuentes recuperadas por respuesta, el coste por petición y la latencia. El conjunto de evaluación se ejecuta automáticamente antes de cada versión, igual que las pruebas unitarias.

¿Qué pasa con la privacidad de los datos, los permisos y la elección del modelo?

Un sistema RAG nunca debe mostrar a un usuario un fragmento que no podría abrir en la fuente original. Guardamos las reglas de acceso como metadatos de cada fragmento y filtramos en el momento de la recuperación, de modo que los permisos se aplican antes de que el modelo vea nada. Los datos sensibles pueden cifrarse en la ingesta; en nuestro proyecto AI Grief Companion cada mensaje se cifra con AES-256-GCM por mensaje bajo una clave de sobre KMS, y un usuario puede borrarlo todo con un clic.

Para la etapa de generación trabajamos con las APIs de OpenAI y Anthropic Claude y con modelos abiertos servidos en su propia infraestructura (el mismo proyecto ejecuta adaptadores de Qwen2.5-7B mediante vLLM). La elección depende de las reglas sobre los datos, los idiomas, la latencia y el coste por respuesta. Los prompts se guardan en la base de datos con historial de versiones cuando resulta útil, para poder ajustar el tono y las instrucciones sin publicar código.

¿Cuánto cuesta el desarrollo RAG?

El coste del desarrollo RAG depende sobre todo de cuántas fuentes conecta, de lo desordenadas que están y de lo estrictos que son los requisitos de precisión y permisos. Una prueba de concepto sobre una fuente con un conjunto de evaluación suele llevar de 3 a 6 semanas; un asistente en producción con varias fuentes, permisos e interfaz, de 2 a 4 meses; un RAG a nivel de plataforma entre productos con modelos propios lleva más tiempo.

Los costes de funcionamiento van aparte: tokens del modelo por respuesta, coste de embeddings en cada reindexación y alojamiento de la base de datos vectorial. Estimamos el coste por cada 1.000 preguntas durante la prueba de concepto para que no haya sorpresas, y le damos un presupuesto cerrado para los hitos acordados tras una breve llamada para definir el alcance. Con nosotros, un asistente RAG sobre su conocimiento parte de 5.000 USD; nuestra guía sobre el coste del desarrollo de chatbots con IA cubre los alcances mayores.

¿Dónde hemos construido sistemas RAG y LLM?

Nuestro trabajo de recuperación más completo es el AI Grief Companion para una startup estadounidense: una pasarela de ingesta en Python convierte diez formatos de exportación de chats en una única tabla de mensajes normalizada, y un pipeline de ML construye un perfil de personalidad, un grafo de hechos en Neo4j, memoria RAG y adaptadores LoRA. El chat usa siempre la etapa que esté lista, de modo que los usuarios pueden hablar con el sistema antes de que termine el entrenamiento.

En el lado de producto, AI Resume Master, nuestro propio creador de currículums, usa LLM para generar, reescribir y mejorar el contenido de currículums y cartas de presentación, y alcanzó 50.000 usuarios activos mensuales. Para una visión más amplia de cómo añadir funciones con LLM a un producto existente, consulte servicios de integración de IA y nuestra guía de implementación de RAG.

Cómo trabajamos en proyectos RAG

Empezamos con una breve llamada para definir el alcance y una fase de descubrimiento: revisamos sus fuentes, recopilamos preguntas reales y construimos el conjunto de evaluación junto con su equipo. Después entregamos una prueba de concepto sobre una fuente con la precisión medida, y solo entonces escalamos a más fuentes, permisos y una interfaz de producción. Los ingenieros sénior son responsables de la arquitectura; internamente usamos agentes de programación con IA para avanzar más rápido en la infraestructura.

Si tiene una base de conocimiento sobre la que la gente hace siempre las mismas preguntas, reserve una llamada de definición del alcance y traiga cinco preguntas de ejemplo. Le diremos con honestidad si RAG es la herramienta adecuada.