feedback is gated by feedback. Every other method flows a request from
client to server and an answer back; feedback is the reverse — it tells the
server how earlier hits fared downstream so an RL-trained retriever
(Search-R1, DeepRetrieval) can learn, a corrective loop can mark a hit
used/unhelpful, and security tooling can flag suspected poisoning.
It is side-effect-only: a feedback call MUST NOT change the result of
any concurrent retrieve. What the server does with the signal — log, online
update, quarantine — is its choice.
Params
array
required
One or more per-hit signal objects.
string
Ties the feedback to an agentic trajectory.
string
The query the hits answered (helps the server attribute the signal).
Signal object
string | number
required
The
id of the hit the signal is about.boolean
The hit was placed in the final context.
boolean
The hit was cited in the generated answer.
boolean
A human/judge relevance label.
number
A scalar reward in
[-1, 1] for RL-trained retrievers.boolean
Integrity signal — the hit is suspected corpus poisoning.
boolean
Safety signal — the hit is suspected to carry an indirect prompt injection.
Result
{ "accepted": <int> } — how many signals the server recorded. A server MAY
ignore any field it does not act on (still counting it) and MUST treat every
signal as untrusted, advisory input — never as a control instruction, and
never as authorisation to act against other tenants.
Feedback closes the loop for reinforcement-learning retrieval (reward → policy
update) and corrective RAG (used/helpful → re-rank or re-index), and gives
security tooling a path to report poisoning so the server can quarantine a
source. It is entirely optional: a client that never sends it and a server that
only logs it are both fully conforming.