How to Build an AI-Based Semantic Search for a Fitness App

A fitness app that starts with a handful of short answers to common questions ends up with a library of meal plans, coach notes, product recommendations, recovery guides, and habit-building content. Once that library grows, search starts to fail.

Users don’t know how editors title articles or how coaches phrase questions in the article collection. One person types "craving sugar," another types "I keep reaching for chocolate at night." A person reads one question asked two ways. A keyword-based search engine sees two queries that might lead to different results or no results at all.

This article walks through how the team handled this in a client’s fitness and nutrition app: why keyword search falls short for fitness content, how semantic search works in practice, and how a working implementation was built without over-engineering the architecture.

When Keyword Search Stops Working for Fitness Content

The product in question is a mobile app for people tracking nutrition, building habits, and working out. The app’s knowledge base covers questions and answers about weight loss, training, food choices, eating habits, meal timing, and recovery.

Early on this was manageable. A few dozen articles still worked: users browsed categories or typed a word into the search bar. As content grew, finding the right article got harder, because people searched by describing a condition, a doubt, or an everyday situation:

• "what to eat so I don’t binge at night"

• "can I drink diet soda while losing weight"

• "what to buy at the store for more protein"

Regular keyword search fails when the article does not contain those exact words. Sometimes it finds a formally similar article that still is not the one answering the question.

Semantic similarity search addresses this by matching meaning. Users type naturally, and the app returns content that’s conceptually close to their query, whether or not it contains the same words.

A quick comparison of the two approaches:

Keyword Search

Semantic Search

Matches exact or partial words

Matches meaning and user intent

Misses synonyms and related concepts

Understands that "sweet craving" and "sugar urge" are the same thing

Returns nothing if words don’t match

Finds relevant content even with different phrasing

Depends on manual tagging and titles

Works with the content itself

Requires users to guess the right keywords

Lets users ask naturally

How AI‑Based Semantic Search Matches User Queries with Fitness Articles

The approach fits content that can be described in text, and a fitness app is exactly that. Each item carries meaning: a question, an answer, a problem description, a recommendation, an example, an explanation.

There is a catch: a content library of only a dozen short entries makes semantic search pointless, because a user query needs something to compare against. Before the approach could be tested, the base was expanded to 160+ entries, with questions and answers about nutrition, weight loss, training, food choices, sugar cravings, and other common topics.

Variety matters as well. A base written in one dry, formal style keeps natural user queries falling through the cracks. Content for this kind of search should describe the topic from different angles: goals, pain points, habits, shopping scenarios, training context, casual language. Search accuracy follows how well the base covers real user phrasing.

The system doesn’t generate answers or replace articles. It helps users find what’s already there. Articles and user queries get converted into numerical representations of meaning called embeddings. The system then compares these representations and returns the closest matches.

How to Build Semantic Search Without a Separate ML Service

The project already used MySQL 8. It’s a solid, stable foundation, but it doesn’t have native vector search support. And semantic search relies on vectors. In this approach, text gets turned into arrays of numbers, and the system compares how close those arrays are.

In theory the team could have attempted a full rebuild: migrate the database, move data to a different DBMS, connect a separate vector database, and build a new sync layer. For this task, that path seemed too heavy for a couple of reasons:

• The main database was already working and doing its job;

• A database migration for one new feature always carries risks: compatibility issues, testing overhead, potential regressions;

• The feature still had to prove itself. If users ignored the smart search, complex infrastructure would have been premature.

So the team left the stable core alone and added intent-based search as a separate layer. The architecture stayed fairly straightforward.

A Server-Side Search Layer with In-Memory Comparison

The original content stays in the main knowledge base. For each entry (question, answer, or text block), the system generates a vector representation. The vector gets stored alongside the record in MySQL as JSON. Not an ideal vector database, but for a pilot it works and is easy to understand.

On the server side, an indexer runs periodically. It scans the database, finds new or changed records, recalculates their vectors, and updates the in‑memory search index. Indexing is configurable and can be triggered, for example, when new content is added or on a schedule.

When a user enters a query, the server doesn’t scan the entire database each time. The query gets converted into a vector using the same model that indexed the content. Then that vector gets compared to the article vectors already loaded in memory. The user gets back the closest matches.

For vectorization, a model from the Xenova Transformers family was used, available in a JavaScript environment. This was convenient since there was no need to spin up a separate Python service or ML infrastructure just for a prototype. For more context on why JavaScript was chosen over a separate Python service, here’s the team’s comparison of Node.js vs Python.

Each text block was converted into a vector with 384 dimensions. In simple terms, a vector is a numerical fingerprint of meaning. Two phrases with similar meanings have vectors that are closer together than phrases about different topics.

For example, "I constantly want sweets" should land closer to articles about sugar cravings, eating habits, and snack options than to articles about choosing dumbbells or squat technique. The exact word "sweets" doesn’t have to be the only anchor. The system looks broader: at context, meaning, and related topics.

On a server with 4 cores and 16 GB of RAM, this approach proved realistic. In the prototype, the model and index took roughly 500‑600 MB of memory. For a single search feature, that’s noticeable but not critical, especially compared to the cost of separate infrastructure.

What Made Semantic Search Accuracy Difficult to Tune

Tuning took more than picking a model and turning it on. Those challenges showed up after implementation.

Short queries are ambiguous. Type "protein" and the user might mean high‑protein foods, protein powder recommendations, or an explanation of why protein matters for muscle recovery. The system has to guess from context, and with little context it’s a coin flip.

What gets vectorized matters. Embed the full article with its title, body, and metadata, and the vector might get pulled in different directions. Embed only the title, and you might miss content where the body helps more than the headline. Several approaches were tested; combining the question and a short answer summary worked best here.

Similarity scores aren’t everything. The closest match by cosine similarity can be the wrong outcome. A slightly less similar article sometimes helps more because it covers the user’s specific situation better. Ranking needs human judgment or at least some behavioral signals.

Embeddings need updating. When content changes, the vector must be regenerated. Skip that step and old vectors point to outdated content. A simple versioning system was built to track when each article was last embedded.

In‑memory search has limits. As content grows, memory usage grows with it. At some point you either scale the server or move to a dedicated vector database.

Why a Lightweight Semantic Search Setup Was Enough for the First Version

A dedicated vector database has advantages: it handles large volumes, complex indexes, high load, and distributed architecture better. It also has costs: a new service, configuration, monitoring, backups, data sync, DevOps support, additional points of failure.

So the compact path came first. It let the team show working mechanics, test result quality on real scenarios, and see how much content the feature needs to make sense. That build-what-you-need approach carries over to custom AI software development, where the aim is to deliver value without over-engineering.

Once the base grows to tens of thousands of entries, search becomes a primary scenario with 10-20+ queries per second, multiple server instances, and uptime requirements, and it is time to move to a dedicated search layer. That could be a specialized vector database or a separate service that stores a copy of the content, builds the index, and handles only semantic search results.

Business Value: Making Existing Fitness Content Easier to Find

For the product, an AI component by itself proves nothing. Technology is rarely an argument. The interesting part is what changes for the user and the business.

• The knowledge base starts working better. Data buried deep in a section appears more often in search results and starts delivering value.

• Users get answers faster and are less frustrated by empty search results. It matters most in apps where motivation is fragile: today the user is ready to figure out nutrition, tomorrow they have given up.

• Support load decreases. Coaches, trainers, or consultants focus on cases that actually need individual attention, while repetitive questions are handled through a well-organized information repository.

• The product gains a foundation for future features. Personalized recommendations, smart navigation across educational materials, search over video transcripts, suggestions in the meal tracker or workout log.

The solution is a layer that increases the value of accumulated content and opens the door to a more personalized user experience. In apps dealing with health-related content, healthcare software solutions can be tailored to incorporate this kind of intelligent retrieval without disrupting the existing user flow.

Final Takeaways: Adding In‑App Semantic Search Without Changing the Core Architecture

The described approach works well for products that want to test intelligent search on real content quickly but aren’t ready to implement a separate vector infrastructure yet. The entry point is clear: start with stored content, evaluate result quality, collect feedback, and only then decide about scaling.

Smart search doesn’t have to start with a big migration. Sometimes the better move is to leave the stable system alone and add a careful layer on top that solves a specific user problem.

Technical writer and content creator. Passionate about delivering reader-friendly tech-related content. Love Linux, FOSS, and horror movies.