RAG sin RAG: cómo crear un índice de investigación para Claude

El proyecto de este fin de semana empezó con una necesidad simple: recopilar las transcripciones de unos 20 vídeos de YouTube del canal de mi cliente, para un corpus de investigación. El objetivo era usar con precisión los datos de YouTube para referenciarlos en el contenido que estamos construyendo.

---

Para capturar transcripciones de YouTube, TikTok o Instagram, Supadata es, sinceramente, el servicio a usar. Simplemente funciona, que es más de lo que puedo decir de la mayoría de APIs de transcripción que he probado.

Para aquellos de vosotros que ya estéis familiarizados con configurar un servidor MCP, aquí está la configuración más sencilla:

{
  "mcpServers": {
    "@supadata/mcp": {
      "command": "npx",
      "args": ["-y", "@supadata/mcp"],
      "env": {
        "SUPADATA_API_KEY": "YOUR-API-KEY"
      }
    }
  }
}

En fin. Puede que hayas leído investigación reciente sobre cómo la precisión de RAG se desploma según el tamaño del corpus. Y, en cualquier caso, la mayoría de proyectos individuales son demasiado pequeños para la infraestructura de RAG. Por eso construí en su lugar una solución de «RAG sin RAG».

Mientras construía el corpus de investigación para una serie de artículos, documenté el trabajo. ¡Allá vamos!

¿Por qué no usar simplemente RAG?

Aparte de que estamos hablando de un corpus de 100.000 palabras, me topé por casualidad con la investigación de Stanford mientras comprobaba si me estaba dejando algo obvio. Resulta que RAG no es la bala de plata que venden los proveedores.

El paper: «Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools», de Magesh et al. (Stanford, marzo de 2025), probó sistemas basados en RAG de LexisNexis y Thomson Reuters. Son implementaciones «de nivel empresarial» con enormes bases de datos jurídicas detrás.

El paper descubrió que los sistemas RAG del estudio alucinaron un 17-33 % de las veces. El AI-Assisted Research de Westlaw fue preciso solo el 42 % de las veces, alucinando casi el doble que otras herramientas probadas. Para el ámbito legal en particular, esto queda muy mal.

Este gráfico lo resume muy bien:

La precisión de la búsqueda semántica se degrada a medida que crece el corpus: el paso de recuperación se convierte en el cuello de botella. Personalmente, cualquier cosa por encima de 1.000 documentos me empieza a poner nervioso.

RAG añade una complejidad que solo compensa a escala masiva y con bases de datos vectoriales mantenidas profesionalmente. Si eres un proveedor como Hubspot y tienes los recursos de ingeniería para evaluar la salida, vale; pero sospecho que la documentación de Hubspot se mueve en el rango de 1-5k documentos de todos modos. ¿Para un proyecto local de Claude Desktop con 20 transcripciones? Es una exageración de ingeniería que introduce fallos sin llegar a resolver el problema real.

Si estás construyendo sistemas en producción con miles de documentos y necesitas similitud semántica sobre contenido dinámico, RAG tiene todo el sentido, y pronto cubriré los fundamentos de RAG. El artículo de hoy trata específicamente del caso más sencillo: colecciones de investigación estáticas en las que conoces la estructura o, al menos, puedes fijar el contexto a su alrededor.

Requisitos previos: comprensión básica de la estructura JSON y de los proyectos de Claude Desktop con colecciones de documentos. Saber configurar un MCP (los MCP de hoy son Desktop Commander y Supadata; el artículo de Desktop Commander te explica cómo instalar un MCP).

Índices problemáticos, pero sencillos

Obviamente, necesitas descargar cada transcripción y guardarla en un directorio de trabajo fijo. Como parte del prompt (que hubo que repetir varias veces para obtener todas las transcripciones) empecé con un archivo index.md básico que listaba los nombres de archivo de las transcripciones y los temas. Se veía así:

# Research Index

- yt-001-trail-braking.txt - Trail braking technique
- yt-002-throttle-control.txt - Balancing throttle in slow corners
- yt-003-slip-angle.txt - Slip angle theory
- And so on...

Esto no funciona bien.

1. No se pueden consultar relaciones — ¿qué transcripciones se complementan? Ni idea.
2. No hay insights almacenados — hay que volver a leer archivos enteros para extraer los puntos clave
3. No hay profundidad técnica — no se puede filtrar contenido de principiante frente a avanzado
4. El despilfarro de tokens persiste — sigue habiendo que cargar varios archivos para encontrar lo que necesitas

Un índice sencillo es solo una tabla de contenidos. No captura la estructura de tu base de conocimiento. El problema realmente gordo es que si citas el archivo index.md en tu prompt hay muchas probabilidades de que la IA se proponga leer las 100.000 palabras completas, lo que te mandará al banquillo de la ventana de contexto.

Así que, tras descargar la carpeta completa de transcripciones, construí dos archivos que funcionan juntos:

1. research-index.json — metadatos legibles por máquina con campos buscables
2. research-guide.md — clústeres, ejemplos y estrategias legibles por humanos

El prompt era muy sencillo, pero es un poco largo para pegarlo en WordPress; aquí está.

¿Por qué JSON y un archivo MD? Las máquinas parecen funcionar mucho mejor con JSON para consultas; los humanos necesitan Markdown para entender. Intentar servir a ambos públicos con un único archivo grande crea un desastre.

La estructura JSON

Aquí está el ejemplo de mi colección de transcripciones:

{
  "research_base": "simracing-driving-technique",
  "created": "2025-01-05",
  "total_transcripts": 19,
  "transcripts": [
    {
      "id": "yt-001",
      "filename": "youtube-insights-trail-braking-technique.txt",
      "path": "articles/simracing-driving-technique/research/youtube-insights-trail-braking-technique.txt",
      "title": "Trail Braking Technique",
      "source_url": "[youtube_url]",
      "duration_mins": 10,
      "topics": ["trail_braking", "weight_transfer", "corner_entry"],
      "key_insights": [
        "Trail braking overlaps braking with turning for efficiency",
        "80% braking in straight line for hairpins, 20% trail braking",
        "Smoothness is vital - any bumpiness disturbs weight transfer",
        "Load cell brake pedals measure pressure making trail braking easier"
      ],
      "relevant_to": ["cornering_fundamentals", "advanced_braking", "slip_angle"],
      "technical_depth": "intermediate",
      "equipment_mentioned": ["load_cell_brake_pedal", "force_feedback_wheel"]
    }
  ]
}

Los campos críticos:

• topics — etiquetas para filtrar («trail_braking», «throttle_control»)
• key_insights — pepitas de oro preextraídas (nunca volver a leer el archivo completo)
• relevant_to — red de referencias cruzadas que mapea relaciones
• technical_depth — orientación al público (principiante/intermedio/avanzado)

Esta estructura permite consultas como:

// Find all advanced trail braking content
const advanced = index.transcripts.filter(t => 
  t.topics.includes('trail_braking') && 
  t.technical_depth === 'advanced'
);

// What's related to corner exit speed?
const related = index.transcripts.filter(t =>
  t.relevant_to.includes('corner_exit_speed')
);

La guía estratégica en Markdown

El JSON es consultable, pero no es tan amigable para las personas. Mi archivo Markdown complementario aporta:

Clústeres de temas organizados por caso de uso:

## Fundamentals Cluster (Load Together)

**Core theory that works together:**
- yt-001: Trail Braking Technique (how)
- yt-003: Slip Angle Theory (why)  
- yt-011: Racing Line Fundamentals (where)

**Why these three:** Trail braking is the technique, slip angle explains why it works, racing line shows where to apply it. Loading all three gives complete mental model.

Ejemplos de estrategia de búsqueda:

## Query Pattern: "Find all X content"

**Advanced braking techniques:**
topics.includes('trail_braking') && technical_depth === 'advanced'
Returns: yt-001, yt-005

**Wet weather driving:**
topics.includes('wet_weather')
Returns: yt-015, yt-016

La guía hace que el sistema sea detectable. Ojeas los clústeres, identificas los IDs relevantes y luego cargas solo esos archivos concretos.

¿Ahorro real de tokens?

Creo que sí: ¡el método antiguo se estaba parando después de solo 3 transcripciones!

• Cargar las 20 transcripciones
• Coste en tokens: ~100.000+ tokens
• Claude intenta procesarlo todo a la vez
• Lento, caro, propenso a perder detalles, probablemente pierde el hilo

Con este sistema:

1. Consultar research-index.json para obtener los IDs de transcripción relevantes
2. Cargar solo esos 3-5 archivos
3. Coste en tokens: ~20.000 tokens
4. Extracción centrada a partir de insights preidentificados

Resultado: ~80 % de reducción de tokens.

El ahorro se acumula porque no solo reduces tokens, sino que mejoras la calidad. Claude puede centrarse de verdad en el contenido relevante en lugar de intentar sintetizar transcripciones dispares a la vez.

Aquí tienes un prompt que referenciaría los archivos correctos en el orden correcto:

Carga C:\dev\content-machine\articles\simracing-driving-technique\research\research-index.json Encuentra las entradas etiquetadas con "trail braking" Carga los archivos doc_summary.md e index.md relevantes de esas carpetas

Esto es lo que hace que el patrón funcione mejor que un índice sencillo.

Mira el campo key_insights:

"key_insights": [
  "Small throttle (10-50%) maintains speed through tight corners",
  "Rear diff grips track when throttle applied, balances car",
  "Mental trick: Keep engine note high to prevent imaginary bomb",
  "Most effective in first/second gear corners and chicanes"
]

Estos son hallazgos contraintuitivos extraídos durante el análisis inicial de la transcripción, de modo que nunca tienes que volver a leer la transcripción completa para obtener estos insights. Se almacenan como metadatos.

Cuando operamos en modo investigación:

1. Consulta el índice en busca de transcripciones relevantes
2. Lee los arrays key_insights
3. Carga solo las 3-5 transcripciones completas que necesitan más detalle
4. Referencia los insights durante la redacción del artículo

Esto es fundamentalmente distinto de RAG porque no hay búsqueda semántica ni similitud vectorial. Es filtrado puro de metadatos con relaciones curadas por humanos.

Construye tu propio índice de investigación

Así puedes replicar este patrón para cualquier colección de documentos. Asumo que ya has recopilado los documentos en un único directorio de trabajo.

Paso 1: analiza tu corpus

Para cada documento, extrae:

• Topics (formato minúsculas_con_guion_bajo: «api_design», «error_handling»)
• Key insights (5-7 puntos contraintuitivos o no obvios)
• Related concepts (¿a qué otros temas conecta esto?)
• Technical depth (principiante/intermedio/avanzado)
• Prerequisites (¿qué deberían saber primero los lectores?)

Crea una entrada JSON:

{
  "id": "doc-001",
  "filename": "api-rate-limiting.md",
  "path": "research/api-rate-limiting.md",
  "title": "API Rate Limiting Best Practices",
  "topics": ["api_design", "rate_limiting", "redis"],
  "key_insights": [
    "Token bucket allows bursts whilst maintaining average rate",
    "Sliding window more accurate than fixed window",
    "Redis INCR with EXPIRE creates race conditions - use Lua script"
  ],
  "relevant_to": ["caching_strategies", "redis_patterns", "api_security"],
  "technical_depth": "intermediate",
  "tools_mentioned": ["redis", "nginx"]
}

Paso 2: mapea las relaciones

Esta es la parte que lleva tiempo pero crea el valor real.

Para cada documento, pregúntate:

• ¿Qué temas explica esto?
• ¿Qué conceptos asume que ya conoces?
• ¿Qué deberías leer después de esto?
• ¿Qué otros documentos complementan a este?

Rellena el array relevant_to con etiquetas de temas relacionados. Esto crea una red de referencias cruzadas que habilita el descubrimiento.

Paso 3: crea clústeres de temas

Agrupa los documentos relacionados en conjuntos coherentes:

## API Design Fundamentals

**Core concepts (read together):**
- doc-001: Rate Limiting
- doc-003: Authentication Patterns  
- doc-007: Error Response Design

**Why together:** Understanding rate limits requires knowing auth context, and error responses need to communicate limit violations.

Paso 4: escribe ejemplos de consulta

Documenta las consultas habituales que usas en tu trabajo de investigación:

## Finding Advanced Redis Content

Filter:
topics.includes('redis') && technical_depth === 'advanced'

Returns: doc-001, doc-012, doc-019

Esto hace que el sistema se autodocumente. Seis meses después, recuerdas cómo consultarlo.

Cuándo funciona este patrón

Encaja bien:

• Transcripciones de investigación o notas de entrevistas
• Colecciones de documentación técnica
• Archivos de posts de blog
• Bibliotecas de snippets de código
• Notas de reuniones con tareas de acción

Mal encaje:

• Contenido que se actualiza con frecuencia (el índice queda desfasado; este método requeriría un agente ejecutándose para refrescar continuamente el contenido de los archivos de índice, asumiendo que se fueran añadiendo y eliminando archivos nuevos del directorio de documentos)
• Notas de lluvia de ideas no estructuradas
• Documentos de un solo uso
• Contenido que requiere búsqueda de texto completo

Pero para bases de conocimiento estables, documentación legacy donde necesitas acceso selectivo y no búsqueda exhaustiva, parece funcionar muy bien.

Lecciones aprendidas

1. La preextracción lo es todo — almacenar insights como metadatos significa no volver a leer los archivos fuente
2. Las relaciones importan más que las categorías — el campo relevant_to crea rutas de descubrimiento que la categorización rígida no puede
3. El filtrado por profundidad técnica es crítico — casar la sofisticación de la fuente con el público del artículo evita desajustes de tono
4. Los ejemplos hacen que los sistemas sean usables — los ejemplos de patrones de consulta en research-guide.md son lo que hace que el JSON sea consultable en la práctica
5. Dos interfaces, una sola verdad — JSON para máquinas, Markdown para humanos, pero referencian la misma estructura subyacente
6. La economía de tokens cambia el comportamiento (en Claude, lo que en ocasiones es problemático) — cuando la investigación cuesta un 80 % menos de tokens, puedes permitirte ser más minucioso

Uso en el mundo real

Así es como lo uso en la Fase 2 de Content Machine:

"Produce la investigación que necesito para redactar «Advanced Braking Guide»; consulta research-index.json"

1. Claude abrirá research-index.json
2. Escaneará el «Braking Techniques Cluster»
3. Anotará: yt-001 (trail braking), yt-005 (brake bias), yt-006 (dashboard data)
4. Cargará solo esas 3 transcripciones (~15k tokens)
5. Extraerá insights usando los key_insights prealmacenados como puntos de partida
6. Verificará con yt-003 (slip angle theory) para validación

Enlaces y referencias

• Estudio de alucinaciones de RAG de Stanford — Magesh et al., marzo de 2025
• Supadata — recopila transcripciones de TikTok, YouTube e Instagram