Event Embedding Pipeline

Problem

ParentConnect’s event system needs semantic understanding of events — for duplicate detection when new events are created and for natural language search. Every event needs a vector embedding, but generating them manually or in batch jobs means events sit without embeddings until the next run. Embeddings should exist the moment an event is saved, and they shouldn’t be regenerated unnecessarily when unrelated fields (like a like count) change.

Approach

A Firestore onDocumentWritten trigger on events/{eventId} fires every time an event is created or updated. It constructs an embedding input by concatenating the event’s key content fields:

{title}. {description} Event date: Saturday, April 05, 2026.

The date is formatted as a human-readable string so the embedding captures temporal context — “Saturday morning workshop” and “Tuesday evening class” produce meaningfully different vectors.

Before calling Vertex AI, the function compares the before and after values of three fields — title, description, and startDate. If none changed and an embedding already exists, it returns early. This means updates to unrelated fields (interactions, moderation status, image) don’t trigger an unnecessary API call.

When embedding is needed, it calls Vertex AI’s text-embedding-004 model with SEMANTIC_SIMILARITY as the task type, producing a 768-dimension vector stored directly on the event document.

A separate admin script (regenerateEmbeddings.js) handles bulk re-embedding for model migrations. It checks the dimension count of each existing embedding — if it’s already 768, it skips. If it’s a different dimension (from an older model), it regenerates. This made it straightforward to upgrade from an earlier embedding model without re-processing events that were already current.

Results

• Every event gets an embedding within seconds of creation — no batch delay
• Unrelated field updates (likes, moderation, images) don’t trigger re-embedding
• Cost is negligible: ~$0.000005 per event ($0.025 per 1M characters)
• Embedding failures are non-blocking — the event still saves, and duplicate detection falls back to string similarity
• The bulk regeneration script processed the full event catalog in one run when upgrading embedding models