Construcción de un RAG agéntico para Obsidian con Claude y un arnés de evaluación para detectar alucinaciones

Un desarrollador en r/ClaudeAI construyó un sistema RAG agéntico sobre su bóveda de Obsidian para que Claude respondiera preguntas de PDFs de ingeniería sin agotar el límite semanal de tokens. El flujo de trabajo: convertir PDFs de ingeniería a markdown, colocarlos en una bóveda de Obsidian, usar un agente barato (Kimi K2.5) para la recuperación BM25 sobre la bóveda, y que Claude solo vea fragmentos relevantes en lugar de libros completos. Esto redujo el costo de tokens por pregunta de ~50k a ~5k.
El nuevo problema: el agente a veces se equivocaba con seguridad — por ejemplo, diciendo "Marco Aurelio escribió sobre la muerte en el Libro IX, sección 3" cuando el pasaje canónico estaba en el Libro IV, sección 5. Lo suficientemente plausible como para requerir verificación manual. Así que el desarrollador construyó un arnés de evaluación usando Claude Sonnet 4.6 como juez LLM, deliberadamente una familia de modelos diferente del agente Kimi para evitar calificar su propia salida.
La rúbrica inicial tenía cuatro categorías, incluyendo un 0.7 "débil pero no incorrecto". Al calificar manualmente, el evaluador humano (el mismo desarrollador, ciego, en un día diferente) también colapsó todo lo límite en 0.7. El número de concordancia parecía respetable, pero en realidad medía un sesgo compartido. Después de cuatro iteraciones de la rúbrica, la versión funcional eliminó por completo la categoría intermedia y añadió una categoría 0.9 para un caso específico: "respuesta correcta, fragmento incorrecto". Este caso antes causaba un falso positivo (1.0 encubriendo una falla de recuperación) o un falso negativo (0.4 castigando una respuesta correcta). La división lo solucionó.
Bajo la nueva rúbrica, la concordancia del juez con el humano en 18 filas pasó de 7/18 (39%) a 17/18 (94%). Salvedades: 18 filas son una muestra pequeña, un solo evaluador (confiabilidad entre evaluadores no establecida), BM25 no es novedoso (pero funciona bien para corpus técnicos/literarios donde la superposición de vocabulario entre consulta y documento es alta). Un resultado negativo: la misma técnica de fragmentación que elevó un corpus en 33pp hizo retroceder otro en 17pp en la misma evaluación — el arnés lo detectó en la primera ejecución.
El artículo completo con la historia de las cuatro iteraciones de la rúbrica, la hoja de trabajo de calibración y la nota sobre el resultado negativo está en Medium. El autor tiene curiosidad sobre otros que usen Claude Sonnet como juez para sus configuraciones RAG/agente, qué rúbrica adoptaron y cómo manejan la confiabilidad entre evaluadores con un solo humano en el ciclo.
📖 Read the full source: r/ClaudeAI
👀 Ver también

Construyendo una Guía de Estilo de Escritura que se Actualiza Automáticamente para Contenido Asistido por IA
Un equipo que construye una plataforma de extracción de voz llamada Noren ha desarrollado una guía de estilo en Markdown de 117 líneas que se reescribe después de cada publicación, usando Claude para hacer cumplir las reglas y prohibiendo palabras que suenan a IA como 'cadencia' y 'optimizar'.

IUM: El indexador de símbolos MCP reduce el uso de tokens de IA en 15.9 veces frente a grep
IUM indexa codebases en una matriz SQLite de eventos de símbolos, exponiendo coordenadas exactas archivo:línea, trazado del grafo de llamadas y búsqueda semántica a través de MCP. Comparado con DataFusion (1,538 archivos) muestra 15.9 veces menos tokens que grep para consultas equivalentes.

Tarea-observador: Una meta-habilidad que automatiza la mejora de habilidades para agentes de codificación de IA
Observador de tareas es un meta-skill que mejora automáticamente todas las habilidades de tu agente de IA, incluyéndose a sí mismo. Registró 600 mejoras en 40 habilidades en 3 meses y automatiza la creación de habilidades a partir de brechas de trabajo.

graphify-ts: El servidor MCP local reduce los tokens de revisión de PR de Claude Code de 63K a 8.7K
graphify-ts construye un grafo de conocimiento local de tu código fuente usando tree-sitter AST + comunidades Louvain + BM25 + rerank opcional ONNX, exponiéndolo a través de MCP stdio. En pruebas de producción, redujo los tokens de entrada en 2.6x y la latencia en 2.8x para consultas de código, y recortó los prompts de revisión de PR de 63K a 8.7K tokens.