Semantic Search

Search that matches meaning rather than spelling — across your knowledge base, your ticket history and a 700,000-product catalogue — with tenant boundaries enforced inside the query, not after it.

The problem

Keyword search fails exactly when it matters. The runbook says “VPN tunnel renegotiation”; the user types “can’t connect from home”. The resolved ticket says “certificate expired”; the new ticket says “browser says not secure”. The answer exists and the search returns nothing, so the work is done twice.

For a provider the failure compounds. The corpus that would answer the question spans several clients, and a search that reaches across that boundary is not a better search — it is a disclosure.

What Solidlio does about it

A query is embedded the same way, and matching is by proximity in that space — so “can’t connect from home” finds the VPN runbook without sharing a word with it. Tenant and visibility predicates are part of the search query itself, evaluated before the result limit, and the index is configured to keep scanning until it has genuinely found the best matches that satisfy those filters rather than stopping at the first candidates and returning a short list.


Capabilities

CapabilityWhat it does
Knowledge searchFinds articles by meaning, with a configurable relevance floor
Similar ticketsFinds resolved tickets that resemble the one in hand, with their resolutions
Duplicate detectionFlags likely duplicates as a ticket is written
Catalogue smart searchSemantic ranking over ~700,000 products, with facets applied on top
Help-centre searchThe same engine behind the customer-portal knowledge search
RAG groundingSupplies the assistant with cited source material per turn
Visibility-aware resultsArticle visibility rules are part of the SQL, not a post-filter

Built for MSPs and their clients

The visibility cascade that governs who may read an article is compiled into the search predicate. A customer searching the help centre and an MSP technician searching internally run the same engine against the same index and get different result sets, because the filter is evaluated per caller inside the query. Platform-wide articles are pinned to having no owning organization, so a tenant’s article cannot become globally readable by changing its visibility level alone.


How it works

  1. Content is embedded — knowledge articles on publish, tickets and catalogue products by a background sweep.
  2. A query arrives and is embedded with the same model and dimension.
  3. The scan iterates until the limit is satisfied against those filters, so a selective tenant filter returns a full page rather than a truncated one.
  4. Results above the relevance floor are returned with their similarity score.

Credit cost

OperationCredits
Retrieval-augmented query3

Knowledge indexing is charged when an article is published or re-indexed.


Limits

  • Documents are embedded whole rather than chunked, so a very long article is represented by a single vector and its tail contributes less to matching.
  • Tickets are embedded by a periodic sweep, not on creation, so a new or edited ticket becomes searchable on the next tick rather than immediately.
  • Catalogue products are embedded by an operator-run backfill; newly imported products are not embedded automatically.

See this working on a real account.

Book a walkthrough and we will run this capability against your own clients, devices and tickets.

Book a demo All features

A 30-minute walkthrough against your own workflow. No slides.