Casi todos los proyectos RAG empiezan en el lugar equivocado. La primera reunión se va en embeddings, tamaño de chunk, bases vectoriales, búsqueda híbrida, rerankers y qué modelo debería redactar la respuesta.
Eso es implementación. La primera pregunta es más simple y bastante más incómoda: ¿puede el corpus responder lo que el negocio quiere preguntar?
La prueba de answerability
Antes de construir el retrieval escribimos un set de answerability —si la pregunta tiene respuesta dentro del corpus, y dónde. Tiene tres columnas:
- La pregunta real del usuario.
- El pasaje, registro, política, ticket, contrato o transcripción exacta que sostiene la respuesta.
- La respuesta esperada, incluido el caso en que lo correcto es «no hay evidencia suficiente» o «esto lo decide un humano».
Si el equipo no puede llenar la segunda columna, todavía no hay un sistema RAG. Hay un problema de gestión del conocimiento con presupuesto de IA.
Por qué la similitud no alcanza
La similitud semántica encuentra texto cercano. No demuestra que ese texto cercano responda la pregunta.
La diferencia se paga en producción. Un agente de soporte que resuelve «¿este cliente puede recibir un reembolso?» no necesita el párrafo más parecido sobre reembolsos. Necesita la cláusula de política, el estado del cliente, la fecha de compra, la regla de excepción y el umbral de escalación que juntos hacen defendible la respuesta.
Un retrieval que devuelve contexto plausible pero no demuestra answerability es peor que un buscador: genera confianza sin nadie que responda por ella.
Qué tiene que medir el eval
Para RAG en producción medimos al menos cinco cosas por separado:
- Answerability: la respuesta existe en el corpus.
- Grounding: la respuesta cita la fuente concreta que la sostiene.
- Rechazo: el sistema admite que no puede responder cuando el corpus no da para más.
- Vigencia: el sistema prefiere la fuente actual antes que un duplicado obsoleto.
- Utilidad: el output encaja con lo que el usuario puede hacer a continuación.
Solo después de escribir eso afinamos el chunking, la estrategia de retrieval, el reranking o la elección de modelo.
El modo de fallo que rechazamos
«RAG sobre todos nuestros documentos» no es un alcance. Suele ser la petición de convertir un corpus desordenado en un oráculo sin nombrar preguntas, ni responsables, ni los conflictos entre fuentes de verdad.
Construimos RAG cuando las preguntas son concretas, el corpus se puede inspeccionar y el eval distingue una respuesta con grounding de una simplemente plausible. Si la prueba de answerability falla, la recomendación honesta casi nunca es «más IA». Es limpiar las fuentes, asignarles responsable y acotar el workflow.
Eso también es avanzar. Y evita que el presupuesto del build termine convertido en una demo de búsqueda carísima.