会话日志
每次聊天机器人的执行都会被结构化成事件记录下来,可导出到流式数据集,用于监控与分析。
https://www.palantir.com/docs/foundry/chatbot-studio/session-logging/
原始标题:AIP Chatbot Studio • Session logging • Palantir · 所属:AIP Chatbot Studio(做对话机器人)
先记住这几条
写在前面
AIP Chatbot Studio 中的聊天机器人执行会以结构化事件的形式记录日志,这些事件可以导出到 Foundry 流式数据集,用于监控和分析。每条发送给聊天机器人的消息算作一次执行,每次执行都会被分配一个唯一的 trace 标识符,用于关联所有相关的日志条目。
聊天机器人会话日志导出使用配置日志记录功能。事件 schema 和事件类型可能会发生变化。可能会新增事件,现有 schema 也可能被修改。
前置条件
理解聊天机器人执行日志
每个日志条目都包含由日志 schema 提供的通用字段,以及聊天机器人特有的事件数据。聊天机器人特有的数据由一个 event_name 和一个描述执行期间所发生情况的 payload 组成。
Common log fields
以下字段包含在每个日志条目中,可用于筛选和关联日志。执行流程中来自各产品的日志(例如函数执行和语言模型使用)也共享这些字段,因此你可以用它们来追踪完整的执行请求:
| Field | Type | Description |
|---|---|---|
traceId | String | 分配给每次执行的 Foundry trace 标识符。同一次执行的所有日志条目共享相同的 traceId。用它来端到端地追踪一个请求。 |
uid | String | 发送消息的用户的标识符。 |
owning_rid | String | 发起此次执行的源执行器的资源标识符,例如聊天机器人、函数或 Workshop 应用程序。例如,如果 Chatbot A 调用了一个函数,而该函数又调用了 Chatbot B,那么由此产生的所有日志的 owning_rid 都是 Chatbot A 的 RID。用它来查找来自某个特定源执行器的所有日志,无论调用链有多深。 |
Chatbot event data
每个聊天机器人事件都包含一个标识事件类型的 event_name,以及一个带事件专属字段的 payload。每个事件 payload 都包含一个 session_rid,用于标识聊天机器人会话。用它来把单次对话中的所有事件归组到一起。
Sample log structure
以下是 user_request 事件日志条目的简化示例:
{
"time": "2024-01-15T09:30:00.000Z",
"uid": "<USER_ID>",
"traceId": "<TRACE_ID>",
"content": {
"event_name": "user_request",
"payload": {
"session_rid": "ri.aip-agents..session.<SESSION_ID>",
"user_query": {
"content": [
{
"text": {
"content": "Summarize the key points from the latest press conference transcript."
}
}
]
}
}
}
}事件类型
聊天机器人执行期间会记录以下事件类型:
| Event name | Description |
|---|---|
session_metadata | 在执行开始时记录聊天机器人 RID、聊天机器人版本、会话 RID 和调用方标识符。 |
user_request | 捕获用户的消息,以及所有 retrieval context 和应用变量。 |
system_chat_message | 包含发送给 LLM 的已编译系统提示词,其中包括工具定义。 |
user_chat_message | 包含发送给 LLM 的用户消息内容。 |
assistant_chat_message | 包含 LLM 的回复内容,其中可能包括文本或工具调用。 |
tool_call | 记录一次工具调用,包括工具名称和解析后的输入。 |
tool_call_result | 记录一次工具调用的结果,包括其成功或失败,以及耗时。 |
final_response | 包含聊天机器人返回给用户的最终回复。 |
execution_error | 记录执行期间发生的错误。 |
Session metadata
在每次执行开始时记录一次,包含有关聊天机器人和会话的标识信息。
| Field | Type | Description |
|---|---|---|
agent_rid | String | 聊天机器人的资源标识符。 |
agent_version | String | 聊天机器人的版本。 |
session_rid | String | 会话的资源标识符。 |
caller_identifier | String | 发起此次执行的调用方的标识符。 |
User request
捕获用户消息的完整上下文,包括为此次执行解析出的所有 retrieval context 和应用变量。
| Field | Type | Description |
|---|---|---|
session_rid | String | 会话标识符。 |
user_query | UserQuery | 用户的消息内容,可能包括文本和媒体。 |
contexts_from_profile | List\<Context> | 从聊天机器人已配置的上下文源解析出的 retrieval contexts。每个 context 代表一种特定的上下文类型,例如 Ontology、document、function-backed 或自定义文档。 |
contexts_from_user_input | List\<Context> | 从用户输入解析出的 retrieval contexts。 |
application_variables | List\<ApplicationVariable> | 请求时的应用变量及其值。每个变量都包含其标识符、名称、值和提示词可见性设置。 |
node_id | String | 执行节点的标识符。 |
parent_node_id | String(可选) | 此执行所延续的会话节点的标识符。 |
Chat messages
system_chat_message、user_chat_message 和 assistant_chat_message 事件具有相似的结构。
| Field | Type | Description |
|---|---|---|
session_rid | String | 会话标识符。 |
content | List\<Content> | 消息内容,可能包括文本、媒体引用或工具调用。 |
native_tools | List\<NativeTool> | 使用 native tool calling 模式时 LLM 可用的工具。仅存在于 system_chat_message 中。在 prompted tool calling 模式下配置的工具则包含在 content 字段中。 |
Tool calls
tool_call 事件记录聊天机器人调用某个工具的情况。
| Field | Type | Description |
|---|---|---|
session_rid | String | 会话标识符。 |
tool_name | String | 被调用工具的名称。 |
parsed_tool_input | Map\<String, String> | 输入参数名称到其值的映射。 |
Tool call results
tool_call_result 事件记录一次工具调用的结果。
| Field | Type | Description |
|---|---|---|
session_rid | String | 会话标识符。 |
tool_name | String | 被调用工具的名称。 |
tool_call_id | String(可选) | 该次具体工具调用的标识符。 |
duration_milliseconds | Long | 该次工具调用执行所花费的时间,以毫秒为单位。 |
result | ToolResult | 该次工具调用的结果,为以下之一: |
ToolResult 类型为以下之一:
- Success: 包含一个
llm_value(String),即返回给 LLM 的值;以及一个variable_updates列表,其中包含所有被更新的应用变量的变量名和新值。 - Failure: 包含一个
error_message(String)和一个说明工具调用失败原因的reason(String)。
Final response
包含聊天机器人对用户的最终回复。
| Field | Type | Description |
|---|---|---|
session_rid | String | 会话标识符。 |
response | FinalResponse | 回复内容,为以下之一: |
FinalResponse 类型为以下之一:
- Chatbot response: 包含一个内容项列表,其中可能包括文本和媒体。
- Client tool call: 表示聊天机器人将交由客户端操作处理,而不是返回直接回复。
Execution errors
在执行期间发生错误时记录。
| Field | Type | Description |
|---|---|---|
session_rid | String | 会话标识符。 |
error_name | String | 错误的名称或类型。 |
示例
Reconstruct a conversation
若要重建与某个特定聊天机器人的聊天对话:
- 筛选
owning_rid与该聊天机器人 RID 匹配的日志。 - 进一步按
session_rid筛选,以隔离出单次对话。 - 对于用户消息,查找
event_name为user_request的条目,并从 payload 中提取user_query。 - 对于聊天机器人的回复,查找
event_name为final_response的条目,并从 payload 中提取response。
Evaluate tool performance
若要分析工具的表现:
- 查找
event_name为tool_call_result的条目。每个条目都包含tool_name、duration_milliseconds,以及该次调用是成功还是失败。 - 若要衡量可靠性,请按工具比较成功结果与失败结果的数量。
- 若要找出较慢的工具,请按
duration_milliseconds排序。 - 若要检测重试,请在单个
traceId内查找具有相同tool_name的多组tool_call和tool_call_result配对。一次失败之后又对同一工具发起另一次调用,即表明聊天机器人进行了重试。
延伸阅读 · 相关页面
按主题横向跳转,不必顺着目录一篇篇读。
本组其他页面 · AIP Chatbot Studio(做对话机器人)
同一主题下的相邻内容。
- AIP Chatbot Studio 总览想做一个懂你业务、能引用出处、能调工具的对话机器人?AIP Chatbot Studio(原名 AIP Agent St
- Chatbot Studio 核心概念这页把搭建聊天机器人要用到的关键概念一次讲全:应用状态、检索上下文、工具、引用等。
- Chatbot Studio 快速入门这一篇带你从零搭一个基础聊天机器人:认识界面、配置信息与工具,然后部署到生产并监控。
- 应用状态(Application state)聊天机器人要记住会话里的信息,才能做多轮推理。应用状态就是它的"工作记忆"。
- 检索上下文类型(Context types)机器人回答得好不好,八成取决于喂给它的上下文。检索上下文针对每一条新消息确定性地运行,把相关内容塞进模型。
- 引用(Citations)回答要可信,就得能指出来源。配置了文档或 Ontology 上下文的机器人会输出引用,点击可跳回原始材料。
- 工具(Tools)工具是外部功能或 API,让 LLM 能执行操作或获取自身不具备的信息。有了工具,机器人从"能说"变成"能做"。
- 把命令用作工具平台里的命令(command)可以直接挂成机器人的工具 —— 用户一句自然语言,就能触发应用里的具体操作。
- 把聊天机器人发布为函数发布为函数(Function)后,你的聊天机器人就能在平台里任何可执行函数的地方被调用 —— 复用性大幅提升。
- 用 Marketplace 分发聊天机器人把聊天机器人打包成产品,分发给别的团队/环境安装使用 —— 这是从"自己用"到"组织内复用"的一步。
- 通过 Foundry API 使用聊天机器人要在 Foundry 平台之上自建应用?这一篇讲用 Palantir API 调起会话、发消息、拿回复。
常见问题速答 · FAQ
关于「会话日志」,读者最常问的几个问题。