RAG: el modelo no tiene que saber todo de memoria

Los modelos tienen conocimiento congelado en entrenamiento. todo lo que pasó después, o todo lo que es interno a tu organización, no lo saben. Hay dos formas de darles acceso:

1. Tools (Track 3). el modelo invoca funciones que consultan info en tiempo real.
2. RAG. antes de generar, traés datos relevantes y los inyectás en el prompt como contexto.

RAG es la opción dominante cuando:

• Tenés un corpus grande (manuales, docs, transcripciones).
• Las preguntas son sobre contenido, no sobre acciones.
• Querés que las respuestas vengan citadas (verificables).

Las tres etapas

[query del usuario]
        ↓
   retrieve   (búsqueda vectorial sobre el corpus → top-K snippets)
        ↓
   augment    (compone un prompt: snippets + pregunta original)
        ↓
   generate   (LLM responde usando el prompt aumentado, citando fuentes)
        ↓
[respuesta + citations]

Tu trabajo: diseñar la configuración YAML del pipeline. Tres steps, encadenados por output_keys.

La trampa que rompe RAG

El problema más común no es retrieval. es que el generate no maneja el caso "los snippets no son relevantes a la pregunta". Cuando eso pasa, si no le decís al modelo qué hacer, inventa una respuesta con datos sueltos de los snippets. Eso es peor que no responder: parece confiable, lleva citations falsas, y el usuario no se da cuenta.

Regla práctica: en el prompt del generador, siempre incluí algo como "Si los snippets no contienen información relevante, decí que no encontraste eso en el manual." Es la diferencia entre RAG honesto y RAG que alucina.

Cómo se evalúa

5 criterios LLM-judge:

1. retrieve declarado como llamada a tool/función (no LLM).
2. augment recibe pregunta + snippets, los combina explícitamente.
3. generate usa el augmented_prompt (no la pregunta cruda).
4. generate pide citations de los snippets.
5. generate maneja "snippets vacíos / no relevantes" sin alucinar.