Construcción de Aplicaciones RAG con Bases de Datos Vectoriales: Ingesta, Chunking y Arquitectura de Búsqueda

Los Modelos de Lenguaje de Gran Tamaño (LLMs) ofrecen capacidades sobresalientes de síntesis y razonamiento generalista. Sin embargo, al desplegarse en entornos empresariales, los modelos base se topan con dos restricciones fundamentales: el límite temporal de sus datos de entrenamiento (knowledge cutoff) y la tendencia a generar afirmaciones plausibles pero totalmente ficticias, conocidas como alucinaciones (confabulation).

La arquitectura Retrieval-Augmented Generation (RAG) soluciona este dilema desacoplando el almacenamiento de conocimientos de la memoria paramétrica del modelo. En lugar de forzar al LLM a memorizar toda la documentación y bases de datos corporativas, el sistema RAG extrae dinámicamente fragmentos de texto relevantes desde un motor de información especializado —generalmente una base de datos vectorial— y los incorpora al contexto de inferencia en tiempo real.

No obstante, transformar un prototipo básico en un servicio empresarial de alta disponibilidad requiere rigor técnico. Las divisiones arbitrarias de texto cada 1.000 caracteres combinadas con búsquedas vectoriales simples provocan pérdidas de contexto, tablas fragmentadas, exceso de ruido documental y alucinaciones derivadas de datos contradictorios.

En este tutorial analizamos en profundidad las capas de un pipeline RAG de producción: ingesta y particionamiento (chunking) con conciencia de estructura, cálculo de similitud vectorial, reordenación con clasificadores cruzados (cross-encoders) y generación de respuestas con citas verificables de procedencia.

1. Arquitectura RAG de Extremo a Extremo

Un sistema RAG en producción opera a través de dos ciclos desacoplados: el Pipeline de Ingesta e Indexación Fuera de Línea y el Bucle de Búsqueda y Generación en Tiempo Real.

[ PIPELINE DE INGESTA FUERA DE LÍNEA ]
Documentos Fuentes (PDF, Markdown, HTML, Bases Confluence)
       │
       ▼
Extracción de Texto y Limpieza
       │
       ▼
Particionamiento Estructural (400–800 tokens, 10–15% solapamiento)
       │
       ▼
Generación de Embeddings Densos (text-embedding-3-small, 1536 dim)
       │
       ▼
Indexación en Base Vectorial (Grafo HNSW / Carga de Metadatos)

─────────────────────────────────────────────────────────────────

[ BUCLE DE BÚSQUEDA Y GENERACIÓN EN TIEMPO REAL ]
Consulta del Usuario
       │
       ▼
Preprocesamiento y Expansión Semántica de Consulta (HyDE)
       │
       ▼
Búsqueda Híbrida (Similitud Coseno Densa + Frecuencia de Términos BM25)
       │
       ▼
Fusión por Rango Recíproco (RRF) ──> Top 50 Candidatos
       │
       ▼
Reordenador con Cross-Encoder ──> Top 4 Fragmentos Seleccionados
       │
       ▼
Construcción del Contexto y Etiquetas de Citas
       │
       ▼
Generación Verificable por el LLM (Exigencia de [Fuente-N] y Rechazo si no existe)

2. Ingesta Documental y Estrategias de Particionamiento (Chunking)

La precisión de recuperación de un sistema RAG está limitada por la calidad de la estrategia de particionamiento. Si un fragmento es demasiado pequeño, se pierde el contexto explicativo; si es excesivamente largo, el vector denso se diluye con ruido irrelevante, disminuyendo la similitud ante preguntas específicas.

Comparativa de Métodos de Chunking

Implementación de Chunker Estructurado en Markdown (TypeScript)

Para repositorios técnicos y bases de conocimiento, preservar la jerarquía de encabezados Markdown proporciona la mayor precisión de búsqueda:

// src/lib/rag/chunker.ts

export interface DocumentSection {
  title: string;
  sourceUrl: string;
  category: string;
  content: string;
}

export interface TextChunk {
  chunkId: string;
  sourceUrl: string;
  headingPath: string;
  content: string;
  tokenEstimate: number;
}

/**
 * Divide el texto respetando los encabezados (#, ##, ###) y los límites de párrafos
 */
export function chunkMarkdownDocument(
  doc: DocumentSection,
  maxTokens: number = 600,
  overlapTokens: number = 60
): TextChunk[] {
  const sections = doc.content.split(/\n(?=#{1,3}\s)/);
  const chunks: TextChunk[] = [];
  let chunkCounter = 0;

  for (const section of sections) {
    const lines = section.trim().split("\n");
    const heading = lines[0].startsWith("#") ? lines[0].replace(/^#+\s*/, "") : "General";
    const body = lines[0].startsWith("#") ? lines.slice(1).join("\n").trim() : section.trim();

    if (!body) continue;

    const estimatedTokens = Math.ceil(body.length / 4);

    if (estimatedTokens <= maxTokens) {
      chunkCounter++;
      chunks.push({
        chunkId: `${doc.sourceUrl}#chunk-${chunkCounter}`,
        sourceUrl: doc.sourceUrl,
        headingPath: `${doc.title} > ${heading}`,
        content: `### ${heading}\n${body}`,
        tokenEstimate: estimatedTokens
      });
    } else {
      const paragraphs = body.split(/\n\n+/);
      let currentBuffer: string[] = [];
      let currentTokenCount = 0;

      for (const paragraph of paragraphs) {
        const pTokens = Math.ceil(paragraph.length / 4);

        if (currentTokenCount + pTokens > maxTokens && currentBuffer.length > 0) {
          chunkCounter++;
          chunks.push({
            chunkId: `${doc.sourceUrl}#chunk-${chunkCounter}`,
            sourceUrl: doc.sourceUrl,
            headingPath: `${doc.title} > ${heading}`,
            content: `### ${heading}\n${currentBuffer.join("\n\n")}`,
            tokenEstimate: currentTokenCount
          });

          const overlap = currentBuffer.slice(-1);
          currentBuffer = [...overlap, paragraph];
          currentTokenCount = Math.ceil(currentBuffer.join("\n\n").length / 4);
        } else {
          currentBuffer.push(paragraph);
          currentTokenCount += pTokens;
        }
      }

      if (currentBuffer.length > 0) {
        chunkCounter++;
        chunks.push({
          chunkId: `${doc.sourceUrl}#chunk-${chunkCounter}`,
          sourceUrl: doc.sourceUrl,
          headingPath: `${doc.title} > ${heading}`,
          content: `### ${heading}\n${currentBuffer.join("\n\n")}`,
          tokenEstimate: currentTokenCount
        });
      }
    }
  }

  return chunks;
}

3. Métricas de Similitud Vectorial e Indexación HNSW

Los modelos de embeddings mapean fragmentos textuales en un espacio vectorial continuo $\mathbb{R}^d$.

Similitud Coseno vs Producto Punto (Dot Product)

• Similitud Coseno: Mide el coseno del ángulo entre dos vectores con independencia de su longitud, resultando ideal para fragmentos con longitudes heterogéneas.
• Producto Punto: Si los vectores se normalizan previamente con norma unitaria L2 ($|\mathbf{u}|_2 = 1$), el producto punto es matemáticamente equivalente a la similitud coseno y se ejecuta mucho más rápido en hardware moderno gracias a instrucciones vectorizadas (AVX-512).

Búsqueda Aproximada de Vecinos Cercanos (ANN) y HNSW

Comparar exhaustivamente colecciones millonarias de vectores tiene una complejidad de $O(N \cdot d)$, haciendo imposible lograr tiempos de respuesta en milisegundos. Las bases de datos vectoriales implementan el algoritmo HNSW (Hierarchical Navigable Small World):

• M: Número máximo de conexiones bidireccionales por nodo.
• efConstruction: Tamaño de la lista de evaluación durante la construcción del índice.
• efSearch: Profundidad de exploración durante las consultas en tiempo real.

4. Búsqueda Híbrida y Reranking con Cross-Encoder

Depender exclusivamente de vectores densos introduce vulnerabilidades ante términos unívocos, identificadores numéricos, códigos de error o nombres de métodos exactos.

La arquitectura recomendada recurre a la Búsqueda Híbrida (Hybrid Search): disparando en paralelo la búsqueda semántica densa y la búsqueda léxica dispersa BM25, combinando los resultados mediante Reciprocal Rank Fusion (RRF).

Posteriormente, los 40 a 50 mejores candidatos se entregan a un modelo Cross-Encoder Reranker, que procesa la atención cruzada entre la consulta y cada fragmento, eliminando hasta el 90% del ruido antes de la síntesis del LLM.

5. Implementación del Pipeline de Generación RAG (TypeScript)

Presentamos una implementación completa y robusta en TypeScript con Pinecone y OpenAI, incorporando control de umbrales y rechazo ante información insuficiente:

// src/lib/rag/pipeline.ts
import { Pinecone } from '@pinecone-database/pinecone';

export interface RetrievedChunk {
  chunkId: string;
  sourceUrl: string;
  headingPath: string;
  content: string;
  score: number;
}

export interface GroundedRAGResponse {
  answer: string;
  citations: Array<{ citationIndex: number; sourceUrl: string; headingPath: string }>;
  tokenUsage: { promptTokens: number; completionTokens: number };
  refusal: boolean;
}

export async function executeGroundedRAG(
  query: string,
  pineconeClient: Pinecone,
  pineconeIndexName: string,
  embeddingApiKey: string,
  llmApiKey: string
): Promise<GroundedRAGResponse> {
  // 1. Obtención del vector normalizado de la consulta
  const embeddingResponse = await fetch('https://api.openai.com/v1/embeddings', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${embeddingApiKey}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      input: query,
      model: 'text-embedding-3-small'
    })
  });

  if (!embeddingResponse.ok) {
    throw new Error(`Error en el servicio de embeddings: ${embeddingResponse.statusText}`);
  }

  const embeddingData = await embeddingResponse.json();
  const queryVector: number[] = embeddingData.data[0].embedding;

  // 2. Consulta de candidatos en la base vectorial
  const index = pineconeClient.index(pineconeIndexName);
  const queryResult = await index.query({
    vector: queryVector,
    topK: 10,
    includeMetadata: true
  });

  const candidates: RetrievedChunk[] = (queryResult.matches || []).map((match) => ({
    chunkId: match.id,
    sourceUrl: (match.metadata?.sourceUrl as string) || 'Unknown Source',
    headingPath: (match.metadata?.headingPath as string) || 'General',
    content: (match.metadata?.content as string) || '',
    score: match.score || 0
  }));

  // 3. Filtrado de fragmentos bajo el umbral de similitud
  const MIN_SIMILARITY_SCORE = 0.65;
  const filteredChunks = candidates.filter(c => c.score >= MIN_SIMILARITY_SCORE);

  // Si no hay fragmentos válidos, se rechaza la generación para evitar alucinaciones
  if (filteredChunks.length === 0) {
    return {
      answer: "La documentación oficial suministrada no contiene evidencias suficientes para responder con precisión a esta consulta.",
      citations: [],
      tokenUsage: { promptTokens: 0, completionTokens: 0 },
      refusal: true
    };
  }

  const selectedContext = filteredChunks.slice(0, 4);

  // 4. Formulación del prompt con reglas estrictas de citación
  const contextBlock = selectedContext
    .map((chunk, idx) => `[Fuente-${idx + 1}] (${chunk.headingPath})\n${chunk.content}`)
    .join("\n\n---\n\n");

  const systemPrompt = `Usted es un asistente documental técnico riguroso.
Responda a la pregunta del usuario utilizando EXCLUSIVAMENTE los fragmentos verificados a continuación.
Reglas obligatorias:
1. Toda afirmación debe ir acompañada de su etiqueta correspondiente en formato [Fuente-N].
2. Si los textos no contienen la respuesta, indique textualmente: "La documentación disponible no cuenta con información suficiente para responder."
3. No efectúe suposiciones ni incorpore conocimientos externos ajenos a las fuentes provistas.

DOCUMENTACIÓN VERIFICADA:
${contextBlock}`;

  // 5. Síntesis mediante el modelo de lenguaje
  const llmResponse = await fetch('https://api.openai.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${llmApiKey}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      model: 'gpt-4o-mini',
      messages: [
        { role: 'system', content: systemPrompt },
        { role: 'user', content: query }
      ],
      temperature: 0.1,
      max_tokens: 500
    })
  });

  if (!llmResponse.ok) {
    throw new Error(`Fallo en la llamada al LLM: ${llmResponse.statusText}`);
  }

  const completionData = await llmResponse.json();
  const answerText = completionData.choices[0].message.content;

  const citations = selectedContext.map((chunk, idx) => ({
    citationIndex: idx + 1,
    sourceUrl: chunk.sourceUrl,
    headingPath: chunk.headingPath
  }));

  return {
    answer: answerText,
    citations,
    tokenUsage: {
      promptTokens: completionData.usage.prompt_tokens,
      completionTokens: completionData.usage.completion_tokens
    },
    refusal: answerText.includes("no cuenta con información suficiente")
  };
}

6. Verificación de Hechos: ¿Elimina RAG las Alucinaciones por Completo?

La afirmación comercial de que “implementar una base vectorial y RAG elimina al 100% las alucinaciones de los modelos de lenguaje” es técnicamente incorrecta.

Aunque RAG reduce drásticamente las confabulaciones, genera escenarios de fallo característicos:

1. Fallo de Extracción (Retrieval Miss): Divergencias léxicas provocan que el fragmento clave no se recupere. Sin reglas explícitas de rechazo, el modelo recurre a su memoria interna e inventa hechos.
2. Efecto ‘Lost in the Middle’: Los modelos de atención priorizan los extremos de contextos extensos. Saturar el prompt con muchos fragmentos provoca que hechos situados en el medio se pasen por alto.
3. Contaminación por Fuentes Contradictorias: Si la base contiene simultáneamente documentación de la v1 y de la v2, el modelo puede mezclar sintaxis y generar métodos inexistentes.
4. Falta de Fidelidad (Faithfulness Failure): Cuando un dato del contexto colisiona con un sesgo arraigado durante el preentrenamiento del modelo, este puede ignorar el texto recuperado.

7. Conclusión

Las bases de datos vectoriales y las arquitecturas RAG representan los cimientos para diseñar inteligencias artificiales empresariales seguras y verificables. Mediante particionamiento sensible a la sintaxis, búsqueda híbrida, reordenación y control de citas, los equipos de desarrollo pueden ofrecer herramientas de conocimiento confiables y auditables.

Para explorar estrategias de segregación de datos en arquitecturas en la nube, consulte nuestra guía sobre Patrones de Arquitectura SaaS Multi-Inquilino, o examine cómo adaptar modelos a tareas específicas en Ajuste Fino (Fine-Tuning) de LLMs para Tareas Especializadas.