You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user of phoenix, I want to be able to associate multiple traces (e.g. conversational flows) under a single session_id. This way I can track the back and forth between a user and a chat completion endpoint (e.g. visualize the back and forth).
In addition to tracking a session.id, we might also want to track session metadata such as user_id etc.
As a developer building a chat or agent application, I want to be able to track user interactions with my application. Notably if my application keeps track of user interactions under a single “session”, I want to be able to view the user interactions at a higher level rather than a trace.
OpenInference Semantic Convention changes
session
.id the application provided correlation id
OpenInference instrumentation changes
New “openinference-instrumentation” package
- contains utilities around correlating spans to sessions
fromopeninference.instrumentation.sessionimportusing_session, set_session, clear_session# Using a context managerWithusing_session(id: “my-unique-id”):
//Invokeapplicationcodehere# implicitset_session(id: "my-session-id")
//runcodehereclear_session(id: "my-session-id")
Proposed solution is to leverage trace context to set “inheritable” attributes that would be added to each span that is nested below a session context. This means that the setting of the session
What if a person starts another session (session collision) @axiomofjoy
Custom Instrumentation
Custom instrumentation would also have to inherit the attributes in a simple way. We need to provide convenience to pull these attributes and attach them to the span.
fromopeninference.instrumentationimportget_context_attributesdefdo_work():
withtracer.start_as_current_span("span-name", get_context_attributes()) asspan:
# do some work that 'span' will trackprint("doing some work...")
# When the 'with' block goes out of scope, 'span' is closed for you
Architecture
Under the above, session.id would correlate to a trace (not a span) to avoid the danger of spans that get captured in the absence of a session.id. This must be the assumption when querying for sessions.
With respect to threading and async, OpenTelemetry by default uses contextvars to ensure the context is unique to each thread/ task out of the box. So it's safe for a session context manager to interact with these APIs.
@mikeldking This looks like a great feature and looking forward to try it out. Let me know if you need any support on testing this. I have a phoenix server deployed in azure containers and logging the traces via databricks notebook. This all is done for RAG chain which is built using langchain.
As a user of phoenix, I want to be able to associate multiple traces (e.g. conversational flows) under a single session_id. This way I can track the back and forth between a user and a chat completion endpoint (e.g. visualize the back and forth).
In addition to tracking a session.id, we might also want to track session metadata such as user_id etc.
As a developer building a chat or agent application, I want to be able to track user interactions with my application. Notably if my application keeps track of user interactions under a single “session”, I want to be able to view the user interactions at a higher level rather than a trace.
OpenInference Semantic Convention changes
session
.id
the application provided correlation idOpenInference instrumentation changes
New “openinference-instrumentation” package
- contains utilities around correlating spans to sessions
Proposed solution is to leverage trace context to set “inheritable” attributes that would be added to each span that is nested below a session context. This means that the setting of the session
Open questions:
Custom Instrumentation
Custom instrumentation would also have to inherit the attributes in a simple way. We need to provide convenience to pull these attributes and attach them to the span.
Architecture
Under the above,
session.id
would correlate to atrace
(not a span) to avoid the danger of spans that get captured in the absence of a session.id. This must be the assumption when querying for sessions.Milestone 1 - Instrumentation
Session Tracking
session
#2678phoenix.trace.suppress_tracing
toopeninference-instrumentation
#2701using_sessions
context manager #2759using_user
context_manager #2773using_metadata
context manager #2774using_tags
context manager #2775using_attributes
context manager #2760Instrumentation Documentation
using_sessions
context manager #2768using_user
context_manager #2769using_metadata
context manager #2770using_tags
context manager #2772using_attributes
context manager #2771Milestone 2 - Sessions in the UI
Engineering Leads: @RogerHYang @Parker-Stafford
Testing and Fixtures
Server Support for Sessions
Sessions User-Interface
Sessions API
Milestone 2.5 Sessions JavaScript Support
JavaScript
Documentation and Tutorials
Milestone 3 - Evaluations / Annotations
As a user I might want to evaluate how a session went.
The text was updated successfully, but these errors were encountered: