Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
127 changes: 115 additions & 12 deletions rfcs/text/0052-gen_ai-additional-fields.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,18 +31,14 @@ Stage 1: Describe at a high level how this change affects fields. Include new or

Field | Type | Description /Usage
-- | -- | --
gen_ai.system.message.content | text/TBD | The contents of the system message.
gen_ai.system.message.role | text | The actual role of the message author as passed in the message.
gen_ai.user.message.content | text | The contents of the user message.
gen_ai.user.message.role | text | The actual role of the message author as passed in the message.
gen_ai.assistant.message.content | text | The contents of the tool message.
gen_ai.assistant.message.role | text | The actual role of the message author as passed in the message.
gen_ai.assistant.message.tool_calls[] | text | The tool calls generated by the model, such as function calls.
gen_ai.assistant.message.function[] | [TBD] | The function call.
gen_ai.assistant.message.arguments | [TBD] | The arguments of the function as provided in the LLM response.
gen_ai.assistant.message.name | text | The name of the function.
gen_ai.assistant.message.id | text | The id of the tool call.
gen_ai.assistant.message.type | [TBD] | The type of the tool.
gen_ai.system_instructions | (Looking for feedback) flattened | The system message or instructions provided to the GenAI model separately from the chat history.
gen_ai.input.messages | (Looking for feedback) flattened | The chat history provided to the model as an input.
gen_ai.output.messages | (Looking for feedback) flattened | Messages returned by the model where each message represents a specific model response (choice, candidate).
gen_ai.tool.definitions | (Looking for feedback) nested | (Part of invoke_agent span) The list of source system tool definitions available to the GenAI agent or model.
gen_ai.tool.call.arguments | (Looking for feedback) nested | (Part of OTel execute_tool span) Parameters passed to the tool call.
gen_ai.tool.call.result | (Looking for feedback) nested | (Part of OTel execute_tool span) The result returned by the tool call (if any and if execution was successful).

Changes based on OTel https://github.com/open-telemetry/semantic-conventions/pull/2179/files

<!--
Stage 2: Add or update all remaining field definitions. The list should now be exhaustive. The goal here is to validate the technical details of all remaining fields and to provide a basis for releasing these field definitions as beta in the schema. Use GitHub code blocks with yml syntax formatting, and add them to the corresponding RFC folder.
Expand All @@ -60,6 +56,106 @@ Stage 1: Describe at a high-level how these field changes will be used in practi
Stage 1: Provide a high-level description of example sources of data. This does not yet need to be a concrete example of a source document, but instead can simply describe a potential source (e.g. nginx access log). This will ultimately be fleshed out to include literal source examples in a future stage. The goal here is to identify practical sources for these fields in the real world. ~1-3 sentences or unordered list.
-->

Example usage:

```json
{
"gen_ai": {
"system_instructions": {
[
{
"type": "text",
"content": "You are a assistant for frequent travelers."
},
{
"type": "text",
"content": "Your mission is to assist travelers with their queries about locations around the world."
}
]
},
"input": {
"messages": {
[
{
"role": "user",
"parts": [
{
"type": "text",
"content": "Weather in Paris?"
}
]
},
{
"role": "assistant",
"parts": [
{
"type": "tool_call",
"id": "call_VSPygqKTWdrhaFErNvMV18Yl",
"name": "get_weather",
"arguments": {
"location": "Paris"
}
}
]
},
{
"role": "tool",
"parts": [
{
"type": "tool_call_response",
"id": " call_VSPygqKTWdrhaFErNvMV18Yl",
"result": "rainy, 57°F"
}
]
}
]
}
},
"output" :{
"messages": {
[
{
"role": "assistant",
"parts": [
{
"type": "text",
"content": "The weather in Paris is currently rainy with a temperature of 57°F."
}
],
"finish_reason": "stop"
}
]
},

// Below needs to be updated, but keeping in this commit for illustration purposes.
"assistant": {
"message": {
"content": "To carry a 5lb package, you would need a drone with sufficient payload capacity. Drones designed for heavy lifting often fall in the industrial or commercial category. Consider drones with a payload capacity of at least 6-7lbs to ensure safe transport and account for additional factors like battery and stability.",
"role": "assistant",
"tool_calls": [
{
"function": "getDroneSpecifications",
"arguments": {"payloadWeight": 5},
"name": "getDroneSpecifications",
"id": "toolCall1",
"type": "function_call",
},
{
"function": "retrieveAvailableDronesDocument",
"arguments": {"documentType": "availableDrones", "payloadRequirement": 5},
"name": "retrieveAvailableDronesDocument",
"id": "toolCall2",
"type": "function_call",
}
],
}
},
}
}
}
```


<!--
Stage 2: Included a real world example source document. Ideally this example comes from the source(s) identified in stage 1. If not, it should replace them. The goal here is to validate the utility of these field changes in the context of a real world example. Format with the source name as a ### header and the example document in a GitHub code block with json formatting, or if on the larger side, add them to the corresponding RFC folder.
-->
Expand All @@ -84,6 +180,9 @@ The goal here is to research and understand the impact of these changes on users
Stage 1: Identify potential concerns, implementation challenges, or complexity. Spend some time on this. Play devil's advocate. Try to identify the sort of non-obvious challenges that tend to surface later. The goal here is to surface risks early, allow everyone the time to work through them, and ultimately document resolution for posterity's sake.
-->

In OTel, many field types are set to `any` and are typically .json objects. [Example](https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/)
In ECS, should we use something like [flattened](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/flattened) type, if allowed?

<!--
Stage 2: Document new concerns or resolutions to previously listed concerns. It's not critical that all concerns have resolutions at this point, but it would be helpful if resolutions were taking shape for the most significant concerns.
-->
Expand Down Expand Up @@ -116,7 +215,11 @@ e.g.:
<!-- Insert any links appropriate to this RFC in this section. -->

* https://opentelemetry.io/blog/2024/otel-generative-ai/
* https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-events/
* https://github.com/open-telemetry/semantic-conventions/commits/main/docs/gen-ai/gen-ai-events.md
* https://github.com/open-telemetry/semantic-conventions/pull/2702
* https://www.elastic.co/docs/reference/ecs/ecs-gen_ai#_gen_ai_field_details
* https://github.com/open-telemetry/semantic-conventions/pull/2179/

### RFC Pull Requests

Expand Down