Article
Semantic search in a DAM with Laravel: how I built it
Searching video, images and text by meaning instead of keywords, inside a DAM in production. Choices, limits and what actually matters.
Published 12 March 20266 min readLaravelAIDAM
In the DAM of BaseCamp Studio, where I work as a full-stack developer, I built a Laravel package that indexes video, images and text and lets you search them by meaning. Type "person running on the beach at sunset" and you find the clip even if nobody ever tagged it that way. Here I describe how I set it up and, above all, what I learned about the hard part not being the model.
No model from scratch
The first decision was to train nothing. Embedding models already on the market turn a text, an image or a video frame into a vector, and two similar contents end up close together. For a company with a DAM in production, building its own model would have been a research project; integrating existing ones was an engineering project. The second one ships, the first one gets presented at conferences.
How the package is built
The flow is linear. When an asset enters the DAM, a queued job produces a textual and vector representation of it: for images straight from the visual content, for videos by sampling frames across the duration, for text from the text itself. The vectors go into an index that can be queried by proximity. A search applies the same transformation to the user's phrase and returns the closest assets, combined with the classic filters (client, project, format, date) a DAM already has. Audio is next, with the same scheme via transcription.
All in Laravel, inside a package separate from the application, so it updates on its own and can be switched off without touching the rest. Alongside it there's automatic tag generation on assets, again with existing AI services: those serve classic searches and users who want to see at a glance what's inside a file.
What actually matters
- Cost per asset. Every indexing run is a paid call. With thousands of videos the question isn't "does it work?" but "what does it cost to reindex everything if we change model?". That gets decided upfront.
- The queue. Indexing must not slow down uploads. Async jobs, retries, and a way to see what's pending.
- The users' flow. Semantic search is only useful if it sits where people already search, with the same filters. A separate "AI search" panel gets opened by nobody after the first week.
- False positives. By meaning you also find things that resemble but don't belong. You need a threshold, and you need to tell users.
The lesson, if I have to pick one: the AI was 20% of the work. The other 80% was making it fit the flow of the people who use the DAM every day without them noticing. It's the same thing I offer SMBs when I talk about AI in real work: not a new model, but features that live inside the tools you already use.