DAM media asset search: keyword, semantic and similarity search

Searching for a product code and searching for a remembered scene are different tasks. If you know the code, you need a dependable match to that fact. If you remember a cyclist beside an orange wall, you need candidates that resemble the meaning of your description.

DAM search works best when the retrieval method matches what you already know. Exact facts call for identifier lookup or text matching. Known properties call for filters. Remembered meaning calls for semantic or hybrid retrieval. An example asset can be a starting point for similarity search, where that workflow is supported.

Each method helps decide what to inspect. None of them, by itself, proves that an asset is suitable for the campaign, product or market in which you intend to use it.

Start with what you already know

Before rewriting a query, identify the information you can supply. Do you have an exact identifier, a constraint, a description or an example? Those signals need different treatment.

What you know	Best starting point	What to check next
Exact asset ID, filename, SKU or product code	Identifier lookup or text matching against the field that contains it	Does the returned asset contain the exact identifier?
Collection, file type or another recorded property	Available filters or metadata constraints	Is the required property recorded and filterable?
A remembered scene or meaning	Semantic or hybrid search	Which candidates match the description, and where do they differ?
An existing example asset	Similarity retrieval, where an existing-asset workflow is available	Does "similar" mean related content, visual resemblance or near-duplication?
A business requirement such as market or permitted use	Business context and inspection, with a structured constraint where supported	What evidence establishes suitability?

A single search box can combine several methods behind the interface. That does not make their results interchangeable. The practical choice is which signal to start with and which uncertainty still needs resolving.

Use exact signals for exact facts

Suppose the product code is R42. Search the stored code or use a supported identifier field. A semantically related result for another commuter bicycle is not an acceptable replacement for the correct product.

The identifier must exist somewhere the chosen retrieval path can search. If R42 appears only in a separate product database, typing it into a DAM cannot establish a relationship that has never been recorded. A filename, supplied title, description or tag can carry the code where the product supports that field.

Exact asset-ID lookup, literal text matching and full-text search are also different operations. An ID lookup addresses one record. A literal text search matches stored characters. Full-text search usually analyzes words and can rank matches across indexed context; it is not automatically a byte-for-byte filename or code comparison.

Check the result for the exact fact you need. A substring match for R42 may also find R420. Text analysis can treat punctuation in a filename differently from literal matching. These are reasons to test identifiers explicitly, not reasons to abandon exact retrieval in favour of AI search.

Filters constrain the result set

A filter applies a condition. A JPEG filter should narrow the eligible files to that format. A collection filter should narrow them to the identified collection. Semantic ranking answers a different question: how closely does an eligible candidate relate to the query?

The distinction matters for business context. A structured campaign filter could constrain results to Autumn 2026 if the DAM stores that field and exposes it as a filter. Typing those words into a search box is a text or semantic query unless the product explicitly converts them into a supported constraint.

Do not assume every metadata value has a dedicated filter. Campaign context may be searchable text, a tag or collection membership. Use the mechanism the product actually provides and inspect the recorded value.

Filters also depend on data quality. A portrait asset with missing dimensions might not satisfy an orientation filter. If a narrow search returns nothing, remove one constraint at a time to determine whether the asset is absent or its recorded properties are incomplete.

Describe the scene when the filename is missing

The query cyclist beside an orange wall supplies a subject and a relationship. That is useful when you remember the image but do not remember whether its filename was descriptive or simply a camera-generated number.

Semantic retrieval compares meaning using numerical representations of a query and indexed asset context. It can surface a candidate whose description uses different words, such as a bicycle rider next to an orange building. The comparison does not establish an exact match to every part of the request.

Semantic retrieval is probabilistic. Results can include strong matches, partial matches and false positives. A cyclist against a red wall may be a plausible candidate. A parked bicycle near an orange building may match part of the description while missing the person you remember.

Describe observable details that help distinguish the image. If every result shows a cyclist, add the orange wall or the subject's position. Do not add unrelated business requirements and expect the semantic model to turn them into verified facts.

Generated titles, captions and tags can supply searchable language that the original filename lacked. They can also omit details or introduce errors. The AI tagging guide covers how that context is created. For retrieval, the immediate question is whether the available context lets this query surface the intended asset.

Hybrid search combines useful retrieval signals

Real asset queries often contain both specific words and a remembered description. Hybrid retrieval can combine text matching with semantic signals in one candidate ranking. Elastic's hybrid search documentation, for example, describes combining full-text and vector retrieval into one ranked result list.

That is useful when an identifier or campaign phrase matters alongside descriptive context. Text signals can help retain the specific wording; semantic signals can surface related descriptions that use different vocabulary.

Hybrid does not mean every method is always better together. A direct asset-ID lookup is still the appropriate starting point when you have the ID. A required file type still needs a supported constraint. Combining rankings does not convert a product code, approval decision or licence condition into something the system has verified.

When evaluating AI search in DAM, ask which signals the current search path combines and which controls it exposes. An endpoint named "full-text" can implement hybrid retrieval. A library search field can use ordinary text matching. The name alone does not tell you the behaviour.

Similarity depends on what is being compared

An example asset can replace a written query in a DAM that supports searching from an existing asset. You select a reference and inspect related candidates. Adobe's asset search documentation describes a Find Similar workflow that starts with an existing library image.

Similarity is a broad term. Semantic similarity concerns related meaning. Visual similarity concerns resemblance in characteristics such as framing, colour or composition. Near-duplicate detection asks whether files contain almost the same image. A product can implement these through different representations and workflows.

Two photographs can both depict a cyclist in a city while differing in perspective, lighting and subject placement. They are semantically related, but one may be a poor visual substitute for the other.

Conversely, two product photographs can have similar framing and colour while showing different models. Visual resemblance does not establish the same product, campaign or market.

Define what you want from "more like this" before judging the results. Related subject matter, matching composition and an alternate export of the same source are different requirements. A system comparing descriptive context should not be assumed to compare image pixels or reproduce visual art direction.

Reference handling also varies by product. Selecting an existing library asset does not imply that a search tool accepts an arbitrary uploaded image or external image URL. Verify the actual workflow before making it part of a team's retrieval process.

A relevant result still needs a suitability check

A search result can be relevant without being suitable for use. The cyclist image may match the remembered scene but show the wrong product. Another result may belong to a previous campaign or include copy for a different locale.

Retrieval answers which assets are worth inspecting. Business suitability answers which asset the team should actually use. Check the product, campaign, market and locale where they matter, then identify the intended source or selected creative. Reuse permission needs its own evidence.

Consider the boundary query approved UK hero. The words can help retrieve candidates if that context has been supplied and indexed. They do not prove that approval happened, that UK use is permitted or that the file is the chosen hero.

Those concepts work reliably as constraints only where the corresponding structured fields and filters exist and are maintained. A free-text description containing "approved" is still descriptive data. The approval decision belongs to the team's actual review record; a search match cannot enforce it.

The distinction between generated context and human business metadata explains why pixels cannot establish these decisions. Search users need enough visible context to understand why a file is a candidate and distinguish it from the asset they need.

Refine the uncertainty that remains

After the first query, change the signal that addresses the problem. If the results are visually plausible but show several products, use the recorded product code or inspect product metadata. If the scene is right but the file type is wrong, apply the available format filter. If too many results match the subject, add a distinctive scene detail.

Keep ranking and constraints separate during refinement. Adding "UK" to a descriptive query is not equivalent to a maintained market field. If the product has no such filter, inspect the supplied context and relevant business record.

When a search returns nothing useful, check the scope and the searchable data before repeatedly rephrasing. The wrong collection, an absent identifier or unfinished indexing can each produce an empty result set. A longer natural-language query will not repair those conditions.

How Vyso search works today

Vyso provides distinct asset-list and full-text/hybrid retrieval paths. The Search API documentation identifies both. Their contracts differ, so an integration should not assume that every search parameter works on both paths.

Asset-list text search matches filenames, generated or user-managed titles, user descriptions and generated or user-managed captions. The list supports constraints such as collection, asset type, format, orientation, date added and metadata status, plus sorting and offset or cursor pagination. The Assets API documents the available list controls.

The full-text/hybrid implementation combines indexed text matches with semantic candidates and ranks the combined results. Its query schema accepts q and an optional searchSessionId; it does not expose the same list-filter and pagination parameters. Indexed text includes filename context, generated titles/captions/tags and user-managed titles/descriptions/captions/tags. List text matching and indexed full-text retrieval therefore do not search identical field sets.

The semantic path compares the query with text-based asset context. This is different from comparing a text query directly with embeddings of the image pixels. Generated image descriptions contribute language about visual content; they do not independently compare composition or colour.

The current similarity implementation groups existing indexed assets using their stored context representations. Its search contract does not accept a selected asset ID or an arbitrary reference-image upload. These groups contain assets with related indexed context. They should not be treated as a search for visually similar neighbours or a dedicated "more like this" workflow starting from a chosen asset.

Image enrichment generates titles, captions and tags in the background. Stored, enriched and indexed are separate conditions. A file can be present in the library before the context needed for a descriptive query becomes available. Check processing and search updates when evaluating a recent upload.

These capabilities for images do not establish video semantic search, person identity recognition, mood or emotion detection, approval filtering or rights clearance. Search returns candidates; the team still verifies suitability. There is no latency or relevance guarantee implied by the retrieval method.

Test DAM search with representative queries

Use assets your team knows and queries that reflect different starting points. Include an exact code such as R42, supplied campaign wording such as "Autumn commuter campaign", a remembered scene and a similarity task where the product provides that workflow. Include a plausible but unsuitable asset so the test checks selection as well as retrieval.

Keep an evaluation record with the query, expected asset IDs, retrieval method, top results and failure reason. Record observed results from the actual library; do not judge a system only by whether it returned something.

• Did the expected asset appear, and how high did it rank?
• How many irrelevant candidates appeared before it?
• Did the user need to rephrase, and which detail changed the result?
• Did plausible results contain the wrong product, campaign or locale?
• Would an identifier lookup or structured filter have been more appropriate?
• For a visual-similarity task, did the candidates resemble the example in the characteristics that mattered?
• Could the user distinguish the intended source using the available context?

Classify the failure before deciding what to change:

• No useful result: check missing searchable context, scope, processing and retrieval-method mismatch.
• Relevant scene, wrong business asset: check suitability context and selection criteria.
• Too many plausible candidates: add useful metadata or refine with a supported constraint.
• Exact identifier not found: check the stored value, searchable field and matching or indexing behaviour.
• Wrong-looking similarity results: check whether the method measures visual resemblance at all, then evaluate its fit for the task.

Repeat the representative queries after changing metadata or search configuration. Keep the expected assets and retrieval method in the record so a change in ranking can be assessed against the same task.