Observations
Observations are the building blocks inside a trace. While a trace captures the complete end-to-end operation, observations record what happened at each individual step: model calls, tool invocations, retrieval operations, and any other discrete action in your workflow.
Observations can be nested, forming hierarchies that reflect the structure of your application's pipeline. Each observation contains a start time and its latency, a name and type, attributes (key-value metadata), and parent-child relationships for hierarchical traces.
You can navigate to https://app.interactive.ai/project/<your_project_id>/observations to see all observations in your project.
For the full Tracing API reference including all method signatures, parameters, and advanced options, see the SDK Documentation.
Why Observations Matter
Observations give you granular visibility into each step of your LLM pipeline. With observations, you can:
Measure latency and cost at each step, not just end-to-end
Identify which specific operation caused a failure or unexpected result
Compare performance across different model versions or configurations
Build datasets from specific observations for targeted evaluation
Observation Types
InteractiveAI supports several observation types, each designed for specific kinds of operations:
Span
A unit of work with a start and end time; use for any operation you want to measure
Generation
An LLM call; captures prompts, completions, model details, token usage, and costs
Tool
A tool or function invocation; records the tool name, inputs, and outputs
Event
A discrete occurrence without duration; use for logging specific moments
. Agent
An orchestration step where an LLM decides what action to take
Chain
A sequence of operations linked together
Retriever
A data retrieval operation (e.g., querying a vector database)
Embedding
A vector embedding generation; captures model, token usage, and costs
Evaluator
An evaluation function execution
Guardrail
A safety check against malicious input or unsafe content
generation and embedding are special types that accept additional parameters: model, model_parameters, usage_details, cost_details, completion_start_time, and prompt. All other types share the same base parameters.
Creating Observations
Observations are always created within the context of a trace. When nested inside an existing trace, they automatically become children of the current span.
@observe examples on this page assume from interactiveai import observe has been imported.
For complex pipelines, observations can be nested multiple levels deep:
When decorated functions call other decorated functions, nesting happens automatically:
This produces the same nested hierarchy as the context manager version, without manual nesting.
Updating Observations
After creating an observation, you can update it with additional data that becomes available during execution.
Use update() on the observation object:
For generation and embedding observations, update() also accepts model-specific parameters:
Inside a decorated function, use update_current_span() to add data to the current observation:
For generation and embedding observations, use update_current_generation() which accepts model-specific parameters:
Properties of an Observation
Name
The name of the observation (e.g., "llm-generation", "vector-search")
Start Time
Timestamp when the observation began
End Time
Timestamp when the observation completed
Input
JSON payload capturing the request or input data
Output
JSON payload capturing the response or output data
Level
Importance level to control verbosity: DEBUG, DEFAULT, WARNING, ERROR
Status Message
Additional information, such as error details when level is ERROR
Latency
Duration of the observation from start to end
Model
The model used (for generations and embeddings)
Model Cost
Cost of the operation (for generations and embeddings)
Time to First Token
Time elapsed before the first token was received
Tokens
Token count (input + output) for the observation
Prompt
Link to prompt version in InteractiveAI prompt management
Environment
Deployment context like production, staging, or development
Trace Tags
Tags inherited from the parent trace
Metadata
Free-form JSON for extra context specific to this observation
Observation ID
Unique identifier (16-character lowercase hexadecimal string)
Trace Name
Name of the parent trace containing this observation
Trace ID
Unique identifier of the parent trace
Observation Type Examples
Span
A generic unit of work. Use when no specialized type fits your operation:
Agent, Chain, and Evaluator work identically to Span but are visually differentiated in the InteractiveAI UI for filtering and organization. Use as_type="agent", as_type="chain", or as_type="evaluator" respectively.
Generation
Captures model, token usage, and costs:
Tool
Use for function or tool invocations:
Retriever
Use for vector database queries or document retrieval:
Embedding
Use for embedding generation. Like generation, this type captures model, token usage, and costs:
Event
A discrete, zero-duration occurrence. Use for logging specific moments like user feedback, system events, or state changes. Events use the dedicated create_event() method — they cannot be created with @observe or start_as_current_observation because they have no duration to wrap around.
create_event() accepts the same base parameters as other observation types (name, input, output, metadata, version, level, status_message) but creates an observation that starts and ends at the same instant.
Guardrail
Use for safety checks:
Last updated
Was this helpful?

