AWS for M&E Blog
Finding the perfect moment: How Formula 1® uses AWS AI to search archives in seconds
Formula 1 fandom doesn’t switch off when the checkered flag drops. Fans follow their favorite drivers between races, replay the overtakes, relive the battles that drew them to the sport, and share the moments that mattered. For a global fan base of more than 830 million, that appetite runs all week, and serving it is now a core part of the fan experience.
As one of the most data-saturated sports, in addition to telemetry from the cars, F1 has been capturing audio, video, and imagery at races around the world since the 1970s. That footage has grown into a 12-petabyte F1 Video Archive, which social admins, production teams, and broadcasters rely on to find that one unforgettable moment for the fans waiting on the other side. For perspective, 12 petabytes is roughly the equivalent to streaming over 4 million hours of HD video footage.
F1 worked with AWS to migrate petabytes of footage from ageing tape robots, in multiple formats and proxy files, into Amazon Simple Storage Service (Amazon S3) alongside the live footage from every new race. That gave the sport one durable home for its heritage: the F1 Video Archive. In April 2026, F1 upgraded the archive with a new Media Archive Discovery system. Working with Amazon Web Services (AWS), the team added Amazon Bedrock in a deliberately narrow role: a layer that reads a request in plain language, works out what it means, looks up any facts it depends on, and turns it into a precise search the archive can retrieve. Users can now type a prompt like “find celebrations after Leclerc’s first Ferrari win” and instantly source the clips they need.
Upgrading traditional search to manage complex queries
Modernizing search over an archive this large presented two kinds of challenges. The first was foundational. F1 needed to index millions of assets and refine the mappings, analyzers, and filtering, so the search engine handles everyday lexical variation including misspellings, partial names, and different word forms efficiently. The second concerns the intent by each search. A single search often mixes a driver, a season, a session, and a mood, such as “Verstappen wet qualifying laps 2021.” Answering it well means taking the request apart, deciding which pieces are hard requirements or ranking signals, then reassembling them so the search is specific without over-narrowing the results.
The most memorable footage tends to be described rather than labeled, such as “a driver’s first win” or “a moment of raw emotion.” Serving those means reading a loose description and working out which parts point to a place, a season, or a theme the archive records. Some searches require information based on facts, like “pole position Silverstone 2007,” which depends on race results kept in a separate database. Answering them takes several steps. First, recognize that the question depends on a result, then look up that result, work out who or what it points to, and find that specific footage.
The common thread is that building a good query is the hard part. That is what a large language model (LLM) adds to traditional search. Rather than matching text, it interprets the request, breaks it into the pieces that matter, checks them against what the archive contains, and runs multistep logic (like resolving a fact) before retrieving a clip. Because the system recognizes F1 specific terminology, including driver names, teams, circuits, and race conditions, and carries contextual awareness of historical facts like race results, it removes the technical barriers that used to slow content discovery.
The approach
Instead of replacing the search engine, the team paired Amazon OpenSearch Service optimization with an AI-based query enhancer, a reasoning layer that sits in front of the existing engine. That layer takes the way the user naturally phrases a request and translates it into the precise, field-by-field query an expert would have built by hand.
Two rules shaped every decision. First, don’t slow down the everyday searches the engine already handles well because the new layer only does extra work on the queries that genuinely need interpreting. Second, never leave a user staring at a blank screen. If any step fails or comes up short, the system falls back to a plain text search, so results always come back.
How it works
Before adding any AI, the team rebuilt the underlying OpenSearch Service index so ordinary search would be faster, more resilient, and cheaper to run:
- A cleaner document structure –Fields were reorganized into consistent, logically grouped shapes, which makes precise queries, like filtering clips by time, far easier.
- Matching tuned to each kind of data –Rather than treating every field the same, each tag type got the matching it deserves. Fuzzy matching was provided where users approximate a spelling, tolerance for wording variation where terms are descriptive, and exact or range matching for codes and numbers. This absorbs everyday variation without ever calling a model.
- Sharding for speed –The index was split so queries run in parallel, improving response time and write capacity without over-provisioning the cluster.
Grounding the model in a catalog of real F1 tags
The single most important design decision is that the model is never asked to recall F1 knowledge on its own. Instead, its instructions include a catalog of the tags the archive uses, mapping the wording to a value that already exists in that catalog and returning nothing that isn’t there. For example, when someone types “British GP,” the model returns the archive’s official value, “British Grand Prix,” and it won’t invent an event the archive doesn’t have. Because every answer is a real catalog value, it can be used directly as an exact search filter. Editors are constantly adding, changing, and retiring tags, so a separate scheduled process keeps the catalog current in the background, and new tags become usable without anyone touching the search code. Plus, if the catalog is ever unavailable, the layer falls back to ordinary search rather than guessing.
The layer uses Amazon Nova on Amazon Bedrock for two distinct tasks:
- Entity extraction turns free text into validated catalog values, each labeled with a type and a priority, plus a flag for whether the query depends on a fact.
- Fact resolution handles the questions that need a lookup rather than a tag match (such as “who took pole position at Monaco 2023?”) by finding the answer and turning it into a filter.
A deterministic check sits between the model and the results, and the model runs a self-correction pass to catch its own misreadings, keeping results complete without manual tuning. Every clip goes through two separate decisions. Gating decides which clips are eligible to appear, and scoring decides how the eligible ones are ranked. Keeping the two apart matters, because unmatched queries always fall back to a plain-text search, so tightening precision can never leave a user empty-handed.
When results come back, a new timeline explorer lays them out across a chronological view, so a user can see exactly where relevant moments fall within the F1 historical archives. Instead of a flat list, an editor sees how a driver’s story, a rivalry, or a circuit’s history unfolds across the decades and can jump straight to the era they care about. The following screenshot shows the timeline explorer.
Figure 1: The timeline explorer component on the F1 Video Archive
Keeping cost and speed in check with layered caching
Three caches address a different source of cost or delay:
- Query-result cache –Before any model call, the system checks the query-result cache on Amazon DynamoDB whether it has seen this exact query before. If it has, it reuses the stored result and skips the model entirely, removing both the model cost and the model delay.
- In-memory catalog cache –The tag catalog is held in the AWS Lambda environment and reused across warm invocations, so it isn’t reread on every request.
- Prompt caching –For queries that do reach the model in Amazon Bedrock, the catalog is by far the biggest part of the prompt and rarely changes. Marking it as cacheable bills those tokens at a reduced rate on repeat calls.
Prompt caching alone cut model cost by 88 percent, by recognizing that most of the prompt stays the same from one request to the next. Storing the catalog as compact rather than formatted JSON trimmed another 12 percent. And the query-result cache removes cost and delay altogether for repeated searches.
AI guardrails are safe by design
Because this layer sits in front of a production tool and can reach a database, the team constrained what the model is allowed to do at every step rather than trusting it to behave:
- A closed vocabulary –The extractor can return only values that exist in the catalog. Anything else is discarded, so the model can’t invent drivers, events, or tags.
- The model never writes SQL –For factual questions, Amazon Nova returns a structured description of the lookup (table, filters, ordering, limit), never raw SQL. A separate validator turns that description into a safe, parameterized query, checking every element against an allowlist of approved tables and columns only, a restricted set of operators, numeric fields that reject non-numbers, and a bounded row limit.
- Least-privilege access –The fact resolver can read only flat, read-only tables through a single tool. It can’t write, reach other tables, or run arbitrary queries.
- Input gating –Queries that shouldn’t reach a model at all, like empty searches, filenames, and internal media codes, are caught up front and sent straight to standard search.
- Graceful degradation –Every model-dependent step is wrapped so a timeout, a validation failure, or a missing dependency falls back to a plain-text search.
These controls follow AWS guidance for building generative AI responsibly: grounding outputs in trusted data, limiting what the model can do, validating inputs and outputs, and designing for safe failure. Where broader content filtering is needed, they can be complemented with managed controls such as those in Amazon Bedrock Guardrails.
What happens on a single search
The layer sits behind AWS AppSync and is run by a Lambda function, drawing on a tag catalog in Amazon DynamoDB, historical race facts in Amazon Relational Database Service (Amazon RDS) for PostgreSQL, the media index in OpenSearch Service, and Amazon Nova models in Amazon Bedrock. A query flows from users through AWS AppSync and an AWS Lambda orchestrator, which draws on Amazon Bedrock (using Amazon Nova), Amazon DynamoDB, Amazon RDS for PostgreSQL, and Amazon OpenSearch Service before ranked results return to the user:
- A user submits a query from the archive frontend to AWS AppSync.
- AWS AppSync hands it to the Lambda orchestrator, which runs skip checks. Empty queries, filenames, and internal codes go straight to baseline search.
- The orchestrator checks the query-result cache in DynamoDB. On a hit, it reuses the stored result and skips the model calls entirely.
- On a miss, it reads the tag catalog from DynamoDB (served from the in-memory cache).
- It calls Amazon Nova to extract catalog-validated entities. For example, it resolves “British GP” to “British Grand Prix” and separates the event from the circuit it was held at. Prompt caching covers the fixed catalog portion of the prompt.
- For factual queries such as “pole position Silverstone 2007,” a second Amazon Nova call resolves the answer against Amazon RDS for PostgreSQL and turns it into a filter. The race statistics backing these lookups were sourced from a verified internal repository.
- The entities and resolved facts become an OpenSearch Service query, split into gating clauses (which documents are eligible) and scoring clauses (how they rank), and run against the index.
- Ranked results return through AWS AppSync to the user, laid out on the timeline explorer. If any step fails, such as a model timeout or an unavailable catalog, the layer falls back to a weighted text search, so the user still gets results.
Separately from this path, a scheduled Lambda function keeps the catalog up to date.
The following diagram shows the path a single query takes.
Figure 2: Architecture diagram of the natural-language search layer for the F1 Video Archive
Why it matters
The payoff lands with the fan. An editor building content regardless of media platform can now ask the archive a question in plain language and get back the same precise, field-scoped result an expert would have built by hand. What previously took hours of research now takes minutes, which means teams can create more diverse and compelling content inside tight production timelines, and the heritage of the sport—its action and its history—stays within reach of the fans who love it.
The broader lesson carries well beyond motorsport. Adding generative AI to an existing search stack doesn’t mean replacing it. The biggest gains here came from using the model in a narrow, well-guarded role, grounding it in trusted data, and letting the existing search engine keep doing what it does best. That is an approach any organization sitting on a deep archive can follow to better serve the people on the other end of the search box.