nomad prefrences
Nomad
QuarkLM UI
quicky search results
Model selection
home screen quicky and video based context result

Inspiration

QuarkLM started with a simple frustration: we remember what something contains, but rarely remember what we named it.

You might remember a zebra appearing in a video from a trip, a sentence from your lecture notes, or an idea saved somewhere in a PDF. The memory is clear enough to describe, but finding the actual file still means scrolling through folders and opening things one by one.

We wanted to make that description enough.

That became the idea behind Quicky, our semantic search agent for iOS. Alongside it, we built Nomad to help discover places around us. Both sit on top of QuarkLM, our application for running AI locally. Together, they address two everyday needs: finding something we already have and discovering something new.

What it does

Quicky is a multimodal semantic search engine for iOS. It lets users search supported, accessible content—including text, images, PDFs, notes, and video frames—using natural language.

For example, a user can ask for “the video with a zebra” without knowing its filename or when it was recorded. The goal is to retrieve content based on its meaning, including relevant matches that do not contain the exact search words.

Quicky combines semantic similarity with keyword matching. This helps it handle both descriptive searches and queries where a particular word matters.

Nomad applies the same focus on reducing manual searching to local discovery. Users set preferences for cuisines, attractions, and essentials, and the agent surfaces relevant places using available location and place data.

QuarkLM also supports offline queries, image descriptions, and text-to-image generation. These are supporting capabilities within the wider application.

How we built it

We built QuarkLM using Flutter for iOS and developed Quicky as a search pipeline with separate stages for file ingestion, neural inference, and query execution.

Our embedding pipeline uses EmbeddingGemma to create vector representations for semantic retrieval. Across the supported content types, the pipeline prepares searchable representations and maps them into a shared vector space. This gives Quicky a way to compare the meaning of a query with the content it has indexed.

When someone searches, Quicky creates a query vector and tokenizes the query into keywords. A hybrid scorer combines cosine similarity with keyword matching to rank the results. The semantic component helps retrieve related concepts, while the keyword component helps preserve exact terms.

We separated file ingestion, heavy neural inference, and real-time query execution into isolated OS processes. This architecture keeps expensive indexing work away from the interactive search path and helps keep the app responsive.

Challenges we ran into

The biggest challenge was making semantic search practical on a phone. Processing files and running neural inference can be expensive, but users still expect typing and searching to feel responsive.

That pushed us to think carefully about which work belongs in ingestion, which work can be prepared ahead of time, and what must happen when a query arrives.

Working with different content types also made the problem more involved. A note, a PDF, and a video do not arrive in the same form, but the search experience needs to feel consistent.

Ranking was another challenge. Semantic similarity is useful for descriptions, but exact keywords still matter. Combining both signals gave us a way to address that trade-off.

Accomplishments that we're proud of

We're proud of implementing a search pipeline that connects natural-language queries with the contents of different file types.

The most satisfying part is the interaction itself: describing something you remember and seeing a relevant file appear. It makes the value of the underlying models easy to understand.

We're also proud of the architecture behind Quicky. Separating the expensive processing from interactive search was an important step toward making the experience usable on a mobile device.

What we learned

We learned that a useful AI application depends on much more than the model. Ingestion, indexing, process boundaries, and ranking all affect whether a search feels helpful.

We also learned that semantic search and keyword search complement each other. People sometimes describe a concept and sometimes remember one exact word. A useful system needs to support both.

Building Quicky gave our work a clear direction: use local AI to reduce the effort involved in an ordinary task.

What's next for QuarkLM

Our next steps are to improve Quicky’s retrieval accuracy, refine the hybrid scorer, and evaluate it against more varied files and real search queries. We also want to reduce indexing time and memory use as collections grow.

For Nomad, we want to improve preference-based discovery and explore cached place information for limited-connectivity situations.

More broadly, we want QuarkLM to support useful everyday agents while giving users clear control over the content those agents can access. Quicky is our first step toward making the things we save easier to find again.