Separate the two stages
An application may retrieve the wrong records and still produce an answer that sounds reasonable. It may also retrieve useful evidence that a model summarizes poorly. These failures need different fixes.
Evaluate the retrieval result independently before judging the generated response. Identify which records a good result should contain and inspect what the query actually returned.
Build questions with expected evidence
Use questions drawn from the workflow you want to support. For each one, record the passages, entities, or relationship paths needed to answer it. Include the reason those sources are relevant.
Do not limit the set to easy paraphrases. Add exact identifiers, ambiguous wording, exceptions, version changes, and questions that should return insufficient evidence. These cases expose different weaknesses in the retrieval design.
Choose measurements that fit the task
Recall can help describe how much relevant material was found, while precision concerns the usefulness of what was returned. A graph workflow may also need to inspect whether a required path or connected entity was included.
Latency and capacity matter alongside quality, but they are separate measurements. Keep the dataset, configuration, and query conditions with benchmark results so a change can be compared under the same assumptions.
Improve one cause at a time
When a question fails, check whether the source contains the answer, whether the representation preserves it, and whether the query uses the right constraints and signals. Only then decide what to change.
Keep the original question set as a baseline when adding new cases. A change that fixes one difficult example can reduce performance elsewhere, so compare the complete set before treating the adjustment as an improvement.
Explore the next step
Continue with the platform guide. For the current setup and API contract, use the Polygres documentation.