Retrieval de evidencia en producción: respuestas con fuentes verificables

Por qué RAG y no fine-tuning

Fine-tuning un LLM es costoso, difícil de actualizar y propenso a hallucinations sobre datos que no estaban en el training set. RAG (Retrieval-Augmented Generation) resuelve esto al separar conocimiento de razonamiento: el LLM razona sobre documentos recuperados dinámicamente, no sobre memorización estática. Para datos empresariales que cambian frecuentemente (políticas, manuales, regulaciones), RAG es la arquitectura correcta.

Chunking, embeddings y retrieval

La calidad del RAG depende del retrieval, no del LLM. Chunking incorrecto (chunks demasiado grandes pierden precisión, demasiado pequeños pierden contexto) es la causa principal de respuestas de baja calidad. Estrategias: sentence-based chunking con overlap, recursive splitting por headers, y parent-child chunking donde se recupera el chunk relevante pero se envía el documento padre completo al LLM. Hybrid search (dense embeddings + sparse BM25) supera consistentemente a dense-only.

Evaluación de retrieval y detección de alucinaciones

Métricas de retrieval: Recall@k (¿se recuperaron los documentos relevantes?), MRR (¿el más relevante está primero?), y NDCG (calidad del ranking completo). Para alucinaciones, citation grounding verifica que cada afirmación del LLM esté soportada por un chunk recuperado. Las afirmaciones sin soporte se marcan como no verificadas. Esto requiere un paso post-generación con un modelo evaluador (un segundo LLM o un clasificador ligero).