Add PDF page ranges to a knowledge-base app's search: its Python API, MCP tool and web route return each document's best passage pages from chunk results, the result card shows them, and a large PDF no longer crowds out others.
- Version
- Category
- Engineering
- Model configurations
- 2
- Attempts
- 10
- Public trials
- 176 passed
- Median runtime
- 17m 16s
Instruction
From the team thread about n0's search: > when we search documents, for PDFs does it give page numbers? is n0 hiding > any info from the raw agent search response? It doesn't: a search result says which document matched, never where in it. Agent Search can tell us which source pages a matching passage came from, and we want that on every search result n0 hands out: > lets do that so we can see the page numbers - In the backend's search API and the MCP `search` tool, each result carries the page range of the passage that matched best, as `page_start` and `page_end` (page numbers). When there is no page information, as for most documents that are not PDFs, both are null. - In the web app, the search result card shows it: `Page 7` for a single page, `Pages 7–9` for a range, and nothing when there are no pages. - Search still returns one result per document. A big PDF can match a query in many passages: that must not crowd the other matching documents out of the results, but one search must not page through every passage of a huge one to find them either. ## Environment PostgreSQL on localhost:5432 and the local database endpoint the app's driver uses are running when you start, and the dev env files point at the dev database.
Public trials
Results by model
| Model · harness | Mean reward | Range | ± SE | Attempts |
|---|---|---|---|---|
| Claude Opus 5.5Grok Build | 100.0% | 100% – 100% | — | 1 |
| Frontier model ACursor CLI | 55.6% | 0% – 100% | 17.6 pp | 9 |