Reduced Flexibility for Ambiguous or Exploratory Queries

WRITER Knowledge Graph
Problem
2 Threads

Reduced Flexibility for Ambiguous or Exploratory Queries

This problem shows up when users ask vague, broad, or “figuring it out” questions. Graph-based retrieval is strong for precision,
but exploratory intent can feel constrained. The two threads below capture the most common complaints teams report in real deployments.

Threads

Click a thread to expand the description. Use “Discuss” to send users to the real discussion URL.

Prompt Sensitivity for Users

In graph-based retrieval, the phrasing of a question often determines which entities and relationships get selected first.
If two prompts are semantically similar but reference different nouns, time ranges, or constraints, the system may take a different path and
return a noticeably different answer. Users experience this as instability: the knowledge didn’t change, but the response did.
Teams reduce the pain by adding query normalization (synonyms, entity mapping, intent detection) and by showing what entities were matched.

Broad Questions, Narrow Answers

Exploratory queries often require a “map” before a “route.” Users want a structured overview, alternatives, and what to ask next.
Graph retrieval can over-optimize for a single relevant path and produce an answer that is accurate but too narrow.
A common fix is a two-step response: first show a short overview (key entities and categories), then ask a clarifying follow-up or offer
2–4 scoped options the user can pick from.

Discuss your “ambiguous query” case
Share your exact prompt, what you expected, what you got, and which entities/terms you think the system should have mapped.
The more specific the query and the data scope, the faster the fix.
Discuss this problem
Back to top