Auditoría de un asistente de soporte que se inventaba respuestas
Una semana para medir dónde fallaba un asistente con RAG, por qué costaba cada vez más y qué arreglar primero.
Este es un proyecto de ejemplo: describe un tipo de trabajo que hago, no un cliente concreto.
- Sector
- Software B2B
- Encargo
- Auditoría para un equipo de producto
- Mi papel
- Auditoría técnica
- Duración
- 1 semana
- Stack
- Python, LangChain, OpenAI, PostgreSQL, pgvector
El problema
Una empresa de software tiene un asistente de soporte con RAG sobre su documentación. Los usuarios se quejan de respuestas incorrectas y la factura del modelo sube cada mes. Nadie sabe cuántas respuestas fallan ni por qué.
Qué hice
- Reuní con el equipo 80 preguntas reales del historial de soporte y su respuesta correcta.
- Medí el asistente tal como estaba contra esa batería.
- Separé los fallos por causa: el documento correcto no se recupera, se recupera pero se usa mal, o la pregunta no está cubierta por la documentación.
- Revisé el coste por conversación: tamaño del contexto, modelo usado en cada paso y reintentos.
Qué encontré
- La mayoría de fallos venían de la recuperación: fragmentos demasiado grandes y sin el título de la sección a la que pertenecen.
- Cuando no encontraba nada, el asistente respondía igualmente en lugar de decir que no lo sabía.
- Todo el contexto recuperado iba al modelo más caro, también en preguntas de una línea.
Qué entregué
Un informe con los fallos ordenados por impacto, la batería de pruebas lista para ejecutarse en cada cambio y un plan de arreglo en tres pasos, empezando por el troceado de la documentación.