We bring you Power Search. Find information on Cableizer using keywords and semantic search enhanced with an AI Chat and structured output including mathematical formulas and tables.
Posted 2026-07-07
Categories:
New feature
, Tips and tricks
, User guides
Finding the right piece of information inside Cableizer used to mean knowing exactly where to look. With over 1 400 documented parameters, a growing library of blog posts, and a decade of engineering methodology behind the platform, the knowledge was there — but it was spread across definitions, formulas, and articles. The new Power Search brings all of it together under a single input field, and gives you three complementary ways to query it: a precise keyword engine, a meaning-based semantic engine, and a conversational AI Chat that can reason over the results.
This post is a technical walkthrough of how each mode works, what happens under the hood, and when to reach for which.
The search box is deliberately minimal: a full-width input, a Keyword ⇄ Semantic toggle, and a single result list. The toggle switches the entire retrieval strategy — not just the ranking, but which models are loaded and how the query is parsed. Both engines search the same unified index, which currently holds nearly 1 500 entries: a total of 1 364 parameter definitions extracted directly from our documentation, plus more than 120 blog posts.
Every result is tagged by type and by engine — you'll see badges such as Blog Post, Parameter Definition, or, in semantic mode, Blog Post (semantic) and Parameter Definition (semantic) — so it's always clear where a hit came from and how it was matched.
Keyword search is for engineers who know exactly what they're looking for. It is a pure lexical engine — no embedding model is ever loaded in this mode — which keeps it fast and completely deterministic. The same query always returns the same ranked results.
What makes it a power search rather than a plain text filter is a full query grammar built on a proper boolean parser:
| Operator | Syntax | Meaning |
|---|---|---|
| AND | induced AND voltage | Both terms must be present |
| OR | sheath OR shield | Either term qualifies |
| NOT | NOT armour | Exclude matches |
| Required | +voltage | Term must appear |
| Exclude | -armour | Term must not appear |
| Group | (a OR b) AND c | Control precedence explicitly |
| Phrase | "text string" | Match an exact sequence |
| Units | Ohm.m degC mm2 uT | Unit-aware tokens |
The parser builds an abstract syntax tree, so operator precedence and grouping behave
the way you'd expect from a real query language — presence (+) and
exclusion (-) signals are evaluated independently and never collide.
As the screenshot shows, induced AND voltage returns 13 results — blog
posts describing the IND and WRK postprocessing plots
alongside the parameter definition for induced shield voltage (U_k,
unit V/m), complete with its rendered formula. The index now also flattens parameter
choice tables (choices / th_choice)
into the searchable body text, so option values buried inside a parameter's
configuration are reachable by keyword too.
Semantic search is for when you know what you mean but not the exact term the documentation uses. Instead of matching tokens, it encodes your query into a vector with a sentence-transformer model and ranks every entry by cosine similarity — so "resistance of buried cable insulation" finds the right parameter even if it's documented under different wording.
This mode lets you ask questions in plain language. A query like "induced voltage when working on a cable system" returns 21 semantically ranked results, badged HF Semantic, drawing on the same underlying content but ordered by conceptual relevance rather than literal overlap.
Because it operates on meaning, semantic search will surface conceptually adjacent material that a strict keyword query would miss entirely. The two engines are intentionally kept separate: keyword mode never pays the cost of loading an embedding model, so it stays instant, while semantic mode brings the heavier machinery to bear only when you ask for it.
Both search modes share two features that matter for technical documentation.
Cableizer's parameters aren't just names and units — many carry their governing equations. These are rendered as true typeset mathematics directly in the results, not as plain-text ASCII, with subscripts, fractions, radicals, and logarithms all properly formatted, exactly as they would appear in a reference paper.
Many parameters reference sizeable lookup tables — country-specific voltage levels, standardized choices, and similar reference data. Rather than flooding a result with hundreds of rows, these are rendered as expandable tables, collapsed by default. You get a clean, scannable result list, and drill into the full data only for the entries you care about.
The third mode is where the search becomes conversational. Every result page carries a Search / AI Chat tab pair. Switch to AI Chat, and instead of just listing hits, the system feeds the retrieved entries to a locally hosted large language model as context — a Retrieval-Augmented Generation (RAG) pipeline — and lets you ask questions about them in natural language.
The model runs entirely on our own infrastructure — Mistral via a local Ollama runtime, with no data leaving Cableizer's server. Retrieval reuses the same unified index, and results are deduplicated (by parameter key or URL) before being handed to the model, so it reasons over distinct, non-redundant context rather than repeated snippets.
Crucially, the AI Chat is multi-turn. In the example above, the first question — "induced voltage when working on a cable system" — returns a grounded answer pointing to the IND postprocessing plot and explaining the limits of what's directly documented. The follow-up — "how can I calculate the induced voltage on a conductor considering the influence of all other systems" — builds on that context, and the model derives a superposition approach, then supplies the underlying IEEE 575-2014 and Energies 2022 shield-voltage equations, fully typeset, and explains each symbol. The same KaTeX rendering used in the search results is applied to the model's answers, so formulas the LLM produces are displayed as proper mathematics rather than raw markup — even when injected dynamically into the conversation.
Because the answers are grounded in Cableizer's own parameter definitions and blog content, the AI Chat stays on-topic and traceable: it explains our methodology, references our documented equations, and points you back to the source material when a specific case isn't covered.
| Mode | Best for | Under the hood |
|---|---|---|
| Keyword | Exact terms, boolean logic, precise filtering | Lexical parser, AST evaluation, no ML model |
| Semantic | Plain-language questions, conceptual matches | Sentence-transformer embeddings, cosine ranking |
| AI Chat | Explanations, derivations, follow-up questions | RAG over the index + local Mistral (Ollama) |
Power Search is built to grow with the platform. As new parameters and blog posts are added, the index rebuilds to include them automatically — all three modes benefit immediately. We're continuing to refine retrieval quality and the AI Chat's grounding, and welcome your feedback on how it performs for your own queries.
We'd love to hear how Power Search works for you — which mode you reach for, what you search for most, and where the results could be better. If you encounter any issues or have suggestions, please reach out to our support team.
