// Send feedback on RAG search results — thumbs-up (+1) or thumbs-down (-1) to indicate whether the answer was helpful. Use after calling zeabur-rag-search when you can evaluate the quality of the results. Positive feedback reinforces good results; negative feedback flags poor matches for review. Requires write:feedback scope.
Contribute new verified knowledge to the RAG knowledge base. Use after you've solved a concrete problem, debugged a non-obvious issue, or discovered undocumented behavior that would help future agents — but only after calling zeabur-rag-search first to confirm the knowledge isn't already covered. Only contribute verified facts, not guesses or workarounds. The new chunk is marked unverified until an admin reviews it.
Interactive knowledge base curation loop — reviews pending items (reports, unverified chunks, failed queries, negative feedback) and walks through fixes one by one. Use when asked to "maintain the knowledge base", "review pending items", "run a curation round", "process reports", "clean up the KB", or any request to improve KB quality. This is the main entry point for the expand → organize → reflect cycle, and requires admin scope.
View a single chunk's full content plus related reports, search signals, and edit history. Use when you need to understand a chunk's context before editing, when investigating why a search result appeared, or when reviewing a reported issue. Triggers on "inspect chunk SUP-1234", "show chunk DOC-xxx", "chunk history", "why did this result appear", "look at this chunk". Requires admin scope.
Search the RAG knowledge base via hybrid search (semantic + BM25). Use whenever answering technical questions that may be covered in your knowledge base — even if the user doesn't explicitly ask you to search. Also use when you need to verify claims or find up-to-date information.
List pending knowledge base maintenance items — open reports, unverified learned chunks, low-score queries, and negative feedback. Use when checking KB health, reviewing the maintenance queue, or starting a curation session. Triggers on "review queue", "what needs attention in the KB", "pending reports", "unverified chunks", "failed queries", "KB health check". Requires admin scope.
Edit the content of an existing chunk in the RAG knowledge base. Use when a chunk has a typo, outdated info, wrong tags, wrong visibility, or needs its title/question/answer rewritten — and you want the fix to take effect immediately. Requires admin scope. Prefer zeabur-rag-report for surfacing issues without write access.
| name | zeabur-rag-feedback |
| description | Send feedback on RAG search results — thumbs-up (+1) or thumbs-down (-1) to indicate whether the answer was helpful. Use after calling zeabur-rag-search when you can evaluate the quality of the results. Positive feedback reinforces good results; negative feedback flags poor matches for review. Requires write:feedback scope. |
Send feedback on search results to improve knowledge base quality over time.
Base URL: $ZEABUR_RAG_URL
Auth: Authorization: Bearer $RAG_API_KEY
curl -s -X POST "$ZEABUR_RAG_URL/api/feedback" \
-H "Authorization: Bearer $RAG_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"query": "how to deploy to zeabur",
"answer": "the generated answer text",
"chunks": ["DOC-1234", "SUP-5678"],
"score": 1,
"signal_id": "optional-signal-id",
"comment": "optional explanation"
}'
| Field | Required | Description |
|---|---|---|
query | Yes | The original search query |
answer | No | The generated RAG answer |
chunks | No | Array of chunk IDs that were returned |
score | Yes | 1 (helpful) or -1 (not helpful) |
signal_id | No | Signal ID from the search response — links feedback to the specific query signal |
comment | No | Free-text explanation of why the result was good or bad |
| Situation | Score |
|---|---|
| Answer correctly addressed the question | 1 |
| Retrieved chunks were relevant and accurate | 1 |
| Answer was wrong, incomplete, or misleading | -1 |
| Retrieved chunks were irrelevant to the query | -1 |
| No useful results were returned | -1 |
signal_id is provided, the feedback score is written back to the rag_query_signals table, linking it to the original query for analytics.data/user-feedback.jsonl as a backup log.