La mayoría de los proyectos RAG empieza en el lugar equivocado. La primera reunión habla de embeddings, tamaño de chunks, bases vectoriales, búsqueda híbrida, rerankers y qué modelo debería sintetizar la respuesta.
Eso es implementación. La primera pregunta es más simple y más incómoda: el corpus puede responder las preguntas que el negocio quiere hacer?
La prueba de answerability
Antes de construir retrieval, escribimos un set de answerability. 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, incluyendo cuándo la respuesta correcta es "no hay evidencia suficiente" o "preguntar a un humano."
Si el equipo no puede completar la segunda columna, todavía no hay sistema RAG. Hay un problema de gestión de conocimiento con presupuesto de IA.
Por qué similitud no alcanza
La similitud semántica encuentra texto cercano. No prueba que ese texto cercano responda la pregunta.
Esa diferencia importa en producción. Un agente de soporte que pregunta "este cliente puede recibir un reembolso?" no necesita el párrafo más parecido sobre reembolsos. Necesita la cláusula de política, estado del cliente, fecha de compra, regla de excepción y umbral de escalación que hacen defendible la respuesta.
Un sistema de retrieval que devuelve contexto plausible pero no puede probar answerability es peor que un buscador. Crea confianza sin accountability.
Qué debe medir la evaluación
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 específica que la sostiene.
- Rechazo: el sistema dice que no puede responder cuando el corpus no alcanza.
- Freshness: el sistema prefiere la fuente vigente sobre duplicados obsoletos.
- Accionabilidad: el output encaja con lo que el usuario puede hacer después.
Solo después de escribir eso afinamos chunking, estrategia de retrieval, reranking o elección de modelo.
El modo de falla que rechazamos
"RAG sobre todos nuestros documentos" no es un scope. Suele ser una solicitud para convertir un corpus desordenado en un oráculo sin nombrar preguntas, owners ni conflictos de fuente de verdad.
Construimos RAG cuando las preguntas son concretas, el corpus es inspeccionable y la evaluación puede distinguir una respuesta grounded de una plausible. Si falla la prueba de answerability, la recomendación honesta normalmente no es "más IA." Es limpieza de fuentes, ownership y un workflow más acotado.
Eso sigue siendo progreso. Evita que el presupuesto de build se convierta en un demo de búsqueda muy caro.