Como a Lyft aumentou em 16% sua taxa de resolução com LangSmith e LangGraph

Autoria: LangChain · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How Lyft Increased Its Agent Resolution Rate by 16% with LangSmith and LangGraph · Canal: LangChain · 03:12 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Engenharia de software com IA

Resumo

A Lyft atende centenas de milhares de consultas de usuários por dia, em casos de suporte variados, e busca resolver mais problemas sem encaminhá-los a agentes humanos. Antes de adotar LangSmith, seus agents eram determinísticos e difíceis de avaliar, observar e depurar em produção. A empresa criou uma plataforma self-service para que equipes de produto e operações configurem e publiquem agents, com revisão dos engenheiros e suporte de LangSmith e LangGraph. O tempo para lançar agents caiu de seis meses para uma ou duas semanas, e a taxa de resolução aumentou em 16%.

Pontos-chave

A Lyft recebe cerca de 200 mil a 300 mil consultas de usuários por dia.
A plataforma da empresa cobre de 30% a 40% dos casos de uso.
Os agents anteriores eram determinísticos e baseados em um único LLM com um prompt extenso e acesso a APIs internas.
A falta de evals e de observabilidade dificultava identificar se falhas vinham de tool calls, prompts ou alucinações do LLM.
A Lyft criou uma plataforma self-service para que equipes de produto e operações montem agents com mudanças mínimas de código.
Os prompts ficam no LangSmith Prompt Hub e podem ser revisados por engenheiros antes de serem publicados.
Um meta-agent registra subagents como nós, e a plataforma os compõe dinamicamente a partir de configurações e prompts.
Com tracing, depuração, evals e testes no LangSmith, o prazo de lançamento caiu de seis meses para uma ou duas semanas.
A iteração mais rápida permitiu publicar mais agents e aumentou a taxa de resolução em 16%.

Capítulos

Início	Capítulo	Resumo
00:00	Volume de suporte e agents iniciais	A Lyft descreve a variedade de casos de suporte, o volume de consultas e as limitações dos agents que usava.
01:05	Dificuldades de observabilidade e depuração	A equipe explica por que era difícil identificar falhas e por que queria liberar engenheiros para trabalhos mais complexos.
01:37	Plataforma self-service para criar agents	A Lyft apresenta uma plataforma para equipes de produto e operações configurarem e publicarem agents com revisão dos engenheiros.
02:41	Publicação mais rápida e aumento na resolução	Tracing, depuração, evals e testes reduziram o prazo de lançamento para uma ou duas semanas e elevaram a taxa de resolução em 16%.

Citações

Nossa plataforma cobre cerca de 30% a 40% dos casos de uso. — 00:33

Não sabíamos qual componente do pipeline tinha comprometido a resposta. — 01:05

Cada novo agent agora é apenas uma configuração no repositório de runtime e prompts no LangSmith Prompt Hub. — 02:07

O prazo caiu de seis meses para uma ou duas semanas. — 02:41

Isso definitivamente resultou em um aumento de 16% na taxa de resolução. — 03:12

Conceitos e entidades

Lyft (empresa): Empresa que usa uma plataforma de agents para resolver consultas de suporte de usuários.
LangSmith (ferramenta): Ferramenta usada pela Lyft para tracing, depuração, evals, testes e gestão de prompts.
LangGraph (ferramenta): Ferramenta citada no título do vídeo como parte da solução usada pela Lyft.
LangChain (empresa): Empresa associada às ferramentas mencionadas e responsável pelo canal do vídeo.
LangSmith Prompt Hub (ferramenta): Espaço onde as equipes mantêm prompts que podem ser revisados e publicados.
meta agent (conceito): Agent que reúne subagents registrados como nós e compõe a plataforma dinamicamente.
resolution rate (conceito): Métrica que indica quanto dos problemas de suporte é resolvido sem encaminhamento a agentes humanos.
observability (conceito): Capacidade de acompanhar o comportamento dos agents e identificar componentes que causam falhas.

Tradução completa (pt-BR)

00:00 Os casos de uso de suporte ao cliente são muito abrangentes. Podem ser problemas como perda de objetos e achados, reclamações por danos ou questões relacionadas a impostos. Temos cerca de 500 milhões de interações por dia e quase 200 a 300 mil consultas de usuários por dia. É muita coisa. Então, trabalhamos para passageiros, motoristas e candidatos. Uma das métricas que acompanhamos é a taxa de resolução. Ou seja, quanto conseguimos resolver os problemas dos nossos clientes sem

00:33 encaminhá-los a agentes humanos. Nossa plataforma cobre cerca de 30 a 40% dos casos de uso. Antes de adotarmos o LangSmith, nossos agentes eram bem básicos. Eram muito determinísticos. Talvez fossem um único arquivo de LLM de uma só chamada, com um prompt enorme e várias APIs internas às quais ele podia acessar. Então, não havia sofisticação nas conversas com várias interações. Também não havia avaliações adequadas. A observabilidade era um grande problema, porque lançamos alguns agentes em

01:05 produção e, às vezes, eles não se comportavam como esperávamos. Mas não sabíamos o que fazer a respeito. Não sabíamos qual componente daquele pipeline tinha causado a falha na resposta: se era uma chamada de ferramenta, um prompt ou talvez o próprio LLM tivesse alucinado no meio da resposta. Era difícil depurar os problemas. Estava ficando difícil escalar. Queríamos que nossos engenheiros se concentrassem mais em

01:37 casos de uso mais complexos ou em melhorias fundamentais, em vez de passar todo o tempo criando agentes. Tentamos preencher essa lacuna criando uma plataforma de autoatendimento para pessoas que não são da engenharia, como PMs e equipes de operações, para que pudessem usar o conhecimento do próprio domínio e suas habilidades de prompting em linguagem natural para criar agentes e colocá-los em produção sem fazer muitas alterações no código. Assim, basta uma alteração de configuração e

02:07 eles escrevem alguns prompts no Prompt Hub do LangSmith. Nós, como engenheiros, podemos revisá-los, mas eles são muito fáceis de implantar em produção. O que fizemos foi criar um meta-agente, e todos os subagents são registrados como nós nesse meta-agente. Fazemos isso dinamicamente quando iniciamos o serviço. Agora, cada novo agente é apenas uma configuração que mantemos em um repo de runtime e prompts que mantemos no Prompt Hub do LangSmith. Então, buscamos isso e a plataforma cuida do restante.

02:41 Assim, tudo ficou bem fácil. Com o tracing, a depuração, as avaliações e os testes do LangSmith, tudo ficou muito mais fluido e fácil. Foi uma grande melhoria para colocar coisas em produção. Antes, isso levava seis meses, mas, com a plataforma de criação de agentes que desenvolvemos, o prazo caiu para algumas semanas, uma ou duas semanas. Isso é muito empolgante, porque agora temos tempo livre para nos concentrarmos em melhorias mais complexas e fundamentais

03:12 enquanto PMs e outras pessoas das equipes de operações podem colocar agentes em produção diretamente. O ciclo de iteração ficou mais rápido. Colocar soluções em produção mais rapidamente nos permitiu criar mais agentes e cobrir mais problemas em produção, e isso certamente resultou em um aumento de 16% na taxa de resolução. Então, sim, desde que começamos a usar o LangSmith e o LangChain.

Transcrição original

[00:00] Customer support use cases is very broad. It can be like issues like lost and found or issues like damage claims or issues like taxes. We have like 500 million type of interactions every day and we have almost like 200 to 300,000 user queries per day. Which is a lot. So we work for riders, drivers and applicants. One of the metrics we go for is what’s like the resolution rate. So how much how much can we solve our customer issues without

[00:33] escalating them to human agents. Our platform covers about 30 to 40% of use cases before we adopted LangSmith, our agents were pretty basic. They were very deterministic. Maybe like a one single shot LLM file with a huge prompt and a bunch of internal APIs it can access. >> [music] >> So there was no like sort of sophistication in multi-turn conversations. There were no evaluations, proper evaluations. The observability was a was a big issue because we we kind of launched a few agents in

[01:05] production and sometimes it did not behave as we expected it to be. But then we didn’t know what to do about it. Like we didn’t know which component inside that pipeline broke the response, whether it was a tool call or like a prompt or maybe like LLM itself hallucinated in between providing a response. So it was it was difficult to debug issues. It was getting difficult to scale. So we wanted our engineers to focus more on

[01:37] more complex use cases or maybe like foundational improvements and not spend all of their time building agents. We tried to bridge this gap by creating a self-serve platform for our non-engineering people like PMs and ops where they can use their own domain and natural language prompting skills to build agents and ship them to production without making a lot of code changes. So, it’s merely like a config change and

[02:07] they they write some prompts on LangSmith prompt hub. We as an engineers can review them, but they are like very easily deployable to production. [music] So, what we did was we have like a meta agent and all the sub-agents are kind of registered as nodes in that meta agent. And we we do that dynamically when we start the service. So, every new agent now it’s just like a config which we have in a runtime repository and prompts which we have in the LangSmith prompt hub. So, we just pull that and like the the

[02:41] platform composes rest of the things. So, it’s become pretty easy and because of LangSmith tracing, the debugging and evaluations, testing, everything has become like very smooth and very easy. It was a huge upgrade to ship to production. But then with this agent builder platform [music] that we have created, that has reduced to from 6 months to a to a few weeks, uh 1 [music] to 2 weeks. And that’s pretty exciting because now like we have free time to focus on more complex and foundational improvements

[03:12] while PMs and other ops people can directly ship agents. So, it’s it’s the iteration loop has become faster. Shipping faster has enabled us to create more agents and like cover more issues in production and that’s definitely resulted in >> [music] >> uh increase in resolution rate by 16%. So, yeah, since we have started using LangSmith [music] and LangChain.