Publicas un asistente sobre los 2.000 artículos de tu sitio y la primera pregunta real ya falla: el bot no encuentra una guía publicada hace dos años. El culpable casi nunca es el modelo; la técnica está validada desde el paper de Meta de 2020 y los fallos suelen estar en los puntos donde el pipeline toca WordPress. Estos son los tres errores más comunes al montar RAG en WordPress, cada uno con su corrección concreta.
Error 1: trocear el contenido tal como lo devuelve la base de datos
Trocear mal el contenido es el error más barato de cometer al montar RAG en WordPress. El pipeline típico lee la tabla wp_posts y envía cada entrada completa al modelo de embeddings; post_content acumula el HTML del editor de bloques, shortcodes sin resolver y marcado que otros plugins insertan en el propio contenido. El vector resultante es un promedio difuso y la recuperación falla justo en las preguntas específicas.
La práctica habitual divide el texto en fragmentos de 400 a 800 tokens con un solapamiento del 10-15 %. Usa los encabezados h2 y h3 como límites naturales y aplica el filtro the_content antes de trocear, para que los shortcodes se conviertan en texto real. Un limpiador como BeautifulSoup (en Python) elimina el marcado residual. Cada fragmento debe poder leerse por sí solo.
Con chunks limpios, la siguiente decisión es dónde viven esos vectores.
Error 2: guardar los vectores en la propia base de datos de WordPress
Un modelo como text-embedding-3-small de OpenAI genera vectores de 1.536 dimensiones. Guardarlos serializados en wp_postmeta y calcular similitudes desde PHP obliga a un escaneo completo en cada consulta, y el tiempo de respuesta crece con el número de entradas. MySQL no ofrece índices de vecinos más cercanos para este caso de uso, y MariaDB no incorporó búsqueda vectorial hasta la versión 11.6, publicada a finales de 2024; la mayoría de hostings de WordPress sigue en series anteriores.
La corrección separa el almacén: Qdrant y Weaviate corren en un contenedor propio, Pinecone funciona como servicio gestionado y pgvector añade búsqueda aproximada a PostgreSQL en una tarde. Si necesitas coincidencia exacta de términos además de similitud semántica, conserva el índice FULLTEXT de MySQL y combina ambos resultados mediante búsqueda híbrida.
Separar el almacén resuelve el rendimiento, pero deja otra vía de fallo abierta: qué contenido puede ver cada usuario.
Error 3: indexar sin respetar los permisos de WordPress
Una consulta directa como SELECT * FROM wp_posts WHERE post_type IN (‘post’, ‘page’) recoge también borradores, contenido pendiente de revisión y entradas privadas. Si ese material entra en el índice, cualquier visitante anónimo puede pedirle al chatbot información reservada a usuarios registrados. El contenido protegido con contraseña sigue el mismo camino.
La corrección tiene dos capas. En la ingesta, filtra por post_status = ‘publish’ y guarda el ID de la entrada en los metadatos de cada vector. En la consulta, recupera los candidatos del almacén y vuelve a comprobar permisos con current_user_can() o get_post_status() antes de devolver texto al usuario; una entrada privada aparece así solo para quien puede verla.
Conclusión: audita el pipeline antes de ampliarlo
Estos tres puntos condicionan cualquier proyecto de RAG en WordPress con contenido vivo, y hay un cuarto silencioso que los agrava: un índice estático. Engancha el hook save_post para regenerar el embedding de cada entrada cuando cambie y elimina los vectores de contenido borrado. Después, crea un banco de pruebas con 20 preguntas reales de tus usuarios y la URL que debería responder cada una; ejecútalo tras cada cambio en el sistema. Y si quieres una victoria inmediata, abre hoy la consulta que alimenta tu ingesta: si no filtra por post_status = ‘publish’, ya tienes un error que corregir y una buena razón para revisar los otros dos.
Para el montaje completo revisa la guía de conexión con Ollama y la comparativa de costes.