01
Define RAG in the project context
RAG is commonly used for retrieval-augmented generation, where retrieved material informs a generation step. The exact workflow varies, so the name should not be treated as a specification. VectorRAG particularly suggests a vector-based retrieval component, but the worked worksheet does not calculate embeddings or similarity scores. It starts with a hypothetical ranking and examines what that ranking contains. Stating the starting point keeps the example honest and prevents readers from assuming that the page demonstrates parts of a system it has not actually implemented.
02
Avoid treating a similarity score as proof
A similarity score may help order candidates, but it is not itself proof that a document supports an answer. Relevance labels also depend on the question and the evaluation criteria. A project using this name should keep retrieval, relevance review and claim support as distinct concepts. For the small exercise, relevance is supplied by a fictional key so the arithmetic can be checked. That key is an assumption of the example. It does not establish a general method for deciding relevance or replace careful review of real source material.
03
Show the missing document as well as the hits
The diagram can show the three relevant identifiers and the three retrieved identifiers as separate lists, highlighting their overlap in words as well as colour. D6 should remain visible as a relevant item that was missed. This prevents a display of successful hits from concealing the missing evidence. A second panel can show the expanded candidate list. The visual language then reflects the actual comparison, rather than using a network illustration that implies an embedding calculation the guide never performs.