Use case
Grounded question answering
Teams building assistants that answer factual questions from current sources.
The problem, and the approach
The problem
- Answering from a ranked list means the model does the selection, and the selection is where accuracy is decided.
- The model cannot tell that six of the ten results are the same story, so repetition reads as confirmation.
- When the answer has to be defended, "the model chose these sources" is not an account of anything.
The approach
- assemble_context does the selection with signals the model does not have: story clusters, corroboration counts across rejected duplicates, and graph centrality.
- Every returned item carries the reason it was included, which makes the answer explainable rather than merely sourced.
- A corroboration floor means single-sourced claims never reach the model at all.
The parameters that matter
| Parameter | Value | Why |
|---|---|---|
assemble_context?q= | the question | The whole retrieval loop in one call. |
budget | 3000–4000 | Enough context for a grounded answer without crowding the prompt. |
min_independent_sources | 2 | Single-sourced claims excluded before the model sees them. |
lang | user’s language | Pins output language when the user needs one. |
curl -H "x-api-key: $UNLOB_API_KEY" \
"https://api.unlob.com/assemble_context?q=what+changed+in+EU+AI+regulation+this+year&budget=3500"One call, and the reason it is one call
An assistant that answers factual questions runs the same four steps every time: retrieve candidates, remove duplicates, judge which sources to trust, and cut to a budget. Each step is easy to write and none of them is easy to keep good, because the tuning that makes them work is implicit and the regressions are invisible until someone reads a wrong answer.
Moving the loop behind one call does not make those decisions disappear — it makes them someone else's default, which is a trade rather than a win. It is the right trade when you would otherwise be maintaining a reranker you do not evaluate, and the wrong one when you have a domain-specific notion of authority that a general policy will not reproduce. The test is whether you can currently say what your pipeline drops and why.
Attach the reason, or the answer cannot be defended
The difference between an assistant that is trusted and one that is merely used is usually whether a user can find out why it said something. A packed context set where each passage carries the reason it was included makes that answerable at the level that matters — not a similarity score, which means nothing to a reader, but a statement that this passage was included because it was independently corroborated, or because it was the most central treatment of the subject.
It also changes what a wrong answer costs you. When the reasons are recorded, a bad output is a traceable retrieval decision rather than an unexplained model failure, and the fix is usually a parameter rather than a prompt. Check the publication dates on what came back before asserting anything is current: the index is not a real-time wire, and an assistant that says today when it means recently is making a claim it cannot support.
Where this is not the right tool
- Ranking policy is ours. If you have a domain-specific reranker, use the retrieval endpoints instead.
- For questions about very recent events, check published_at on the returned passages — the index is not a real-time news wire.
Frequently asked questions
What token budget should I use?
Three to four thousand covers most factual questions. Larger budgets add marginal passages that rarely change the answer and reliably cost tokens.
Can I see why each passage was chosen?
Yes — every item in the pack carries a reason string, such as corroborated by five independent hosts or highest centrality in its cluster. Log it alongside the answer.
Build it on the free tier
10,000 credits a month, no card. Every parameter above works on every plan.