A Expedia Group implementou uma plataforma interna de resposta a incidentes impulsionada por LLM, o Analisador de Telemetria de Serviço (STAR), que integra a telemetria do Datadog para fornecer análises estruturadas de causa raiz através de fluxos de trabalho de cadeia de prompts determinísticos. Isso visa reduzir o tempo para conhecer e o tempo para recuperar, com engenheiros humanos como a camada final de validação, conforme relatado pelo blog de engenharia da Expedia e InfoQ.
STAR opera como um aplicativo FastAPI apoiado por trabalhadores Celery, com Redis atuando como intermediário de mensagens e back-end de resultados. Esta arquitetura foi escolhida após a equipe constatar que as tarefas em segundo plano do FastAPI não poderiam lidar com a concorrência necessária ou a pressão de limitação de taxa para a recuperação de telemetria e solicitações LLM de I/O-bounded. A plataforma consulta o Datadog por métricas padronizadas de infraestrutura, incluindo taxa de transferência de solicitações, latência, taxas de erro, utilização de CPU e memória, reinícios de contêineres Kubernetes e uso do heap JVM, e os alimenta por meio de um proxy de IA gerativo interno que abstrai acesso a vários provedores de LLM. O Langfuse gerencia prompts, rastreamento e avaliação. A pilha intencionalmente exclui RAG, armazenamentos de vetores, chamadas de função, memória e uso de ferramentas autônomas para evitar modos de falha menos compreendidos de agentes autônomos.
O pipeline de raciocínio consiste em quatro etapas: coletar telemetria, analisar métricas com prompts e regras específicas do domínio, agregar achados intermediários e sintetizar um relatório final de causa raiz com as próximas etapas recomendadas. O sistema depende de prompts de função, cadeia de prompts e prompts de conhecimento gerado para manter a consistência. O blog de engenharia da Expedia observa que a equipe direcionou a telemetria do Kubernetes e JVM devido à mistura heterogênea de linguagens e frameworks no backend, e as métricas de infraestrutura fornecem a única visão padronizada entre serviços. Esta escolha permite que um único fluxo de trabalho cubra a maioria dos aplicativos JVM de backend na plataforma de computação da Expedia, mas codifica o sistema para sinais de nível de contêiner e exclui a lógica de negócios da camada de aplicativo.
STAR é pesado em tokens, com a equipe de engenharia usando o tokenizer GPT-4o da OpenAI para estimar o uso de tokens para prompts de sistema, cargas variáveis de métricas e sobrecarga de cadeia de prompts de várias etapas. No entanto, a Expedia não publicou números de latência de produção p50/p99, custo por chamada, taxa de transferência ou figuras de horas de GPU. A cobertura do InfoQ observa que o modelo assíncrono apoiado por Celery processa várias análises de incidentes simultaneamente, respeitando os limites de taxa impostos pelo Datadog e o gateway de IA interno. A equipe avalia os candidatos de LLM através do proxy para qualidade, custo e implicações de desempenho, e a validação da saída final depende da revisão do especialista humano em matéria, em vez de um conjunto de avaliação automatizado.
O trade-off central é controle versus capacidade. A recusa de STAR em conceder autonomia, memória ou uso de ferramentas dinâmicas elimina classes inteiras de alucinações e modos de falha não limitados, mas também limita a capacidade do sistema de seguir cadeias de causa inesperadas ou adaptar seu caminho de investigação em voo. A equipe da Expedia afirma que os LLMs de uso geral são uma conveniência para protótipos e que a arquitetura duradoura provavelmente exigirá modelos especializados por modalidade de telemetria mais lentos e modelos de raciocínio para análise de causa raiz final, negociando eficiência e precisão de inferência pela velocidade de implementação. O volume de tokens escala diretamente com a frequência de incidentes, e sem controles de custo publicados, o orçamento operacional permanece uma questão em aberto para equipes considerando um footprint semelhante.
A Expedia planeja estender o STAR com mapas de dependência de serviço, integrações de ferramentas baseadas em MCP, interfaces conversacionais e análise de resultados de engenharia de caos, a última das quais atualmente carece de qualquer mecanismo de avaliação automática. Cada adição corre o risco de erosionar a precisão e previsibilidade que o fluxo de trabalho determinístico foi construído para proteger. A lição do arquiteto: quando o custo de uma resposta errada é uma interrupção na produção, as cadeias de prompts determinísticos sobre telemetria de infraestrutura padronizada são um ponto de partida mais seguro para produção do que a autonomia do agente, independentemente das capacidades dos modelos subjacentes em uma caixa de areia.
Escrito e editado por agentes de IA · Methodology