Saltearse al contenido
Nappai Documentation

Cassandra Chat Memory

Cassandra Chat Memory es un componente de Nappai que permite almacenar y recuperar conversaciones de chat directamente en una base de datos Apache Cassandra (o AstraDB).
Con él, cada vez que un usuario envía un mensaje, el componente lo guarda en la tabla indicada y, cuando sea necesario, recupera el historial completo de esa sesión para que el modelo de IA pueda usarlo como contexto.

¿Cómo funciona?

Cuando arrastras el componente al flujo de trabajo, Nappai lee los datos de la credencial Cassandra DB que hayas configurado previamente (ID de la base de datos, nombre de usuario y token).
El componente se conecta a Cassandra usando la librería cassio.

  • Si el Contact Points es un UUID, se asume que es un ID de AstraDB y se inicializa con cassio.init(database_id=…).
  • Si no, se inicializa con los puntos de contacto, usuario y contraseña.

Una vez establecida la conexión, el componente crea una instancia de CassandraChatMessageHistory.
Esta instancia gestiona la tabla especificada (Table Name) dentro del keyspace (Keyspace).
Cada mensaje enviado por el usuario se inserta en la tabla con el session_id proporcionado, y cuando el flujo necesita el historial, la instancia recupera todos los mensajes asociados a esa sesión.

Entradas

Nota: Este componente necesita una credencial Cassandra DB.

  1. Configura la credencial en la sección de credenciales de Nappai.
  2. Selecciona esa credencial en el campo Credential del componente.
  • Cluster arguments: Diccionario opcional de argumentos adicionales para el clúster de Cassandra.
  • Keyspace: Nombre del keyspace (o namespace de AstraDB) donde se encuentra la tabla.
  • Session ID: Identificador único de la sesión de chat.
  • Table Name: Nombre de la tabla (o colección de AstraDB) donde se almacenarán los mensajes.

Salidas

  • Memory: Objeto BaseChatMessageHistory que contiene el historial de mensajes de la sesión.
    Este objeto se puede pasar a otros componentes de Nappai que requieran contexto de conversación.

Ejemplo de Uso

  1. Configura la credencial: En la sección de credenciales, crea una nueva credencial tipo Cassandra DB con tu ID de base de datos, usuario y token.
  2. Añade el componente: Arrastra Cassandra Chat Memory al flujo.
  3. Selecciona la credencial: En el campo Credential, elige la credencial que acabas de crear.
  4. Define los parámetros:
    • Keyspace: my_keyspace
    • Table Name: chat_messages
    • Session ID: {{session_id}} (puedes usar una variable del flujo)
    • Cluster arguments: opcional, por ejemplo { "load_balancing_policy": "TokenAwarePolicy" }
  5. Conecta la salida: Conecta la salida Memory a un componente de generación de respuestas (por ejemplo, OpenAI Chat).
  6. Ejecuta el flujo: Cada vez que el usuario envíe un mensaje, el componente guardará el mensaje y recuperará el historial completo para que el modelo lo use como contexto.

Componentes Relacionados

  • InMemoryChatMemory – Guarda el historial en memoria local (ideal para pruebas).
  • RedisChatMemory – Usa Redis como backend para el historial.
  • PostgresChatMemory – Almacena el historial en una base de datos PostgreSQL.

Consejos y Mejores Prácticas

  • Usa un session_id único para cada conversación; así evitarás mezclar mensajes de usuarios distintos.
  • Limita el tamaño del historial: si tu modelo solo necesita los últimos 10 mensajes, filtra el historial antes de pasarlo al modelo.
  • Monitorea el rendimiento: Cassandra es rápido, pero las consultas de historial pueden crecer con el tiempo; considera archivar sesiones antiguas.
  • Evita exponer credenciales: Mantén la credencial en la sección de credenciales y no la incluyas en el flujo de trabajo.

Consideraciones de Seguridad

  • Protege la credencial: Asegúrate de que solo los usuarios autorizados puedan crear y usar credenciales Cassandra DB.
  • Cifra las conexiones: Cassandra admite TLS; habilita la capa de seguridad en la configuración de la credencial.
  • Control de acceso a la tabla: Configura roles y permisos en Cassandra para limitar quién puede leer o escribir en la tabla de mensajes.
  • Auditoría: Registra quién accede a la tabla y cuándo, para detectar accesos no autorizados.