Skip to main content
This page defines the format of the data you send to Seer when you call the logging API.

Context Format

Seer supports 2 forms for context:
  • String array: list[str], simple passage texts
  • Object array: list[dict], passage objects with metadata
When using object items, include at least the text field. Optional fields enable richer analytics.

Passage Object Fields

Examples

Simple strings:
Passage objects:

Limits & Guidelines

We’re working on supporting larger context sizes with internal chunking and multi-evaluator calls. For now, keep individual passages under 4,000 characters.
  • If you have retrieval scores, include them. They enable nDCG and ranking metrics.
  • Use stable id values if you want to track passages across runs or use ground truth (to measure Seer’s accuracy).

Event Schema (API)

An event describes a single retrieval to be evaluated.

Top-Level Fields

Python SDK

When running inside an OpenTelemetry span, the SDK automatically captures trace_id, span_id, parent_span_id, and span_name.To enable auto-detection, install with: pip install seer-sdk[otel]If you already have opentelemetry-api installed in your environment, auto-detection works automatically.

HTTP API

Response


Metadata

The metadata field is a free-form dict for filtering and segmentation. All fields are optional. Usage:
Avoid:
  • Extremely large nested objects
  • High-cardinality fields with millions of unique values
  • Sensitive PII that shouldn’t be logged

Sampling

The sample_rate field controls what percentage of events get evaluated by Seer.

Defaults

  • Default sample rate: 10% (0.1)
  • Override per-request: Pass sample_rate=0.5 for 50%, sample_rate=1.0 for 100%

Single Records vs Multi-Span Traces

For single retrievals (one log() call per query), each event is sampled independently based on sample_rate. For multi-step workflows (agentic RAG, query decomposition, parallel retrieval), the SDK auto-detects OTEL trace IDs and uses trace-level sampling:
  • The first span in a trace determines whether the entire trace is sampled
  • All subsequent spans with the same trace_id get the same sampling decision
  • This ensures you never see partial traces in your dashboard
For advanced multi-step patterns, see the Multi-Hop Retrieval Guide.

Multi-Hop & Agentic Retrieval

For multi-step retrieval (decomposed queries, agent loops), use these fields:

is_final_context

Mark the retrieval step whose context is the final evidence passed to the LLM or agent for answer synthesis:
When is_final_context=True:
  • Trace-level metrics (Recall, F1) are derived from this span
  • The span is highlighted in the Seer UI as the “final evidence”
  • If no span is marked, Seer uses the last span by timestamp

subquery

For decomposed queries, include the subquery that this specific retrieval hop is answering:
When subquery is provided, Seer evaluates context against both:
  • The original task: is this hop contributing to the end goal?
  • The subquery: did this hop answer its specific question?
Learn more: Multi-Hop Retrieval Guide

Ground Truth (Testing Seer’s Accuracy)

For accuracy testing, you can include labeled data to validate Seer’s evaluator performance:

What Seer Computes with Ground Truth

When you provide ground_truth, Seer computes two separate sets of metrics:
If Seer doesn’t perform well on your domain, contact us. We can create specialized evaluator models tuned for your content type.
Learn more → Accuracy Testing Guide

OpenTelemetry Fields

For distributed tracing integration: The SDK auto-detects these from the current OTEL context when use_otel_trace=True (default). Manual override:

See Also