Scraping para alimentar un RAG

Para meter documentación pública en un RAG —un buscador semántico que responde citando tus fuentes— el trabajo real no es el modelo: es convertir páginas en texto limpio, trocearlo por secciones y guardar de dónde salió cada trozo. Si el texto entra sucio, ninguna elección de modelo lo arregla, y la respuesta será mala aunque la búsqueda funcione.

Esta guía va paso a paso con esa cadena, que es la misma tanto si acabas usando un servicio como si lo montas tú.

1. Decide qué entra antes de recolectar nada

La tentación es rastrear el dominio entero. Es el error que más caro sale: metes el menú de navegación, el pie, el aviso de cookies y trescientas páginas de listado, y luego el buscador te devuelve fragmentos de la política de privacidad cuando preguntas por la API.

Empieza por una lista corta y concreta. El sitemap.xml del sitio es el mejor punto de partida: es la lista de lo que su dueño considera contenido de verdad. Filtra por prefijo —solo /docs/, solo /blog/— y mira los títulos antes de aceptar nada.

Regla: es mejor un RAG con cincuenta páginas buenas que con cinco mil regulares. El ruido no se diluye, compite.

2. Convierte a Markdown, no a texto plano

Un innerText a pelo destruye justo lo que más falta hace después: dónde acaba una sección y empieza otra.

Markdown conserva encabezados, listas y tablas, y eso permite trocear por estructura en el paso siguiente en vez de por número de caracteres. Es la diferencia entre un fragmento que se entiende solo y uno que empieza a mitad de una frase.

Firecrawl hace exactamente esto: le pasas una URL o un sitio y devuelve Markdown limpio, con el menú y el pie ya quitados. Es lo que evita escribir un scraper a medida por cada sitio, que es la parte que no escala. Si lo montas tú, la pieza equivalente es un extractor de contenido principal antes del conversor a Markdown.

3. Trocea por secciones, no por caracteres

El chunking es donde se gana o se pierde la calidad, y casi todos los tutoriales lo hacen mal.

Cortar cada 1000 caracteres es fácil y produce fragmentos que empiezan y acaban a mitad de idea.

Cortar por encabezados —cada ## es un trozo— produce fragmentos que responden a una pregunta completa, que es exactamente lo que quieres recuperar. Con dos ajustes prácticos: si una sección se pasa de largo, pártela por párrafos; si es de dos líneas, únela con la siguiente.

Y arrastra el contexto: cada fragmento debería llevar delante el título de la página y la jerarquía de encabezados que lo contiene. Un trozo que empieza por «Documentación de X › Autenticación › Tokens» se recupera muchísimo mejor que uno que empieza por «Para ello, usa el siguiente valor».

4. Guarda la fuente con cada trozo

Es el paso que separa un RAG útil de uno del que nadie se fía.

Cada fragmento se guarda con su URL exacta, su título y la fecha en que lo recolectaste. Sin eso no puedes citar la fuente, y un RAG que no cita es indistinguible de un modelo inventando: quien lee no tiene forma de comprobar nada.

La fecha importa más de lo que parece. Documentación de hace un año contestando sobre una API que cambió es peor que no contestar.

5. Elige dónde buscar

Aquí hay menos decisión de la que parece:

• Postgres con pgvector. El valor por defecto sensato para proyectos pequeños y medianos: una pieza menos que mantener, y ya tienes la base de datos. Supabase y Neon lo traen, y los comparamos en bases de datos con plan gratuito.
• Base vectorial dedicada. Qdrant tiene plan gratuito y se justifica cuando el volumen o la latencia dejan de encajar.

Y un consejo que se salta casi todo el mundo: prueba primero la búsqueda por texto de toda la vida. Para documentación técnica llena de nombres propios y códigos, el buscador léxico de Postgres acierta más de lo que la gente espera, y combinarlo con el vectorial suele batir a cualquiera de los dos por separado.

6. Vuelve a recolectar, y date cuenta de lo que cambió

Un RAG montado una vez y nunca actualizado envejece en silencio: sigue respondiendo con seguridad sobre una documentación que ya no existe.

Guarda un hash del contenido de cada página. En la siguiente pasada, solo reprocesas lo que cambió: gastas menos y, sobre todo, tienes una lista de qué se movió. Programa la tanda y pon un aviso de que se ejecutó: Healthchecks.io avisa cuando una tarea deja de dar señales, que es como fallan estas cosas —en silencio, devolviendo cero—.

Todas las piezas y sus planes gratuitos, en herramientas de scraping gratis. Y antes de recolectar de un sitio ajeno, las cuatro preguntas de scraping legal: documentación pública es el caso fácil, pero conviene mirar la licencia igualmente.

Preguntas frecuentes

¿Qué tamaño debe tener cada fragmento? Menos importante que dónde cortas. Con troceo por encabezados, el tamaño sale solo y suele quedar entre 200 y 800 palabras. Si tienes que elegir un número fijo porque el contenido no tiene estructura, empieza por algo pequeño con solapamiento y mide antes de subirlo.

¿Hace falta una base de datos vectorial? Para la mayoría de proyectos, no. Postgres con pgvector cubre bien decenas de miles de fragmentos y te ahorra un servicio más. Una base dedicada se justifica por volumen o por latencia, no por defecto.

¿Por qué mi RAG responde mal si la búsqueda encuentra los documentos correctos? Casi siempre por el troceo. Si el fragmento recuperado empieza a mitad de una explicación o le falta el contexto de la sección, el modelo recibe algo que no se entiende solo. Antes de cambiar de modelo, imprime los fragmentos que recuperas y léelos: si a ti no te bastan, al modelo tampoco.

¿Puedo meter un sitio entero de una vez? Puedes, y casi siempre empeora el resultado. El menú, el pie y las páginas de listado generan fragmentos que compiten con el contenido bueno. Filtra por prefijo de URL y revisa la lista antes de procesar.

¿Cada cuánto hay que volver a recolectar? Depende de lo rápido que cambie la fuente: documentación de un producto activo, cada semana o dos; contenido estable, cada mes. Lo importante no es la frecuencia exacta, es que exista y que te avise si un día deja de ejecutarse.