O SessionStore é um recurso de armazenamento e análise no nível de sessão que o Simple Log Service (SLS) oferece para aplicações de IA. Ele é adequado para cenários como solução de problemas de agentes, otimização de desempenho, avaliação de efeitos, auditoria de segurança e análise de custos. O SessionStore associa sessões de usuário com múltiplas interações aos logs da aplicação, entradas e saídas do modelo, trajetórias de execução e chamadas de ferramentas. Isso permite rastrear uma resposta anômala camada por camada até a etapa específica de execução, localizar problemas como respostas incorretas, falhas em chamadas de ferramentas e alta latência na cadeia de chamadas, além de analisar o consumo de tokens e o uso de modelos e ferramentas. O SessionStore fornece suporte de dados para a otimização contínua e operação de aplicações de IA.
O que é o SessionStore
Um SessionStore reside em um projeto do Simple Log Service. Gerencie os SessionStores de diferentes aplicações em um único projeto e visualize os dados da mesma aplicação em diferentes visualizações.
|
Visualização de dados |
Conteúdo |
Perguntas típicas |
|
Dados brutos |
Logs brutos ingeridos ou associados |
Os dados foram reportados com sucesso? Os campos brutos estão corretos? |
|
Trajetória única |
Entradas e saídas, etapas e relações de agentes de uma execução |
Onde o tempo foi gasto em uma solicitação e quais ferramentas foram usadas? |
|
Sessões |
Interações com múltiplas voltas e trajetórias de execução associadas por ID de sessão |
Qual é o contexto de uma sessão e em qual volta ocorre uma exceção? |
|
Recursos da trajetória |
Eventos de ferramentas, arquivos, habilidades ou memória extraídos do processo de execução |
Quais tipos de ferramentas retornam erros frequentemente e quais trajetórias acessaram um arquivo específico? |
Conceitos básicos
|
Conceito |
Descrição |
|
Dados brutos (Raw) |
Logs reportados por aplicações, coletores ou gateways. Os dados brutos são a base para solucionar problemas de coleta e de campos. |
|
Trajetória |
Representação estruturada de um processo de execução, incluindo entradas e saídas, etapas de execução e relações de chamada de agentes fornecidas explicitamente nos dados. Não trate cada span bruto como uma trajetória separada. |
|
Sessão |
Grupo de interações associadas pelo mesmo ID de sessão. Uma sessão pode conter múltiplas trajetórias de execução. |
|
Recurso da trajetória |
Registro estruturado de um tipo de comportamento em um processo de execução, como chamadas de ferramentas e leituras/escritas de arquivos. Os registros de recursos servem para recuperação e estatísticas, não sendo equivalentes a pontuações de qualidade. |
|
Etapa |
Evento em uma trajetória, como uma interação com modelo, chamada de ferramenta ou retorno de ferramenta. |
|
Trace ID |
Identificador usado para associar uma execução de uma cadeia de chamadas. A disponibilidade deste identificador depende da fonte de dados. |
Selecione um modo de ingestão de dados
O SessionStore suporta dois modos: gravação direta e referência.
|
Item |
Modo de gravação direta (gerenciado) |
Modo de referência (referência) |
|
Cenário |
Ingestão de dados de uma nova aplicação ou gravação direta em um SessionStore. |
Dados da aplicação já coletados em um Logstore padrão. |
|
Local de gravação de dados |
O SessionStore no projeto atual |
O Logstore source original |
|
Necessidade de selecionar um Logstore source durante a criação |
Não |
Sim. É obrigatório selecionar um projeto source e um Logstore source. |
|
Escopo da fonte de dados |
Pipeline de ingestão do SessionStore atual |
Logstore padrão pertencente à mesma conta Alibaba Cloud e residente na mesma região. O Logstore pode pertencer a um projeto diferente. |
|
Gerenciamento de configuração de coleta |
Gerenciado a partir da entrada de ingestão de dados do SessionStore |
Gerenciado no Logstore source |
|
Índice de dados brutos |
Pode ser criado ou modificado no SessionStore |
Somente leitura no SessionStore. Modifique o índice no Logstore source. |
|
Ajuste da política de retenção do SessionStore |
Ajusta os dados gerenciados pelo SessionStore |
Não altera a política de retenção do Logstore source |
Formatos de dados suportados
|
Formato de dados |
Fonte aplicável |
|
OpenTelemetry Trace |
Cadeias de execução e dados GenAI reportados na forma de traces ou spans do OpenTelemetry. Logs de trace ingeridos usando agentes do Cloud Monitor 2.0 ou Application Real-Time Monitoring Service (ARMS), ou logs de trace ingeridos via SDK do OpenTelemetry. |
|
OpenTelemetry Log Ebpf |
Logs de agente eBPF coletados no formato correspondente. Logs coletados usando o plug-in input_agentsight do LoongCollector no Simple Log Service. |
|
OpenTelemetry Log AI Gateway |
Logs do Alibaba Cloud AI Gateway |
Cenários típicos
Solucione problemas de resposta anômala
Quando um agente retorna uma resposta incorreta, uma chamada de ferramenta falha ou uma tarefa não é concluída conforme o esperado, visualize as entradas e saídas do modelo, parâmetros de ferramentas e resultados retornados na trajetória de execução para localizar a etapa onde a exceção ocorreu. Verifique também a base da resposta comparando-a com os logs brutos associados. Por exemplo, se um agente de atendimento ao cliente responder que o pagamento de um pedido não foi recebido, rastreie a consulta do pedido, registros de pagamento e informações de falha para determinar se a resposta tem respaldo factual.
Analise a colaboração entre múltiplos agentes
Se uma tarefa for executada por vários agentes, utilize as relações entre o agente principal e os subagentes registradas na trajetória para reconstruir o processo de delegação de tarefas, execução de ramificações e retorno de resultados. Essa abordagem ajuda a identificar qual agente causou um problema e como os resultados das ramificações afetam a resposta final. Por exemplo, após um agente de atendimento delegar a solução de falhas a um agente de diagnóstico, verifique se o resultado do diagnóstico foi utilizado corretamente.
Acompanhe sessões de múltiplas voltas e resultados de tarefas
Caso um usuário faça perguntas complementares sobre o mesmo problema, use a sessão para associar cada volta da conversa à sua trajetória de execução. Em seguida, compare alterações no status do negócio, resultados de consultas de cada volta e respostas do agente para verificar se ele atualizou seu julgamento com base em novas evidências. Por exemplo, em uma série de interações envolvendo "pagamento realizado mas não recebido", "serviço restaurado" e "pagamento verificado novamente", distinga a restauração do serviço do recebimento efetivo do pagamento do pedido. Identifique também casos em que o agente depende de contexto desatualizado ou afirma que o problema foi resolvido sem verificação.
Analise latência de execução e consumo de recursos
Para situações em que um agente responde lentamente ou consome muitos tokens, analise o número de chamadas, latência de execução e uso de tokens por sessão, volta, modelo e agente. Faça drill down em chamadas específicas de modelos, ferramentas e ramificações de colaboração para identificar etapas com concentração de latência e execuções repetidas. Esses dados fundamentam ajustes na seleção de modelos, organização de contexto e fluxos de trabalho colaborativos.
Audite operações de agentes e base de execução
Ao precisar verificar se um agente segue os requisitos da tarefa, utilize nomes de ferramentas, parâmetros de chamada, resultados retornados e registros brutos para rastrear as operações realmente executadas. Valide os resultados confrontando-os com os comprovantes de negócio associados. Por exemplo, em uma tarefa que permite apenas consultas de pedidos, confirme se os registros de execução coletados contêm chamadas de reemissão ou reembolso e se a resposta afirmando que o pagamento foi recebido possui respaldo nos registros financeiros.
Construa amostras de avaliação e regressão
Para validar o impacto de alterações em um modelo, prompt ou versão de agente, organize perguntas e respostas consecutivas, trajetórias de execução e resultados de ferramentas de sessões de produção em amostras de avaliação. Essas amostras fornecem contexto reutilizável e evidências de execução para sistemas de avaliação como o AgentLoop. Por exemplo, utilize uma sessão onde o service foi restaurado mas não há registro de pagamento como caso de regressão, verificando se a nova versão ainda respeita a regra de não afirmar o recebimento do pagamento sem comprovante.