De repositorio a cerebro: arquitectura de conocimiento con Payload, Typesense y agentes IA

Elegir un CMS suele ser el primer punto donde los proyectos se complican antes de empezar. O te ahogas en configuración visual y pierdes control real sobre el código, o te vas al otro extremo y acabas manteniendo un frankenstein casero sin panel de edición que nadie quiere tocar. Existe una tercera vía que resuelve bien esta dicotomía: Payload CMS como núcleo code-first, Typesense como capa de búsqueda vectorial, y un microservicio Python para la lógica de agentes. En este post desglosamos cómo encajan estas tres piezas y por qué la separación de responsabilidades importa.

El punto de partida: por qué code-first

La mayoría de los CMS comparten el mismo problema estructural: la definición de datos vive en la base de datos, no en el repositorio. Cualquier cambio de esquema queda fuera del control de versiones, no pasa por una Pull Request y es difícil de revertir de forma limpia. 

Payload CMS invierte este paradigma. Las colecciones se definen en TypeScript, lo que tiene tres consecuencias relevantes:

• Tipado en toda la cadena. Al definir un campo en el CMS, el tipo correspondiente está disponible automáticamente en el frontend. Si el esquema cambia, el compilador avisa antes de que nada llegue a producción.
• El esquema vive en Git. Los cambios en la estructura de datos pasan por el mismo flujo que cualquier cambio de código: rama, PR, revisión, merge. Es Infrastructure as Code aplicado a los datos.
• Sin límites en la lógica. Hooks transaccionales complejos, tareas programadas, validaciones cruzadas entre colecciones. No hay restricciones impuestas por lo que una interfaz gráfica permite hacer.

El panel de administración también es extensible: se pueden inyectar componentes React propios para construir botones de sincronización con sistemas externos, flujos de aprobación con feedback visual o vistas personalizadas por rol. La lógica compleja va encapsulada en plugins reutilizables, sin ensuciar el núcleo.

En cuanto a infraestructura, la apuesta natural es Docker + CI/CD con despliegue en cualquier entorno que soporte contenedores, y Keycloak como proveedor de identidad para OIDC, SAML y SSO. Sin vendor lock-in, sin dependencia de plataformas de hosting propietarias.

La capa de búsqueda: de base de datos a motor de conocimiento

Tener los datos bien estructurados es solo la mitad del trabajo. La otra es hacerlos accesibles de manera inteligente. Esto suele derivar a delegar la búsqueda a la base de datos principal. Las bases de datos relacionales son eficientes para integridad transaccional, pero lentas y limitadas para texto completo, tolerancia a erratas o filtrado por facetas a escala. Para eso existe una capa dedicada.

Typesense encaja bien aquí: open source, in-memory (muy rápido), fácil de desplegar y con soporte nativo para búsqueda vectorial. La sincronización con el CMS se resuelve con hooks de base de datos que transforman y envían cada documento a Typesense en el momento en que se crea, actualiza o elimina. El índice siempre refleja el estado real del contenido.

La estrategia de indexación varía según el tipo de dato. Los campos que requieren comprensión semántica, como los resúmenes o cuerpos de texto, se vectorizan mediante embeddings. Los metadatos estructurados, fechas, autores y categorías, van a índices exactos para filtrado rápido.

El resultado más potente es la búsqueda híbrida: ejecutar ambas consultas en paralelo y fusionar los resultados con un algoritmo de ranking (RRF - Reciprocal Rank Fusion). Una consulta como "cómo configuro la autenticación" puede encontrar un documento que habla de "gestión de identidad y SSO" sin compartir una sola palabra. Eso es lo que separa un buscador útil de uno que devuelve resultados literales. 

Esta infraestructura no solo sirve a usuarios humanos. Es también la base sobre la que se construye la capa de agentes.

El cerebro: microservicio de agentes IA

Con datos estructurados y búsqueda vectorial, el paso siguiente es añadir capacidad de razonamiento. Para eso tiene sentido un microservicio independiente en Python, separado del servidor Node.js del CMS.

Las razones son arquitectónicas, no de preferencia de lenguaje. El ecosistema Python para IA (LangChain, LlamaIndex, librerías de orquestación de LLMs) no tiene equivalente real en Node.js. La lógica de agentes evoluciona a un ritmo diferente que la gestión de contenidos, por lo que separarla permite desplegar mejoras sin tocar la estabilidad del CMS. Y los perfiles de consumo de recursos son distintos: la inferencia de IA tiene picos de CPU y memoria que deben poder escalarse de forma independiente.

Para esto, una arquitectura sobre Kubernetes con autoescalado funciona especialmente bien. Esto es, Scale to zero en momentos de inactividad: sin carga, sin coste de cómputo. Scale to N ante picos de tráfico o procesamiento masivo en segundo plano, con réplicas aprovisionadas automáticamente. El núcleo del servicio implementa el patrón RAG (Retrieval-Augmented Generation):

1. El usuario envía una pregunta al agente.
2. El agente vectoriza la pregunta y recupera los fragmentos más relevantes semánticamente desde Typesense.
3. Construye un prompt que combina la pregunta original con el contexto recuperado.
4. El LLM genera la respuesta y la transmite token a token (streaming) para reducir la latencia percibida.

Para que el RAG funcione bien, los documentos deben estar preprocesados: divididos en fragmentos que preservan el contexto (respetando párrafos y encabezados), con embeddings precalculados y metadatos de origen que permiten citar fuentes con precisión. Tener el chunking bien resuelto es lo que separa un RAG que alucina de uno que razona.

Tener un servicio dedicado abre además la puerta a agentes autónomos con razonamiento multi-paso: el sistema decide que para responder necesita consultar primero la documentación interna, luego llamar a una API externa, y finalmente sintetizar ambas respuestas. O directamente actuar creando borradores, enviando alertas o detectando inconsistencias en los datos, con los permisos necesarios.

La tríada completa

Al final del recorrido, la arquitectura tiene tres capas con responsabilidades bien delimitadas:

• El cuerpo: Payload CMS. Backend soberano, fuertemente tipado, extensible. La verdad de los datos vive en Git, el esquema se valida en compilación y el panel admin es moldeable. Sin vendor lock-in, desplegable en cualquier infraestructura.
• La memoria: Typesense. Motor de búsqueda vectorial híbrido. La información es recuperable semánticamente, sincronizada en tiempo real desde el CMS, con estrategias de indexación diferenciadas por tipo de dato. La base de la que beben los agentes de IA.
• El cerebro: Microservicio Python. Capa de razonamiento desacoplada, escalable a cero y a N en Kubernetes. Implementa RAG con streaming, preparado para evolucionar hacia agentes autónomos multi-paso.

Esta separación de responsabilidades no es elegancia arquitectónica por el gusto de la elegancia. Es lo que hace el sistema resiliente cuando algo falla, fácil de mantener cuando el equipo rota y capaz de absorber las innovaciones que siguen llegando en el campo de la IA sin necesidad de reescribir todo.