Video Search for Business: Find the Clip, Not the File

Google DeepMind released EmbeddingGemma 2 this week, a model small enough to search audio, video and images on a phone. Buried in that is a change most businesses have not costed. The archive of recorded calls, site photographs and training footage you have been accumulating for years has been write-only: easy to add to, searchable by filename and date, and otherwise inert.

What changes when content becomes the index

Searching video today means searching what somebody typed about it. A filename, a date, a folder, a tag if you were disciplined. The footage itself contributes nothing, which is why finding a specific moment means either remembering roughly when it happened or scrubbing.

Content-based retrieval inverts that. A model turns each segment into a numeric representation of what it contains, your query gets the same treatment, and matching happens between those. You can ask for the damaged pallet on the loading dock without anyone having written the words damaged pallet anywhere.

Model size is the commercially interesting part. Running on a phone or a laptop means the index can be built where the footage already is, which removes the upload, the bandwidth bill and most of the data residency conversation. That is the same local-first argument covered in running LLMs locally.

Four questions this answers

Each of those questions currently gets answered by somebody spending forty minutes, or by nobody. The second outcome is more common and less visible, because a question that goes unasked never appears in a report.

The last row carries the clearest return for most businesses. Reshooting assets you already own is a recurring cost that nobody attributes to search, and it sits next to the catalogue work described in AI product photography.

Audio is usually the cheaper win

Before building anything over video, check what transcription alone gives you. A recorded call becomes searchable text at low cost, and text search is well understood, auditable and easy to connect to the rest of your systems. For sales conversations and support calls, that covers most of the value.

Visual retrieval earns its place where the information is not spoken. Conditions on a site, equipment states, product appearance, anything where the answer is what something looked like. Splitting the archive that way keeps the project small enough to finish.

Searchable is also discoverable

An archive that was practically inaccessible becomes practically retrievable, and that moves your position on several things at once. Access requests become answerable where previously the honest reply was that locating it was not feasible. Material becomes findable in a dispute by anyone entitled to ask.

Internally it also changes what one employee can look up about another. Footage recorded for safety or quality becomes a queryable record of who was where, which is a different thing from what was consented to when the camera went up. The boundary question is worked through in AI video analysis and the line to surveillance.

Three decisions handle most of this. Who can query the index, which is usually a smaller group than who can access the files. Whether queries are logged, which they should be. And a retention period, because the strongest argument against holding fifteen years of searchable footage is that you have no reason to. Data residency considerations are in AI data residency in Canada.

Expect approximate answers

Content retrieval returns a ranked list of likely matches rather than a definitive answer. Treat the output as a shortlist a person opens, which is the same posture that works for document extraction, where scoring per field rather than per document is the useful discipline, as in extracting data from PDFs.

That caveat matters most where the result will be used as evidence. A clip surfaced by a search is a candidate, and the thing you rely on is the clip a person watched and confirmed. Keep that distinction explicit in any process that touches a claim or a contract.

A first project that finishes

One archive, one question, three known moments. Choose the collection where an answer has money attached, usually recorded calls. Index that collection only. Then test retrieval against three moments you already know are in there, because a search tool you cannot trust to find a known item will not get used on an unknown one.

If it finds all three, extend to a second archive. If it finds one, the problem is usually the index rather than the model, and it is cheaper to learn that on one collection than on fifteen years of everything. The reason these projects stall is almost always scope, not technology, which is the pattern behind most data integration work.

Frequently Asked Questions