Cómo configurar un sistema RAG paso a paso para tu pyme (con pgvector).
Arquitectura completa de RAG con pgvector, chunking inteligente, embeddings de Voyage o OpenAI, retrieval con filtros y generación con Claude. Ejemplos de código simplificados, no demo vendor.
Actualizado mayo 2026
Qué es RAG y por qué importa antes de empezar a montar.
Un sistema RAG (Retrieval Augmented Generation) conecta un LLM con tus documentos propios para que responda con información de tu empresa, no con su memoria genérica. Sin RAG, un modelo IA solo sabe lo que aprendió hasta su fecha de corte. Con RAG, puede contestar sobre tu catálogo, tus manuales, tus contratos o tus actas de reunión.
La arquitectura tiene cuatro componentes: (1) pipeline de ingesta (documentos → chunks → embeddings → vector DB); (2) vector database (en este artículo, pgvector); (3) retriever que busca chunks relevantes para cada consulta; (4) LLM que genera la respuesta final usando los chunks recuperados como contexto.
En esta guía montamos un RAG mínimo viable con stack pyme-friendly: PostgreSQL + pgvector + Voyage embeddings + Claude Haiku. Coste recurrente: ~30-80 €/mes. Tiempo de montaje: 2-4 semanas desde cero. Si tu pyme ya tiene PostgreSQL, este es el camino más barato y rápido para llevar RAG a producción.
Los seis pasos para montar tu sistema RAG.
Preparar PostgreSQL con pgvector
Postgres 15+ con extensión pgvector instalada (CREATE EXTENSION vector). Crea tabla "chunks" con columnas: id (uuid), document_id, content (text), embedding (vector(1024)), metadata (jsonb), created_at. Índice HNSW sobre embedding con parámetros m=16, ef_construction=64 para balance precisión/velocidad.
Ingestar y chunkear documentos
Usa unstructured.io o llamaparse para extraer texto de PDF/DOCX. Chunking semántico: 600-800 tokens por chunk con 100 tokens de overlap. Para tablas y documentos estructurados, mantener filas/secciones completas. Guarda metadata (fuente, página, sección, tipo) para filtros posteriores.
Generar embeddings con Voyage o OpenAI
Voyage-3 (1.024 dims, ~0,12 €/M tokens) o text-embedding-3-small de OpenAI (1.536 dims, ~0,02 €/M). Procesar en batches de 100 chunks. Para una base de 5.000 chunks de 600 tokens: coste de ingesta inicial ~0,4-2 €. Insert en pgvector con bind params, no concatenación.
Retriever con filtros y reranking
Consulta del usuario → embedding → SQL: SELECT * FROM chunks WHERE metadata->>cliente_id = $1 ORDER BY embedding <=> $2 LIMIT 20. Después, rerank con cohere-rerank-v3 o jina-reranker (~0,001 €/consulta) para quedarte con los 5 más relevantes. Mejora calidad 15-30% sobre top-k vectorial puro.
Generación con Claude Haiku
Prompt con sistema (rol, restricciones) + contexto (los 5 chunks reranked, con cite tags) + consulta del usuario. Claude Haiku 4 (~0,25 €/M input, 1,25 €/M output). Pedir al modelo que cite los chunks por id. Coste medio por consulta: 0,001-0,005 €.
Observabilidad y evaluación
Loggear cada consulta con: query, chunks recuperados, respuesta, feedback usuario. Tabla "rag_traces" en mismo Postgres. Evaluación: dataset de 50-100 preguntas con respuestas esperadas, ejecución semanal automatizada, métrica de "answer correctness" con LLM-as-judge (Claude Sonnet evaluando respuestas).
El esquema PostgreSQL mínimo que necesitas.
Activa la extensión: CREATE EXTENSION IF NOT EXISTS vector; en tu base de datos. Si tu Postgres no es 15+, actualízalo antes — versiones anteriores no soportan pgvector eficientemente. Supabase, Neon y Hetzner Postgres ya vienen con pgvector listo.
Tabla de documentos: CREATE TABLE documents (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), title text NOT NULL, source_url text, content_type text, metadata jsonb, created_at timestamptz DEFAULT now());
Tabla de chunks: CREATE TABLE chunks (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), document_id uuid REFERENCES documents(id) ON DELETE CASCADE, content text NOT NULL, embedding vector(1024) NOT NULL, metadata jsonb, chunk_index int, created_at timestamptz DEFAULT now());
Índice HNSW para búsqueda rápida: CREATE INDEX chunks_embedding_idx ON chunks USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64); Con esto consultas de top-k sobre 100.000 chunks tardan ~20-50ms. Suficiente para asistentes pyme.
Tabla de trazas: CREATE TABLE rag_traces (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), query text, retrieved_chunk_ids uuid[], answer text, feedback smallint, latency_ms int, created_at timestamptz DEFAULT now()); Crítica para evaluación y mejora continua.
Cómo trocear documentos para que el retrieval funcione
El error que más rompe sistemas RAG en pyme es chunkear mal.
Por tamaño con overlap
600-800 tokens por chunk + 100 de overlap. Buen default para documentos narrativos (manuales, contratos, blogs). Usa tiktoken o tokenizer del modelo para contar, no caracteres.
Por estructura semántica
Para Markdown/HTML: chunkea por secciones (h1, h2) en lugar de tamaño fijo. Mantén títulos como prefijo del chunk. Conserva contexto. Calidad de retrieval sube 10-20%.
Por tabla/fila para datos
Tablas de productos o catálogos: una fila = un chunk. Concatena cabecera + valores. NO partir tablas a la mitad por límite de tokens. Si la tabla es grande, descomponer por categoría.
Multimodal (futuro próximo)
Imágenes y diagramas con caption automático (Claude Vision o GPT-4V) y embed conjunto. Cada vez más relevante en sectores con planos, esquemas o catálogos visuales.
Chunk parent + child (advanced)
Chunks pequeños (200 tokens) para retrieval preciso, pero devolver al LLM el chunk padre (800 tokens) para más contexto. Implementable con LlamaIndex; complejidad +30% pero mejora notable.
Filtros por metadata obligatorios
Siempre filtra por metadata antes del top-k vectorial: cliente_id, departamento, fecha. Sin ello, riesgo de fuga de datos entre clientes y pérdida de relevancia.
Cómo se ve una consulta RAG end-to-end (pseudocódigo).
Paso 1: El usuario pregunta "¿Cuántos días de paternidad nos corresponden en mi empresa?". Paso 2: Generamos embedding de la pregunta con Voyage-3: const queryEmbedding = await voyage.embed(query). Coste: ~0,0001 €.
Paso 3: Consultamos pgvector con filtro de tenant: SELECT id, content, metadata FROM chunks WHERE metadata->>empresa_id = 'acme' ORDER BY embedding <=> $1::vector LIMIT 20. Devuelve 20 chunks candidatos en ~30ms.
Paso 4: Rerank con cohere-rerank-v3 para quedarnos con los 5 más relevantes a la consulta exacta: const reranked = await cohere.rerank({ query, documents: chunks, topN: 5 }). Coste: ~0,001 €.
Paso 5: Construimos prompt con system + contexto + pregunta y llamamos a Claude Haiku: const answer = await claude.messages.create({ model: "claude-haiku-4", system: SYSTEM_PROMPT, messages: [{ role: "user", content: buildPrompt(reranked, query) }] }). Coste: ~0,002 €.
Paso 6: Devolvemos respuesta al usuario citando chunks (id de fuente + sección). Loggeamos trace completa en rag_traces para evaluación. Coste total de la consulta: ~0,003 €. Para una pyme con 1.000 consultas/mes: ~3 €/mes en IA + 5-20 € en hosting de Postgres. Total <30 €/mes operativo.
Cinco errores que rompen sistemas RAG en pyme
Chunks demasiado grandes o demasiado pequeños
Chunks de 2.000 tokens dilatan el contexto y el modelo se pierde. Chunks de 100 carecen de contexto. Sweet spot: 400-800 tokens. Probar con datos reales antes de fijar.
No reindexar al cambiar documentos
El manual se actualiza pero los embeddings siguen siendo los antiguos. Las respuestas obsoletas son peores que ninguna respuesta. Pipeline de re-ingesta automático al detectar cambios en la fuente.
Olvidar filtros de tenant en multi-cliente
Una empresa pregunta y el RAG le devuelve chunks de otro cliente. Brecha de seguridad grave. SIEMPRE filtrar por tenant antes del top-k, no después.
Confiar en similitud vectorial pura sin reranking
Top-5 por similitud incluye chunks parecidos pero no exactamente relevantes a la consulta. Reranker mejora calidad sustancialmente por <0,002 € por consulta.
No medir calidad con dataset de evaluación
Si no tienes 50-100 preguntas con respuesta esperada, no sabes si el sistema mejora o empeora cuando cambias chunking, modelo o prompt. Evaluación continua > intuición.
Dudas que nos hacéis llegar
¿Quieres montar un RAG con tu documentación?
Reunión técnica con Marcos: revisamos tus fuentes (PDFs, manuales, BBDD), diseñamos arquitectura RAG mínima viable y la montamos en 2-4 semanas. Cofinanciable con Kit Consulting IA si calificas.