Project guide

This repository accompanies the MongoDB tutorial on building an AI-powered image search application. If you watched the video, or you are about to, this page summarizes how the repo is organized and what each layer of search does.

Start here

Most operating systems still rely heavily on filenames when searching images. Once your collection grows into hundreds or thousands of photos, finding exactly what you are looking for becomes surprisingly difficult.

This project explores a different approach. Instead of searching filenames, a vision model understands each image, generates structured metadata, stores everything in MongoDB, and layers increasingly capable search techniques on top of that data.

Helpful links

Built with MongoDB Search, MongoDB Vector Search, Ollama, Voyage AI, and Next.js.

What you'll build

Starting with nothing more than a folder of images, you build a search application capable of understanding what is actually inside each image. The search experience grows one layer at a time.

StepTry searchingWhat happens
MongoDB SearchbeachKeyword match across titles, descriptions, summaries, tags, and other metadata
MongoDB Vector SearchoceanFinds relevant images by meaning, even when the exact word never appears in a document
Hybrid Searchwild flying animalsMongoDB Search and Vector Search combined with $rankFusion for keyword precision plus semantic understanding

Architecture

One of the goals of this project was to keep the overall architecture simple. Everything revolves around a single MongoDB document per image.

high-level pipeline

Images
   │
   â–Ľ
Vision Model (Ollama)
   │
   â–Ľ
Structured Metadata
   │
   â–Ľ
MongoDB Documents
   ├── MongoDB Search
   └── Vector Embeddings
            │
            â–Ľ
       Hybrid Search
            │
            â–Ľ
      Next.js Application

Rather than introducing multiple databases or external search systems, MongoDB becomes the central source of truth. Metadata, embeddings, and search indexes all live together. That simplicity is one of the best parts of this architecture.

Why it's built this way

As the project grew, a few design decisions ended up making a big difference.

  • Two LLMs are better than one. The vision model focuses on understanding the image. A second instruction model transforms that understanding into structured JSON. Prompts are easier to iterate on and documents are more consistent.
  • Embeddings are generated separately. They can be regenerated later without analyzing every image again, and experimenting with different embedding models is much easier.
  • Everything lives in one MongoDB document. Titles, descriptions, tags, colors, feelings, prompt history, model information, embeddings, and location data. The document grows as the application grows.
  • Hybrid search gives you the best of both worlds. Keyword search is precise. Vector search understands meaning. Hybrid search combines both, which is the experience many real-world applications need.

Repository guide

If you are exploring the code after watching the video, these are the best places to start.

LocationPurpose
tools/process/Image processing pipeline, Ollama integration, metadata generation, and embedding tools
lib/image/queries/MongoDB aggregation pipelines for Search, Vector Search, and Hybrid Search
app/api/API routes connecting the frontend to MongoDB
app/Next.js application and user interface

Suggested reading order

That order mirrors the tutorial and builds the project one concept at a time.

Video guide

These sections map directly to the repository. Timestamps point to where each topic appears in the tutorial.

Video sectionTimestampRepository
System architecture & local LLM processing2:05ARCHITECTURE.md
Generating structured metadata JSON3:19tools/process/
Image processing4:44tools/process/
Setting up traditional text search8:33SEARCH.md, lib/image/queries/
Creating a vector search index13:09generate-embeddings.js
Implementing hybrid search with rank fusion20:25lib/image/queries/

Go deeper

Where to go next

Image search is really just the beginning. The same architecture can be applied to many other types of data.

  • Documents
  • Knowledge bases
  • Product catalogs
  • Support tickets
  • Internal tools
  • Retrieval-Augmented Generation (RAG)
  • Recommendation systems

Once your data has been enriched with AI and stored in MongoDB, you can continue building on top of it without introducing additional systems. That is what makes this pattern so powerful.

Learn more: learnmongo.com