📦 Clona y dale ⭐ a stop-ai-agents-losing-memory-sample-for-aws
La Parte 1 de este post mostró cómo la búsqueda por palabras clave falla en preguntas semánticas, y midió dos backends vectoriales: FAISS y Amazon S3 Vectors (administrado), sobre los mismos recuerdos de un viajero. Ambos encontraron la respuesta. La diferencia fue el despliegue: local vs administrado en la nube.
Esta parte agrega un tercer backend vectorial: Amazon DynamoDB Vector Search, disponible de forma general desde 2025. La pregunta y los recuerdos son idénticos. Solo cambia el backend.
almacenado: dietary_notes: "Vegetariana; alergia severa a los mariscos — sin
crustáceos ni moluscos."
pregunta: "¿Qué debo evitar comer cuando salga a cenar en este viaje?"
DynamoDB Vector Search: resultado principal (score 0.231) respuesta encontrada: True
¿Qué es Amazon DynamoDB Vector Search?
Es un índice vectorial que se agrega a una tabla de DynamoDB existente. No es un servicio separado. Se define un bloque VectorIndexes al crear (o actualizar) la tabla, y DynamoDB almacena los embeddings como un atributo List en cada ítem. Las consultas usan la API SearchVectors.
La diferencia clave con S3 Vectors: los vectores viven en la misma tabla que tus datos operacionales. Si tu agente ya lee preferencias de usuario o registros de viaje desde DynamoDB, puedes agregar un índice vectorial a esa misma tabla y consultar por significado sin provisionar otro servicio.
| Amazon S3 Vectors | Amazon DynamoDB Vector Search | |
|---|---|---|
| Dónde viven los vectores | Bucket vectorial dedicado | Dentro de una tabla DynamoDB |
| Datos operacionales colocalizados | No | Sí |
| Latencia de consulta | ~100–200 ms | Un solo dígito en ms |
| Modelo de facturación | Por consulta + almacenamiento | Bajo demanda (PAY_PER_REQUEST) |
| Precisión | ✅ igual (mismos embeddings) | ✅ igual (mismos embeddings) |
| Sobrevive reinicios | Sí | Sí |
| Infraestructura a gestionar | Ninguna | Ninguna |
| Mejor para | Memoria vectorial dedicada, sin datos operacionales que gestionar | Agentes que ya usan DynamoDB, o que quieren un solo servicio para datos y embeddings |
Ambas son opciones válidas. S3 Vectors está diseñado para cargas de trabajo vectoriales dedicadas y es la opción correcta cuando se quiere memoria completamente separada de los datos operacionales. DynamoDB Vector Search es la opción correcta cuando los datos del agente ya están en DynamoDB y se quiere un solo servicio para ambos.
(Esta demo usa Strands Agents. El patrón aplica a cualquier framework de agentes.)
¿Cómo se ve la comparación de embeddings?
La misma pregunta, los mismos embeddings de Titan V2, cuatro backends en paralelo:
| Store | Encuentra la respuesta | cos_sim | Latencia de consulta |
|---|---|---|---|
| Clave-valor (búsqueda por palabras clave) | No | — | — |
| FAISS | Sí | 0.231 | <0.1 ms |
| Amazon S3 Vectors | Sí | 0.231 | ~195 ms |
| Amazon DynamoDB Vector Search | Sí | 0.231 | un solo dígito en ms |
Los tres backends vectoriales devuelven el mismo resultado con el mismo score, porque usan el mismo modelo Amazon Titan Text Embeddings V2. La llamada al embedding (~510 ms) sigue dominando la latencia total en todos ellos. Lo que cambia es la consulta después del embedding.
¿Cómo se agrega un índice vectorial a una tabla DynamoDB?
DynamoDB Vector Search requiere facturación bajo demanda (PAY_PER_REQUEST). El índice vectorial se declara al crear la tabla:
client.create_table(
TableName="agent-memory-demo-ddb",
BillingMode="PAY_PER_REQUEST", # obligatorio para índices vectoriales
KeySchema=[{"AttributeName": "memory_key", "KeyType": "HASH"}],
AttributeDefinitions=[{"AttributeName": "memory_key", "AttributeType": "S"}],
VectorIndexes=[{
"IndexName": "memory-vector-index",
"VectorAttribute": {"AttributeName": "embedding"},
"Dimensions": 1024,
"DistanceFunction": "COSINE",
"Projection": {"ProjectionType": "ALL"},
}],
)
La demo crea la tabla y el índice automáticamente si no existen: sin pasos en la consola, sin CDK.
¿Cómo se escriben y consultan vectores?
Los embeddings se almacenan como un atributo List de DynamoDB junto al resto del ítem:
client.put_item(
TableName="agent-memory-demo-ddb",
Item={
"memory_key": {"S": "dietary_notes"},
"text": {"S": "Vegetariana; alergia severa a los mariscos..."},
"embedding": {"L": [{"N": str(float(f))} for f in vector]}, # 1024 floats
},
)
Las consultas usan la API SearchVectors con el mismo formato AttributeValue:
resp = client.search_vectors(
TableName="agent-memory-demo-ddb",
IndexName="memory-vector-index",
SearchVector=[{"N": str(float(f))} for f in question_vector],
TopK=3,
)
Nota sobre el score: SearchVectors devuelve una distancia coseno (menor = más similar). La demo lo convierte a similitud coseno (1.0 − score) para que el resultado sea directamente comparable con FAISS y S3 Vectors.
¿El índice sobrevive un reinicio?
Sí. Es DynamoDB. Un cliente nuevo instanciado después de ejecutar la demo sigue viendo todos los ítems:
fresh = DynamoDBVectorStore()
fresh.count() == 10 # True — los 10 recuerdos están ahí
Esta es la misma prueba de reinicio que se ejecutó en la Parte 1 para S3 Vectors. Ambas pasan.
¿Cómo se ejecuta el Test 4?
El Test 4 corre como parte del test_vector_memory.py existente en el repo:
git clone https://github.com/elizabethfuentes12/stop-ai-agents-losing-memory-sample-for-aws
cd stop-ai-agents-losing-memory-sample-for-aws/02-vector-memory-demo
uv venv && uv pip install -r requirements.txt
uv run python test_vector_memory.py
Necesita credenciales AWS (aws configure) para los embeddings de Titan (Bedrock), S3 Vectors y DynamoDB. La demo crea la tabla DynamoDB y el índice vectorial automáticamente si no existen. Requiere boto3>=1.43.72 (SearchVectors se agregó en esa versión).
¿Cuándo elegir DynamoDB sobre S3 Vectors?
| Situación | Elige |
|---|---|
| No hay tabla DynamoDB existente; la memoria es el único caso de uso | S3 Vectors — diseñado para cargas de trabajo vectoriales dedicadas |
| Hay una tabla DynamoDB existente con datos de usuario | DynamoDB Vector Search — agrega el índice a la misma tabla; un servicio, un modelo de facturación |
| Se necesita latencia de consulta menor a 100 ms después del embedding | DynamoDB Vector Search — un solo dígito en ms vs ~200 ms |
| Alto QPS, búsqueda híbrida o filtrado avanzado | Base de datos vectorial dedicada (OpenSearch, Qdrant, etc.) |
FAQ
¿Puedo agregar un índice vectorial a una tabla DynamoDB existente?
Sí. Usa update_table con VectorIndexUpdates para agregar el índice a una tabla que ya tiene datos. Los ítems existentes que no tengan el atributo de embedding no aparecerán en las consultas vectoriales hasta que se haga un backfill de sus embeddings.
¿DynamoDB Vector Search funciona en todas las regiones?
Revisa la disponibilidad regional; la funcionalidad es GA pero no está disponible en todas las regiones desde el día del lanzamiento.
¿Cuál es el costo comparado con S3 Vectors?
DynamoDB Vector Search usa facturación bajo demanda: se pagan las unidades de capacidad de lectura/escritura y el almacenamiento de la tabla. S3 Vectors cobra por consulta y por vector almacenado. Para cargas de trabajo de memoria de agentes (consultas poco frecuentes, pocos vectores por usuario) ambos tienen costo bajo; el factor decisivo es la arquitectura, no el precio.
¿Por qué SearchVectors devuelve una distancia y no una similitud?
SearchVectors devuelve distancia coseno (1 − cosine_similarity), donde 0 significa idénticos y 1 significa opuestos. La demo convierte con 1.0 − score para obtener similitud coseno y poder comparar directamente con FAISS (que devuelve producto interno de vectores normalizados, equivalente a similitud coseno) y S3 Vectors (que también devuelve 1 − distancia).
Recursos
- Repo de la demo 02 con la prueba completa de 4 backends
- Amazon DynamoDB Vector Search — Guía del desarrollador
- Anuncio GA de Amazon DynamoDB Vector Search
- Amazon S3 Vectors — Guía del usuario
- Amazon Titan Text Embeddings V2
- Parte 1 — FAISS y S3 Vectors
¿Qué te sorprendió más: la latencia de un solo dígito en ms de DynamoDB, o que el score de similitud coseno sea idéntico en los cuatro backends? Comparte en los comentarios.
Gracias!
🇻🇪 Dev.to Linkedin GitHub Twitter Instagram Youtube
Top comments (0)