Self-RAG: el sistema que se evalúa a sí mismo

Un RAG normal responde siempre. Self-RAG añade tres puntos de control —¿hace falta buscar?, ¿sirve lo que encontré?, ¿mi respuesta se apoya de verdad en ello?— y con ellos gana algo que un RAG normal no tiene: la capacidad de decir que no sabe. Eso es lo valioso. La parte que hay que mirar con lupa es cómo se implementan esos controles, porque un evaluador que falla hacia el sí no es un evaluador.

01 — Los tres controles

Dónde se para el flujo

¿Necesito retrieval?
    │ No  → responder directamente (conocimiento general)
    │ Sí  ↓
  Retrieval
    │
  ¿Los chunks son relevantes?
    │ No  → descartar / avisar de que no hay información
    │ Sí  ↓
  Generar respuesta
    │
  ¿La respuesta está fundamentada en el contexto?
    │ Sí  → devolver
    │ No  → devolver con advertencia

Los tres son útiles, y cada uno ataca un fallo distinto:

Control	Qué evita
¿Necesito retrieval?	Buscar en el corpus para preguntas de conocimiento general — gasto y ruido innecesarios
¿Son relevantes?	Meterle al modelo chunks que no vienen a cuento, que es como se producen las respuestas erráticas
¿Está fundamentada?	Que el modelo complete con lo que sabe lo que el contexto no decía — la alucinación clásica del RAG

El tercero es el más interesante porque revisa el trabajo ya hecho: compara la respuesta generada contra el contexto que se le dio y decide si se sostiene. Es la única de las tres que puede detectar el fallo después de haberlo cometido.

02 — El coste

Cuántas llamadas cuesta una respuesta

Cada control es una llamada al modelo, y el segundo es una por chunk:

Paso	Llamadas al LLM
¿Necesito retrieval?	1
Evaluar relevancia	1 por chunk recuperado
Generar la respuesta	1
Verificar fundamentación	1
Con k=5: ocho llamadas para responder una pregunta, frente a una de un RAG normal.

Ocho veces el coste y ocho veces la latencia no se justifican en un chat que responde dudas triviales. Se justifican donde una respuesta mal fundamentada tiene consecuencias —soporte técnico que da instrucciones, información legal o médica, cualquier cosa que alguien vaya a ejecutar— y ahí la comparación no es contra el RAG normal, es contra revisar a mano.

La mitigación evidente y que el material no menciona: el control de relevancia se puede hacer en una sola llamada, pasando los cinco chunks juntos y pidiendo una lista de veredictos. Pasa de ocho llamadas a cuatro sin perder nada.

// evaluar cinco chunks en cinco llamadas cuesta cinco veces más que en una

03 — Decir que no

La rama que justifica todo lo demás

De todo el flujo, la parte que de verdad cambia el sistema es la salida por «no hay chunks relevantes»: en vez de generar una respuesta con material que no viene a cuento, contesta que no encontró información. Un RAG normal no tiene esa rama — siempre recupera algo y siempre responde algo.

Y ahí está el criterio para decidir si te compensa: ¿prefieres una respuesta dudosa o un «no lo sé»? En un buscador interno, lo primero. En un sistema que alguien va a creerse, lo segundo — y entonces las ocho llamadas son el precio de poder callarte.

Auditoría La implementación tiene dos defectos que conviene conocer antes de copiarla. Uno: la confianza que devuelve —impresa como porcentaje con dos decimales— es el producto de tres constantes elegidas a ojo (0.9 / 0.6 / 0.3) por la proporción de chunks relevantes. No mide nada: subir k la baja aunque la respuesta sea idéntica, porque el denominador crece; y la rama que responde sin buscar devuelve un 0.9 fijo, sin evaluar. Dos: los tres veredictos se extraen buscando subcadenas en texto libre, y el caso por defecto es siempre el optimista: cualquier respuesta que el modelo no formatee como se esperaba se clasifica como RELEVANTE y FUNDAMENTADA. Un evaluador cuyo modo de fallo es aprobar no es un evaluador. ¿Qué devolvería tu modelo si le pidieras estas tres cosas con salida estructurada en vez de texto libre, y qué pasaría si el caso por defecto fuera el pesimista?

Para hacer

Provocar el «no lo sé»

Monta el control más barato de los tres —el de fundamentación— sobre tu RAG actual: una llamada extra que reciba el contexto, la pregunta y la respuesta generada, y devuelva si la respuesta se apoya en el contexto. Después lánzale diez preguntas cuya respuesta sepas que no está en tu corpus.

Cuenta cuántas veces tu sistema, sin ese control, contestaba igualmente algo con aplomo. Ese número es la razón por la que existe esta familia — y probablemente te sorprenda.