01
Define the test set
List representative questions, expected evidence, and the source documents that should support each answer. Keep private documents out of the public page.
← Read the publishing guide
SaveKit use case
Publish a RAG Evaluation Checklist as a Shareable Page
RAG systems are easier to discuss when the evaluation criteria are visible. A simple static page can document the retrieval question, expected evidence, answer quality, and known failure modes without requiring a documentation platform.
A good fit for: AI engineering teams, internal evaluation plans, retrieval demos, technical workshops, and model quality reviews.
02
Separate observations from conclusions
Record retrieval coverage, citation quality, latency, and failure examples. Avoid claiming that a small sample proves production reliability.
03
Share the review version
Publish the checklist as HTML or a ZIP build, then ask reviewers to comment on missing cases, unclear pass criteria, and what should be measured next.
Before you publish
A quick static-site checklist
These checks prevent the most common surprises after a folder becomes a public URL.
- Test cases contain no confidential source text
- Pass criteria are explicit
- Retrieval and generation errors are separated
- Limitations and sample size are visible
Common questions
What to know before using a static host
Can the page run a live RAG query?
SaveKit is a static host. Use it for the evaluation plan, result summary, or safe interactive mockup; keep live retrieval behind a secured service.
What should a RAG checklist include?
Include representative questions, expected evidence, retrieval quality, groundedness, citation correctness, latency, and a place to record failure cases.
Should I publish benchmark numbers?
Only publish numbers you can reproduce and explain. Include the dataset scope, evaluation method, date, and caveats.
Have a page ready to share?
Upload the HTML or ZIP build, preview it, and get a link you can send to the next person who needs to see it.
Start publishing