Tutorial: RAG empresarial con pgvector + Postgres + Vercel AI SDK

La conversación sobre vector DBs en 2026 se simplifica: para PyME y empresa mediana chilena con menos de 50 millones de vectores, pgvector sobre el Postgres que ya tienes es suficiente, escalable y mucho más barato. Tres razones operativas:

• Cero servicios nuevos: corre dentro del Postgres existente. Una operación, una base, una factura.
• Datos en tu jurisdicción: relevante para Ley 21.719 vigente el 1-dic-2026.
• HNSW configurado correctamente entrega latencias de 20-80 ms para hasta 10M vectores, suficiente para casi todo caso PyME.

Para detalle de comparativa con Pinecone/Qdrant/Weaviate ver nuestro satélite dedicado. Aquí vamos al código.

Necesitamos chunkear el documento original, generar el embedding de cada chunk y persistir. Implementación con Vercel AI SDK:

import { openai } from '@ai-sdk/openai';
import { embedMany } from 'ai';
import { Pool } from 'pg';

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

async function indexarDocumento(
  origen: string,
  textoCompleto: string,
  metadata: Record<string, any> = {}
) {
  const chunks = chunkearTexto(textoCompleto, 1000, 200); // size=1000, overlap=200

  const { embeddings } = await embedMany({
    model: openai.embedding('text-embedding-3-small'),
    values: chunks,
  });

  // Inserta en batch
  const rows = chunks.map((c, i) => ({
    origen,
    contenido: c,
    metadata,
    embedding: `[${embeddings[i].join(',')}]`,
  }));

  await pool.query(
    `INSERT INTO documentos (origen, contenido, metadata, embedding)
     SELECT origen, contenido, metadata, embedding::vector
     FROM jsonb_to_recordset($1) AS x(origen text, contenido text, metadata jsonb, embedding text)`,
    [JSON.stringify(rows)]
  );
}

function chunkearTexto(texto: string, tamano = 1000, overlap = 200): string[] {
  const chunks: string[] = [];
  for (let i = 0; i < texto.length; i += tamano - overlap) {
    chunks.push(texto.slice(i, i + tamano));
  }
  return chunks;
}

El parámetro overlap=200 garantiza que información en los bordes de chunks no se pierda. Para casos especiales (código, listas estructuradas, normativa) conviene chunkear semánticamente con librerías como llamaindex o semantic-chunking.

Búsqueda solo vectorial pierde matches donde el usuario busca términos exactos (nombres propios, números, códigos). La búsqueda híbrida combina vector + full-text con scoring ponderado:

async function buscarHibrido(query: string, limite = 6) {
  const { embedding } = await embed({
    model: openai.embedding('text-embedding-3-small'),
    value: query,
  });

  // Combinamos vector + keyword con pesos 0.7 / 0.3
  const result = await pool.query(
    `WITH
       vector_search AS (
         SELECT id, contenido, origen,
                1 - (embedding <=> $1::vector) AS score_vector
         FROM documentos
         ORDER BY embedding <=> $1::vector
         LIMIT 20
       ),
       keyword_search AS (
         SELECT id, contenido, origen,
                ts_rank(to_tsvector('spanish', contenido),
                        plainto_tsquery('spanish', $2)) AS score_keyword
         FROM documentos
         WHERE to_tsvector('spanish', contenido) @@ plainto_tsquery('spanish', $2)
         ORDER BY score_keyword DESC
         LIMIT 20
       )
     SELECT
       COALESCE(v.id, k.id) AS id,
       COALESCE(v.contenido, k.contenido) AS contenido,
       COALESCE(v.origen, k.origen) AS origen,
       COALESCE(v.score_vector, 0) * 0.7
         + COALESCE(k.score_keyword, 0) * 0.3 AS score
     FROM vector_search v
     FULL OUTER JOIN keyword_search k ON v.id = k.id
     ORDER BY score DESC
     LIMIT $3`,
    [`[${embedding.join(',')}]`, query, limite]
  );

  return result.rows;
}

Los pesos 0.7/0.3 son punto de partida. Ajustar según tu corpus: si tu base es muy técnica con términos exactos importantes, aumentar peso keyword (0.5/0.5 o 0.4/0.6).

Para corpus de 100k+ vectores, los parámetros HNSW afectan latencia y precisión. Recomendaciones:

• `m = 16` (default) para corpus medianos. Aumentar a `m = 32` para mayor precisión a costa de uso de memoria.
• `ef_construction = 64` (default) suficiente para la mayoría. `ef_construction = 100` cuando precisión es crítica.
• En query time: `SET hnsw.ef_search = 100;` antes de la búsqueda para mayor precisión (default es 40).
• Si el corpus crece sobre 5M vectores, considerar quantization (pgvector 0.8+ soporta `halfvec`).
• Postgres tuning: `shared_buffers`, `work_mem`, `maintenance_work_mem` impactan rendimiento. Default de Vercel Postgres suele ser suficiente para PyME.