Casi todas las demos de RAG que hemos visto en los dos últimos años parecen magia, y casi todos los sistemas RAG en producción que nos han pedido arreglar en los últimos doce meses tenían el mismo conjunto de problemas. La distancia entre la demo y la producción no está en el modelo: está en todo lo que rodea al modelo.
Cuando ponemos en marcha un sistema de generación aumentada por recuperación, lo primero que construimos es el banco de evaluación. No el prompt. No el pipeline de embeddings. El banco de evaluación: normalmente entre 200 y 2.000 ejemplos de referencia que recogen las preguntas que el sistema tiene que responder, con las respuestas que sabemos que son correctas.
Sin ese banco, cada cambio en el sistema es una apuesta. Con él, cada cambio se mide. A los seis meses, cuando se actualiza el modelo, sabes con un clic si la actualización ha mejorado las cosas o las ha empeorado.
Lo segundo que construimos es la recuperación híbrida. BM25 encuentra lo que la búsqueda vectorial se deja. El re-ranking encuentra lo que se deja la recuperación híbrida. La reescritura de consultas rescata lo que estropean las preguntas mal formuladas. Cada una de esas capas te da una mejora medible de recall, y conviene saber cuál de ellas está haciendo el trabajo.
Lo tercero, y es la parte que la mayoría de los equipos se salta, es la observabilidad. Cada recuperación, cada prompt y cada respuesta, registrados con el ID de traza que los vincula a la pregunta original del usuario. Cuando algo falle dentro de seis meses, querrás poder responder «¿por qué ha contestado esto?» en menos de un minuto.
RAG es una de las cosas más útiles que se pueden construir ahora mismo. También es de las más fáciles de enseñar en una demo y de las más difíciles de mantener vivas en producción. No te saltes las partes poco vistosas.
Escrito por el equipo de brainiac/studio. Publicamos trabajo original de los ingenieros, diseñadores y profesionales de marketing que hacen el trabajo, nunca encargado a una agencia de contenidos.