RAG para empresas: cómo construimos un buscador inteligente sobre 124.000 documentos

El problema: 124.000 documentos que nadie puede buscar

Chile tiene un corpus legal enorme: 7 códigos base, más de 14 leyes especiales, miles de dictámenes de la Dirección del Trabajo, circulares del SII, sentencias del Tribunal Constitucional, de la Corte Suprema, y dictámenes de la Contraloría. En total, más de 124.000 documentos legales que afectan la vida cotidiana de millones de personas.

El problema: esta información está dispersa en decenas de sitios web institucionales, en formatos diferentes (PDF, HTML, XML), sin un buscador unificado que entienda lenguaje natural. Si quieres saber “¿puedo trabajar los domingos?”, necesitas saber que la respuesta está en el Artículo 38 del Código del Trabajo, en los dictámenes de la DT que lo interpretan, y en la Ley 21.561 que modificó la jornada.

Construimos un sistema que responde esa pregunta con citas verificables en menos de 3 segundos. Así es como funciona.

¿Qué es RAG?

Retrieval-Augmented Generation(RAG) es un patrón de arquitectura que combina búsqueda semántica con generación de lenguaje. En lugar de pedirle a un modelo de IA que “sepa” la respuesta (lo que lleva a alucinaciones), le das los documentos relevantes como contexto y le pides que responda basándose únicamente en ellos.

El flujo es simple en concepto, complejo en ejecución:

1. El usuario hace una pregunta en lenguaje natural.
2. La pregunta se convierte en un vector numérico(embedding) que captura su significado semántico.
3. Se buscan los documentos más similares en una base de datos vectorial (los 5-10 más relevantes entre 124.000).
4. Los documentos encontrados se envían como contexto a un modelo de lenguaje, junto con instrucciones estrictas: “responde solo con lo que está en estos documentos, cita la fuente”.
5. El modelo genera una respuesta con citas verificables que el usuario puede consultar en la fuente original.

Arquitectura real: lo que usamos

Esta no es una arquitectura teórica. Es lo que corre en producción hoy, respondiendo consultas legales de usuarios reales:

Embeddings: Voyage AI (voyage-3.5, 1024 dimensiones).Evaluamos OpenAI, Cohere y Voyage AI. Voyage AI ganó en calidad de búsqueda para texto en español y en costo: 50 millones de tokens gratuitos al mes. Para nuestro volumen actual, el costo de embeddings es $0.

Base de datos vectorial: PostgreSQL + pgvector.No usamos Pinecone, Weaviate ni Qdrant. Usamos PostgreSQL con la extensión pgvector, alojado en Supabase. ¿Por qué? Porque ya teníamos PostgreSQL para el resto de la aplicación y pgvector soporta búsqueda por similitud coseno con índices HNSW/IVFFlat. Menos infraestructura, menos costos, menos puntos de falla.

LLM: Groq con Llama 3.3 70B.Elegimos Groq por velocidad (tokens por segundo) y costo (tier gratuito generoso). Llama 3.3 70B responde bien en español y sigue instrucciones de citas con precisión. El costo de inferencia para nuestro volumen: $0.

Frontend: Next.js con streaming.La respuesta se envía token por token al usuario usando Server-Sent Events. El usuario ve la respuesta construyéndose en tiempo real, lo que mejora la percepción de velocidad.

El desafío real: la calidad de los datos

La arquitectura es la parte fácil. El verdadero trabajo está en los datos. Cada fuente legal tiene sus propias complejidades:

Códigos y leyesvienen de la API de la Biblioteca del Congreso Nacional (BCN) en formato XML. La estructura es jerárquica (libros → títulos → párrafos → artículos). Cada artículo se vectoriza individualmente, preservando su contexto jerárquico en el embedding.

Dictámenes de la Dirección del Trabajono tienen API. Los obtuvimos vía scraping del sitio web de la DT, extrayendo los resúmenes legales de cada dictámen (los PDFs originales son imágenes escaneadas sin capa de texto).

Circulares del SIIestán en PDFs con texto extraíble. Cada circular se descargó, se extrajo el texto, y se dividió en chunks de ~5.000 caracteres con overlap de 200 caracteres para no perder contexto en los límites.

Sentencias de la Corte Supremafueron el mayor desafío: ~30.000 sentencias obtenidas del Poder Judicial, cada una con texto completo que puede superar los 20.000 caracteres. Chunking inteligente preservando las secciones VISTOS, CONSIDERANDOS y RESUELVE.

Costos reales: cuánto cuesta operar esto

Una de las preguntas más frecuentes que recibimos es sobre costos. Esta es la realidad:

• Embeddings (Voyage AI): $0/mes. El tier gratuito cubre nuestro volumen actual. Si creciéramos 10x, serían ~$3 USD/mes.
• LLM (Groq): $0/mes. 6.000 requests/día en tier gratuito. Con el volumen actual, no nos acercamos al límite.
• Base de datos (Supabase Pro): $25 USD/mes. 8 GB de disco para 124.000 documentos con vectores de 1024 dimensiones.
• Hosting (Vercel): $0/mes. El tier hobby soporta nuestro tráfico actual sin problemas.
• Total: ~$25 USD/mes para operar un buscador semántico sobre 124.000 documentos legales.

Esto no es magia ni subsidio: es el resultado de elegir servicios con tiers gratuitos generosos y optimizar la arquitectura para minimizar llamadas a APIs externas (caché de embeddings, rate limiting inteligente).

Lecciones aprendidas

Después de un año construyendo y operando este sistema, estas son las lecciones que nos habría gustado saber antes:

La calidad del chunking importa más que el modelo.Puedes usar el mejor LLM del mundo, pero si tus chunks están mal cortados (un artículo partido a la mitad, un dictamen sin su conclusión), las respuestas serán mediocres. Invertimos más tiempo en la estrategia de chunking que en cualquier otro componente.

Los índices vectoriales tienen límites de memoria.Con 82.000 documentos, un índice HNSW funciona bien con 64 MB de RAM. Con 124.000, necesitamos cambiar a IVFFlat porque el servidor compartido no tenía suficiente memoria. Planifica el crecimiento de tu índice desde el día 1.

Rate limiting desde el principio.Las APIs de IA tienen límites estrictos. Sin rate limiting global, un solo usuario puede agotar la cuota de todos. Implementa rate limiting por usuario Y global antes de tu primer usuario real.

Los datos legales cambian.Las leyes se modifican, los dictámenes se emiten diariamente, las circulares se actualizan. Necesitas un pipeline de actualización automática, no una carga única. Tenemos cron jobs que detectan nuevas leyes desde la API de la BCN cada día.

¿RAG para tu empresa?

El patrón RAG no es exclusivo del ámbito legal. Funciona para cualquier organización con un corpus grande de documentos que necesita ser consultable: manuales técnicos, normativa interna, contratos, informes financieros, documentación de productos.

La diferencia entre “un chatbot que alucina” y “un asistente que cita sus fuentes” es RAG bien implementado. Si tienes documentos que tus equipos no pueden buscar eficientemente, podemos ayudarte.