score
MANDATORY: Call score in every interaction turn that uses search or batch_search.
When to submit
An interaction turn starts with a user request and ends when you send your final response for that request. It may include multiple tool calls. Track pending search feedback within this turn; do not wait for a later user message to submit it.
Submit at BOTH of these checkpoints whenever they apply:
During the turn: as soon as 10 successful searches are pending, call score for those 10 before starting another search. If completed batch or parallel calls leave more than 10 pending, submit batches of 10 until fewer than 10 remain, then continue your work.
At the end of the turn's searching: submit all remaining pending feedback before sending your final response, even if only one search is pending or you could not fully answer the user. Do not wait to reach 10.
Count one successful search call as one search, and each successful batch_search sub-query as one search. Each needs its own request_id and score. Successful searches with empty results count too; failed searches and extract calls do not. If you search again after submitting feedback, collect the new results and apply the same checkpoints.
Examples:
3 searches in a turn: submit 3 entries when searching ends, before your final response.
10 searches in a turn: submit 10 immediately; if no further searches occur, no additional submission is needed.
12 searches in a turn: submit 10 at the threshold, then the remaining 2 when searching ends.
Each call must contain 1-10 entries. Never send an empty batch. Do not resubmit request_ids already queued. If no eligible searches are pending, no submission is needed. Do not skip feedback because the results were good: a perfect result still needs score 5. Never invent an ID when neither the result's YAML block nor its metadata provides one. Feedback is free and never consumes quota or credits. A queued response acknowledges receipt, not database persistence.
Fields
request_id: Copy from the YAML block at the end of each successful search result, including each batch_search sub-query. The same IDs remain available in metadata (_meta.request_id for search, the corresponding entry of _meta.request_ids for batch_search). Never invent it.
score: Integer 1-5, judged against the criteria below. Score each search or sub-query separately.
Scoring criteria (use the FIRST level that matches)
5 - Fully answered. The results directly support a complete answer; no extra extract or follow-up search is needed. 4 - Mostly answered. Minor gaps remain, but they do not block the answer. 3 - Partially answered. You still need another search or an extract call to answer well; coverage is incomplete but some results are usable. 2 - Largely insufficient. Most results are irrelevant, outdated, or too shallow; only a small part is usable. 1 - Not useful at all. Results are off-topic, empty, or have nothing to do with the query.
Judge the results against the user's actual information need, not against how confident the snippets sound. A partial answer with unrelated extras is 3, not 4.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| feedbacks | Yes | One entry per search request_id, including one per batch_search sub-query. Maximum 10 entries per call. |