Skip to content
Back to Blog
· 4 min read

Why IoT App Discovery Needs More Than Vector Search

AIIoTSearch

Vector search is excellent when users describe what they mean in natural language. It is not always enough when the domain has strict terminology, overlapping categories, and metadata that needs to stay explainable.

That is what I ran into while building HEDGE ExpertAI, an AI discovery assistant for the HEDGE-IoT App Store.

The Search Problem

An IoT catalog can include energy monitoring, smart buildings, patient health, agriculture, water systems, manufacturing, environmental sensing, and smart city applications.

A query like "I need an app for monitoring energy consumption" is clear to a human, but the ranking system still needs to match it against titles, descriptions, tags, ontology classes, and app metadata.

Pure keyword search is too brittle. Pure vector search can be too fuzzy.

The Hybrid Approach

The HEDGE ranking layer combines three signals:

  • Vector similarity for semantic intent.
  • BM25-style keyword scoring for exact domain terms.
  • SAREF ontology boosts for IoT classes like Energy, Building, Environment, Water, Agriculture, City, Health, and Manufacturing.

This makes the system more grounded. It can understand the user's intent while still respecting the structure of the catalog.

Explanations Need Ranking Discipline

The recommendation layer uses an LLM to explain why certain apps are relevant. But LLM explanations can drift. If the model says "start with App B" while the ranking system returned App A first, trust drops immediately.

So the explanation layer checks for ranking consistency and falls back to deterministic text when needed.

The Takeaway

For domain search, I rarely want a single clever model call. I want a retrieval system with multiple signals, measured evaluation, and explanations grounded in actual metadata.

That is how search becomes product infrastructure instead of a demo.