retrieval

Every Ditto user already has a knowledge graph. As you talk, Ditto extracts subjects (typed topics, people, projects, preferences) and links each one to the memories it touches. (That’s the dreaming pipeline at work.) We’d already seen that matching a query to subjects, rather than only to raw memories, was a powerful signal. v4 leans on it directly.

Storing memories is easy. Finding the right one from a vague question is the hard research problem. When you ask Ditto something indirect, like “what did I decide about that thing a while back?”, there’s no keyword to match on, just a fuzzy query against a haystack of everything you’ve ever told it.

Modern retrieval agents expose many configuration choices—LLM, retriever, number of documents, number of hops, and synthesis strategy—each shaping both
answer quality and serving cost. Today, these pipelines are typically hand-tuned
once per workload, leaving substantial per-query optimization untapped. We formulate Query2Conf : given a natural-language query and either an accuracy or
a budget target, select from a predefined pipeline catalog the configuration that
minimizes cost (or maximizes accuracy) at inference time. We propose BRANE
which uses an LLM to convert each query into workload-specific characteristics,
then trains a lightweight per-configuration predictor that estimates whether the
pipeline will answer the query correctly. At inference time, BRANE selects the
configuration that maximizes predicted correctness penalized by cost, exposing a
tunable cost–quality tradeoff without retraining. Across MuSiQue, BrowseCompPlus, and FinanceBench, BRANE consistently pushes the cost–quality Pareto
frontier, matches the best fixed configuration’s accuracy at up to 89% lower cost,
and outperforms LLM-routing, rule-based, and fine-tuned Qwen3-4B baselines.
These results show that per-query configuration of the full retrieval pipeline is a
practical alternative to static workload-level tuning.