Back office ops · Production

The infrastructure behind AI search in Figma: embedding models, vector search, and scale optimizations

The problem

Figma users were struggling to locate specific designs or components, especially in large organizations with complex design systems. Component search relied on strict text matching, forcing designers to manually enumerate keywords in descriptions.

First attempt

The initial indexing approach serialized entire Figma files as JSON and parsed that in Ruby, which was extremely slow and memory-intensive. An early experiment generating embeddings from textual JSON representations also produced worse results than image-based embeddings.

Workflow diagram · grounded in source
1
File change or publish triggers indexing
trigger
“Whenever a library is published, an asynchronous job is kicked off to compute embeddings for each thumbnail”
2
Headless C++ editor identifies frames
ai_action
“unpublished frames within a Figma file are not readily enumerable. To identify them, we run a headless server-side version of the C++ Figma editor in an asynchronous job”
3
SageMaker generates embeddings in batches
ai_action
“Our embedding model is deployed in AWS SageMaker. Embedding requests are sent to our SageMaker endpoint in batches, allowing us to perform inference in parallel.”
4
Write embeddings and metadata to indexes
integration
“Embeddings are written to the search index, along with additional metadata like the frame's name, the containing file ID and name, and the containing project, team, and organization of the frame.”
5
User submits search query
trigger
“you can find what you're looking for using just a screenshot, selection of Figma layers, or even a text description”
6
Query embedding generated on-the-fly
ai_action
“Figma generates an embedding on-the-fly that can be inputted into the embedding model directly. If you're searching via a selection of Figma layers, we simply generate a new screenshot of your selection and then use that as an input to t…”
7
Nearest neighbor vector search
ai_action
“issuing a query to find the items whose embeddings are nearest to the query”
8
Hybrid lexical and semantic result ranking
output
“searches are performed simultaneously against both the lexical index and the new embeddings index. Since raw scores from the independent OpenSearch indexes are not directly comparable, the result sets are assigned new scores based on a m…”
Reported outcome

Figma launched AI-powered search in early beta, enabling semantic and visual search across designs and components.
Infrastructure optimizations reduced indexing data volume to 12% of the original by debouncing, and cut the search index in half by removing duplicates and draft files.

Reported metrics
Indexing data volume after debouncing12%
Search index size after deduplicationcut the index in half
Reported stack
CLIPOpenSearchAWS SageMakerDynamoDBS3llvmpipe
Source
https://www.figma.com/blog/the-infrastructure-behind-ai-search-in-figma/
Read source ↗

Frequently asked questions

What did this team achieve with this AI workflow?

Figma launched AI-powered search in early beta, enabling semantic and visual search across designs and components.

What tools did this team use?

CLIP, OpenSearch, AWS SageMaker, DynamoDB, S3, llvmpipe.

What results were reported?

Indexing data volume after debouncing: 12%; Search index size after deduplication: cut the index in half (source-reported, not independently verified).

What failed first in this deployment?

The initial indexing approach serialized entire Figma files as JSON and parsed that in Ruby, which was extremely slow and memory-intensive.

How is this back office ops AI workflow structured?

File change or publish triggers indexing → Headless C++ editor identifies frames → SageMaker generates embeddings in batches → Write embeddings and metadata to indexes → User submits search query → Query embedding generated on-the-fly → Nearest neighbor vector search → Hybrid lexical and semantic result ranking.

Related back office ops cases