Chatbot de documentación con RAG

El problema

La documentación técnica de EMMA es extensa y está repartida en muchas páginas. Tanto los clientes que integran el producto como el equipo interno tenían que navegarla a mano para resolver una duda concreta, o preguntar a soporte y esperar la respuesta. Hacía falta una forma de preguntar con lenguaje natural y obtener la respuesta al momento, basada solo en lo que dice la documentación.

Qué hice yo

Diseñé la arquitectura y desarrollé el chatbot de principio a fin:

• El proceso que extrae la documentación, la limpia, la fragmenta y genera sus embeddings (vectores que representan el significado de cada fragmento), y la tarea programada que lo ejecuta.
• La búsqueda semántica que localiza los fragmentos relevantes para cada pregunta.
• La API que genera la respuesta en streaming y guarda el historial de la conversación.
• La interfaz del chat.

El despliegue en Kubernetes lo hizo el equipo.

Decisiones clave

Embeddings calculados fuera de línea

La documentación cambia poco, así que los embeddings no se calculan cuando llega una pregunta. Una tarea programada los genera y los guarda en AWS S3, y el servicio los descarga al arrancar. Se valoró usar una base de datos vectorial; guardarlos en S3 separa la generación del consumo, y una pregunta solo paga el coste de buscar y responder.

Fragmentos que conservan su contexto

En lugar de cortar el texto en bloques de tamaño fijo, lo fragmento por secciones, y cada fragmento conserva los títulos de los que cuelga. Un párrafo suelto sobre «configuración» no dice a qué plataforma se refiere; con su jerarquía de títulos, sí.

Búsqueda en tres niveles

Una sola búsqueda falla con preguntas cortas o de seguimiento. El sistema busca primero con la pregunta tal cual. Si no encuentra contenido relevante, añade el historial de la conversación. Si tampoco, pide a un modelo de lenguaje que reformule la consulta, con una técnica basada en HyDE. Cada nivel cuesta más que el anterior, por eso solo se usa cuando el anterior no basta.

Sesiones en Redis

El historial de cada conversación se guarda en Redis y no en la memoria del servicio. Así el chatbot atiende a varios usuarios a la vez sin perder el hilo de ninguna conversación.

Resultado

• Está en producción, al alcance de los clientes y del equipo interno.
• Las dudas sobre la documentación se resuelven preguntando, sin recorrer las páginas a mano ni esperar a soporte.
• El chatbot entiende preguntas de seguimiento: «¿y cómo lo hago en iOS?» después de una pregunta sobre Android.
• Responde en español y en inglés.
• La respuesta se empieza a leer mientras se genera.