Why IoT App Discovery Needs More Than Vector Search
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.