feat(search): send fusion, granularity and min_relevance from the search page - #331
feat(search): send fusion, granularity and min_relevance from the search page#331cbcoutinho wants to merge 1 commit into
Conversation
…rch page
The app's Semantic Search page could reach almost none of the settings the MCP
server supports. An audit of both search paths found that of every parameter
the retrieval benchmark varies, this page could request exactly one (`limit`,
and only up to 50) — so measured improvements were not deliverable to users.
Three parameters were accepted by the server and never sent from here:
- `fusion` — the admin's rrf/dbsf choice reached only the Nextcloud global
search bar. It also selects which relevance curve the server applies, so
omitting it pinned the reported relevance to the RRF-ordinal mapping
regardless of configuration. Now sent, defaulting to the admin setting so
both surfaces finally agree.
- `granularity` — one row per document rather than per passage, the shape
"which files mention X" wants. Requires the matching server change; an older
server ignores the field rather than erroring.
- `min_relevance` — the server-side relevance cut, applied BEFORE the page is
trimmed to `limit`, so a filtered search still returns a full page.
The existing "Minimum relevance" slider is NOT that parameter: it filters
client-side over rows already returned, so raising it shortens the list rather
than reaching deeper. Both controls are now present, labelled distinctly, and
each says which it is — previously they were indistinguishable.
Also fixes a related swallowing bug: a 422 from the MCP server (a well-formed
request this deployment cannot serve — unsupported algorithm, document
granularity on a dense-only algorithm, reranking when unconfigured) was
collapsed into `RuntimeException("Unexpected HTTP 422")` and surfaced as an
opaque 500 that reads like an outage. The server's structured body now reaches
the client with a 422.
Verified end to end against a live login-flow stack: granularity=document
returns results, document+semantic returns the server's 422 payload, rrf vs
dbsf flips relevance_source between fusion_ordinal and uncalibrated (proving
the value reaches the server rather than being accepted and ignored), and
min_relevance=0.5 cuts a 5-row page to 1.
Deck #1070.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
Claude finished @cbcoutinho's task in 2m 33s —— View job Review complete
SummarySolid, well-documented parity fix — the Findings1. No test coverage added — this is the mandatory gate in this repo's own
This PR touches This isn't a case of missing infrastructure: If the intent is to treat this as covered by the "known gaps" list (provider-state endpoint not implemented), that should be stated explicitly in the PR description per CLAUDE.md's instructions — right now it's silent, which is the thing the gate is meant to prevent. 2. The rerank feature isn't mentioned anywhere in the PR description The diff adds a complete cross-encoder rerank feature end-to-end: a 3. Minor —
Nits
|
1 participant
The Semantic Search page could reach almost none of the settings the MCP server supports. An audit of both search paths — this page (
POST /api/v1/vector-viz/search) and the Nextcloud global search bar (POST /api/v1/search) — found that of every parameter a retrieval benchmark varies, this page could request exactly one:limit, and only up to 50.That makes measured retrieval improvements undeliverable to users, which is how it was found: a benchmark sweep produced clean results for settings nobody could actually request.
Three parameters accepted by the server and never sent
fusiongranularitymin_relevancelimit, so a filtered search still returns a full page.The two relevance controls were indistinguishable
The existing "Minimum relevance" slider is not
min_relevance. It filters client-side over rows already returned, so raising it shortens the list rather than reaching deeper into the corpus. Both controls now exist, are labelled distinctly, and each carries a line saying which it is:Also: a 422 was surfacing as a 500
A 422 from the MCP server means a well-formed request this deployment cannot serve — unsupported search algorithm, document granularity on a dense-only algorithm, reranking when it is not configured. It was being collapsed into
RuntimeException("Unexpected HTTP 422 from MCP server")and returned as an opaque 500, which reads to the user as an outage and discards a structured, actionable body. The server's own error now reaches the client with a 422.Same class of bug as the parity gaps themselves: a meaningful signal discarded in transit.
Verification
End to end against a live login-flow stack with 60 indexed Deck cards:
granularity=documentgranularity=document+algorithm=semanticgranularity_unsupported_for_algorithmand the server's payloadfusion=rrfvsdbsfrelevance_sourceflipsfusion_ordinal→uncalibratedmin_relevance=0.5The fusion check is the one worth noting: result ordering was identical on this corpus, but the relevance curve changed — so asserting that the parameter arrives rather than that results change is what proves it is wired.
Compatibility
fusionandmin_relevancewere already accepted by the server.granularityneeds the matching server change (nextcloud-mcp-server #1359); an older server ignores the unknown field rather than erroring, so there is no deployment-ordering requirement in either direction.Checks
npm run lint— 0 errors (one pre-existingvizPlotwarning, untouched).npm run stylelint— clean.composer cs:check— 0 of 102 files need fixing.php -lclean on both modified PHP files.Deck #1070.
This PR was generated with the help of AI, and reviewed by a Human